development release newLISP v.9.3.2

Started by Lutz, February 25, 2008, 11:14:07 AM

Previous topic - Next topic

Lutz

• IPv6 compile flavor for Linux, BSD's and Mac OS X

• roundtrip times in net-ping

• bug fixes



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



Lutz

Dmi

#1
Hi, Lutz!



Debian packaging script have reported that newlisp should not be linked with libncurses because no symbols used from it.



Rebuilding with -lncurses removed from makefile was successful.



Is it a real dependency?
WBR, Dmi

Lutz

#2
QuoteIs it a real dependency?


For some Linux it has been, others need libtermcap, unfortunately there is no makefile with libreadline support which fits all flavors of Linux.



Lutz

Dmi

#3
Hmm.... As I can see libreadline doesn't needed in either termcap or ncurses/terminfo to be linked to newlisp (only libreadline itself depends libncurses)



This is mostly for information - the correction of makefile_debian isn't mandatory because debian packaging system will automatically patch for it once it was corrected.
WBR, Dmi

HPW

#4
newlisp-tk 1.37 no more runs with newlisp.exe 9.3.2 on windows!

It throws an error and terminates.

9.3.0 did run without problems.
Hans-Peter

Lutz

#5
DMI,



The makefile_debian is corrected in the next version.



HPW,



I have no time to still maintain the old Tcl/Tk frontend. The new Java based front end is now out for almost a year. If anybody wants to take over newlisp-tk.tcl as a maintainer, that would be fine with me, and I put a link for it on the site.



In general Tcl/Tk apps still work with newLISP 9.3.2 (see examples/tcltk.lsp). The problem is related to two of the changes in 9.3.2. One of the problems is this line in newlisp-tk.tcl:


(net-send SYS:tk-sock 'result)

to


(net-send SYS:tk-sock result)

taking away the quote.



The other change affecting newlisp-tk.tcl is the new sign-on banner which now includes the string "IPv4" or "IPv6". In newlisp.c change:


varPrintf(OUT_CONSOLE, banner, ostype, IPV, ".");

to


varPrintf(OUT_CONSOLE, banner, ostype, ".", IPV);

The fix in newlisp.c will be made in the next development version.





Lutz

HPW

#6
Lutz,



Thanks for the info.



Even when the  Tcl/Tk frontend is no more maintained it is good to know how it can be used.

It is still one option in the newLISP toolbox.
Hans-Peter

Dmi

#7
Thanks, Lutz!
WBR, Dmi

HPW

#8
When I tries today my old product configurator with the latest newLISP release, it was broken.

It show really strange errors and I need several hours to debug.

Finally it turn out that the new command 'read' was the problem.

In my autolisp-compatibilty layer I had defined it yet.

Now that code was broken because of the protected new 'read'.



I ended up to unprotect the command and overload it with my own version.



(cpymem (pack "c c" 0 32)(last (dump 'read))2)
Hans-Peter

Lutz

#9
You don't need the 'cpymem' trick to unprotect the built-in 'read', you just can do:


(constant (global 'read) (import "autolisp.dll" "read"))

and overwrite a native symbol with your own version.



Lutz

HPW

#10
Thanks for the tip.

More consistent and not looking so hacky.



Other point: Was is wise to call it 'read' because many people coming from other dialects has the wrong impression what it is.



Wouldn't 'reader' be more descriptive?
Hans-Peter

Cyril

#11
Quote from: "Lutz"You don't need the 'cpymem' trick to unprotect the built-in 'read', you just can do:


(constant (global 'read) (import "autolisp.dll" "read"))

and overwrite a native symbol with your own version.


Is it true that in general one can change a value of a protected symbol by 'constant' but can not make it unprotected (aside 'cpymem' hack)?
With newLISP you can grow your lists from the right side!

Lutz

#12
Quoteis it true that in general one can change a value of a protected symbol by 'constant' but can not make it unprotected (aside 'cpymem' hack)?


Yes

cormullion

#13
QuoteOther point: Was is wise to call it 'read' because many people coming from other dialects has the wrong impression what it is.



Wouldn't 'reader' be more descriptive?


How about scan?



I hope to try out this new function soon. But I'm still trying to work out how to run multiple versions of newLISP on a single machine. I want 9.2 for compatibility, 9.3 for general use, and the latest dev version running separately for comparison and experiment. If anyone knows how to do this easily on MacOS X, please share.