`ALLOW_MEMORY_GROWTH=1` allows to grow the wasm vm memory space as
needed and avoid out-of-memory issues. This is for development
purpose, production build will want to set memory size to something
that is fit the application (I don't remember the actual option name,
but removing ALLOW_MEMORY_GROWTH=1 from the compilation, and
re-running the app will display the good option to use).
Using read/write/exec causes an error (or possibly abort) on systems
with W^X policies (like OpenBSD and NetBSD have by default).
Since the heap does not need to be executable, just use read/write.
When mmap fails it returns MAP_FAILED, not NULL. POSIX does not
define the value for MAP_FAILED, but on at least the BSDs and Linux
its value is ((void *) -1).
Use find instead of any so load-mime-types will get the filename
instead of #t when a mime.types file is found. Otherwise an error
occurs in load-mime-types.
tl;dr process-running? would always return #f on OpenBSD and
NetBSD, and in the one-argument case it would always return #t
on DragonFly.
To get the process information from the process table on OpenBSD
and NetBSD, we need to pass 6 level names to sysctl instead of 4.
Passing the wrong number of level names to sysctl has caused it
to always fail, which in turn caused process-running? to always
return #f:
(process-running? 1) => #f
(process-running? (current-process-id)) => #f
and so on.
After the above fix, we also need to check the amount of data
actually filled in by sysctl. It appears that on OpenBSD, NetBSD
and DragonFly, if the requested process doesn't exist then sysctl
will return with a return value of 0 and just not actually fill in
the given structure. This caused process-running? to return #t
when no process with the given PID existed:
(process-running? -1) => #t
(process-running? <other nonexistent pid>) => #t
and so on.
I have tested on OpenBSD, NetBSD, DragonFly BSD and FreeBSD, and
process-running? now behaves as expected on all of them.
To get the repository path in Chicken 5, we not only have to require the
chicken.platform module, we also need to take the car of the result
since it now returns a list.
The method snow-chibi used to get the version of Chicken installed
doesn't work with Chicken 5. Adding "-R chicken.platform" would make it
work with Chicken 5, but then it wouldn't work with Chicken 4.
In both Chicken 4 & 5, however, csi has a -release option that will just
give the version number. So, I've changed the Chicken version detection
in snow-chibi to use this option.
Testing with...
./chibi-scheme tools/snow-chibi.scm implementations
...then seemed to work with both Chicken 4 & 5.
