Re: [gentoo-dev] The fallacies of GLEP55

[Patrick Lauer]

On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote:
> On Thu, 14 May 2009 20:06:51 +0200
>
> Patrick Lauer <patrick@g.o> wrote:
> > "You need to know the EAPI to parse the ebuild to find the EAPI"
> > Obviously that's not true, because somehow we manage at the moment.
> > And if one does a small restriction (which doesn't restrict current
> > behaviour because all in-tree ebuilds currently fit within this
> > limitation) it becomes trivial again:
> >
> > Let EAPI be defined as (the part behind the = of) the first line of
> > the ebuild starting with EAPI=
>
> Uh, so horribly utterly and obviously wrong.
>
>     inherit foo
>     EAPI=4
>
> where foo is both a global and a non-global eclass that sets metadata.
Interesting, but quite subtly wrong. I'm surprised that you try to slip such 
an obvious logical mistake in in an attempt to save your arguments.

> If you're looking for a formally correct alternative that works in the
> way you suggest, I already provided one, and you already read about it
> -- and it still doesn't solve the problems that 55 does.
And glep55 doesn't solve the problem either. It's neither formal nor correct, 
plus in this case ... what on earth are you trying to communicate?

> > "It's slower!"
> > The theory here being that a stat() is needed if it is encoded in the
> > filename, but a stat() followed by an open() to parse it from the
> > file. Well then, just cache it! You can use the mtime to check the
> > cache validity (which means you do a stat() anyway, so with glep55
> > caching it is actually slower!), and then you have to parse the
> > ebuild anyway for the other metadata. So the "extra" cost of finding
> > the EAPI is ... what extra cost? The only case when it is actually
> > slower is when there is no cache because then you have to parse the
> > ebuild. But that "degenerate" case will only hit some overlay users
> > and people like developers that can wait .3 seconds longer. And ...
> > uhm ... to extract other metadata like DEPENDS you'll have to parse
> > it anyway.
> Where on earth are you getting the idea that GLEP 55 makes things
> slower? The only difference to the code with GLEP 55 is in checking
> file extensions against a slightly larger set of strings, which is
> nowhere near a measurable increase in anything. You're claiming that
> checking for a suffix of either ".ebuild-4" or ".ebuild" against a
> fixed string is in any way relevant, which is obviously trolling.
That is quite definitely not my point. I mean, hombre, did you even READ my 
email, or do you just apply prewritten text blocks in the hope of solving 
issues like most "technical" "support" does? 

> There is no existing version ordering solution that accurately
> represents upstream scm branches.
Ah. Thanks. At last you say in clear words that GLEP54 doesn't actually solve 
the problem either. So we can safely keep it buried ...

> > A few words in closing -
> >
> > We can encode all the relevant info in "the first line of the ebuild
> > starting with EAPI="
>
> No we can't. That's *obviously* completely wrong.
>
It's obviously quite specifically not. Can you show any case where that fails 
or where adding this restriction removes relevant functionality?

> > The overhead of parsing out this value for all ebuilds in the tree
> > has been timed at ~2 CPU-seconds by solar. It's negligible.
>
> Those of us who have been measuring this have been discarding CPU time
> entirely, since it's utterly irrelevant. That you bring CPU time into
> this shows you've been deliberately ignoring everything we've said.
Eh, I already smashed the disk seek time argument somewhere up there. It 
amortizes quite nicely. And you are ignoring everything I say just to make a 
point that is not even wrong anymore. 

> We all know you're not stupid enough to believe what you've been
> posting or ignorant enough to miss the point so badly. So please stop
> pretending -- this issue would have gone through a long time ago were
> it not for you and your ilk deliberately pretending to be retarded so
> you can raise straw man arguments against it rather than addressing the
> issues at hand. You're doing both yourself and everyone else a huge
> disfavour by acting dumb and assuming everyone else is going to play
> along with that.
Hey. Wow. I'll keep that to post it whenever you try to insult, confuse or 
obfuscate issues to get your ideas pushed in. It describes you so wonderfully 
precise how only your own words can do.

Now, thanks for the logical fallacies (I think you've missed at least one, but 
I haven't been looking carefully) and the attempt at a personal attack. It's 
quite great, but this mailing list is definitely not the place for it. 

Now can we please get back to _debating_ things instead of wargharbling?

Thanks,

el meow