Re: Feedback from GSL folks on libflame 4.0

[Gerard Jungman <jungman@lanl.gov>]

On Thu, 2010-02-18 at 13:50 -0600, Rhys Ulerich wrote:

> I'm willing to take a stab at providing the necessary error handling
> underneath flame to make it play nice with GSL's error handling model.
> The obvious choice is to adopt GSL's routines.  However, flame is
> LGPL and so adopting GSL's GPLed error handling directly is not an
> option.
> 
> Do you know of an LGPL project that you believe does a good job in this regard?

I don't know of another project, but I haven't looked very hard
(and certainly not in a long time). Anyway, I think that copying
the GSL stuff (if you really want to) only requires asking us.
Brian probably has the copyright for the error-handling stuff
and can just re-license and gift that part of the code (unless
he has some objection or I am missing something).

In my follow-on comments to Field, I suggested the two-prototype model
used by (at least parts of) GSL, where each function has both a
"natural" abort-on-trouble version and a "return-code" version.
The "natural" version defers to the "return-code" version in
the obvious way. I am happy enough with this part of GSL, anyway.
Anything more complicated should probably be discussed critically.
I don't think I'm totally happy with every aspect of GSL error-handling,
mainly because I don't think it was implemented consistently across
the whole library.

The work required is obviously very easy, just a
bit tedious. Eventually the "natural" versions could be
automatically generated, if that seems worth doing. A
catalog of return codes and associated static error
messages is needed. That might require eye-balling
the libflame source, possibly doing some classification
work, depending on how organized they were about their
error conditions.


If you can think of something better, that would be great too.
Any ideas for improvement are welcome.

--
G. Jungman