The fallacies of GLEP55

classic Classic list List threaded Threaded
113 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

The fallacies of GLEP55

Patrick Lauer
For quite some time (over a year, actually) we've been discussing the
mysterious and often misunderstood GLEP55.
[http://www.gentoo.org/proj/en/glep/glep-0055.html]

The proposed solution to a problem that is never refined, in short, is to add
the EAPI into the ebuild filename "to make things easier". Which is a rather
unsubstantiated idea that doesn't really add up if you look at it ... and it
adds some artifacts that we've been laughing about for a decade because
microsoft did the exact same thing (binding the executable-ness of a file to
the filename).

Here's just some of the theories in support of GLEP55 that have been thrown at
me, and a few words to show how they are not really issues:

"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=

As long as ebuilds remain shell-like this is not much of a restriction, and
any format that diverges enough to make this inconvenient shouldn't be called
an ebuild anyway. Finding the EAPI is then quite unsurprisingly trivial.

"You need to parse the ebuild and its eclasses to find the EAPI!"
See above, and eclasses shouldn't change EAPI anyway. It leads to lots of
strange effects and is implicitly impossible with GLEP55 anyway, so it might
be easier to just declare it invalid.

"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.

"But we need to be able to change things in the future!"
Well then. Once we have identified such an issue we can do the changes. Until
then it's not even clear if there are such changes, so why should we break
current known and predictable behaviour to satisfy a need we don't even have?
Make a structured proposal defining a concrete problem in unambiguous terms,
list all the ways to solve this issue, including advantages and disadvantages,
and we can get it voted on and ratified within a month.

"We want to change the versioning rules!"
Why do you want that, and what do we gain from it?

"Having GLEP55 allows us to add GLEP54 without issues!"
Yeah, uhm, the live-ness of an ebuild is an attribute. How about we add it to
metadata, as we should for all metadata? Define a key, I don't know ... LIVE ?
LIVE="true". There. No need to fix the filename. And now stop mixing up issues
because it is highly confusing!

"Obviously you don't understand the issue, because if you did you'd support
it!"
Uhm, obviously you have no idea what you are saying. But  just to play along
... if it were that obvious we wouldn't have had to discuss it for so long.
Maybe understanding the issue forces one to support the current behaviour!


A few words in closing -

We can encode all the relevant info in "the first line of the ebuild starting
with EAPI="
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.
The changes are none at the moment, all that changes is the specification. And
if we ever have the need to change things around we can still look at the
expected costs and benefits and decide to implement something almost, but not
completely unlike GLEP55. And maybe we can now spend the same amount of
council-time (it has been eating time for over a year!) to get important
things done ...

hth,

Patrick the bonsaikitten


P.S. http://dev.gentooexperimental.org/~dreeevil/whargarbl.jpg

Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

Ciaran McCreesh-4
On Thu, 14 May 2009 20:06:51 +0200
Patrick Lauer <[hidden email]> 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.

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.

> "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.

> "Having GLEP55 allows us to add GLEP54 without issues!"
> Yeah, uhm, the live-ness of an ebuild is an attribute. How about we
> add it to metadata, as we should for all metadata? Define a key, I
> don't know ... LIVE ? LIVE="true". There. No need to fix the
> filename. And now stop mixing up issues because it is highly
> confusing!

There is no existing version ordering solution that accurately
represents upstream scm branches.

> 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.

> 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.

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.

--
Ciaran McCreesh

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

David Leverton-2
In reply to this post by Patrick Lauer
On Thursday 14 May 2009 19:06:51 Patrick Lauer wrote:
> For quite some time (over a year, actually) we've been discussing the
> mysterious and often misunderstood GLEP55.
> [http://www.gentoo.org/proj/en/glep/glep-0055.html]

We agree on the latter adjective, if nothing else.

> The proposed solution to a problem that is never refined, in short, is to
> add the EAPI into the ebuild filename "to make things easier". Which is a
> rather unsubstantiated idea that doesn't really add up if you look at it
> ... and it adds some artifacts that we've been laughing about for a decade
> because microsoft did the exact same thing (binding the executable-ness of
> a file to the filename).

I wonder where people get this strange delusion that only Windows uses file
extensions for anything?

> Here's just some of the theories in support of GLEP55 that have been thrown
> at me, and a few words to show how they are not really issues:
>
> "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.

Because we haven't yet introduced any changes that would break it.

> 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=
>
> As long as ebuilds remain shell-like this is not much of a restriction,

It's an arbitrary, magical restriction that doesn't follow from the general
rules of the language that ebuilds are written in - you said it
yourself, "shell-like".   "printf -v EAPI 1" is perfectly valid shell (at
least if we decide to allow bash 3.1 features), and has the same effect
as "EAPI=1" under the rules of the shell, but it's not compatible with your
new rule.

> "You need to parse the ebuild and its eclasses to find the EAPI!"
> See above, and eclasses shouldn't change EAPI anyway. It leads to lots of
> strange effects and is implicitly impossible with GLEP55 anyway, so it
> might be easier to just declare it invalid.

With GLEP 55 it's naturally invalid, and can't possibly be assumed to be
valid.  If you keep the assignment-like syntax but disallow it in eclasses,
it's an extra weird restriction.

> "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.

And people say Gentoo users are ricers... the whole speed argument is a
strawman, relevant only to the extent that we don't want to make things
noticeably slower than they are already.  You claim that GLEP 55 does that,
but this claim seems to be based on the assumption that without it there
would be no need to parse the filename in any way, which clearly isn't true.

> "But we need to be able to change things in the future!"
> Well then. Once we have identified such an issue we can do the changes.
> Until then it's not even clear if there are such changes, so why should we
> break current known and predictable behaviour to satisfy a need we don't
> even have? Make a structured proposal defining a concrete problem in
> unambiguous terms, list all the ways to solve this issue, including
> advantages and disadvantages, and we can get it voted on and ratified
> within a month.

The same thing happened when EAPI itself was introduced.  EAPI support was
committed to Portage in late September 2005, but the first new EAPI in
mainstream Gentoo was introduced in early October 2007, just over two years
later.  That's clearly not an argument for rejecting a compatibility
mechanism.

It's also not necessary to start putting EAPI in the filename as soon as it's
approved.  The Council could easily state that "once we need to make a change
that requires a stronger mechanism than EAPI is currently, we'll do it like
this" - no need to reject it, or keep "maybe"ing it for eternity.

Of course, there's at least one GLEP 55-scope change that people want already,
to the extent that they're making up hacks to work around the lack of it,
namely per-package eclasses.  I would hope that everyone agrees that a
package manager-supported mechanism would be far preferably (I know that
vapier does).

> "We want to change the versioning rules!"
> Why do you want that, and what do we gain from it?

Aside from -scm (below), there are various changes suggested at
http://lists.exherbo.org/pipermail/exherbo-dev/2009-February/000400.html that
would help match various upstream version formats more closely, and reduce
the amount of versionator hacking.  Even if you don't like any of those
examples, the version format has changed in the past, and it would be quite
foolish to design around the assumption that it will never happen again.

> "Having GLEP55 allows us to add GLEP54 without issues!"
> Yeah, uhm, the live-ness of an ebuild is an attribute.

No more so than the "1.2ness".  "This ebuild installs the latest sources from
the repository" is the same class of information as "this ebuild installs
version 1.2", and therefore belongs in the same place.

> How about we add it
> to metadata, as we should for all metadata? Define a key, I don't know ...
> LIVE ? LIVE="true". There. No need to fix the filename. And now stop mixing
> up issues because it is highly confusing!

That still doesn't solve the version ordering issues, as has already been said
countless times.

> "Obviously you don't understand the issue, because if you did you'd support
> it!"
> Uhm, obviously you have no idea what you are saying. But  just to play
> along ... if it were that obvious we wouldn't have had to discuss it for so
> long.

You'd think so, but it never seems to work out that way.

> Maybe understanding the issue forces one to support the current
> behaviour!

Unlikely.

Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

Bugzilla from scarabeus@gentoo.org
In reply to this post by Ciaran McCreesh-4
Dne čtvrtek 14 Květen 2009 20:39:07 Ciaran McCreesh napsal(a):
> 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.
Read the block once more, he is not stating that adding suffix to the filename
is slower.

>
> > "Having GLEP55 allows us to add GLEP54 without issues!"
> > Yeah, uhm, the live-ness of an ebuild is an attribute. How about we
> > add it to metadata, as we should for all metadata? Define a key, I
> > don't know ... LIVE ? LIVE="true". There. No need to fix the
> > filename. And now stop mixing up issues because it is highly
> > confusing!
>
> There is no existing version ordering solution that accurately
> represents upstream scm branches.
>
> > 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.
We actualy can, you consider it wrong, so we all should do so
>
> > 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.
Well cpu is not real benchmark, but if it took 2 secs it means the tweaking is
not worth efforts.
>
> 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.
And this is really just personal offense which you should take out from your
mails if you want somebody to take your experience acordingly to your
knowledge and not just judge you as 10 year old whining kid.

Tomas

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

Ciaran McCreesh-4
In reply to this post by Patrick Lauer
On Thu, 14 May 2009 21:05:52 +0200
Patrick Lauer <[hidden email]> wrote:
> > 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?

Please explain why you claimed GLEP 55 makes things slower. Until you
answer that, it's hard to take you for anything other than a troll.

--
Ciaran McCreesh

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

Jeremy Olexa-3
In reply to this post by David Leverton-2
On Thu, May 14, 2009 at 2:06 PM, David Leverton
<[hidden email]> wrote:
> yourself, "shell-like".   "printf -v EAPI 1" is perfectly valid shell (at
> least if we decide to allow bash 3.1 features), and has the same effect

To stir things up:
Who decides this? There are more and more bash-3.1 features in the
tree and I brought it up to the Council months ago becase the PMS says
that only bash-3.0 is allowed but no one cares.

-Jeremy

Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

Robert Bridge
In reply to this post by Patrick Lauer
Patrick Lauer wrote:

> On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote:
>> On Thu, 14 May 2009 20:06:51 +0200
>>
>> Patrick Lauer <[hidden email]> wrote:
>>> 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.

Patrick, in the interest of making this comprehensible to the average
schmuck like me, which you seem to be trying to do, could you actually
explain WHY this is wrong? Otherwise it looks like you are simply trying
the arrogant "I am right because I say so" line.

>> 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?

Again, see my previous comment.

>>> 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?

Both of you need to explain your opinions here.


Just my thoughts,
R.

Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

RB-14
In reply to this post by Ciaran McCreesh-4
On Thu, May 14, 2009 at 13:11, Ciaran McCreesh
<[hidden email]> wrote:
> Please explain why you claimed GLEP 55 makes things slower. Until you
> answer that, it's hard to take you for anything other than a troll.

Hell, I'll explain.  Read paragraph 8 again.  Slowly.  Read it a
second time, since you obviously didn't read the first time.  The
paragraph makes the point that the pro-GLEP55 stance says that
encoding EAPI inside the file is slower.  It is not saying GLEP55 is
slower, it is attempting to debunk the theory that it is faster.

You may be a lightning-fast typer and emailer, but until your
comprehension catches up, you might want to consider reading things
that make you angry twice.

Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

Ciaran McCreesh-4
In reply to this post by Bugzilla from scarabeus@gentoo.org
On Thu, 14 May 2009 21:09:58 +0200
Tomáš Chvátal <[hidden email]> wrote:
> Dne čtvrtek 14 Květen 2009 20:39:07 Ciaran McCreesh napsal(a):
> > 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.
> Read the block once more, he is not stating that adding suffix to the
> filename is slower.

He is stating that GLEP 55 makes things slower. I quote:

"so with glep55 caching it is actually slower!"

The only possible change to GLEP 55 performance-wise is in the file
name recognition, and that's so obviously not an issue that there's no
way anyone can take it seriously.

Unless you seriously think he's claiming that GLEP 55 does away with the
need for storing EAPI in metadata cache, which is even more obviously
nonsense...

Either way, he's trolling and needs to be called on it.

--
Ciaran McCreesh

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

Ciaran McCreesh-4
In reply to this post by RB-14
On Thu, 14 May 2009 13:17:24 -0600
RB <[hidden email]> wrote:

> On Thu, May 14, 2009 at 13:11, Ciaran McCreesh
> <[hidden email]> wrote:
> > Please explain why you claimed GLEP 55 makes things slower. Until
> > you answer that, it's hard to take you for anything other than a
> > troll.
>
> Hell, I'll explain.  Read paragraph 8 again.  Slowly.  Read it a
> second time, since you obviously didn't read the first time.  The
> paragraph makes the point that the pro-GLEP55 stance says that
> encoding EAPI inside the file is slower.  It is not saying GLEP55 is
> slower, it is attempting to debunk the theory that it is faster.
"so with glep55 caching it is actually slower!"

There's no possible way that can make sense. Whatever he's claiming by
that is obviously nonsense.

--
Ciaran McCreesh

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

Patrick Lauer
On Thursday 14 May 2009 21:20:18 Ciaran McCreesh wrote:

> On Thu, 14 May 2009 13:17:24 -0600
>
> RB <[hidden email]> wrote:
> > On Thu, May 14, 2009 at 13:11, Ciaran McCreesh
> >
> > <[hidden email]> wrote:
> > > Please explain why you claimed GLEP 55 makes things slower. Until
> > > you answer that, it's hard to take you for anything other than a
> > > troll.
> >
> > Hell, I'll explain.  Read paragraph 8 again.  Slowly.  Read it a
> > second time, since you obviously didn't read the first time.  The
> > paragraph makes the point that the pro-GLEP55 stance says that
> > encoding EAPI inside the file is slower.  It is not saying GLEP55 is
> > slower, it is attempting to debunk the theory that it is faster.
>
> "so with glep55 caching it is actually slower!"
>
> There's no possible way that can make sense. Whatever he's claiming by
> that is obviously nonsense.


Ah. I was not precise enough.

Let me rephrase it in less ambiguous terms then -


"Having EAPI in the ebuild is slower than having it encoded in the filename"

Counterpoint: No, you use caching if it is that darn slow
Bonus: GLEP55 makes caching that slower than accessing it directly
Extra bonus: about a dozen emails going around in circles over a careless
formulation that gets misinterpreted into "The iraqis have weapons of mass
destruction!"

Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

Ciaran McCreesh-4
In reply to this post by Jeremy Olexa-3
On Thu, 14 May 2009 14:15:28 -0500
Jeremy Olexa <[hidden email]> wrote:

> On Thu, May 14, 2009 at 2:06 PM, David Leverton
> <[hidden email]> wrote:
> > yourself, "shell-like".   "printf -v EAPI 1" is perfectly valid
> > shell (at least if we decide to allow bash 3.1 features), and has
> > the same effect
>
> To stir things up:
> Who decides this? There are more and more bash-3.1 features in the
> tree and I brought it up to the Council months ago becase the PMS says
> that only bash-3.0 is allowed but no one cares.
Can't allow newer bash features in global scope until the whole "can't
make global scope changes" thing is sorted out.

--
Ciaran McCreesh

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

Ciaran McCreesh-4
In reply to this post by Patrick Lauer
On Thu, 14 May 2009 21:24:14 +0200
Patrick Lauer <[hidden email]> wrote:

> > "so with glep55 caching it is actually slower!"
> >
> > There's no possible way that can make sense. Whatever he's claiming
> > by that is obviously nonsense.
>
> Ah. I was not precise enough.
>
> Let me rephrase it in less ambiguous terms then -
>
> "Having EAPI in the ebuild is slower than having it encoded in the
> filename"
>
> Counterpoint: No, you use caching if it is that darn slow
Cache it where? There's already a cache, and introducing any new cache
will only slow things down, not speed them up.

And you still haven't justified how glep 55 makes it slower.

--
Ciaran McCreesh

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

Ben de Groot-2
In reply to this post by Patrick Lauer
Patrick Lauer wrote:
> For quite some time (over a year, actually) we've been discussing the
> mysterious and often misunderstood GLEP55.
> [http://www.gentoo.org/proj/en/glep/glep-0055.html]
>
> The proposed solution to a problem that is never refined,

This, in my opinion, is the crux of the matter. Most of us apparently
are not sufficiently convinced that there actually is a problem. Until
the problem is explained with clarity, the rest of the proposal is useless.

> "Obviously you don't understand the issue, because if you did you'd support
> it!"

I concur that speaking for myself, I don't understand the issue. And it
looks like many others don't either. So if anyone wants to promote this
GLEP, their job is clear: make people understand what the issue is here,
and convince them it is actually an issue. (Examples, scenarios usually
work well, indeed a lot better than calling people names.)

> And maybe we can now spend the same amount of
> council-time (it has been eating time for over a year!) to get important
> things done ...

I want to call on the Council to reject this GLEP in its current form,
as the problem has been insufficiently clarified. We should not waste
more time on it.

Cheers,
--
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
Gentoo Linux Release Engineering PR liaison
______________________________________________________

Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

Peter Alfredsen-3
On Thu, 14 May 2009 22:03:22 +0200
Ben de Groot <[hidden email]> wrote:

> I concur that speaking for myself, I don't understand the issue. And
> it looks like many others don't either. So if anyone wants to promote
> this GLEP, their job is clear: make people understand what the issue
> is here, and convince them it is actually an issue. (Examples,
> scenarios usually work well, indeed a lot better than calling people
> names.)

We need a mechanism to be able to use newer bash-features in ebuilds.
Preferably one that doesn't go "Wait a couple of years, hope
everyone did X then Just Do it." We want one that goes like "Get a new
EAPI approved with new minimum bash-version attached, start using cool
stuff like ( Bash-4.0 ):

shopt -s globstar
for i in /usr/share/man/**/*remote*
do
        stuff
done

Built-in find in bash, how do you like them bananas? :-)

find equivalent would be, if you wanted the same level of space-safety:

while read -r line
do
        stuff
done < <(find /usr/share/man -name '*remote*')

Personally, I like the first version better. It would be cool if we
could start using it sooner. GLEP-55 provides the "clean" solution, by
just making the file name indicate what's inside. No need to parse, no
nothing. Portage is currently testing a "first line with EAPI=
determines EAPI" method. That's slightly less clean, but has the added
benefit of not breaking anything that relies on .ebuild extension for
ebuilds and I think it's not an unreasonable limitation on ebuilds to
require EAPI= to be parseable by !bash.

/loki_val

Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

William Hubbs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I realize that I'm asking this very late in the discussion, so please
bear with me if it has been hashed before.

On Thu, May 14, 2009 at 11:16:23PM +0200, Peter Alfredsen wrote:
> We need a mechanism to be able to use newer bash-features in ebuilds.
> Preferably one that doesn't go "Wait a couple of years, hope
> everyone did X then Just Do it." We want one that goes like "Get a new
> EAPI approved with new minimum bash-version attached, start using cool
> stuff like ( Bash-4.0 ):
 
 <snip>

> Personally, I like the first version better. It would be cool if we
> could start using it sooner. GLEP-55 provides the "clean" solution, by
> just making the file name indicate what's inside. No need to parse, no
> nothing. Portage is currently testing a "first line with EAPI=
> determines EAPI" method. That's slightly less clean, but has the added
> benefit of not breaking anything that relies on .ebuild extension for
> ebuilds and I think it's not an unreasonable limitation on ebuilds to
> require EAPI= to be parseable by !bash.
 
I don't know how strong this argument is, but here is my opinion about
the issue, followed up with a question.

The second solution seems to be the better one because it does not go
against standards.  For example, we see extentions like .c, .py and
.pl, instead of .c-43, .py-25 and .pl-58.  There are ways within the
languages to tell which version of the compiler is compiling them as
needed.  So, If we say that, EAPI 4, for example, requires bash-4.0,
Isn't there a way the PM could find out which version of bash is being
run, compare that to the EAPI, then take appropriate action?

- --
William Hubbs
gentoo accessibility team lead
[hidden email]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoMkdUACgkQblQW9DDEZTihowCdEynGXsB0Z1r9y43VeWEs9JLF
SrQAn2iNPikCR+tZHGyrv+ykr4y1D+81
=6F5i
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

Ciaran McCreesh-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 14 May 2009 16:49:09 -0500
William Hubbs <[hidden email]> wrote:
> The second solution seems to be the better one because it does not go
> against standards.  For example, we see extentions like .c, .py and
> .pl, instead of .c-43, .py-25 and .pl-58.  There are ways within the
> languages to tell which version of the compiler is compiling them as
> needed.  So, If we say that, EAPI 4, for example, requires bash-4.0,
> Isn't there a way the PM could find out which version of bash is being
> run, compare that to the EAPI, then take appropriate action?

It can't, because it doesn't know the EAPI until it's sourced the thing
using bash. Using things like += in global scope will break older bash
versions to the point that they can't reliably extract EAPI.

- --
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkoMkuMACgkQ96zL6DUtXhEWmQCeOIHQLeguFo7vZXQCG5aE5imF
0rIAn1tOEyeyATdwoLGI8dCUs5s3afKR
=JRMB
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

Patrick Lauer
On Thursday 14 May 2009 23:53:37 Ciaran McCreesh wrote:

> On Thu, 14 May 2009 16:49:09 -0500
>
> William Hubbs <[hidden email]> wrote:
> > The second solution seems to be the better one because it does not go
> > against standards.  For example, we see extentions like .c, .py and
> > .pl, instead of .c-43, .py-25 and .pl-58.  There are ways within the
> > languages to tell which version of the compiler is compiling them as
> > needed.  So, If we say that, EAPI 4, for example, requires bash-4.0,
> > Isn't there a way the PM could find out which version of bash is being
> > run, compare that to the EAPI, then take appropriate action?
>
> It can't, because it doesn't know the EAPI until it's sourced the thing
> using bash. Using things like += in global scope will break older bash
> versions to the point that they can't reliably extract EAPI.

Trying to pull a Goebbels, eh?

As I've said a few times you don't have to do something as complex as sourcing
it. In most cases you might get lucky and have some form of caching or pre-
parsed data available, so you don't even have to care. And in the other cases,
assuming that we're talking about current ebuilds which are shell-ish and
either define EAPI explicitly or can be assumed to be EAPI0 you can search
with a simple regexp. That's so funky that it even works!

So if you were a lazy Unix coder you'd just restrict the current rules a bit
so that there's only one line starting with EAPI= allowed (or maybe you just
take the first or last one, but that's annoying) and if no such line matches
you can safely assume EAPI0

Maybe you're very lazy, so you explicitly forbid eclasses from setting or
changing EAPI. That also avoids weird effects that make you lose lots of time
for debugging because you didn't think about what would happen if foo.eclass
set EAPI="3.14" and bar.eclass inherited later set EAPI="1" ...

And magically you haven't really changed current behaviour, can get the EAPI
without sourcing it and you can be lazy once more. Isn't it great?

Reply | Threaded
Open this post in threaded view
|

Re: The fallacies of GLEP55

George Prowse-3
In reply to this post by Ciaran McCreesh-4
Ciaran McCreesh wrote:

> On Thu, 14 May 2009 20:06:51 +0200
> Patrick Lauer <[hidden email]> 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.
>
> 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.
>
>> "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.
>
>> "Having GLEP55 allows us to add GLEP54 without issues!"
>> Yeah, uhm, the live-ness of an ebuild is an attribute. How about we
>> add it to metadata, as we should for all metadata? Define a key, I
>> don't know ... LIVE ? LIVE="true". There. No need to fix the
>> filename. And now stop mixing up issues because it is highly
>> confusing!
>
> There is no existing version ordering solution that accurately
> represents upstream scm branches.
>
>> 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.
>
>> 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.
>
> 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.
>
Having countered those four points I guess you agree with the other five
then. Over 50% success rate (by your definition) is hardly being
ignorant or trolling

1234 ... 6