From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA07402 for caml-redistribution@pauillac.inria.fr; Mon, 27 Mar 2000 19:26:08 +0200 (MET DST) Resent-Message-Id: <200003271726.TAA07402@pauillac.inria.fr> Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA28190 for ; Fri, 24 Mar 2000 19:09:58 +0100 (MET) Received: from csc-sun.math.utah.edu (csc-sun.math.utah.edu [128.110.198.2]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id TAA29881 for ; Fri, 24 Mar 2000 19:09:57 +0100 (MET) Received: from suntan.math.utah.edu (suntan.math.utah.edu [155.99.144.26]) by csc-sun.math.utah.edu (8.9.3/8.9.3) with ESMTP id LAA05917; Fri, 24 Mar 2000 11:09:55 -0700 (MST) Received: (from hohn@localhost) by suntan.math.utah.edu (8.9.3/8.9.3) id LAA19108; Fri, 24 Mar 2000 11:09:54 -0700 (MST) Date: Fri, 24 Mar 2000 11:09:54 -0700 (MST) Message-Id: <200003241809.LAA19108@suntan.math.utah.edu> X-Authentication-Warning: suntan.math.utah.edu: hohn set sender to hohn@math.utah.edu using -f From: Michael Hohn To: garrigue@kurims.kyoto-u.ac.jp CC: caml-list@inria.fr In-reply-to: <20000324171008W.garrigue@kurims.kyoto-u.ac.jp> (message from Jacques Garrigue on Fri, 24 Mar 2000 17:10:08 +0900) Subject: Re: Using Tk extensions under caml/labltk References: <200003222021.NAA03988@suntan.math.utah.edu> <20000324171008W.garrigue@kurims.kyoto-u.ac.jp> Resent-From: weis@pauillac.inria.fr Resent-Date: Mon, 27 Mar 2000 19:26:08 +0200 Resent-To: caml-redistribution@pauillac.inria.fr >>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: [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