Tim,
On Wed, 24 Mar 2004, Tim Jenness wrote:
> messgen will now append the _ext data rather than
> prepending it. I'm half inclined to have _msg_befor and _msg_after
> files rather than a single _ext file. That would allow for a nice
> starlink-style prolog to be included as well as the option of something
> else at the end. It's a minor tweak to messgen to support that but does
> anyone have any comments on the idea?
I'm nervous about adding stuff to messgen to support applications
which handle error codes in wierd -- probably plain wrong -- ways.
Later:
> What's the deal with PGP_ERR (in GRAPHPAR)? The codes are simply not valid
> messgen codes at all. As they stand cremsg complains about an illegal
> [...]
>
> Any objections if in the CVS version I "fix" the error codes and make sure
> the fac file gets installed? Or can someone explain why the codes are
> broken? Looking at GRERR things get confusing since 176 to 192 are used by
> GRERR but 172 to 196 are reserved for pgppar.
I'm not sure I'm fully understanding the error code problem. Is it just
that some libraries have had error codes added by hand, by someone who
simply got them wrong, in the sense that the codes are illegal according
to the EMS system?
Could we not just then junk them, and create a new .msg file with the
same error names and facility code? That _should_ be invisible to the
application, since that's the whole point of the error codes and the
include files. If this breaks the library, because it's using magic
values rather than the error code names, then the library is simply
broken and we just didn't know it, but it would bite us or someone else
sooner or later.
The same goes for the IDI__OK: it looks as if whoever added that error
code just thought that 0 was a good-looking success status, but was
otherwise well-behaved. If you grep through the Fortran it does appear
that the status is explicitly tested against IDI__OK each time, rather
than the magic value 0.
If IDI is using codes without the IDI__ prefix, wouldn't that be
fixable with a bit of sedding (OK, Tim, a line of Perl).
Thus fixing the applications to use correct MESSGEN output seems a better
strategy in the long run than adding features to messgen to accomodate
badly behaved applications. I can see why CHR needs to have some extra
codes added (presumably CHR__WRDNOTFND and CHR__WNOTF are both documented
so we need the duplicate; though why do we need a magic CHR__ERROR?),
but this seems a very special case.
Having _msg_before and _msg_after seems the first step to a very
baroque MESSGEN.
As for prologues, I'm one for the blunt: `This file was generated by
MESSGEN from file X. DO NOT EDIT'.
See you,
Norman
--
---------------------------------------------------------------------------
Norman Gray http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK [log in to unmask]
|