Message-ID: <423747A6.3060606 at rftp.com>
Date: Tue, 15 Mar 2005 12:37:58 -0800
From: Robert Roessler <roessler at rftp.com>
Organization: Robert's High-performance Software
MIME-Version: 1.0
To: Jacques Garrigue <garrigue at math.nagoya-u.ac.jp>
CC: lablgtk at math.nagoya-u.ac.jp
Subject: Re: Relationship of LablGTK/GTK signal processing
References: <423212DE.5090007 at rftp.com>	<20050312.162426.68555891.garrigue at kurims.kyoto-u.ac.jp>	<423555E6.7060202 at rftp.com> <20050315.152358.111179216.garrigue at math.nagoya-u.ac.jp> <4236AB33.2060508 at rftp.com>
In-Reply-To: <4236AB33.2060508 at rftp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Robert Roessler wrote:

> Jacques Garrigue wrote:
> 
>> From: Robert Roessler <robertr@rftp.com>
>> ...
>> Note that the above code code doesn't attempt to do anything about the
>> pointer. It just allows you to get a hand on it, and eventually call a
>> C function that will use it. No memory management is done.
>> Note also that this pointer is "boxed", ie. the actuall pointer is in
>> the second field of an abstract ocaml block, which you can access on
>> the C side as Field(p,1).
> 
> 
> Reality is not quite matching expectations... to start with, the 
> callback ends up looking like int -> Gpointer.boxed option -> unit... 
> the runtime "boxed" pointer as seen by my
> 
> CAMLprim value ml_scn_from_boxed_pointer(value bpVal)
> 
> function has tag==0 and Wosize==1.  Seriously.  Also, interpreting the 
> pointed-to memory as the expected structure is problematic. :)
> 
> BTW, this function is intended to construct a record representation of 
> the Scintilla "SCNotification" struct.

That was easy - upon short reflection, it became clear that the extra 
level of indirection is because of the "option" - marshalling (at 
least in this direction) now functions properly! :)

Robert Roessler
roessler@rftp.com
http://www.rftp.com