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.