newlisp.DLL possible?
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
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
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
Hans-Peter
>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.
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.
Hans-Peter
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 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
http://hpwickern.bei.t-online.de/anmeld ... SPDemo.zip
Hans-Peter
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
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.
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.
Hans-Peter
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.
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.
Hans-Peter
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)
http://hpwickern.bei.t-online.de/anmeld ... SPDemo.zip
Now with ported Hanoi-Demo.
(Version with one return string)
Hans-Peter
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.
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.
Hans-Peter
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.
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.
Hans-Peter
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.
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.
Hans-Peter
-
- Posts: 429
- Joined: Tue Nov 11, 2003 2:11 am
- Location: Brisbane, Australia
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
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?
version:
Code: Select all
> (sys-info)
(639 298 1 0 1024 7317 6)
> (nth 5(sys-info))
7317
Couldn't you do the (load "ini.lsp") as the first action from your programm?
writeline:
Code: Select all
> (silent(write-line "Test1"))
Test1
So what's the problem with it?
Hans-Peter
-
- Posts: 429
- Joined: Tue Nov 11, 2003 2:11 am
- Location: Brisbane, Australia
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
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
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
-
- Posts: 429
- Joined: Tue Nov 11, 2003 2:11 am
- Location: Brisbane, Australia
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
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
;; 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
-
- Posts: 429
- Joined: Tue Nov 11, 2003 2:11 am
- Location: Brisbane, Australia