newlispfanclub.alh.net

• 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/

Lutz

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?

Is 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

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.

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.

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:
to
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:
to
The fix in newlisp.c will be made in the next development version.


Lutz

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.

Thanks, Lutz!

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)

You don't need the 'cpymem' trick to unprotect the built-in 'read', you just can do:
and overwrite a native symbol with your own version.

Lutz

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?

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

Code: Select all

(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)?

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)?

Yes

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?

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.