Comments for Rooftop lab

Comment on Wanted: An extension for profiling Firefox by vineel

vineel — Sat, 28 Jan 2012 06:07:26 +0000

Sir,
I ‘m currently a software engineer at Siemens R & D Pune. I understand Java and C++ . I ‘m interested in contributing to this.

Regards,
Venkata Vineel

Comment on Mozilla summer internships by Akansha Singh

Akansha Singh — Tue, 17 Jan 2012 20:17:49 +0000

i am a Btech student from DAIICT Gujarat and is willing to apply for summer internship in year 2012..
please respond as soon as possible

Comment on Mozilla summer internships by Harshit Shrivastava

Harshit Shrivastava — Mon, 26 Dec 2011 18:35:13 +0000

Hi
Does Mozilla also offer a 6 week summer intership? Also i would like to know if Mozilla offers internship at some place in India, apart from the US?
Thanks

Comment on Anatomy of a JavaScript object by peter

peter — Tue, 04 Oct 2011 21:33:49 +0000

if the shape of an object would be named it could act as the type of the object. it is interesting that objects are classified by their shape. the shape defines its (unnamed) type. inheritance relation is given if the shape of an object is included in the shape of another.

Comment on Harmony modules and asynchronous script loading and document.write (oh my) by jorendorff

jorendorff — Wed, 21 Sep 2011 22:57:34 +0000

Blake: Yeah, I didn’t make that clear at all. Sorry. “JavaScript caller waiting” is meant as a rule of thumb. I don’t think we should actually specify examining the stack to see if there’s a JS stack frame. If we went that way, then for consistency, the relevant notion would actually have to be formally specified—currently it is not. (Note that proper tail calls, for example, or self-hosting some APIs, could affect whether there is anything “waiting”.) It sounds hard, and it would make it very difficult for developers to figure out from the spec what to expect. Instead, for each case (that is, for each place in the HTML spec and the ES-Harmony spec where a script is compiled), we should specify whether or not a blocking script load is permitted. So blocking script loads will be allowed or not based on the immediate context of the script, not the whole stack. The ES-Harmony grammar will note that from "url" is banned in contexts where script loads aren’t allowed. We can use the “JavaScript caller waiting” rule of thumb to figure out what to specify for each case. For example, clearly eval typically has a caller waiting, so we’ll ban blocking script loads there (even if eval happens to have been tail-called from setTimeout code, so that nobody is really waiting for the answer at all!) and allow them in evalAsync. That’s my intuition. I could be wrong. The relevant parts of the HTML spec are still new to me.

Comment on Harmony modules and asynchronous script loading and document.write (oh my) by jorendorff

jorendorff — Wed, 21 Sep 2011 22:46:55 +0000

pd: Harmony is a code name for the next major edition of the ECMAScript standard. It’s being put together now. You can see what has been proposed here: wiki.ecmascript.org/doku.php?id=harmony:proposals

As that page says: “Lacking a formal language specification, the following list is not definitive, but it should reflect consensus achieved so far in TC39.”

Comment on Harmony modules and asynchronous script loading and document.write (oh my) by Blake Kaplan

Blake Kaplan — Tue, 20 Sep 2011 21:39:00 +0000

Why wouldn’t the nested script case fall into the “JavaScript caller waiting” category of blocked module loads?

Comment on Harmony modules and asynchronous script loading and document.write (oh my) by pd

pd — Tue, 20 Sep 2011 14:18:53 +0000

This might be an interesting article … if you remembered to link to somewhere that would tell the reader WTF Harmony is!

Comment on Harmony modules and asynchronous script loading and document.write (oh my) by jorendorff

jorendorff — Tue, 20 Sep 2011 05:28:23 +0000

Thanks, bz. That makes sense.

Function(“module x from ‘x.js’”) will throw a SyntaxError.

Comment on Harmony modules and asynchronous script loading and document.write (oh my) by Boris

Boris — Tue, 20 Sep 2011 03:20:53 +0000

> silently make that script load asynchronously, just because
> document.write() created it.

More precisely, continue execution of the script that executed the document.write call, then once it’s done block the parser waiting for blottr.js to load before running the script that’s using the module.

> What happens if you try to load a module by assigning a string to an event
> handler attribute

Exactly the same thing that happens when you do new Function(“module ….”). Event handler attribute values are just function bodies compiled with a particular list of formal parameters and in a particular scope. What _does_ happen in this case with new Function?

Note that compile errors in event handler attributes are ignored, by the way (apart from being reported to an error console or whatnot); if they have a SyntaxError you just get no handler.