[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]

Ali Polatel (hawking) schrieb:
> 	use threads \
> 		&& myconf="${myconf} --with-threads" \
> 		|| myconf="${myconf} --without-threads"

What about an econf option $(use_with threads)?

> 	econf \
> 		--with-fpectl \
> 		--enable-shared \
> 		`use_enable ipv6` \
> 		--infodir='${prefix}'/share/info \
> 		--mandir='${prefix}'/share/man \
> 		--with-libc='' \
> 		${myconf} || die

"|| die" could be dropped

> src_install() {
> 	dodir /usr

Will the install fail without a /usr dir?

> 	src_configure
> 	make DESTDIR="${D}" altinstall maninstall || die

Why not emake?

> 	if use examples ; then
> 		mkdir -p "${D}"/usr/share/doc/${P}/examples
> 		cp -r "${S}"/Tools "${D}"/usr/share/doc/${P}/examples
> 	fi

what about this:
	insinto /usr/share/doc/${P}/examples
	doins -r Tools

> 	python_mod_cleanup /usr/lib/python${PYVER}
> 	[[ "$(get_libdir)" == "lib" ]] || \
> 		python_mod_cleanup /usr/$(get_libdir)/python${PYVER}

Why not remove the first 2 lines?

> 	python_mod_optimize -x "(site-packages|test)" \
> 						/usr/lib/python${PYVER}
> 	[[ "$(get_libdir)" == "lib" ]] || \
> 		python_mod_optimize -x "(site-packages|test)" \
> 							/usr/$(get_libdir)/python${PYVER}

the same here


-- 
Thomas Sachau

Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 315 bytes --]

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Ulrich Mueller]

>>>>> On Sun, 05 Oct 2008, Thomas Sachau wrote:

>> econf \
>> [...]
>> ${myconf} || die

> "|| die" could be dropped

All our documentation (devmanual, ebuild howto, skel.ebuild, pms)
recommends "econf || die".

So maybe you should first make an effort to have it changed there?
I wouldn't consider it a bug in ebuilds if they conform to what is
documented.

Ulrich

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 217 bytes --]

On Sun, 5 Oct 2008 21:48:09 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> All our documentation (devmanual, ebuild howto, skel.ebuild, pms)
> recommends "econf || die".

I've fixed PMS.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Ali Polatel]

[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]

Thomas Sachau yazmış:
> Ali Polatel (hawking) schrieb:
> > 	use threads \
> > 		&& myconf="${myconf} --with-threads" \
> > 		|| myconf="${myconf} --without-threads"
> 
> What about an econf option $(use_with threads)?
> 
> > 	econf \
> > 		--with-fpectl \
> > 		--enable-shared \
> > 		`use_enable ipv6` \
> > 		--infodir='${prefix}'/share/info \
> > 		--mandir='${prefix}'/share/man \
> > 		--with-libc='' \
> > 		${myconf} || die
> 
> "|| die" could be dropped
> 
> > src_install() {
> > 	dodir /usr
> 
> Will the install fail without a /usr dir?
> 
> > 	src_configure
> > 	make DESTDIR="${D}" altinstall maninstall || die
> 
> Why not emake?
> 
> > 	if use examples ; then
> > 		mkdir -p "${D}"/usr/share/doc/${P}/examples
> > 		cp -r "${S}"/Tools "${D}"/usr/share/doc/${P}/examples
> > 	fi
> 
> what about this:
> 	insinto /usr/share/doc/${P}/examples
> 	doins -r Tools
> 
> > 	python_mod_cleanup /usr/lib/python${PYVER}
> > 	[[ "$(get_libdir)" == "lib" ]] || \
> > 		python_mod_cleanup /usr/$(get_libdir)/python${PYVER}
> 
> Why not remove the first 2 lines?
> 
> > 	python_mod_optimize -x "(site-packages|test)" \
> > 						/usr/lib/python${PYVER}
> > 	[[ "$(get_libdir)" == "lib" ]] || \
> > 		python_mod_optimize -x "(site-packages|test)" \
> > 							/usr/$(get_libdir)/python${PYVER}
> 
> the same here
> 
> 

+*python-2.6-r1 (06 Oct 2008)
+
+  06 Oct 2008; Ali Polatel <hawking@gentoo.org> -python-2.6.ebuild,
+  +python-2.6-r1.ebuild:
+  Revbump. Use use_with for threads, remove die from econf, use emake
+  instead of make, remove redundant python_mod_{cleanup,optimize}. Drop old.
+

Thanks!

> -- 
> Thomas Sachau
> 
> Gentoo Linux Developer
> 

-- 
Regards,
Ali Polatel

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Steve Long]

Thomas Sachau wrote:

> what about this:
> insinto /usr/share/doc/${P}/examples
Is there any chance we can start using correctly quoted filenames across the
board? 

[@list NB: I'm raising this as a talking-point, not pushing it as an agenda,
so please don't reply if discussion doesn't interest you.]

Besides being faster (quote the whole thing) they leave the option in future
of having package names etc with spaces, or at this point, more useful
error messages in the case of a dev/user slip-up. They also highlight
better in a capable editor.[1]

iow: insinto "/usr/share/doc/$P/examples"

[1] Try kate, if gvim and xemacs don't do it for you: that quoting error of
yours in the other thread would be a very good example-- it simply wouldn't
happen on kate unless you had a very strange (ie functionally useless;)
colour setup.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

Steve Long wrote:
>> insinto /usr/share/doc/${P}/examples
> Is there any chance we can start using correctly quoted filenames across the
> board? 

Since when is ${P} allowed to have spaces?

> Besides being faster (quote the whole thing)

Have you done a benchmark certifying that "/usr/share/doc/${P}/examples" 
is faster than /usr/share/doc/${P}/examples?

> more useful error messages in the case of a dev/user slip-up

Could you elaborate?

> They also highlight better in a capable editor.[1]

Please elaborate.

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

On Mon, 13 Oct 2008 03:59:00 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:

> Thomas Sachau wrote:
> 
> > what about this:
> > insinto /usr/share/doc/${P}/examples
> Is there any chance we can start using correctly quoted filenames
> across the board?

This is correctly quoted, so, yep.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Steve Long]

Jan Kundrát wrote:
> Steve Long wrote:
>>> insinto /usr/share/doc/${P}/examples
>> Is there any chance we can start using correctly quoted filenames across
>> the board?
> 
> Since when is ${P} allowed to have spaces?
>
I believe I answered this in my prior post.
 
>> Besides being faster (quote the whole thing)
> 
> Have you done a benchmark certifying that "/usr/share/doc/${P}/examples"
> is faster than /usr/share/doc/${P}/examples?
>
Here you go (this is on an old machine, so you'll get much quicker times if
you try this at home):
[igli@box ~]$ echo "$(<run)"
#!/bin/bash
P='some-crap/god-i-hate-asshats'
for ((i=0;i<100000;i++)); do echo /usr/share/doc/${P}/examples > /dev/null;
done
[igli@box ~]$ echo "$(<run2)"
#!/bin/bash
P='some-crap/god-i-hate-asshats'
for ((i=0;i<100000;i++)); do echo "/usr/share/doc/$P/examples" > /dev/null;
done

[igli@box ~]$ for ((l=0;l<5;l++)); do time -p ./run; done
real 11.25
user 9.96
sys 1.13
real 11.12
user 9.82
sys 1.16
real 10.99
user 9.70
sys 1.15
real 11.25
user 10.02
sys 1.07
real 11.36
user 10.06
sys 1.16

[igli@box ~]$ for ((l=0;l<5;l++)); do time -p ./run2; done
real 9.24
user 8.00
sys 1.11
real 9.22
user 8.02
sys 1.08
real 9.08
user 7.90
sys 1.06
real 9.23
user 7.96
sys 1.15
real 9.18
user 7.98
sys 1.09

>> more useful error messages in the case of a dev/user slip-up
> 
> Could you elaborate?
>
File not found "foo/bar bar/" as opposed to two separate lines; for elib
functions, one would expect there to be an error handler which would be
wrapping that, per-parameter.
 
>> They also highlight better in a capable editor.[1]
> 
> Please elaborate.
> 
I did.

Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 243 bytes --]

On Wed, Oct 15, 2008 at 10:33:22AM +0100, Steve Long wrote:
> Here you go (this is on an old machine, so you'll get much quicker times if
> you try this at home):

A big gain in the context of ebuilds and source packages. Well done.

- ferdy


[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[David Leverton]

On Wednesday 15 October 2008 10:33:22 Steve Long wrote:
> Here you go (this is on an old machine, so you'll get much quicker times if
> you try this at home):
> [igli@box ~]$ echo "$(<run)"
> #!/bin/bash
> P='some-crap/god-i-hate-asshats'

I do hope that that isn't directed at anyone in particular.

> for ((i=0;i<100000;i++)); do echo /usr/share/doc/${P}/examples > /dev/null;

> real 11.25

> real 9.24

So that's what, on the order of 20 microseconds faster for each iteration?

This is a purely stylistic issue, same as the braces with variable expansions.  
You're free to write your own code however you like, but harassing other 
people to do things your favourite way with no practical benefit is just 
going to annoy everyone. 

[gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Steve Long]

Fernando J. Pereda wrote:

> On Wed, Oct 15, 2008 at 10:33:22AM +0100, Steve Long wrote:
>> Here you go (this is on an old machine, so you'll get much quicker times
>> if you try this at home):
> 
> A big gain in the context of ebuilds and source packages. Well done.
> 
Yes, almost as important as not sourcing any ebuilds, so let's all stick an
EAPI extension on the end of the filename.

Re: [gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

On Wed, 15 Oct 2008 20:28:43 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> Fernando J. Pereda wrote:
> > On Wed, Oct 15, 2008 at 10:33:22AM +0100, Steve Long wrote:
> >> Here you go (this is on an old machine, so you'll get much quicker
> >> times if you try this at home):
> > 
> > A big gain in the context of ebuilds and source packages. Well done.
> > 
> Yes, almost as important as not sourcing any ebuilds, so let's all
> stick an EAPI extension on the end of the filename.

If you really think that EAPI as an extension has anything to do with
performance, you are even more sadly mistaken than usual, and I
suggest you lay off the GLEP 55 bashing until you've bothered to read
it.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Steve Long]

David Leverton wrote:

> On Wednesday 15 October 2008 10:33:22 Steve Long wrote:
>> Here you go (this is on an old machine, so you'll get much quicker times
>> if you try this at home):
>> [igli@box ~]$ echo "$(<run)"
>> #!/bin/bash
>> P='some-crap/god-i-hate-asshats'
> 
> I do hope that that isn't directed at anyone in particular.
>
No, but thanks for drawing attention to it.
 
>> for ((i=0;i<100000;i++)); do echo /usr/share/doc/${P}/examples >
>> /dev/null;
> 
>> real 11.25
> 
>> real 9.24
> 
> So that's what, on the order of 20 microseconds faster for each iteration?
>
Or ~18%. (You shouldn't use the first iteration in general, btw.)
 
> This is a purely stylistic issue, same as the braces with variable
> expansions.
See my other posts.

> You're free to write your own code however you like, but 
> harassing other people to do things your favourite way with no practical
> benefit is just going to annoy everyone.

I'm sorry you feel harrassed by my talking about the basics of
shell-scripting, it wasn't intended like that. Though, given your tone, I
don't think you are feeling harrassed; perhaps you're just feeling
defensive about your trap boo-boo? Whatever, leaving aside the amateur
dramatics, it was more to show how to do the benchmarking than anything
else; I'd have simply said "yes" but that reminded me too much of behaviour
I have criticised in the past.

For the record, I'm sorry if my choice of package name caused any offence to
anyone else. It was a quick thing I knocked off, cp'ed and pasted; at most
I thought it would be taken as a joke when I wrote it, then I didn't check
it through in the correct frame of mind (I have flu and was tired, so just
wanted to send the thing and didn't check the script itself) when I sent
it, and for that I apologise to everyone reading.

Re: [gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

On Wed, 15 Oct 2008 20:51:32 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > So that's what, on the order of 20 microseconds faster for each
> > iteration?
> >
> Or ~18%. (You shouldn't use the first iteration in general, btw.)

18% of nothing is nothing.

> perhaps you're just feeling defensive about your trap boo-boo?

Those of us who have tried trap have fairly conclusive proof it won't
work. Perhaps you'd like to show how wrong we are and provide a working
demonstration.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 285 bytes --]

On Wed, Oct 15, 2008 at 08:51:32PM +0100, Ranjit Singh wrote:
> > This is a purely stylistic issue, same as the braces with variable
> > expansions.
> See my other posts.

Your other posts only show that this is, indeed, a personal stylistic
issue. And a pointless one, too.

- ferdy


[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Arun Raghavan]

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

Steve Long wrote:
[...]
>>> for ((i=0;i<100000;i++)); do echo /usr/share/doc/${P}/examples >
>>> /dev/null;
>>> real 11.25
>>> real 9.24
>> So that's what, on the order of 20 microseconds faster for each iteration?
>>
> Or ~18%. (You shouldn't use the first iteration in general, btw.)

I've not really got an opinion on the topic, per se, but fwiw, this is
really not a meaningful statistic. *If* parsing strings in the ebuild is
not a trivial part of the overall ebuild parsing process, then yes, this
is a significant gain and should be treated as such. I find it unlikely
that this would be the case.

I'm not sure how one can go about measuring the impact of this on ebuild
parsing as a whole. Maybe make take a few "typical" ebuilds, change
quoting style, and run it through ebuild.sh in a loop. All the inherited
eclasses would need to change too, though, I guess.

Regards,
Arun
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkj2sxgACgkQ+Vqt1inD4uzW3wCfancNcJxcyHerjSZdZfK9UKb7
k5oAn0186/lLTAS2+n1Z7egzhAP1kISV
=CkaZ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Peter Volkov]

В Срд, 15/10/2008 в 20:51 +0100, Steve Long пишет:
> >> for ((i=0;i<100000;i++)); do echo /usr/share/doc/${P}/examples >
> >> /dev/null;
> > 
> >> real 11.25
> > 
> >> real 9.24
> > 
> > So that's what, on the order of 20 microseconds faster for each iteration?
> >
> Or ~18%. (You shouldn't use the first iteration in general, btw.)

Steve, your example only tests how much time bash takes to parse string.
It's obvious that in quoted strings some expansions could be avoided and
thus bash works faster. But although ebuilds use bash syntax they are
interpreted not only by bash - the time to parse stings is negligible to
other activities. I have not calculated but made a rough estimation
taking into account the number of ebuilds in the tree. So I think we
have of order of 10^6 string. This means that during merge of all
packages we'll win 10 seconds. I don't think it's worth to consider this
gain.

So in portage tree this is the matter of style. That's said, since
personally I don't have any preference on this style and until there
will be arguments not to use this style I'll start to use full quotation
of the strings.

And yes, in pure bash programs possibly this'll make sense.

-- 
Peter.

[gentoo-dev] Re: Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Steve Long]

Arun Raghavan wrote:
> I've not really got an opinion on the topic, per se, but fwiw, this is
> really not a meaningful statistic. *If* parsing strings in the ebuild is
> not a trivial part of the overall ebuild parsing process, then yes, this
> is a significant gain and should be treated as such. I find it unlikely
> that this would be the case.
>
Sure, it's nothing that major, it's just one example of a free performance
increase. (Although I would point out that "parsing strings" is basically
what shells do.) Sure, that's nothing in the context of the actual install,
but there were a few comments in the huge GLEP-55 thread about performance
during cache generation.
 
> I'm not sure how one can go about measuring the impact of this on ebuild
> parsing as a whole. Maybe make take a few "typical" ebuilds, change
> quoting style, and run it through ebuild.sh in a loop. All the inherited
> eclasses would need to change too, though, I guess.
> 
Yeah, though I won't be doing it, I've kinda lost my enthusiasm; if anyone's
learnt something they didn't know before, that's good enough.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Steve Long]

Peter Volkov wrote:
> Steve, your example only tests how much time bash takes to parse string.
> It's obvious that in quoted strings some expansions could be avoided and
> thus bash works faster.

Yeah that's all I wanted to get across.

> But although ebuilds use bash syntax they are 
> interpreted not only by bash - the time to parse stings is negligible to
> other activities. I have not calculated but made a rough estimation
> taking into account the number of ebuilds in the tree. So I think we
> have of order of 10^6 string. This means that during merge of all
> packages we'll win 10 seconds. I don't think it's worth to consider this
> gain.
>
Agreed; in the context of a build it's not at all significant. It might be
in the context of metadata generation.

> So in portage tree this is the matter of style. That's said, since
> personally I don't have any preference on this style and until there
> will be arguments not to use this style I'll start to use full quotation
> of the strings.
>
Thanks for taking it on board :-)

> And yes, in pure bash programs possibly this'll make sense.
> 
Yeah; that's effectively what ebuild.sh, combined with all the files it
sources, is. (There's quite a bit of code there.)

Regards,
Steve.

[gentoo-dev] Re: Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Steve Long]

Ciaran McCreesh wrote:
> On Wed, 15 Oct 2008 20:28:43 +0100
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> Fernando J. Pereda wrote:
>> > A big gain in the context of ebuilds and source packages. Well done.
>> > 
>> Yes, almost as important as not sourcing any ebuilds, so let's all
>> stick an EAPI extension on the end of the filename.
> 
> If you really think that EAPI as an extension has anything to do with
> performance

You mentioned performance a few times in that lovely thread when it got shot
down, I believe in the context of metadata generation:

"Performance hit" (when discussing an alternative) [1]
"The GLEP is not about performance, but any solution that forces the
introduction of a slowdown of more than, say, 20%, isn't viable." [2]
"It's several more directory reads. This is a measurable performance
hit" [3]

Are you now saying performance doesn't matter?

> , you are even more sadly mistaken than usual

My how the insults fly.. must be a new academic year.

> , and I  
> suggest you lay off the GLEP 55 bashing until you've bothered to read
> it.
> 
Yeah cos obviously I never read it when it was last discussed. Way to go
with unfounded, clearly absurd, assertions.

[1] http://article.gmane.org/gmane.linux.gentoo.devel/53512
[2] http://article.gmane.org/gmane.linux.gentoo.devel/53751
[3] http://article.gmane.org/gmane.linux.gentoo.devel/53668

Re: [gentoo-dev] Re: Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

On Thu, 16 Oct 2008 22:01:40 +0100 Ranjit Singh wrote:
> > If you really think that EAPI as an extension has anything to do
> > with performance
> 
> You mentioned performance a few times in that lovely thread when it
> got shot down, I believe in the context of metadata generation:
> 
> "Performance hit" (when discussing an alternative) [1]
> "The GLEP is not about performance, but any solution that forces the
> introduction of a slowdown of more than, say, 20%, isn't viable." [2]
> "It's several more directory reads. This is a measurable performance
> hit" [3]
> 
> Are you now saying performance doesn't matter?

Please re-read what I said. EAPI as an extension has nothing to do with
performance. This does not mean that an alternative that has
significant performance implications is not a problem.

I'll explain it for you in much simpler terms: equipping a car with a
new kind of engine and fuel system that is much safer in the case of an
accident is a good thing, but not if it also reduces the car's top
speed to 30mph.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]

On Thu, Oct 16, 2008 at 10:01:40PM +0100, Steve Long wrote:
> Ciaran McCreesh wrote:
> > On Wed, 15 Oct 2008 20:28:43 +0100
> > Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> >> Fernando J. Pereda wrote:
> >> > A big gain in the context of ebuilds and source packages. Well done.
> >> > 
> >> Yes, almost as important as not sourcing any ebuilds, so let's all
> >> stick an EAPI extension on the end of the filename.
> > 
> > If you really think that EAPI as an extension has anything to do with
> > performance
> 
> You mentioned performance a few times in that lovely thread when it got shot
> down, I believe in the context of metadata generation:
> 
> "Performance hit" (when discussing an alternative) [1]
> "The GLEP is not about performance, but any solution that forces the
> introduction of a slowdown of more than, say, 20%, isn't viable." [2]
> "It's several more directory reads. This is a measurable performance
> hit" [3]
> 
> Are you now saying performance doesn't matter?

No, performance is just a side effect it has never been part of the
motivation of the GLEP. You are the only fighting over stupid pico
optimizations.

- ferdy


[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[David Leverton]

2008/10/15 Steve Long <slong@rathaus.eclipse.co.uk>:
> Though, given your tone, I don't think you are feeling harrassed; perhaps
> you're just feeling defensive about your trap boo-boo?

Er, I'm not aware of anyone even trying to tell me that I'm wrong with
anything I've ever said about trap.  If you mean not being able to use
trap ... ERR instead of explicit dies, and you know of a way to make
it work nicely with existing bash versions, then by all means post it
to the bug.  Otherwise, I really have no idea what you're on about.