On Tue, Mar 11, 2008 at 04:02:01PM -0400, Hezekiah M. Carty wrote: > On Tue, Mar 11, 2008 at 5:32 AM, Andrew Ross > <[EMAIL PROTECTED]> wrote: > > I agree that swig would be good to minimise maintenance effort. I see > > that the camidl approach needs (another) modified copy of plplot.h. Swig > > would presumably use the existing plplotcapi.i file. Having said that, > > if there are convincing technical reasons for using camidl I could be > > persuaded. > > The plplot_h file (yet another modified plplot.h) is a definite > down-side to the camlidl approach to generating these bindings. > However, even with that issue I think maintenance of the OCaml > bindings will be easier with camlidl and, as you quoted from one of my > previous emails the resulting OCaml interface is much lighter weight. > > The maintainer of the swig-based OCaml bindings (found here: > http://vityok.org.ua/cgi-bin/odd.cgi/Ocaml-plplot) has said that they > are unable to dedicate the time to continuing upkeep of those > bindings. > > One of the main reasons I chose camlidl over swig as a binding aid is > that camlidl handles C -> OCaml types in a much more clean and direct > fashion than swig does. In order to make the swig-based OCaml > interface look like the C API, every function has to be wrapped in > extra OCaml code to extract or copy values from swig generated > wrappers. In the case of camlidl you end up with this interface > without the extra code. This is partly due to camlidl being very > OCaml specific and covering fewer C and C++ features out of the box > than swig does. PLplot's C api is thankfully quite simple overall, so > camlidl can handle the vast majority of the functions without much > manual intervention. The end result is a very OCaml-friendly > interface without a lot of extra hand-coding. > > The functions that camlidl does not handle on its own (functions > taking callback parameters mainly) are wrapped by hand. > > As an example, moving from a plplot_h based on 5.7.3 to one based on > 5.9.0 (admittedly not a huge change, but did include the char* -> > const char* and several new functions) took me much less than an hour, > including getting the PLplot code, installing it and updating the > OCaml parts. The steps I used to do so are indicated here if you want > a better description of the process: > http://code.google.com/p/ocaml-plplot/wiki/HowItWorks > > I hope this clarifies why I think camlidl is still the way to go for > the OCaml interface. I am quite open to further discussion though if > needed.
Hi Hez, Thanks for this. None of the core developers are ocaml experts, so we will bow to your advice on the benefits of camlidl. The fact that you are willing to support the code is a big plus to us. I've got round to trying your code. It took a while as my ubuntu systems don't yet have ocaml 3.10 which is required to get ocamlbuild. This may limit the use of the bindings in the short term, but I expect serious ocaml users will upgrade. The next round of distribution releases will fix this I'm sure. A few points: Can you remove plarrows from the bindings? This is in line with recent svn changes. The function has been deprecated for several years and no longer appears in the examples. It is still available under C for now, but we certainly don't want to propagate it to new bindings. Ocamlbuild looks like a good way of building the bindings and handling dependencies. Is it possible to use some other way of installing though? For plplot the bindings should be installed in the specified install location. This makes it easier to keep the install in a specific place for testing etc and also makes it possible to install without root privileges. Ideally we would have some more examples implemented. It is always good to have a full set of examples. Firstly this shows users how to use plplot with the language. Secondly it provides a thorough test of the bindings and helps to detect problems. If you can sort out these issues I'm happy to help you integrate the bindings in with the cmake build system. From the look of the Makefile this should be (relatively) simple. Andrew ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel