newlisp.DLL possible?
newlisp.DLL possible?
Hello Lutz,
I would like to ask if it is possible to make a newlisp.dll where I can call
a function "eval" and pass a string containing a lisp-code.(cdecl)
This would be similar to newlisp "Direct execution mode".
It would return a string to the calling Programm.
But the DLL could then stay in memory and preserve it's memory with code and data.
Would be another powerfull option.
What do you think?
I would like to ask if it is possible to make a newlisp.dll where I can call
a function "eval" and pass a string containing a lisp-code.(cdecl)
This would be similar to newlisp "Direct execution mode".
It would return a string to the calling Programm.
But the DLL could then stay in memory and preserve it's memory with code and data.
Would be another powerfull option.
What do you think?
Hans-Peter
This has also been requested by Steve and it is on the list of things to do. Unfortunately it is one of those features, which needs a different treatment on the Windows and UNIX platforms, and I haven't done any Windows specific development in the last two years after moving newLISP to UNIX.
You might also consider talking to newLISP via TCP/IP, this is the way the newlisp-tk frontend is doing it. If you start newLISP in demon mode with the -d option it will stay in memory with all its data, even if the connecting application exits, you can reconnect and all data are still there.
This would also be a platform independent solution and you can have newLISP running on a different computer on the network/internet.
Anyway I will look into a DLL mode when I have a little bit more time.
Lutz
You might also consider talking to newLISP via TCP/IP, this is the way the newlisp-tk frontend is doing it. If you start newLISP in demon mode with the -d option it will stay in memory with all its data, even if the connecting application exits, you can reconnect and all data are still there.
This would also be a platform independent solution and you can have newLISP running on a different computer on the network/internet.
Anyway I will look into a DLL mode when I have a little bit more time.
Lutz
the problem is with exiting, sometimes on Windows when the client application exits, the demon will receive an exception and exit too. On my system it has never occured again since I installed XP, and I check this feature with every build. I suspect it was only true on Windows 2000.
Give it a try! You can quickly check it out with the telnet command under Windows.
But I will look into the DLL stuff anyway.
Lutz
Give it a try! You can quickly check it out with the telnet command under Windows.
But I will look into the DLL stuff anyway.
Lutz
Thanks Hans-Peter, I will look into it again the coming week and might post the files which you use to compile as a DLL, to get some help.
Here in USA we have the long Thanksgiving / holyday weekend, which started yesterday on Thursday, so I will be not very active here on the board until Monday.
Lutz
Here in USA we have the long Thanksgiving / holyday weekend, which started yesterday on Thursday, so I will be not very active here on the board until Monday.
Lutz
Thanks Steve, I know you have prpbably the most experience, when it comes to building newLISP on Windows. I'll give it another quick shot tomorrow Monday, because I didn't look at it since I wrote it mid October and sometimes after a while you see some obvious screwup. After that I'll pass it on to you.
Its a .c, .def and a makefile. The .c and .def files just get added to the usual files and the whole thing gets compiled with the new makefile_win32dll.
Lutz
Its a .c, .def and a makefile. The .c and .def files just get added to the usual files and the whole thing gets compiled with the new makefile_win32dll.
Lutz
>Don't forget to 'make clean' between making the newlisp.exe and newlisp.dll.
I forgot it! :-)
Some first observation:
(get-string (dllEvalStr "(string(main-args))"))
gives a crash. I assume a DLL can not have main-args.
(get-string (dllEvalStr "(load "test1.lsp")"))
gives a crash. Maybe the double-quotes.
(get-string (dllEvalStr "(load \"test1.lsp\")"))
returns "true" but does not evaluate the expression inside the lsp "(setq a10)".
I forgot it! :-)
Some first observation:
(get-string (dllEvalStr "(string(main-args))"))
gives a crash. I assume a DLL can not have main-args.
(get-string (dllEvalStr "(load "test1.lsp")"))
gives a crash. Maybe the double-quotes.
(get-string (dllEvalStr "(load \"test1.lsp\")"))
returns "true" but does not evaluate the expression inside the lsp "(setq a10)".
Hans-Peter
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. newlisp.dll now passes the QA suite which is not 100% but tests most features of newLISP.
Certain math exceptions i.e. (sqrt -1) result in a correct result of 'NaN', but the DLL pops up a Windows messge box, which has to be acknowledged.
Lutz
Certain math exceptions i.e. (sqrt -1) result in a correct result of 'NaN', but the DLL pops up a Windows messge box, which has to be acknowledged.
Lutz
Yep, in 7.3.12 problem with main-args is solved.
But this remains:
(get-string (dllEvalStr "(load "test1.lsp")"))
gives a crash. Maybe the double-quotes.
(get-string (dllEvalStr "(load \"test1.lsp\")"))
returns "true" but does not evaluate the expression inside the lsp "(setq a 10)".
Here a remains nil.
But this remains:
(get-string (dllEvalStr "(load "test1.lsp")"))
gives a crash. Maybe the double-quotes.
(get-string (dllEvalStr "(load \"test1.lsp\")"))
returns "true" but does not evaluate the expression inside the lsp "(setq a 10)".
Here a remains nil.
Hans-Peter
As a quick hack I put together a neobook-plugin (delphi) for newlisp.
(hpwNewLISP.nbp 33KB Interface-DLL binded into neobook runtime)
In the past I have made some free plugins for the authoring package neobook.
I have a plugin running to call corman DLL's.
http://hpwickern.bei.t-online.de/anmeld ... obook.html
I upload a demo-exe to my plugin-page:
http://hpwickern.bei.t-online.de/anmeld ... ewLISP.zip
Question: Is it in the interest of newLisp to release this to the neobook community to spread the word about newlisp to more people?
(hpwNewLISP.nbp 33KB Interface-DLL binded into neobook runtime)
In the past I have made some free plugins for the authoring package neobook.
I have a plugin running to call corman DLL's.
http://hpwickern.bei.t-online.de/anmeld ... obook.html
I upload a demo-exe to my plugin-page:
http://hpwickern.bei.t-online.de/anmeld ... ewLISP.zip
Question: Is it in the interest of newLisp to release this to the neobook community to spread the word about newlisp to more people?
Hans-Peter
Remember that all code you execute runs in the environment of newlisp.dll. After loading you 'test1.lsp' which has (setq a 10) do a:
(get-string (dllEvalStr "a")) => "10"
Also, instead of:
(get-string (dllEvalStr "(load \"test1.lsp\")"))
you can also do for less quote clutter:
(get-string (dllEvalStr {(load "test1.lsp")}))
About the crash:
When putting "(load "test.lsp")" as argment to dllEvalStr, it really receives 3 args: "(load " , test.lsp and ")". This will mess up the call stack in the DLL, where the function expects only one argument. Fixing this would require a lot of overhead when importing functions. Right now imported functions in newLISP are very fast.
When using the DLL from other Win32 applications, this will not be an issue, as all of these to extensive checking and declaring.
In newLISP it is always recommended to put wrappers around imported functions to check for the right type and number of args if these get exposed to users.
The next version will also have fix from Steve/adamss3 for the popup problem with FP exceptions.
Lutz
(get-string (dllEvalStr "a")) => "10"
Also, instead of:
(get-string (dllEvalStr "(load \"test1.lsp\")"))
you can also do for less quote clutter:
(get-string (dllEvalStr {(load "test1.lsp")}))
About the crash:
When putting "(load "test.lsp")" as argment to dllEvalStr, it really receives 3 args: "(load " , test.lsp and ")". This will mess up the call stack in the DLL, where the function expects only one argument. Fixing this would require a lot of overhead when importing functions. Right now imported functions in newLISP are very fast.
When using the DLL from other Win32 applications, this will not be an issue, as all of these to extensive checking and declaring.
In newLISP it is always recommended to put wrappers around imported functions to check for the right type and number of args if these get exposed to users.
The next version will also have fix from Steve/adamss3 for the popup problem with FP exceptions.
Lutz
>Remember that all code you execute runs in the environment of newlisp.dll. After loading you 'test1.lsp' which has (setq a 10) do a:
Of cource you are right. Have not thought much before posting.
Thanks for clearing. Nice advice for less quote clutter.
Seems to be another great thing with the DLL feature.
I like it very much.
Of cource you are right. Have not thought much before posting.
Thanks for clearing. Nice advice for less quote clutter.
Seems to be another great thing with the DLL feature.
I like it very much.
Hans-Peter