• 19 new functions, many enhancements to existing functions, new 64-bit compile flavor, built-in web server.
Binaries for Win32, MacOS X and UBUNTU Linux here: http://newlisp.org/downloads/
Release notes: http://newlisp.org/downloads/newLISP-9.1-Release.html
Lutz
Aaaa a mile stone again ;-) Thanks Lutz for the work..!
Documentation, not to forget!! looks also good ;-)
thanks from me too!
By the way - the MacOS X installer doesn't include any docs anymore. Is that right?
Oh sorry, my mistake. It's just moved and I needed to update my bookmarks:
old:
file:///usr/share/newlisp/doc/newlisp_manual.html
new:
file:///usr/share/doc/newlisp/newlisp_manual.html
I seem to remember something about this. A memory leak obviously... :-)
The move to usr/share/doc/newlisp was made because it seems to be the standard on most UNIX including Mac OS X, LINUX and FreeBSD. The newlisp-tk programs takes this into account but old newlisp-tk.conf files in the home directory should be removed or edited with a text editor to reflect the new doc path.
There is one known place where the new doc path is not reflected, which is the file init.lsp.example. The path in the function 'help' at the end of the file still has the old invalid path. In any case the file will not be loaded until renamed to init.lsp .
Lutz
Cool. Thanks.
Both deb packages install on my Ubuntu 6.10 (updated to 20Feb updates) using gdebi without any warning messages and newlisp and newlisp-tk run fine and open help docs fine.
Thanks Lutz
Nigel
PS as another option in install.txt - in firefox you click on the deb on the download page - it will offer to install it - when downloaded it will automatically open with gdebi installer and clicking install button does it - very easy. Then run in terminal as described.
I'm a bit late to the party, but the arch linux package and PKGBUILD are in their usual locations.
http://perpetualnewbie.info/archlinux/packages/newlisp/newlisp-9.1.0-1.pkg.tar.gz
http://perpetualnewbie.info/archlinux/packages/newlisp/PKGBUILD
Compiling for Tru64Unix 4.0f revealed a minor issue:
Quote
cc: Warning: nl-sock.c, line 1128: In this statement, & before array ""
"" is ignored. (addrarray)
if(newLine) write(handle, &LINE_FEED, strlen(LINE_FEED));
-----------------------------^
As LINE_FEED is a C-define, it seems there is no need to use an ampersand here? From functional point of view this compilewarning can be ignored, of course, but I just thought you'ld like to know.
Peter
The Tru64Unix package for newLisp 9.1 is ready and can be downloaded from here:
http://www.turtle.dds.nl/newlisp/index.html
This package contains READLINE support and can be installed both on Tru64Unix 4.x and 5.x systems.
Enjoy,
Peter
This is my first post, and I have to say I absolutely love using newlisp. These forums have been very helpful, and I've managed to do some very beautiful things with the language. Unfortunately, my first post deals with some strange behavior I've run across.
The following code fails to print the entire array ctx:a and shows some garbage at the end of the output (with v.9.1.0 on Win32).
; Empty context
(context 'MAIN)
(new EMPTY_CTX 'ctx)
(setq ctx:a (array 600))
(println (string ctx:a))
This has been tested on two different Win32 computers, and is 100% reproducible using v.9.1.0.
v.9.0 on Win32, and v.9.1.0 on Linux (Ubuntu) didn't exhibit this behavior in the cursory tests I ran.
can't reproduce this problem on MacOS X, running 9.1...
nice to see you here, anyway, m35!
Running WINE under linux with newlisp 9.1 gives not a problem either...
(but thats more like a Win98 simmulation)
Under Linux itself also no problem..
Wine output ->
> (context 'EMPTY_CTX)
; Empty context
(context 'MAIN)
(new EMPTY_CTX 'ctx)
(setq ctx:a (array 600))
(println (string ctx:a)) EMPTY_CTX
EMPTY_CTX> EMPTY_CTX> EMPTY_CTX> MAIN
> > ctx
> > (nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil)
> >
I can not reproduce it here on WIN XP:
Quote
newLISP v.9.1.0 on Win32.
> (context 'EMPTY_CTX)
EMPTY_CTX
EMPTY_CTX> (context 'MAIN)
MAIN
> (new EMPTY_CTX 'ctx)
ctx
> (setq ctx:a (array 600))
(nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
..
..
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil)
> (println (string ctx:a))
(nil nil nil nil nil ... nil nil
[text](nil nil nil nil ... nil nil nil nil nil)[/text]
>
I have shorten some nil output here.
Thanks for checking it HPW, newdep, and cormullion. I guess the problem only appears when you load the code from a file at the command-line.
(nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
...
nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil nil nil nilR
newLISP v.9.1.0 on Win32, execute 'newlisp -h' for more info.
>
This problem won't show up if you use (load "test.lsp") either. Oh, and I'm working on WinXP Professional SP2.
In your example you've just given, I can explain the newlisp line (newLISP v.9.1.0 on Win32, execute 'newlisp -h' for more info.) - newLISP drops into the interpreter when it's finished with your code, unless you specify an (exit).
But I can't explain the preceding 'R' on the previous line or the insufficient display of the list...
Turns out most of that code is inconsequential.
This will produce the same results.
newlisp-tk also exhibits the strange behavior.
Sounds odd - I don't know what could be happening. Here's a few things I'd try if I was getting this problem myself...
What does the 'garbage' actually consist of? What happens if you include an (exit) at the end of the file? Can you save the output in a file (eg like directing STDOUT on Unix) to see if there's a difference between what is produced and what gets displayed see? If you run this:
- how many numbers do you get before you see garbage? (Perhaps there's a maximum length of line or something...) What's the lowest number you can supply instead of 600 before you start to see garbage?
Thanks for your help with this cormullion.
The problem shows up after displaying about 2048 characters, tested with the following:
(array 1
(list (dup "x" 2048))
)
))
Here's another variation of code who's output is cut-off/show garbage
The garbage varies:
* no garbage (the output is just cut short)
* one or two letters
* a couple of ASCII lines (around ASCII 0xE0 to 0xDA)
* most often is bunch of smiles (ASCII 0x1, 0x2) mixed with other garbage
Adding an (exit) to the end of the program still shows the garbage (just doesn't go to the interpreter).
Variations such as
(println (array 600))
and
(write-file "test.txt" (string (array 600)))
produce correct output.
I manually piped the output into a file
newlisp test.lsp > out.txt
and the garbage was in the file too.
I take it I'm the only one getting this strange behavior :/
I'd jump into GDB and try to step through the problem if I had more time (and I wish I could find a Windows GUI for GDB).
sadly this beats me, i think it's going to be a question for the more technical folks. However, I'm intrigued by your mention of 2048 - this is coincidentally the number of characters in a string that should be enclosed (by the system) in [text] and [/text] tags (http://www.newlisp.org/downloads/newlisp_manual.html#type_ids)... a clue - or a red herring...
Thanks again cormullion (folks sure are nice in these forums :)
Here are a few other things I've just tried
When I run each of those programs, the output gets cut-off with garbage.
It seems it has something to do with (string) trying to create any kind of text longer than 2048, but only when output to the screen ((write-file) doesn't have this problem), and only for code loaded at startup.
This has to do with printing a string to stdout which is longer then 2048 characters. This can be produced like this
when loading this as a program only about 2080 characters will be printed. But the following shows thay the string is fine:
This was introduced in 9.1.0 and will be fixed shortly for Windows
Lutz
Yay! Thank you Lutz, and thanks for letting me know it wasn't just me being crazy :)
This release update fixes a bug in the Win32 version of newLISP. MacOS X and UNIX users do not need to upgrade.
http://newlisp.org/downloads/newlisp-9101-win-tk-137.exe
Lutz
UTF-8 executable and dynamic link library versions are available for 9.1.1 Win32:
http://newlisp.org/downloads/UTF-8_win32/
Lutz