lawnsea

I can't fit everyone's handles in a single tweet, so let's do this here.

Info so far:
- Alex is carless and will be south of the river, downtown
- Aaron will show up btwn 8 and 9
- Lon is available after 6:45
- Dave and Garann are out

I propose two options:
- HH and food trucks on the East side, starting 6:30ish (we'll need to transport Alex)

lawnsea

var Player = (function () {
    
    var Player, generateGuid, maxCoins, secrets, get, set, cashIn;

    maxCoins = 100;

    // via http://stackoverflow.com/questions/105034/how-to-create-a-guid-uuid-in-javascript
    generateGuid = function () {
        return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {
            var r, v;

lawnsea

Goal

We would like to observe changes to the DOM and, for each changed element el, call one or more functions f1, f2, ..., fn, passing el as an argument to each. For each function, if it returns true, add a CSS class C to el, and otherwise remove class C from el.

Solution

Register a mutation observer on the root element of the DOM. The mutation observer is responsible for tracking the "generation" of all elements in the DOM and for marshalling MutationRecords to a Web Worker. Specifically:

1. For each mutation:

• increment the generation of the mutated element and its ancestors

lawnsea

XXX: this will not work

the callback can go cause trouble, calling other functions, including awaitCallback. this is a non-starter.

instead, something like this might be the place to start:

var awaiter = new Awaiter;
setTimeout(awaiter, 100);
// any args that would have been passed to the callback are returned

lawnsea

define([
  'intern!tdd',
  'intern/dojo/node!leadfoot/helpers/pollUntil',
],
function (tdd, pollUntil) {
  tdd.suite('pollUntil', function () {
    tdd.test('should call the errback if it times out', function () {
      return this.get('remote')
        .get('http://google.com')
        .then(pollUntil(function () {

lawnsea

I have been watching the current discussions about running a virtual DOM in a web worker with a great deal of interest. In 2011, I built a research project, [Treehouse][] ([USENIX Talk][] ([DOMTRIS][] demo at 20:25), [paper][]), which ran a hacked-up version of jsdom in a worker. My goal was fine-grained containment of untrusted scripts, while still providing access to browser APIs that existing code expected.

Treehouse achieved a small amount of influence in academic circles, but it had problems and was ultimately unsuccessful. Virtual DOMs were not a widespread or well-understood idea at the time, so the advantages of running one in a worker

lawnsea

declare module "worker_threads" {
  export var isMainThread: bool
  export var parentPort: null | MessagePort
  export var threadId: int
  export var threadId: int
  export var workerData: any

  export interface Worker {
    readonly threadId: int
    readonly stdin: stream.Writable | null