newLISP version 9.1 Release

Started by Lutz, February 15, 2007, 04:12:34 AM

Previous topic - Next topic

m35

#15
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.


C:>newlisp test.lsp
(nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
 nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
 nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
 nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil
 
 ...
 
 nil nil nil nil nil 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.

cormullion

#16
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...

m35

#17
Turns out most of that code is inconsequential.


(println (string (array 600)))


This will produce the same results.

newlisp-tk also exhibits the strange behavior.

cormullion

#18
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:


(println (string (array 600 (sequence 0 600))))

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

m35

#19
Thanks for your help with this cormullion.



The problem shows up after displaying about 2048 characters, tested with the following:
(println (string
(array 1
(list (dup "x" 2048))
)
))


Here's another variation of code who's output is cut-off/show garbage
(set 'a (string (array 600))) (println a)


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

cormullion

#20
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">http://www.newlisp.org/downloads/newlis ... l#type_ids">http://www.newlisp.org/downloads/newlisp_manual.html#type_ids)... a clue - or a red herring...

m35

#21
Thanks again cormullion (folks sure are nice in these forums :)



Here are a few other things I've just tried


(println (string (list (dup nil 600))))
(println (string (dup "x" 2048) "END" ))

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.

Lutz

#22
This has to do with printing a string to stdout which is longer then 2048 characters. This can be produced like this


(println (dup "#" 10000))

when loading this as a program only about 2080 characters will be printed. But the following shows thay the string is fine:


(write-file "report" (sup "#" 10000))

This was introduced in 9.1.0 and will be fixed shortly for Windows



Lutz

m35

#23
Yay! Thank you Lutz, and thanks for letting me know it wasn't just me being crazy :)

Lutz

#24
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">http://newlisp.org/downloads/newlisp-91 ... tk-137.exe">http://newlisp.org/downloads/newlisp-9101-win-tk-137.exe



Lutz

Lutz

#25
UTF-8 executable and dynamic link library versions are available for 9.1.1 Win32:



http://newlisp.org/downloads/UTF-8_win32/">http://newlisp.org/downloads/UTF-8_win32/



Lutz