Release 9.0.12

[newdep]

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)

[Lutz]

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

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

Lutz

[Lutz]

development version 9.0.12 has been withdrawn, 9.0.13 later today

Lutz

[Sammo]

~ 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

[Lutz]

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.