I run some test to use newLISP.DLL direct from TclTk
I use Ffidl Version 0.5 from:
http://elf.org/ffidl/
Here a test code for calling the DLL:
package require Ffidl 0.5
ffidl::callout dll_EvalStr {pointer-utf8} pointer-utf8 [ffidl::symbol newlisp.dll newlispEvalStr]
proc EvalStr { lispstring } {
dll_EvalStr $lispstring
}
proc exit? {} {
set answer [tk_messageBox -message "Really quit?" -type yesno -icon question]
switch -- $answer {
yes {
exit
}
no {}
}
}
proc LispTest {win} {
set size(X) 200
set size(Y) 200
toplevel $win
wm title $win "Tcl-Lisp" ;
wm overrideredirect $win true
update idletasks ;
set lispreturn0 [EvalStr "(setq a (+ 5 6))"]
set lispreturn1 [EvalStr "(+ a 7)"]
canvas $win.c -background yellow -width $size(X) -height $size(Y) -relief flat -bd 0
$win.c create text 100 100 -fill navy -font {Times 12} -text $lispreturn0
$win.c create text 100 130 -fill navy -font {Times 12} -text $lispreturn1
pack $win.c -expand yes -fill both
focus -force $win
bind $win <Key> exit?
bind $win <Motion> {}
}
wm withdraw .
LispTest .scr
There is now the question, if a alternativ newLISP-TK can be build which use the DLL instead of the EXE. Calling LISP is not the problem, but the EXE version use a callback technik via TCP, where I am not sure if it can be done with the DLL.
For what it can be usable:
For systems without installed TCP-IP stack.
For systems with have security concerns with personal firewalls.
One process solution
That would be possible, you would have to rewrite some routines in newlisp-tk.tcl. I think the potential demand for this is too small. The only ones complaining about tcp/ip are occasional Win95/98 users, and I am not shure if compatibility with those systems is already broken anyway because of shared memory and semaphores in v.8.2.3 and later.
Perhaps GUI work would be better invested building a lisp layer on top of the TK api.
Lutz
>That would be possible, you would have to rewrite some routines in newlisp-tk.tcl
Can give you a hint, how it can be done? The current EXE can be called and can start actions in TK as a reaction of this call, because the interface transport the call, but does not wait on the answer.The answer comes with a seperate callback from lisp. In the meantime both process run independently. With DLL each call give a return value and is the DLL is then inaktiv until the next call. Here is only one code running, either the MAIN-EXE or the DLL.
>Perhaps GUI work would be better invested building a lisp layer on top of the TK api.
What have you in mind with the lisp layer?
We have the (tk ...) function to create TK-GUI via LISP.
Heeeeeeee I searched for that Library some years ago !! Finaly its possible to
run libs from Tcl ;-) (wasnt possible then..) great thanks for the tips..although Im unable to drop newlisp for tcl :-)
>>> Can give you a hint, how it can be done?
When writing an interactive frontend to newLISP you need two channel one is the Tcl-Tk listener, the other one is the newLISP listener.
>>>> What have you in mind with the lisp layer?
instead of currently:
(tk "toplevel .dw -background lightblue")
(tk "wm geometry .dw 200x340+540+80")
you would do something like:
(set 'dw (window 200 340 540 80))
(window-background "lighblue")
Or perhaps you have an OO implementation with contexts:
(set 'dw (window:create 200 340 540 80))
(dw:set-background "lighblue")
(dw:event-mouse-entry 'mouse-entry-handler)
(define (mouse-entry-handler)
(dw:set-background "red"))
etc..
I would preferthe OO method because things are easier to remember and it would be similar to what other languages today do.
Lutz
>When writing an interactive frontend to newLISP you need two channel one is the Tcl-Tk listener, the other one is the newLISP listener.
This is the difficulty with the usage of the DLL. You have no 2 independent listener on each side. It is limitted to calls to a lisp-sub-system.
Well, you can load the newLISP DLL and then start the listener on the newLISP side with a call from Tcl the channels could be pipes.
Lutz