plplot-general

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

[<lan...@qw...>]

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?

Jerry (aka C idiot)

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

[Arjen M. <arj...@wl...>]

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

Regards,

Arjen

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
__________________________

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

[<lan...@qw...>]

On Jul 3, 2006, at 2:55 AM, 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?
>
> Jerry (aka C idiot)

Thanks to everyone for their suggestions. I'm finding the Modula-3  
bindings very helpful, and I'll take a look at the FORTRAN bindings-- 
I've found a handy FORTRAN-to-Ada converter that worked pretty well  
for converting some of the examples to Ada--maybe I should have  
applied it to the bindings themselves. I also found a c2ada converter  
that looks very polished but unfortunately needs a bit of updating in  
order to work correctly. I looked at the SWIG approach but decided  
that for this rather smallish job, given Ada's relatively  
friendliness with C, and given that learning about SWIG was still  
another layer of stuff I didn't know (added to C and Ada itself),  
that a more direct approach would work OK. I've used a few regex  
lines applied to plplot.h to great advantage. About the only thing  
puzzling me now is what in the heck is this:

typedef struct {
     char *opt;
     int  (*handler)	(char *, char *, void *);  <<<<<<< ?
     void *client_data;                             <<<<<<< ?
     void *var;                                     <<<<<<< ?
     long mode;
     char *syntax;
     char *desc;
} PLOptionTable;

Jerry

[Plplot-general] PLPlot DLL

[Henning T. <pl...@he...>]

I have some very stupid FAQ: Is there some DLL of plplot availabe? I have
some program developed with Modula-3 using plplot on Linux and now I want
to run that on plain Windows XP without going through the nightmare of
installing a C compiler on Windows or even a Linux emulation environment.
I hope that a precompiled DLL of plplot would save me much trouble. But I
only see a source archive on sourceforge.net, packed with tar, which is
already a problem for a bare Windows, you know. :-)

Re: [Plplot-general] PLPlot DLL

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

On 2006-07-19 17:32+0200 Henning Thielemann wrote:

>
> I have some very stupid FAQ: Is there some DLL of plplot availabe? I have
> some program developed with Modula-3 using plplot on Linux and now I want
> to run that on plain Windows XP without going through the nightmare of
> installing a C compiler on Windows or even a Linux emulation environment.
> I hope that a precompiled DLL of plplot would save me much trouble. But I
> only see a source archive on sourceforge.net, packed with tar, which is
> already a problem for a bare Windows, you know. :-)

Hi Henning:

I am not aware of any publically available PLplot DLL for bare Windows.
However, we are making excellent progress with the new CMake build system
which should make it much easier to build PLplot on Linux, Unix, Mac OS X,
and especially bare Windows.  Of course, a compiler is required for the
build, but you cannot have everything. :-)

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
__________________________