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 WAA21223; Tue, 18 May 2004 22:02:24 +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 WAA21212 for ; Tue, 18 May 2004 22:02:22 +0200 (MET DST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i4IK2LSH014951 for ; Tue, 18 May 2004 22:02:22 +0200 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BQAn6-00061S-00; Tue, 18 May 2004 22:02:20 +0200 Received: from [80.129.112.174] (helo=gate.gerd-stolpmann.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BQAn6-0001DA-00; Tue, 18 May 2004 22:02:20 +0200 Received: from ice.gerd-stolpmann.de (ice.gerd-stolpmann.de [192.168.0.13]) by gate.gerd-stolpmann.de (Postfix) with ESMTP id EBAEF5730; Tue, 18 May 2004 22:02:19 +0200 (CEST) Received: by ice.gerd-stolpmann.de (Postfix, from userid 1000) id CADB6B032; Tue, 18 May 2004 22:02:18 +0200 (CEST) Subject: Re: [Caml-list] Automatic wrapper generator From: Gerd Stolpmann To: Richard Jones Cc: caml-list In-Reply-To: <20040518121147.GA20094@redhat.com> References: <1084869517.19838.409.camel@pelican.wigram> <20040518090635.GA6918@bourg.inria.fr> <1084875941.19838.446.camel@pelican.wigram> <20040518121147.GA20094@redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1084910535.30471.49.camel@ice.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 18 May 2004 22:02:18 +0200 X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:a6865a839c0178d9aa0ce41878507ea2 X-Miltered: at concorde with ID 40AA6BCD.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 gerd:01 stolpmann:01 2004:99 interfacing:01 hvs:99 avs:99 high-level:01 wrappers:01 behave:01 deallocate:01 wdialog:01 sourceforge:01 wdialog:01 ids:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Die, 2004-05-18 at 14:11, Richard Jones wrote: > The actual problem with Gtk revolves (yet again) around memory > management. Gtk uses a rather half-baked reference counting scheme. > The problems with this are similar to the problems with interfacing > Perl (see below). > > > However at some stage, the only way to make a genuinely > > Ocaml centric version of a library such as Gtk is to write > > the wrapper code by hand. > > > > A low level generator is still useful though. > > It can help by importing the C interface into Ocaml, > > so at least you can try to do most of the remodelling > > to a higher level interface in Ocaml. > > It sounds very similar to Perl4caml, which offers two levels of > interface. At the lowest level you get to manipulate SVs, HVs and AVs > directly from OCaml [1]. You have to convert strings/ints to SVs when > calling Perl code (using sv_of_string, etc.), and when returning > values you have to convert them from SVs to OCaml native types (using > string_of_sv, etc.). For some libraries I've written high-level > wrappers which do all this conversion for you, allowing you to use > objects and modules which look just like OCaml native objects [2]. > > Perl uses reference counting. I still haven't worked out a scheme to > make reference counting behave well with the OCaml garbage collector, > so the current version of Perl4caml will never deallocate Perl objects > (there is an experimental makefile flag to turn deallocation on, but > this sometimes causes programs to crash). I've tried wrapping the > Perl objects in custom blocks, but it doesn't work, and I'd appreciate > some help sorting it out! Maybe a look at the WDialog interface for Perl helps: http://cvs.sourceforge.net/viewcvs.py/wdialog/wdialog/code/src/UI/Stubs/stubs.ml?rev=3.4.2.1&only_with_tag=wdialog-perlapi-030403-branch&view=auto (Note: This is only in the wdialog-perlapi-030403-branch, and not in the released version of WDialog.) This interface exports O'Caml objects as Perl objects, and not the other way round like Perl4caml. The concept is: - The objects exist when they exist on the O'Caml side. The Perl object is only a proxy for the O'Caml object. The existence is explicitly controlled by the global variable uiobjects_list; all existing objects are added to it. - The O'Caml object has a reference to the Perl proxy, but the Perl proxy knows only the ID of the O'Caml object that can be used to look it up in uiobjects_list. This is important: In one direction one can use addresses to reference, but in the other direction one must use a weak name like object IDs. - There is a finaliser for the O'Caml object. When it is called, the reference counter of the Perl proxy is decreased. Usually, the counter goes to zero then, and the Perl proxy will be deallocated. It may happen, however, that the proxy lives longer than the object. However, when one calls methods of such half-dead proxies, exceptions are raised, so this is not a problem. A half-dead proxy can be detected because the object ID cannot be looked up. - The remaining question is when an object should be removed from uiobject_list. Fortunately, there is a kind of activity cycle, and when the cycle is over, it is possible to set uiobject_list:=[]. This solution may be interesting for you, because it demonstrates some useful techniques like finalisers, and because one can see which questions must be answered. Btw, the code is fully debugged, and passes a test showing that all memory is actually freed after the activity cycle. I think the point is that this API selects one of the memory managers as the primary one. For a number of reasons the O'Caml manager was chosen. In the other language one has only proxies that route accesses across the language boundary. A major problem are cyclic references between the managers. When they cannot be avoided, e.g. to realise callbacks across the language boundary, the primary manager must record these references explicitly, and give them a weak name (like the object IDs). It may happen that the weak name cannot be resolved, and this is handled as a runtime error. The weak names must be allocated and deallocated explicitly by user code (Wdialog binds this to the activity cycle, but such a thing is not available in the general case.) I hope this gives you some idea how to tackle this problem. Gerd -- ------------------------------------------------------------ Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de ------------------------------------------------------------ ------------------- 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