You want to use the CHIBI_MODULE_PATH environment variable now,
not CHIBI_MODULE_DIR, and can use : separators as expected.
The default main now also accepts -I<dir> and -A<dir> to prepend
or append module directories.
The default path is ".:./lib:$PREFIX/share/chibi". The first
two may be removed in a future version.
to have an SEXP_ prefix. Now all values from the headers
are prefixed with either sexp_ or SEXP_, important for ease
of embedding. "make USE_BOEHM=1" still works as an alias
for "make SEXP_USE_BOEHM=1".
Sorry if this patch breaks your code, it had to be done
sooner or later.
Each contexts keep a link to the heap which it is a part
of (when using the native GC), as well as a vector of
special globals that it needs quick access to (e.g. the
`quote' and `quasiquote', etc. symbols. You can use this
to manage multiple completely unrelated VMs in the same
application, and everything will be thread-safe.
The old behavior is still available by editing config.h,
which now includes somewhat better descriptions of all
the settings.
Using <u.h> and <libc.h> for plan9, no need for separate .i file
construction. Also mkfile now simplified and using /sys/src/cmd/mkone
(thanks to Charles Forsyth).
Notably no longer converting from function pointers <-> void*.
Remaining --pedantic warnings:
* ISO C90 does not support 'long long'
* ISO C90 does not support the 'z' printf length modifier
* ISO C90 does not support flexible array members
* ISO C90 forbids mixed declarations and code
* ISO C90 forbids specifying subobject to initialize
* anonymous variadic macros were introduced in C99
* invalid use of structure with flexible array member
The first one is only used when optional bignums are enabled,
and I have no intention of supporting bignums on systems w/o
long long (although it's not guaranteed two words fit in a
long long - I need to fix this).
The 'z' modifier is necessary for long types (you'd get
warnings the other way without it).
The next 4 are intentional - they make the code cleaner,
and all of these extensions are supported by Plan 9.
The last one is tricky. I think it refers to the fact
that not only am I using flexible array members, but I'm
using them as non-final alternates in a union. I'll have
to double check the semantics of this.
can disable with USE_BIGNUMS=0 - the interactions between this and
USE_FLONUMS are messy, so they will likely be merged into a single
option in the near future (i.e. you either have only fixnums, or a
full range of numeric types).
adding rationals based on this would be easy and is a likely future
feature. adding native support for complex numbers is unlikely.
