>From <garrigue@kurims.kyoto-u.ac.jp>:
>> ...
>> 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:
[Compare:
tcl_eval "package require BLT"
vs.
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
>> http://pauillac.inria.fr/para/cdrom/prog/unix/efuns/eng.htm
>> 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...
Cheers,
Michael
This archive was generated by hypermail 2b29 : Mon Mar 27 2000 - 19:30:34 MET DST