JavaScript:New to SpiderMonkey: Difference between revisions

Jump to navigation Jump to search

JavaScript:New to SpiderMonkey (view source)

Revision as of 13:37, 21 September 2020

2,967 bytes removed ,  21 September 2020
remove a bunch of old content
m (typo)
(remove a bunch of old content)
Line 71: Line 71:


You'll need that later.  
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 =====
===== Compare =====
Line 107: Line 93:
To get the patch from mercurial, use:  
To get the patch from mercurial, use:  


hg qdiff # if you're using queues or
  hg diff  # if you're not
  hg diff  # if you're not


Add it to the bug as an attachment.  
Add push it using moz-phab. See https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html#to-submit-a-patch for more information.


=== Get a review ===
=== Get a review ===
Line 190: Line 175:
=== Coding Style ===
=== 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 exceptions, and generally avoid virtual functions for core data, 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.
SpiderMonkey uses the same coding style as Firefox. Please see https://firefox-source-docs.mozilla.org/code-quality/coding-style/index.html for more details


=== Workflow ===
=== Workflow ===
Line 197: Line 182:


==== Sample Workflows ====
==== 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]
[https://blog.mozilla.org/sfink/2017/06/01/sfink-mozilla-workflow/ Steve Fink: Mozilla workflow]
Line 220: Line 203:
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:


[extensions]
mq =
   
   
  [ui]
  [ui]
Line 247: Line 228:
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.
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 ===
==== Example workflow ====
 
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 qpop
The workflow is detailed on the contribution page:
hg qrefresh
https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
etc


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]]
[[Category:New Contributor Landing Page]]
Sylvestre
Account confirmers, Anti-spam team, Bureaucrats, canmove, Confirmed users, Module owners and peers, smwadministrator, smwcurator, Administrators, MozillaWiki team, Widget editors
731

edits

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

Navigation menu