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 QAA27065 for caml-redistribution@pauillac.inria.fr; Fri, 24 Mar 2000 16:50:58 +0100 (MET) Resent-Message-Id: <200003241550.QAA27065@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 JAA11630 for ; Fri, 24 Mar 2000 09:10:16 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id JAA04681 for ; Fri, 24 Mar 2000 09:10:14 +0100 (MET) Received: from localhost (sansho.kurims.kyoto-u.ac.jp [130.54.16.90]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id RAA06106; Fri, 24 Mar 2000 17:10:09 +0900 (JST) To: hohn@math.utah.edu Cc: caml-list@inria.fr Subject: Re: Using Tk extensions under caml/labltk In-Reply-To: Your message of "Wed, 22 Mar 2000 13:21:06 -0700 (MST)" <200003222021.NAA03988@suntan.math.utah.edu> References: <200003222021.NAA03988@suntan.math.utah.edu> X-Mailer: Mew version 1.93 on Emacs 20.5 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000324171008W.garrigue@kurims.kyoto-u.ac.jp> Date: Fri, 24 Mar 2000 17:10:08 +0900 From: Jacques Garrigue X-Dispatcher: imput version 980905(IM100) Resent-From: weis@pauillac.inria.fr Resent-Date: Fri, 24 Mar 2000 16:50:58 +0100 Resent-To: caml-redistribution@pauillac.inria.fr From: Michael Hohn > Recently, I needed to use the BLT extension to Tk. Since all my data comes > from ocaml, and there is a fair amount of data, I wrote a simple C interface. > Below are the steps I took under ocaml-2.04. > My questions are: > > 1. Why is tcl_eval not exported by default (in protocol.mli)? I > don't like Tcl much, but > for trivial commands like "package require blt", I don't see a > problem with direct string evaluation. 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 > 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. 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. > 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. Jacques --------------------------------------------------------------------------- Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp JG