This is the mail archive of the
gsl-discuss@sourceware.org
mailing list for the GSL project.
Re: Feedback from GSL folks on libflame 4.0
- From: Rhys Ulerich <rhys dot ulerich at gmail dot com>
- To: jungman at lanl dot gov
- Cc: gsl-discuss mailing list <gsl-discuss at sourceware dot org>, "Field G. Van Zee" <field at cs dot utexas dot edu>
- Date: Thu, 18 Feb 2010 13:50:44 -0600
- Subject: Re: Feedback from GSL folks on libflame 4.0
- References: <4a00655d1002171047t4e87fb85w88b609245e3f9a8e@mail.gmail.com> <4B7D90B5.4020707@cs.utexas.edu>
Hi Gerard,
>> (4) According to the manual, libflame calls abort() when it encounters
>> ? ?a problem. As I have discussed before, this is brain-damaged. It
>> ? ?makes it hard for other library developers (us) to integrate
>> ? ?their thing into an existing error-handling system.
>
> Bottom line: we are anything but married to the idea of aborting when an error
> is encountered, but we are unsure how to come up with a solution that is less
> brain-damaged and portable and that fits our users' coding style.
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?
- Rhys