On Thu, 25 Mar 2004, Norman Gray wrote:
> 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.
>
It's completely generic though. Anyway, the _ext "hack" is in and is now
used by CHR, GWM and IDI. Works like a charm.
> 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?
>
Yes.
> 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.
That's what I'm going to do.
>
> 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).
>
That's my plan for the weekend.
> 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.
Presumably, in some cases like IDI, because they did not want a dependency
on SAE (SAI__ERROR) - although since SAE is documented to duplicate the
ADAM error codes (rather than everything using a single SAE include file)
this is all a bit strange.
>
> Having _msg_before and _msg_after seems the first step to a very
> baroque MESSGEN.
Fine. I won't do that (but the _ext tweak does help things IMHO).
>
> As for prologues, I'm one for the blunt: `This file was generated by
> MESSGEN from file X. DO NOT EDIT'.
>
Yes. I can add that to the messgen output in general. I'll see if I can
muster the energy to also add where the _ext came from.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|