Version française
Home     About     Download     Resources     Contact us    
Browse thread
Using Tk extensions under caml/labltk
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Michael Hohn <hohn@m...>
Subject: Re: Using Tk extensions under caml/labltk

>From <>:

>> ...
>>    You can do something equivalent by using the Protocol.tkEval command.
>>    You just have to preparse your string. This is basically how the whole
>>    library is built.
>>      val tkEval : tkArgs array -> string
>> ...

True.  Buried in my message was this:
	     tcl_eval "package require BLT"
	     tkEval [| TkToken "package"; TkToken "require"; TkToken "BLT"
	 On longer inputs, this would not be amusing... ]

This could be cleaned up by using Str.split, but that means a lot of
wasteful computing.

>> ...
>>    >     Also, it would be nice to have some interactive control over
>>    >     caml programs compiled to native code; wouldn't Tcl work well
>>    >     for this?
>>    Doesn't sound like a very good idea to me.
>> ...

There are several advantages to embedding caml in Tcl and using
(simple) Tcl scripts:

1.  All existing Tcl documentation can be used unchanged.  This is a
    problem in all languages that use their own bindings to Tcl.  Just
    recently, I had to battle with Python's binding methodology.
    Fortunately, a partial BLT wrapper was available.

2.  All Tk extensions will work immediately.  No need to produce
    wrapper function after wrapper function.  Again, Python's tkinter
    is a good example of pain...

3.  Conversion to and from Tcl takes time.  After profiling my
    Python/Tkinter GUI, about 25% (yes, 25%) of the time went to the
    argument conversion routines!  This would be better in caml, but
    it's bad in any event. 

>> ...
>>      I don't know what are your exact needs, but you might have a look at
>>      what is done inside efuns
>>      There Fabrice Le Feissant has a bytecode interpreter written in Caml,
>>      allowing dynamic loading of caml bytecode inside a native application.
>>      This is reasonably efficient. 
>> ...

And uses caml, which is what I want.  The problem thus reduces to
producing caml bindings, my second question:

>> ...
>>    > 2.  Apparently, most high-level widget interfaces are defined in
>>    >     otherlibs/labltk/Widgets.src, with special routines in 
>>    >     otherlibs/labltk/builtin/* and general low level support in 
>>    >     otherlibs/labltk/support.
>>    This approach also allows to define interfaces for other libraries
>>    independently. I don't know very well how this works, so somedbody more
>>    competent should answer, but for instance there was already an
>>    interface for BLT in the camltk41 version distributed with MMM.
>> ...

Yes, there was.  But again, there is no documentation of the idea
behind the binding.  After fiddling with it for a few hours, I dropped
it.  If I remember correctly, the binding was for version 1.8 of BLT,
and did not include the graph widget :(

Thanks for the ideas.  I'll have another look at MMM...