- added option/improvements in 'bayes-query'
- more cleanup in context system
- speedup in 'parse' with regular expressions for big files
- bug fixes
for files and change notes see http://newlisp.org/downloads/development/
Lutz
ps: I bumped up the release date for 8.8 10 days to Feb 20th, to give more time trying the new manual approach and make sure that changes in the context system are Ok.
Just discovered that after 8.7.0 (at least from 8.7.6 and later) newlisp doesn't
handle my locale:
newLISP v.8.7.9 on linux, execute 'newlisp -h' for more info.
> (setq a "тест") ; plain cyrillic letters here
"212197211212"
> a
"212197211212"
>
...nevertheless, cyrillic letters in symbol names are not translated.
My locale is ru_RU.KOI8-R and other programs works fine with it.
newlisp is compiled with readline and without unicode.
version 8.7.0 and prior shows plain letters well.
That is only for the string returned on the command-line, if you print it it should be fine:
> (println (char 937))
Ω
"206169"
>
The print should show a Greek omega character in your browser, if it is UTF-8 enabled.
Perhaps we need an additional option in 'set-locale' to turn this on or off for characters > 126 ?
Lutz
The next version will do the raw string output on the commandline only when the default "C" locale is selected.
Lutz
Hmm... If raw output means no translation to codes, I think the behavior should be inverse:
Locale "C" have only first 127 characters defined, so it's ok to translate 128+ chars to their codes.
Other (most) locales have defined addidtional 128+ characters, so it's mostly ok to not to translate them.
Yes, that is what I meant, so for all upper ASCII you see nnn in the "C" locale but if a different locale is set, upper ASCII will be displayed as the locale's character.
Lutz
Thanx! It would be very nice!
Some Tru64 notes:
1) The build script recognizes Tru64 now, and compiles, BUT there is no 'exit' at the end:
Quote
OSF1)
echo Discovered True64 Unix, please read doc/TRU64BUILD
make -f makefile_tru64
;;
Therefore the make always ends with the message that it does not recognize the platform, in spite of having compiled the binary already.
2) The float problem is still there:
Quote
Discovered True64 Unix, please read doc/TRU64BUILD
cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET newlisp.c
cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-symbol.c
cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-math.c
cc: Warning: nl-math.c, line 2206: In this statement, underflow occurs in evaluating the expression "1e-308". (underflow)
Qchi2[idx] += log(1e-308) * -2.0;
---------------------------^
cc: Warning: nl-math.c, line 2211: In this statement, underflow occurs in evaluating the expression "1e-308". (underflow)
Pchi2[idx] += log(1e-308) * -2.0;
---------------------------^
cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-list.c
cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-liststr.c
cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-string.c
cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-filesys.c
cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-sock.c
cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-import.c
cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-xml.c
cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-web.c
cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-matrix.c
cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-debug.c
cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET tru64.c
cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET pcre.c
cc newlisp.o nl-symbol.o nl-math.o nl-list.o nl-liststr.o nl-string.o nl-filesys.o nl-sock.o nl-import.o nl-xml.o nl-web.o nl-matrix.o nl-debug.o tru64.o pcre.o -taso -lm -lrt -ldb -lbsd -Lffi-tru64-4.0 -lffi -o newlisp
strip newlisp
Shall I add a macro to workaround this issue?
Peter
sorry, forgot about this. I will put:
log(3e-308)
in the next version, which is slightly bigger than the IEE-754 and doesn't matter for the algrorithm used and will be fine with TRU64.
Lutz