Add make make OS_ID=0.n.m for building other platforms. See my blog.
Minor changes to build process for HaikuOS (POSIX binding, of course)
Requested consistency changes to the borrowed code from Haiku porting FAQ
Merge pull request #53 from hostilefork/haiku-os-build

Minor changes to build process for HaikuOS (POSIX binding, of course)
use parse for macro constructor
add SET-ENV, tweaks to host api for environment string handling
Fix spaces-instead-of-tabs that slipped into /src/os/posix/host-lib.c
Fix missing /local in make-boot.r

Due to the missed /local, the global `data` is overwritten. Currently,
this only results in a weird informational message (compressed code
beeing much larger than the supposedly uncompressed code).

But it also result in the uncompressed original code becoming
unavailable after compression. This is a nuisance, if we want to emit
uncompressed code for whatever reason.
Merge pull request #57 from earl/misc-fixes

Fix missing /local in make-boot.r
Update src/boot/actions.r

Corrected misspelled word in head?  definition; 
from 
begininnt
to
begininng
fix a typo
Fix a regression in PARSE for the THRU keyword

Commit 44012cc1e7313f2fd3772e543f2f8b9096d90f9c introduced a regression
to PARSE that may lead a failing THRU to incorrectly reset the parse
position. This, in turn, leads to endless loops in PARSE. A testcase
showing this regression is:

    parse "123.123." [any [thru "123"]]

This same regression also caused an endless loop in the `make prep` step
of the R3 build.

Technically, the earlier commit always incremented the match position
with the number of characters for skipping a successful THRU, without
checking if the THRU match itself was successful. For unsuccesful
matches, `NOT_FOUND` is returned, which is defined as -1. Adding the
THRU offset to this may result in a position that is again within bounds
of the data to be parsed, thereby potentially initiating an endless
loop.

This commit fixes the regression by adding an explicit check against
NOT_FOUND to the increment condition.

The regression was originally noted by user "dt2" on Stack Overflow
chat.
two memcpy to memmove changes, fix use of uninitialized err value
Match  "uncased" parse in Check_Bit by inverting HAS_CASE(parse)
Fix crash in evaluation of immediate operators (op! values)

The `ET_OPERATOR` case in `Do_Next` potentially dereferences a null
pointer in `word`.

For the regular case when an op! is evaluated indirectly via word lookup
(as in `do [1 + 2]`), the `word` variable will is properly initialised
during the lookup before entering the operator evaluation.

If, however, an op! is evaluated directly (e.g. `do reduce [1 :+ 2]`),
`word` will still be initialised to `0` and the attempt to look up the
name associated with the operator in VAL_WORD_SYM(word) will dereference
a null pointer.

We fix this in analogue to the implementation for immediate functions,
by also using the internal "-unnamed-" placeholder (`ROOT_NONAME`) for
immediate operators.

This bug was found via static code analysis with the Clang Static
Analyzer.

Fixes CureCode bug 1934.
Fix crash when reading dns:// without a hostname

Previously, `read dns://` crashed the interpreter. With this fix, a
dns:// spec without a hostname (or IPv4 address) is considered invalid
for READ access:

    >> read dns://
    ** Access error: invalid spec or options: dns://

Fixes the crash reported in CureCode issue #1935.
Allow INDEX? of NONE, returning NONE

This makes INDEX? "NONE-transparent", in line with the already
none-transparent EMPTY? and LENGTH?:

    >> index? none
    == none

This implements CureCode wish #1611.
Remove redundant code

The A_INDEXQ and A_LENGHTQ cases would already fall through to A_TAKE
containing precisely the same `if` (making the `if` redundant in case
the condition is true) and then falls through further to the `trap_it`
block (making the `goto` redundant in case the `if` condition is false).
Move NONE! to end of INDEX? & LENGTH? typespecs
parse thru fix