Skip to content

Instantly share code, notes, and snippets.

Just coding

Kyle Simpson getify

Just coding
View GitHub Profile
getify / memtest-results.txt
Last active Aug 29, 2015
profiling memory usage issues with parsing a big JSON database
View memtest-results.txt
> 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 / gist:8903246
Created Feb 9, 2014
function declarations in blocks?
View gist:8903246
"use strict";
foo(); // "b"
var a = true;
if (a) {
function foo() { console.log("a"); }
else {
function foo() { console.log("b"); }
getify / gist:8902610
Last active Aug 29, 2015
how i wish JS generators could have worked
View gist:8902610
// 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 / gist:8911224
Last active Aug 29, 2015
another idea that'll never happen
View gist:8911224
// {?( .. ) 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 features
// that have breaking syntax. You construct a FT for the feature
// and if the test succeeds, use it, otherwise skip it.
getify / gist:8921982
Created Feb 10, 2014
using for an async forEach()
View gist:8921982
function handleItem(val,cb) {
setTimeout( function(){
console.log( val );
}, 100 );
getify / gist:9107067
Created Feb 20, 2014
exploring generators + parallel-promises for a single "step"
View gist:9107067
// 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?
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 / gist:9105362
Last active Aug 29, 2015
Exploring why I wish ES6's `for-of` had a syntax for sending in values to each iteration's `next(..)` call
View gist:9105362
// 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 / gist:9118029
Last active Aug 29, 2015
how sync/async inconsistency + setTimeout hack == race condition
View gist:9118029
// 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
getify / gist:9117527
Last active Aug 29, 2015
Trying to illustrate the sync/async inconsistency between promise initialization and promise chaining.
View gist:9117527
// 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){
getify / gist:9110935
Last active Aug 29, 2015
promise sync vs async?
View gist:9110935
// 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){
You can’t perform that action at this time.