-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The error macros are problematic #6
Comments
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? |
My primary requirement is C99 compatibility. Ideally I'd like to avoid any calls to In |
@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 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 |
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 On Wed, Oct 12, 2016 at 1:46 AM, Rich FitzJohn [email protected]
|
Hi, I'm working on this over the next week. Any suggestions for an API to handle errors? |
doodling some ideas:
|
|
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]
The text was updated successfully, but these errors were encountered: