Re: [Plplot-general] Bindings for Ada and a dumb C question

[Alan W. I. <ir...@be...>]

On 2006-07-03 12:07+0200 Arjen Markus wrote:

> lan...@qw... wrote:
>
>> Hi list,
>>
>> Sorry to bother with such a trivial question that should properly be
>> asked elsewhere, but maybe you'll humor me.
>>
>> I'm making some serious progress as a spare-time project in making
>> Ada bindings for PLplot, and some of the examples are working well.
>> Here's my dumb C question: If there is a C procedure such as
>>
>> void plfoo(PLFLT *bar);
>>
>> how does one tell if the parameter is intended to be a pointer to an
>> array of PLFLT or whether it is simply a scalar (single number) PLFLT
>> that is being passed by reference? Am I missing something here? Will
>> I have to consult the API reference for each function to discover
>> what is intended if it's not obvious otherwise?
>>
>>
> Unfortunately, C does not make any distinction between the two cases
> you mention. So, indeed, you will have to consult the documentation instead
> (and ultimately even the source code for that particular function).
>
> You may find it useful to look at the Fortran 90/95 interface, because for
> that interface we had to solve the same (or at least a similar) problem.
> We have not used the INTENT(IN/OUT) attribute there, because it
> might interfere with the way C expects the arguments to be passed,
> but at least it will give you a way other than the documentation of
> identifying which are scalar and which are array arguments.
>
> PLplot has a helpful naming convention:
> plg - for functions that return attributes
> pls - for functions that set attributes

To add to what Arjen said, our swig-based interfaces (currently Java and
Python) require exactly the information you requested.  It is collected in
bindings/swig-support/plplotcapi.i in an easy-to-understand form.

BTW, have you considered using Swig for this Ada interface?  Swig provides a
framework for interfacing any language with C libraries such as libplplot.
It's huge advantage is it recognizes all distinct C argument patterns (see
plplotcapi.i above) and treats them in a uniform manner rather than relying
on human recognition of the argument pattern that is required for
hand-crafted interfaces and the associated errors from failing to recognize
the pattern or treat it in a uniform way. Also, since we have plplotcapi.i
already set up, adding a new PLplot language interface using swig is
straightforward.

Case in point, we had worked on a hand-crafted Java interface to PLplot off
and on for years, but I was getting frustrated by how much effort it would
take to complete it.  Therefore, I tried the swig approach instead following
the pioneering effort that had been done with the swig-based python
interface.  That new swig-based Java interface took me, a relative Java
newbie, only a week or so to set up, and the result was automatically
complete.  It's because of this huge saving of programming effort that
I always recommend swig for new language interfaces to PLplot.

The only difficulty I can see with generating a swig-based Ada interface to
PLplot is that language is not yet officially supported by swig (see
http://www.swig.org/compat.html#SupportedLanguages which details the ~20
computer languages officially supported by Swig). However, a superficial
google search for (swig ada) showed there has been at least one attempt to
add an ada module to swig.  At that point, I didn't dig any deeper, but if
there is continuing development of such a module, you might benefit a whole
lot of Ada users (not just PLplot ones) by adding your Ada interfacing
expertise to that effort.  The whole effort might actually take less time
than a hand-crafted interface to PLplot simply because of the argument
pattern recognition factor discussed above which makes the swig-based
approach so much easier to programme.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________