getify

> node --expose-gc memtest.js

On my 64bit mac, this process uses about 391mb of memory according to "Activity Monitor".

> node --expose-gc memtest2.js

By contrast, if I read in 3.1mm records nearly identical to those being generated, from a .json file,
this process fills up 1.5gb of memory quickly, then crawls to a halt, and takes a REALLY long time to 
get all the records finally pulled in (like hours).

getify

// I wish that generators allowed you to call next(..)
// at the first step with a value, and that value was
// the first (named) argument to the generator itself.
//
// see `next(3)` below setting `msg` to `3`.
//
// It would mirror how `return` is overloaded to do the final
// `yield`: by letting an argument be the initial "yield target"
// of an iterator-sent message.

getify

"use strict";

foo(); // "b"

var a = true;
if (a) {
   function foo() { console.log("a"); }
}
else {
   function foo() { console.log("b"); }

getify

// {?( .. ) opens up a conditionally compiled block.
// inside the ( .. ), you do a test, which is evaluated
// to see if the contents of the block should be compiled
// or not. If success, proceeds as a normal { .. } block
// of code. If test fails, entire contents of block
// are ignored and not compiled (no syntax errors)
//
// This would primarily be useful for using ES.next features
// that have breaking syntax. You construct a FT for the feature
// and if the test succeeds, use it, otherwise skip it.

getify

function handleItem(val,cb) {
	setTimeout( function(){
		console.log( val );
		cb();
	}, 100 );
}

ASQ()
.map(
	[1,2,3,4,5]	

getify

// This example shows a simple data structure object that holds
// a sequence of numbers from 0 to 99. It defines its own iterator
// which lets you dump all those values out using a `for-of` loop.
//
// Note: the iterator accepts a value to `next(..)` which represents
// a step value, if you wanted to get only every nth value from
// the sequence.
//
// Unfortunately, ES6's for-of doesn't have a syntax for passing in
// a value to that default per-iteration `next(..)` call that occurs. :(

getify

// is this how most people see CLEANLY doing the task of
// firing off multiple "parallel" tasks at a single step
// in a generator, using parallel promises (aka, `all()`)?
//
// or is there another pattern for "parallel" generator steps?

spawn(function*(){
	var [x,y] = yield Promise.all(getValue(10),getValue(12));
	var z = yield getValue(20);
	console.log("Meaning of life: " + (x+y+z)); // Meaning of life: 42

getify

// Hey, what gives here? This is weird and unexpected.
// Why is the promise factory called synchronously, when
// all the other steps resolve async? For consistency,
// one would expect them all to be async.

var p = new Promise(function(resolve,reject){
   console.log("what");
   resolve();
});

getify

// For consistency sake, would expect:
//       1, 2, 3, 4, 5
// actually gets, confusingly:
//       1, 2, 4, 3, 5


var p = new Promise(function(resolve,reject){
	resolve();
});

getify

// expected:
//     1, 2, 3, 4, 5
// got:
//     1, 2, 3, 5, 4
// ...
// :(

// by using the setTimeout "hack" that @domenic suggests, now we
// create a race-condition between "4" and "5", and
// confusingly, "5" wins