From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id FAA20758; Mon, 29 Mar 2004 05:37:09 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id FAA17420 for ; Mon, 29 Mar 2004 05:37:08 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i2T3b5Hd024393 for ; Mon, 29 Mar 2004 05:37:06 +0200 Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3p2-20030924/3.7W) with ESMTP id MAA09930; Mon, 29 Mar 2004 12:36:54 +0900 (JST) To: skaller@users.sourceforge.net Cc: caml-list@inria.fr Subject: Re: [Caml-list] Delaying module initialization In-Reply-To: <1080517867.4708.174.camel@pelican.wigram> References: <1080403497.4708.160.camel@pelican.wigram> <20040328193438O.garrigue@kurims.kyoto-u.ac.jp> <1080517867.4708.174.camel@pelican.wigram> <1080520544.4708.188.camel@pelican.wigram> X-Mailer: Mew version 1.94.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20040329123654I.garrigue@kurims.kyoto-u.ac.jp> Date: Mon, 29 Mar 2004 12:36:54 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 jacques:01 sourceforge:01 2004:99 jacques:01 dynamically:01 dynamically:01 invokes:01 model:01 model:01 runtime:01 camlgl:01 runtime:01 stub:01 unload:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 403 From: skaller > On Sun, 2004-03-28 at 20:34, Jacques Garrigue wrote: > > > > The former is interesting but not industrially satisfying > > > because it doesn't allow dynamic loading of interfaces > > > to C, which must be native code. > > > > But, this is plain wrong: since 3.04 you can dynamically load C stubs > > through dynamically loading a bytecode library. > > This I do not understanding but I seem to have missed something. > > Are you saying I can write a module X.ml which wraps a C library > with function f(), and another Y.ml which wraps a different > function f() of another shared library, and then write a > program which can be run like: > > loadit X > loadit Y > > where the first script invokes X's f() and the second Y's f()? You are mixing here different problems, and I can interpret your question in several ways. If your question is: can I load simultaneously several shared libraries containing some C functions with the same name, then the answer is probably: only under windows. But I did not try, so maybe it works on other systems too, or maybe it doesn't work on windows for some reason. This is a question of C binary namespace, flat or hierarchical. To simplify writing libraries, ocaml uses the flat model (more usual on Unix), but windows happens to support only the hierarchical model. If it is: can I choose at runtime which shared library to load, and provide a unified interface independent of the library, then the answer is yes. IIRC, CamlGL uses that to allow choosing your openGL library at runtime. There are some pitfalls, like the fact you need to provide a different stub library (both C and caml part) for each shared library you want to load, or the fact you cannot unload a library. But in my opinion the main problem is that different libraries shall probably have different signatures under the refined ocaml type system, so that it will be very hard to use a unified interface (we have already trouble with the different version of Gtk+-2.x). If it is: can I dynamically generate stubs for a shared library, compile them (both C and caml part) and load the library in the same program, then this should be yes too. Automatizing all this might be a lot of work, but there is no theoretical limitation. Again there may be problems with name spaces, but if this is really your concern you just have to change one line in ocamlrun sources to use the hierarchical model. > If dynamic loading is as Jacques suggests, then it would > seem mod_caml has a strange design.. > > Given an HTML page containing some Caml script > which in invokes some functions which wrap > Perl modules .. the whole thing should be > dynamic automatically. > > I can't see how 'initialising all the Perl modules' > could happen. I'd have to try extremely hard to even > think about how to make that happen. Here we enter another problem: ocaml has dynamic loading, but not auto-loading/initializing. Looks like lots of people would want to have that: a module would be initialized only when one of its members is used. This is _not_ a problem of dynamic loading, and this could actually change the semantics of the language, since initializing one module might force initializing another one in its turn, and as a result module initialization might not be sequential. On the other hand, this should not be too hard to do with bytecode, at least java style: parse the .cma's, but do not load their dependencies immediately. Without auto-loading, you end-up loading everything in your name space; so that would result in initializing all Perl modules if you are initializing them on load. Some workarounds have already been suggested to delay this initialization. Jacques Garrigue ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners