newlispfanclub.alh.net

the new development release 7.3.16 has the 'silent' bug fixed.

About the >2048 issue. Longer >2048 results strings from newLISP come back not quoted by "..." but by [text]... [/text] tags, I wonder if that could do something funny to the NeoBook interface which seems to treat [,] square brackest as some sort of escape/special character?

Lutz

Just released release 1.01 of the newlisp-wrapper for neobook:

See Froum post:

http://www.neosoftware.com/cgi-bin/ikon ... &topic=390

Updated plugin-page:

http://hpwickern.bei.t-online.de/anmeld ... obook.html

I upload a new demo-exe of the release demo to my plugin-page:

http://hpwickern.bei.t-online.de/anmeld ... SPDemo.zip

Features:
Action: hpwNewLispCall - Support for callbacks in return-messages into neoScript!
Support-file: nb_util.lsp with usefull functions. Starts with: (nl2nb-list '("1" "2" "3"))
Demo-file: neoTurtle.lsp with fractal-graphics in neobook powered by newLISP/hpwImage.
Last but not least: newlisp.dll Development version 7.3.16

>I wonder if that could do something funny to the NeoBook interface which seems to treat [,] square brackest as some sort of escape/special character?

The brackets mark variables in neobook and have indeed to be treated different. I thought Sam has it working now.


May be we have to check again.

Hi Hans-Peter and Lutz,

I do have it (my program to copy just the unique lines in a text file) working now. All of the work is done in newLISP (thanks, Lutz!) and I am not passing lengthy strings back to NeoBook. I think the problem was that I was unaware of the [text]...[/text] requirement for lengthy strings and so was passing to a newLISP function a >2048 string delimited with double-quotes. I will verify this by returning to my old code and using [text]...[/text] in place of double-quotes. If this proves to be the culprit, we can document it for neoBook coders.

Verified! Using [text]...[/text] in neoBook when passing >2048 strings to newLISP eliminated the "string too long" error.


-- Sam

I uploaded a polished demo-exe of the release demo to my plugin-page:

http://hpwickern.bei.t-online.de/anmeld ... SPDemo.zip

where did the turle demo go? I loved th turtle port you did, and thought I would see the Hanoi demo in the next NeoBook demo ;). There might be a problem though with the Hanoi demo, because the disk deletion works there by deleting a TK graphic object. I don't know if it is possible to do that with NeoBook.

Anyway, why don't you put it back (load "neoTurtle.lsp") doesn't work, I guess it doesn't find a graphic context to draw to.

Lutz

Dont't know what you mean, when you enter the turtle page it is loaded automaticly. You have to press the 'Start Lisp' button to start the string '(Turtle:run) in the entry field. The articel-object is just there to show the source. I only want to show what is done behind the scene.

To the Hanoi demo, the hpwImage plugin is a scriptable bitmap object, which does not work with objects like TK. Of cource it could be done with a complete redraw each time. Will take a look.

Oops, sorry about it! I always extracted an old version, this latest one is beautiful with the source pane on the right! This NeoBook software looks better to me each time you have a new demo.

About Hanoi: What I did in an older version, was overdraw the disk with 'white' to delete it.

Lutz

Many people (like high-flying MS-User ;-)) think neobook is a toy-tool.
Of cource a Visual studio might be better for huge projects and programmer teams. But Dave has really made a RAD-tool which can produce very nice results in less time. And through it's SDK you get an interface to extent the core-functionality.

>About Hanoi: What I did in an older version, was overdraw the disk with 'white' to delete it.

That was what I mean. The problem with the the neobook interface is, that it is not truly bidirectional. There are not 2 independent running process which communicate via TCP, there is one call into it and the answer has to contain the complete result neoscript. So with Hanoi, newlisp is ready when neobook starts painting. Will see how it will work.

Another idea would be to break it into parts and call it in a neobook loop and update the screen in this loop with subsequent calls for the disk position. Must be also possible.

I uploaded a new demo-exe of the release demo to my plugin-page:

http://hpwickern.bei.t-online.de/anmeld ... SPDemo.zip

Now with ported Hanoi-Demo.
(Version with one return string)

Great Job on the Hanoi port to NeoBook!

A little optimization, instead of:

(append "foo" (string (nth 2 lst)) "bar")

you can do:

(string "foo" (nth 2 lst) "bar")

'string' can take several arguments and will convert and append at the same time.

Lutz

I uploaded a new demo-exe of the release demo to my plugin-page:

http://hpwickern.bei.t-online.de/anmeld ... SPDemo.zip

It contains another demo from Sam Cox (Thanks) for calculating roman numbers.

For Hanoi.lsp I have tried to measure the time in newLISP. But I don't know if it is that fast or if the neobook timer just not work as long as the DLL works in the process.

Nice (very LISPish) Roman number algorithm by Sam Cox!

What confused me first was the '(silent (print expr))' instead of just 'expr' used in the NeoBook version, until I realized it was necessary to strip of the quotes from the return value.

Lutz

Late in the evening I upload a revised demo, with a newlisp-timer instead of a neobook timer.
Now there comes result between 800-900 ms for computing in newlisp. (6 Disk 0 Delay)

I uploaded a new demo-exe of the release demo to my plugin-page:

http://hpwickern.bei.t-online.de/anmeld ... SPDemo.zip

Based on hpwNewLISP.nbp 1.02 with new command hpwNewLispFileread.
It was added to the pluigin to load files in neobook which contains a '|' character which has a special meaning for the neobook 'FileRead'.
In the last Demo a seperate plugin was binded so now it a bit smaller.
Now only hpwNewLISP and hpwImage are binded.

I uploaded a new demo-exe of the release demo to my plugin-page:

http://hpwickern.bei.t-online.de/anmeld ... SPDemo.zip

Based on hpwNewLISP.nbp 1.03 with new restart-feature for hpwNewLispCall.
Now it is possible to feed commands into the neobook action-engine and get back into newlisp to generate further action-commands. So it is not necessary to compute a complete action-script at once (and wait in neobook). You can start generating at once in neobook and feed commands on demand.

I've been playing with calling newlisp from IBASIC http://www.pyxia.com/ibasic.html and realised it would be good to be able to check the dll newlisp version from the calling program - I couldn't see a function for it -
something like (version) -> "newLISP v7.3.17 Copyright (c) 2003 Lutz Mueller. All rights reserved."
so (nth 1 (parse (version))) -> "v7.3.17".

Also re initialization of dll
Following advice
When the DLL is loaded it looks for an ini.lsp file in the same directory as the DLL and loads it if it exists.
I tried putting ini.lsp (and init.lsp) into the directory but nothing seemed to happen the ini.lsp was
(setq a "this is inited")
Loading ini.lsp with (load "ini.lsp") has the expected effect.


also re suppression of (print ) mentioned earlier in thread
(write-line ) put a line onto an open IBASIC console - I haven't
tested what happens without a console but it may give problems
similar to (print ) but on the other hand outputting to the IBASIC
console could be good.
The IBASIC program I use is just a simple read-eval-print loop viz:

def ins, outs :STRING
declare "newlisp",dllEvalStr(thestring:STRING),STRING

OPENCONSOLE

while 1
input ">",ins
if ins = ""
goto doneit
endif
outs = dllEvalStr( ins)
print "OUT:", outs
endwhile
label doneit
Print "Break - press key to end"
DO:UNTIL INKEY$ <> ""
CLOSECONSOLE
END

In summary
-can we get at version?
-how to in.lsp the dll?
-watch out for (write-line in dll

Nigel

Hello Nigel,

version: ini:
Couldn't you do the (load "ini.lsp") as the first action from your programm?

writeline: Works for me in newlisp-TK and in neobook/newlisp.dll.
So what's the problem with it?

Hello,

version:
Thanks for directing me to (sys-info) - it's what I needed.

ini:
I was really pointing out a statement in the documentation that didn't appear to be implemented or wasn't working (or I didn't understand).

write-line:
I mentioned it because I saw in this thread the post by Lutz:
"There is a newlisp_7312.tgz in the development directory, it takes care of crashing in 'main-args' and 'print', both are now suppressed and will be ignored in DLL's"

I thought that whatever was done to (print will need to be done to
(write-line. However, using (print in the dll of 7.3.17 seems to print to the open IBASIC so I'm not sure what Lutz was referring to as print being suppressed - perhaps you could make it clearer for me Lutz?
Anyway thanks for prompting me to think more about the dll console i/o
I'll fiddle with it a bit to understand it better.

Regards
Nigel

About 'init.lsp':
The file has to be in the current directory of the calling process not of the DLL. The manual is wrong about this. (will change this in the doc)

About 'print' in DLL:
'print' was not working in a DLL in the first version 7.3.12, but was then fixed in 7.3.14 and is now working fine.

Lutz

A suggestion about error reporting:
Now error returns are coming back to a program from a dll rather than just being seen on a console perhaps now is a time to formalise their strucure to be more "machine friendly".
viz
> (div 1 0)

division by zero in function div

>
This eror may be hard to differentiate from a valid reply.

I use the editor Credit that catches compile errors and suggest that the runtime dll error could consider a similar format to 'standard' compiler error formats.
Credit help says:
Error patterns

This area is only used if the tool's output is captured. It contains a list of patterns which are compared to the captured output. If a match is found, a double-click on a message line in the output pane automatically goes to the place in the source file referenced by the line.

For example, if you are using a tool which produces error messages of this kind:

Error 314: myprg.c (21,6) Identifier expected

Perhaps a newlisp error could look like

Error <err-no> <context> <function> <readable error text>

viz as above
Error 25 Main div Math_exception division_by_zero

I don't know how easy it is to return context.

Any comments?
I realize tyhe form I've suggested looks less friendly - perhaps error
format could be a settable option.

Nigel

this is easily done with defining a customized error handling routine in newLISP:

;; define the error handling routine
(define (error-handler) (print "ERR:" (error-number) " " (error-text)))

;; set it as the error-event
(error-event 'error-handler)

now when provoking an error:

(foo) =>

ERR:20 invalid function : (foo)

if 'foo' was called from another subroutines the stack trace would also be returned.

Lutz

thanks for the solution Lutz

Nigel

Lutz,

work for me in newlisp-tk, but not with the newLisp.DLL.
Still returns the old message.

Have you test it with DLL?