COLLECTED BY

Organization: Archive Team

Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.

History is littered with hundreds of conflicts over the future of a community, group, location or business that were "resolved" when one of the parties stepped ahead and destroyed what was there. With the original point of contention destroyed, the debates would fall to the wayside. Archive Team believes that by duplicated condemned data, the conversation and debate can continue, as well as the richness and insight gained by keeping the materials. Our projects have ranged in size from a single volunteer downloading the data to a small-but-critical site, to over 100 volunteers stepping forward to acquire terabytes of user-created data to save for future generations.

The main site for Archive Team is at archiveteam.org and contains up to the date information on various projects, manifestos, plans and walkthroughs.

This collection contains the output of many Archive Team projects, both ongoing and completed. Thanks to the generous providing of disk space by the Internet Archive, multi-terabyte datasets can be made available, as well as in use by the Wayback Machine, providing a path back to lost websites and work.

Our collection has grown to the point of having sub-collections for the type of data we acquire. If you are seeking to browse the contents of these collections, the Wayback Machine is the best first stop. Otherwise, you are free to dig into the stacks to see what you may find.

The Archive Team Panic Downloads are full pulldowns of currently extant websites, meant to serve as emergency backups for needed sites that are in danger of closing, or which will be missed dearly if suddenly lost due to hard drive crashes or server failures.

Collection: Archive Team: URLs

TIMESTAMPS

tj/co

The ultimate generator based flow-control goodness for nodejs (supports thunks, promises, etc)

Mark Moore

@mmoo9154

Maybe add that tip to the co doc on npm. ;-) "google "coroutines" if you really wanna see how crazy this stuff can be."

LeonineKing1199

@LeonineKing1199

But they're crazy to implement in C++

TJ's not big on updating co

co is supposed to die when async/await are released officially

Mark Moore

@mmoo9154

ahhh...

LeonineKing1199

@LeonineKing1199

Yeah, if you look on the github issues for co, you'll see him specifically deny requests for expanding the module

Mark Moore

@mmoo9154

Well, thanks again!

LeonineKing1199

@LeonineKing1199

No problem!

I'm like the only one here. But I'm allergic to work so I can answer any questions you may have :)

Mark Moore

@mmoo9154

Is there a way to save this transcript? I haven't used gitter before just now

LeonineKing1199

@LeonineKing1199

Um, not that I'm aware of

Mark Moore

@mmoo9154

LeonineKing1199

@LeonineKing1199

There's a C++ gitter that I'm a part of too

So if you ever feel like chatting about C++, there is a gitter for it

Barney Carroll

@barneycarroll

Hi folks!

I've been working with promises for ages, and

in the last year I've been using async / await with some delight

Something I didn't get early on in my playing with async / await was a fair bit of criticism that deemed the proposal redundant since we already had generators

This was because I'd never really grokked generators, they were too broad in their use cases and I'd never come up with a scenario where I'd used them to significant effect

Barney Carroll

@barneycarroll

However recently I've discovered the power of splitting low level logic into subroutines and I've realised just how useful generators can be

co was always cited as the empowering toolkit that made generators shine, so I thought I'd come back and read a bit in the hope of getting some more ideas of the possibility space of generators

Barney Carroll

@barneycarroll

And I'm surprised to see that the README says generators and generator functions are now only consumable as yieldables as a backward compatibility measure, with the recommendation being that people use promises instead

This strikes me as odd, since it suggests that in the modern spec world, co is essentially relegating itself to async / await with special unwrapping behaviour

Does anyone have any insight as to the rationale behind "avoid yielding generators"?

LeonineKing1199

@LeonineKing1199

I'm not sure I understand the logic as well :P

Delegating generators just increases the amount of iterations the generator supports

Maybe it's a pain in the ass to maintain the code? Though I couldn't see how that's true

It's simple to yield co(...); though so I'm not complaining

I think it's because in the future, await will only work with promises

co was built with planned obsolescence in mind. Generator delegation probably is a hurdle to that because it won't work natively with await

Barney Carroll

@barneycarroll

TBH I've had mysterious problems trying to get recursive generators to work anyway, I can't blame co for wanting to keep the API predictable and limit generators to anonymous constructs wrapped in a co call

LeonineKing1199

@LeonineKing1199

I'm glad someone brought some life into this gitter :P

Barney Carroll

@barneycarroll

Haha

Transient life!

LeonineKing1199

@LeonineKing1199

I think TJ's main goal was to have co be used and then when ES7 hits, people can just replace yield with await and it'll all just work

Sorry, I keep thinking about the rationale for the delegation deprecation

Barney Carroll

@barneycarroll

Ironic considering the volume of people saying async / await are unnecessary precisely because we have generators / yield

joystick

@joystick

Hi there, looking for advise how can one yield from underscore.js callbacks, e.g. from _.map().

joystick

@joystick

trying to do smth like:

_.each(transactionTypes, function*(transactionTypes) {
        state[transactionType] = yield db.collection(transactionType).find().toArray(); 
    });

LeonineKing1199

@LeonineKing1199

You can't yield from inside callbakcs

You'll have to use a for-loop

joystick

@joystick

Thanks @LeonineKing1199 I moving towards it. Could you please check what's wrong with following?

co(function * () {
    var state = {};
    state.db = yield MongoClient.connect('mongodb://localhost/test');
    return state;
})
.then(function(state) {
    console.log(state.db);
    state.transactionTypes = yield state.db.collection('Transaction').distinct('TxnType');
    return state;
})
.then(function(state) {
    console.log(state.transactionTypes);
    state.db.close();
})
.catch(function(error) {
    console.error(error);
});

joystick

@joystick

It tells me

C:\Users\ak\Documents\code\qb\export.js:14
    state.transactionTypes = yield state.db.collection('Transaction').distinct('TxnType');
                                   ^^^^^

SyntaxError: Unexpected identifier
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:373:25)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Function.Module.runMain (module.js:441:10)
    at startup (node.js:139:18)
    at node.js:968:3

joystick

@joystick

I think I got the idea - I'm not returning promise from .then().

LeonineKing1199

@LeonineKing1199

Nope

Actually, why are you even chaining Promises?

Basically, takes what's inside all your .then functions and put it inside your generator function*

You can only yield from inside generators

LYF

@pod4g

Hi. there is a statistical analysis tool for performance testing https://github.com/pod4g/hiper/

Feb	MAR	Apr
	09
2020	2021	2022

Where communities thrive

People

Repo info

Activity