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

[James Blackwell]

Tom wrote:
> James' suggestion was something like named boolean flags, set I
> presume in a static array in some C file --- is that about right?

Close, but ints. However, the more I think about it, the more I agree
that they do look an awfully like bools.

For example, if we added "spaces-support" to the list, later we could go
back and say "We still have spaces support, but now it does more". We
could bump spaces-support up to 2, 7, 69, or whatever our hearts
desired.

> Such a table is easy to code up an understand, but also easy to make a
> mistake with while maintaining it (a task akin to double checking
> somebody's arithmetic at adding up a long column of numbers).

Making a mistake is certainly a likely possibility. As a example, lets 
say that there's a change in pike escaping that happens to affect
several listed "features" enough that six of them should be bumped, but
only five of them actually received that bump.

In that case, if somebody like ddaa complains, we just say "ok" and bump
the version number. 

> When I balance my checkbook, I do the math by hand and double check
> with a calculator: I'm not sure we can expect people to be so careful
> with a centralized "features" table and I'm not sure what the
> "features" equivalent of a calculator (for double checking) would be.

Yeah. I wasn't planning on performing anysort of "maintainership" role
for features (see below).

> Next: I like to be frugal with new design add-ons.   If it's *really*
> necessary to add something new, hopefully it should solve lots of (or
> a very general) existing problems.   "Features" seems a bit isolated
> to me, in this context.   

Maybe this (features) ain't it, but we do need something. When it comes
to predicting the needs of future frontends, I look to ddaa (pyarch) as
our little canary in a cage. At conference, he was definitely showing
signs that we need to make it easier for him to distinguish versions. 


> For example: revision libraries have parameter settings (e.g., the
> greedy and sparse flags).   Should "features" variables *really* be a
> fundamentally different thing?  or is there usefully some more general
> concept that would make "features" and revision library params the
> same thing?

I think I see what you're getting at. A thirty second think tells me
that they really are different animals. 

The library flags, .arch-params, et. al. all involve tracking state of
some sort. 

The features idea isn't about tracking state; rather, its about tracking
the definition of what arch is at the particular moment it was built.

> And of course -- the old questions -- are features really just
> booleans?   who controls the namespace of them and how?

As previously mentioned, I envisioned them as ints that represent
versions, but yeah, I think a lot of them would essentially be bools.

I wasn't planning on putting in any sort of review process. I'd
basically take patches for any that looked reasonably sensible (Ohh, Tom
wants to know whether or not this version catches truncated ids)


Seeing as how 1) We don't have to solve this "today" (though we do need
to solve it in the medium term) and 2) That this solution isn't a
flawless one, why don't we put this off for a bit and see if any better
solutions come up. 



>     > From: Jason McCarty <address@hidden>
>
>     > James Blackwell wrote:
>     > > Tom Lord wrote:
>
>
>     > > > [....]Asking for `features' in `tla' suggests that we suddenly 
> expect *lots*
>     > > > of users to all be running slightly different versions of arch, some
>     > > > with such and such feature, some without ---- *AND* ----- we expect
>     > > > that situation to get *so* out of hand that many external tools have
>     > > > to deal [with] all the possible combinations of features.
>     > > 
>     > > What? You don't think that's happening? How many are running 1.1.5?
>     > > 1.2.0? 1.2.1? What about when 1.2.2 comes out?
>     > > [...]
>     > > Sure, we can offload the work to the frontends to track it, but that
>     > > means writing code anyways. The current --version is completely broken
>     > > for this task. With buildcfg -r, you get one version string. With
>     > > buildcfg -r, you get a different string (not a version string at all).
>     > > If you use a tla that comes with a distribution, then it's been 
> screwed
>     > > with in godawful ways.
>     > 
>     > I have to agree with James; the syntax of about 20 commands changed
>     > between 1.1 and 1.2, and testing --version isn't completely reliable. I
>     > resort to letting the user specify the version, or assume 1.3 when I
>     > can't tell.
>     > 
>     > -- 
>     > Jason McCarty <address@hidden>
>     > 
>     > 
>     > _______________________________________________
>     > Gnu-arch-users mailing list
>     > address@hidden
>     > http://lists.gnu.org/mailman/listinfo/gnu-arch-users
>     > 
>     > GNU arch home page:
>     > http://savannah.gnu.org/projects/gnu-arch/
>     > 
>     > 
>
>
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnu-arch-users
>
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
>


-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400