Also add more AjsHeap pool sizes for measurements. The resulting pool
total size is >128kB, but only a small part of it is used. It's good
to have pool entries with 4-byte increments in the low range so that
actual used sizes can be more easily seen.
Print out the massif graph and a grepped "maximum usage" to get some
quick idea of how much memory a certain ecmascript testcase uses at
the moment. Used for e.g. a hello world memory usage test. Usage is:
"make massif-test-dev-hello-world" or "make massif-XXX" for any other
test in ecmascript-testcases/. A few convenience targets like
massif-helloworld are included.
Set --peak-inaccuracy=0.0 for massif run to get as accurate a peak
estimate as possible. (This is not that important because the measure
itself is not 100% relevant.)
Also adds a testcase needed by massif-helloworld target.
This target is used during development and the git pull just brings the
Duktape binaries up-to-date from duktape-releases. For offline use it's
nice not to fail a 'make site' when network is not available.
The 'make dist-site' target also does a git pull and won't allow an error.
By default dukweb.js gets a shallow stack intended for embedded
environments. This results in C recursion limits being hit for
large expression that work fine on the command line, see e.g.
GH-67.
Some system simulators have no network support or the network support is a
pain to configure. An ISO dist package allows easier testing. The ISO
target is now a separate target to avoid increasing the util requirements
for e.g. Cygwin builds.
The default is a barebones build and it happens without any specific options.
This is a better default for people trying Duktape out for the first time.
Without this, newer Emscripten will emit a memory init file which is more
awkward than passing around a single file. This change fixes the current
Dukweb REPL page. Using an explicit memory init file would of course also
be possible and a better fix might be to use the Emscripten default.
Immediate assignment avoids multiple evaluation and removes potential to
race with e.g. build timestamps. The changes made here don't really have
an impact because e.g. GIT_DESCRIBE won't change during a build.
With -f the rm command should not fail unless something is really wrong,
so wrong that we should stop, so a preceding minus is not necessarily a
good idea.
With this change, building an old Duktape version will use a specific
version of the closure compiler, so that changes in the closure compiler
won't trigger unexpected InitJS bugs. Apparently minifying can sometimes
break code, depending on what options are used.