creationix

var five = require('johnny-five');

var board = new five.Board();

board.on("ready", function () {

  var leds = new Array(5);
  for (var i = 0; i < 5; i++) {
    leds[i] = new five.Led({pin: i + 5});
  }

domenic

import { absolutizeRelativeSelectorList } from "http://dev.w3.org/csswg/selectors/#absolutizing";

// Assume JSIDL conversions have been applied already,
// i.e. we don't do `selectors = String(selectors)` manually.
class Elements extends Array {
    query(selectors) {
        return this.queryAll(selectors)[0]; // highly inefficient obviously, but clear semantics
    }
    
    queryAll(selectors) {

Protonk

var five = require("./lib/johnny-five.js"),
    board, slider;

board = new five.Board();

board.on("ready", function() {
    
  var accel = new five.Accelerometer({
    pins: [ "I0", "I1" ],
    freq: 100

polotek

// Grab the EventEmitter constructor. events is a core node module.
var Emitter = require('events').EventEmitter;

// Our internal function will generate random numbers
function randomInt(limit) {
  return Math.ceil( Math.random() * limit );
}

module.exports = function(limit) {
  if(!(limit && limit > 0)) {

jorendorff

class Mapping {
    // Subclasses define at least @@iterator().
    @@iterator() {
        throw TypeError("abstract operation")
    }

    // Mutable subclasses also define set() and delete().
    set(key, value) {
        throw TypeError("mapping is not mutable");
    }

domenic

Unabashed Monadic Promises on top of Q-Like Promises

Using the terminology from Mark Miller's "The Paradox of Partial Parametricity", this gist shows how you can build unabashed monadic promises on top of Q-like promises.

Problem Statement

Given:

Q: Ref<t> → Promise<t>

Protonk

# fast json library for R. 
# drop in replacement for rjson (another library)
# use whatever you prefer
library(RJSONIO)

## hardcoded for this test 

ny.json <- fromJSON("/Users/protonk/dev/R/nomnom/data.json")

unflatten <- function(json) {

dfkaye

2013-3-30

Some recent activity from active contributors regarding ES6 proposals threaten to undermine its acceptance from the community at large.

ES6 proposals include the fat arrow, destructured assignment, splat args, let/block scope, class syntax, class-based inheritance, setters/getters with export, the module loader syntax, weak maps, weak events, @symbols, and so forth.

That is a lot for a community user of the language to comprehend. It is a lot for a single iteration of any project.

The sheer amount of change is at root of the confusion apparent even among the es-discuss mailing list ~ [see this conversation for an example] (https://twitter.com/kangax/status/315863525899780096 ""that was removed from the spec", "I thought it was back in", "it's on the table", "'on the table' does not mean 'in the spec'"").

jlongster

struct Point {
  function void Point(double x, double y) {
      this->x = x;
      this->y = y;
  }

  double x, y;
}

function int add1(int x) {

cowboy

// OOP
console.log( 'OHAI'.blink() );

// Call invocation
console.log( String.prototype.blink.call('OHAI') );

// $ always makes things look awesome.
var $ = Function.prototype.call;

// Very explicit call invocation