MozillaWiki

JavaScript:New to SpiderMonkey: Difference between revisions

Page Discussion

JavaScript:New to SpiderMonkey (view source)

Revision as of 18:29, 7 August 2010

521 bytes added ,  7 August 2010
Clean up wording, put things into section.
(Wrote a tutorial for your first patch.)
(Clean up wording, put things into section.)
Line 1: Line 1:
This is a page to help new member of the JS team or new contributors to SpiderMonkey to orient themselves. It's maintained by Paul Biggar (pbiggar@mozilla.com), who is currently new to SpiderMonkey. Please help by telling me what you found useful when you were new.
This is a page to help new member of the JS team or new contributors to SpiderMonkey to orient themselves. It's maintained by Paul Biggar (pbiggar@mozilla.com), who is currently new to SpiderMonkey. Please help by telling me what you found useful when you were new.


== Quick getting started tutorial ==
== Tutorial: your first patch ==
 
The first step to getting involved with SpiderMonkey is to make your first patch. This guides you through it, and at the end you should have learnt a lot of the procedures and formalisms involved in getting things done here.


We'll assume you're on a Unix-y platform, and that you know what you're doing. We'll ignore nearly all details.  
We'll assume you're on a Unix-y platform, and that you know what you're doing. We'll ignore nearly all details.  


Get the code from the repository.  
=== Get the code ===
 
We work out of the "tracemonkey" branch of the Mozilla Mercurial repository. Download it:


  hg clone http://hg.mozilla.org/tracemonkey
  hg clone http://hg.mozilla.org/tracemonkey


The tracemonkey directory is a full copy of all the firefox source code. So we'll need to build it.
=== Build Firefox ===
 
The tracemonkey/ directory contains a full copy of all the firefox source code. Before building it, you need a .mozconfig file. Download one we made earlier:
 
wget http://TODO/.mozconfig -O ~/.mozconfig
 
Build it:


  cd tracemonkey  
  cd tracemonkey  
  make -f client.mk build # this takes about an hour if you throw 4 cores at it, so this might be a good time to fill in the assignment paperwork (TODO link).
  make -f client.mk build  


This builds an "out-of-source" build, where the object files and binaries are in obj-i686-pc-linux-gnu.  
This builds an "out-of-source" build, where the object files and binaries are in obj-i686-pc-linux-gnu (depending of course on your platform).


Do we need a .mozconfig file?
This is going to take a long time, maybe an hour on a four core machine. It's a good time to peruse the rest of this guide.  


Most of the time, you'll be working with the Javascript shell, instead of the full Firefox browser. So let's build the shell:  
=== Build the js shell ===
 
Most of the time, you'll be working with the Javascript shell, instead of the full Firefox browser. So build the shell:  


  cd js/src  
  cd js/src  
Line 24: Line 36:
  cd build_DBG.OBJ  
  cd build_DBG.OBJ  
  ../configure --enable-debug --disable-optimize
  ../configure --enable-debug --disable-optimize
=== Fix something ===


At this point, you're ready to make your first fix.  
At this point, you're ready to make your first fix.  


  TODO: something useless. Maybe adding a datemicrosecond function.
  TODO: something useless. Maybe adding a datemicrosecond function.
==== Building your changes ====


Having made the change, build the shell again.  
Having made the change, build the shell again.  
Line 33: Line 49:
  cd build_DBG.OBJ  
  cd build_DBG.OBJ  
  make
  make
==== Testing your changes ====


It builds. Hurray. Time to run the tests to check you haven't broken anything.  
It builds. Hurray. Time to run the tests to check you haven't broken anything.  
Line 42: Line 60:
  cd build_DBG.OBJ  
  cd build_DBG.OBJ  
  python ../tests/jstests.py ./js --args="-j"
  python ../tests/jstests.py ./js --args="-j"
==== Benchmark your changes ====


Tests all pass. Congrats, you didn't break anything. Now, did you make it faster or slower? We benchmark using the v8 and SunSpider benchmarks. Get the benchmarks:  
Tests all pass. Congrats, you didn't break anything. Now, did you make it faster or slower? We benchmark using the v8 and SunSpider benchmarks. Get the benchmarks:  
Line 53: Line 73:
  cd ..
  cd ..


So there's a few problems here. First, we tested a debug version. Secondly, we need to compare it against the old version if we're going to see if it got faster. OK, first, let's make an optimized build:
===== Optimized build =====
 
Whoops, we benchmarked the debug version. Let's make an optimized build to test instead.


  mkdir build_OPT.OBJ  
  mkdir build_OPT.OBJ  
Line 67: Line 89:
You'll need that later.  
You'll need that later.  


So we now need to go back and time the baseline version. This calls for a brief introduction to mercurial queues, which most people think is a pretty good way of managing their SpiderMonkey workflow:  
===== Baseline version / Mercurial Queues =====
 
We need to time our optimized version against the baseline version. This calls for a brief introduction to mercurial queues, which most people think is a pretty good way of managing their SpiderMonkey workflow:  


  hg qinit
  hg qinit
Line 77: Line 101:
  hg qpop
  hg qpop


And we're back to our pristine version. So build again and rerun SunSpider again. You should now have two files like:  
And we're back to our pristine version.
 
===== Compare =====
 
Build again and rerun SunSpider again. You should now have two files like:  


  sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js
  sunspider-0.9.1-results/sunspider-results-2010-08-07-17.56.48.js
Line 86: Line 114:
  sunspider-compare-results FILE1 FILE2
  sunspider-compare-results FILE1 FILE2


==== Get a real bug  ====
=== Get a real bug  ===


At this point, you've seen nearly everything you need to do hack on SpiderMonkey. So it's time to get a real bug to work on. Go to the IRC channel, #jsapi on irc.mozilla.org, and say the magic words:  
At this point, you've seen nearly everything you need to do hack on SpiderMonkey. So it's time to get a real bug to work on. Go to the IRC channel, #jsapi on irc.mozilla.org, and say the magic words:  
Line 96: Line 124:
Fix the bug, updating the bug report with your progress. When it's done, repeat all the steps above. Then it's time to get your patch into the tree.
Fix the bug, updating the bug report with your progress. When it's done, repeat all the steps above. Then it's time to get your patch into the tree.


==== Submit a patch  ====
=== Submit a patch  ===


To get the patch from mercurial, use:  
To get the patch from mercurial, use:  
Line 105: Line 133:
Add it to the bug as an attachment.  
Add it to the bug as an attachment.  


==== Get a review ====
=== Get a review ===


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.  


==== Try server  ====
=== Try server  ===


On your first commit, you're likely to be a little wary of breaking things. Mozilla has a "tryserver" where you can send a patch, and it'll be built on tons of machines which will report back to you.  
On your first commit, you're likely to be a little wary of breaking things. Mozilla has a "tryserver" where you can send a patch, and it'll be built on tons of machines which will report back to you.  
Line 115: Line 143:
The guide for getting "level 1" access, which you need for the try server, is here. Ask your reviewer to vouch for you, and send in the paperwork ASAP.  
The guide for getting "level 1" access, which you need for the try server, is here. Ask your reviewer to vouch for you, and send in the paperwork ASAP.  


Of course, your patch maybe small enough not to need the try server, so you don't always have to
TODO: Move this elsewhere. Level 1 access can take ages.


https://wiki.mozilla.org/Build:TryServer  
https://wiki.mozilla.org/Build:TryServer  


==== Commit ====
=== Commit ===


You can't commit until you have "level 2" access, and you don't have level 2 access (at time of writing, I don't have level 2 access), so you'll need someone to do this for you. The volunteer from IRC may do this, otherwise you'll need a new volunteer.  
You can't commit until you have "level 2" access, and you don't have level 2 access (at time of writing, I don't have level 2 access), so you'll need someone to do this for you. The volunteer from IRC may do this, otherwise you'll need a new volunteer.  
Pbiggar
120

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/243722"