newLISP-TK with DLL possible?

[HPW]

I run some test to use newLISP.DLL direct from TclTk



I use Ffidl Version 0.5 from:

http://elf.org/ffidl/">http://elf.org/ffidl/



Here a test code for calling the DLL:

Code Select Expand


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

[Lutz]

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

[HPW]

>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.

[newdep]

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 :-)

[Lutz]

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

[HPW]

>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.

[Lutz]

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