Open richfitz opened 8 years ago
Dear @richfitz
Those macros were introduced by @rainwoodman; we could always revert these back to the original code, or just redefine them. Happy to drop GNU extensions etc. What would suit rlsoda etc.? Would you prefer a set of error codes defined by macros?
It's been a few years. But I do recall the reason I added these ugly trinary operators was very likely because I wanted the initial reentrable version to be as close as the old code as possible.
I think it may as well be the right time to modernize the API -- spliting the error interface from the LSODA context, and probably rename the context class to LSODASolver. also, adding a LSODAError \ argument to each function call that raises an exception.
Dear @rainwoodman
Thanks for the feedback. What would you suggest for the fields of a lsoda_error_t (I don't mind keeping the naming very old-c like)? Would it be worth using something like exceptions4c?
What would suit rlsoda etc.? Would you prefer a set of error codes defined by macros?
My primary requirement is C99 compatibility. Ideally I'd like to avoid any calls to sprintf
too as these will need to be patched (CRAN is super strict about these things, which is annoying for developers but does help with the platform independence).
In dde
I use an enum of error codes (which would be an improvement of the magic numbers that trace back to the original Fortran -- similar also for itask
which is pretty obscure atm).
@sdwfrost I think that would be an overkill. I feel a split between the request and result would be good enough -- the exception can be returned in the result object -- something along these lines:
I haven't been actively using this package for many years, so it is really up to the boots on the ground to decide.
@richfitz Could you point to me some reference guide for coding style of CRAN? Is there an alternative to sprintf that is recommended? (printf would be even worse since it writes to stdout) We shall try to wrap these into the new implementation (assuming it will happen).
Sorry - I mistyped; it's the use of printf
and fprintf
that is an issue (or anything that writes to stderr
/stdout
). The abort
is also an issue but that's easily avoided.
The reference guide is "writing R extensions" which is long and rambling and at the same time not necessarily comprehensive, along with the CRAN repository policy. Practically it's just a case of running the code through R's QA tools and seeing where the grumbles are (there's a lot of culture clash within the old and new parts of the R community).
I agree with @rainwoodman that the exceptions4c looks like overkill. Also while I'm not a lawyer that could induce licence issues? (It's LGPL which I understand even less than GPL).
So, should there be a separate error struct (which could contain arbitrary amounts of detail about the error) or should just a pointer to an int
be passed in which to write an error code (removing the char* error
in the context)?
Given the varied nature of the messages, then a full struct seems the more natural choice
Yes I agree with Rich. if we can do vsprintf then it is always a good idea to give more context. shall one of us propose a draft new API (just the header file) based on the current functionality, so that we have something to work on? The minimal requirement is R conformal and no loss of functionality so far we have discussed.
On Wed, Oct 12, 2016 at 1:46 AM, Rich FitzJohn notifications@github.com wrote:
Given the varied nature of the messages, then a full struct seems the more natural choice
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sdwfrost/liblsoda/issues/6#issuecomment-253155022, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIbTATngepYkdiRTz7LNnQbL4z40O2pks5qzJ54gaJpZM4KSwSU .
Hi, I'm working on this over the next week. Any suggestions for an API to handle errors?
doodling some ideas:
LSODASolver solver[1] = {{
.function = function,
.itask = 1, /* replace with better names + enum */
.opt = 1,
....
},};
LSODAError error[1];
if(0 != lsoda_solver_init(solver, error)) {
goto exc_init;
}
double tout = 1, t=0;
for(int i = 0; i < 10; i ++) {
tout = tout * 10;
if(0 != lsoda_solver_run(solver, &t, tout, error)) {
goto exc_run;
}
}
lsoda_solver_destroy(solver);
return 0;
exc_run:
printf("%s\n", error->message);
lsoda_error_destroy(error);
lsoda_solver_destroy(solver);
return 1;
exc_init:
printf("%s\n", error->message);
return 1;
goto
here serves as a 'try-catch' block.
I get a number of compiler warnings from the
softfailure
,hardfailure
andERROR
macros (and function macros are pretty gross in general IMO).There are a few approaches to fixing these, but all will involve some moderate refactoring of the code. You may have thoughts on how best to do this, or be looking at other bits of refactoring that would overlap.
With clang (Apple LLVM version 7.0.0 (clang-700.0.72)) and with
-Wall -Wextra -pedantic -Wno-unused-parameter
I see(and so on)
With gcc (same flags)
[snip]