newlispfanclub.alh.net

ho ho ho ..

I just rolled down trough the white Ftp-forest and found a package labeled:
*** newlisp-9.0.12.tgz ***

On the small note beside it it said:



the newLISP-tk installer now contains a file md5-checksums.txt with
checksums for newlisp-tk.exe, newlisp.exe and newlisp.dll

bit not ~ was still on 32 bits now 64 like all integer arithmetik since 9.0

all buffer variables moved to size_t and ssize_t type in preparation for
64-bit model LP64 compile for 64-bit memory addressing.

get-char, get-int, get-float and get-string failed when using on 64-bit
addresses, which where not converted correctly on little-endian CPUs.
This affected the mysql.lsp and mysql5.lsp modules when using with newLISP
versions 8.9.7 and later and on Intel CPUs. On Mac PPC and other big-endian
architectures this problem did not occur. All other modules where not affected
on any architecture.

<,>,<=,>=,= when given only one argument cimpare agains 0, "" or () all other
all other data types return true as before
(<1>nil, (= 0) =>true, (> "abc") => true, (= "") =>true etc.

64-bit file poisitioning fixed under Win32 (now runs qa-lfs)

<,>,<=,>=,= when given only one argument compare agains 0, "" or ()

Please don't use this feature yet, as it causes memory management problems.

Lutz

development version 9.0.12 has been withdrawn, 9.0.13 later today

Lutz

~ was still on 32 bits

Thanks for fixing ~. I was wondering why my crc16 code had stopped working. Until today I had been using a pre-8.9.7 dll because of that problem. Now it's fixed and I'm back in step with everyone else.

-- Sam

Normally I only fix bugs I know about ;-)

Lutz

ps: ~ still is wrong, now it takes 64bit arguments but still only returns 32bits, probably in your calculations this did not matter.