User-visible changes between 0.4.0 and 0.5.0:
Changes in behaviour:
There are now two engines: the fast engine (gforth-fast) is at least
as fast as gforth in earlier releases; the debugging engine (gforth)
supports precise backtracing for signals (e.g., illegal memory
access), but is slower by a factor of 1-2.
Block files now start at block 0 by default (instead of block 1). If
you have block files around, prepend 1024 bytes to convert them, or
do a "1 OFFSET !" to establish the old behaviour.
Gforth now does not translate newlines to LFs on reading. Instead,
READ-LINE now interprets LF, CR, and CRLF as newlines. Newlines on
output are in the OSs favourite format.
SEE now disassembles primitives (or hex-DUMPs the code if no
disassembler is available).
>HEAD (aka >NAME) now returns 0 (instead of the nt of ???) on failure.
Syntax of prim changed: stack effects are now surrounded by
parentheses, tabs are insignificant.
Operating environment:
Gforth now produces a backtrace when catching an exception.
On platforms supporting the Unix 98 SA_SIGINFO semantics, you get more
precise error reports for SIGSEGV and SIGFPE (e.g., "stack
underflow" instead of "Invalid memory address").
Gforth now produces exit code 1 if there is an error (i.e., an
uncaught THROW) in batch processing.
You can use "gforthmi --application ..." to build an image that
processes the whole command-line when invoked directly (instead of
through gforth -i).
Ports:
AIX.
20% speedup on 604e under powerpc-unknown-linux-gnu,
19%-29% speedup on Celeron with gcc-2.95.
New words:
Missing ANS Forth words: EKEY EKEY? EKEY>CHAR
Timing words: CPUTIME UTIME
Vector arithmetic: V* FAXPY
FP comparison: F~ABS F~REL
Deferred words: <IS> [IS]
Nested number output: <<# #>>
Exception handling: TRY RECOVER ENDTRY
Directory handling: OPEN-DIR READ-DIR CLOSE-DIR FILENAME-MATCH
Other: ]L PUSH-ORDER
Miscellaneous:
Significant extensions to the manual (added an introduction, among
other things), many of them due to a new team member: Neal Crook.
Added assemblers and disassemblers for 386, Alpha, MIPS (thanks to
contributions by Andrew McKewan, Bernd Thallner, and Christian
Pirker). Contributions of assemblers and disassemblers for other
architectures are welcome.
The patch against regcomp.c (uninitialized variable) has been fed back
to the perl maintainers. The others are more like workarounds for known
toolchain problems and not fed back (for now).
The hints/netbsd.sh file has an additional change: the perl buildin malloc
(which is disabled in pkgsrc builds via configure arguments anyway) is now
disabled in the hints file as well. This makes it possible to build a
working perl outside of pkgsrc with this hints file. Wheter this hints file
should be fed back is subject to further discussion.
Make perl not build against a dynamic libperl.so.
There are two reasons: (a) the dynamic libperl.so version does not work
at all on sparc64, and (b) the static linked version is said to have a
significant performance improvement on some platforms (i.e. sparc). I think
the libperl.so was enabled by accident when switching from perl 5.0.4 to
5.6.0.
Other packages using libperl.so should not depend on perl5-base but on
../libperl.
* Fix `define' so that it tracks bound variables and ignores
shadowed keywords when traversing code
* Added checks to compilation process for the kind of missing
shared-library problems that many people see
* Fixed the `install-aliases' shell script
libintl for i18n needs. Changes since version 0.12.4 are *lots* of bug
fixes, module namespace reorganization, several _incompatible_ VM changes,
and the addition of several new modules, including a safe-interpreter for
untrusted bytecodes.
lang/python upgraded to 2.0
lang/py-html-docs upgraded to 2.0
misc/py-readline upgraded to 2.0
databases/py-gdbm upgraded to 2.0
x11/py-Tk upgraded to 2.0
devel/py-curses upgraded to 2.0
lang/py-extclass upgraded to 2.2.2 and for Python 2.0
textproc/py-dtml upgraded to 2.2.2 and for Python 2.0
www/py-zpublisher upgraded to 2.2.2 and for Python 2.0
print/py-reportlab upgraded to 1.01 and for Python 2.0
More coming...
doesn't enable any functionality. It is here as a marker, so people building
binary packages know that these packages have version-specific features
that would make them incompatible with other point releases.. (such as
LKM's)
