Re: Using Tk extensions under caml/labltk

From: Michael Hohn (hohn@math.utah.edu)
Date: Fri Mar 24 2000 - 19:09:54 MET

  • Next message: Max Skaller: "Re: variables in 'let rec'"

    >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