Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Automatic wrapper generator
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Michael Hamburg <hamburg@f...>
Subject: Re: [Caml-list] Automatic wrapper generator
>
> 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!

I don't know how Perl's reference-counting scheme works, but I'm  
working on interfacing O'Caml with Cocoa, which also uses ref-counts.   
I've basically made O'Caml incref any object allocated on its heap, and  
decref it as a finalization step.  Conversely, O'Caml objects in C get  
added to the global roots.  I still have to do more testing, but it  
seems that this doesn't crash, nor does it leak much memory.

I say much because such a scheme cannot detect loops.  I think you'd  
have to mod the garbage collector to do so.  As of now, there's also no  
way to safely break a known loop, since decrefing an object may cause  
it to go away before O'Caml can finalize it, which would cause a  
segfault.  An interface change to the  Cocoa wrapper of O'Caml objects  
might fix this.

Mike

> Rich.
>
> [1] The low-level interface:
> http://www.merjis.com/developers/perl4caml/html/Perl.html
>
> [2] Example of a high-level wrapper:
> http://www.merjis.com/developers/perl4caml/html/Pl_HTML_Element.html
> http://www.merjis.com/developers/perl4caml/html/ 
> Pl_HTML_Element.html_element.html
>
> -- 
> Richard Jones. http://www.annexia.org/ http://www.j-london.com/
> Merjis Ltd. http://www.merjis.com/ - improving website return on  
> investment
> http://www.winwinsales.co.uk/ - CRM improvement consultancy

-------------------
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