120
edits
JavaScript:New to SpiderMonkey: Difference between revisions
Final step, for now at least.
No edit summary |
(Final step, for now at least.) |
||
| Line 1: | Line 1: | ||
This is a page to help new | This is a page to help new members of the JS team or new contributors to SpiderMonkey to orient themselves. Please [[JavaScript:New_to_SpiderMonkey#Help_make_this_better|help out]]. | ||
| Line 126: | Line 126: | ||
Nothing gets into the tree without a review, so you'll need one. The easiest way to get a review is to go to the #jsapi IRC channel on irc.mozilla.org and ask for a volunteer. Point them to the bug. In all likelyhood, they'll give you a review and ask you to change something. Fix what they ask, resubmit the patch to bugzilla, and ask for another review. After you repeat this step a few times, they'll say something like "review=me" meaning it's now good to commit. | Nothing gets into the tree without a review, so you'll need one. The easiest way to get a review is to go to the #jsapi IRC channel on irc.mozilla.org and ask for a volunteer. Point them to the bug. In all likelyhood, they'll give you a review and ask you to change something. Fix what they ask, resubmit the patch to bugzilla, and ask for another review. After you repeat this step a few times, they'll say something like "review=me" meaning it's now good to commit. | ||
=== Commit === | === Commit === | ||
| Line 143: | Line 134: | ||
TODO: we don't want them worrying about false positives either, since there are plenty. | TODO: we don't want them worrying about false positives either, since there are plenty. | ||
== Overview of the JS engine == | == Overview of the JS engine == | ||
| Line 158: | Line 151: | ||
http://hacks.mozilla.org/2009/07/tracemonkey-overview/ | http://hacks.mozilla.org/2009/07/tracemonkey-overview/ | ||
=== Medium level documentation === | === Medium level documentation === | ||
| Line 164: | Line 158: | ||
Mapping JS idioms to SpiderMonkey code: https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Phrasebook | Mapping JS idioms to SpiderMonkey code: https://developer.mozilla.org/En/SpiderMonkey/JSAPI_Phrasebook | ||
=== Detailed documentation === | === Detailed documentation === | ||
| Line 177: | Line 172: | ||
== Collaboration and teamwork == | == Collaboration and teamwork == | ||
=== Communication (in descending order of information content) === | === Communication (in descending order of information content) === | ||
| Line 204: | Line 198: | ||
== Code considerations == | |||
=== Repository === | |||
Most active work on SpiderMonkey is done in the [http://hg.mozilla.org/tracemonkey] branch of the mozilla repository. Currently, there is also work in the [http://hg.mozilla.org/jaegermonkey JaegerMonkey] branch, but this should be merged back to Tracemonkey very soon. The main Mozilla branch is [http://hg.mozilla.org/mozilla-central Mozilla-central], to which sayrer merges our code each week. | Most active work on SpiderMonkey is done in the [http://hg.mozilla.org/tracemonkey] branch of the mozilla repository. Currently, there is also work in the [http://hg.mozilla.org/jaegermonkey JaegerMonkey] branch, but this should be merged back to Tracemonkey very soon. The main Mozilla branch is [http://hg.mozilla.org/mozilla-central Mozilla-central], to which sayrer merges our code each week. | ||
=== Coding Style === | |||
For many years, SpiderMonkey was written in C, and is gradually moving to C++. We still avoid many features such as run-time type information and virtual functions, but have come around to the glory of templates and namespaces relatively recently. Read the [[JavaScript:SpiderMonkey:C++ Coding Style]]. Do NOT read the | For many years, SpiderMonkey was written in C, and is gradually moving to C++. We still avoid many features such as run-time type information and virtual functions, but have come around to the glory of templates and namespaces relatively recently. Read the [[JavaScript:SpiderMonkey:C++ Coding Style|Coding Style]]. Do NOT read the portability guidelines, which I will not link to, since they are very out of date. | ||
=== Workflow === | |||
As stated above, everything goes through bugzilla. We find a bug or have an idea, then submit it to bugzilla, then file patches to solve it. When it is solved, the patch is reviewed by team members, and is then committed to the tracemonkey repository. Commit links are added as comments. | As stated above, everything goes through bugzilla. We find a bug or have an idea, then submit it to bugzilla, then file patches to solve it. When it is solved, the patch is reviewed by team members, and is then committed to the tracemonkey repository. Commit links are added as comments. | ||
| Line 220: | Line 214: | ||
Bugs which are fixed in tracemonkey are marked as 'fixed-in-tracemonkey' on the bugzilla whiteboard for the bug. When sayrer merges the code into mozilla-central, those bugs are marked as fixed. | Bugs which are fixed in tracemonkey are marked as 'fixed-in-tracemonkey' on the bugzilla whiteboard for the bug. When sayrer merges the code into mozilla-central, those bugs are marked as fixed. | ||
==== Sample Workflows ==== | |||
[http://blog.mozilla.com/nnethercote/2009/07/27/how-i-work-on-tracemonkey/ Nicholas Nethercote: How I work on Tracemonkey] | [http://blog.mozilla.com/nnethercote/2009/07/27/how-i-work-on-tracemonkey/ Nicholas Nethercote: How I work on Tracemonkey] | ||
=== Policy === | |||
The following docs are for the Mozilla project, and differ ever so slightly from what you should do for SpiderMonkey. For example, you may ignore the checkin-needed thing, and ask in #jaspi instead, and you should find reviewers in #jsapi rather than #developers. | The following docs are for the Mozilla project, and differ ever so slightly from what you should do for SpiderMonkey. For example, you may ignore the checkin-needed thing, and ask in #jaspi instead, and you should find reviewers in #jsapi rather than #developers. | ||
| Line 234: | Line 228: | ||
[https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch Submitting a patch] | [https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch Submitting a patch] | ||
[https://developer.mozilla.org/en/Supported_build_configurations Supported Platforms] | |||
==== .hgrc file ==== | |||
This .hgrc file contains a lot of the wisdom distilled through the wiki: | This .hgrc file contains a lot of the wisdom distilled through the wiki: | ||
| Line 262: | Line 257: | ||
try = ssh://email@domain.tld@hg.mozilla.org/try/ | try = ssh://email@domain.tld@hg.mozilla.org/try/ | ||
==== Mercurial Queues | === Try server === | ||
Often, you may be a little wary of breaking things. Mozilla has a [[Build:TryServer|Try Server]] where you can send a patch, and it'll be built on tons of machines which will report back to you. | |||
=== Mercurial Queues === | |||
Since most of our lives revolve around patches, and we use Mercurial, nearly everybody uses Mercurial queues. | Since most of our lives revolve around patches, and we use Mercurial, nearly everybody uses Mercurial queues. | ||
| Line 268: | Line 267: | ||
Queues are based on the idea of patch management. Each queue consists of a series of patches, applied sequentially. The aim of the game is to split potential commits into simple, bite-sized chunks which are easy to review. This also makes it simple to experiment without polluting your existing work on a bug, to spin parts off into new bugs, and to rapidly apply and unapply patches (as demonstrated in the tutorial above). | Queues are based on the idea of patch management. Each queue consists of a series of patches, applied sequentially. The aim of the game is to split potential commits into simple, bite-sized chunks which are easy to review. This also makes it simple to experiment without polluting your existing work on a bug, to spin parts off into new bugs, and to rapidly apply and unapply patches (as demonstrated in the tutorial above). | ||
==== Enabling ==== | |||
Add the following snippet to your .hgrc file to enable MQ | Add the following snippet to your .hgrc file to enable MQ | ||
| Line 275: | Line 274: | ||
mq = | mq = | ||
==== Example MQ workflow ==== | |||
Clone the repository to deal with a bug: | Clone the repository to deal with a bug: | ||
| Line 329: | Line 328: | ||
There are some more complex techniques that we won't go into in detail. You can enable only some patches using qguard and qselect, and you can reorder the patches by manually editing the .hg/patches/series file. But be careful! | There are some more complex techniques that we won't go into in detail. You can enable only some patches using qguard and qselect, and you can reorder the patches by manually editing the .hg/patches/series file. But be careful! | ||
== Help make this better == | == Help make this better == | ||
| Line 340: | Line 340: | ||
Will review patches, commit code: | Will review patches, commit code: | ||
Volunteer! | |||
Will answer newbie questions: | Will answer newbie questions: | ||
Paul Biggar - pbiggar - pbiggar@mozilla.com | Paul Biggar - pbiggar - pbiggar@mozilla.com | ||
== TODO == | |||
* Add tools section: | |||
** Using static analysis checkers | |||
** Shark/valgrind | |||
** Tinderbox/talos | |||
* How do we get bugs for the newbies? | |||
* Other blog posts which have good SpiderMonkey-related content | |||
* List other blogs with a high proportion of SpiderMonkey | |||