Commit 3d67f89 ("fix generation of v8 constants on freebsd") is an
unfortunate victim of this rollback.
Revert "dtrace: fix generation of v8 constants on freebsd"
Revert "dtrace: More style"
Revert "dtrace: Make D style more D-ish"
Revert "dtrace: x64 ustack helper"
Revert "dtrace: fix style in ustack helper"
Revert "dtrace: SeqAsciiString was renamed to SeqOneByteString in v8"
This reverts commit 3d67f89552.
This reverts commit 321b8eec08.
This reverts commit 38df9d51a2.
This reverts commit f9afb3f010.
This reverts commit 13296e4b13.
This reverts commit 3b715edda9.
Noteworthy installer improvements provided here:
* Support in the Installer UI for not installing shortcuts.
* Support in the Installer UI for choosing a custom install directory.
* Command line support for not installing shortcuts (ADDDEFAULT=nodejs)
* Command line support for custom install directory (INSTALLDIR=c:\tools\node)
Every constant is certainly 4 bytes now, but freebsd's objdump utility
prints out odd byte sequences (5-bytes, 6-bytes and even 9-bytes long)
for v8's data section. We can safely ignore all upper bytes, because all
constants that we're using are just `int`s. Since on all supported
platforms `int` is 32bit long (and anyway v8's constants are 32bit too),
we ignore all higher bits if they were read.
Make tools/install.py work with python 2.5
2.5 is still fairly widespread and does not include a json lib as
standard. Most python folk will have simplejson if they are in that
boat.
In general it seems a bit tricky to solve this perfectly...
Tests can leave the tty in non-blocking mode. If the test runner tries
to print to stdout/stderr after that and the tty buffer is full, it'll
die with a EAGAIN OSError. Ergo, put the tty back in blocking mode
before proceeding.
Noted in @shtylman's #3898, API stability notes are easy to overlook
in the html documentation. This can be especially troublesome if the API
is deprecated. This commit gives visual feedback by adding in a class
to the html docs when they're generated. The API headers with
corresponding colors are also listed in the 'About this Documentation'
page for easy reference.
This "portable" mode rewrites the npm shebang to use the "node" executable
in the same directory relative to the "npm" script. This makes the "npm"
script "just work" even when "node" is not in the user's $PATH.
This mode is necessary for the precompiled binary packages that may potentially
be extracted to anywhere. The regular shebang-rewriting logic would normally
set the npm script's shebang to "/bin/node" which will not be present on anyone's
machine. In the end, we want the precompiled packages to be as user-friendly as
possible.