Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: hohn@math.utah.edu
Cc: caml-list@inria.fr
Subject: Re: Using Tk extensions under caml/labltk
Date: Fri, 24 Mar 2000 17:10:08 +0900	[thread overview]
Message-ID: <20000324171008W.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: Your message of "Wed, 22 Mar 2000 13:21:06 -0700 (MST)" <200003222021.NAA03988@suntan.math.utah.edu>

From: Michael Hohn <hohn@math.utah.edu>

> 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
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>



  reply	other threads:[~2000-03-24 15:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-22 20:21 Michael Hohn
2000-03-24  8:10 ` Jacques Garrigue [this message]
2000-03-24 18:09   ` Michael Hohn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20000324171008W.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=hohn@math.utah.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox