Re: [Gnu-arch-users] Features command for arch

[David Allouche]

On Sat, 2004-08-28 at 16:22 -0400, James Blackwell wrote:
> I brought this one up because David (ddaa of pyarch) is having difficulty
> predicting tla behavior.  Sometimes, tla acts differently before a bug
> is fixed than after. Also, he'd like to know trivially things like
> whether or not tla uses pika escaping, etc. 

I have already been thinking that "tla features" would be a good thing
to have for a long time, and discussed it on #arch. The specific problem
that triggered the discussion with jblack was the support of archive-
meta-info.

      * Up to  recently, archive-meta-info produced no output and exited
        with status 0 either if the requested meta-info file was missing
        or if it was empty.
      * This made it impossible to know whether an archive was signed or
        set to use listings because even though make-archive never
        create meta-info files with empty content, tla behaviour only
        depends on the _existence_ of the file, and there are many
        archives in the wild with empty http-blows and signed-archive
        files.
      * tla was modified so archive-meta-info exit(1) if the file is
        missing, exit(0) if it is present and empty, and print nothing
        in both cases.
      * At this point, "archive-meta-info signed-archive" printing
        nothing and exiting with status 0 can mean either "the archive
        is signed" (new tla) or "the archive is not signed" (old tla).

So PyArch needs to know whether the archive-meta-info fix is present.
Currently that is done in a very ugly way: a flag is set in the source
code and the test suite checks it for consistence with the observed
behaviour of tla.

> Tom Lord wrote:
> > How would user's benefit from such a feature? 
> 
> Users will benefit because the work on arch front/mid-ends will be
> easier
> 
> 
> >                                                How would it make arch
> > better?  
> 
> Directly, not at all. Indirectly, yes, by easing the work the frontend
> guys are doing it
> 
> >          Why is it important to work on now?  
> 
> There's more important things to work on, but it is low hanging fruit.
> 
> 
> >                                              What is the definition
> > of "a feature"? 
> 
> Any sort of behavioral change to tla that needs to be account for in
> front ends.

Yep.

> >               How do implementors know whether or not they should
> > say that such-and-such a feature is present?  
> 
> If there's any doubt, throw it in.
> 
> I suspect that I don't understand your question.
> 
> >                                                     Who shall be the
> > arbitrator of "feature names"? 
> 
> I don't think there will be much need for an arbitrator, but I suppose
> that if a controversial name comes up, it can be discussed.

Yep. The feature name-space will probably end up quite crowded (in a few
years) but I do not think that is going to be a real problem. And even
if we find out that we need something more elaborate, we can just make
it a new feature: for example "tla features --new" that we can look for
using "tla features new-style-features".

I do not see why a special arbitration authority would be needed. It's
not like the feature name-space has any value (it's only intended for
use by scripts) so there should not be any dispute... And if there is
ever the need for a dispute resolution, that's a job for the maintainers
to just send the idiots to piss off.

> >                                  How does this relate to the idea of
> > standardizing arch with formal standards docs?
> 
> The syntax I threw up for the sake of argument. If you like, we can have
> an extended conversation about the proper syntax to use.

I may have missed a recent thread where that plan was discussed. Off the
top of my head, these are orthogonal. You _can_ have features named
after design documents, but this is addressing a mostly different issue
of pragmatic interoperability.

Or are we already talking past each other?

-- 
                                                            -- ddaa