newlisp.DLL possible?

Started by HPW, October 13, 2003, 12:30:58 PM

Previous topic - Next topic

HPW

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



http://hpwickern.bei.t-online.de/anmeldung/html1/neobook/hpwNewLISPDemo.zip">http://hpwickern.bei.t-online.de/anmeld ... SPDemo.zip">http://hpwickern.bei.t-online.de/anmeldung/html1/neobook/hpwNewLISPDemo.zip



Now with ported Hanoi-Demo.

(Version with one return string)
Hans-Peter

Lutz

#61
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

HPW

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



http://hpwickern.bei.t-online.de/anmeldung/html1/neobook/hpwNewLISPDemo.zip">http://hpwickern.bei.t-online.de/anmeld ... SPDemo.zip">http://hpwickern.bei.t-online.de/anmeldung/html1/neobook/hpwNewLISPDemo.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

Lutz

#63
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

HPW

#64
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)
Hans-Peter

HPW

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



http://hpwickern.bei.t-online.de/anmeldung/html1/neobook/hpwNewLISPDemo.zip">http://hpwickern.bei.t-online.de/anmeld ... SPDemo.zip">http://hpwickern.bei.t-online.de/anmeldung/html1/neobook/hpwNewLISPDemo.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

HPW

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



http://hpwickern.bei.t-online.de/anmeldung/html1/neobook/hpwNewLISPDemo.zip">http://hpwickern.bei.t-online.de/anmeld ... SPDemo.zip">http://hpwickern.bei.t-online.de/anmeldung/html1/neobook/hpwNewLISPDemo.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

nigelbrown

#67
I've been playing with calling newlisp from IBASIC http://www.pyxia.com/ibasic.html">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

HPW

#68
Hello Nigel,



version:

> (sys-info)
(639 298 1 0 1024 7317 6)
> (nth 5(sys-info))
7317


ini:

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



writeline:

> (silent(write-line "Test1"))
Test1


Works for me in newlisp-TK and in neobook/newlisp.dll.

So what's the problem with it?
Hans-Peter

nigelbrown

#69
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

Lutz

#70
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

nigelbrown

#71
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

Lutz

#72
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

nigelbrown

#73
thanks for the solution Lutz



Nigel

HPW

#74
Lutz,



work for me in newlisp-tk, but not with the newLisp.DLL.

Still returns the old message.



Have you test it with DLL?
Hans-Peter