https://wiki.mozilla.org/api.php?action=feedcontributions&user=Dherman&feedformat=atomMozillaWiki - User contributions [en]2024-03-29T10:13:38ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=WeeklyUpdates/2012-11-19&diff=488576WeeklyUpdates/2012-11-192012-11-19T18:39:21Z<p>Dherman: /* Introducing New Hires */</p>
<hr />
<div><small>[[WeeklyUpdates/{{#time:Y-m-d|{{SUBPAGENAME}} -1 week}}|« previous week]] | [[WeeklyUpdates|index]] | [[WeeklyUpdates/{{#time:Y-m-d|{{SUBPAGENAME}} +1 week}}|next week »]]</small><br />
<br />
{{conf|8600}}<br />
<br />
__TOC__<br />
<br />
= All-hands Status Meeting Agenda =<br />
<br />
Items in this section will be shared during the live all-hand status meeting.<br />
<br />
== Friends of the Tree [[Image:Tree.gif|Friends of the Tree]] ==<br />
<br />
== Upcoming Events ==<br />
<br />
=== This Week ===<br />
<br />
=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===<br />
<br />
=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===<br />
<br />
=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===<br />
<br />
=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===<br />
<br />
=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===<br />
<br />
=== Next Week ===<br />
<br />
== Product Status Updates (voice updates) ==<br />
<br />
=== Firefox Desktop ===<br />
''Speaker Location:''<br />
<br />
=== Firefox Mobile ===<br />
''Speaker Location:'' <br />
<br />
=== Thunderbird ===<br />
''Speaker Location:'' <br />
<br />
=== Older Branch Work ===<br />
''Speaker Location:'' <br />
<br />
=== Webmaker ===<br />
''Speaker Location:''<br />
<br />
=== Identity ===<br />
''Speaker Location:''<br />
<br />
=== Services ===<br />
''Speaker Location:''<br />
<br />
=== Firefox OS ===<br />
''Speaker Location:''<br />
<br />
=== Grow Mozilla ===<br />
''Speaker Location:''<br />
<br />
== Speakers ==<br />
<br />
The limit is 3 minutes per speaker. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation.<br />
<br />
{| class="fullwidth-table"<br />
|-<br />
! Title<br />
! Presenter<br />
! Topic<br />
! Media<br />
! More Details<br />
|-<br />
| Community Manager for Firefox Engineering<br />
| Benjamin Smedberg<br />
| Inviting members of the community to apply or recommend people for this new position.<br />
| No onscreen info<br />
| [http://careers.mozilla.org/en-US/position/oByUWfwJ Online Job Posting]<br />
|-<br />
|}<br />
<br />
== Introducing New Hires ==<br />
{| class="fullwidth-table"<br />
|-<br />
| Who is the new hire?<br />
| Who will be introducing that person?<br />
| From which office will that introduction be transmitted?<br />
| What will the new person be working on?<br />
|-<br />
| ''Who is the new hire?''<br />
| ''Who will be introducing that person?''<br />
| ''From which office will that introduction be transmitted?''<br />
| ''What will the new person be working on?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
| ''Milan Sreckovic''<br />
| ''Jet Villegas''<br />
| ''Toronto''<br />
| ''Platform Graphics Engineering Manager''<br />
|-<br />
| ''Stephen Pohl''<br />
| ''Robert Strong''<br />
| ''Mountain View''<br />
| ''Platform Integration Team working on Mac OS X and Windows integration points, Application Update, and the Firefox Installer''<br />
|-<br />
| ''Felix Klock''<br />
| ''Dave Herman''<br />
| ''San Francisco''<br />
| ''Research Engineer, working on River Trail (JavaScript parallelism), Rust and Servo, and maybe more!''<br />
|-<br />
|-<br />
|}<br />
<br />
== Introducing New Interns ==<br />
{| class="fullwidth-table"<br />
|-<br />
! New Intern<br />
! Introduced by<br />
! Speaker location<br />
! Will be working on<br />
|-<br />
| ''Who is the new intern?''<br />
| ''Who will be introducing that person?''<br />
| ''From which office will that introduction be transmitted?''<br />
| ''What will the new person be working on?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
|}<br />
<br />
== Roundtable ==<br />
<br />
= &lt;meta&gt; =<br />
<br />
Notes and non-voice status updates that aren't part of the live meeting go here.<br />
<br />
== Status Updates By Team (*non-voice* updates) ==<br />
<br />
=== Firefox ===<br />
<br />
=== Platform ===<br />
<br />
=== Services ===<br />
<br />
=== Messaging ===<br />
<br />
=== Mobile ===<br />
<br />
=== IT ===<br />
<br />
=== Release Engineering ===<br />
<br />
=== QA ===<br />
<br />
==== Test Execution ====<br />
<br />
==== WebQA ====<br />
*AMO<br />
**Firefox 17 compatibility changes are landing this week.<br />
*Firefox Health Report (FHR) - https://blog.mozilla.org/metrics/fhr-faq/<br />
**the work and timeline is currently being scoped<br />
**https://intranet.mozilla.org/Program_Management/FirefoxHealthReport<br />
*B2G/Gaia testing:<br />
**we'll be able to check out the touch-event support in Marionette, tomorrow:<br />
**https://bugzilla.mozilla.org/show_bug.cgi?id=809245<br />
**this unblocks us from finishing Marketplace + almost all of the smoketests (sans ~2)<br />
**A-team is busy working through our list of outright blockers or testability bugs:<br />
***https://bugzilla.mozilla.org/show_bug.cgi?id=811053<br />
***https://bugzilla.mozilla.org/show_bug.cgi?id=810376 (landed)<br />
***https://bugzilla.mozilla.org/show_bug.cgi?id=811351 (landed, needs to land in aurora)<br />
*Bouncer <br />
**Sentry improvements verified and in the pipeline for the next release - https://bugzilla.mozilla.org/show_bug.cgi?id=804347#c13<br />
*Engagement Projects <br />
**Firefox Flicks is in early project-kickoff state<br />
*Firefox Marketplace <br />
**App signing is being set up. See https://bugzilla.mozilla.org/show_bug.cgi?id=797902 for more details<br />
**We push as always on Thursdays. This week's changes are available at http://cl.ly/3K29001a3E2X<br />
*Mozilla.com <br />
**http://scrumbu.gs/p/mozilla_org/<br />
*Mozillians <br />
** shipped the API today!<br />
**Funkload performance benchmarking complete -https://bugzilla.mozilla.org/show_bug.cgi?id=795388#c7<br />
*MDN <br />
**http://scrumbu.gs/t/mdn/2012-11-20/<br />
*PFS<br />
**just got asked to help move PFS off of AMO:<br />
***https://bugzilla.mozilla.org/show_bug.cgi?id=811841<br />
*Socorro <br />
*Milestone 26 slated for release tomorrow<br />
**https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced;target_milestone=26;product=Socorro;list_id=4964812<br />
*team completed a postmortem for last week's release which needed to be rolled back due to https://bugzilla.mozilla.org/show_bug.cgi?id=792118 causing a regression<br />
*Community Members Onboarding<br />
**Firechemist/Jonah Ho has done some great MozTrap testing<br />
**chrisculver701 joined IRC today and has looked at a few Marketplace tests<br />
<br />
==== QA Community ====<br />
<br />
=== Automation & Tools ===<br />
<br />
=== Security ===<br />
<br />
=== Engagement ===<br />
<br />
==== PR ====<br />
<br />
==== Events ====<br />
<br />
==== Creative Team ====<br />
<br />
==== Community Marketing ====<br />
<br />
=== Support ===<br />
<br />
=== Metrics ===<br />
<br />
=== Evangelism ===<br />
<br />
=== Labs ===<br />
<br />
=== Apps ===<br />
<br />
=== Developer Tools ===<br />
<br />
=== Add-ons ===<br />
<br />
=== Webdev ===<br />
<br />
=== L10n ===<br />
<br />
=== People Team ===<br />
<br />
=== WebFWD ===<br />
<br />
== Foundation Updates ==</div>Dhermanhttps://wiki.mozilla.org/index.php?title=WeeklyUpdates/2012-11-19&diff=488571WeeklyUpdates/2012-11-192012-11-19T18:31:55Z<p>Dherman: /* Introducing New Hires */</p>
<hr />
<div><small>[[WeeklyUpdates/{{#time:Y-m-d|{{SUBPAGENAME}} -1 week}}|« previous week]] | [[WeeklyUpdates|index]] | [[WeeklyUpdates/{{#time:Y-m-d|{{SUBPAGENAME}} +1 week}}|next week »]]</small><br />
<br />
{{conf|8600}}<br />
<br />
__TOC__<br />
<br />
= All-hands Status Meeting Agenda =<br />
<br />
Items in this section will be shared during the live all-hand status meeting.<br />
<br />
== Friends of the Tree [[Image:Tree.gif|Friends of the Tree]] ==<br />
<br />
== Upcoming Events ==<br />
<br />
=== This Week ===<br />
<br />
=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===<br />
<br />
=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===<br />
<br />
=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===<br />
<br />
=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===<br />
<br />
=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===<br />
<br />
=== Next Week ===<br />
<br />
== Product Status Updates (voice updates) ==<br />
<br />
=== Firefox Desktop ===<br />
''Speaker Location:''<br />
<br />
=== Firefox Mobile ===<br />
''Speaker Location:'' <br />
<br />
=== Thunderbird ===<br />
''Speaker Location:'' <br />
<br />
=== Older Branch Work ===<br />
''Speaker Location:'' <br />
<br />
=== Webmaker ===<br />
''Speaker Location:''<br />
<br />
=== Identity ===<br />
''Speaker Location:''<br />
<br />
=== Services ===<br />
''Speaker Location:''<br />
<br />
=== Firefox OS ===<br />
''Speaker Location:''<br />
<br />
=== Grow Mozilla ===<br />
''Speaker Location:''<br />
<br />
== Speakers ==<br />
<br />
The limit is 3 minutes per speaker. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation.<br />
<br />
{| class="fullwidth-table"<br />
|-<br />
! Title<br />
! Presenter<br />
! Topic<br />
! Media<br />
! More Details<br />
|-<br />
| Community Manager for Firefox Engineering<br />
| Benjamin Smedberg<br />
| Inviting members of the community to apply or recommend people for this new position.<br />
| No onscreen info<br />
| [http://careers.mozilla.org/en-US/position/oByUWfwJ Online Job Posting]<br />
|-<br />
|}<br />
<br />
== Introducing New Hires ==<br />
{| class="fullwidth-table"<br />
|-<br />
| Who is the new hire?<br />
| Who will be introducing that person?<br />
| From which office will that introduction be transmitted?<br />
| What will the new person be working on?<br />
|-<br />
| ''Who is the new hire?''<br />
| ''Who will be introducing that person?''<br />
| ''From which office will that introduction be transmitted?''<br />
| ''What will the new person be working on?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
| ''Milan Sreckovic''<br />
| ''Jet Villegas''<br />
| ''Toronto''<br />
| ''Platform Graphics Engineering Manager''<br />
|-<br />
| ''Stephen Pohl''<br />
| ''Robert Strong''<br />
| ''Mountain View''<br />
| ''Platform Integration Team working on Mac OS X and Windows integration points, Application Update, and the Firefox Installer''<br />
|-<br />
| ''Felix Klock''<br />
| ''Dave Herman''<br />
| ''San Francisco''<br />
| ''Research Engineer''<br />
|-<br />
|-<br />
|}<br />
<br />
== Introducing New Interns ==<br />
{| class="fullwidth-table"<br />
|-<br />
! New Intern<br />
! Introduced by<br />
! Speaker location<br />
! Will be working on<br />
|-<br />
| ''Who is the new intern?''<br />
| ''Who will be introducing that person?''<br />
| ''From which office will that introduction be transmitted?''<br />
| ''What will the new person be working on?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
|}<br />
<br />
== Roundtable ==<br />
<br />
= &lt;meta&gt; =<br />
<br />
Notes and non-voice status updates that aren't part of the live meeting go here.<br />
<br />
== Status Updates By Team (*non-voice* updates) ==<br />
<br />
=== Firefox ===<br />
<br />
=== Platform ===<br />
<br />
=== Services ===<br />
<br />
=== Messaging ===<br />
<br />
=== Mobile ===<br />
<br />
=== IT ===<br />
<br />
=== Release Engineering ===<br />
<br />
=== QA ===<br />
<br />
==== Test Execution ====<br />
<br />
==== WebQA ====<br />
<br />
==== QA Community ====<br />
<br />
=== Automation & Tools ===<br />
<br />
=== Security ===<br />
<br />
=== Engagement ===<br />
<br />
==== PR ====<br />
<br />
==== Events ====<br />
<br />
==== Creative Team ====<br />
<br />
==== Community Marketing ====<br />
<br />
=== Support ===<br />
<br />
=== Metrics ===<br />
<br />
=== Evangelism ===<br />
<br />
=== Labs ===<br />
<br />
=== Apps ===<br />
<br />
=== Developer Tools ===<br />
<br />
=== Add-ons ===<br />
<br />
=== Webdev ===<br />
<br />
=== L10n ===<br />
<br />
=== People Team ===<br />
<br />
=== WebFWD ===<br />
<br />
== Foundation Updates ==</div>Dhermanhttps://wiki.mozilla.org/index.php?title=WeeklyUpdates/2012-11-19&diff=488570WeeklyUpdates/2012-11-192012-11-19T18:31:17Z<p>Dherman: added Felix Klock to new hires</p>
<hr />
<div><small>[[WeeklyUpdates/{{#time:Y-m-d|{{SUBPAGENAME}} -1 week}}|« previous week]] | [[WeeklyUpdates|index]] | [[WeeklyUpdates/{{#time:Y-m-d|{{SUBPAGENAME}} +1 week}}|next week »]]</small><br />
<br />
{{conf|8600}}<br />
<br />
__TOC__<br />
<br />
= All-hands Status Meeting Agenda =<br />
<br />
Items in this section will be shared during the live all-hand status meeting.<br />
<br />
== Friends of the Tree [[Image:Tree.gif|Friends of the Tree]] ==<br />
<br />
== Upcoming Events ==<br />
<br />
=== This Week ===<br />
<br />
=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===<br />
<br />
=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===<br />
<br />
=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===<br />
<br />
=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===<br />
<br />
=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===<br />
<br />
=== Next Week ===<br />
<br />
== Product Status Updates (voice updates) ==<br />
<br />
=== Firefox Desktop ===<br />
''Speaker Location:''<br />
<br />
=== Firefox Mobile ===<br />
''Speaker Location:'' <br />
<br />
=== Thunderbird ===<br />
''Speaker Location:'' <br />
<br />
=== Older Branch Work ===<br />
''Speaker Location:'' <br />
<br />
=== Webmaker ===<br />
''Speaker Location:''<br />
<br />
=== Identity ===<br />
''Speaker Location:''<br />
<br />
=== Services ===<br />
''Speaker Location:''<br />
<br />
=== Firefox OS ===<br />
''Speaker Location:''<br />
<br />
=== Grow Mozilla ===<br />
''Speaker Location:''<br />
<br />
== Speakers ==<br />
<br />
The limit is 3 minutes per speaker. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation.<br />
<br />
{| class="fullwidth-table"<br />
|-<br />
! Title<br />
! Presenter<br />
! Topic<br />
! Media<br />
! More Details<br />
|-<br />
| Community Manager for Firefox Engineering<br />
| Benjamin Smedberg<br />
| Inviting members of the community to apply or recommend people for this new position.<br />
| No onscreen info<br />
| [http://careers.mozilla.org/en-US/position/oByUWfwJ Online Job Posting]<br />
|-<br />
|}<br />
<br />
== Introducing New Hires ==<br />
{| class="fullwidth-table"<br />
|-<br />
| Who is the new hire?<br />
| Who will be introducing that person?<br />
| From which office will that introduction be transmitted?<br />
| What will the new person be working on?<br />
|-<br />
| ''Who is the new hire?''<br />
| ''Who will be introducing that person?''<br />
| ''From which office will that introduction be transmitted?''<br />
| ''What will the new person be working on?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
| ''Milan Sreckovic''<br />
| ''Jet Villegas''<br />
| ''Toronto''<br />
| ''Platform Graphics Engineering Manager''<br />
|-<br />
| ''Stephen Pohl''<br />
| ''Robert Strong''<br />
| ''Mountain View''<br />
| ''Platform Integration Team working on Mac OS X and Windows integration points, Application Update, and the Firefox Installer''<br />
|-<br />
| ''Felix Klock''<br />
| ''Dave Herman''<br />
| ''Paris''<br />
| ''Research Engineer''<br />
|-<br />
|-<br />
|}<br />
<br />
== Introducing New Interns ==<br />
{| class="fullwidth-table"<br />
|-<br />
! New Intern<br />
! Introduced by<br />
! Speaker location<br />
! Will be working on<br />
|-<br />
| ''Who is the new intern?''<br />
| ''Who will be introducing that person?''<br />
| ''From which office will that introduction be transmitted?''<br />
| ''What will the new person be working on?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
|}<br />
<br />
== Roundtable ==<br />
<br />
= &lt;meta&gt; =<br />
<br />
Notes and non-voice status updates that aren't part of the live meeting go here.<br />
<br />
== Status Updates By Team (*non-voice* updates) ==<br />
<br />
=== Firefox ===<br />
<br />
=== Platform ===<br />
<br />
=== Services ===<br />
<br />
=== Messaging ===<br />
<br />
=== Mobile ===<br />
<br />
=== IT ===<br />
<br />
=== Release Engineering ===<br />
<br />
=== QA ===<br />
<br />
==== Test Execution ====<br />
<br />
==== WebQA ====<br />
<br />
==== QA Community ====<br />
<br />
=== Automation & Tools ===<br />
<br />
=== Security ===<br />
<br />
=== Engagement ===<br />
<br />
==== PR ====<br />
<br />
==== Events ====<br />
<br />
==== Creative Team ====<br />
<br />
==== Community Marketing ====<br />
<br />
=== Support ===<br />
<br />
=== Metrics ===<br />
<br />
=== Evangelism ===<br />
<br />
=== Labs ===<br />
<br />
=== Apps ===<br />
<br />
=== Developer Tools ===<br />
<br />
=== Add-ons ===<br />
<br />
=== Webdev ===<br />
<br />
=== L10n ===<br />
<br />
=== People Team ===<br />
<br />
=== WebFWD ===<br />
<br />
== Foundation Updates ==</div>Dhermanhttps://wiki.mozilla.org/index.php?title=B2G&diff=333300B2G2011-07-26T02:17:58Z<p>Dherman: fix broken html</p>
<hr />
<div>This page is edited by brendan, cjones, gal, shaver. Please don't change without permission.<br />
<br />
<h2>Booting to the web</h2><br />
<br />
Mozilla believes that the web can displace proprietary, single-vendor stacks for application development. To make open web technologies a better basis for future applications on mobile and desktop alike, we need to keep pushing the envelope of the web to include --- and in places exceed --- the capabilities of the competing stacks in question.<br />
<br />
We also need a hill to take, in order to scope and focus our efforts. Recently we saw the [http://github.com/andreasgal/pdf.js/ pdf.js] project expose small gaps that needed filling in order for "HTML5" to be a superset of PDF. We want to take a bigger step now, and find the gaps that keep web developers from being able to build apps that are --- in every way --- the equals of native apps built for the iPhone, Android, and WP7.<br />
<br />
To that end, we propose a project we’re calling [http://wiki.mozilla.org/B2G Boot to Gecko] (B2G) to pursue the goal of building a complete, standalone operating system for the open web. It’s going to require work in a number of areas.<br />
<br />
* '''New web APIs''': build prototype APIs for exposing device and OS capabilities to content (Telephony, SMS, Camera, USB, Bluetooth, NFC, etc.)<br />
* '''Privilege model''': making sure that these new capabilities are safely exposed to pages and applications<br />
* '''Booting''': prototype a low-level substrate for an Android-compatible device<br />
* '''Applications''': choose and port or build apps to prove out and prioritize the power of the system.<br />
<br />
We will do this work in the open, we will release the [http://github.com/andreasgal/B2G source] in real-time, we will take all successful additions to an appropriate standards group, and we will track changes that come out of that process. We aren't trying to have these native-grade apps just run on Firefox, we're trying to have them run on the web.<br />
<br />
This project is in its infancy; some pieces of it are only captured in our heads today, others aren’t fully explored. We’re talking about it now because we want expertise from all over Mozilla -- and from people who aren’t yet part of Mozilla -- to inform and build the project we’re outlining here. Please see, and join, [http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/7668a9d46a43e482# the thread in mozilla.dev.platform].</div>Dhermanhttps://wiki.mozilla.org/index.php?title=WeeklyUpdates/2011-03-14&diff=290760WeeklyUpdates/2011-03-142011-03-14T15:59:32Z<p>Dherman: research interns starting this week</p>
<hr />
<div><small>[[WeeklyUpdates/2011-03-07|« previous week]] | [[WeeklyUpdates|index]] | [[WeeklyUpdates/2011-03-21|next week »]]</small><br />
<br />
= Video for today's meeting =<br />
<br />
<video controls="controls"><source src="http://videos.mozilla.org/serv/air_mozilla/monday_meetings/status-2011-03-14.ogg" type="video/ogg; codecs=&quot;theora, vorbis&quot;" /></video> <br />
<br />
= Friends of the Tree [[Image:Tree.gif|Friends of the Tree]] =<br />
<br />
= Upcoming Events =<br />
'''This Week'''<br />
<br />
'''Monday, 14 March'''<br />
<br />
'''Tuesday, 15 March'''<br />
<br />
'''Wednesday, 16 March'''<br />
<br />
'''Thursday, 17 March'''<br />
<br />
'''Friday, 18 March''' <br />
<br />
'''Next Week'''<br />
<br />
= Product Status Updates =<br />
<br />
== Firefox 4 ==<br />
<br />
== Firefox 3.6 ==<br />
<br />
== Mobile Firefox ==<br />
<br />
== Thunderbird ==<br />
<br />
== Older Branch Work ==<br />
<br />
== Drumbeat ==<br />
<br />
= Speakers =<br />
<br />
The limit is 3 minutes per speaker. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation.<br />
<br />
{| class="fullwidth-table"<br />
|-<br />
! Title<br />
! Presenter<br />
! Topic<br />
! Media<br />
! More Details<br />
|-<br />
| Your Title Here<br />
| Your Name Here<br />
| What are you going to talk about?<br />
| Links to slides or images you want displayed on screen<br />
| Link to where audience can find out more information<br />
|-<br />
|}<br />
<br />
= Status Updates By Team =<br />
<br />
== Firefox ==<br />
<br />
== Platform ==<br />
<br />
== Messaging ==<br />
<br />
== Mobile ==<br />
<br />
== IT ==<br />
<br />
== Release Engineering ==<br />
<br />
== QA ==<br />
<br />
;Test Execution<br />
<br />
;Test Automation<br />
* The structure of the [http://www.hskupin.info/2011/03/11/new-structure-of-the-mozmill-tests-repository/ mozmill-tests repository has been changed] to allow future work<br />
* [http://blargon7.com/2011/03/endurance-results-from-test-day/ Detailed Endurance results] from add-ons testday<br />
<br />
;WebQA<br />
<br />
;QA Community<br />
<br />
;Test Dev<br />
<br />
== Automation & Tools ==<br />
<br />
== Security ==<br />
<br />
== Engagement ==<br />
<br />
'''PR''' <br />
<br />
'''Events''' <br />
<br />
'''Creative Team''' <br />
<br />
'''Community Marketing'''<br />
<br />
'''Developer Engagement'''<br />
* Demo Studio is live: http://developer.mozilla.org/demos<br />
** Please help spread the word and invite developers to contribute awesome Web demos!<br />
<br />
== Support ==<br />
<br />
== Metrics ==<br />
<br />
== Evangelism ==<br />
<br />
== Labs ==<br />
<br />
== Developer Tools ==<br />
<br />
== Add-ons ==<br />
<br />
== Webdev ==<br />
<br />
== L10n ==<br />
<br />
= Introducing New Hires =<br />
<br />
Research intern: '''Tim Chevalier'''<br />
<br />
Mentor: Dave Herman<br />
<br />
Research intern: '''Lindsey Kuper'''<br />
<br />
Mentor: Dave Herman<br />
<br />
= Foundation Updates =<br />
<br />
= Roundtable =</div>Dhermanhttps://wiki.mozilla.org/index.php?title=User:Jgoulie&diff=277789User:Jgoulie2011-01-14T20:31:17Z<p>Dherman: added back lecture notes that got deleted</p>
<hr />
<div>=<b>MIT IAP, January 10-14, 2011</b>=<br />
<br />
==Overview==<br />
* Name of the class: IAP HTML5 Game Programming Course and Competition<br />
* Coursework Component: 5 sessions, 2 hours each (total instruction time 10 hours)<br />
*Schedule, everyday 11.30-1.30pm EST<br />
*Room is 32-141 (32 Vassar St, room #141 (first floor) (http://whereis.mit.edu/)<br />
*Onsite support:<br />
**mitcho (Michael Erlewine), mitcho@mit.edu<br />
**office: 32-D866, Mondays during IAP or by appointment<br />
*External support on [http://irc.mozilla.org/ IRC] #mitiap2011<br />
*Here's a list of some [http://en.wikipedia.org/wiki/IRC#Client_software IRC clients] depending on your OS.<br><br />
*<b>Emergency line for the Stata Center</b>: 617-253-7669 || Please call on Wednesday to make sure the center is open!<br />
<br />
==Layout of the week==<br />
===January 10, 2011===<br />
*Lecturer: Dave Herman<br />
*<b>Lecture notes</b>: http://www.ccs.neu.edu/home/dherman/mit-iap-2011/<br />
*Contact info:<br />
**Email: dherman@mozilla.com<br />
**IRC: dherman -- available on irc.mozilla.org at #jslang and #jsapi <br />
**Twitter: @littlecalculist<br />
*Topics covered: Foundations of JavaScript programming in the browser. Language syntax and concepts. Browser environment, events. (object and prototype, scope and global object, closures, events and call backs, numbers, XHR)<br />
*Resources:<br />
**https://developer.mozilla.org/en/JavaScript/Guide<br />
**https://developer.mozilla.org/En/XMLHttpRequest/Using_XMLHttpRequest //documentation on XHR, which Dave will be talking a bit during his lecture (Students may or may not need it for their games, but it's a good way to learn about using callbacks for event handling without having to learn all the complications of DOM events.)<br />
**http://www.squarefree.com/shell/shell.html //Students can use it to test out JS commands in any browser. But the more recommended way would be to use the built-in developer tools of their browser (FF4 console or Firebug, Chrome console, Safari console).<br />
<br />
===January 11, 2011===<br />
*Lecturer: Boris Zbarsky<br />
*Contact info<br />
**Email: bzbarsky@mit.edu<br />
**IRC: bz -- available on irc.mozilla.org at #developers<br />
*Topics covered: The Document Object Model (DOM), the canvas element, resource loading (graphics)<br><br />
*Resources:<br />
**Presentation: http://web.mit.edu/bzbarsky/www/IAP-2011-DOM-talk/intro.html<br />
**HTML5 (draft): http://www.whatwg.org/specs/web-apps/current-work/multipage/<br />
**XMLHttpRequest (close to final): http://www.w3.org/TR/XMLHttpRequest/<br />
**XMLHttpRequest extensions (draft): http://dev.w3.org/2006/webapi/XMLHttpRequest-2/<br />
**CORS (for cross-site XMLHttpRequest, draft): http://www.w3.org/TR/cors/<br />
**CSS 2.1 (close to final): http://www.w3.org/TR/CSS21/<br />
**Canvas (mix of close to final and draft): http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html<br />
**DOM Core: http://www.w3.org/TR/DOM-Level-3-Core/core.html<br />
**DOM Events: http://www.w3.org/TR/DOM-Level-2-Events/events.html<br />
<br />
===January 12, 2011===<br />
*Lecturers: Benoit Jacob and Andor Salga<br />
*Contact info (Benoit)<br />
**Email: bjacob@mozilla.com<br />
**IRC: bjacob -- available on irc.mozilla.org at #developers #gfx #audio<br />
*Contact info (Andor)<br />
**Email: andor.salga@senecac.on.ca<br />
**IRC: nick:asalga -- available on irc.mozilla.org on #Seneca #Processing.js and #C3DL Also avaiable on irc.freenode.net on #WebGL<br />
**Twitter: @asalga<br />
**Wordpress: http://asalga.wordpress.com<br />
*Topics covered: Introduction to 3D graphics with OpenGL/WebGL. Basics of shader programming<br />
*Useful links<br />
**WebGL specification: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html<br />
**WebGL tutorials: http://www.learningWebGL.com<br />
**http://www.doesmybrowsersupportwebgl.com/<br />
**http://learningwebgl.com/lessons/<br />
*Further links<br />
**WebGL point cloud renderer: http://zenit.senecac.on.ca/wiki/index.php/XB_PointStream<br />
**Data visualizer library which uses WebGL: www.processingjs.org<br />
**WebGL library: www.c3dl.org<br />
<br />
===January 13, 2011===<br />
*Lecturer: Chris Heilmann<br />
*Topics covered: Multimedia on the web - audio and video<br />
<br />
===January 14, 2011===<br />
*Lecturer: Pascal Rettig from [http://cykod.com/ Cykod]<br />
*Topics covered: Offline web applications, local storage, debugging and optimizing JS performance. Also to be discussed: server side Javascript (node.js) and Web sockets.<br />
*Resources:<br />
**Offline storage - http://diveintohtml5.org/offline.html<br />
**Local storage - http://diveintohtml5.org/storage.html<br />
**JS Debugging /w Firebug - http://getfirebug.com/javascript<br />
**Node.js - http://nodejs.org/<br />
**Node Package Manager - http://npmjs.org/<br />
**Node Realtime Sockets Module - http://socket.io/<br />
<br />
<br />
==Competition==<br />
*After the course work component, students will compete in a HTML5 game programming competition. The competition will run for 4 weeks. Mozilla will host a discussion forum for students to communicate and collaborate and ask and answer questions amongst each other. The goal is for students to implement an interesting HTML5 game or visual demonstration. Whether its a create re-implementation of existing games (HTML5 pong?), or a full fledge 3D game, anything goes. <br />
*Prize: The winning team (up to 4 team members max) will come to Mountain View, spend a w/e in SF. During their time at Mozila, the team will present its demo/game and spend some time with Brendan Eich.</div>Dhermanhttps://wiki.mozilla.org/index.php?title=User:Jgoulie&diff=276826User:Jgoulie2011-01-11T04:32:38Z<p>Dherman: added lecture notes</p>
<hr />
<div>== MIT IAP, January 10-14, 2011 ==<br />
<br />
<br />
* Name of the class: IAP HTML5 Game Programming Course and Competition<br />
* Coursework Component: 5 sessions, 2 hours each (total instruction time 10 hours)<br />
*Schedule: everyday 11.30-1.30pm EST in room 32-141 ((http://whereis.mit.edu/)<br />
*Onsite support:<br />
**mitcho (Michael Erlewine), mitcho@mit.edu<br />
**office: 32-D866, Mondays during IAP or by appointment<br />
*External support on [http://irc.mozilla.org/ IRC] #mitiap2011<br />
*Here's a list of some [http://en.wikipedia.org/wiki/IRC#Client_software IRC clients] depending on your OS.<br />
<br><br />
*<b>Layout of the week</b><br />
**<b>January 10, 2011</b><br />
***<b>Lecture notes</b>: http://www.ccs.neu.edu/home/dherman/mit-iap-2011/<br />
***Lecturer: Dave Herman<br />
***Contact info:<br />
****Email: dherman@mozilla.com<br />
****IRC: dherman -- available on irc.mozilla.org at #jslang and #jsapi <br />
****Twitter: @littlecalculist<br />
***Topics covered: Foundations of JavaScript programming in the browser. Language syntax and concepts. Browser environment, events. (primitives, objects and prototypes, scope and global object, closures, events and callbacks)<br />
***Resources:<br />
****https://developer.mozilla.org/en/JavaScript/Guide<br />
****ECMAScript language standard (hard-core, but Ch. 15 is a useful reference for the standard JS library)<br />
*****Official PDF: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf<br />
*****HTML copy: http://ecma262-5.com/ELS5_HTML.htm<br />
****http://www.squarefree.com/shell/shell.html //Students can use it to test out JS commands in any browser. But the more recommended way would be to use the built-in developer tools of their browser (FF4 console or Firebug, Chrome console, Safari console).<br><br />
**<b>January 11, 2011</b> <br />
***Lecturer: Boris Zbarsky<br />
***Contact info<br />
****Email: bzbarsky@mozilla.com<br />
****IRC: bz -- available on irc.mozilla.org at #developers<br />
***Topics covered: The Document Object Model (DOM), the canvas element, resource loading (graphics)<br><br />
**<b>January 12, 2011</b><br />
***Lecturers: Benoit Jacob and Andor Salga<br />
***Contact info (Benoit)<br />
****Email: bjacob@mozilla.com<br />
****IRC: bjacob -- available on irc.mozilla.org at #developers #gfx #audio<br />
***Contact info (Andor)<br />
****Email: andor.salga@senecac.on.ca<br />
****IRC: nick:asalga -- available on irc.mozilla.org on #Seneca #Processing.js and #C3DL Also avaiable on irc.freenode.net on #WebGL<br />
****Twitter: @asalga<br />
****Wordpress: http://asalga.wordpress.com<br />
***Topics covered: Introduction to 3D graphics with OpenGL/WebGL. Basics of shader programming<br />
***Useful links<br />
****WebGL specification: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html<br />
****WebGL tutorials: http://www.learningWebGL.com<br />
****WebGL point cloud renderer: http://zenit.senecac.on.ca/wiki/index.php/XB_PointStream<br />
****Data visualizer library which uses WebGL: www.processingjs.org<br />
****WebGL library: www.c3dl.org<br />
****http://www.doesmybrowsersupportwebgl.com/<br />
****http://learningwebgl.com/lessons/<br />
**<b>January 13, 2011</b> <br />
***Lecturer: Chris Heilmann<br />
***Topics covered: Audio tag and foundations of audio programming/mixing. Chris to spend time on video too?<br />
**<b>January 14, 2011</b><br />
***Lecturer: Pascal Rettig from [http://cykod.com/ Cykod]<br />
***Topics covered: Offline web applications, local storage, debugging and optimizing JS performance. Also to be discussed: server side Javascript (node.js) and Web sockets.<br />
***Resources:<br />
****Offline storage - http://diveintohtml5.org/offline.html<br />
****Local storage - http://diveintohtml5.org/storage.html<br />
****JS Debugging /w Firebug - http://getfirebug.com/javascript<br />
****Node.js - http://nodejs.org/<br />
****Node Package Manager - http://npmjs.org/<br />
****Node Realtime Sockets Module - http://socket.io/<br />
<br />
<br><br />
*<b>Competition</b><br />
**After the course work component, students will compete in a HTML5 game programming competition. The competition will run for 4 weeks. Mozilla will host a discussion forum for students to communicate and collaborate and ask and answer questions amongst each other. The goal is for students to implement an interesting HTML5 game or visual demonstration. Whether its a create re-implementation of existing games (HTML5 pong?), or a full fledge 3D game, anything goes. <br />
**Swag: The winning team (up to 4 team members max) will come to Mountain View, spend a w/e in SF. During their time at Mozila, the team will present its demo/game and spend some time with Brendan Eich.</div>Dhermanhttps://wiki.mozilla.org/index.php?title=User:Jgoulie&diff=276540User:Jgoulie2011-01-10T03:57:58Z<p>Dherman: /* MIT IAP, January 10-14, 2011 */</p>
<hr />
<div>== MIT IAP, January 10-14, 2011 ==<br />
<br />
<br />
* Name of the class: IAP HTML5 Game Programming Course and Competition<br />
* Coursework Component: 5 sessions, 2 hours each (total instruction time 10 hours)<br />
*Schedule: everyday 11.30-1.30pm EST in room 32-141 ((http://whereis.mit.edu/)<br />
*External support on [http://irc.mozilla.org/ IRC] #mitiap2011<br />
<br><br />
*<b>Layout of the week</b><br />
**<b>January 10, 2011</b><br />
***Lecturer: Dave Herman<br />
***Contact info:<br />
****Email: dherman@mozilla.com<br />
****IRC: dherman -- available on irc.mozilla.org at #jslang and #jsapi <br />
****Twitter: @littlecalculist<br />
***Topics covered: Foundations of JavaScript programming in the browser. Language syntax and concepts. Browser environment, events. (primitives, objects and prototypes, scope and global object, closures, events and callbacks)<br />
***Resources:<br />
****https://developer.mozilla.org/en/JavaScript/Guide<br />
****ECMAScript language standard (hard-core, but Ch. 15 is a useful reference for the standard JS library)<br />
*****Official PDF: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf<br />
*****HTML copy: http://ecma262-5.com/ELS5_HTML.htm<br />
****http://www.squarefree.com/shell/shell.html //Students can use it to test out JS commands in any browser. But the more recommended way would be to use the built-in developer tools of their browser (FF4 console or Firebug, Chrome console, Safari console).<br><br />
**<b>January 11, 2011</b> <br />
***Lecturer: Boris Zbarsky<br />
***Contact info<br />
****Email: bzbarsky@mozilla.com<br />
****IRC: bz -- available on irc.mozilla.org at #developers<br />
***Topics covered: The Document Object Model (DOM), the canvas element, resource loading (graphics)<br><br />
**<b>January 12, 2011</b><br />
***Lecturers: Benoit Jacob and Andor Salga<br />
***Contact info (Benoit)<br />
****Email: bjacob@mozilla.com<br />
****IRC: bjacob -- available on irc.mozilla.org at #developers #gfx #audio<br />
***Contact info (Andor)<br />
****Email: andor.salga@senecac.on.ca<br />
****IRC: nick:asalga -- available on irc.mozilla.org on #Seneca #Processing.js and #C3DL Also avaiable on irc.freenode.net on #WebGL<br />
****Twitter: @asalga<br />
****Wordpress: http://asalga.wordpress.com<br />
***Topics covered: Introduction to 3D graphics with OpenGL/WebGL. Basics of shader programming<br />
***Useful links<br />
****WebGL specification: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html<br />
****WebGL tutorials: http://www.learningWebGL.com<br />
****WebGL point cloud renderer: http://zenit.senecac.on.ca/wiki/index.php/XB_PointStream<br />
****Data visualizer library which uses WebGL: www.processingjs.org<br />
****WebGL library: www.c3dl.org<br />
****http://www.doesmybrowsersupportwebgl.com/<br />
****http://learningwebgl.com/lessons/<br />
**<b>January 13, 2011</b> <br />
***Lecturer: Chris Heilmann<br />
***Topics covered: Audio tag and foundations of audio programming/mixing. Chris to spend time on video too?<br />
**<b>January 14, 2011</b><br />
***Lecturer: Pascal Rettig from [http://cykod.com/ Cykod]<br />
***Topics covered: Offline web applications, local storage, debugging and optimizing JS performance. Also to be discussed: server side Javascript (node.js) and Web sockets.<br />
<br><br />
*<b>Competition</b><br />
**After the course work component, students will compete in a HTML5 game programming competition. The competition will run for 4 weeks. Mozilla will host a discussion forum for students to communicate and collaborate and ask and answer questions amongst each other. The goal is for students to implement an interesting HTML5 game or visual demonstration. Whether its a create re-implementation of existing games (HTML5 pong?), or a full fledge 3D game, anything goes. <br />
**Swag: The winning team (up to 4 team members max) will come to Mountain View, spend a w/e in SF. During their time at Mozila, the team will present its demo/game and spend some time with Brendan Eich.</div>Dhermanhttps://wiki.mozilla.org/index.php?title=User:Jgoulie&diff=276539User:Jgoulie2011-01-10T03:57:07Z<p>Dherman: /* MIT IAP, January 10-14, 2011 */</p>
<hr />
<div>== MIT IAP, January 10-14, 2011 ==<br />
<br />
<br />
* Name of the class: IAP HTML5 Game Programming Course and Competition<br />
* Coursework Component: 5 sessions, 2 hours each (total instruction time 10 hours)<br />
*Schedule: everyday 11.30-1.30pm EST in room 32-141 ((http://whereis.mit.edu/)<br />
*External support on [http://irc.mozilla.org/ IRC] #mitiap2011<br />
<br><br />
*<b>Layout of the week</b><br />
**<b>January 10, 2011</b><br />
***Lecturer: Dave Herman<br />
***Contact info:<br />
****Email: dherman@mozilla.com<br />
****IRC: dherman -- available on irc.mozilla.org at #jslang and #jsapi <br />
****Twitter: @littlecalculist<br />
***Topics covered: Foundations of JavaScript programming in the browser. Language syntax and concepts. Browser environment, events. (object and prototype, scope and global object, closures, events and call backs, numbers, XHR)<br />
***Resources:<br />
****https://developer.mozilla.org/en/JavaScript/Guide<br />
****ECMAScript language standard (hard-core, but Ch. 15 is a useful reference for the standard JS library)<br />
*****Official PDF: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf<br />
*****HTML copy: http://ecma262-5.com/ELS5_HTML.htm<br />
****http://www.squarefree.com/shell/shell.html //Students can use it to test out JS commands in any browser. But the more recommended way would be to use the built-in developer tools of their browser (FF4 console or Firebug, Chrome console, Safari console).<br><br />
**<b>January 11, 2011</b> <br />
***Lecturer: Boris Zbarsky<br />
***Contact info<br />
****Email: bzbarsky@mozilla.com<br />
****IRC: bz -- available on irc.mozilla.org at #developers<br />
***Topics covered: The Document Object Model (DOM), the canvas element, resource loading (graphics)<br><br />
**<b>January 12, 2011</b><br />
***Lecturers: Benoit Jacob and Andor Salga<br />
***Contact info (Benoit)<br />
****Email: bjacob@mozilla.com<br />
****IRC: bjacob -- available on irc.mozilla.org at #developers #gfx #audio<br />
***Contact info (Andor)<br />
****Email: andor.salga@senecac.on.ca<br />
****IRC: nick:asalga -- available on irc.mozilla.org on #Seneca #Processing.js and #C3DL Also avaiable on irc.freenode.net on #WebGL<br />
****Twitter: @asalga<br />
****Wordpress: http://asalga.wordpress.com<br />
***Topics covered: Introduction to 3D graphics with OpenGL/WebGL. Basics of shader programming<br />
***Useful links<br />
****WebGL specification: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html<br />
****WebGL tutorials: http://www.learningWebGL.com<br />
****WebGL point cloud renderer: http://zenit.senecac.on.ca/wiki/index.php/XB_PointStream<br />
****Data visualizer library which uses WebGL: www.processingjs.org<br />
****WebGL library: www.c3dl.org<br />
****http://www.doesmybrowsersupportwebgl.com/<br />
****http://learningwebgl.com/lessons/<br />
**<b>January 13, 2011</b> <br />
***Lecturer: Chris Heilmann<br />
***Topics covered: Audio tag and foundations of audio programming/mixing. Chris to spend time on video too?<br />
**<b>January 14, 2011</b><br />
***Lecturer: Pascal Rettig from [http://cykod.com/ Cykod]<br />
***Topics covered: Offline web applications, local storage, debugging and optimizing JS performance. Also to be discussed: server side Javascript (node.js) and Web sockets.<br />
<br><br />
*<b>Competition</b><br />
**After the course work component, students will compete in a HTML5 game programming competition. The competition will run for 4 weeks. Mozilla will host a discussion forum for students to communicate and collaborate and ask and answer questions amongst each other. The goal is for students to implement an interesting HTML5 game or visual demonstration. Whether its a create re-implementation of existing games (HTML5 pong?), or a full fledge 3D game, anything goes. <br />
**Swag: The winning team (up to 4 team members max) will come to Mountain View, spend a w/e in SF. During their time at Mozila, the team will present its demo/game and spend some time with Brendan Eich.</div>Dhermanhttps://wiki.mozilla.org/index.php?title=Narcissus/Development&diff=244456Narcissus/Development2010-08-11T00:11:14Z<p>Dherman: </p>
<hr />
<div>== Terminology ==<br />
<br />
Since JavaScript is both the language of the implementation and the language being implemented, it's helpful to distinguish the two levels conceptually:<br />
<br />
* '''host''' ("host code," "host JS," etc): JS code in the implementation of Narcissus<br />
* '''user''' ("user code," "user JS," etc): JS code being interpreted by Narcissus<br />
<br />
== Narcissus global object ==<br />
<br />
Loading the Narcissus source files creates a global variable <code>Narcissus</code>.<br />
<br />
<code>Narcissus.options</code> is an object which can be used to set some global configuration options for Narcissus. Currently there is just one configuration option:<br />
<br />
{| border="1"<br />
! Property || Options<br />
|-<br />
| <code>version</code> || <code>185</code>, <code>"harmony"</code><br />
|}<br />
<br />
== Narcissus modules ==<br />
<br />
Narcissus is divided into four "modules" (using the [http://yuiblog.com/blog/2007/06/12/module-pattern/ module pattern]):<br />
<br />
* <code>Narcissus.definitions</code> (jsdefs.js): basic definitions shared by the other modules<br />
* <code>Narcissus.lexer</code> (jslex.js): lexer<br />
* <code>Narcissus.parser</code> (jsparse.js): parser<br />
* <code>Narcissus.interpreter</code> (jsexec.js): interpreter<br />
<br />
The <code>Narcissus.interpreter</code> module is optional; that is, it's possible to load just the first three files to obtain a JavaScript parser written in portable JavaScript.<br />
<br />
== Host language versions ==<br />
<br />
These are the host language versions required by each module/source file:<br />
<br />
* jsdefs.js: ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* jslex.js: ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* jsparse.js: ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* jsexec.js: SpiderMonkey JS 1.9:<br />
** <code>const</code> (Harmony)<br />
** <code>catch</code> guards (replaceable with <code>catch</code> + <code>if</code>)<br />
** <code>let</code> declarations (Harmony)<br />
** <code>Proxy</code> (Harmony)<br />
** <code>Object.defineProperty</code> (ES5)<br />
** <code>Object.getOwnPropertyDescriptor</code> (ES5)<br />
** <code>Object.getPrototypeOf</code> (ES5)<br />
** <code>Object.getOwnPropertyNames</code> (ES5)<br />
** <code>__proto__ = null</code> (replaceable with [http://wiki.ecmascript.org/doku.php?id=strawman:simple_maps_and_sets Harmony maps])<br />
** <code>__proto__ = obj</code> (replaceable with <code>Object.create</code>)<br />
<br />
The first three modules are web-portable. Only jsexec.js depends on SpiderMonkey extensions.<br />
<br />
== User language versions ==<br />
<br />
The versions of JavaScript interpreted by Narcissus are under development. Currently, the interpreter works reasonably well on ES3 code, with support for a few SpiderMonkey extensions.<br />
<br />
'''TODO:''' tighten this up as it stabilizes<br />
<br />
== Interpreter ==<br />
<br />
Narcissus is a meta-circular JavaScript interpreter with a very direct representation of values: primitives are self-representing, objects are represented as objects (with their properties accessible via usual property access), and functions are represented as functions. The interpreter is designed this way to allow existing JavaScript functions and objects (such as the standard libraries) to interface directly with Narcissus code without following any special protocol or requiring wrapping and unwrapping.<br />
<br />
=== Values ===<br />
<br />
User-JS primitive values are represented in host-JS directly as themselves.<br />
<br />
User-JS objects are represented directly as host-JS objects; each user-property <code>foo</code> is directly represented as a host-property <code>foo</code>.<br />
<br />
User-JS functions are represented as proxy functions that wrap a <code>FunctionObject</code>, which encapsulates the <code>Node</code> and <code>ExecutionContext</code> for the closure.<br />
<br />
=== Control flow ===<br />
<br />
Code is always executed with a current <code>ExecutionContext</code>, which contains the current scope chain and <code>this</code> binding. Execution contexts also contain a <code>result</code> property, which is used for the completion value of the current statement or expression or the result of returning from a function or throwing an exception.<br />
<br />
Calling a user-JS function is represented by calling the host-JS <code>__call__</code> method. Narcissus patches the host-JS <code>Function.prototype</code> to add a default <code>__call__</code> method. Similarly, calling a user-JS function as a constructor (i.e., from <code>new</code>) is represented by calling the host-JS <code>__construct__</code> method. (This is leaky and would be better implemented with private names; see [https://bugzilla.mozilla.org/show_bug.cgi?id=586095 bug 586095].)<br />
<br />
Returning from a function via <code>return</code> is represented by throwing the constant <code>RETURN</code>. The return value is stored in the <code>result</code> property of the current execution context.<br />
<br />
Throwing a user-JS exception is represented by throwing the constant <code>THROW</code>. The exception value is stored in the <code>result</code> property of the current execution context.<br />
<br />
Breaking or continuing a loop is represented by throwing the constant <code>BREAK</code> or <code>CONTINUE</code>, respectively.</div>Dhermanhttps://wiki.mozilla.org/index.php?title=Narcissus/Development&diff=244396Narcissus/Development2010-08-10T22:16:53Z<p>Dherman: interpreter info</p>
<hr />
<div>== Terminology ==<br />
<br />
Since JavaScript is both the language of the implementation and the language being implemented, it's helpful to distinguish the two levels conceptually:<br />
<br />
* '''host''' ("host code," "host JS," etc): JS code in the implementation of Narcissus<br />
* '''user''' ("user code," "user JS," etc): JS code being interpreted by Narcissus<br />
<br />
== Narcissus global object ==<br />
<br />
Loading the Narcissus source files creates a global variable <code>Narcissus</code>.<br />
<br />
<code>Narcissus.options</code> is an object which can be used to set some global configuration options for Narcissus. Currently there is just one configuration option:<br />
<br />
{| border="1"<br />
! Property || Options<br />
|-<br />
| <code>version</code> || <code>185</code>, <code>"harmony"</code><br />
|}<br />
<br />
== Narcissus modules ==<br />
<br />
Narcissus is divided into four "modules" (using the [http://yuiblog.com/blog/2007/06/12/module-pattern/ module pattern]):<br />
<br />
* <code>Narcissus.definitions</code> (jsdefs.js): basic definitions shared by the other modules<br />
* <code>Narcissus.lexer</code> (jslex.js): lexer<br />
* <code>Narcissus.parser</code> (jsparse.js): parser<br />
* <code>Narcissus.interpreter</code> (jsexec.js): interpreter<br />
<br />
The <code>Narcissus.interpreter</code> module is optional; that is, it's possible to load just the first three files to obtain a JavaScript parser written in portable JavaScript.<br />
<br />
== Host language versions ==<br />
<br />
These are the host language versions required by each module/source file:<br />
<br />
* jsdefs.js: ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* jslex.js: ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* jsparse.js: ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* jsexec.js: SpiderMonkey JS 1.9:<br />
** <code>const</code> (Harmony)<br />
** <code>catch</code> guards (replaceable with <code>catch</code> + <code>if</code>)<br />
** <code>let</code> declarations (Harmony)<br />
** <code>Proxy</code> (Harmony)<br />
** <code>Object.defineProperty</code> (ES5)<br />
** <code>Object.getOwnPropertyDescriptor</code> (ES5)<br />
** <code>Object.getPrototypeOf</code> (ES5)<br />
** <code>Object.getOwnPropertyNames</code> (ES5)<br />
** <code>__proto__ = null</code> (replaceable with [http://wiki.ecmascript.org/doku.php?id=strawman:simple_maps_and_sets Harmony maps])<br />
** <code>__proto__ = obj</code> (replaceable with <code>Object.create</code>)<br />
<br />
The first three modules are web-portable. Only jsexec.js depends on SpiderMonkey extensions.<br />
<br />
== User language versions ==<br />
<br />
The versions of JavaScript interpreted by Narcissus are under development. Currently, the interpreter works reasonably well on ES3 code, with support for a few SpiderMonkey extensions.<br />
<br />
'''TODO:''' tighten this up as it stabilizes<br />
<br />
== Interpreter ==<br />
<br />
Narcissus is a meta-circular JavaScript interpreter with a very direct representation of values: primitives are self-representing, objects are represented as objects (with their properties accessible via usual property access), and functions are represented as functions. The interpreter is designed this way to allow existing JavaScript functions and objects (such as the standard libraries) to interface directly with Narcissus code without following any special protocol or requiring wrapping and unwrapping.<br />
<br />
=== Values ===<br />
<br />
User-JS primitive values are represented in host-JS directly as themselves.<br />
<br />
User-JS objects are represented directly as host-JS objects; each user-property <code>foo</code> is directly represented as a host-property <code>foo</code>.<br />
<br />
User-JS functions are represented as proxy functions that wrap a <code>FunctionObject</code>, which encapsulates the <code>Node</code> and <code>ExecutionContext</code> for the closure.<br />
<br />
=== Control flow ===<br />
<br />
Code is always executed with a current <code>ExecutionContext</code>, which contains the current scope chain and <code>this</code> binding. Execution contexts also contain a <code>result</code> property, which is used for the completion value of the current statement or expression or the result of returning from a function or throwing an exception.<br />
<br />
Calling a user-JS function is represented by calling the host-JS <code>__call__</code> method. Narcissus patches the host-JS <code>Function.prototype</code> to add a default <code>__call__</code> method. Similarly, calling a user-JS function as a constructor (i.e., from <code>new</code>) is represented by calling the host-JS <code>__construct__</code> method. '''This is unnecessary now that functions are proxies; see [https://bugzilla.mozilla.org/show_bug.cgi?id=586095 bug 586095].'''<br />
<br />
Returning from a function via <code>return</code> is represented by throwing the constant <code>RETURN</code>. The return value is stored in the <code>result</code> property of the current execution context.<br />
<br />
Throwing a user-JS exception is represented by throwing the constant <code>THROW</code>. The exception value is stored in the <code>result</code> property of the current execution context.<br />
<br />
Breaking or continuing a loop is represented by throwing the constant <code>BREAK</code> or <code>CONTINUE</code>, respectively.</div>Dhermanhttps://wiki.mozilla.org/index.php?title=Narcissus/Development&diff=244228Narcissus/Development2010-08-10T17:12:22Z<p>Dherman: another host-lang req, more in the interpreter</p>
<hr />
<div>== Terminology ==<br />
<br />
Since JavaScript is both the language of the implementation and the language being implemented, it's helpful to distinguish the two levels conceptually:<br />
<br />
* '''host''' ("host code," "host JS," etc): JS code in the implementation of Narcissus<br />
* '''user''' ("user code," "user JS," etc): JS code being interpreted by Narcissus<br />
<br />
== Narcissus global object ==<br />
<br />
Loading the Narcissus source files creates a global variable <code>Narcissus</code>.<br />
<br />
<code>Narcissus.options</code> is an object which can be used to set some global configuration options for Narcissus. Currently there is just one configuration option:<br />
<br />
{| border="1"<br />
! Property || Options<br />
|-<br />
| <code>version</code> || <code>185</code>, <code>"harmony"</code><br />
|}<br />
<br />
== Narcissus modules ==<br />
<br />
Narcissus is divided into four "modules" (using the [http://yuiblog.com/blog/2007/06/12/module-pattern/ module pattern]):<br />
<br />
* <code>Narcissus.definitions</code> (jsdefs.js): basic definitions shared by the other modules<br />
* <code>Narcissus.lexer</code> (jslex.js): lexer<br />
* <code>Narcissus.parser</code> (jsparse.js): parser<br />
* <code>Narcissus.interpreter</code> (jsexec.js): interpreter<br />
<br />
The <code>Narcissus.interpreter</code> module is optional; that is, it's possible to load just the first three files to obtain a JavaScript parser written in portable JavaScript.<br />
<br />
== Host language versions ==<br />
<br />
These are the host language versions required by each module/source file:<br />
<br />
* jsdefs.js: ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* jslex.js: ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* jsparse.js: ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* jsexec.js: SpiderMonkey JS 1.9:<br />
** <code>const</code> (Harmony)<br />
** <code>catch</code> guards (replaceable with <code>catch</code> + <code>if</code>)<br />
** <code>let</code> declarations (Harmony)<br />
** <code>Proxy</code> (Harmony)<br />
** <code>Object.defineProperty</code> (ES5)<br />
** <code>Object.getOwnPropertyDescriptor</code> (ES5)<br />
** <code>Object.getPrototypeOf</code> (ES5)<br />
** <code>Object.getOwnPropertyNames</code> (ES5)<br />
** <code>__proto__ = null</code> (replaceable with [http://wiki.ecmascript.org/doku.php?id=strawman:simple_maps_and_sets Harmony maps])<br />
** <code>__proto__ = obj</code> (replaceable with <code>Object.create</code>)<br />
<br />
The first three modules are web-portable. Only jsexec.js depends on SpiderMonkey extensions.<br />
<br />
== User language versions ==<br />
<br />
The versions of JavaScript interpreted by Narcissus are under development. Currently, the interpreter works reasonably well on ES3 code, with support for a few SpiderMonkey extensions.<br />
<br />
'''TODO:''' tighten this up as it stabilizes<br />
<br />
== Interpreter ==<br />
<br />
Narcissus is a meta-circular JavaScript interpreter with a very direct representation of values: primitives are self-representing, objects are represented as objects (with their properties accessible via usual property access), and functions are represented as functions. The interpreter is designed this way to allow existing JavaScript functions and objects (such as the standard libraries) to interface directly with Narcissus code without following any special protocol or requiring wrapping and unwrapping.<br />
<br />
=== Values ===<br />
<br />
* all values are roughly self-representing<br />
* function proxies<br />
<br />
=== Control flow ===<br />
<br />
* <code>ExecutionContext</code>s<br />
* <code>RETURN</code>, <code>THROW</code>, <code>BREAK</code>, <code>CONTINUE</code><br />
* <code>__call__</code><br />
* function proxies</div>Dhermanhttps://wiki.mozilla.org/index.php?title=Narcissus/Development&diff=244032Narcissus/Development2010-08-09T21:27:49Z<p>Dherman: Narcissus.options</p>
<hr />
<div>== Terminology ==<br />
<br />
Since JavaScript is both the language of the implementation and the language being implemented, it's helpful to distinguish the two levels conceptually:<br />
<br />
* '''host''' ("host code," "host JS," etc): JS code in the implementation of Narcissus<br />
* '''user''' ("user code," "user JS," etc): JS code being interpreted by Narcissus<br />
<br />
== Narcissus global object ==<br />
<br />
Loading the Narcissus source files creates a global variable <code>Narcissus</code>.<br />
<br />
<code>Narcissus.options</code> is an object which can be used to set some global configuration options for Narcissus. Currently there is just one configuration option:<br />
<br />
{| border="1"<br />
! Property || Options<br />
|-<br />
| <code>version</code> || <code>185</code>, <code>"harmony"</code><br />
|}<br />
<br />
== Narcissus modules ==<br />
<br />
Narcissus is divided into four "modules" (using the [http://yuiblog.com/blog/2007/06/12/module-pattern/ module pattern]):<br />
<br />
* <code>Narcissus.definitions</code> (jsdefs.js): basic definitions shared by the other modules<br />
* <code>Narcissus.lexer</code> (jslex.js): lexer<br />
* <code>Narcissus.parser</code> (jsparse.js): parser<br />
* <code>Narcissus.interpreter</code> (jsexec.js): interpreter<br />
<br />
The <code>Narcissus.interpreter</code> module is optional; that is, it's possible to load just the first three files to obtain a JavaScript parser written in portable JavaScript.<br />
<br />
== Host language versions ==<br />
<br />
These are the host language versions required by each module/source file:<br />
<br />
* jsdefs.js: ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* jslex.js: ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* jsparse.js: ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* jsexec.js: SpiderMonkey JS 1.9:<br />
** <code>const</code> (Harmony)<br />
** <code>catch</code> guards (replaceable with <code>catch</code> + <code>if</code>)<br />
** <code>let</code> declarations (Harmony)<br />
** <code>Proxy</code> (Harmony)<br />
** <code>Object.defineProperty</code> (ES5)<br />
** <code>Object.getOwnPropertyDescriptor</code> (ES5)<br />
** <code>Object.getPrototypeOf</code> (ES5)<br />
** <code>Object.getOwnPropertyNames</code> (ES5)<br />
** <code>__proto__ = null</code> (replaceable with [http://wiki.ecmascript.org/doku.php?id=strawman:simple_maps_and_sets Harmony maps])<br />
<br />
The first three modules are web-portable. Only jsexec.js depends on SpiderMonkey extensions.<br />
<br />
== User language versions ==<br />
<br />
The versions of JavaScript interpreted by Narcissus are under development. Currently, the interpreter works reasonably well on ES3 code, with support for a few SpiderMonkey extensions.<br />
<br />
'''TODO:''' tighten this up as it stabilizes<br />
<br />
== Interpreter ==<br />
<br />
'''TODO:''' write this<br />
<br />
* value representation<br />
* control flow<br />
* use of proxies<br />
* standard library</div>Dhermanhttps://wiki.mozilla.org/index.php?title=Narcissus/Development&diff=244015Narcissus/Development2010-08-09T21:07:37Z<p>Dherman: updated module names</p>
<hr />
<div>== Terminology ==<br />
<br />
Since JavaScript is both the language of the implementation and the language being implemented, it's helpful to distinguish the two levels conceptually:<br />
<br />
* '''host''' ("host code," "host JS," etc): JS code in the implementation of Narcissus<br />
* '''user''' ("user code," "user JS," etc): JS code being interpreted by Narcissus<br />
<br />
== Narcissus modules ==<br />
<br />
Narcissus is divided into four "modules" (using the [http://yuiblog.com/blog/2007/06/12/module-pattern/ module pattern]):<br />
<br />
* <code>Narcissus.definitions</code> (jsdefs.js): basic definitions shared by the other modules<br />
* <code>Narcissus.lexer</code> (jslex.js): lexer<br />
* <code>Narcissus.parser</code> (jsparse.js): parser<br />
* <code>Narcissus.interpreter</code> (jsexec.js): interpreter<br />
<br />
The <code>Narcissus.interpreter</code> module is optional; that is, it's possible to load just the first three files to obtain a JavaScript parser written in portable JavaScript.<br />
<br />
== Host language versions ==<br />
<br />
These are the host language versions required by each module/source file:<br />
<br />
* jsdefs.js: ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* jslex.js: ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* jsparse.js: ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* jsexec.js: SpiderMonkey JS 1.9:<br />
** <code>const</code> (Harmony)<br />
** <code>catch</code> guards (replaceable with <code>catch</code> + <code>if</code>)<br />
** <code>let</code> declarations (Harmony)<br />
** <code>Proxy</code> (Harmony)<br />
** <code>Object.defineProperty</code> (ES5)<br />
** <code>Object.getOwnPropertyDescriptor</code> (ES5)<br />
** <code>Object.getPrototypeOf</code> (ES5)<br />
** <code>Object.getOwnPropertyNames</code> (ES5)<br />
** <code>__proto__ = null</code> (replaceable with [http://wiki.ecmascript.org/doku.php?id=strawman:simple_maps_and_sets Harmony maps])<br />
<br />
The first three modules are web-portable. Only jsexec.js depends on SpiderMonkey extensions.<br />
<br />
== User language versions ==<br />
<br />
The versions of JavaScript interpreted by Narcissus are under development. Currently, the interpreter works reasonably well on ES3 code, with support for a few SpiderMonkey extensions.<br />
<br />
'''TODO:''' tighten this up as it stabilizes<br />
<br />
== Configuration ==<br />
<br />
'''TODO:''' write this<br />
<br />
* <code>Narcissus</code> global<br />
* <code>Narcissus.options</code><br />
<br />
== Interpreter ==<br />
<br />
'''TODO:''' write this<br />
<br />
* value representation<br />
* control flow<br />
* use of proxies<br />
* standard library</div>Dhermanhttps://wiki.mozilla.org/index.php?title=Narcissus/Development&diff=243887Narcissus/Development2010-08-09T16:07:40Z<p>Dherman: more on host-JS feature requirements</p>
<hr />
<div>== Terminology ==<br />
<br />
Since JavaScript is both the language of the implementation and the language being implemented, it's helpful to distinguish the two levels conceptually:<br />
<br />
* '''host''' ("host code," "host JS," etc): JS code in the implementation of Narcissus<br />
* '''user''' ("user code," "user JS," etc): JS code being interpreted by Narcissus<br />
<br />
== Narcissus modules ==<br />
<br />
Narcissus is divided into four "modules" (using the [http://yuiblog.com/blog/2007/06/12/module-pattern/ module pattern]):<br />
<br />
* '''jsdefs''': basic definitions shared by the other modules<br />
* '''jslex''': lexer<br />
* '''jsparse''': parser<br />
* '''jsexec''': interpreter<br />
<br />
The '''jsexec''' module is optional; that is, it's possible to use just the first three modules as a JavaScript parser written in portable JavaScript.<br />
<br />
== Host language versions ==<br />
<br />
These are the host language versions required by each module:<br />
<br />
* '''jsdefs''': ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* '''jslex''': ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* '''jsparse''': ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* '''jsexec''': SpiderMonkey JS 1.9:<br />
** <code>const</code> (Harmony)<br />
** <code>catch</code> guards (replaceable with <code>catch</code> + <code>if</code>)<br />
** <code>let</code> declarations (Harmony)<br />
** <code>Proxy</code> (Harmony)<br />
** <code>Object.defineProperty</code> (ES5)<br />
** <code>Object.getOwnPropertyDescriptor</code> (ES5)<br />
** <code>Object.getPrototypeOf</code> (ES5)<br />
** <code>Object.getOwnPropertyNames</code> (ES5)<br />
** <code>__proto__ = null</code> (replaceable with [http://wiki.ecmascript.org/doku.php?id=strawman:simple_maps_and_sets Harmony maps])<br />
<br />
The first three modules are web-portable. Only the '''jsexec''' module depends on SpiderMonkey extensions.<br />
<br />
== User language versions ==<br />
<br />
The versions of JavaScript interpreted by Narcissus are under development. Currently, the interpreter works reasonably well on ES3 code, with support for a few SpiderMonkey extensions.<br />
<br />
'''TODO:''' tighten this up as it stabilizes<br />
<br />
== Configuration ==<br />
<br />
'''TODO:''' write this<br />
<br />
* <code>Narcissus</code> global<br />
* <code>Narcissus.options</code><br />
<br />
== Interpreter ==<br />
<br />
'''TODO:''' write this<br />
<br />
* value representation<br />
* control flow<br />
* use of proxies<br />
* standard library</div>Dhermanhttps://wiki.mozilla.org/index.php?title=Narcissus/Development&diff=243720Narcissus/Development2010-08-07T18:12:13Z<p>Dherman: created</p>
<hr />
<div>== Terminology ==<br />
<br />
Since JavaScript is both the language of the implementation and the language being implemented, it's helpful to distinguish the two levels conceptually:<br />
<br />
* '''host''' ("host code," "host JS," etc): JS code in the implementation of Narcissus<br />
* '''user''' ("user code," "user JS," etc): JS code being interpreted by Narcissus<br />
<br />
== Narcissus modules ==<br />
<br />
Narcissus is divided into four "modules" (using the [http://yuiblog.com/blog/2007/06/12/module-pattern/ module pattern]):<br />
<br />
* '''jsdefs''': basic definitions shared by the other modules<br />
* '''jslex''': lexer<br />
* '''jsparse''': parser<br />
* '''jsexec''': interpreter<br />
<br />
The '''jsexec''' module is optional; that is, it's possible to use just the first three modules as a JavaScript parser written in portable JavaScript.<br />
<br />
== Host language versions ==<br />
<br />
These are the host language versions required by each module:<br />
<br />
* '''jsdefs''': ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* '''jslex''': ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* '''jsparse''': ES3 + <code>const</code> + <code>Object.defineProperty</code><br />
* '''jsexec''': SpiderMonkey JS 1.9:<br />
** <code>const</code><br />
** <code>catch</code> guards<br />
** <code>let</code> declarations<br />
** <code>Proxy</code><br />
** <code>Object.defineProperty</code><br />
** <code>Object.getOwnPropertyDescriptor</code><br />
** <code>Object.getPrototypeOf</code><br />
** <code>Object.getOwnPropertyNames</code><br />
<br />
The first three modules are web-portable. Only the '''jsexec''' module depends on SpiderMonkey extensions.<br />
<br />
== User language versions ==<br />
<br />
The versions of JavaScript interpreted by Narcissus are under development. Currently, the interpreter works reasonably well on ES3 code, with support for a few SpiderMonkey extensions.<br />
<br />
'''TODO:''' tighten this up as it stabilizes<br />
<br />
== Configuration ==<br />
<br />
'''TODO:''' write this<br />
<br />
* <code>Narcissus</code> global<br />
* <code>Narcissus.options</code><br />
<br />
== Interpreter ==<br />
<br />
'''TODO:''' write this<br />
<br />
* value representation<br />
* control flow<br />
* use of proxies<br />
* standard library</div>Dhermanhttps://wiki.mozilla.org/index.php?title=Narcissus&diff=243719Narcissus2010-08-07T17:57:55Z<p>Dherman: info on running, moved development info to separate page</p>
<hr />
<div>Narcissus is a JavaScript interpreter written in pure JavaScript, using the SpiderMonkey engine.<br />
<br />
Originally a proof-of-concept by Brendan Eich, Narcissus is being revived as a test-bed for rapidly prototyping new language features for the JavaScript language (and ECMAScript standard).<br />
<br />
== Downloading ==<br />
<br />
Narcissus is not currently available as a standalone distribution. It is included in the main SpiderMonkey source code tree. To download it, follow the instructions for [https://developer.mozilla.org/en/SpiderMonkey_Build_Documentation downloading and building the SpiderMonkey source].<br />
<br />
== Running at the command-line ==<br />
<br />
After building SpiderMonkey, your build directory includes a Python script called <code>njs</code>.<br />
<br />
Usage: njs<br />
<br />
Options:<br />
-h, --help show this help message and exit<br />
-f FILE, --file=FILE JS file to load<br />
-e JS_EXPS, --expression=JS_EXPS<br />
JS expression to evaluate<br />
-i, --interactive enable interactive shell<br />
-H, --harmony enable ECMAScript Harmony mode<br />
<br />
== Running in the browser ==<br />
<br />
Not yet supported. We're working on it.<br />
<br />
== Development ==<br />
<br />
See [[Narcissus/Development]].<br />
<br />
== Contributors ==<br />
<br />
* Tom Austin<br />
* Brendan Eich<br />
* Andreas Gal<br />
* Shu-yu Guo<br />
* Dave Herman<br />
* Dimitris Vardoulakis<br />
* Patrick Walton</div>Dhermanhttps://wiki.mozilla.org/index.php?title=Narcissus&diff=243346Narcissus2010-08-05T18:21:39Z<p>Dherman: </p>
<hr />
<div>Narcissus is a JavaScript interpreter written in pure JavaScript, using the SpiderMonkey engine.<br />
<br />
Originally a proof-of-concept by Brendan Eich, Narcissus is being revived as a test-bed for rapidly prototyping new language features for the JavaScript language (and ECMAScript standard).<br />
<br />
== Downloading ==<br />
<br />
Narcissus is included in the main SpiderMonkey source code tree. To download it, follow the instructions for [https://developer.mozilla.org/en/SpiderMonkey_Build_Documentation downloading and building the SpiderMonkey source], and run the "njs" script from the build directory.<br />
<br />
== Terminology ==<br />
<br />
Since JavaScript is both the language of the implementation and the language being implemented, it's helpful to distinguish the two levels conceptually. We use the term '''host''' ("host code," "host JavaScript," etc) to describe the JavaScript code of the implementation and '''user''' ("user code," "user JavaScript," etc) to describe the JavaScript code being interpreted.<br />
<br />
<br />
== Contributors ==<br />
<br />
* Tom Austin<br />
* Brendan Eich<br />
* Andreas Gal<br />
* Shu-yu Guo<br />
* Dave Herman<br />
* Dimitris Vardoulakis<br />
* Patrick Walton</div>Dhermanhttps://wiki.mozilla.org/index.php?title=Narcissus&diff=242470Narcissus2010-08-02T23:06:48Z<p>Dherman: quick downloading instructions</p>
<hr />
<div>Narcissus is a JavaScript interpreter written in pure JavaScript, using the SpiderMonkey engine.<br />
<br />
Originally a proof-of-concept by Brendan Eich, Narcissus is being revived as a test-bed for rapidly prototyping new language features for the JavaScript language (and ECMAScript standard).<br />
<br />
== Downloading ==<br />
<br />
Narcissus is included in the main SpiderMonkey source code tree. To download it, follow the instructions for [https://developer.mozilla.org/en/SpiderMonkey_Build_Documentation downloading and building the SpiderMonkey source], and run the "njs" script from the build directory.<br />
<br />
== Contributors ==<br />
<br />
* Tom Austin<br />
* Brendan Eich<br />
* Andreas Gal<br />
* Shu-Yu Guo<br />
* Dave Herman<br />
* Dimitris Vardoulakis<br />
* Patrick Walton</div>Dhermanhttps://wiki.mozilla.org/index.php?title=Narcissus&diff=242468Narcissus2010-08-02T23:01:30Z<p>Dherman: created</p>
<hr />
<div>Narcissus is a JavaScript interpreter written in pure JavaScript, using the SpiderMonkey engine.<br />
<br />
Originally a proof-of-concept by Brendan Eich, Narcissus is being revived as a test-bed for rapidly prototyping new language features for the JavaScript language (and ECMAScript standard).<br />
<br />
<br />
== Contributors ==<br />
<br />
* Tom Austin<br />
* Brendan Eich<br />
* Andreas Gal<br />
* Shu-Yu Guo<br />
* Dave Herman<br />
* Dimitris Vardoulakis<br />
* Patrick Walton</div>Dhermanhttps://wiki.mozilla.org/index.php?title=Summit2010/Meetings&diff=236415Summit2010/Meetings2010-07-05T05:17:51Z<p>Dherman: /* JavaScript / DOM / Wrappers */</p>
<hr />
<div>Additional meetings<br />
<br />
This page shall help us to coordinate additional meetings at the Summit.<br />
<br />
Maybe you'd like to meet with a group of people to sit down and discuss a topic, and none of the other talks seem to cover it?<br />
<br />
Which meetings will happen? Who is interested? Where to go? When?<br />
<br />
= Mozilla Meetings =<br />
Coming soon!...<br />
<br />
= Developer Meetings =<br />
<br />
== Security code, PSM, NSS, padlock ==<br />
<br />
* We want to talk about the open issues in PSM and answer questions<br />
* brainstorm on future code changes, such as improving the "https padlock tracking" mechanisms<br />
<br />
Proposed time and place:<br />
* After the "security trends" talk (B081), in the same room.<br />
<br />
Want to come (add yourself):<br />
* Honza Bambas<br />
* Kai Engert<br />
* Sid Stamm<br />
<br />
== Secure Authentication ==<br />
<br />
* We want to talk about PKI based user authentication, SSL client auth<br />
* brainstorm on user interfaces and implementation<br />
<br />
Proposed time and place:<br />
* After the "Account Manager & Online Identity" talk (B027), in the same room.<br />
<br />
Want to come (add yourself):<br />
* Kai Engert<br />
* Sid Stamm<br />
<br />
== Ubiquity catchup ==<br />
<br />
* General face-to-face get-together and catchup of Ubiquity's developers (and anyone else interested). Discussion about Ubiquity: past, present, and future.<br />
<br />
Proposed time and place:<br />
* Suggestions welcome<br />
<br />
Want to come (add yourself):<br />
* Blair McBride<br />
* Atul Varma<br />
* Jono Xia<br />
* Aza Raskin<br />
* Christian Sonne<br />
* Michael Erlewine<br />
<br />
== JavaScript / Harmony Proxies ==<br />
<br />
* Introduction to harmony proxies, the JS interface as well as our internal C++ interface.<br />
<br />
Proposed time and place:<br />
* Suggestions welcome<br />
<br />
Want to come (add yourself):<br />
* Andreas Gal<br />
* Luke Wagner<br />
* Dave Herman<br />
<br />
== JavaScript / DOM / Wrappers ==<br />
<br />
* We will talk about the JS security wrappers, old and new, and GC compartments. If you want to understand how security works in content and chrome JS or you have ideas how to make it better, this is for you.<br />
<br />
Proposed time and place:<br />
* Suggestions welcome<br />
<br />
Want to come (add yourself):<br />
* Andreas Gal<br />
* Blake Kaplan<br />
* David Anderson<br />
* Luke Wagner<br />
* Dave Herman<br />
<br />
= Contributor Meetings =<br />
== SuMoMo Non English Meeting ==<br />
[http://support.mozillamessaging.com/en-US/kb/ SuMoMo] is the knowledge base for Thunderbird! <br />
all SuMoMo contributors welcome but emphasis on non English SuMoMo. Would like especially like anybody who can/will contribute to SuMoMo from these languages DE, JP, IT, FR, CZ, NL, etc - <br />
host:rolandtanglao on irc ping him on #moz10, cell:+16047297924, roland AT mozillamessaging.com, Mozilla Messaging Technical Support Lead <br />
<br />
== QA & Support working hand in hand ==<br />
[http://etherpad.mozilla.com:9000/CV7WkIdVsx Organizing Thunderbird QA/Support Communities] - [[User:Tsk|Ludovic Hirlimann]] and Roland Tanglao (see SuMoMo above for contact info) will present ideas to organize support better to make support more effective worldwide as well as make support and QA work better together<br />
<br />
= Engineering Meetings =<br />
<br />
== IT, Labs/Services, Webdev collaboration ==<br />
<br />
Projects move back and forth among these groups throughout a projects' lifecycle, but there can be lots of bumps along the way.<br />
<br />
I'd like a meeting where people from these groups get together and we talk out ways to make everything move smoother. I guess the code phrase... to work together more like the web ;)<br />
<br />
Proposed time and place:<br />
<br />
* Suggestions? Put them in. First one with an opinion wins!<br />
<br />
Want to come (add yourself):<br />
<br />
* Ian Bicking<br />
* Les Orchard<br />
* Atul Varma<br />
* Pascal Finette<br />
* Zandr Milewski<br />
* Michael Coates<br />
<br />
== IT, RelEng: how to setup Build-VPN? ==<br />
<br />
We need restricted access to RelEng production systems. First attempt at Build-VPN was uncleanly specified, and doesn't work well. Fixing this is a joint IT/RelEng goal for Q3. <br />
<br />
Lets meet at whiteboard and brainstorm how to do this, before we start filing bugs and doing any work.<br />
<br />
Proposed time and place:<br />
<br />
* Suggestions? Put them in. First one with an opinion wins!<br />
<br />
Want to come (add yourself):<br />
<br />
<br />
== RelEng Brownbag - and RelEng Roast ==<br />
<br />
All you ever wanted to know about how the RelEng infrastructure works, and how you use it faster and more efficiently. Also, Q&A session to find suggestions for future improvements?<br />
<br />
At the December2009 allhands, there were a couple of "RelEng Roast" sessions at Academy of Science and at 650castro which people found quite useful. If you have gripes, pet peeves of things to fix or a wishlist of things you'd like to see added, this is the place.<br />
<br />
Proposed time and place:<br />
<br />
<br />
Want to come (add yourself):<br />
<br />
== RelEng, QA, Dev: How to Deal with Intermittent Oranges? ==<br />
<br />
Intermittent test failures (oranges) are still an issue, perhaps even more so now that we have brand-new 64-bit operating systems in play. <br />
<br />
Are people happy with brasstacks (http://brasstacks.mozilla.com/topfails/)? It seems to do most of the things we need to track intermittent test failures over time, but how many people are looking at it? At the risk of overburdening TBPL, do we need to link this info into TBPL somehow?<br />
<br />
On the RelEng side, we had/have the facility to re-run certain tests multiple times in a row, but we've had it disabled for a while since no one was looking at the results.<br />
<br />
<br />
Proposed time and place:<br />
<br />
<br />
Want to come (add yourself):<br />
Chris Cooper<br />
<br />
= Engagement Meetings =<br />
<br />
== PGP Signing party ==<br />
Idea is that mozilla contributors from all over the world are meeting. Some of us are using PGP on a daily basis - would be nice to sign / cross sign our keys.<br />
<br />
[[User:Tsk]] created a keyring on [http://biglumber.com/x/web?keyring=4739 biglumber], please add your key there , this will facilitate - the meeting and signing process, as printing the keyring will allow an easy, I've check this signature.<br />
<br />
If you have a pgp key consider joigning and add your key to the keyrrin (see above).<br />
<br />
Thursday July 8th 11:30 before the lightning talks. Meetpoint the lobby.<br />
<br />
See also: [http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html The Keysigning Party HOWTO]<br />
<br />
== CAcert Signing Party ==<br />
<br />
Assurers (please add your name if you want to assure) :<br />
* Bogomil Shopov<br />
* Iacopo Benesperi<br />
* Ludovic Hirlimann<br />
* Wolfgang Rosenauer<br />
* Karsten Düsterloh<br />
<br />
Thursday July 8th 13:45 - 14:15 Meetpoint , The lobby.</div>Dhermanhttps://wiki.mozilla.org/index.php?title=Summit2010/Meetings&diff=236414Summit2010/Meetings2010-07-05T05:16:32Z<p>Dherman: /* JavaScript / Harmony Proxies */</p>
<hr />
<div>Additional meetings<br />
<br />
This page shall help us to coordinate additional meetings at the Summit.<br />
<br />
Maybe you'd like to meet with a group of people to sit down and discuss a topic, and none of the other talks seem to cover it?<br />
<br />
Which meetings will happen? Who is interested? Where to go? When?<br />
<br />
= Mozilla Meetings =<br />
Coming soon!...<br />
<br />
= Developer Meetings =<br />
<br />
== Security code, PSM, NSS, padlock ==<br />
<br />
* We want to talk about the open issues in PSM and answer questions<br />
* brainstorm on future code changes, such as improving the "https padlock tracking" mechanisms<br />
<br />
Proposed time and place:<br />
* After the "security trends" talk (B081), in the same room.<br />
<br />
Want to come (add yourself):<br />
* Honza Bambas<br />
* Kai Engert<br />
* Sid Stamm<br />
<br />
== Secure Authentication ==<br />
<br />
* We want to talk about PKI based user authentication, SSL client auth<br />
* brainstorm on user interfaces and implementation<br />
<br />
Proposed time and place:<br />
* After the "Account Manager & Online Identity" talk (B027), in the same room.<br />
<br />
Want to come (add yourself):<br />
* Kai Engert<br />
* Sid Stamm<br />
<br />
== Ubiquity catchup ==<br />
<br />
* General face-to-face get-together and catchup of Ubiquity's developers (and anyone else interested). Discussion about Ubiquity: past, present, and future.<br />
<br />
Proposed time and place:<br />
* Suggestions welcome<br />
<br />
Want to come (add yourself):<br />
* Blair McBride<br />
* Atul Varma<br />
* Jono Xia<br />
* Aza Raskin<br />
* Christian Sonne<br />
* Michael Erlewine<br />
<br />
== JavaScript / Harmony Proxies ==<br />
<br />
* Introduction to harmony proxies, the JS interface as well as our internal C++ interface.<br />
<br />
Proposed time and place:<br />
* Suggestions welcome<br />
<br />
Want to come (add yourself):<br />
* Andreas Gal<br />
* Luke Wagner<br />
* Dave Herman<br />
<br />
== JavaScript / DOM / Wrappers ==<br />
<br />
* We will talk about the JS security wrappers, old and new, and GC compartments. If you want to understand how security works in content and chrome JS or you have ideas how to make it better, this is for you.<br />
<br />
Proposed time and place:<br />
* Suggestions welcome<br />
<br />
Want to come (add yourself):<br />
* Andreas Gal<br />
* Blake Kaplan<br />
* David Anderson<br />
* Luke Wagner<br />
<br />
= Contributor Meetings =<br />
== SuMoMo Non English Meeting ==<br />
[http://support.mozillamessaging.com/en-US/kb/ SuMoMo] is the knowledge base for Thunderbird! <br />
all SuMoMo contributors welcome but emphasis on non English SuMoMo. Would like especially like anybody who can/will contribute to SuMoMo from these languages DE, JP, IT, FR, CZ, NL, etc - <br />
host:rolandtanglao on irc ping him on #moz10, cell:+16047297924, roland AT mozillamessaging.com, Mozilla Messaging Technical Support Lead <br />
<br />
== QA & Support working hand in hand ==<br />
[http://etherpad.mozilla.com:9000/CV7WkIdVsx Organizing Thunderbird QA/Support Communities] - [[User:Tsk|Ludovic Hirlimann]] and Roland Tanglao (see SuMoMo above for contact info) will present ideas to organize support better to make support more effective worldwide as well as make support and QA work better together<br />
<br />
= Engineering Meetings =<br />
<br />
== IT, Labs/Services, Webdev collaboration ==<br />
<br />
Projects move back and forth among these groups throughout a projects' lifecycle, but there can be lots of bumps along the way.<br />
<br />
I'd like a meeting where people from these groups get together and we talk out ways to make everything move smoother. I guess the code phrase... to work together more like the web ;)<br />
<br />
Proposed time and place:<br />
<br />
* Suggestions? Put them in. First one with an opinion wins!<br />
<br />
Want to come (add yourself):<br />
<br />
* Ian Bicking<br />
* Les Orchard<br />
* Atul Varma<br />
* Pascal Finette<br />
* Zandr Milewski<br />
* Michael Coates<br />
<br />
== IT, RelEng: how to setup Build-VPN? ==<br />
<br />
We need restricted access to RelEng production systems. First attempt at Build-VPN was uncleanly specified, and doesn't work well. Fixing this is a joint IT/RelEng goal for Q3. <br />
<br />
Lets meet at whiteboard and brainstorm how to do this, before we start filing bugs and doing any work.<br />
<br />
Proposed time and place:<br />
<br />
* Suggestions? Put them in. First one with an opinion wins!<br />
<br />
Want to come (add yourself):<br />
<br />
<br />
== RelEng Brownbag - and RelEng Roast ==<br />
<br />
All you ever wanted to know about how the RelEng infrastructure works, and how you use it faster and more efficiently. Also, Q&A session to find suggestions for future improvements?<br />
<br />
At the December2009 allhands, there were a couple of "RelEng Roast" sessions at Academy of Science and at 650castro which people found quite useful. If you have gripes, pet peeves of things to fix or a wishlist of things you'd like to see added, this is the place.<br />
<br />
Proposed time and place:<br />
<br />
<br />
Want to come (add yourself):<br />
<br />
== RelEng, QA, Dev: How to Deal with Intermittent Oranges? ==<br />
<br />
Intermittent test failures (oranges) are still an issue, perhaps even more so now that we have brand-new 64-bit operating systems in play. <br />
<br />
Are people happy with brasstacks (http://brasstacks.mozilla.com/topfails/)? It seems to do most of the things we need to track intermittent test failures over time, but how many people are looking at it? At the risk of overburdening TBPL, do we need to link this info into TBPL somehow?<br />
<br />
On the RelEng side, we had/have the facility to re-run certain tests multiple times in a row, but we've had it disabled for a while since no one was looking at the results.<br />
<br />
<br />
Proposed time and place:<br />
<br />
<br />
Want to come (add yourself):<br />
Chris Cooper<br />
<br />
= Engagement Meetings =<br />
<br />
== PGP Signing party ==<br />
Idea is that mozilla contributors from all over the world are meeting. Some of us are using PGP on a daily basis - would be nice to sign / cross sign our keys.<br />
<br />
[[User:Tsk]] created a keyring on [http://biglumber.com/x/web?keyring=4739 biglumber], please add your key there , this will facilitate - the meeting and signing process, as printing the keyring will allow an easy, I've check this signature.<br />
<br />
If you have a pgp key consider joigning and add your key to the keyrrin (see above).<br />
<br />
Thursday July 8th 11:30 before the lightning talks. Meetpoint the lobby.<br />
<br />
See also: [http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html The Keysigning Party HOWTO]<br />
<br />
== CAcert Signing Party ==<br />
<br />
Assurers (please add your name if you want to assure) :<br />
* Bogomil Shopov<br />
* Iacopo Benesperi<br />
* Ludovic Hirlimann<br />
* Wolfgang Rosenauer<br />
* Karsten Düsterloh<br />
<br />
Thursday July 8th 13:45 - 14:15 Meetpoint , The lobby.</div>Dhermanhttps://wiki.mozilla.org/index.php?title=Build:TryServer&diff=232006Build:TryServer2010-06-21T04:20:57Z<p>Dherman: link to pending builds page</p>
<hr />
<div>= Try Server =<br />
The try server is an easy way to test a patch without actually checking the patch into the core repository. Your code will go through the same tests as a mozilla-central push, and you'll be able to download builds if you wish.<br />
<br />
To use try server, you need a [http://www.mozilla.org/hacking/committer/ Mozilla hg account] ([http://www.mozilla.org/hacking/commit-access-policy/ level 1] is sufficient).<br />
<br />
== How to push to try ==<br />
To submit a change to the try server:<br />
* For changes to mozilla-central or close enough (e.g. tracemonkey branch), you can <code>hg push -f ssh://hg.mozilla.org/try/</code> <br/>''or''<br/><code>hg push -f ssh://&lt;username@host@&gt;hg.mozilla.org/try/</code><br />
<br />
To see the results:<br />
* You'll get an email from each builder with results.<br />
* Look for your changeset on the [http://tinderbox.mozilla.org/showbuilds.cgi?tree=MozillaTry Try Tinderbox] or [http://tests.themasta.com/tinderboxpushlog/?tree=MozillaTry Try TBPL].<br />
* Compare Talos perf numbers using Pike's [http://github.com/Pike/talos-node talos-node].<br />
* Download your completed builds from [http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/?C=M;O=D firefox/tryserver-builds on ftp.m.o].<br />
<br />
If you're using [https://developer.mozilla.org/en/Mercurial_Queues Mercurial queues], the <code>push -f</code> command pushes any patches that are currently applied, and the Try server will build the result. (This is an awesome feature, not a bug!)<br />
<br />
You don’t need to clone or pull from the <code>try</code> repo, and you probably don’t want to. You’d get every half-baked changeset anybody ever tested.<br />
<br />
See [http://blog.mozilla.com/jorendorff/2008/08/18/push-to-try/ Jorendorff's blog] for more details.<br />
<br />
== Using a custom mozconfig ==<br />
If you want to use setting other than those in the default mozconfigs, you can push an '''extra file''' to the $topsrcdir:<br />
<br />
* '''mozconfig-extra''' with settings to be applied to all mozconfigs<br />
* '''mozconfig-extra-$platform''' to apply changes only to that platform's mozconfig<br />
<br />
The options you enable/disable in your custom mozconfig are '''appended''' to the existing config.<br />
<br />
The default mozconfigs used for tryserver builds are available in Hg: [http://hg.mozilla.org/build/buildbot-configs/file/default/mozilla2/ http://hg.mozilla.org/build/buildbot-configs/file/default/mozilla2/]$platform/tryserver ([http://hg.mozilla.org/build/buildbot-configs/file/default/mozilla2/linux/tryserver linux example])<br />
<br />
== Pending builds ==<br />
<br />
You can find information about pending builds and server load at http://build.mozilla.org/builds/pending/try.html .<br />
<br />
== Other Notes ==<br />
* Finished builds will be deleted after '''14 days'''. <br />
* Try repo is reset '''occasionally''', and you may not be able to use TBPL to see your test results after it has been reset.<br />
* If you have any problems please [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Release%20Engineering&status_whiteboard=tryserver file a bug]<br />
* Windows builds have symbols uploaded to http://build.mozilla.org/tryserver-symbols. Windbg and the Visual Studio debugger may use them to help debug crashing try server builds. Instructions for setting this up can be found here: http://developer.mozilla.org/en/docs/Using_the_Mozilla_symbol_server. Make sure you use the aforementioned URL instead of http://symbols.mozilla.org/firefox.<br />
<br />
* Suggestions for the future can be made [[Build:TryServer:Suggestions|here]]<br />
<br />
== Other Mozilla Try Servers ==<br />
* [https://wiki.mozilla.org/Thunderbird/Infrastructure/TryServer Thunderbird Try Server] for the comm-central repository<br />
* 1.9.2 try is coming soon ([https://bugzilla.mozilla.org/show_bug.cgi?id=563822 bug 563822])</div>Dhermanhttps://wiki.mozilla.org/index.php?title=JSInternProjects2010&diff=217125JSInternProjects20102010-04-20T20:58:21Z<p>Dherman: /* Proposed Intern Projects */</p>
<hr />
<div>=== Proposed Intern Projects ===<br />
<br />
* Lazy function parsing, pin parsed scripts in the HTTP cache to reduce latency where possible (the second piece might not be feasible without some major work). Compilation of prefetched scripts might fit in here.<br />
* Measure whether JSC-like ropes would help us out ([https://bugzilla.mozilla.org/show_bug.cgi?id=555395 bug 555395]) and, if that is hopeful, do it<br />
* Improve/import regexp compiler<br />
* Create JS microbenchmarking suite and analysis system, and also analyze competing implementation and look for needed improvements<br />
* Create "real-world" JS benchmark suite, possibly in collaboration with an intern at MSR<br />
<br />
* Scope chain rework for JM (see https://wiki.mozilla.org/JaegerMonkey#Major_Optimizations)<br />
* Globals reworking for JM (careful--this is high priority)<br />
* General JM work: adding compiler fast paths, perf testing<br />
* Collaborate with bhackett on type inference-based optimization<br />
<br />
* Revive Narcissus (minimize/eliminate dependence on compilation flags, improve perf)<br />
* Implement proposed Harmony features, or prototype in Narcissus</div>Dhermanhttps://wiki.mozilla.org/index.php?title=JavaScript:SpiderMonkey:Parser_API&diff=205049JavaScript:SpiderMonkey:Parser API2010-02-27T05:52:48Z<p>Dherman: </p>
<hr />
<div>== JavaScript API ==<br />
<br />
=== Design ===<br />
<br />
A general parsing API could treat the visitor interface from [http://code.google.com/p/es-lab/wiki/JsonMLASTFormat JsonMLAST] as a [http://en.wikipedia.org/wiki/Builder_pattern builder] with a parametric type. In Java-like pseudo-types:<br />
<br />
<pre><br />
interface Visitor<A> {<br />
visitThisExpr(attr : {}) : A;<br />
visitReturnStmt(attr : {},<br />
expr : A) : A;<br />
/* etc. */<br />
}<br />
</pre><br />
<br />
and take it as an optional argument to the constructor of a parser object:<br />
<br />
<pre><br />
class Parser<A> {<br />
Parser(builder : Visitor<A>?);<br />
<br />
parse(src : string,<br />
[filename : string?,<br />
startLine : (number >= 1)?,<br />
startColumn : (number >= 0)?])<br />
: A;<br />
}<br />
</pre><br />
<br />
This would allow the <code>parse</code> method to use the visitor as a way of injecting the parsed nodes into whatever type ''A'' the client wants. Making the argument optional makes it easy to default to the JsonMLAST format.<br />
<br />
It's a little messy (wrt types) to reuse the visitor interface for this, since the JsonMLAST visitor expects JsonMLAST values as arguments, whereas this use expects the type ''A'' as arguments. So it's maybe better to have a parallel "Builder" interface that's the same as the visitor interface but with buildXXXX methods instead:<br />
<br />
<pre><br />
interface Builder<A> {<br />
buildThisExpr(attr : {}) : A;<br />
buildReturnStmt(attr : {},<br />
expr : A) : A;<br />
/* etc. */<br />
}<br />
</pre><br />
<br />
<br />
Should also implement a JsonMLAST processor that takes a visitor:<br />
<br />
<pre><br />
processAST(ast : JsonMLAST,<br />
visitor : Visitor<A>) : A;<br />
</pre><br />
<br />
This could be implemented in pure JS, at least initially. (It'll be ugly without pattern matching, though.)<br />
<br />
=== Plan ===<br />
<br />
Several separate steps to make this work:<br />
<br />
*[https://bugzilla.mozilla.org/show_bug.cgi?id=548461 Bug 548461] -- refactor JSCompiler to JSSourceCompiler and JSAstCompiler (draft done, patch under review)<br />
*[https://bugzilla.mozilla.org/show_bug.cgi?id=533874 Bug 533874] -- implement marshalling to JsonMLAST (draft done, not quite ready for review)<br />
*implement source location information<br />
*generalize to take visitor (not started)<br />
*refactor to build on top of C++ API? (not started)<br />
<br />
[mailto:dherman@mozilla.com /dherman]<br />
<br />
== C++ API ==<br />
<br />
=== Brendan's notes ===<br />
<br />
Currently [http://lxr.mozilla.org/mozilla/source/js/src/jsparse.h jsparse.h] defines a <code>JSParseNode</code> struct, a variant record documented by the major comment before its declaration, and a few <code>JS_FRIEND_API</code> entry points for parsing and compiling, but not executing, token streams.<br />
<br />
There is interest, from the [http://groups.google.com/group/netscape.public.mozilla.jseng jseng newsgroup], in adding a <code>jsparseapi.[ch]</code> module to SpiderMonkey that exposes these parse-tree internals in a sustainable way. See [http://groups.google.com/group/netscape.public.mozilla.jseng/tree/browse_frm/thread/b60521be22b1747a/94a3564cbe78accd?rnum=1&_done=%2Fgroup%2Fnetscape.public.mozilla.jseng%2Fbrowse_frm%2Fthread%2Fb60521be22b1747a%2F94a3564cbe78accd%3F#doc_e17ac2982cf6d7fd my post] in [http://groups.google.com/group/netscape.public.mozilla.jseng/browse_frm/thread/b60521be22b1747a/94a3564cbe78accd#94a3564cbe78accd the thread] on this topic.<br />
<br />
In [http://groups.google.com/group/netscape.public.mozilla.jseng/tree/browse_frm/thread/b60521be22b1747a/94a3564cbe78accd?rnum=1&_done=%2Fgroup%2Fnetscape.public.mozilla.jseng%2Fbrowse_frm%2Fthread%2Fb60521be22b1747a%2F94a3564cbe78accd%3F#doc_766fd5323e92e054 a followup post], I talk about various APIs that could be used to glean information from the direct members of <code>JSParseNode</code>, but with a new <code>jsparseapi.h</code> interface, we would do better to use functions to hide all data types that are not already exposed via <code>jspubtd.h</code> and <code>jsapi.h</code>.<br />
<br />
The parse-tree API should expose a <code>JSParseTree</code> opaque struct type. This type represents a tree parsed from a token stream, or a subtree (even just one leaf node). We should not expose <code>JSTokenStream</code>, rather we should make API entry points such as<br />
<br />
<pre><br />
extern JS_PUBLIC_API(JSParseTree *)<br />
JS_ParseScript(JSContext *cx, const jschar *chars, size_t length,<br />
const char *filename, uintN lineno);<br />
</pre><br />
<br />
that returns <code>NULL</code> on failure and a pointer to a valid <code>ParseTree</code> on success.<br />
<br />
The API would consist of accessors only, no mutators. We might want an API modeled on the [http://en.wikipedia.org/wiki/Visitor_pattern visitor pattern]. So <code>JSParseTree</code> would be a <i>Visitable</i> and the API would introduce a <i>Visitor</i> interface (in the C callbacks or poor-man's vtable sense) for API clients to implement.<br />
<br />
Please feel free to add your design notes below.<br />
<br />
[mailto:brendan@mozilla.org /be]<br />
<br />
=== Kimman's Notes ===<br />
Work on this API originated from an email in the news group post by Jeremy. I volunteered to assist him and since then we have worked together on this. After getting a feel of the task at hand, we started work on a note outlining ideas for this API. Jeremy has been unable to devote time owing to other committments, and so I am posting this even though I have not had his comments on this note.<br />
<br />
==== Work Done So Far ====<br />
<br />
Based on the hints provided in Brendan's post, the following progress<br />
has been made :<br />
<br />
1. Parsing a script using js_ParseTokenStream<br />
<br />
2. Walking of the ParseNodes tree using recursion<br />
<br />
3. Implementation of a simple callback set (HaveNewSubTree,<br />
HaveNodeInTree, EndSubTree) that is called during the walking of the<br />
nodes. The structure used is :<br />
<pre><br />
typedef struct _JSParseNodeVisitor {<br />
NewParseNodeTree newnode;<br />
UseParseNode usenode;<br />
EndParseNodeTree endnode;<br />
void *data;<br />
} JSParseNodeVisitor;<br />
</pre><br />
This is not a proper implementation of the Visitor pattern but used as<br />
a simple starting point.<br />
<br />
4. Implementation of two sets of callbacks - the first that prints the<br />
contents of the nodes (not all node types have been done as yet) and<br />
the second that builds a frequency distribution for 'arity' of nodes,<br />
TOK_ constants and JS Opcodes.<br />
<br />
5. Implementation of a non-recursive walker making the same callbacks.<br />
<br />
==== About the ParserAPI ====<br />
<br />
Before implementing an API, it is essential to have the end-use in<br />
perspective, as well as to delineate clearly the boundaries of<br />
capabilities.<br />
<br />
First the boundaries: The ParserAPI will not evaluate the scripts.<br />
This will ensure that the API can be used on scripts for which object<br />
implementations are not available. For eg, debugger.js references an<br />
object jsd in its top level code. An attempt to evaluate the code will<br />
return an error.<br />
<br />
However, the ParserAPI should be able to allow a javascript function<br />
(that is compiled and evaluated) to be a user of the API. This could<br />
be achieved through a form of 'chaining' where the user of the API is<br />
an internal implementation that in turn invokes the real user<br />
implemented in JS.<br />
<br />
<br />
The idea of the ParserAPI emerged from an interest in a tool, like<br />
JavaDoc, to aid in documenting JS scripts and script collections. Some<br />
other potential uses for the API could be :<br />
<br />
<br />
A GUI application that allows a user to drill down a collection of JS<br />
ie the nodes of interest may differ depending on where the GUI is at<br />
that point in time, and secondly the ability to locate a parseNode and<br />
then continue the API usage from there. Eg, in the first pass, the GUI<br />
may display the source files and function names. When the user clicks<br />
a function, we then have to display the variables, functions called<br />
etc. The application would hold the ParseNode tree - when the user<br />
clicks the funciton, the application would locate that ParseNode and<br />
then start using our API from there.<br />
<br />
An application that wants to build a Calls/Called By kind of graph -<br />
they would use the API to parse the nodes and then build their own<br />
data structures.<br />
<br />
An application is complex and the user is reviewing the code - the API<br />
could be the foundation on which to build a simple search for usage<br />
kind of interface.<br />
<br />
During the initial 'getting-the-feel' work, simple Token Type and<br />
OpCode counting functions have been implemented as users of the API.<br />
This could help to identify a group of scripts that use all tokens and<br />
op codes - this could serve as a 'testing set' for JS engine builds.<br />
<br />
<br />
<br />
==== Design Ideas ====<br />
<br />
1. A user of the API should be able to control the extent of<br />
recursion. For eg, a user who is interested only in top level code and<br />
function definitions should be able to return a value from the<br />
'visitor' callback that will determine the next step for walking. So<br />
on receiving a FUNCTION during the walk, the callback could return a<br />
value that implies 'SKIP THE FUNCTION BODY'. Likewise, a callback<br />
could return a value saying 'STOP WALKING' eg the user found what they<br />
were looking for or decided they werent interested any longer.<br />
<br />
The callback should be able to inhibit the walking of the pn_next node in a given ParseNode.<br />
<br />
2. Related to the above, the API should be able to return a 'marker'<br />
for each node. The user of the API should be able to provide this<br />
marker at a subsequent point to determine the 'walk start' node. For<br />
implementations where GC is not an issue (eg a GUI application for documentation),<br />
this marker could be the 'NODE' pointer itself. Howevever, for other<br />
implementations the marker could be based on the BEGINPOS, ENDPOS<br />
available with each ParseNode.<br />
<br />
3. A single walk of the parse tree should be able to cater to multiple<br />
'visitors'. This is an idea I bring from the arena of image processing<br />
- while walking the contents of an image, different consumers are<br />
supported. At the end of walking, the application can query each<br />
consumer for information of interest. This has two advantages - the<br />
walking is done once, and consumer implementations can be simpler (and<br />
also easily reused). An application sets up the consumers, walks the<br />
contents and then queries each consumer for information. This<br />
information is aggregated / evaluated to determine the application's<br />
course of action.<br />
<br />
4. The Visitable/Visitor definition : I think the API should provide<br />
different types of these. At the 'lowest' level, the Visitor interface<br />
could include a callback for each type of ParseNode. At the next<br />
level, the Visitor interface could include some categorisation based<br />
on TOK_ types. This would seem to be like introducing a 'guide' interface ie the guide interface prepares the visitable which a vistor can visit.<br />
<br />
5. Reviewing the SpiderMonkey code, there are several places where this walker (as a 'js_friend') could be used eg js_FoldConstants, js_EmitTree, CheckSideEffects and some others. These functions currently use recursion and in some cases this recursion appears expensive. I am not sure whether the 'auhtors/maintainers' of these functions would find the code easily maintained if they were to switch to using this API.<br />
<br />
==== Other Issues ====<br />
<br />
1. The API should provide human readable descriptions for elements<br />
like JS OpCode and Parser Tokens. Currently, jsopcode.c is the only<br />
place in the JS code where the 'names' of JS op codes are available.<br />
These are defined in the file jsopcode.tbl. This file is included in<br />
jsopcode.h and jsopcode.c : in the .h file, only the numeric constants<br />
for the opcodes are included whereby the enumeration of the JS opcodes<br />
is exposed. In the .c file, the complete table is included which is<br />
used during disassembly. For the ParserAPI, a function should be added<br />
to jsopcode.c that would return a pointer to the name corresponding to<br />
a given JS Opcode. An option is that there is a public function<br />
exposed by the ParserAPI which in turn invokes a 'friend' function in<br />
jsopcode.c.<br />
<br />
2. Memory and GC : The starting point for the API will be to parse a<br />
script using js_ParseTokenStream. Upon successful parsing, the core<br />
functions of the API will be used ie walking the tree of parse nodes.<br />
During the use of the API, the memory allocated in the context temp<br />
arena pool must not be freed. This suggests when the API user has<br />
finished with the ParserAPI, they must call a function that will<br />
release the arena pool - this seems 'reasonable'. However, the API<br />
will also depend on GC not taking place so that atoms referenced in<br />
the different JSParseNodes will not get freed. During<br />
js_ParseTokenStream, atoms are protected from GC by using<br />
JS_KEEP_ATOMS. Upon completion of the parsing, JS_UNKEEP_ATOMS is<br />
called. One option is that after parsing is completed, JS_KEEP_ATOMS<br />
is called again and JS_UNKEEP_ATOMS is called in the same function<br />
when the arena pool is released.<br />
<br />
3. Folding of constants : When the parsing is completed successfully,<br />
js_FoldConstants is called. If I've understood this correctly,<br />
js_FoldConstants performs optimisation by resolving once expressions<br />
involving literals. A question that arises is whether, a user of the<br />
ParserAPI would prefer that this optimisation is not performed. For<br />
eg, a user of the API may be trying to identify the usage of a<br />
constant value that has been used as a literal in a collection of<br />
scripts - with the constants folded, the literals will not be visible<br />
via the ParserAPI. Similarly, a user of the API trying to find<br />
examples of usage of different operators may get an empty result set<br />
on account of the folding of constants.<br />
<br />
4. When an error occurs during parsing, it is necessary to report the<br />
error to the ErrorHandler callback if set in the context. The error is<br />
available in an Exception object. An issue to consider is whether the<br />
ParserAPI should aggregate all Warnings and make these available at<br />
the end of the parsing.<br />
<br />
5. Clarifications required on TOK_DEFSHARP and TOK_USESHARP. Also on<br />
#n=[], #n={..}, #n# and the like in the comments in jsparse.h.<br />
<br />
[mailto:bkimman@gmail.com /kimman]</div>Dhermanhttps://wiki.mozilla.org/index.php?title=JavaScript:SpiderMonkey:Parser_API&diff=205045JavaScript:SpiderMonkey:Parser API2010-02-27T05:48:03Z<p>Dherman: more cleanup of JS API</p>
<hr />
<div>== JavaScript API ==<br />
<br />
=== Design ===<br />
<br />
A general parsing API could treat the visitor interface from [http://code.google.com/p/es-lab/wiki/JsonMLASTFormat JsonMLAST] as a [http://en.wikipedia.org/wiki/Builder_pattern builder] with a parametric type. In Java-like pseudo-types:<br />
<br />
<pre><br />
interface Visitor<A> {<br />
visitThisExpr(attr : {}) : A;<br />
visitReturnStmt(attr : {},<br />
expr : A) : A;<br />
/* etc. */<br />
}<br />
</pre><br />
<br />
and take it as an optional argument to the constructor of a parser object:<br />
<br />
<pre><br />
class Parser<A> {<br />
Parser(builder : Visitor<A>?);<br />
<br />
parse(src : string,<br />
[filename : string?,<br />
startLine : (number >= 1)?,<br />
startColumn : (number >= 0)?])<br />
: A;<br />
}<br />
</pre><br />
<br />
This would allow the <code>parse</code> method to use the visitor as a way of injecting the parsed nodes into whatever type ''A'' the client wants. Making the argument optional makes it easy to default to the JsonMLAST format.<br />
<br />
It's a little messy (wrt types) to reuse the visitor interface for this, since the JsonMLAST visitor expects JsonMLAST values as arguments, whereas this use expects the type ''A'' as arguments. So it's maybe better to have a parallel "Builder" interface that's the same as the visitor interface but with buildXXXX methods instead:<br />
<br />
<pre><br />
interface Builder<A> {<br />
buildThisExpr(attr : {}) : A;<br />
buildReturnStmt(attr : {},<br />
expr : A) : A;<br />
/* etc. */<br />
}<br />
</pre><br />
<br />
<br />
Should also implement a JsonMLAST processor that takes a visitor:<br />
<br />
<pre><br />
processAST(ast : JsonMLAST,<br />
visitor : Visitor<A>) : A;<br />
</pre><br />
<br />
This could be implemented in pure JS, at least initially. (It'll be ugly without pattern matching, though.)<br />
<br />
=== Plan ===<br />
<br />
Several separate steps to make this work:<br />
<br />
*[https://bugzilla.mozilla.org/show_bug.cgi?id=548461 Bug 548461] -- refactor JSCompiler to JSSourceCompiler and JSAstCompiler (draft done, patch under review)<br />
*[https://bugzilla.mozilla.org/show_bug.cgi?id=533874 Bug 533874] -- implement marshalling to JsonMLAST (draft done, not quite ready for review)<br />
*generalize to take visitor (not started)<br />
*refactor to build on top of C++ API? (not started)<br />
<br />
[mailto:dherman@mozilla.com /dherman]<br />
<br />
== C++ API ==<br />
<br />
=== Brendan's notes ===<br />
<br />
Currently [http://lxr.mozilla.org/mozilla/source/js/src/jsparse.h jsparse.h] defines a <code>JSParseNode</code> struct, a variant record documented by the major comment before its declaration, and a few <code>JS_FRIEND_API</code> entry points for parsing and compiling, but not executing, token streams.<br />
<br />
There is interest, from the [http://groups.google.com/group/netscape.public.mozilla.jseng jseng newsgroup], in adding a <code>jsparseapi.[ch]</code> module to SpiderMonkey that exposes these parse-tree internals in a sustainable way. See [http://groups.google.com/group/netscape.public.mozilla.jseng/tree/browse_frm/thread/b60521be22b1747a/94a3564cbe78accd?rnum=1&_done=%2Fgroup%2Fnetscape.public.mozilla.jseng%2Fbrowse_frm%2Fthread%2Fb60521be22b1747a%2F94a3564cbe78accd%3F#doc_e17ac2982cf6d7fd my post] in [http://groups.google.com/group/netscape.public.mozilla.jseng/browse_frm/thread/b60521be22b1747a/94a3564cbe78accd#94a3564cbe78accd the thread] on this topic.<br />
<br />
In [http://groups.google.com/group/netscape.public.mozilla.jseng/tree/browse_frm/thread/b60521be22b1747a/94a3564cbe78accd?rnum=1&_done=%2Fgroup%2Fnetscape.public.mozilla.jseng%2Fbrowse_frm%2Fthread%2Fb60521be22b1747a%2F94a3564cbe78accd%3F#doc_766fd5323e92e054 a followup post], I talk about various APIs that could be used to glean information from the direct members of <code>JSParseNode</code>, but with a new <code>jsparseapi.h</code> interface, we would do better to use functions to hide all data types that are not already exposed via <code>jspubtd.h</code> and <code>jsapi.h</code>.<br />
<br />
The parse-tree API should expose a <code>JSParseTree</code> opaque struct type. This type represents a tree parsed from a token stream, or a subtree (even just one leaf node). We should not expose <code>JSTokenStream</code>, rather we should make API entry points such as<br />
<br />
<pre><br />
extern JS_PUBLIC_API(JSParseTree *)<br />
JS_ParseScript(JSContext *cx, const jschar *chars, size_t length,<br />
const char *filename, uintN lineno);<br />
</pre><br />
<br />
that returns <code>NULL</code> on failure and a pointer to a valid <code>ParseTree</code> on success.<br />
<br />
The API would consist of accessors only, no mutators. We might want an API modeled on the [http://en.wikipedia.org/wiki/Visitor_pattern visitor pattern]. So <code>JSParseTree</code> would be a <i>Visitable</i> and the API would introduce a <i>Visitor</i> interface (in the C callbacks or poor-man's vtable sense) for API clients to implement.<br />
<br />
Please feel free to add your design notes below.<br />
<br />
[mailto:brendan@mozilla.org /be]<br />
<br />
=== Kimman's Notes ===<br />
Work on this API originated from an email in the news group post by Jeremy. I volunteered to assist him and since then we have worked together on this. After getting a feel of the task at hand, we started work on a note outlining ideas for this API. Jeremy has been unable to devote time owing to other committments, and so I am posting this even though I have not had his comments on this note.<br />
<br />
==== Work Done So Far ====<br />
<br />
Based on the hints provided in Brendan's post, the following progress<br />
has been made :<br />
<br />
1. Parsing a script using js_ParseTokenStream<br />
<br />
2. Walking of the ParseNodes tree using recursion<br />
<br />
3. Implementation of a simple callback set (HaveNewSubTree,<br />
HaveNodeInTree, EndSubTree) that is called during the walking of the<br />
nodes. The structure used is :<br />
<pre><br />
typedef struct _JSParseNodeVisitor {<br />
NewParseNodeTree newnode;<br />
UseParseNode usenode;<br />
EndParseNodeTree endnode;<br />
void *data;<br />
} JSParseNodeVisitor;<br />
</pre><br />
This is not a proper implementation of the Visitor pattern but used as<br />
a simple starting point.<br />
<br />
4. Implementation of two sets of callbacks - the first that prints the<br />
contents of the nodes (not all node types have been done as yet) and<br />
the second that builds a frequency distribution for 'arity' of nodes,<br />
TOK_ constants and JS Opcodes.<br />
<br />
5. Implementation of a non-recursive walker making the same callbacks.<br />
<br />
==== About the ParserAPI ====<br />
<br />
Before implementing an API, it is essential to have the end-use in<br />
perspective, as well as to delineate clearly the boundaries of<br />
capabilities.<br />
<br />
First the boundaries: The ParserAPI will not evaluate the scripts.<br />
This will ensure that the API can be used on scripts for which object<br />
implementations are not available. For eg, debugger.js references an<br />
object jsd in its top level code. An attempt to evaluate the code will<br />
return an error.<br />
<br />
However, the ParserAPI should be able to allow a javascript function<br />
(that is compiled and evaluated) to be a user of the API. This could<br />
be achieved through a form of 'chaining' where the user of the API is<br />
an internal implementation that in turn invokes the real user<br />
implemented in JS.<br />
<br />
<br />
The idea of the ParserAPI emerged from an interest in a tool, like<br />
JavaDoc, to aid in documenting JS scripts and script collections. Some<br />
other potential uses for the API could be :<br />
<br />
<br />
A GUI application that allows a user to drill down a collection of JS<br />
ie the nodes of interest may differ depending on where the GUI is at<br />
that point in time, and secondly the ability to locate a parseNode and<br />
then continue the API usage from there. Eg, in the first pass, the GUI<br />
may display the source files and function names. When the user clicks<br />
a function, we then have to display the variables, functions called<br />
etc. The application would hold the ParseNode tree - when the user<br />
clicks the funciton, the application would locate that ParseNode and<br />
then start using our API from there.<br />
<br />
An application that wants to build a Calls/Called By kind of graph -<br />
they would use the API to parse the nodes and then build their own<br />
data structures.<br />
<br />
An application is complex and the user is reviewing the code - the API<br />
could be the foundation on which to build a simple search for usage<br />
kind of interface.<br />
<br />
During the initial 'getting-the-feel' work, simple Token Type and<br />
OpCode counting functions have been implemented as users of the API.<br />
This could help to identify a group of scripts that use all tokens and<br />
op codes - this could serve as a 'testing set' for JS engine builds.<br />
<br />
<br />
<br />
==== Design Ideas ====<br />
<br />
1. A user of the API should be able to control the extent of<br />
recursion. For eg, a user who is interested only in top level code and<br />
function definitions should be able to return a value from the<br />
'visitor' callback that will determine the next step for walking. So<br />
on receiving a FUNCTION during the walk, the callback could return a<br />
value that implies 'SKIP THE FUNCTION BODY'. Likewise, a callback<br />
could return a value saying 'STOP WALKING' eg the user found what they<br />
were looking for or decided they werent interested any longer.<br />
<br />
The callback should be able to inhibit the walking of the pn_next node in a given ParseNode.<br />
<br />
2. Related to the above, the API should be able to return a 'marker'<br />
for each node. The user of the API should be able to provide this<br />
marker at a subsequent point to determine the 'walk start' node. For<br />
implementations where GC is not an issue (eg a GUI application for documentation),<br />
this marker could be the 'NODE' pointer itself. Howevever, for other<br />
implementations the marker could be based on the BEGINPOS, ENDPOS<br />
available with each ParseNode.<br />
<br />
3. A single walk of the parse tree should be able to cater to multiple<br />
'visitors'. This is an idea I bring from the arena of image processing<br />
- while walking the contents of an image, different consumers are<br />
supported. At the end of walking, the application can query each<br />
consumer for information of interest. This has two advantages - the<br />
walking is done once, and consumer implementations can be simpler (and<br />
also easily reused). An application sets up the consumers, walks the<br />
contents and then queries each consumer for information. This<br />
information is aggregated / evaluated to determine the application's<br />
course of action.<br />
<br />
4. The Visitable/Visitor definition : I think the API should provide<br />
different types of these. At the 'lowest' level, the Visitor interface<br />
could include a callback for each type of ParseNode. At the next<br />
level, the Visitor interface could include some categorisation based<br />
on TOK_ types. This would seem to be like introducing a 'guide' interface ie the guide interface prepares the visitable which a vistor can visit.<br />
<br />
5. Reviewing the SpiderMonkey code, there are several places where this walker (as a 'js_friend') could be used eg js_FoldConstants, js_EmitTree, CheckSideEffects and some others. These functions currently use recursion and in some cases this recursion appears expensive. I am not sure whether the 'auhtors/maintainers' of these functions would find the code easily maintained if they were to switch to using this API.<br />
<br />
==== Other Issues ====<br />
<br />
1. The API should provide human readable descriptions for elements<br />
like JS OpCode and Parser Tokens. Currently, jsopcode.c is the only<br />
place in the JS code where the 'names' of JS op codes are available.<br />
These are defined in the file jsopcode.tbl. This file is included in<br />
jsopcode.h and jsopcode.c : in the .h file, only the numeric constants<br />
for the opcodes are included whereby the enumeration of the JS opcodes<br />
is exposed. In the .c file, the complete table is included which is<br />
used during disassembly. For the ParserAPI, a function should be added<br />
to jsopcode.c that would return a pointer to the name corresponding to<br />
a given JS Opcode. An option is that there is a public function<br />
exposed by the ParserAPI which in turn invokes a 'friend' function in<br />
jsopcode.c.<br />
<br />
2. Memory and GC : The starting point for the API will be to parse a<br />
script using js_ParseTokenStream. Upon successful parsing, the core<br />
functions of the API will be used ie walking the tree of parse nodes.<br />
During the use of the API, the memory allocated in the context temp<br />
arena pool must not be freed. This suggests when the API user has<br />
finished with the ParserAPI, they must call a function that will<br />
release the arena pool - this seems 'reasonable'. However, the API<br />
will also depend on GC not taking place so that atoms referenced in<br />
the different JSParseNodes will not get freed. During<br />
js_ParseTokenStream, atoms are protected from GC by using<br />
JS_KEEP_ATOMS. Upon completion of the parsing, JS_UNKEEP_ATOMS is<br />
called. One option is that after parsing is completed, JS_KEEP_ATOMS<br />
is called again and JS_UNKEEP_ATOMS is called in the same function<br />
when the arena pool is released.<br />
<br />
3. Folding of constants : When the parsing is completed successfully,<br />
js_FoldConstants is called. If I've understood this correctly,<br />
js_FoldConstants performs optimisation by resolving once expressions<br />
involving literals. A question that arises is whether, a user of the<br />
ParserAPI would prefer that this optimisation is not performed. For<br />
eg, a user of the API may be trying to identify the usage of a<br />
constant value that has been used as a literal in a collection of<br />
scripts - with the constants folded, the literals will not be visible<br />
via the ParserAPI. Similarly, a user of the API trying to find<br />
examples of usage of different operators may get an empty result set<br />
on account of the folding of constants.<br />
<br />
4. When an error occurs during parsing, it is necessary to report the<br />
error to the ErrorHandler callback if set in the context. The error is<br />
available in an Exception object. An issue to consider is whether the<br />
ParserAPI should aggregate all Warnings and make these available at<br />
the end of the parsing.<br />
<br />
5. Clarifications required on TOK_DEFSHARP and TOK_USESHARP. Also on<br />
#n=[], #n={..}, #n# and the like in the comments in jsparse.h.<br />
<br />
[mailto:bkimman@gmail.com /kimman]</div>Dhermanhttps://wiki.mozilla.org/index.php?title=JavaScript:SpiderMonkey:Parser_API&diff=205042JavaScript:SpiderMonkey:Parser API2010-02-27T05:39:39Z<p>Dherman: fixed up types a little bit</p>
<hr />
<div>== JavaScript API ==<br />
<br />
=== Design ===<br />
<br />
A general parsing API could treat the visitor interface from [http://code.google.com/p/es-lab/wiki/JsonMLASTFormat JsonMLAST] as a factory with a parametric type. In Java-like pseudo-types:<br />
<br />
<pre><br />
interface Visitor<A> {<br />
visitThisExpr(attr : {}) : A;<br />
visitReturnStmt(attr : {},<br />
expr : A) : A;<br />
/* etc. */<br />
}<br />
</pre><br />
<br />
and take it as an optional argument to the constructor of a parser object:<br />
<br />
<pre><br />
class Parser<A> {<br />
Parser(factory : Visitor<A>?);<br />
<br />
parse(src : string,<br />
[filename : string?,<br />
startLine : (number >= 1)?,<br />
startColumn : (number >= 0)?])<br />
: A;<br />
}<br />
</pre><br />
<br />
This would allow the <code>parse</code> method to use the visitor as a way of injecting the parsed nodes into whatever type ''A'' the client wants. Making the argument optional makes it easy to default to the JsonMLAST format.<br />
<br />
It's a little messy (wrt types) to reuse the visitor interface for this, since the JsonMLAST visitor expects JsonMLAST values as arguments, whereas this use expects the type ''A'' as arguments. So it's maybe better to have a parallel "Factory" interface that's the same as the visitor interface but with createXXXX methods instead.<br />
<br />
Should also implement a JsonMLAST processor that takes a visitor:<br />
<br />
<pre><br />
processJsonMLAST(ast : JsonMLAST,<br />
visitor : Visitor<A>) : A;<br />
</pre><br />
<br />
This could be implemented in pure JS, at least initially. (It'll be ugly without pattern matching, though.)<br />
<br />
I dislike the verbosity of the JsonMLAST name. Maybe just AST is good enough.<br />
<br />
=== Plan ===<br />
<br />
Several separate steps to make this work:<br />
<br />
*[https://bugzilla.mozilla.org/show_bug.cgi?id=548461 Bug 548461] -- refactor JSCompiler to JSSourceCompiler and JSAstCompiler (draft done, patch under review)<br />
*[https://bugzilla.mozilla.org/show_bug.cgi?id=533874 Bug 533874] -- implement marshalling to JsonMLAST (draft done, not quite ready for review)<br />
*generalize to take visitor (not started)<br />
*refactor to build on top of C++ API? (not started)<br />
<br />
[mailto:dherman@mozilla.com /dherman]<br />
<br />
== C++ API ==<br />
<br />
=== Brendan's notes ===<br />
<br />
Currently [http://lxr.mozilla.org/mozilla/source/js/src/jsparse.h jsparse.h] defines a <code>JSParseNode</code> struct, a variant record documented by the major comment before its declaration, and a few <code>JS_FRIEND_API</code> entry points for parsing and compiling, but not executing, token streams.<br />
<br />
There is interest, from the [http://groups.google.com/group/netscape.public.mozilla.jseng jseng newsgroup], in adding a <code>jsparseapi.[ch]</code> module to SpiderMonkey that exposes these parse-tree internals in a sustainable way. See [http://groups.google.com/group/netscape.public.mozilla.jseng/tree/browse_frm/thread/b60521be22b1747a/94a3564cbe78accd?rnum=1&_done=%2Fgroup%2Fnetscape.public.mozilla.jseng%2Fbrowse_frm%2Fthread%2Fb60521be22b1747a%2F94a3564cbe78accd%3F#doc_e17ac2982cf6d7fd my post] in [http://groups.google.com/group/netscape.public.mozilla.jseng/browse_frm/thread/b60521be22b1747a/94a3564cbe78accd#94a3564cbe78accd the thread] on this topic.<br />
<br />
In [http://groups.google.com/group/netscape.public.mozilla.jseng/tree/browse_frm/thread/b60521be22b1747a/94a3564cbe78accd?rnum=1&_done=%2Fgroup%2Fnetscape.public.mozilla.jseng%2Fbrowse_frm%2Fthread%2Fb60521be22b1747a%2F94a3564cbe78accd%3F#doc_766fd5323e92e054 a followup post], I talk about various APIs that could be used to glean information from the direct members of <code>JSParseNode</code>, but with a new <code>jsparseapi.h</code> interface, we would do better to use functions to hide all data types that are not already exposed via <code>jspubtd.h</code> and <code>jsapi.h</code>.<br />
<br />
The parse-tree API should expose a <code>JSParseTree</code> opaque struct type. This type represents a tree parsed from a token stream, or a subtree (even just one leaf node). We should not expose <code>JSTokenStream</code>, rather we should make API entry points such as<br />
<br />
<pre><br />
extern JS_PUBLIC_API(JSParseTree *)<br />
JS_ParseScript(JSContext *cx, const jschar *chars, size_t length,<br />
const char *filename, uintN lineno);<br />
</pre><br />
<br />
that returns <code>NULL</code> on failure and a pointer to a valid <code>ParseTree</code> on success.<br />
<br />
The API would consist of accessors only, no mutators. We might want an API modeled on the [http://en.wikipedia.org/wiki/Visitor_pattern visitor pattern]. So <code>JSParseTree</code> would be a <i>Visitable</i> and the API would introduce a <i>Visitor</i> interface (in the C callbacks or poor-man's vtable sense) for API clients to implement.<br />
<br />
Please feel free to add your design notes below.<br />
<br />
[mailto:brendan@mozilla.org /be]<br />
<br />
=== Kimman's Notes ===<br />
Work on this API originated from an email in the news group post by Jeremy. I volunteered to assist him and since then we have worked together on this. After getting a feel of the task at hand, we started work on a note outlining ideas for this API. Jeremy has been unable to devote time owing to other committments, and so I am posting this even though I have not had his comments on this note.<br />
<br />
==== Work Done So Far ====<br />
<br />
Based on the hints provided in Brendan's post, the following progress<br />
has been made :<br />
<br />
1. Parsing a script using js_ParseTokenStream<br />
<br />
2. Walking of the ParseNodes tree using recursion<br />
<br />
3. Implementation of a simple callback set (HaveNewSubTree,<br />
HaveNodeInTree, EndSubTree) that is called during the walking of the<br />
nodes. The structure used is :<br />
<pre><br />
typedef struct _JSParseNodeVisitor {<br />
NewParseNodeTree newnode;<br />
UseParseNode usenode;<br />
EndParseNodeTree endnode;<br />
void *data;<br />
} JSParseNodeVisitor;<br />
</pre><br />
This is not a proper implementation of the Visitor pattern but used as<br />
a simple starting point.<br />
<br />
4. Implementation of two sets of callbacks - the first that prints the<br />
contents of the nodes (not all node types have been done as yet) and<br />
the second that builds a frequency distribution for 'arity' of nodes,<br />
TOK_ constants and JS Opcodes.<br />
<br />
5. Implementation of a non-recursive walker making the same callbacks.<br />
<br />
==== About the ParserAPI ====<br />
<br />
Before implementing an API, it is essential to have the end-use in<br />
perspective, as well as to delineate clearly the boundaries of<br />
capabilities.<br />
<br />
First the boundaries: The ParserAPI will not evaluate the scripts.<br />
This will ensure that the API can be used on scripts for which object<br />
implementations are not available. For eg, debugger.js references an<br />
object jsd in its top level code. An attempt to evaluate the code will<br />
return an error.<br />
<br />
However, the ParserAPI should be able to allow a javascript function<br />
(that is compiled and evaluated) to be a user of the API. This could<br />
be achieved through a form of 'chaining' where the user of the API is<br />
an internal implementation that in turn invokes the real user<br />
implemented in JS.<br />
<br />
<br />
The idea of the ParserAPI emerged from an interest in a tool, like<br />
JavaDoc, to aid in documenting JS scripts and script collections. Some<br />
other potential uses for the API could be :<br />
<br />
<br />
A GUI application that allows a user to drill down a collection of JS<br />
ie the nodes of interest may differ depending on where the GUI is at<br />
that point in time, and secondly the ability to locate a parseNode and<br />
then continue the API usage from there. Eg, in the first pass, the GUI<br />
may display the source files and function names. When the user clicks<br />
a function, we then have to display the variables, functions called<br />
etc. The application would hold the ParseNode tree - when the user<br />
clicks the funciton, the application would locate that ParseNode and<br />
then start using our API from there.<br />
<br />
An application that wants to build a Calls/Called By kind of graph -<br />
they would use the API to parse the nodes and then build their own<br />
data structures.<br />
<br />
An application is complex and the user is reviewing the code - the API<br />
could be the foundation on which to build a simple search for usage<br />
kind of interface.<br />
<br />
During the initial 'getting-the-feel' work, simple Token Type and<br />
OpCode counting functions have been implemented as users of the API.<br />
This could help to identify a group of scripts that use all tokens and<br />
op codes - this could serve as a 'testing set' for JS engine builds.<br />
<br />
<br />
<br />
==== Design Ideas ====<br />
<br />
1. A user of the API should be able to control the extent of<br />
recursion. For eg, a user who is interested only in top level code and<br />
function definitions should be able to return a value from the<br />
'visitor' callback that will determine the next step for walking. So<br />
on receiving a FUNCTION during the walk, the callback could return a<br />
value that implies 'SKIP THE FUNCTION BODY'. Likewise, a callback<br />
could return a value saying 'STOP WALKING' eg the user found what they<br />
were looking for or decided they werent interested any longer.<br />
<br />
The callback should be able to inhibit the walking of the pn_next node in a given ParseNode.<br />
<br />
2. Related to the above, the API should be able to return a 'marker'<br />
for each node. The user of the API should be able to provide this<br />
marker at a subsequent point to determine the 'walk start' node. For<br />
implementations where GC is not an issue (eg a GUI application for documentation),<br />
this marker could be the 'NODE' pointer itself. Howevever, for other<br />
implementations the marker could be based on the BEGINPOS, ENDPOS<br />
available with each ParseNode.<br />
<br />
3. A single walk of the parse tree should be able to cater to multiple<br />
'visitors'. This is an idea I bring from the arena of image processing<br />
- while walking the contents of an image, different consumers are<br />
supported. At the end of walking, the application can query each<br />
consumer for information of interest. This has two advantages - the<br />
walking is done once, and consumer implementations can be simpler (and<br />
also easily reused). An application sets up the consumers, walks the<br />
contents and then queries each consumer for information. This<br />
information is aggregated / evaluated to determine the application's<br />
course of action.<br />
<br />
4. The Visitable/Visitor definition : I think the API should provide<br />
different types of these. At the 'lowest' level, the Visitor interface<br />
could include a callback for each type of ParseNode. At the next<br />
level, the Visitor interface could include some categorisation based<br />
on TOK_ types. This would seem to be like introducing a 'guide' interface ie the guide interface prepares the visitable which a vistor can visit.<br />
<br />
5. Reviewing the SpiderMonkey code, there are several places where this walker (as a 'js_friend') could be used eg js_FoldConstants, js_EmitTree, CheckSideEffects and some others. These functions currently use recursion and in some cases this recursion appears expensive. I am not sure whether the 'auhtors/maintainers' of these functions would find the code easily maintained if they were to switch to using this API.<br />
<br />
==== Other Issues ====<br />
<br />
1. The API should provide human readable descriptions for elements<br />
like JS OpCode and Parser Tokens. Currently, jsopcode.c is the only<br />
place in the JS code where the 'names' of JS op codes are available.<br />
These are defined in the file jsopcode.tbl. This file is included in<br />
jsopcode.h and jsopcode.c : in the .h file, only the numeric constants<br />
for the opcodes are included whereby the enumeration of the JS opcodes<br />
is exposed. In the .c file, the complete table is included which is<br />
used during disassembly. For the ParserAPI, a function should be added<br />
to jsopcode.c that would return a pointer to the name corresponding to<br />
a given JS Opcode. An option is that there is a public function<br />
exposed by the ParserAPI which in turn invokes a 'friend' function in<br />
jsopcode.c.<br />
<br />
2. Memory and GC : The starting point for the API will be to parse a<br />
script using js_ParseTokenStream. Upon successful parsing, the core<br />
functions of the API will be used ie walking the tree of parse nodes.<br />
During the use of the API, the memory allocated in the context temp<br />
arena pool must not be freed. This suggests when the API user has<br />
finished with the ParserAPI, they must call a function that will<br />
release the arena pool - this seems 'reasonable'. However, the API<br />
will also depend on GC not taking place so that atoms referenced in<br />
the different JSParseNodes will not get freed. During<br />
js_ParseTokenStream, atoms are protected from GC by using<br />
JS_KEEP_ATOMS. Upon completion of the parsing, JS_UNKEEP_ATOMS is<br />
called. One option is that after parsing is completed, JS_KEEP_ATOMS<br />
is called again and JS_UNKEEP_ATOMS is called in the same function<br />
when the arena pool is released.<br />
<br />
3. Folding of constants : When the parsing is completed successfully,<br />
js_FoldConstants is called. If I've understood this correctly,<br />
js_FoldConstants performs optimisation by resolving once expressions<br />
involving literals. A question that arises is whether, a user of the<br />
ParserAPI would prefer that this optimisation is not performed. For<br />
eg, a user of the API may be trying to identify the usage of a<br />
constant value that has been used as a literal in a collection of<br />
scripts - with the constants folded, the literals will not be visible<br />
via the ParserAPI. Similarly, a user of the API trying to find<br />
examples of usage of different operators may get an empty result set<br />
on account of the folding of constants.<br />
<br />
4. When an error occurs during parsing, it is necessary to report the<br />
error to the ErrorHandler callback if set in the context. The error is<br />
available in an Exception object. An issue to consider is whether the<br />
ParserAPI should aggregate all Warnings and make these available at<br />
the end of the parsing.<br />
<br />
5. Clarifications required on TOK_DEFSHARP and TOK_USESHARP. Also on<br />
#n=[], #n={..}, #n# and the like in the comments in jsparse.h.<br />
<br />
[mailto:bkimman@gmail.com /kimman]</div>Dhermanhttps://wiki.mozilla.org/index.php?title=JavaScript:SpiderMonkey:Parser_API&diff=204983JavaScript:SpiderMonkey:Parser API2010-02-26T21:43:39Z<p>Dherman: a couple more notes</p>
<hr />
<div>== JavaScript API ==<br />
<br />
=== Design ===<br />
<br />
A general parsing API could treat the visitor interface from [http://code.google.com/p/es-lab/wiki/JsonMLASTFormat JsonMLAST] as a factory with a parametric type. In Java-like pseudo-types:<br />
<br />
<pre><br />
interface Visitor<A> {<br />
visitThisExpr(attr : {}) : A;<br />
/* etc. */<br />
}<br />
</pre><br />
<br />
and take it as an optional argument to the constructor of a parser object:<br />
<br />
<pre><br />
class Parser<A, Visitor> {<br />
Parser(factory : Visitor<A>?);<br />
<br />
parse(src : string,<br />
[filename : string | null,<br />
startLine : (number >= 1)?,<br />
startColumn : (number >= 0)?])<br />
: A;<br />
}<br />
</pre><br />
<br />
This would allow the <code>parse</code> method to use the visitor as a way of injecting the parsed nodes into whatever type ''A'' the client wants. Making the argument optional makes it easy to default to the JsonMLAST format.<br />
<br />
It's a little messy (wrt types) to reuse the visitor interface for this, since the JsonMLAST visitor expects JsonMLAST values as arguments, whereas this use expects the type ''A'' as arguments. So it's maybe better to have a parallel "Factory" interface that's the same as the visitor interface but with createXXXX methods instead.<br />
<br />
Should also implement a JsonMLAST processor that takes a visitor:<br />
<br />
<pre><br />
processJsonMLAST(ast : JsonMLAST,<br />
visitor : Visitor<A>) : A;<br />
</pre><br />
<br />
This could be implemented in pure JS, at least initially. (It'll be ugly without pattern matching, though.)<br />
<br />
I dislike the verbosity of the JsonMLAST name. Maybe just AST is good enough.<br />
<br />
=== Plan ===<br />
<br />
Several separate steps to make this work:<br />
<br />
*[https://bugzilla.mozilla.org/show_bug.cgi?id=548461 Bug 548461] -- refactor JSCompiler to JSSourceCompiler and JSAstCompiler (draft done, patch under review)<br />
*[https://bugzilla.mozilla.org/show_bug.cgi?id=533874 Bug 533874] -- implement marshalling to JsonMLAST (draft done, not quite ready for review)<br />
*generalize to take visitor (not started)<br />
*refactor to build on top of C++ API? (not started)<br />
<br />
[mailto:dherman@mozilla.com /dherman]<br />
<br />
== C++ API ==<br />
<br />
=== Brendan's notes ===<br />
<br />
Currently [http://lxr.mozilla.org/mozilla/source/js/src/jsparse.h jsparse.h] defines a <code>JSParseNode</code> struct, a variant record documented by the major comment before its declaration, and a few <code>JS_FRIEND_API</code> entry points for parsing and compiling, but not executing, token streams.<br />
<br />
There is interest, from the [http://groups.google.com/group/netscape.public.mozilla.jseng jseng newsgroup], in adding a <code>jsparseapi.[ch]</code> module to SpiderMonkey that exposes these parse-tree internals in a sustainable way. See [http://groups.google.com/group/netscape.public.mozilla.jseng/tree/browse_frm/thread/b60521be22b1747a/94a3564cbe78accd?rnum=1&_done=%2Fgroup%2Fnetscape.public.mozilla.jseng%2Fbrowse_frm%2Fthread%2Fb60521be22b1747a%2F94a3564cbe78accd%3F#doc_e17ac2982cf6d7fd my post] in [http://groups.google.com/group/netscape.public.mozilla.jseng/browse_frm/thread/b60521be22b1747a/94a3564cbe78accd#94a3564cbe78accd the thread] on this topic.<br />
<br />
In [http://groups.google.com/group/netscape.public.mozilla.jseng/tree/browse_frm/thread/b60521be22b1747a/94a3564cbe78accd?rnum=1&_done=%2Fgroup%2Fnetscape.public.mozilla.jseng%2Fbrowse_frm%2Fthread%2Fb60521be22b1747a%2F94a3564cbe78accd%3F#doc_766fd5323e92e054 a followup post], I talk about various APIs that could be used to glean information from the direct members of <code>JSParseNode</code>, but with a new <code>jsparseapi.h</code> interface, we would do better to use functions to hide all data types that are not already exposed via <code>jspubtd.h</code> and <code>jsapi.h</code>.<br />
<br />
The parse-tree API should expose a <code>JSParseTree</code> opaque struct type. This type represents a tree parsed from a token stream, or a subtree (even just one leaf node). We should not expose <code>JSTokenStream</code>, rather we should make API entry points such as<br />
<br />
<pre><br />
extern JS_PUBLIC_API(JSParseTree *)<br />
JS_ParseScript(JSContext *cx, const jschar *chars, size_t length,<br />
const char *filename, uintN lineno);<br />
</pre><br />
<br />
that returns <code>NULL</code> on failure and a pointer to a valid <code>ParseTree</code> on success.<br />
<br />
The API would consist of accessors only, no mutators. We might want an API modeled on the [http://en.wikipedia.org/wiki/Visitor_pattern visitor pattern]. So <code>JSParseTree</code> would be a <i>Visitable</i> and the API would introduce a <i>Visitor</i> interface (in the C callbacks or poor-man's vtable sense) for API clients to implement.<br />
<br />
Please feel free to add your design notes below.<br />
<br />
[mailto:brendan@mozilla.org /be]<br />
<br />
=== Kimman's Notes ===<br />
Work on this API originated from an email in the news group post by Jeremy. I volunteered to assist him and since then we have worked together on this. After getting a feel of the task at hand, we started work on a note outlining ideas for this API. Jeremy has been unable to devote time owing to other committments, and so I am posting this even though I have not had his comments on this note.<br />
<br />
==== Work Done So Far ====<br />
<br />
Based on the hints provided in Brendan's post, the following progress<br />
has been made :<br />
<br />
1. Parsing a script using js_ParseTokenStream<br />
<br />
2. Walking of the ParseNodes tree using recursion<br />
<br />
3. Implementation of a simple callback set (HaveNewSubTree,<br />
HaveNodeInTree, EndSubTree) that is called during the walking of the<br />
nodes. The structure used is :<br />
<pre><br />
typedef struct _JSParseNodeVisitor {<br />
NewParseNodeTree newnode;<br />
UseParseNode usenode;<br />
EndParseNodeTree endnode;<br />
void *data;<br />
} JSParseNodeVisitor;<br />
</pre><br />
This is not a proper implementation of the Visitor pattern but used as<br />
a simple starting point.<br />
<br />
4. Implementation of two sets of callbacks - the first that prints the<br />
contents of the nodes (not all node types have been done as yet) and<br />
the second that builds a frequency distribution for 'arity' of nodes,<br />
TOK_ constants and JS Opcodes.<br />
<br />
5. Implementation of a non-recursive walker making the same callbacks.<br />
<br />
==== About the ParserAPI ====<br />
<br />
Before implementing an API, it is essential to have the end-use in<br />
perspective, as well as to delineate clearly the boundaries of<br />
capabilities.<br />
<br />
First the boundaries: The ParserAPI will not evaluate the scripts.<br />
This will ensure that the API can be used on scripts for which object<br />
implementations are not available. For eg, debugger.js references an<br />
object jsd in its top level code. An attempt to evaluate the code will<br />
return an error.<br />
<br />
However, the ParserAPI should be able to allow a javascript function<br />
(that is compiled and evaluated) to be a user of the API. This could<br />
be achieved through a form of 'chaining' where the user of the API is<br />
an internal implementation that in turn invokes the real user<br />
implemented in JS.<br />
<br />
<br />
The idea of the ParserAPI emerged from an interest in a tool, like<br />
JavaDoc, to aid in documenting JS scripts and script collections. Some<br />
other potential uses for the API could be :<br />
<br />
<br />
A GUI application that allows a user to drill down a collection of JS<br />
ie the nodes of interest may differ depending on where the GUI is at<br />
that point in time, and secondly the ability to locate a parseNode and<br />
then continue the API usage from there. Eg, in the first pass, the GUI<br />
may display the source files and function names. When the user clicks<br />
a function, we then have to display the variables, functions called<br />
etc. The application would hold the ParseNode tree - when the user<br />
clicks the funciton, the application would locate that ParseNode and<br />
then start using our API from there.<br />
<br />
An application that wants to build a Calls/Called By kind of graph -<br />
they would use the API to parse the nodes and then build their own<br />
data structures.<br />
<br />
An application is complex and the user is reviewing the code - the API<br />
could be the foundation on which to build a simple search for usage<br />
kind of interface.<br />
<br />
During the initial 'getting-the-feel' work, simple Token Type and<br />
OpCode counting functions have been implemented as users of the API.<br />
This could help to identify a group of scripts that use all tokens and<br />
op codes - this could serve as a 'testing set' for JS engine builds.<br />
<br />
<br />
<br />
==== Design Ideas ====<br />
<br />
1. A user of the API should be able to control the extent of<br />
recursion. For eg, a user who is interested only in top level code and<br />
function definitions should be able to return a value from the<br />
'visitor' callback that will determine the next step for walking. So<br />
on receiving a FUNCTION during the walk, the callback could return a<br />
value that implies 'SKIP THE FUNCTION BODY'. Likewise, a callback<br />
could return a value saying 'STOP WALKING' eg the user found what they<br />
were looking for or decided they werent interested any longer.<br />
<br />
The callback should be able to inhibit the walking of the pn_next node in a given ParseNode.<br />
<br />
2. Related to the above, the API should be able to return a 'marker'<br />
for each node. The user of the API should be able to provide this<br />
marker at a subsequent point to determine the 'walk start' node. For<br />
implementations where GC is not an issue (eg a GUI application for documentation),<br />
this marker could be the 'NODE' pointer itself. Howevever, for other<br />
implementations the marker could be based on the BEGINPOS, ENDPOS<br />
available with each ParseNode.<br />
<br />
3. A single walk of the parse tree should be able to cater to multiple<br />
'visitors'. This is an idea I bring from the arena of image processing<br />
- while walking the contents of an image, different consumers are<br />
supported. At the end of walking, the application can query each<br />
consumer for information of interest. This has two advantages - the<br />
walking is done once, and consumer implementations can be simpler (and<br />
also easily reused). An application sets up the consumers, walks the<br />
contents and then queries each consumer for information. This<br />
information is aggregated / evaluated to determine the application's<br />
course of action.<br />
<br />
4. The Visitable/Visitor definition : I think the API should provide<br />
different types of these. At the 'lowest' level, the Visitor interface<br />
could include a callback for each type of ParseNode. At the next<br />
level, the Visitor interface could include some categorisation based<br />
on TOK_ types. This would seem to be like introducing a 'guide' interface ie the guide interface prepares the visitable which a vistor can visit.<br />
<br />
5. Reviewing the SpiderMonkey code, there are several places where this walker (as a 'js_friend') could be used eg js_FoldConstants, js_EmitTree, CheckSideEffects and some others. These functions currently use recursion and in some cases this recursion appears expensive. I am not sure whether the 'auhtors/maintainers' of these functions would find the code easily maintained if they were to switch to using this API.<br />
<br />
==== Other Issues ====<br />
<br />
1. The API should provide human readable descriptions for elements<br />
like JS OpCode and Parser Tokens. Currently, jsopcode.c is the only<br />
place in the JS code where the 'names' of JS op codes are available.<br />
These are defined in the file jsopcode.tbl. This file is included in<br />
jsopcode.h and jsopcode.c : in the .h file, only the numeric constants<br />
for the opcodes are included whereby the enumeration of the JS opcodes<br />
is exposed. In the .c file, the complete table is included which is<br />
used during disassembly. For the ParserAPI, a function should be added<br />
to jsopcode.c that would return a pointer to the name corresponding to<br />
a given JS Opcode. An option is that there is a public function<br />
exposed by the ParserAPI which in turn invokes a 'friend' function in<br />
jsopcode.c.<br />
<br />
2. Memory and GC : The starting point for the API will be to parse a<br />
script using js_ParseTokenStream. Upon successful parsing, the core<br />
functions of the API will be used ie walking the tree of parse nodes.<br />
During the use of the API, the memory allocated in the context temp<br />
arena pool must not be freed. This suggests when the API user has<br />
finished with the ParserAPI, they must call a function that will<br />
release the arena pool - this seems 'reasonable'. However, the API<br />
will also depend on GC not taking place so that atoms referenced in<br />
the different JSParseNodes will not get freed. During<br />
js_ParseTokenStream, atoms are protected from GC by using<br />
JS_KEEP_ATOMS. Upon completion of the parsing, JS_UNKEEP_ATOMS is<br />
called. One option is that after parsing is completed, JS_KEEP_ATOMS<br />
is called again and JS_UNKEEP_ATOMS is called in the same function<br />
when the arena pool is released.<br />
<br />
3. Folding of constants : When the parsing is completed successfully,<br />
js_FoldConstants is called. If I've understood this correctly,<br />
js_FoldConstants performs optimisation by resolving once expressions<br />
involving literals. A question that arises is whether, a user of the<br />
ParserAPI would prefer that this optimisation is not performed. For<br />
eg, a user of the API may be trying to identify the usage of a<br />
constant value that has been used as a literal in a collection of<br />
scripts - with the constants folded, the literals will not be visible<br />
via the ParserAPI. Similarly, a user of the API trying to find<br />
examples of usage of different operators may get an empty result set<br />
on account of the folding of constants.<br />
<br />
4. When an error occurs during parsing, it is necessary to report the<br />
error to the ErrorHandler callback if set in the context. The error is<br />
available in an Exception object. An issue to consider is whether the<br />
ParserAPI should aggregate all Warnings and make these available at<br />
the end of the parsing.<br />
<br />
5. Clarifications required on TOK_DEFSHARP and TOK_USESHARP. Also on<br />
#n=[], #n={..}, #n# and the like in the comments in jsparse.h.<br />
<br />
[mailto:bkimman@gmail.com /kimman]</div>Dhermanhttps://wiki.mozilla.org/index.php?title=JavaScript:SpiderMonkey:Parser_API&diff=204982JavaScript:SpiderMonkey:Parser API2010-02-26T21:39:27Z<p>Dherman: JS API design notes</p>
<hr />
<div>== JavaScript API ==<br />
<br />
=== Design ===<br />
<br />
A general parsing API could treat the visitor interface from [http://code.google.com/p/es-lab/wiki/JsonMLASTFormat JsonMLAST] as a factory with a parametric type. In Java-like pseudo-types:<br />
<br />
<pre><br />
interface Visitor<A> {<br />
visitThisExpr(attr : {}) : A;<br />
/* etc. */<br />
}<br />
</pre><br />
<br />
and take it as an optional argument to the constructor of a parser object:<br />
<br />
<pre><br />
class Parser<A, Visitor> {<br />
Parser(Visitor<A>? factory);<br />
<br />
parse(src : string,<br />
[filename : string | null,<br />
startLine : number >= 1 | null,<br />
startColumn : number >= 0 | null])<br />
: A;<br />
}<br />
</pre><br />
<br />
This would allow the <code>parse</code> method to use the visitor as a way of injecting the parsed nodes into whatever type ''A'' the client wants. Making the argument optional makes it easy to default to the JsonMLAST format.<br />
<br />
Should also implement a JsonMLAST processor that takes a visitor:<br />
<br />
<pre><br />
processJsonMLAST(ast : JsonMLAST,<br />
visitor : Visitor<A>) : A;<br />
</pre><br />
<br />
This could be implemented in pure JS, at least initially. (It'll be ugly without pattern matching, though.)<br />
<br />
=== Plan ===<br />
<br />
Several separate steps to make this work:<br />
<br />
*[https://bugzilla.mozilla.org/show_bug.cgi?id=548461 Bug 548461] -- refactor JSCompiler to JSSourceCompiler and JSAstCompiler (draft done, patch under review)<br />
*[https://bugzilla.mozilla.org/show_bug.cgi?id=533874 Bug 533874] -- implement marshalling to JsonMLAST (draft done, not quite ready for review)<br />
*generalize to take visitor (not started)<br />
*refactor to build on top of C++ API? (not started)<br />
<br />
[mailto:dherman@mozilla.com /dherman]<br />
<br />
== C++ API ==<br />
<br />
=== Brendan's notes ===<br />
<br />
Currently [http://lxr.mozilla.org/mozilla/source/js/src/jsparse.h jsparse.h] defines a <code>JSParseNode</code> struct, a variant record documented by the major comment before its declaration, and a few <code>JS_FRIEND_API</code> entry points for parsing and compiling, but not executing, token streams.<br />
<br />
There is interest, from the [http://groups.google.com/group/netscape.public.mozilla.jseng jseng newsgroup], in adding a <code>jsparseapi.[ch]</code> module to SpiderMonkey that exposes these parse-tree internals in a sustainable way. See [http://groups.google.com/group/netscape.public.mozilla.jseng/tree/browse_frm/thread/b60521be22b1747a/94a3564cbe78accd?rnum=1&_done=%2Fgroup%2Fnetscape.public.mozilla.jseng%2Fbrowse_frm%2Fthread%2Fb60521be22b1747a%2F94a3564cbe78accd%3F#doc_e17ac2982cf6d7fd my post] in [http://groups.google.com/group/netscape.public.mozilla.jseng/browse_frm/thread/b60521be22b1747a/94a3564cbe78accd#94a3564cbe78accd the thread] on this topic.<br />
<br />
In [http://groups.google.com/group/netscape.public.mozilla.jseng/tree/browse_frm/thread/b60521be22b1747a/94a3564cbe78accd?rnum=1&_done=%2Fgroup%2Fnetscape.public.mozilla.jseng%2Fbrowse_frm%2Fthread%2Fb60521be22b1747a%2F94a3564cbe78accd%3F#doc_766fd5323e92e054 a followup post], I talk about various APIs that could be used to glean information from the direct members of <code>JSParseNode</code>, but with a new <code>jsparseapi.h</code> interface, we would do better to use functions to hide all data types that are not already exposed via <code>jspubtd.h</code> and <code>jsapi.h</code>.<br />
<br />
The parse-tree API should expose a <code>JSParseTree</code> opaque struct type. This type represents a tree parsed from a token stream, or a subtree (even just one leaf node). We should not expose <code>JSTokenStream</code>, rather we should make API entry points such as<br />
<br />
<pre><br />
extern JS_PUBLIC_API(JSParseTree *)<br />
JS_ParseScript(JSContext *cx, const jschar *chars, size_t length,<br />
const char *filename, uintN lineno);<br />
</pre><br />
<br />
that returns <code>NULL</code> on failure and a pointer to a valid <code>ParseTree</code> on success.<br />
<br />
The API would consist of accessors only, no mutators. We might want an API modeled on the [http://en.wikipedia.org/wiki/Visitor_pattern visitor pattern]. So <code>JSParseTree</code> would be a <i>Visitable</i> and the API would introduce a <i>Visitor</i> interface (in the C callbacks or poor-man's vtable sense) for API clients to implement.<br />
<br />
Please feel free to add your design notes below.<br />
<br />
[mailto:brendan@mozilla.org /be]<br />
<br />
=== Kimman's Notes ===<br />
Work on this API originated from an email in the news group post by Jeremy. I volunteered to assist him and since then we have worked together on this. After getting a feel of the task at hand, we started work on a note outlining ideas for this API. Jeremy has been unable to devote time owing to other committments, and so I am posting this even though I have not had his comments on this note.<br />
<br />
==== Work Done So Far ====<br />
<br />
Based on the hints provided in Brendan's post, the following progress<br />
has been made :<br />
<br />
1. Parsing a script using js_ParseTokenStream<br />
<br />
2. Walking of the ParseNodes tree using recursion<br />
<br />
3. Implementation of a simple callback set (HaveNewSubTree,<br />
HaveNodeInTree, EndSubTree) that is called during the walking of the<br />
nodes. The structure used is :<br />
<pre><br />
typedef struct _JSParseNodeVisitor {<br />
NewParseNodeTree newnode;<br />
UseParseNode usenode;<br />
EndParseNodeTree endnode;<br />
void *data;<br />
} JSParseNodeVisitor;<br />
</pre><br />
This is not a proper implementation of the Visitor pattern but used as<br />
a simple starting point.<br />
<br />
4. Implementation of two sets of callbacks - the first that prints the<br />
contents of the nodes (not all node types have been done as yet) and<br />
the second that builds a frequency distribution for 'arity' of nodes,<br />
TOK_ constants and JS Opcodes.<br />
<br />
5. Implementation of a non-recursive walker making the same callbacks.<br />
<br />
==== About the ParserAPI ====<br />
<br />
Before implementing an API, it is essential to have the end-use in<br />
perspective, as well as to delineate clearly the boundaries of<br />
capabilities.<br />
<br />
First the boundaries: The ParserAPI will not evaluate the scripts.<br />
This will ensure that the API can be used on scripts for which object<br />
implementations are not available. For eg, debugger.js references an<br />
object jsd in its top level code. An attempt to evaluate the code will<br />
return an error.<br />
<br />
However, the ParserAPI should be able to allow a javascript function<br />
(that is compiled and evaluated) to be a user of the API. This could<br />
be achieved through a form of 'chaining' where the user of the API is<br />
an internal implementation that in turn invokes the real user<br />
implemented in JS.<br />
<br />
<br />
The idea of the ParserAPI emerged from an interest in a tool, like<br />
JavaDoc, to aid in documenting JS scripts and script collections. Some<br />
other potential uses for the API could be :<br />
<br />
<br />
A GUI application that allows a user to drill down a collection of JS<br />
ie the nodes of interest may differ depending on where the GUI is at<br />
that point in time, and secondly the ability to locate a parseNode and<br />
then continue the API usage from there. Eg, in the first pass, the GUI<br />
may display the source files and function names. When the user clicks<br />
a function, we then have to display the variables, functions called<br />
etc. The application would hold the ParseNode tree - when the user<br />
clicks the funciton, the application would locate that ParseNode and<br />
then start using our API from there.<br />
<br />
An application that wants to build a Calls/Called By kind of graph -<br />
they would use the API to parse the nodes and then build their own<br />
data structures.<br />
<br />
An application is complex and the user is reviewing the code - the API<br />
could be the foundation on which to build a simple search for usage<br />
kind of interface.<br />
<br />
During the initial 'getting-the-feel' work, simple Token Type and<br />
OpCode counting functions have been implemented as users of the API.<br />
This could help to identify a group of scripts that use all tokens and<br />
op codes - this could serve as a 'testing set' for JS engine builds.<br />
<br />
<br />
<br />
==== Design Ideas ====<br />
<br />
1. A user of the API should be able to control the extent of<br />
recursion. For eg, a user who is interested only in top level code and<br />
function definitions should be able to return a value from the<br />
'visitor' callback that will determine the next step for walking. So<br />
on receiving a FUNCTION during the walk, the callback could return a<br />
value that implies 'SKIP THE FUNCTION BODY'. Likewise, a callback<br />
could return a value saying 'STOP WALKING' eg the user found what they<br />
were looking for or decided they werent interested any longer.<br />
<br />
The callback should be able to inhibit the walking of the pn_next node in a given ParseNode.<br />
<br />
2. Related to the above, the API should be able to return a 'marker'<br />
for each node. The user of the API should be able to provide this<br />
marker at a subsequent point to determine the 'walk start' node. For<br />
implementations where GC is not an issue (eg a GUI application for documentation),<br />
this marker could be the 'NODE' pointer itself. Howevever, for other<br />
implementations the marker could be based on the BEGINPOS, ENDPOS<br />
available with each ParseNode.<br />
<br />
3. A single walk of the parse tree should be able to cater to multiple<br />
'visitors'. This is an idea I bring from the arena of image processing<br />
- while walking the contents of an image, different consumers are<br />
supported. At the end of walking, the application can query each<br />
consumer for information of interest. This has two advantages - the<br />
walking is done once, and consumer implementations can be simpler (and<br />
also easily reused). An application sets up the consumers, walks the<br />
contents and then queries each consumer for information. This<br />
information is aggregated / evaluated to determine the application's<br />
course of action.<br />
<br />
4. The Visitable/Visitor definition : I think the API should provide<br />
different types of these. At the 'lowest' level, the Visitor interface<br />
could include a callback for each type of ParseNode. At the next<br />
level, the Visitor interface could include some categorisation based<br />
on TOK_ types. This would seem to be like introducing a 'guide' interface ie the guide interface prepares the visitable which a vistor can visit.<br />
<br />
5. Reviewing the SpiderMonkey code, there are several places where this walker (as a 'js_friend') could be used eg js_FoldConstants, js_EmitTree, CheckSideEffects and some others. These functions currently use recursion and in some cases this recursion appears expensive. I am not sure whether the 'auhtors/maintainers' of these functions would find the code easily maintained if they were to switch to using this API.<br />
<br />
==== Other Issues ====<br />
<br />
1. The API should provide human readable descriptions for elements<br />
like JS OpCode and Parser Tokens. Currently, jsopcode.c is the only<br />
place in the JS code where the 'names' of JS op codes are available.<br />
These are defined in the file jsopcode.tbl. This file is included in<br />
jsopcode.h and jsopcode.c : in the .h file, only the numeric constants<br />
for the opcodes are included whereby the enumeration of the JS opcodes<br />
is exposed. In the .c file, the complete table is included which is<br />
used during disassembly. For the ParserAPI, a function should be added<br />
to jsopcode.c that would return a pointer to the name corresponding to<br />
a given JS Opcode. An option is that there is a public function<br />
exposed by the ParserAPI which in turn invokes a 'friend' function in<br />
jsopcode.c.<br />
<br />
2. Memory and GC : The starting point for the API will be to parse a<br />
script using js_ParseTokenStream. Upon successful parsing, the core<br />
functions of the API will be used ie walking the tree of parse nodes.<br />
During the use of the API, the memory allocated in the context temp<br />
arena pool must not be freed. This suggests when the API user has<br />
finished with the ParserAPI, they must call a function that will<br />
release the arena pool - this seems 'reasonable'. However, the API<br />
will also depend on GC not taking place so that atoms referenced in<br />
the different JSParseNodes will not get freed. During<br />
js_ParseTokenStream, atoms are protected from GC by using<br />
JS_KEEP_ATOMS. Upon completion of the parsing, JS_UNKEEP_ATOMS is<br />
called. One option is that after parsing is completed, JS_KEEP_ATOMS<br />
is called again and JS_UNKEEP_ATOMS is called in the same function<br />
when the arena pool is released.<br />
<br />
3. Folding of constants : When the parsing is completed successfully,<br />
js_FoldConstants is called. If I've understood this correctly,<br />
js_FoldConstants performs optimisation by resolving once expressions<br />
involving literals. A question that arises is whether, a user of the<br />
ParserAPI would prefer that this optimisation is not performed. For<br />
eg, a user of the API may be trying to identify the usage of a<br />
constant value that has been used as a literal in a collection of<br />
scripts - with the constants folded, the literals will not be visible<br />
via the ParserAPI. Similarly, a user of the API trying to find<br />
examples of usage of different operators may get an empty result set<br />
on account of the folding of constants.<br />
<br />
4. When an error occurs during parsing, it is necessary to report the<br />
error to the ErrorHandler callback if set in the context. The error is<br />
available in an Exception object. An issue to consider is whether the<br />
ParserAPI should aggregate all Warnings and make these available at<br />
the end of the parsing.<br />
<br />
5. Clarifications required on TOK_DEFSHARP and TOK_USESHARP. Also on<br />
#n=[], #n={..}, #n# and the like in the comments in jsparse.h.<br />
<br />
[mailto:bkimman@gmail.com /kimman]</div>Dhermanhttps://wiki.mozilla.org/index.php?title=WeeklyUpdates/2010-02-01&diff=198490WeeklyUpdates/2010-02-012010-02-01T17:46:32Z<p>Dherman: /* Upcoming Events */</p>
<hr />
<div><small>[[WeeklyUpdates/2010-01-25|« previous week]] | [[WeeklyUpdates|index]] | [[WeeklyUpdates/2010-02-08|next week »]]</small> <br />
<br />
= Video for today's meeting =<br />
<br />
= Friends of the Tree [[Image:Tree.gif|Friends of the Tree]] =<br />
* Drew Ruderman and David Naylor for helping out with Support for the 3.6!<br />
<br />
= Upcoming Events =<br />
<br />
Put upcoming events here, with dates if possible. Are there any brown bags scheduled for this week? Software releases scheduled for this month?<br />
<br />
'''Previously on "Mozilla"...'''<br />
<br />
'''Monday, Feb 1'''<br />
<br />
'''Tuesday, Feb 2'''<br />
<br />
'''Wednesday, Feb 3'''<br />
<br />
'''Thursday, Feb 4'''<br />
<br />
[[User:Dherman]] design lunch on modules for JavaScript -- 12:30 in Ten Forward (MV)<br />
<br />
'''Friday, Feb 5'''<br />
<br />
* FOSDEM, Feb. 5 - 7, Brussels. Mozilla will be hosting a devroom, booth and community activities this year. [https://wiki.mozilla.org/Fosdem:2010 Details]<br />
<br />
'''Coming up on "Mozilla"...'''<br />
<br />
= Speakers =<br />
<br />
The limit is 3 minutes per speaker. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation.<br />
<br />
{| class="fullwidth-table"<br />
|-<br />
! Title<br />
! Presenter<br />
! Topic<br />
! Media<br />
! More Details<br />
|-<br />
| Support for 3.6<br />
| Cheng Wang<br />
| <br />
| [https://wiki.mozilla.org/images/1/12/Support_increase_by_release.jpg]<br />
| [http://support.mozilla.com/en-US/kb/]<br />
|-<br />
| 3.6 marketing<br />
| Marketing team<br />
| <br />
|-<br />
|}<br />
<br />
= Status Updates By Team =<br />
<br />
== Firefox ==<br />
* '''Firefox 3.6 is continuing to see great pick up, close to 10% of our users already upgraded, and no showstopper issues emerging.'''<br />
<br />
* Check out our list of [[Firefox/Projects|active front end projects]], matched up against our [[Firefox/Goals/2010Q1|team goals list]]. If you're looking to get involved with high priority Firefox front end projects, that's a great place to see what's top-of-mind!<br />
<br />
* Johnathan [http://blog.johnath.com/2010/01/29/mozillas-eu-browser-choice-submission/ blogged] about our submission for the EU browser choice screen.<br />
<br />
== Gecko ==<br />
<br />
== Branch work: Firefox 3.5.x / Firefox 3.6.x / Thunderbird 3.0.x ==<br />
<br />
== Old Branch work: Firefox 3.0.x / Thunderbird 2.0.0.x ==<br />
<br />
== Thunderbird ==<br />
<br />
== SeaMonkey ==<br />
<br />
== Mobile ==<br />
<br />
== IT ==<br />
'''Last Week''' - <i>Even busier!</i>.<br />
* [http://blog.mozilla.com/mrz/2010/01/04/mozillas-new-phoenix-data-center Phoenix!] Status<br />
** Core infrastructure racked and wired<br />
** Starting to configure this week<br />
* Re-implemented SiteSpect behind Zeus<br />
<br />
'''This Week'''<br />
* 2 additional ISC hosted download mirrors <br />
* 50 1u RelEng builders<br />
<br />
'''Upcoming'''<br />
* Production services in Phoenix<br />
** <tt>download.mozilla.org</tt><br />
** <tt>aus2.mozilla.org</tt><br />
<br />
== Release Engineering ==<br />
* Fennec 1.0 release<br />
* shelving WinCE builds for now<br />
* Lorentz project branch open for business<br />
* Places branch parity (test/perf jobs) with mozilla-central<br />
** similar electrolysis work in progress<br />
<br />
== QA ==<br />
<br />
== Security ==<br />
<br />
== Marketing/PR ==<br />
<br />
'''PR''' <br />
<br />
*[http://blogs.zdnet.com/cell-phones/?p=2964 Firefox Mobile version 1.0 now available for the Nokia N900]<br />
*[http://www.maemomagazine.com/2010/01/firefox-mobile-now-available/ Firefox Mobile Now Available]<br />
*[http://www.electronista.com/articles/10/01/31/maemo.gets.firefox.first/ Maemo Gets Firefox First]<br />
*[http://www.brighthand.com/default.asp?newsID=16161&news=Mozilla+Firefox+Fennec+Nokia+N900+Maemo+OS Firefox Web Browser Now Available for Nokia N900]<br />
*[http://www.theregister.co.uk/2010/01/30/firefox_for_maemo_debuts/ Firefox for Maemo Debuts]<br />
*[http://www.mobilecrunch.com/2010/01/29/firefox-mobile-for-maemo-officially-launches/ Firefox for Maemo Officially Launches]<br />
*[http://news.cnet.com/8301-17938_105-10444754-1.html Mozilla releases first mobile Firefox browser]<br />
*[http://www.phonescoop.com/news/item.php?n=5435 Mozilla Releases Final Firefox Build for Maemo 5]<br />
*[http://jkontherun.com/2010/01/30/firefox-for-maemo-first-look/ Firefox for Maemo First Look]<br />
*[http://mashable.com/2010/01/30/firefox-maemo/ Firefox for Mobile Makes Its Debut]<br />
*[http://www.engadget.com/2010/01/30/firefox-for-mobile-makes-maemo-its-first-home/ Firefox for Mobile Makes Maemo Its First Home]<br />
*[http://www.webmonkey.com/blog/Weave_1DOT0_Released__Firefox_Officially_Gets_Syncing Weave 1.0 Released, Firefox Officially Gets Syncing]<br />
*[http://www.readwriteweb.com/archives/weave_goes_10_firefox_gets_an_official_bookmark_sy.php Weave Goes 1.0: Firefox Gets an Official Bookmark Syncing Tool]<br />
*[http://lifehacker.com/5303544/weave-now-syncs-firefox-preferences-auto+logins Weave Now Syncs Firefox Preferences, Auto-Logins]<br />
*[http://blog.internetnews.com/skerner/2010/01/mozilla-weave-10-now-generally.html Mozilla Weave 1.0 now generally available - sync away!]<br />
*[http://gigaom.com/2010/01/29/mozillas-weave-synch-tool-hits-version-1-0-aims-for-firefox-users/?utm_source=gigaom&utm_medium=navigation Mozilla’s Weave Sync Tool Hits Version 1.0, Aims for Firefox Users]<br />
*[http://www.downloadsquad.com/2010/01/29/mozilla-weave-hits-1-0-keeps-all-your-firefox-installs-in-sync/ Mozilla Weave hits 1.0, keeps all your Firefox installs in sync!]<br />
<br />
<br />
'''Events'''<br />
<br />
'''Creative Team'''<br />
<br />
'''Community Marketing'''<br />
<br />
== Support ==<br />
* 3.6 was awesome (see above presentation)<br />
* If you're using an N900 or other Mobile-capable device, please help on our [https://mobile.support.mozilla.com/tiki-view_forum.php?forumId=5 community forums]<br />
<br />
== Metrics ==<br />
<br />
== Evangelism ==<br />
<br />
== Labs ==<br />
<br />
== Developer Tools ==<br />
<br />
* No updates this week<br />
<br />
== Add-ons ==<br />
<br />
== Webdev ==<br />
<br />
== L10n ==<br />
<br />
= Introducing New Hires =<br />
<br />
= Foundation Updates =<br />
<br />
= Roundtable =</div>Dhermanhttps://wiki.mozilla.org/index.php?title=WeeklyUpdates/2010-02-01&diff=198272WeeklyUpdates/2010-02-012010-02-01T04:23:35Z<p>Dherman: /* Upcoming Events */</p>
<hr />
<div><small>[[WeeklyUpdates/2010-01-25|« previous week]] | [[WeeklyUpdates|index]] | [[WeeklyUpdates/2010-02-08|next week »]]</small> <br />
<br />
= Video for today's meeting =<br />
<br />
= Friends of the Tree [[Image:Tree.gif|Friends of the Tree]] =<br />
<br />
= Upcoming Events =<br />
<br />
Put upcoming events here, with dates if possible. Are there any brown bags scheduled for this week? Software releases scheduled for this month?<br />
<br />
'''Previously on "Mozilla"...'''<br />
<br />
'''Monday, Feb 1'''<br />
<br />
'''Tuesday, Feb 2'''<br />
<br />
'''Wednesday, Feb 3'''<br />
<br />
'''Thursday, Feb 4'''<br />
<br />
[[User:Dherman]] design lunch on modules for JavaScript -- noon, location TBD<br />
<br />
'''Friday, Feb 5'''<br />
<br />
'''Coming up on "Mozilla"...'''<br />
<br />
= Speakers =<br />
<br />
The limit is 3 minutes per speaker. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation.<br />
<br />
{| class="fullwidth-table"<br />
|-<br />
! Title<br />
! Presenter<br />
! Topic<br />
! Media<br />
! More Details<br />
|-<br />
| Your title here<br />
| Your name here<br />
| About your topic<br />
| Link to any media you want shown on the screen while you talk<br />
| Link for interested people to get more information<br />
|-<br />
|}<br />
<br />
= Status Updates By Team =<br />
<br />
== Firefox ==<br />
<br />
== Gecko ==<br />
<br />
== Branch work: Firefox 3.5.x / Firefox 3.6.x / Thunderbird 3.0.x ==<br />
<br />
== Old Branch work: Firefox 3.0.x / Thunderbird 2.0.0.x ==<br />
<br />
== Thunderbird ==<br />
<br />
== SeaMonkey ==<br />
<br />
== Mobile ==<br />
<br />
== IT ==<br />
'''Last Week''' - <i>Even busier!</i>.<br />
* [http://blog.mozilla.com/mrz/2010/01/04/mozillas-new-phoenix-data-center Phoenix!] Status<br />
** Core infrastructure racked and wired<br />
** Starting to configure this week<br />
* Re-implemented SiteSpect behind Zeus<br />
<br />
'''This Week'''<br />
* 2 additional ISC hosted download mirrors <br />
* 50 1u RelEng builders<br />
<br />
'''Upcoming'''<br />
* Production services in Phoenix<br />
** <tt>download.mozilla.org</tt><br />
** <tt>aus2.mozilla.org</tt><br />
<br />
== Release Engineering ==<br />
<br />
== QA ==<br />
<br />
== Security ==<br />
<br />
== Marketing/PR ==<br />
<br />
'''PR''' <br />
<br />
'''Events'''<br />
<br />
'''Creative Team'''<br />
<br />
'''Community Marketing'''<br />
<br />
== Support ==<br />
<br />
== Metrics ==<br />
<br />
== Evangelism ==<br />
<br />
== Labs ==<br />
<br />
== Developer Tools ==<br />
<br />
== Add-ons ==<br />
<br />
== Webdev ==<br />
<br />
== L10n ==<br />
<br />
= Introducing New Hires =<br />
<br />
= Foundation Updates =<br />
<br />
= Roundtable =</div>Dhermanhttps://wiki.mozilla.org/index.php?title=WeeklyUpdates/2010-02-01&diff=197948WeeklyUpdates/2010-02-012010-01-30T00:50:22Z<p>Dherman: /* Upcoming Events */</p>
<hr />
<div><small>[[WeeklyUpdates/2010-01-25|« previous week]] | [[WeeklyUpdates|index]] | [[WeeklyUpdates/2010-02-08|next week »]]</small> <br />
<br />
= Video for today's meeting =<br />
<br />
= Friends of the Tree [[Image:Tree.gif|Friends of the Tree]] =<br />
<br />
= Upcoming Events =<br />
<br />
Put upcoming events here, with dates if possible. Are there any brown bags scheduled for this week? Software releases scheduled for this month?<br />
<br />
'''Previously on "Mozilla"...'''<br />
<br />
'''Monday, Feb 1'''<br />
<br />
'''Tuesday, Feb 2'''<br />
<br />
'''Wednesday, Feb 3'''<br />
<br />
[[User:Dherman]] brown bag on modules for JavaScript -- 12:30 (tentative), 2nd floor Mtn View<br />
<br />
'''Thursday, Feb 4'''<br />
<br />
'''Friday, Feb 5'''<br />
<br />
'''Coming up on "Mozilla"...'''<br />
<br />
= Speakers =<br />
<br />
The limit is 3 minutes per speaker. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation.<br />
<br />
{| class="fullwidth-table"<br />
|-<br />
! Title<br />
! Presenter<br />
! Topic<br />
! Media<br />
! More Details<br />
|-<br />
| Your title here<br />
| Your name here<br />
| About your topic<br />
| Link to any media you want shown on the screen while you talk<br />
| Link for interested people to get more information<br />
|-<br />
|}<br />
<br />
= Status Updates By Team =<br />
<br />
== Firefox ==<br />
<br />
== Gecko ==<br />
<br />
== Branch work: Firefox 3.5.x / Firefox 3.6.x / Thunderbird 3.0.x ==<br />
<br />
== Old Branch work: Firefox 3.0.x / Thunderbird 2.0.0.x ==<br />
<br />
== Thunderbird ==<br />
<br />
== SeaMonkey ==<br />
<br />
== Mobile ==<br />
<br />
== IT ==<br />
<br />
== Release Engineering ==<br />
<br />
== QA ==<br />
<br />
== Security ==<br />
<br />
== Marketing/PR ==<br />
<br />
'''PR''' <br />
<br />
'''Events'''<br />
<br />
'''Creative Team'''<br />
<br />
'''Community Marketing'''<br />
<br />
== Support ==<br />
<br />
== Metrics ==<br />
<br />
== Evangelism ==<br />
<br />
== Labs ==<br />
<br />
== Developer Tools ==<br />
<br />
== Add-ons ==<br />
<br />
== Webdev ==<br />
<br />
== L10n ==<br />
<br />
= Introducing New Hires =<br />
<br />
= Foundation Updates =<br />
<br />
= Roundtable =</div>Dhermanhttps://wiki.mozilla.org/index.php?title=User:Dherman&diff=197351User:Dherman2010-01-27T23:48:58Z<p>Dherman: about me</p>
<hr />
<div>I work in Mozilla Labs on JavaScript and programming language-related stuff!<br />
<br />
email: dherman at mozilla.com<br />
<br />
irc: dherman at irc.mozilla.org<br />
<br />
website: http://calculist.blogspot.com</div>Dhermanhttps://wiki.mozilla.org/index.php?title=Labs&diff=197350Labs2010-01-27T23:47:22Z<p>Dherman: added myself to Team list</p>
<hr />
<div>== About Labs == <br />
Laboratories are where science and creativity meet to develop, research, and explore new ideas. Mozilla Labs embraces this great tradition — a virtual lab where people come together to create, experiment, and play with new Web innovations and technologies.<br />
<br />
Anything goes here. Crazy ideas and inspirations are encouraged as we all explore and experiment with brand new ideas in whole new ways. Mozilla Labs is about inspiring and harnessing the intelligence, wisdom, and energy of the Mozilla community; let’s imagine the future of the Web, and then let’s build it together.<br />
<br />
All are welcome. Come play.<br />
<br />
__TOC__<br />
== News ==<br />
* [http://labs.mozilla.com/blog/ Mozilla Labs Blog]<br />
<br />
== Projects ==<br />
; Bespin - [http://labs.mozilla.com/projects/bespin/ site] [[Labs/Bespin | wiki]]<br />
: An open, extensible web-based framework for code editing<br />
<br />
; Concept Series - [http://labs.mozilla.com/projects/concept-series/ site] [[Labs/Concept Series | wiki]]<br />
: Get involved and share your ideas and expertise as we collectively explore and design future directions for the Web. You don't have to be a software engineer to contribue, and you don't have to know how to program computers. Everyone is welcome to participate.<br />
<br />
; Chocolate Factory [[Labs/Chocolate Factory | wiki]]<br />
: Chocolate Factory is the collaborative Open Innovation tool for the Mozilla Labs Concept Series.<br />
<br />
; Jetpack - [https://jetpack.mozillalabs.com/ site] [[Labs/Jetpack | wiki]]<br />
: Jetpack is a project to explore new & innovative approaches to extensibility of the browser. <br />
<br />
; Personas - [http://labs.mozilla.com/projects/firefox-personas/ site] [[Labs/Personas | wiki]]<br />
: Personas for Firefox is an extension that provides dynamic lightweight theming for Firefox.<br />
<br />
; Prism - [http://labs.mozilla.com/projects/prism/ site] [[Prism | wiki]]<br />
: Prism (formerly, Webrunner) is a prototype application that lets users split web applications out of their browser and run them directly on their desktop.<br />
<br />
; Snowl - [http://labs.mozilla.com/projects/snowl/ site] [[Labs/Snowl | wiki]]<br />
: Could the web browser help you follow and participate in online discussions? Snowl is an experiment to answer that question. It's a prototype Firefox extension that integrates messaging into the browser.<br />
<br />
; Test Pilot - [http://mozillalabs.com/testpilot/ blog] [https://testpilot.mozillalabs.com/ site] [[Labs/Test Pilot | wiki]]<br />
: Test Pilot is an idea for a new user testing program for Mozilla Labs that aims to build a 1% representative sample of the Firefox user base for soliciting wide participation and structured feedback for Labs experiments.<br />
<br />
; Ubiquity - [http://labs.mozilla.com/projects/ubiquity/ site] [[Labs/Ubiquity | wiki]]<br />
: An experiment into connecting the Web with language in an attempt to find new user interfaces that could make it possible for everyone to do common Web tasks more quickly and easily.<br />
<br />
; Weave - [http://labs.mozilla.com/projects/weave/ site] [[Labs/Weave | wiki]]<br />
: As the Web continues to evolve and more of our lives move online, we believe that Web browsers like Firefox can and should do more to broker rich experiences while increasing user control over their data and personal information.<br />
<br />
; Labs Site 2.0 - [[Labs/Site 2.0 | wiki]]<br />
: An ongoing project to improve the Mozilla Labs website. Ideas and help always welcome!<br />
<br />
; JS Modules -- [[Labs/JS_Modules|wiki]]<br />
: A set of handy code modules useful in Firefox add-on development.<br />
<br />
; [http://labs.mozilla.com/projects/ Full projects list]<br />
: Includes older, archived, or otherwise inactive projects.<br />
<br />
== Discussions ==<br />
Mozilla Labs is using Google Groups for all its discussions. You can find those groups here:<br />
* [http://groups.google.com/group/mozilla-labs/topics Mozilla Labs] (general discussion and anything that doesn't fit elsewhere)<br />
* [http://groups.google.com/group/bespin/topics Bespin]<br />
* [http://groups.google.com/group/mozilla-labs-concept-series/topics Concept Series]<br />
* [http://groups.google.com/group/mozilla-labs-personas/topics Personas]<br />
* [http://groups.google.com/group/mozilla-labs-prism/topics Prism]<br />
* [http://groups.google.com/group/mozilla-labs-snowl/topics?gvc=2 Snowl]<br />
* [http://groups.google.com/group/mozilla-labs-testpilot/topics?gvc=2 Test Pilot]<br />
* [http://groups.google.com/group/ubiquity-firefox/topics Ubiquity]<br />
* [http://groups.google.com/group/mozilla-labs-weave/topics Weave]<br />
<br />
== Team ==<br />
* Chris Beard<br />
* [[User:Anant | Anant Narayanan]]: Weave, Jetpack<br />
* [[User:Avarma | Atul Varma]]<br />
* Aza Raskin: UX Thinking & Design, Jetpack<br />
* Chris Hofmann<br />
* Dan Mills: Weave<br />
* [[User:Dherman | Dave Herman]]: JavaScript<br />
* [[User:Mardak | Edward Lee]]: Weave<br />
* [[User:Jinghua |Jinghua Zhang]]: Test Pilot<br />
* [[User:JoeWalker | Joe Walker]]: Bespin<br />
* John Resig: Web Platform Capabilities<br />
* [[User:Jdicarlo | Jono DiCarlo]]: Test Pilot<br />
* [[User:Kdangoor | Kevin Dangoor]]: Bespin<br />
* [[User:mhanson | Michael Hanson]]: Principal Engineer, Labs<br />
* Mike Connor: Weave<br />
* [[User:MykMelez |Myk Melez]]: Jetpack<br />
* [[User:PascalF | Pascal Finette]]: Operations, Concept Series<br />
* [[User:Pwalton | Patrick Walton]]: Bespin<br />
* Ragavan Srinivasan: Weave<br />
* Sean Martell: Graphic Design<br />
* Suneel Gupta: Personas<br />
* [[User:Telliott | Toby Elliott]]: Weave<br />
* Zandr Milewski: IT support, Weave<br />
<br />
== Twitter Accounts ==<br />
Most Labs projects have a Twitter account - follow us if you're interested in up-to-the-minute news:<br />
* [http://twitter.com/mozlabs Labs General]<br />
* [http://twitter.com/bespin Bespin ]<br />
* [http://twitter.com/mozconcept Concept Series]<br />
* [http://twitter.com/mozillajetpack Jetpack]<br />
* [http://twitter.com/getpersonas Personas]<br />
* [http://twitter.com/MozTestPilot Testpilot]<br />
* [http://twitter.com/mozillaubiquity Ubiquity]<br />
* [http://twitter.com/mozweave Weave]<br />
<br />
== Archives ==<br />
* [[Labs/Archives/Old Labs page | Old Labs wikipage]]</div>Dherman