You'll need that later.
===== 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 used to be the way most people managed their SpiderMonkey workflow (though these days many people use native hg, native hg + evolution, or git):
hg qinit
hg qnew my_first_patch -f
hg qrefresh
This puts your current work into a patch, managed by Mercurial, symbolically called my_first_patch. To pop the patch off:
hg qpop
And we're back to our pristine version.
===== Compare =====
To get the patch from mercurial, use:
hg qdiff # if you're using queues or
hg diff # if you're not
Add push it using moz-phab. See https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html#to the bug as an attachment-submit-a-patch for more information.
=== Get a review ===
=== Coding Style ===
For many years, SpiderMonkey was written in C, and is gradually moving to C++uses the same coding style as Firefox. We still avoid many features such as runPlease see https://firefox-source-time type information and exceptions, and generally avoid virtual functions for core data, but have come around to the glory of templates and namespaces relatively recentlydocs. Read the [[JavaScript:SpiderMonkey:C++ Coding Style|Coding Style]]mozilla. Do NOT read the portability guidelines, which I will not link to, since they are very out of dateorg/code-quality/coding-style/index.html for more details
=== Workflow ===
==== Sample Workflows ====
(Outdated) [http://blog.mozilla.com/nnethercote/2009/07/27/how-i-work-on-tracemonkey/ Nicholas Nethercote: How I work on Tracemonkey]
[https://blog.mozilla.org/sfink/2017/06/01/sfink-mozilla-workflow/ Steve Fink: Mozilla workflow]
This .hgrc file contains a lot of the wisdom distilled through the wiki:
[extensions]
mq =
[ui]
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 and tested on tons of machines, which report to [https://treeherder.mozilla.org/#/jobs?repo=try TreeHerder]. Although you don't have [https://www.mozilla.org/hacking/commit-access-policy/ access] to TryServer just yet, you can get someone else to push it there for you. Just attach a patch to your bug, and ask in a comment, or on [irc://irc.mozilla.org/#jsapi #jsapi]. To be able to push to try-server yourself, you will need "level 1" access, which you can [https://www.mozilla.org/hacking/commit-access-policy/ request] once you've contributed a patch or two.
=== Mercurial Queues === Since most of our lives revolve around patches, and we use Mercurial, nearly everybody uses Mercurial queues. 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 [extensions] mq = ==== Example MQ workflow ==== Clone the repository to deal with a bug: hg clone http://hg.mozilla.org/mozilla-central Initialize your queue: hg qinit -c Create a new patch, with some name: hg qnew first_attempt Work on the patch, try to fix the bug, test, compile, etc. Refresh (save your work into the patch): hg qrefresh Repeat a few times. Rename the patch (because your first name wasn't appliable): hg qrename refactor_the_whatsit Create a new patch to try a logically separate part of the same bug: hg qnew rip_out_the_old_thing Repeat the process a few times, until you have solved the problem. During this time, it can often be useful to go back and forth between patches: hg qpop # unapply a patch hg qpush # reapply a patch hg qpop -a # unapply all patches hg qpush -a # reapply all patches Combine all the patches into a single patch, which you submit to bugzilla: hg qpush -a hg qdiff --rev qparent:. > my_wonderful_patch.patch Commit the patches to your local patch repository, in case you make a mistake (You might do this periodically): hg qcommit -m "Some message. Doesn't have to be good, this won't be committed to the repository, it's just for you" Go back to the old patches and fiddle with them based on feedback:
hg qpopThe workflow is detailed on the contribution page: hg qrefresh etchttps://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
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!
[[Category:New Contributor Landing Page]]
