Commit 62f7fd61 authored by Jérémy Lal's avatar Jérémy Lal

Imported Upstream version 5.3.0~dfsg

parent 47b69cb4
root = true
[*]
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
[vcbuild.bat]
end_of_line = crlf
[*.{md,markdown}]
trim_trailing_whitespace = false
[{lib,src,test}/**.js]
indent_style = space
indent_size = 2
[src/**.{h,cc}]
indent_style = space
indent_size = 2
[test/*.py]
indent_style = space
indent_size = 2
[configure]
indent_style = space
indent_size = 2
[Makefile]
indent_style = tab
indent_size = 8
[{deps,tools}/**]
indent_style = ignore
indent_size = ignore
end_of_line = ignore
trim_trailing_whitespace = ignore
charset = ignore
......@@ -6,6 +6,7 @@ Alexey Kupershtokh <alexey.kupershtokh@gmail.com> <wicked@alawar.com>
Alexis Campailla <alexis@janeasystems.com> <orangemocha@github.com>
Alexis Sellier <self@cloudhead.net>
Alexis Sellier <self@cloudhead.net> <alexis@cloudhead.io>
Andy Bettisworth <andy.bettisworth@accreu.com>
Aria Stewart <aredridel@dinhe.net> <aredridel@nbtsc.org>
Arlo Breault <arlolra@gmail.com>
Artem Zaytsev <a.arepo@gmail.com>
......@@ -19,15 +20,20 @@ Bert Belder <bertbelder@gmail.com> <piscisaureus@Berts-MacBook-Pro.local>
Brandon Benvie <brandon@bbenvie.com> <brandon@brandonbenvie.com>
Brian White <mscdex@mscdex.net>
Brian White <mscdex@mscdex.net> <mscdex@gmail.com>
Caleb Boyd <caleb.boyd@gmail.com>
Charles <ineedpracticing@gmail.com> <cydjudge@users.noreply.github.com>
Chew Choon Keat <choonkeat@gmail.com>
Charles Rudolph <charles.rudolph@originate.com>
Claudio Rodriguez <cjrodr@yahoo.com> <cr@fansworld.tv>
Colin Ihrig <cjihrig@gmail.com>
Christopher Lenz <cmlenz@gmail.com> <chris@lamech.local>
Dan Kaplun <dbkaplun@gmail.com> <dan@beardtree.com>
Daniel Berger <code+node@dpbis.net>
Daniel Chcouri <333222@gmail.com>
Daniel Gröber <darklord@darkboxed.org>
Daniel Gröber <darklord@darkboxed.org> <dxld@darkboxed.org>
Daniel Pihlström <sciolist.se@gmail.com>
Danny Nemer <hi@dannynemer.com> <DannyNemer@users.noreply.github.com>
Dave Pacheco <dap@joyent.com> <dap@cs.brown.edu>
David Siegel <david@artcom.de> <david.siegel@artcom.de>
Domenic Denicola <domenic@domenicdenicola.com>
......@@ -37,6 +43,8 @@ Einar Otto Stangvik <einaros@gmail.com>
Elliott Cable <me@ell.io>
EungJun Yi <semtlenori@gmail.com>
Evan Larkin <evan.larkin.il.com> <evan.larkin.iit@gmail.com>
Evan Lucas <evanlucas@me.com> <evan@btc.com>
Evan Lucas <evanlucas@me.com> <evan.lucas@help.com>
Farid Neshat <FaridN_SOAD@yahoo.com>
Fedor Indutny <fedor@indutny.com> <fedor.indutny@gmail.com>
Felix Böhm <felixboehm55@googlemail.com> <me@feedic.com>
......@@ -48,23 +56,29 @@ Gabriel de Perthuis <g2p.code@gmail.com>
Gil Pedersen <git@gpost.dk> <github@gpost.dk>
Henry Chin <hheennrryy@gmail.com>
Herbert Vojčík <herby@mailbox.sk>
Icer Liang <liangshuangde@163.com> <wizicer@users.noreply.github.com>
Igor Soarez <igorsoarez@gmail.com>
Igor Zinkovsky <igorzi@microsoft.com>
Isaac Z. Schlueter <i@izs.me>
Isaac Z. Schlueter <i@izs.me> <i@foohack.com>
Jake Verbaten <raynos2@gmail.com>
James Hartig <fastest963@gmail.com> <james.hartig@grooveshark.com>
Jan Krems <jan.krems@gmail.com> <jan.krems@groupon.com>
Jered Schmidt <tr@nslator.jp>
Jeremiah Senkpiel <fishrock123@rocketmail.com>
Jerry Chin <qinjia@outlook.com>
Joe Shaw <joe@joeshaw.org> <joeshaw@litl.com>
Johan Bergström <bugs@bergstroem.nu>
Johan Dahlberg <jfd@distrop.com> <dahlberg.johan@gmail.com>
Johann Hofmann <git@johann-hofmann.com>
Jonas Pfenniger <jonas@pfenniger.name> <jonas@stvs.ch>
Jonathan Ong <jonathanrichardong@gmail.com> <jonathanong@users.noreply.github.com>
Jonathan Persson <persson.jonathan@gmail.com> <jonathan.persson@creuna.se>
Jonathan Rentzsch <jwr.git@redshed.net>
Josh Erickson <josh@snoj.us>
Joshua S. Weinstein <josher19@users.sf.net>
Junliang Yan <john.yan1019@gmail.com>
Junliang Yan <jyan@ca.ibm.com> <jyan@ca.ibm.ca>
Jérémy Lal <kapouer@melix.org>
Jérémy Lal <kapouer@melix.org> <holisme@gmail.com>
Kai Sasaki Lewuathe <sasaki_kai@lewuathe.sakura.ne.jp>
......@@ -81,6 +95,8 @@ Malte-Thorben Bruns <skenqbx@gmail.com>
Malte-Thorben Bruns <skenqbx@googlemail.com>
Marcin Cieślak <saper@marcincieslak.com>
Marcin Cieślak <saper@marcincieslak.com> <saper@saper.info>
Marti Martz <thalamew@q.com>
Martial James Jefferson <martial.jefferson@gmail.com>
Mathias Pettersson <mape@mape.me>
Matthew Lye <muddletoes@hotmail.com>
Michael Bernstein <michaelrbernstein@gmail.com>
......@@ -95,16 +111,20 @@ Nicholas Kinsey <pyrotechnick@feistystudios.com>
Nikolai Vavilov <vvnicholas@gmail.com>
Onne Gorter <onne@onnlucky.com>
Paul Querna <pquerna@apache.org> <paul@querna.org>
Peter Flannery <pflannery@users.noreply.github.com>
Phillip Johnsen <johphi@gmail.com> <phillip.johnsen@finn.no>
Ray Morgan <rmorgan@zappos.com>
Ray Solomon <raybsolomon@gmail.com>
Raymond Feng <enjoyjava@gmail.com> <raymond@strongloop.com>
Rick Olson <technoweenie@gmail.com>
Roman Klauke <romaaan.git@gmail.com> <romankl@users.noreply.github.com>
Roman Reiss <me@silverwind.io>
Ron Korving <rkorving@wizcorp.jp>
Ryan Dahl <ry@tinyclouds.org>
Ryan Emery <seebees@gmail.com>
Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Sam Mikes <smikes@cubane.com>
Sam P Gallagher-Bishop <samgallagherb@gmail.com> <SPGB@users.noreply.github.com>
Sam Shull <brickysam26@gmail.com> <brickysam26@samuel-shulls-computer.local>
Sam Shull <brickysam26@gmail.com> <sshull@squaremouth.com>
Sambasiva Suda <sambasivarao@gmail.com>
......
......@@ -517,7 +517,7 @@ Cam Swords <cam.swords@gmail.com>
Paul Loyd <pavelko95@gmail.com>
Benjamin Waters <benjamin.waters@outlook.com>
Lev Gimelfarb <lev.gimelfarb@gmail.com>
pflannery <pflannery@users.noreply.github.com>
Peter Flannery <pflannery@users.noreply.github.com>
Tuğrul Topuz <tugrultopuz@gmail.com>
Lorenz Leutgeb <lorenz.leutgeb@gmail.com>
ayanamist <contact@ayanamist.com>
......@@ -565,7 +565,7 @@ Feross Aboukhadijeh <feross@feross.org>
Refael Ackermann <refack@gmail.com>
Taojie <taojie.hjp@taobao.com>
Greg Sabia Tucker <greg@tucke.rs>
Dan Kaplun <dan@beardtree.com>
Dan Kaplun <dbkaplun@gmail.com>
Colin Ihrig <cjihrig@gmail.com>
Greg Sabia Tucker <greg@narrowlabs.com>
Mark Stosberg <mark@rideamigos.com>
......@@ -580,7 +580,7 @@ Roman Klauke <romaaan.git@gmail.com>
Xavi Magrinyà <xavi.mb89@gmail.com>
Euan <euank@euank.com>
Ed Morley <emorley@mozilla.com>
Charles <cydjudge@users.noreply.github.com>
Charles <ineedpracticing@gmail.com>
Jan Krems <jan.krems@gmail.com>
Fred K. Schott <fschott@box.com>
Chris Dickinson <christopher.s.dickinson@gmail.com>
......@@ -648,7 +648,7 @@ Bryce Kahle <bkahle@gmail.com>
The Gitter Badger <badger@gitter.im>
Brendan Ashworth <squirrelslikeacorns@gmail.com>
Jose Luis Rivas <me@ghostbar.co>
Evan Lucas <evan@btc.com>
Evan Lucas <evanlucas@me.com>
Vincent Weevers <mail@vincentweevers.nl>
Tyler Kellen <tyler@sleekcode.net>
Evan Torrie <evan.torrie@yahoo.com>
......@@ -669,7 +669,6 @@ Calvin Metcalf <calvin.metcalf@state.ma.us>
Eric Mill <eric@konklone.com>
pkcs <pkcs@gmx.com>
James M Snell <jasnell@gmail.com>
Evan Lucas <evanlucas@me.com>
Cydox <farr.janhendrik@aol.de>
Steven Rockarts <srockarts@invidi.com>
Vladimir Guguiev <wizardzloy@gmail.com>
......@@ -690,7 +689,7 @@ Glen Keane <glenkeane.94@gmail.com>
Xiaowei Li <446240525@qq.com>
toastynerd <tylermorgan86@gmail.com>
Todd Kennedy <todd@selfassembled.org>
Icer Liang <wizicer@users.noreply.github.com>
Icer Liang <liangshuangde@163.com>
Stephen Belanger <admin@stephenbelanger.com>
Jeremiah Senkpiel <fishrock123@rocketmail.com>
Brendan Ashworth <brendan.ashworth@me.com>
......@@ -794,7 +793,7 @@ Oleksandr Chekhovskyi <oleksandr.chekhovskyi@hansoft.com>
Tristian Flanagan <tflanagan@datacollaborative.com>
Mike Tunnicliffe <mike.tunnicliffe@uk.ibm.com>
Ionică Bizău <bizauionica@gmail.com>
Danny Nemer <DannyNemer@users.noreply.github.com>
Danny Nemer <hi@dannynemer.com>
Sven Slootweg <jamsoftgamedev@gmail.com>
Dmitry Vasilyev <vaseker@gmail.com>
Malcolm Ahoy <malcolmahoy@gmail.com>
......@@ -810,5 +809,64 @@ Michał Gołębiowski <m.goleb@gmail.com>
Johann Hofmann <git@johann-hofmann.com>
Charles Rudolph <charles.rudolph@originate.com>
Dave Eddy <dave@daveeddy.com>
Justin Chase <justin@evolvelabs.com>
Jeremy Whitlock <jwhitlock@apache.org>
Rod Machen <mail@rodmachen.com>
Martial James Jefferson <martial.jefferson@gmail.com>
Doug Shamoo <doug.shamoo@gmail.com>
Junliang Yan <jyan@ca.ibm.com>
Dave Hodder <dmh@dmh.org.uk>
Jason Karns <jason.karns@gmail.com>
Balázs Galambosi <galambalazs@yahoo.co.uk>
David Boivin <dave.a.boivin@gmail.com>
Liang-Chi Hsieh <viirya@appier.com>
Timothy Gu <timothygu99@gmail.com>
Fábio Santos <fabiosantosart@gmail.com>
Myles Borins <mborins@us.ibm.com>
Jonas Dohse <jonas@dohse.ch>
Коренберг Марк <mark@ideco.ru>
Caleb Boyd <caleb.boyd@gmail.com>
Yuval Brik <yuval@brik.org.il>
Claudio Rodriguez <cjrodr@yahoo.com>
Ido Ben-Yair <idoby@wix.com>
Kyle Smith <kyle.r.smiff@gmail.com>
Marti Martz <thalamew@q.com>
Stefan Budeanu <stefan@budeanu.com>
Emily Aviva Kapor-Mater <emily@emilyaviva.com>
Sam P Gallagher-Bishop <samgallagherb@gmail.com>
David Woods <david@birnamdesigns.com>
Ashok Suthar <coderatlabs@gmail.com>
Ömer Fadıl Usta <omerusta@gmail.com>
Jerry Chin <qinjia@outlook.com>
Hemanth.HM <hemanth.hm@gmail.com>
Hugues Malphettes <hmalphettes@gmail.com>
Tyler Henkel <tylerhenkel@hotmail.com>
Zheng Chaoping <zbinlin@gmail.com>
Ashley Williams <ashley666ashley@gmail.com>
Bryan English <bryan@bryanenglish.com>
Devin Nakamura <devinn@ca.ibm.com>
Vladimir Varankin <nek.narqo+git@gmail.com>
Manuel B <baslr@users.noreply.github.com>
Jesse McCarthy <git_commits@jessemccarthy.net>
Craig Cavalier <craigcav@gmail.com>
Michael Cornacchia <cornacch@ca.ibm.com>
Markus Tzoe <chou.marcus@gmail.com>
Martin Forsberg <git@martinforsberg.se>
Carl Lei <xecycle@gmail.com>
Lewis Cowper <lewis.cowper@googlemail.com>
Bryon Leung <teslaslegacy@gmail.com>
Chunyang Dai <chunyang.dai@intel.com>
Jonathan Persson <persson.jonathan@gmail.com>
Dave <dave@jut.io>
Luigi Pinca <luigipinca@gmail.com>
Peter A. Bigot <pab@pabigot.com>
Zirak <zirakertan@gmail.com>
Scott Buchanan <sbuchanan@ebay.com>
Rebecca Turner <rebecca@npmjs.com>
Bryce Baril <bryce@ravenwall.com>
Super Zheng <superzheng@tencent.com>
Rafał Pocztarski <r.pocztarski@gmail.com>
Michael Ruddy <mruddybtc@gmail.com>
Andy Bettisworth <andy.bettisworth@accreu.com>
# Generated by tools/update-authors.sh
This diff is collapsed.
......@@ -65,9 +65,11 @@ projects. Do not send your patch to us, we cannot accept it.
In case of doubt, open an issue in the
[issue tracker](https://github.com/nodejs/node/issues/) or contact one of the
[project Collaborators](https://github.com/nodejs/node/#current-project-team-members).
([IRC](http://webchat.freenode.net/?channels=io.js) is often the best medium.) Especially do so if you plan to work on something big. Nothing is more
Especially do so if you plan to work on something big. Nothing is more
frustrating than seeing your hard work go to waste because your vision
does not align with the project team.
does not align with the project team. Node.js has two IRC channels,
[#Node.js](http://webchat.freenode.net/?channels=node.js) for general help and questions, and
[#Node-dev](http://webchat.freenode.net/?channels=node-dev) for development of node core specifically.
### Step 2: Branch
......
......@@ -349,8 +349,8 @@ Instructions:
* [CODE_OF_CONDUCT.md](./CODE_OF_CONDUCT.md)
* [CONTRIBUTING.md](./CONTRIBUTING.md)
* [GOVERNANCE.md](./GOVERNANCE.md)
* IRC:
[#io.js on Freenode.net](http://webchat.freenode.net?channels=io.js&uio=d4)
* IRC (general questions): [#node.js on Freenode.net](http://webchat.freenode.net?channels=node.js&uio=d4)
* IRC (node core development): [#node-dev on Freenode.net](http://webchat.freenode.net?channels=node-dev&uio=d4)
* [nodejs/node on Gitter](https://gitter.im/nodejs/node)
## Security
......@@ -390,6 +390,7 @@ information about the governance of the Node.js project, see
### Collaborators
* [brendanashworth](https://github.com/brendanashworth) - **Brendan Ashworth** &lt;brendan.ashworth@me.com&gt;
* [calvinmetcalf](https://github.com/calvinmetcalf) - **Calvin Metcalf** &lt;calvin.metcalf@gmail.com&gt;
* [ChALkeR](https://github.com/ChALkeR) - **Сковорода Никита Андреевич** &lt;chalkerx@gmail.com&gt;
* [domenic](https://github.com/domenic) - **Domenic Denicola** &lt;d@domenic.me&gt;
* [evanlucas](https://github.com/evanlucas) - **Evan Lucas** &lt;evanlucas@me.com&gt;
......@@ -401,6 +402,7 @@ information about the governance of the Node.js project, see
* [julianduque](https://github.com/julianduque) - **Julian Duque** &lt;julianduquej@gmail.com&gt;
* [JungMinu](https://github.com/JungMinu) - **Minwoo Jung** &lt;jmwsoft@gmail.com&gt;
* [lxe](https://github.com/lxe) - **Aleksey Smolenchuk** &lt;lxe@lxe.co&gt;
* [mcollina](https://github.com/mcollina) - **Matteo Collina** &lt;matteo.collina@gmail.com&gt;
* [mhdawson](https://github.com/mhdawson) - **Michael Dawson** &lt;michael_dawson@ca.ibm.com&gt;
* [micnic](https://github.com/micnic) - **Nicu Micleușanu** &lt;micnic90@gmail.com&gt;
* [mikeal](https://github.com/mikeal) - **Mikeal Rogers** &lt;mikeal.rogers@gmail.com&gt;
......@@ -410,6 +412,7 @@ information about the governance of the Node.js project, see
* [petkaantonov](https://github.com/petkaantonov) - **Petka Antonov** &lt;petka_antonov@hotmail.com&gt;
* [qard](https://github.com/qard) - **Stephen Belanger** &lt;admin@stephenbelanger.com&gt;
* [rlidwka](https://github.com/rlidwka) - **Alex Kocharin** &lt;alex@kocharin.ru&gt;
* [rmg](https://github.com/rmg) - **Ryan Graham** &lt;r.m.graham@gmail.com&gt;
* [robertkowalski](https://github.com/robertkowalski) - **Robert Kowalski** &lt;rok@kowalski.gd&gt;
* [romankl](https://github.com/romankl) - **Roman Klauke** &lt;romaaan.git@gmail.com&gt;
* [saghul](https://github.com/saghul) - **Saúl Ibarra Corretgé** &lt;saghul@gmail.com&gt;
......
......@@ -30,7 +30,7 @@ valid_os = ('win', 'mac', 'solaris', 'freebsd', 'openbsd', 'linux',
valid_arch = ('arm', 'arm64', 'ia32', 'mips', 'mipsel', 'ppc', 'ppc64', 'x32',
'x64', 'x86')
valid_arm_float_abi = ('soft', 'softfp', 'hard')
valid_arm_fpu = ('vfp', 'vfpv2', 'vfpv3', 'vfpv3-d16', 'neon')
valid_arm_fpu = ('vfp', 'vfpv3', 'vfpv3-d16', 'neon')
valid_mips_arch = ('loongson', 'r1', 'r2', 'r6', 'rx')
valid_mips_fpu = ('fp32', 'fp64', 'fpxx')
valid_mips_float_abi = ('soft', 'hard')
......@@ -557,18 +557,13 @@ def cc_macros(cc=None):
def is_arch_armv7():
"""Check for ARMv7 instructions"""
cc_macros_cache = cc_macros()
return ('__ARM_ARCH_7__' in cc_macros_cache or
'__ARM_ARCH_7A__' in cc_macros_cache or
'__ARM_ARCH_7R__' in cc_macros_cache or
'__ARM_ARCH_7M__' in cc_macros_cache or
'__ARM_ARCH_7S__' in cc_macros_cache)
return cc_macros_cache.get('__ARM_ARCH') == '7'
def is_arch_armv6():
"""Check for ARMv6 instructions"""
cc_macros_cache = cc_macros()
return ('__ARM_ARCH_6__' in cc_macros_cache or
'__ARM_ARCH_6M__' in cc_macros_cache)
return cc_macros_cache.get('__ARM_ARCH') == '6'
def is_arm_hard_float_abi():
......@@ -589,7 +584,7 @@ def host_arch_cc():
# would be xlc so hard code gcc
k = cc_macros('gcc')
else:
k = cc_macros()
k = cc_macros(os.environ.get('CC_host'))
matchup = {
'__aarch64__' : 'arm64',
......@@ -636,7 +631,7 @@ def configure_arm(o):
else:
arm_float_abi = 'default'
arm_fpu = 'vfpv2'
arm_fpu = 'vfp'
if is_arch_armv7():
arm_fpu = 'vfpv3'
......
......@@ -2,7 +2,7 @@
<html lang="en">
<head>
<meta charset="utf-8">
<title> Node.js v5.2.0 Manual &amp; Documentation</title>
<title> Node.js v5.3.0 Manual &amp; Documentation</title>
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Lato:400,700,400italic">
<link rel="stylesheet" href="assets/style.css">
<link rel="stylesheet" href="assets/sh.css">
......@@ -61,7 +61,7 @@
<div id="column1" data-id="_toc" class="interior">
<header>
<h1>Node.js v5.2.0 Documentation</h1>
<h1>Node.js v5.3.0 Documentation</h1>
<div id="gtoc">
<p>
<a href="index.html" name="toc">Index</a> |
......
......@@ -2,7 +2,7 @@
<html lang="en">
<head>
<meta charset="utf-8">
<title>Addons Node.js v5.2.0 Manual &amp; Documentation</title>
<title>Addons Node.js v5.3.0 Manual &amp; Documentation</title>
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Lato:400,700,400italic">
<link rel="stylesheet" href="assets/style.css">
<link rel="stylesheet" href="assets/sh.css">
......@@ -61,7 +61,7 @@
<div id="column1" data-id="addons" class="interior">
<header>
<h1>Node.js v5.2.0 Documentation</h1>
<h1>Node.js v5.3.0 Documentation</h1>
<div id="gtoc">
<p>
<a href="index.html" name="toc">Index</a> |
......@@ -99,7 +99,7 @@
<div id="apicontent">
<h1>Addons<span><a class="mark" href="#addons_addons" id="addons_addons">#</a></span></h1>
<p>Addons are dynamically linked shared objects. They can provide glue to C and
<p>Addons are dynamically-linked shared objects. They can provide glue to C and
C++ libraries. The API (at the moment) is rather complex, involving
knowledge of several libraries:
......@@ -112,11 +112,11 @@ tree), which is also available <a href="https://v8docs.nodesource.com/">online</
</li>
<li><p><a href="https://github.com/libuv/libuv">libuv</a>, C event loop library. Anytime one needs to wait for a file
descriptor to become readable, wait for a timer, or wait for a signal
to be received one will need to interface with libuv. That is, if you
to be received, one will need to interface with libuv. That is, if you
perform any I/O, libuv will need to be used.</p>
</li>
<li><p>Internal Node.js libraries. Most importantly is the <code>node::ObjectWrap</code>
class which you will likely want to derive from.</p>
<li><p>Internal Node.js libraries. The most important class is <code>node::ObjectWrap</code>
which you will likely want to derive from.</p>
</li>
<li><p>Others. Look in <code>deps/</code> for what else is available.</p>
</li>
......@@ -131,7 +131,7 @@ be used as a starting-point for your own Addon.
</p>
<h2>Hello world<span><a class="mark" href="#addons_hello_world" id="addons_hello_world">#</a></span></h2>
<p>To get started let&#39;s make a small Addon which is the C++ equivalent of
<p>To get started, let&#39;s make a small Addon which is the C++ equivalent of
the following JavaScript code:
</p>
......@@ -172,12 +172,12 @@ NODE_MODULE(module_name, Initialize)</code></pre>
<code>node.h</code>).
</p>
<p>The <code>module_name</code> needs to match the filename of the final binary (minus the
.node suffix).
<p>The <code>module_name</code> needs to match the filename of the final binary (excluding
the .node suffix).
</p>
<p>The source code needs to be built into <code>addon.node</code>, the binary Addon. To
do this we create a file called <code>binding.gyp</code> which describes the configuration
do this, we create a file called <code>binding.gyp</code> which describes the configuration
to build your module in a JSON-like format. This file gets compiled by
<a href="https://github.com/nodejs/node-gyp">node-gyp</a>.
......@@ -195,7 +195,7 @@ current platform. Use <code>node-gyp configure</code> for that.
</p>
<p>Now you will have either a <code>Makefile</code> (on Unix platforms) or a <code>vcxproj</code> file
(on Windows) in the <code>build/</code> directory. Next invoke the <code>node-gyp build</code>
(on Windows) in the <code>build/</code> directory. Next, invoke the <code>node-gyp build</code>
command.
</p>
......@@ -203,7 +203,7 @@ command.
in <code>build/Release/</code>.
</p>
<p>You can now use the binary addon in an Node.js project <code>hello.js</code> by pointing
<p>You can now use the binary addon in a Node.js project <code>hello.js</code> by pointing
<code>require</code> to the recently built <code>hello.node</code> module:
</p>
......@@ -224,7 +224,7 @@ console.log(addon.hello()); // &#39;world&#39;</code></pre>
handles, scopes, function templates, etc.
</p>
<p>In order to use these examples you need to compile them using <code>node-gyp</code>.
<p>In order to use these examples, you need to compile them using <code>node-gyp</code>.
Create the following <code>binding.gyp</code> file:
</p>
......@@ -237,7 +237,7 @@ Create the following <code>binding.gyp</code> file:
]
}</code></pre>
<p>In cases where there is more than one <code>.cc</code> file, simply add the file name to
the <code>sources</code> array, e.g.:
the <code>sources</code> array. For example:
</p>
<pre><code>&quot;sources&quot;: [&quot;addon.cc&quot;, &quot;myexample.cc&quot;]</code></pre>
......@@ -341,7 +341,7 @@ to completely overwrite <code>exports</code> with a single function instead of
adding the function as a property of <code>exports</code>.
</p>
<p>To test it run the following JavaScript snippet:
<p>To test it, run the following JavaScript snippet:
</p>
<pre><code>// test.js
......@@ -445,8 +445,8 @@ var addon = require(&#39;./build/Release/addon&#39;);
var fn = addon();
console.log(fn()); // &#39;hello world&#39;</code></pre>
<h3>Wrapping C++ objects<span><a class="mark" href="#addons_wrapping_c_objects" id="addons_wrapping_c_objects">#</a></span></h3>
<p>Here we will create a wrapper for a C++ object/class <code>MyObject</code> that can be
instantiated in JavaScript through the <code>new</code> operator. First prepare the main
<p>Here, we will create a wrapper for a C++ object/class <code>MyObject</code> that can be
instantiated in JavaScript through the <code>new</code> operator. First, prepare the main
module <code>addon.cc</code>:
</p>
......@@ -466,7 +466,7 @@ void InitAll(Local&lt;Object&gt; exports) {
NODE_MODULE(addon, InitAll)
} // namespace demo</code></pre>
<p>Then in <code>myobject.h</code> make your wrapper inherit from <code>node::ObjectWrap</code>:
<p>Then, in <code>myobject.h</code>, make your wrapper inherit from <code>node::ObjectWrap</code>:
</p>
<pre><code>// myobject.h
......@@ -495,7 +495,7 @@ class MyObject : public node::ObjectWrap {
} // namespace demo
#endif</code></pre>
<p>And in <code>myobject.cc</code> implement the various methods that you want to expose.
<p>And in <code>myobject.cc</code>, implement the various methods that you want to expose.
Here we expose the method <code>plusOne</code> by adding it to the constructor&#39;s
prototype:
......@@ -580,7 +580,8 @@ console.log( obj.plusOne() ); // 12
console.log( obj.plusOne() ); // 13</code></pre>
<h3>Factory of wrapped objects<span><a class="mark" href="#addons_factory_of_wrapped_objects" id="addons_factory_of_wrapped_objects">#</a></span></h3>
<p>This is useful when you want to be able to create native objects without
explicitly instantiating them with the <code>new</code> operator in JavaScript, e.g.
explicitly instantiating them with the <code>new</code> operator in JavaScript. For
example:
</p>
<pre><code>var obj = addon.createObject();
......@@ -615,8 +616,9 @@ void InitAll(Local&lt;Object&gt; exports, Local&lt;Object&gt; module) {
NODE_MODULE(addon, InitAll)
} // namespace demo</code></pre>
<p>In <code>myobject.h</code> we now introduce the static method <code>NewInstance</code> that takes
care of instantiating the object (i.e. it does the job of <code>new</code> in JavaScript):
<p>In <code>myobject.h</code>, we now introduce the static method <code>NewInstance</code> that takes
care of instantiating the object. In other words, it does the job of <code>new</code> in
JavaScript:
</p>
<pre><code>// myobject.h
......@@ -742,9 +744,9 @@ console.log( obj2.plusOne() ); // 22
console.log( obj2.plusOne() ); // 23</code></pre>
<h3>Passing wrapped objects around<span><a class="mark" href="#addons_passing_wrapped_objects_around" id="addons_passing_wrapped_objects_around">#</a></span></h3>
<p>In addition to wrapping and returning C++ objects, you can pass them around
by unwrapping them with Node.js&#39;s <code>node::ObjectWrap::Unwrap</code> helper function.
In the following <code>addon.cc</code> we introduce a function <code>add()</code> that can take on two
<code>MyObject</code> objects:
by unwrapping them with the Node.js helper function <code>node::ObjectWrap::Unwrap</code>.
In the following <code>addon.cc</code>, we introduce a function <code>add()</code> that can take on
two <code>MyObject</code> objects:
</p>
<pre><code>// addon.cc
......@@ -788,7 +790,7 @@ void InitAll(Local&lt;Object&gt; exports) {
NODE_MODULE(addon, InitAll)
} // namespace demo</code></pre>
<p>To make things interesting we introduce a public method in <code>myobject.h</code> so we
<p>To make things interesting, we introduce a public method in <code>myobject.h</code> so we
can probe private values after unwrapping the object:
</p>
......@@ -819,7 +821,7 @@ class MyObject : public node::ObjectWrap {
} // namespace demo
#endif</code></pre>
<p>The implementation of <code>myobject.cc</code> is similar as before:
<p>The implementation of <code>myobject.cc</code> is similar to before:
</p>
<pre><code>// myobject.cc
......@@ -902,11 +904,11 @@ console.log(result); // 30</code></pre>
<li><code>callback</code>: <code>void (*)(void*)</code> - A pointer to the function to call at exit.</li>
<li><code>args</code>: <code>void*</code> - A pointer to pass to the callback at exit.</li>
</ul>
<p>Registers exit hooks that run after the event loop has ended, but before the VM
<p>Registers exit hooks that run after the event loop has ended but before the VM
is killed.
</p>
<p>Callbacks are run in last-in, first-out order. AtExit takes two parameters:
<p>Callbacks are run in last-in first-out order. AtExit takes two parameters:
a pointer to a callback function to run at exit, and a pointer to untyped
context data to be passed to that callback.
......
This diff is collapsed.
# Addons
Addons are dynamically linked shared objects. They can provide glue to C and
Addons are dynamically-linked shared objects. They can provide glue to C and
C++ libraries. The API (at the moment) is rather complex, involving
knowledge of several libraries:
......@@ -11,11 +11,11 @@ knowledge of several libraries:
- [libuv][], C event loop library. Anytime one needs to wait for a file
descriptor to become readable, wait for a timer, or wait for a signal
to be received one will need to interface with libuv. That is, if you
to be received, one will need to interface with libuv. That is, if you
perform any I/O, libuv will need to be used.
- Internal Node.js libraries. Most importantly is the `node::ObjectWrap`
class which you will likely want to derive from.
- Internal Node.js libraries. The most important class is `node::ObjectWrap`
which you will likely want to derive from.
- Others. Look in `deps/` for what else is available.
......@@ -28,7 +28,7 @@ be used as a starting-point for your own Addon.
## Hello world
To get started let's make a small Addon which is the C++ equivalent of
To get started, let's make a small Addon which is the C++ equivalent of
the following JavaScript code:
module.exports.hello = function() { return 'world'; };
......@@ -68,11 +68,11 @@ Note that all Node.js addons must export an initialization function:
There is no semi-colon after `NODE_MODULE` as it's not a function (see
`node.h`).
The `module_name` needs to match the filename of the final binary (minus the
.node suffix).
The `module_name` needs to match the filename of the final binary (excluding
the .node suffix).
The source code needs to be built into `addon.node`, the binary Addon. To
do this we create a file called `binding.gyp` which describes the configuration
do this, we create a file called `binding.gyp` which describes the configuration
to build your module in a JSON-like format. This file gets compiled by
[node-gyp][].
......@@ -89,13 +89,13 @@ The next step is to generate the appropriate project build files for the
current platform. Use `node-gyp configure` for that.
Now you will have either a `Makefile` (on Unix platforms) or a `vcxproj` file
(on Windows) in the `build/` directory. Next invoke the `node-gyp build`
(on Windows) in the `build/` directory. Next, invoke the `node-gyp build`
command.
Now you have your compiled `.node` bindings file! The compiled bindings end up
in `build/Release/`.
You can now use the binary addon in an Node.js project `hello.js` by pointing
You can now use the binary addon in a Node.js project `hello.js` by pointing
`require` to the recently built `hello.node` module:
// hello.js
......@@ -114,7 +114,7 @@ Below are some addon patterns to help you get started. Consult the online
[Embedder's Guide][] for an explanation of several concepts used such as
handles, scopes, function templates, etc.
In order to use these examples you need to compile them using `node-gyp`.
In order to use these examples, you need to compile them using `node-gyp`.
Create the following `binding.gyp` file:
{
......@@ -127,7 +127,7 @@ Create the following `binding.gyp` file:
}
In cases where there is more than one `.cc` file, simply add the file name to
the `sources` array, e.g.:
the `sources` array. For example:
"sources": ["addon.cc", "myexample.cc"]
......@@ -234,7 +234,7 @@ the full `module` object as the second argument. This allows the addon
to completely overwrite `exports` with a single function instead of
adding the function as a property of `exports`.
To test it run the following JavaScript snippet:
To test it, run the following JavaScript snippet:
// test.js
var addon = require('./build/Release/addon');
......@@ -344,8 +344,8 @@ To test:
### Wrapping C++ objects
Here we will create a wrapper for a C++ object/class `MyObject` that can be
instantiated in JavaScript through the `new` operator. First prepare the main
Here, we will create a wrapper for a C++ object/class `MyObject` that can be
instantiated in JavaScript through the `new` operator. First, prepare the main
module `addon.cc`:
// addon.cc
......@@ -365,7 +365,7 @@ module `addon.cc`:
} // namespace demo
Then in `myobject.h` make your wrapper inherit from `node::ObjectWrap`:
Then, in `myobject.h`, make your wrapper inherit from `node::ObjectWrap`:
// myobject.h
#ifndef MYOBJECT_H
......@@ -394,7 +394,7 @@ Then in `myobject.h` make your wrapper inherit from `node::ObjectWrap`:
#endif
And in `myobject.cc` implement the various methods that you want to expose.
And in `myobject.cc`, implement the various methods that you want to expose.
Here we expose the method `plusOne` by adding it to the constructor's
prototype:
......@@ -480,7 +480,8 @@ Test it with:
### Factory of wrapped objects
This is useful when you want to be able to create native objects without
explicitly instantiating them with the `new` operator in JavaScript, e.g.
explicitly instantiating them with the `new` operator in JavaScript. For
example:
var obj = addon.createObject();
// instead of:
......@@ -515,8 +516,9 @@ Let's register our `createObject` method in `addon.cc`:
} // namespace demo
In `myobject.h` we now introduce the static method `NewInstance` that takes
care of instantiating the object (i.e. it does the job of `new` in JavaScript):
In `myobject.h`, we now introduce the static method `NewInstance` that takes
care of instantiating the object. In other words, it does the job of `new` in
JavaScript:
// myobject.h
#ifndef MYOBJECT_H
......@@ -644,9 +646,9 @@ Test it with:
### Passing wrapped objects around
In addition to wrapping and returning C++ objects, you can pass them around
by unwrapping them with Node.js's `node::ObjectWrap::Unwrap` helper function.
In the following `addon.cc` we introduce a function `add()` that can take on two
`MyObject` objects:
by unwrapping them with the Node.js helper function `node::ObjectWrap::Unwrap`.
In the following `addon.cc`, we introduce a function `add()` that can take on
two `MyObject` objects:
// addon.cc
#include <node.h>
......@@ -690,7 +692,7 @@ In the following `addon.cc` we introduce a function `add()` that can take on two
} // namespace demo
To make things interesting we introduce a public method in `myobject.h` so we
To make things interesting, we introduce a public method in `myobject.h` so we
can probe private values after unwrapping the object:
// myobject.h
......@@ -721,7 +723,7 @@ can probe private values after unwrapping the object: