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/

Here a test code for calling the DLL:

Code: Select all

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