librelist archives

« back to archive

Fortran bindings and an api suggestion

Fortran bindings and an api suggestion

From:
Neil N. Carlson
Date:
2011-07-12 @ 14:10
I've written Fortran 2003 bindings to a portion of yajl
(yajl_parse.h) and was pleasantly surprised that interfacing
OO Fortran to the C interface with its callbacks was easy
after some careful thought, and works quite well.

I do have one quibble about the C interface, specifically
yajl_config.  This function uses varargs, and as such is
not considered "interoperable" with Fortran.  I've lied
(to the Fortran compiler) and treated it as a function that
takes a single option argument.  That appears to work for
the one compiler I'm using, but I'm not at all confident
that this will be portable; there's no reason to expect
that it will be.

I'm not sure how other languages handle binding to this
function -- maybe it's not an issue -- but I'd suggest
changing the interface to accept a single option argument
instead of a variable number.  Further, I find the
semantics of the function to be somewhat odd: it can only
be called with "pure" option values and it internally
or's them with an internal options value; options can
be set but never unset.  It would be much more flexible
to allow/require the user to define the (full) options
value by or'ing (or whatever) the pure option enum values
and passing that to yajl_config who would just use it as is.
This would be a lot more consistent with conventional
practice (at least as I have observed it).

In any case, thanks for yajl!

-- 
Neil Carlson
Computational Physics and Methods (CCS-2)
Los Alamos National Laboratory
PO Box 1663, MS D413 · Los Alamos, NM 87545
505.665.6386 · 505.665.4972 (fax)

Re: [yajl] Fortran bindings and an api suggestion

From:
Hatem Nassrat
Date:
2011-07-12 @ 14:24
On Tue, Jul 12, 2011 at 11:10 AM, Neil N. Carlson <nnc@lanl.gov> wrote:
>
> I do have one quibble about the C interface, specifically
> yajl_config.  This function uses varargs, and as such is
> not considered "interoperable" with Fortran.  I've lied

I had the same issue with ctypes wrapper to yajl (yajl-py), I was not
able to prototype declare the config function, However, this is not
necessary with ctypes and thus yajl-py still works, but there are some
cases where not declaring the argument types (ie. the prototype
declaration) causes issues.

-- 
Hatem Nassrat

Re: [yajl] Fortran bindings and an api suggestion

From:
R. Tyler Croy
Date:
2011-07-12 @ 16:36
On Tue, 12 Jul 2011, Neil N. Carlson wrote:

> I've written Fortran 2003 bindings to a portion of yajl
> (yajl_parse.h) and was pleasantly surprised that interfacing
> OO Fortran to the C interface with its callbacks was easy
> after some careful thought, and works quite well.
> 
> I do have one quibble about the C interface, specifically
> yajl_config.  This function uses varargs, and as such is
> not considered "interoperable" with Fortran.  I've lied
> (to the Fortran compiler) and treated it as a function that
> takes a single option argument.  That appears to work for
> the one compiler I'm using, but I'm not at all confident
> that this will be portable; there's no reason to expect
> that it will be.
> 
> I'm not sure how other languages handle binding to this
> function -- maybe it's not an issue -- but I'd suggest
> changing the interface to accept a single option argument
> instead of a variable number.  Further, I find the
> semantics of the function to be somewhat odd: it can only
> be called with "pure" option values and it internally
> or's them with an internal options value; options can
> be set but never unset.  It would be much more flexible
> to allow/require the user to define the (full) options
> value by or'ing (or whatever) the pure option enum values
> and passing that to yajl_config who would just use it as is.
> This would be a lot more consistent with conventional
> practice (at least as I have observed it).


Are there any configuration options that actually make use of the va_args
nature of yajl_config?

All the examples I've found have passed (generator, mask, int/bool)


Where for art thou Lloyd? :D

- R. Tyler Croy
--------------------------------------
    Code: http://github.com/rtyler
 Chatter: http://identi.ca/agentdero
          http://twitter.com/agentdero

Re: [yajl] Fortran bindings and an api suggestion

From:
Hatem Nassrat
Date:
2011-07-12 @ 17:37
On Tue, Jul 12, 2011 at 1:36 PM, R. Tyler Croy <tyler@monkeypox.org> wrote:

> Are there any configuration options that actually make use of the va_args
> nature of yajl_config?
>
> All the examples I've found have passed (generator, mask, int/bool)
>

The option for indent_string (thats actually yajl_gen_config) takes a char *
(instead of int/bool)


-- 
Hatem Nassrat

Re: [yajl] Fortran bindings and an api suggestion

From:
Lloyd Hilaiel
Date:
2011-07-12 @ 17:49
<html><body class="ApplePlainTextBody" style="word-wrap: break-word; 
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">On Jul 
12, 2011, at 10:36 AM, R. Tyler Croy wrote:<br><br><blockquote 
type="cite"><br></blockquote><blockquote type="cite">On Tue, 12 Jul 2011, 
Neil N. Carlson wrote:<br></blockquote><blockquote 
type="cite"><br></blockquote><blockquote type="cite"><blockquote 
type="cite">I've written Fortran 2003 bindings to a portion of 
yajl<br></blockquote></blockquote><blockquote type="cite"><blockquote 
type="cite">(yajl_parse.h) and was pleasantly surprised that 
interfacing<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">OO Fortran to the C interface with its
callbacks was easy<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">after some careful thought, and works 
quite well.<br></blockquote></blockquote><blockquote 
type="cite"><blockquote 
type="cite"><br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">I do have one quibble about the C 
interface, specifically<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">yajl_config.  This function uses 
varargs, and as such is<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">not considered "interoperable" with 
Fortran.  I've lied<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">(to the Fortran compiler) and treated 
it as a function that<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">takes a single option argument. 
 That appears to work for<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">the one compiler I'm using, but I'm 
not at all confident<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">that this will be portable; there's no
reason to expect<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">that it will 
be.<br></blockquote></blockquote><blockquote type="cite"><blockquote 
type="cite"><br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">I'm not sure how other languages 
handle binding to this<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">function -- maybe it's not an issue --
but I'd suggest<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">changing the interface to accept a 
single option argument<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">instead of a variable number. 
 Further, I find the<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">semantics of the function to be 
somewhat odd: it can only<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">be called with "pure" option values 
and it internally<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">or's them with an internal options 
value; options can<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">be set but never unset.  It would
be much more flexible<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">to allow/require the user to define 
the (full) options<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">value by or'ing (or whatever) the pure
option enum values<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">and passing that to yajl_config who 
would just use it as is.<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">This would be a lot more consistent 
with conventional<br></blockquote></blockquote><blockquote 
type="cite"><blockquote type="cite">practice (at least as I have observed 
it).<br></blockquote></blockquote><blockquote 
type="cite"><br></blockquote><blockquote 
type="cite"><br></blockquote><blockquote type="cite">Are there any 
configuration options that actually make use of the 
va_args<br></blockquote><blockquote type="cite">nature of 
yajl_config?<br></blockquote><br>For the generator, yes.  see 
yajl_gen.c line 81, the handling 
of <br>yajl_gen_print_callback.<br><br>it's true that the config api 
is generalized for an exception, alas.<br><br>lloyd<br><br></body></html>

Re: [yajl] Fortran bindings and an api suggestion

From:
Hatem Nassrat
Date:
2011-07-12 @ 18:23
Am i the only one who received a blob :), here is an attempt to resend
lloyd's email


> On Jul 12, 2011, at 10:36 AM, R. Tyler Croy wrote:
>
>
> On Tue, 12 Jul 2011, Neil N. Carlson wrote:
>
>
> I've written Fortran 2003 bindings to a portion of yajl
>
> (yajl_parse.h) and was pleasantly surprised that interfacing
>
> OO Fortran to the C interface with its callbacks was easy
>
> after some careful thought, and works quite well.
>
>
> I do have one quibble about the C interface, specifically
>
> yajl_config.  This function uses varargs, and as such is
>
> not considered "interoperable" with Fortran.  I've lied
>
> (to the Fortran compiler) and treated it as a function that
>
> takes a single option argument.  That appears to work for
>
> the one compiler I'm using, but I'm not at all confident
>
> that this will be portable; there's no reason to expect
>
> that it will be.
>
>
> I'm not sure how other languages handle binding to this
>
> function -- maybe it's not an issue -- but I'd suggest
>
> changing the interface to accept a single option argument
>
> instead of a variable number.  Further, I find the
>
> semantics of the function to be somewhat odd: it can only
>
> be called with "pure" option values and it internally
>
> or's them with an inte rnal options value; options can
>
> be set but never unset.  It would be much more flexible
>
> to allow/require the user to define the (full) options
>
> value by or'ing (or whatever) the pure option enum values
>
> and passing that to yajl_config who would just use it as is.
>
> This would be a lot more consistent with conventional
>
> practice (at least as I have observed it).
>
>
>
> Are there any configuration options that actually make use of the va_args
>
> nature of yajl_config?
>
>
> For the generator, yes.  see yajl_gen.c line 81, the handling of
> yajl_gen_print_callback.
>
> it's true that the config api is generalized for an exception, alas.
>
> lloyd


-- 
Hatem Nassrat

Re: [yajl] Fortran bindings and an api suggestion

From:
Neil N. Carlson
Date:
2011-07-12 @ 22:43
On Tue, 2011-07-12 at 15:23 -0300, Hatem Nassrat wrote:
> Am i the only one who received a blob :), here is an attempt to resend
> lloyd's email
>  
>         On Jul 12, 2011, at 10:36 AM, R. Tyler Croy wrote:
>         > Are there any configuration options that actually make use
>         > of the va_args
>         > nature of yajl_config?
>         
>         For the generator, yes.  see yajl_gen.c line 81, the handling
>         of 
>         yajl_gen_print_callback.
>         
>         it's true that the config api is generalized for an exception,
>         alas.

I take back some of what I wrote about yajl_config.  I extrapolated
incorrectly from the doxygen page.  Looking at the actual yajl_parse.h
file it seems that if the argument is yajl_allow_comments or
yajl_dont_validate_strings it looks for a second argument (a bool);
presumably to turn on/off the option.  The remaining possible options
don't seem to take a second argument at all.  I'm not sure what the
rationale is here.

In any case, it turns out that the Fortran binding to yajl_config
does *not* work.  I'll have to write a surrogate C function (and
write the Fortran binding to it) in order to access the functionality
of yajl_config (ugly).

I'd really like to see that bit of the yajl api modified to avoid
the use of va_args -- it will make writing bindings to yajl from
other languages easier.

-- 
Neil Carlson
Computational Physics and Methods (CCS-2)
Los Alamos National Laboratory
PO Box 1663, MS D413 · Los Alamos, NM 87545
505.665.6386 · 505.665.4972 (fax)

Re: [yajl] Fortran bindings and an api suggestion

From:
Lloyd Hilaiel
Date:
2011-07-12 @ 22:54
On Tue, Jul 12, 2011 at 04:43:29PM -0600, Neil N. Carlson wrote:
> On Tue, 2011-07-12 at 15:23 -0300, Hatem Nassrat wrote:
> > Am i the only one who received a blob :), here is an attempt to resend
> > lloyd's email
> >  
> >         On Jul 12, 2011, at 10:36 AM, R. Tyler Croy wrote:
> >         > Are there any configuration options that actually make use
> >         > of the va_args
> >         > nature of yajl_config?
> >         
> >         For the generator, yes.  see yajl_gen.c line 81, the handling
> >         of 
> >         yajl_gen_print_callback.
> >         
> >         it's true that the config api is generalized for an exception,
> >         alas.
> 
> I take back some of what I wrote about yajl_config.  I extrapolated
> incorrectly from the doxygen page.  Looking at the actual yajl_parse.h
> file it seems that if the argument is yajl_allow_comments or
> yajl_dont_validate_strings it looks for a second argument (a bool);
> presumably to turn on/off the option.  The remaining possible options
> don't seem to take a second argument at all.  I'm not sure what the
> rationale is here.

I disagree with your assessment of yajl_config:
https://github.com/lloyd/yajl/blob/master/src/yajl.c#L81-103

All of the options should take an integer argument where zero is false
(turns the feature off) and non-zero turns the feature on.

I agree that there's a documentation bug, feel free to file!
https://github.com/lloyd/yajl/blob/master/src/api/yajl_parse.h#L134-159

> In any case, it turns out that the Fortran binding to yajl_config
> does *not* work.  I'll have to write a surrogate C function (and
> write the Fortran binding to it) in order to access the functionality
> of yajl_config (ugly).

yuck.

> I'd really like to see that bit of the yajl api modified to avoid
> the use of va_args -- it will make writing bindings to yajl from
> other languages easier.

Feel free to file a bug with a proposed alternative api.  I'm not
interested in making the change in the short term for reasons of
binary compatibility (we just broke that with yajl 2, a mere three
months ago (http://lloyd.io/whats-new-in-yajl-two).

lloyd

> --
> Neil Carlson
> Computational Physics and Methods (CCS-2)
> Los Alamos National Laboratory
> PO Box 1663, MS D413 · Los Alamos, NM 87545
> 505.665.6386 · 505.665.4972 (fax)
> 

Re: [yajl] Fortran bindings and an api suggestion

From:
R. Tyler Croy
Date:
2011-07-12 @ 23:26
On Tue, 12 Jul 2011, Lloyd Hilaiel wrote:

> On Tue, Jul 12, 2011 at 04:43:29PM -0600, Neil N. Carlson wrote:
> > On Tue, 2011-07-12 at 15:23 -0300, Hatem Nassrat wrote:
> > > Am i the only one who received a blob :), here is an attempt to resend
> > > lloyd's email
> > >  
> > >         On Jul 12, 2011, at 10:36 AM, R. Tyler Croy wrote:
> > >         > Are there any configuration options that actually make use
> > >         > of the va_args
> > >         > nature of yajl_config?
> > >         
> > >         For the generator, yes.  see yajl_gen.c line 81, the handling
> > >         of 
> > >         yajl_gen_print_callback.
> > >         
> > >         it's true that the config api is generalized for an exception,
> > >         alas.
> > 
> > I take back some of what I wrote about yajl_config.  I extrapolated
> > incorrectly from the doxygen page.  Looking at the actual yajl_parse.h
> > file it seems that if the argument is yajl_allow_comments or
> > yajl_dont_validate_strings it looks for a second argument (a bool);
> > presumably to turn on/off the option.  The remaining possible options
> > don't seem to take a second argument at all.  I'm not sure what the
> > rationale is here.
> 
> I disagree with your assessment of yajl_config:
> https://github.com/lloyd/yajl/blob/master/src/yajl.c#L81-103
> 
> All of the options should take an integer argument where zero is false
> (turns the feature off) and non-zero turns the feature on.
> 
> I agree that there's a documentation bug, feel free to file!
> https://github.com/lloyd/yajl/blob/master/src/api/yajl_parse.h#L134-159
> 
> > In any case, it turns out that the Fortran binding to yajl_config
> > does *not* work.  I'll have to write a surrogate C function (and
> > write the Fortran binding to it) in order to access the functionality
> > of yajl_config (ugly).
> 
> yuck.
> 
> > I'd really like to see that bit of the yajl api modified to avoid
> > the use of va_args -- it will make writing bindings to yajl from
> > other languages easier.
> 
> Feel free to file a bug with a proposed alternative api.  I'm not
> interested in making the change in the short term for reasons of
> binary compatibility (we just broke that with yajl 2, a mere three
> months ago (http://lloyd.io/whats-new-in-yajl-two).


I have a question for the OP, can Fortran properly map unions and pointers in
and out of C?

Having done a couple Ada-to-C bindings recently, this approach seems to work
rather well as far as interfacing with variable argument options


I could get behind a call like:
    yajl_config_u(yajl_handle h, yajl_option opt, struct some_union);


Just thinking aloud :)

- R. Tyler Croy
--------------------------------------
    Code: http://github.com/rtyler
 Chatter: http://identi.ca/agentdero
          http://twitter.com/agentdero

Re: [yajl] Fortran bindings and an api suggestion

From:
Lloyd Hilaiel
Date:
2011-07-12 @ 19:12
Oh gosh, thank hatem, and pardon me. 

--lloyd


On Jul 12, 2011, at 12:23 PM, Hatem Nassrat <hnassrat@gmail.com> wrote:

> Am i the only one who received a blob :), here is an attempt to resend 
lloyd's email
>  
> On Jul 12, 2011, at 10:36 AM, R. Tyler Croy wrote:
> 
>> 
>> On Tue, 12 Jul 2011, Neil N. Carlson wrote:
>> 
> 
>>> I've written Fortran 2003 bindings to a portion of yajl
>>> (yajl_parse.h) and was pleasantly surprised that interfacing
>>> OO Fortran to the C interface with its callbacks was easy
>>> after some careful thought, and works quite well.
>>> 
>> I do have one quibble about the C interface, specifically
>>> yajl_config.  This function uses varargs, and as such is
>>> not considered "interoperable" with Fortran.  I've lied
>>> (to the Fortran compiler) and treated it as a function that
>>> takes a single option argument.  That appears to work for
> 
>>> the one compiler I'm using, but I'm not at all confident
>>> that this will be portable; there's no reason to expect
>>> that it will be.
>>> 
>>> I'm not sure how other languages handle binding to this
>>> function -- maybe it's not an issue -- but I'd suggest
>>> changing the interface to accept a single option argument
>>> instead of a variable number.  Further, I find the
>>> semantics of the function to be somewhat odd: it can only
>>> be called with "pure" option values and it internally
>>> or's them with an inte rnal options value; options can
>>> be set but never unset.  It would be much more flexible
>>> to allow/require the user to define the (full) options
>>> value by or'ing (or whatever) the pure option enum values
> 
>>> and passing that to yajl_config who would just use it as is.
>>> This would be a lot more consistent with conventional
>>> practice (at least as I have observed it).
>> 
>> 
> 
>> Are there any configuration options that actually make use of the va_args
>> nature of yajl_config?
> 
> For the generator, yes.  see yajl_gen.c line 81, the handling of 
> yajl_gen_print_callback.
> 
> it's true that the config api is generalized for an exception, alas.
> 
> lloyd
> 
> -- 
> Hatem Nassrat