development release newLISP v.9.2.6

Started by Lutz, November 21, 2007, 10:35:33 AM

Previous topic - Next topic

Lutz

Additions and changes in both, the core newLISP executable and newLISP-GS.



for files and changes notes see:  http://newlisp.org/downloads/development/">http://newlisp.org/downloads/development/



Lutz

cormullion

#1
So far it works fine! (MacOS X Tiger 10.4.11 Intel). And more stuff in the manual too.

Lutz

#2
QuoteAnd more stuff in the manual too.


any improvements to the writing in the new chapter "17. Object Oriented Programming in newLISP" are greatly appreciated.



Lutz

newdep

#3
Hi Lutz,



Slackware 11.0   (where 9.2.5 compiled fine)>



$make linux_readline



make -f makefile_linux_readline

make[1]: Entering directory `/newlisp-9.2.6'

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE                             -DLINUX newlisp.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE                             -DLINUX nl-symbol.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE                             -DLINUX nl-math.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE                             -DLINUX nl-list.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE                             -DLINUX nl-liststr.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE                             -DLINUX nl-string.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE                             -DLINUX nl-filesys.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE                             -DLINUX nl-sock.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE                             -DLINUX nl-import.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE                             -DLINUX nl-xml.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE                             -DLINUX nl-web.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE                             -DLINUX nl-matrix.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE                             -DLINUX nl-debug.c

gcc -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DREADLINE -DLINUX pcre.c

gcc 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 pcre.o -g -lm -ldl -lreadline -lncurses -o newlisp

/usr/lib/gcc/i486-slackware-linux/3.4.6/../../../crt1.o(.text+0xc): In function `_start':

../sysdeps/i386/elf/start.S:109: undefined reference to `__libc_csu_fini'

/usr/lib/gcc/i486-slackware-linux/3.4.6/../../../crt1.o(.text+0x11):../sysdeps/i386/elf/start.S:110: undefined reference to `__libc_csu_init'

collect2: ld returned 1 exit status

make[1]: *** [default] Error 1

make[1]: Leaving directory `/newlisp-9.2.6'

make: *** [linux_readline] Error 2

$
-- (define? (Cornflakes))

Lutz

#4
I bet 9.2.5 doesn't compile anymore on your machine too. There is only one algorithmic change for Unix/Linux in nl-math.c/p_rand(), and which doesn't involve any different library calls. All other changes only involve Win32 and Java in newLISP-GS.



Lutz

newBert

#5
I've got some problems with special characters (in my language) in the version 9.2.6 !



The characters with an accent (e.g. "é" or "è") or other special character ("ç") count for two characters.



Example :

NewLISP v.2.9.5 :

(set 'str "Stéphanie")

(println (str 0) (str 3))

=> Sp



With NewLISP v.9.2.6 :

I must do

(println (str 0) (str 4))

to obtain

=> Sp

because of the "é" , at index #2 (and #3 !)



Sorry, if I'm not clear.



I come back to v.9.2.5 for the moment.



P.S.: I'm on Windows XP ...
<r><I>>Bertrand<e></e></I> − <COLOR color=\"#808080\">><B>newLISP<e></e></B> v.10.7.6 64-bit <B>>on Linux<e></e></B> (<I>>Linux Mint 20.1<e></e></I>)<e></e></COLOR></r>

newdep

#6
You already knew i was stupid ;-)



..The problem isnt newlisp..



Im working on my 2nd linux machine which has an nfs mount.

The P4 wont compile, the AMD64 does..  machines are copy's

so thats odd... Anyway i need to throw something out of the attic window..
-- (define? (Cornflakes))

Lutz

#7
Unfortunately I posted the Win32 version of newLISP 9.2.6 with the newLISP-GS UTF-8 Java GUI, but the newlisp.exe excutable is compiled as non UTF-8 version. I will repost newlisp-9206-win-gs-107.exe tomorrow morning, where the executable is UTF-8 too.



In version 9.2.6 (newLISP-GS) characters are UTF-8 encoded. In UTF-8 all non-ASCII characters are encoded in 2 to 4 bytes, i.e. the accented é is encoded as "195169", a double byte character.



The newLISP executable if compiled as UTF-8 knows about it and when doing indexing as in (str 0) (str 3) etc. can pick out variable-byte-wide characters correctly.



In the future (as already happening on Mac OS X) all binary packages will be shipped full UTF-8. The world is growing together and it makes a lot of sense to use a character set like UTF-8 able to display any character in the world. On the web we have most pages already encoded in UTF-8 and web browsers know how to handle this.



You will then be able to use no-ascii multibyte characters for names, strings and programming text in newLISP, and these programs and their output will look identical on all newLISP-GS platforms, no matter if the computer is running in France, Russia, Turkey or China.



When running the UTF-8 version of newLISP be aware that most (but not all) string functions work on character and not byte boundaries. This chapter: http://newlisp.org/downloads/newlisp_manual.html#unicode_utf8">http://newlisp.org/downloads/newlisp_ma ... icode_utf8">http://newlisp.org/downloads/newlisp_manual.html#unicode_utf8 contains a list of those functions.



Lutz

Lutz

#8
Just reposted newlisp-9206-win-gs-107.exe as consistent UTF-8 for the GUI part and the executable newlisp.exe.



see: http://newlisp.org/downloads/development/">http://newlisp.org/downloads/development/



Lutz

HPW

#9
The new UTF compiled DLL broke my turtls-demo in the neobook demo pub.

No idea what's the problem is.

Have to futher investigate.
Hans-Peter

HPW

#10
9.2.6 also broke my prodcut configurator (from the contest) which runs fine with 9.2.5!



Still searching for the difference.
Hans-Peter

HPW

#11
When I load my turtle.lsp with this line:



(set 'direction -425.6857918)



I get a '12 symbol expected in function set : .6857918'



Seems it is now starting with a different default locale then before.

When I use (set-locale "C") the turtle demo is running again.
Hans-Peter

Lutz

#12
QuoteWhen I use (set-locale "C") the turtle demo is running again.


The UTF-8 version of the newlisp executable switches to the local locale on startup. The non-UTF-8 version enables the 'C' locale on startup.


Quote(set 'direction -425.6857918) ... I get a '12 symbol expected in function set : .6857918'


the switch to the local (German) locale on the UTF-8 version enables the comma as a decimal separator, so the: -425.6857918 now gets parsed as -425  and .6857918 making the 'set' statement fail. The "C" locale assumes the dot "." as the decimal separator.



Lutz

HPW

#13
Still having troubles with my product configurator.



What is the benefit of having UTF enabled by default on WIN EXE and DLL?



17 KB plus (DLL).

Is there a performance difference?
Hans-Peter

HPW

#14
My others troubles seems to come from (char ...).



I used it to made a autolisp-compatibel simple ASCII-shift encoding.

And now I get different results:
Quote
newLISP v.9.2.5 on Win32.

> (char 153)

"153"



newLISP v.9.2.6 on Win32 UTF-8.

> (char 153)

"?"


What are my options now?



A non-UTF native version of (char ..) in the UTF enabled newlisp?

A own (asciichar ..) function written in newlisp?

Stick with the NON-UTF compile on WIN-DLL?



BTW: Do I have to update the compile-toolchain to MinGW 5.1.3 with gcc v.3.4.5 (as announced in change-history)
Hans-Peter