Browse thread
[Caml-list] Automatic wrapper generator
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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