mnemonik

I'm also interested in how asm.js could be improved in this regard without moving away from its existing barebones model. Would love to hear ideas.

I think the first thing we will see is shared array buffers between workers because games really need that.

This would likely get even faster if you manually specialized a map/forEach/etc for each caller, but then you might as well just write the loop out by hand: http://rfrn.org/~shu/2013/03/20/two-reasons-functional-style...

In the simple little project where I used mori, I did this:

    const {
      get,
      conj,
      js_to_clj: map,
      clj_to_js: pretty
    } = mori;

See http://fitzgeraldnick.com/weblog/54/ for some implementation details.

https://developer.mozilla.org/en-US/docs/Tools/Scratchpad

Much of the new JS that I write these days starts as a scratchpad that I evolve over many iterations, right in the browser.

See also the Get Involved page for devtools: https://wiki.mozilla.org/DevTools/GetInvolved

I understand if your app is proprietary and you can't share the source, but even non-minimal test cases are much better than no test case :)

Thanks!

https://bugzilla.mozilla.org/show_bug.cgi?id=972054

We have a light and dark theme; you can toggle back and forth via the options panel (the little cog sprocket thing top left)

https://bugzilla.mozilla.org/show_bug.cgi?id=926449

Here's a screencap of the WIP (ignore the text): https://bug970517.bugzilla.mozilla.org/attachment.cgi?id=841...

> JavaScript profiling (heap, cpu, events)

We have CPU profiling now, but we are in the process of reworking the UI to make it more useful and include a better presentation for events and how they fit into that picture.

I'm working on memory tooling. Here is some more info: http://fitzgeraldnick.com/weblog/54/

And here is a design mockup (won't be exactly like this): https://people.mozilla.org/~dhenein/devtools/memtools/#/memo...

> DOM events monitoring and breakpoints.

We have break on dom events already: http://i.imgur.com/RDy7BXy.jpg

What do mean by monitoring? Would be interested in hearing more about what you're talking about and the use cases.

> JavaScript code completion

We have had this in the console for a long time, and it is coming in the scratchpad very soon: https://bugzilla.mozilla.org/show_bug.cgi?id=968896

Can you give steps to reproduce and a test case? Which panel do you have active? What URL are you on?

FWIW, |Object.freeze| does it but unfortunately it disables some optimizations.

> There is a similar issue with tail calls. The compiler could replace calls in tail position with jumps, but it's important that this be part of the language spec. Without a guarantee in the language spec, code that runs fine on one system may blow up with a stack overflow on another.

Tail calls are part of ES6.

Regarding the garbage point brought up by the OP, with regards to point-free programming: generational gc makes it so that short lived objects are super cheap; I suspect it isn't a bottleneck in 99% of use cases and in the remaining cases you can refactor your code appropriately.

Agreed, of course, that if JS were designed to be functional from the ground up it would make coding in the paradigm a lot easier. Pretty much a tautology.

As far as full live editing goes, we have some refactoring and infrastructure work that needs to happen first that also blocks things like properly debugging eval'd strings and dynamically appended scripts. Its pretty high on our priority list and should be coming soonish!

You would be able to continue using the approach you describe for GMail. There is no reason to publicly serve the debugging information unless you want to.

> 2) it increases the download size for consumers who are not developers and don't need the maps

No, the debugging information would still be an auxiliary file like it is now.

3) if written out as a separate file that co-exists with a stripped binary, it increases memory requirements of the debugger.

Debuggers need to keep the source map around now, anyways; this is no different.

Regarding the scope identifiers: it would solve scoping for the most part, but it fails to handle the last three requirements I defined:

- It should provide a way for the JavaScript debugger to display values in a meaningful way.

- It should optionally provide an eval capability, for use from a REPL, watch expression, or conditional breakpoint.

- The format should be future-extensible. That is, when SourceMap.next v2 rolls out, any SourceMap.next v1 consumer should still be able to parse and use instances of SourceMap.next v2 (although without the new features, of course).

Inspecting values would still be a pain, and you wouldn't have watch expressions or conditional breakpoints, etc.

Also, much of the value in what I described in the blog post is the future-extensible format. It allows us to fix our mistakes post facto.

Edit: Here is a more thorough answer: http://support.mozilla.org/en-US/questions/945460#answer-392...

Come drop in IRC and say hi :)

https://wiki.mozilla.org/DevTools/Hacking

https://wiki.mozilla.org/DevTools/GetInvolved