Please install parseErrorCodes.pl

[rhl@…]

User code is expected to use parseErrorCodes.pl to generate its own sets of error codes. For
this to work, pslib should install parseErrorCodes.pl in $prefix/bin as part of its install
procedure.

[robert.desonia@…]

Is that stated as a requirement somewhere?

I didn't think parseErrorCodes was ever meant for user use. It supplies a means
to register static error codes at psLib compile-time, not at runtime, which is
when the user would register error codes via psErrorRegister calls.

The only thing it does is allow the static error codes to be held in a separate,
maybe friendlier, table file; it probably could just removed altogether from the
project and that information could be located just in psErrorCodes.h.

-rdd

[rhl@…]

I looked to see if it appeared in the SDRS, and it doesn't. Maybe we need to
file that problem first?

However, if you read the original document (no, it has no legal significance)
you'll see that we specified psErrorRegister(), which basically takes the
table processed through parseErrorCodes.pl and makes them available.

Note that this table is processed Twice; once to make a .h and once to make
a .c file so we do need this functionality.

[robert.desonia@…]

I don't think I understand your point, I guess. I see no reason why one would
need to use my petty little helper build script to utilize psErrorRegister().

If I remember right, I created this silly script thinking that error codes would
be added as things evolved and it would be better to keep the information in a
centralised and separate file. I wanted a script like that for another reason
anyway, namely to push the error texts into a separate file for future
localization options, etc. Though that is not a requirement, it was something
I've dealt with before and I thought I'd be nice to start doing it from the
start. The idea is that a simple makefile addition could substitute error
messages of different dialects, but I degress.

The user could just create the list of error codes simply as a static variable
in their code, for instance, i.e.,

static numErrorCodes = 2;
static psErrorDescription errorCodes = {

{1000,"fooed the bar"},
{1001,"it go boom boom"}

};

...

void initSystem() {

...
psErrorRegister(errorCodes, numErrorCodes);
...

}

That method does not require the build script in question at all.

-rdd

[rhl@…]

The reason for a build script (which I thought went back to my initial
toy implementation of psError) is that that it allows the user to
use enums for their error codes.

A user can say:

psError(POIS_ERR_FITS, true, "Cannot write header record\n");

and have the error stack report:

"Problem in FITS I/O"

from an input file such as:

BASE = 512 First value we use; lower values belong to psLib
UNKNOWN Unknown POIS error code
NOT_IMPLEMENTED Desired feature is not yet implemented
FITS Problem in FITS I/O
FITS_WCS Error interpreting FITS WCS information
SWIG Problem in SWIG bindings
UNSUPPORTED_TYPE The datatype is not supported for this operation

[robert.desonia@…]

Well, I guess it doesn't matter too much if I add it to the list of installed
items. I should chenge the name to something like psParseErrorCodes.pl.

I'll get to this by the next release.

[robert.desonia@…]

OK, made it installable. I renamed the script to psParseErrorCodes.

-rdd