glasser

The incomplete items that this update is about are an extra set of keycaps that I honestly can't even find where on the Kickstarter we were promised them. The main product successfully shipped long ago.

And they all are speaking at the GraphQL Summit today and tomorrow in SF!

Darcs was easy to use? Are you referring to the same darcs whose manual tried to explain concepts by making analogies to the simpler and better-understood theory of quantum mechanics?

Is the "import compatibility rule" (ie, `/v2` suffixes in package paths) implemented in vgo today?

Yup: https://guide.meteor.com/security.html#allow-deny

I just submitted a PR to the main Meteor docs pointing there: https://github.com/meteor/docs/pull/164

Don't worry — you can find that code at https://github.com/chrislgarry/Apollo-11

My goal in writing this post was not to convince people to use or not use MongoDB, but to document an edge case that may affect people who happen to use it for whatever reason, which as far as I could tell was inadequately documented elsewhere.

If I understand correctly, this method says "only scan the built in _id index, not any other index". Which means that you will not hit this index-specific bad behavior, but also that you won't get the performance characteristics of using an index.

This is not related to reading from secondaries. This issue can occur in single node systems.

Oh, wow. This looks like a really easy way to get a "turn on lights slow then play music" alarm... and some dance party blinky lights... and whatever else I bother to program!

Threadable is like Google Groups, except that whether or not the default reply-to is "all" is a user preference rather than a group preference, which made me so happy.

(There are other features too, which I entirely ignore without missing anything. In fact, other than "there are some HTML buttons in the email", which will probably also eventually have an option to turn off, our transition from our prior mailing list service was almost unnoticeable for somebody like me who didn't want to use the extra features. And that's a compliment.)

Exactly. Doing that by mistake (and then being taught to set `push.default` to upstream or simple) has been a rite of passage for engineers at my company.

Yep, as Arunoda says I'm actively working on it right now, currently hoping for an initial release this month.

I really appreciate the work Arunoda has done on smart collections; my implementation and his package have both learned from each other. That said, there are a number of subtle race conditions involved in synchronizing queries between the oplog and the main database, and working out all the little details as carefully as possible has taken time!

I'm not sure what your problem with contributor agreements are; basically every sizable open source project has one. You know, like... Node: http://nodejs.org/cla.html

Our understanding of the current level of browser support is actually in a big comment at the beginning of every file aimed at the browser we generate that has a source map :)

    If you are using Chrome, open the Developer Tools and click the gear
    icon in its lower right corner. In the General Settings panel, turn
    on 'Enable source maps'.
    
    If you are using Firefox 23, go to `about:config` and set the
    `devtools.debugger.source-maps-enabled` preference to true.
    (The preference should be on by default in Firefox 24; versions
    older than 23 do not support source maps.)

That post predates `npm shrinkwrap`.

Cool! A major reason I made this post was because I assumed that this must be something people had seen before, but I had trouble finding any references to it in the JavaScript context. I'll add a link to http://flint.cs.yale.edu/flint/publications/escc.pdf to the blog post!

Yes, but you can statically determine whether or not eval is called.

A world-class JavaScript environment like V8 is far past "the simplest thing that is correct according to the spec".

In fact, the JavaScript spec doesn't actually define anything about garbage collection! You can create a compliant ECMAScript-262 runtime that literally never collects any garbage ever. That's certainly the simplest correct thing. But it's a bad idea!

V8 already goes to the trouble of figuring out whether or not a given variable needs to be stored in the lexical environment or not. Specifically: variables that are not used in ANY closures and where there is no eval in sight can be stored outside of the lexical environment. This is great, and better than many similar programming language environments offer.

It just would be even better if they went one step farther.

Looks like Go optimizes this fully, as pointed out by https://twitter.com/nynexrepublic/status/350717895971586049

If you run these on your own machine and peek at the RSIZE, it stays constant (well, the first grows slowly due to `logIt`).

http://play.golang.org/p/A5Pz-3kthP http://play.golang.org/p/RnXr_jB5Qh

OP here. Several people have pointed out that of course I should expect a leak, since each `logIt` object is leaked. That's absolutely true; my point was just that we don't want `str` to leak.

But the original bug that led to this discovery involved a data structure that shouldn't have leaked at all. I've updated the post to show it; duplicated here since GitHub Pages seems to cache posts pretty aggressively.

    var theThing = null;
    var replaceThing = function () {
      var originalThing = theThing;
      // Define a closure that references originalThing but doesn't ever actually
      // get called. But because this closure exists, originalThing will be in the
      // lexical environment for all closures defined in replaceThing, instead of
      // being optimized out of it. If you remove this function, there is no leak.
      var unused = function () {
        if (originalThing)
          console.log("hi");
      };
      theThing = {
        longStr: new Array(1000000).join('*'),
        // While originalThing is theoretically accessible by this function, it
        // obviously doesn't use it. But because originalThing is part of the
        // lexical environment, someMethod will hold a reference to originalThing,
        // and so even though we are replacing theThing with something that has no
        // effective way to reference the old value of theThing, the old value
        // will never get cleaned up!
        someMethod: function () {}
      };
      // If you add `originalThing = null` here, there is no leak.
    };
    setInterval(replaceThing, 1000);

No, actually, you literally have to call eval as a function called eval if you want to get the local lexicals. See sections 10.4.2 and 15.1.2.1.1 of the ECMAScript standard, or try it out:

   > (function () { var x = 5; eval("console.log(x)"); })()
   5
   > (function () { var x = 5; var e = eval; e("console.log(x)"); })()
   ReferenceError: x is not defined

Right, but according to sections 10.4.2 and 15.1.2.1.1 of the ECMAScript standard, you only get lexical bindings inside your `eval` if it's literally a call to a thing called `eval`. (Which I believe is what you meant by "direct `eval`".)

So you should be able to statically determine if this is the case, and it's not here.

I don't know how to look at memory usage in other modern JS interpreters like those used in FireFox and Safari. Anyone able to check to see if they have this problem? (And if they manage to avoid the memory leaks in the first two code samples?)

To be clear: when you say "removing the call to doSomethingWithStr() doesn't change the unbounded memory growth" you do literally mean "removing the call" and not "removing the function definition", right? That matches what I see.

BTW, the original bug in the Meteor codebase wasn't a setInterval.

It was that code to replace a certain type of object (a Spark renderer) with a new instance of that object accidentally ended up with a reference to the preceding renderer in a closure assigned somewhere on it, even though that particular closure didn't actually use that reference.

So instead of replacing renderer #N with renderer #(N+1) and GCing #N, we ended up with a stream of renderers which never could be GCed... even though the reference keeping the old ones alive was literally impossible to ever use.

The surprise isn't that the memory associated with `logIt` is leaked.

The surprise is that `logIt` holds on to the giant `str` object in its environment, despite the fact that there is literally no way for the `str` variable to ever be used again.

V8 is smart enough to not make `logIt` hold on to `str` if there are no closures at all which refer to `str`. It's the introduction of the unrelated `doSomethingWithStr` closure that forces `str` into the lexical environment.

We took inspiration from the great work Tom and Mike did on Meteorite; several of 0.6.0's features are essentially versions of what Meteorite let you do, except for much more deeply integrated into the core. For now, Meteorite is still a great tool for installing packages from Atmosphere into your app... a fully integrated third-party package repository is in the works but isn't part of 0.6.0.

This is under active development on the linker branch: https://github.com/meteor/meteor/tree/linker ! The goal, hopefully coming in one of the next few releases, is to provide package-scoped variables and explicit exports from packages, so that you don't need to rely on globals at all any more.

I saw some of these installed at Burning Man last year. They looked great! If I had time to play with blinky lights this would totally be my first choice.

At the office, I do a physical variant of this: when I'm at my desk, I'm in work mode. If I want to spend time doing personal things at the office, I'll go to another area (eg a couch). If nothing else, it's easy for me to notice when I've been there for a while. And it keeps me efficient in either mode.