[gentoo-dev] Re: ICC Profile

2008-07-18 Thread Nikos Chantziaras

Adam Stylinski wrote:

The intel C Compiler (icc) has an ebuild for gentoo and the wiki has
a script to integrate it with portage.


I'm using ICC for programs where I have numbers about performance; for 
example, bzip2 is 30% faster here when compiled with ICC.


However, one thing I don't like about ICC is that when you post in the 
Intel forums about a problem you have on Gentoo, the reply is Gentoo is 
not supported, please use RedHat.  If Gentoo is going to support ICC, 
ICC should be supporting Gentoo as well.


--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] ICC Profile

2008-07-18 Thread Adam Stylinski
I'm not suggesting that it be sold. Gentoo is
non-profit anyway, the livecd could be available for
download only. The binaries don't have to be
licensed if you're not selling them, however the
compiler does. This is where the non-commercial free
license comes in (with a fetch restriction requiring
the user to register for it). This is completely
free and I don't see it much more of a pain than it
is to go sign up for the IBM developers work to
extract their PPC version of java.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: ICC Profile

2008-07-18 Thread Adam Stylinski
I actually know somebody working at intel, maybe he can get them more involved.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: ICC Profile

2008-07-18 Thread Branko Badrljica

BTW: Is ICC really worth the fuss ?
I have checked around and reported that newest gcc-4.3 is able to to 
catch and sometimes even outperform icc ( not always, naturally).


Big news seemed to be thatnew gcc si close and sometimes better than icc.

Is it any truth to that and if it is, what is the motive of having 
non-open icc option ?






Adam Stylinski wrote:

I actually know somebody working at intel, maybe he can get them more involved.
  


--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] ICC Profile

2008-07-18 Thread Doug Goldstein

Robert Bridge wrote:

On Fri, 18 Jul 2008 11:34:11 +0900
Luca Barbato [EMAIL PROTECTED] wrote:

  

Adam Stylinski wrote:


The intel C Compiler (icc)
  

icc, xlc, llvm, sunstudio could be interesting fields of discovery.

Which are the pitfalls of using icc?

lu




If I recall correctly, needing some packages compiled with ICC flags
set one way, and needing others compiled with the same flag set the
oter way.

Can it compile a kernel yet?

Rob.
  
No. It doesn't implement all of GCCs extensions and all GNUisms that the 
kernel relies on.

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] system set no longer in part of world set

2008-07-18 Thread Doug Goldstein

Olivier Crête wrote:

On Mon, 2008-07-14 at 18:01 -0400, Doug Goldstein wrote:
  
This brings out the fun of circular depends. I don't really know how to 
address this but a lot of packages are going to have to be updated to 
contain proper depends. i.e. C based apps will need 
RDEPEND=virtual/libc. C++ packages will need a stdc++ depend.



Adding a dep to libc almost everywhere seems extremely wrong to me. I
though we had decided many times that it was a bad idea.

  
Yes. Adding libc everywhere is wrong. However, if you don't have one of 
the packages listed here [1], your libc won't ever update.


[1] http://tinderbox.dev.gentoo.org/misc/rindex/virtual/libc
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] ICC Profile

2008-07-18 Thread Sébastien Fabbro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Apologies if you received this mail already, I'm having problems with my
smtp.

On Thursday July 17 Adam Stylinski wrote:

 The intel C Compiler (icc) has an ebuild for gentoo and the wiki has
 a script to integrate it with portage.  This script works will in
 terms of building binaries, however when mixed with gcc environments
 there are massive linking issues.  I propose that an ICC profile is
 made which contains specific versions and default flags for people
 who want to build a mixed icc-gcc environment.  ICC is much faster
 than GCC and although not free, offers a free non-commercial
 license.  I would be very interested in this project and more than
 willing to help to the best of my abilities.  I've already been
 trying to maintain a mixed environment with some luck, while there
 have been a lot of problems using dynamically linked libraries (ld
 from intel and ld from gcc don't always get along), my system is
 substatially faster.  The kernel obviously will still be built under
 gcc as well as bash (unless intel helps submit patches to make the
 code work with their compiler).  There are many tools icc ! has to
 offer for vectorization.  If these were streamlined into Gentoo with
 a fetch restriction for ICC, a bootsrapping boot disk could be made
 and result in a very fast distribution. 


An icc profile would be welcome. I've been the maintainer of icc (and
other Intel tools) for the last year or so more by default than
real interest. I would welcome any input from the Gentoo community.
Re-adding slots and an icc profile was on my mind, but never found the
time to invest in it, and got at the tail of my priority list. So don't
hesitate to contact me (email, irc, bugs) and others.

There was some attempts a few years ago for rolling up a full Gentoo
with icc, but it hit several problems if I recall. Now both icc and gcc
have improved since then.

Also, if you haven't already, check also some of the old bugs [1,2] we
have, and a recurring one [3].

I would like to recall one important issue with the Intel license
concerning the free for non-commercial use [4]. It means
you can't use it for free if you're paid to use it. Yes,
beer is not free for academic scientists too.

[1] http://bugs.gentoo.org/show_bug.cgi?id=26757
[2] http://bugs.gentoo.org/show_bug.cgi?id=53808
[3] http://bugs.gentoo.org/show_bug.cgi?id=201596
[4] http://www.intel.com/cd/software/products/asmo-na/eng/219692.htm#0

- - -- 
Sébastien
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiApboACgkQ1ycZbhPLE2BMHgCggfzfS4SakVyw42r+JnnxYNpL
E9gAoJvRrocinIDlInF6kbeSGF2kvX9t
=M4XK
-END PGP SIGNATURE-


Re: [gentoo-dev] ICC Profile

2008-07-18 Thread Sébastien Fabbro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Thursday July 17, Adam Stylinski wrote:

 Pro's:
 
 1.) Bloody fast machine code.  Intel obfuscates their architecture
 but they give back to the community as much as possible to make their
 hardware marketable toward the open source sysadmin, developer, etc
 etc.  Their drivers are open and they develop for the kernel
 constantly.  This cooperation leads me to believe that they would
 assist a team of developers in making 100% icc compatible code.  

Gentoo is not supported from Intel, and they had not plans doing so. As
of October 2007, I asked their Software channel whether Gentoo
users have similar support as RedHat or SUSE users and the answer was:

No, we have no current plans to support Gentoo. Also, Gentoo is NOT a
derivative of a Linux we do support.  My understanding is that it is
independently derived from Kernel.org.  Thus it is less likely to work
than a distro which is a derivative of a supported distribution.

Meanwhile, Debian/Ubuntu got support, so things might change if
Gentoo re-becomes/remains popular. Any Intel dev reading this list,
please contact us.

And as Luca mentioned, having sunstudio, xlc (is this one free?) or llvm
would not make Intel a privileged case for Gentoo.


 2.) Bloody fast compilation time.  In my experience the compiler
 works much faster even with heavy optimization.  

I don't experience this that much, but I really don't use it much
either. Would be nice to have benchmarks here.

 
 4.) will project gentoo toward the power user more, helps the gentoo
 image, and overall will make linux a more professional operating
 system (and a quite competitive alternative to something like a
 SPARC+Solaris configuration).  This would also make cluster farms and
 science application more respectful toward the gentoo community.  The
 academic and research world already uses ICC to compile their apps
 for the sake of speed.  The interprocedural optimizations for both
 the fortran and c/c++ compilers make it a must.  

I would be careful about this, and this needs benchmarks, especially
with gcc  4.3. By default icc flags are fairly agressive. For example,
for many scientific applications, you don't want a simple -O2 where you
loose floating point precision. Add -mp or -mp1 to your icc flags, add
some decent gcc flags, and improvement over gcc is much smaller.
 
 5.) It's free, albeit a commercial product.  As gentoo is entirely
 non-profit, there is no restriction when it comes to licensing.  The
 binaries won't be sold for the intel-compiled livecd, and the
 compiler itself with a fetch restriction allows the user to legally
 register for their free non-commercial license.

Again, as long as you're not being compensated for doing it (for Gentoo
I'm not).

In summary, I'm completely in favor of trying projects like this, but
first, this needs a few benchmarks before going further.


- -- 
Sébastien
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiApcoACgkQ1ycZbhPLE2C0TQCfYLD2+mazHKjosK7wiHFU6FGb
d3EAnR1FWZ92O2B9xBJerCj4dj2GRUZ4
=YhT2
-END PGP SIGNATURE-
���^�X�����(��j)b�b�

Re: [gentoo-dev] Re: ICC Profile

2008-07-18 Thread Adam Stylinski
GCC 4.3 is catching up, but they are no where near utilizing SSE4 or SSE5 
instructions.  

http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html

He concludes that it's not worth pursuing, but I beg to differ.  Those are 
signifcant differences for a processor.
-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: ICC Profile

2008-07-18 Thread Nikos Chantziaras

Branko Badrljica wrote:

BTW: Is ICC really worth the fuss ?
I have checked around and reported that newest gcc-4.3 is able to to 
catch and sometimes even outperform icc ( not always, naturally).


Big news seemed to be thatnew gcc si close and sometimes better than icc.

Is it any truth to that and if it is, what is the motive of having 
non-open icc option ?


The programs where I care about speed the most are gzip, bzip2, oggenc, 
lame, x264...  I guess you get the pattern, they're 
encoders/compressors.  ICC wins in every one of them (speed increase is 
quite dramatic in the case of gzip and bzip2; 20% to 30%).  GCC won with 
diffutils though; 2% faster than ICC.


Testing other tools is difficult; how do you measure if X is faster with 
ICC?  Or KDE?  (If it even compiles with ICC; didnt' test.)


There's the issue of bugs though; programs break even with different 
versions of GCC (see Thunderbird; it breaks when compiled with *any* 
form of optimization turned on with GCC 4.3. See bugs 223375 and 
217805).  Who knows what breakage can occur with ICC.  The vast majority 
of projects out there are developed and tested only on GCC systems.


Then there's the show stopper #1 bug: every C++ source file that has an 
#include limits.h refuses to compile with ICC (at least on my system; 
AMD64).  Intel responds with use RedHat where it works, we don't 
support Gentoo.  Supporting ICC in Gentoo is probably going to be too 
difficult if Intel refuses to even try to fix bugs that don't show up in 
RedHad and Novell's enterprise SUSE.


--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] system set no longer in part of world set

2008-07-18 Thread Arfrever Frehtes Taifersar Arahesis
2008-07-18 16:01:28 Doug Goldstein napisał(a):
 Olivier Cr�te wrote:
  On Mon, 2008-07-14 at 18:01 -0400, Doug Goldstein wrote:

  This brings out the fun of circular depends. I don't really know how to 
  address this but a lot of packages are going to have to be updated to 
  contain proper depends. i.e. C based apps will need 
  RDEPEND=virtual/libc. C++ packages will need a stdc++ depend.
  
 
  Adding a dep to libc almost everywhere seems extremely wrong to me. I
  though we had decided many times that it was a bad idea.
 

 Yes. Adding libc everywhere is wrong. However, if you don't have one of 
 the packages listed here [1], your libc won't ever update.

IMHO it would be better to teach users to explicitly specify '@system' during
updates, e.g. `emerge -uDN @system @world`.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: ICC Profile

2008-07-18 Thread Ciaran McCreesh
On Fri, 18 Jul 2008 10:24:58 -0400 (EDT)
Adam Stylinski [EMAIL PROTECTED] wrote:
 GCC 4.3 is catching up, but they are no where near utilizing SSE4 or
 SSE5 instructions.  
 
 http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html
 
 He concludes that it's not worth pursuing, but I beg to differ.
 Those are signifcant differences for a processor.

He doesn't establish whether the code in question is highly cpu-bound
or not when run on his system. For a lot of memory- and i/o-bound code,
there's little practical difference between gcc with optimisations
turned off and gcc with -frice-my-shorts except that the former
compiles an order of magnitude faster.

The more interesting question, then, is whether users run any
non-trivial cpu-bound programs. We know the applied science types do,
but they tend to be the ones who're doing clever things with icc
anyway. What about normal users?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: ICC Profile

2008-07-18 Thread Adam Stylinski
He's also doing it on a core 2 duo.  It would be interesting to compare this 
with some mildly legacy hardware (netburst pipelines) in order to see whether 
GCC does a comparable job.  My guess would be no, seeing as netburst was 
extremely ugly and complicated, only intel would be able to write a compiler 
that took advantage of it.  
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] system set no longer in part of world set

2008-07-18 Thread Richard Freeman

Doug Goldstein wrote:


  
Yes. Adding libc everywhere is wrong. However, if you don't have one of 
the packages listed here [1], your libc won't ever update.




Sure it will.  When the version of libc you have installed is removed 
from the portage tree you'll get bumped to the most recent version 
(stable/testing as appropriate).


Works fine for me.  I generally don't care if I'm running an older 
version of libc.  If something requires a particular version it will 
have a dependency and will pull it in.


--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] system set no longer in part of world set

2008-07-18 Thread Robert Bridge
On Fri, 18 Jul 2008 16:30:20 +0200
Arfrever Frehtes Taifersar Arahesis [EMAIL PROTECTED] wrote:

 IMHO it would be better to teach users to explicitly specify
 '@system' during updates, e.g. `emerge -uDN @system @world`.

Why not just re-instate the implicit dependency of world on system?

Rob.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] ICC Profile

2008-07-18 Thread Robert Bridge
On Fri, 18 Jul 2008 15:16:18 +0100
Sébastien Fabbro [EMAIL PROTECTED] wrote:

 There was some attempts a few years ago for rolling up a full Gentoo
 with icc, but it hit several problems if I recall. Now both icc and
 gcc have improved since then.

Including needing package specific CFLAGS because some packages in
@system needed mutually exclusive flag settings. 

I'll see if I can dig up the link for an old blog on the topic later.
--
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] strange portage behaviour

2008-07-18 Thread Alin Năstac
Portage no longer install ._cfg_* files for the CONFIG_PROTECTed 
files touched by the user. Even if I remove the package and reinstall it 
again, the protected file will remain like it is.


Can someone enlighten me?



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] ICC Profile

2008-07-18 Thread Adam Stylinski
Also, in the academic environment the grad student/university can pay for the 
license that the student slipstreams into their gentoo installation, making it 
100% legal depending on how many seats he or she buys.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: ICC Profile

2008-07-18 Thread Richard Freeman

Ciaran McCreesh wrote:


The more interesting question, then, is whether users run any
non-trivial cpu-bound programs. We know the applied science types do,
but they tend to be the ones who're doing clever things with icc
anyway. What about normal users?



I'm sure they do on some occasion if they encode compressed audio/video, 
or when compressing data with zip/etc.  That is probably the biggest 
application of cpu-bound software.


Personally, I use -Os across the board when it doesn't break.  As you 
said I tend to be memory/IO bound, and optimizing for size helps with 
both (swapping causes IO).  I'd probably benefit from using -O3 on the 
aforementioned CPU-intensive apps.

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: ICC Profile

2008-07-18 Thread Ciaran McCreesh
On Fri, 18 Jul 2008 15:34:53 -0400
Richard Freeman [EMAIL PROTECTED] wrote:
 Ciaran McCreesh wrote:
  The more interesting question, then, is whether users run any
  non-trivial cpu-bound programs. We know the applied science types
  do, but they tend to be the ones who're doing clever things with icc
  anyway. What about normal users?
 
 I'm sure they do on some occasion if they encode compressed
 audio/video, or when compressing data with zip/etc.  That is probably
 the biggest application of cpu-bound software.

How much of that is memory bound? Of the things that aren't, how many
aren't written in assembly anyway? Of those things, what proportion of
the runtime is spent in those areas?

If you double the speed of something that takes up 2% of the overall
execution time, you can't measure the improvement.

Or looking at it the other way -- is there any reason to believe that
using icc (which can end up being a substantial pain in the arse, given
the way it tries to use gcc's c++ headers but doesn't support some of
the extensions or quirks that g++ does) will provide a genuine gain
for people who aren't already doing clever profile-directed trickery
anyway?

 I'd probably benefit from using -O3 on the aforementioned
 CPU-intensive apps.

The problem with -O3 is that function inlining can lead to a
substantial cache hit. Unless you're using profile-directed
optimisations, which Gentoo doesn't support, it's extremely hit and
miss as to whether O3 helps or hurts.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: ICC Profile

2008-07-18 Thread Richard Freeman

Ciaran McCreesh wrote:


How much of that is memory bound? Of the things that aren't, how many
aren't written in assembly anyway? Of those things, what proportion of
the runtime is spent in those areas?

If you double the speed of something that takes up 2% of the overall
execution time, you can't measure the improvement.

Or looking at it the other way -- is there any reason to believe that
using icc (which can end up being a substantial pain in the arse, given
the way it tries to use gcc's c++ headers but doesn't support some of
the extensions or quirks that g++ does) will provide a genuine gain
for people who aren't already doing clever profile-directed trickery
anyway?


The problem with -O3 is that function inlining can lead to a
substantial cache hit. Unless you're using profile-directed
optimisations, which Gentoo doesn't support, it's extremely hit and
miss as to whether O3 helps or hurts.



I agree with all of the above.   Gentoo is about choice, so if people 
want to make ICC work well more power to them.  I agree that it would be 
hard to make it THE ONLY system compiler.  For those who do try it I'd 
be really interested in their findings.

--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: ICC Profile

2008-07-18 Thread Adam Stylinski
Perhaps we could write a script that compiles packages in portage with both ICC 
and GCC and runs them with different flags.  I think there was an effort on the 
GCC side already to test flags with specific packages.  We can then have the 
script run time on the applications doing work (again, that's a lot of packages 
for a lot of different tasks).  If we can store these in the portage tree (yes, 
it's more metadata), the user can actually benefit well from the optimizations.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] strange portage behaviour

2008-07-18 Thread Zac Medico
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alin Năstac wrote:
 Portage no longer install ._cfg_* files for the CONFIG_PROTECTed
 files touched by the user. Even if I remove the package and reinstall it
 again, the protected file will remain like it is.
 
 Can someone enlighten me?
 

It's common for people get get confused like this by the confmem
behavior that's built into portage's merge process. You can use
- --noconfmem to disable it.

In newer versions of portage (those not marked stable yet),
uninstalling a package or downgrading it will automatically trigger
behavior like --noconfmem [1], so hopefully this will help to avoid
some confusion in the future.

Zac

[1] http://sources.gentoo.org/viewcvs.py/portage?rev=10250view=rev
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiBG1oACgkQ/ejvha5XGaNf6wCeNZXwZdByfP3pZ2pVoyLh5kYh
NqEAn0JddFw6y833/sXrUz2E+O+HQ+ar
=7QCy
-END PGP SIGNATURE-
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] system set no longer in part of world set

2008-07-18 Thread Marius Mauch
On Fri, 18 Jul 2008 10:01:28 -0400
Doug Goldstein [EMAIL PROTECTED] wrote:

 Olivier Crête wrote:
  On Mon, 2008-07-14 at 18:01 -0400, Doug Goldstein wrote:

  This brings out the fun of circular depends. I don't really know
  how to address this but a lot of packages are going to have to be
  updated to contain proper depends. i.e. C based apps will need 
  RDEPEND=virtual/libc. C++ packages will need a stdc++ depend.
  
 
  Adding a dep to libc almost everywhere seems extremely wrong to me.
  I though we had decided many times that it was a bad idea.
 

 Yes. Adding libc everywhere is wrong. However, if you don't have one
 of the packages listed here [1], your libc won't ever update.

Now that's a big exaggeration. It _might_ be missing from world updates
(there are still many cases where it will be included), but that's not
the only available operation in portage.

Marius
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] system set no longer in part of world set

2008-07-18 Thread Marius Mauch
On Fri, 18 Jul 2008 16:21:24 +0100
Robert Bridge [EMAIL PROTECTED] wrote:

 On Fri, 18 Jul 2008 16:30:20 +0200
 Arfrever Frehtes Taifersar Arahesis [EMAIL PROTECTED] wrote:
 
  IMHO it would be better to teach users to explicitly specify
  '@system' during updates, e.g. `emerge -uDN @system @world`.
 
 Why not just re-instate the implicit dependency of world on system?

Because that doesn't actually fix the problem, it just covers it up to
some degree (there has never been a guarantee that system is
actually satisifed when you install a package). Also the new solution is
more flexible as it still allows you to include system in world easily,
or update/rebuild system and world separately. And for a full system
updates there is a new target available that actually includes all
installed packages.
Yes, this is going to require some user reeducation, and yes, this will
take some time, but it isn't as dramatic as some people make it. The
whole implicit-system-dependency thing has never existed, it was
always a broken assumption that only didn't blow up badly because a) the
system target rarely changes b) most packages only depend on a tiny
part of system and c) most users actually do full system updates
regulary.
As soon as you want to install a package that actually implicitly
depends on something in system that isn't already installed the whole
thing breaks down.

Marius
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: auto-detection of unpack dependencies

2008-07-18 Thread Petteri Räty

Marius Mauch kirjoitti:


If someone wants to use it I can add it on the tree (after the normal
review process and being better tested), but I'll only be doing it
when there is an actual demand for it (no point in adding an eclass that
nobody uses).



I have been long thinking about adding support for .zip handling to java 
eclasses so let's get this in and it will get a user from java-pkg-2 and 
java-pkg-opt-2 eclasses at least.


Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: IBM article of interest ?

2008-07-18 Thread Ryan Hill
On Thu, 17 Jul 2008 11:20:15 -0400
Philip Webb [EMAIL PROTECTED] wrote:

 080717 Jeremy Olexa wrote:
  Philip Webb wrote:
  [2] http://www.ibm.com/developerworks/linux/library/l-awk1.html
  '03 Jul 2008' has been added since I sent my comment to them
  yesterday ! However, the incorrect URL for Gentoo Technologies --
  www.gentoo.org -- is still there, probably because I didn't
  mention it in my comment, so I'll try sending them another.
  I don't know all the details or the 'proper' way to handle
  what you are doing. But I wanted to say thanks for spending time on
  this.
 
 Thanks (big smile) !  It's good to have a bit of encouragement.
 
 There's really no more to say here: my initial message was about IBM
  I reacted as might any casual reader of their page,
 wondering why they were including 8-year-old information re its
 author. I did not remember that it was also included in Gentoo docs,
 but now do.
 
 It's clear to me by now that Gentoo does the correct  sensible thing:
 reproduce the original as it was in 2000 with a prominent disclaimer.
 It's IBM which is not doing that  needs prodding: I've sent another
 comment.

Are you high?  The article was written in 2000.  It says so at the
beginning.  The information in the article pertains to that time.  You
don't go updating every article you publish every time the author's
personal details change.

Please leave IBM alone.  They were nice enough to allow us to reprint
the content of several articles written by Daniel.


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


signature.asc
Description: PGP signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: mozcoreconf-2.eclass

2008-07-18 Thread Ryan Hill
On Fri, 18 Jul 2008 17:55:00 +
Raul Porcel (armin76) [EMAIL PROTECTED] wrote:

 armin76 08/07/18 17:55:00
 
   Modified: mozcoreconf-2.eclass
   Log:
   Enable by default mozilla's optimization

 +IUSE=${IUSE} custom-optimization
 +

Could you use custom-cflags for this instead?


[EMAIL PROTECTED] ~ $ grep cflag /usr/portage/profiles/use.local.desc

app-crypt/johntheripper:custom-cflags - Enables custom cflags (not supported)
app-emulation/hercules:custom-cflags - Use CFLAGS from /etc/make.conf rather 
than the default package CFLAGS (not supported)
app-emulation/xen-tools:custom-cflags - Use CFLAGS from /etc/make.conf rather 
than the default Xen CFLAGS (not supported)
app-emulation/xen:custom-cflags - Use CFLAGS from /etc/make.conf rather than 
the default Xen CFLAGS (not supported)
games-emulation/zsnes:custom-cflags - Enables custom cflags (not supported)
media-libs/libsdl:custom-cflags - Allow users to use any CFLAGS they like 
completely (at their own risk)
media-video/mplayer:custom-cflags - Enables custom CFLAGS (UNSUPPORTED)
sys-boot/grub:custom-cflags - Enables custom cflags (not supported)
x11-drivers/nvidia-drivers:custom-cflags - Build with CFLAGS from 
/etc/make.conf (unsupported)


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


signature.asc
Description: PGP signature


[gentoo-dev] Re: system set no longer in part of world set

2008-07-18 Thread Ryan Hill
On Mon, 14 Jul 2008 18:01:23 -0400
Doug Goldstein [EMAIL PROTECTED] wrote:

 With the new split in Portage where system set packages are not 
 considered in an emerge -auDNv world unless something in world 
 RDEPENDs on it brings about a few issues.

Just curious, what are the benefits of not having world include system?


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


signature.asc
Description: PGP signature


[gentoo-dev] Re: system set no longer in part of world set

2008-07-18 Thread Ryan Hill
On Fri, 18 Jul 2008 23:13:01 -0600
Ryan Hill [EMAIL PROTECTED] wrote:

 Just curious, what are the benefits of not having world include
 system?

Nevermind, I just found your post explaining this.

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


signature.asc
Description: PGP signature


[gentoo-portage-dev] [RFC/PATCH] New objects cpv, pv and version to be used instead of raw strings.

2008-07-18 Thread Ali Polatel
Hi,
Attached patch adds objects cpv, pv and version to portage.versions. This is
meant as a thin layer over functions vercmp(), pkgcmp(), pkgsplit() and
catpkgsplit().
Using these objects instead of the mentioned functions allows us to write
cleaner code and remove deprecated stuff like:
list.sort(pkgcmp)
which won't exist in py3k.

Please comment.

---
 pym/portage/versions.py |  292 +--
 1 files changed, 256 insertions(+), 36 deletions(-)

diff --git a/pym/portage/versions.py b/pym/portage/versions.py
index 261fa9d..20b0d4f 100644
--- a/pym/portage/versions.py
+++ b/pym/portage/versions.py
@@ -4,6 +4,7 @@
 # $Id$
 
 import re
+import warnings
 
 ver_regexp = 
re.compile(^(cvs\\.)?(\\d+)((\\.\\d+)*)([a-z]?)((_(pre|p|beta|alpha|rc)\\d*)*)(-r(\\d+))?$)
 suffix_regexp = re.compile(^(alpha|beta|rc|pre|p)(\\d*)$)
@@ -12,6 +13,205 @@ endversion_keys = [pre, p, alpha, beta, rc]
 
 from portage.exception import InvalidData
 
+# builtin all() is new in Python-2.5
+# TODO Move compatibility stuff to a new module portage.compat
+# and import from it like from portage.compat import all
+from sys import hexversion
+if hexversion  0x0205:
+def all(iterable):
+for i in iterable:
+if not bool(i):
+return False
+return True
+del hexversion
+
+def needs_version(func):
+   Decorator for functions that require non-keyword arguments of type 
version.
+   def func_proxy(*args, **kwargs):
+   if not all([isinstance(arg, version) for arg in args]):
+   raise TypeError(Not all non-keyword arguments are of 
type version)
+   return func(*args, **kwargs)
+   func_proxy.__doc__ = func.__doc__
+   return func_proxy
+
+def needs_pv(func):
+   Decorator for functions that require non-keyword arguments of type 
pv.
+   def func_proxy(*args, **kwargs):
+   if not all([isinstance(arg, pv) for arg in args]):
+   raise TypeError(Not all non-keyword arguments are of 
type pv)
+   return func(*args, **kwargs)
+   func_proxy.__doc__ = func.__doc__
+   return func_proxy
+
+def needs_cpv(func):
+   Decorator for functions that require non-keyword arguments of type 
cpv.
+   def func_proxy(*args, **kwargs):
+   if not all([isinstance(arg, cpv) for arg in args]):
+   raise TypeError(Not all non-keyword arguments are of 
type cpv)
+   return func(*args, **kwargs)
+   func_proxy.__doc__ = func.__doc__
+   return func_proxy
+
+class version(str):
+   Represents a package version
+
+   __hash = None
+   __parts = ()
+   __str = 
+
+   def __new__(cls, value):
+   m = ver_regexp.match(value)
+   if m is None:
+   raise TypeError(Syntax error in version: %s % value)
+   else:
+   new_ver = str.__new__(cls, m.groups())
+   new_ver.__hash = hash(m.groups()) + hash(value)
+   new_ver.__parts = m.groups()
+   new_ver.__str = value
+
+   return new_ver
+
+   def __str__(self):
+   return self.__str
+
+   def __repr__(self):
+   return %s object at 0x%x: %s % (self.__class__.__name__,
+   id(self), self.__str)
+
+   def __hash__(self):
+   return self.__hash
+
+   def __getitem__(self, i):
+   return self.__parts[i]
+
+   def __getslice__(self, i, j):
+   return self.__parts[i:j]
+
+   def __len__(self):
+   return len(self.__parts)
+
+   @needs_version
+   def __cmp__(self, y):
+   return vercmp(self, y)
+
+   @needs_version
+   def __eq__(self, y):
+   return vercmp(self, y) == 0
+
+   @needs_version
+   def __ne__(self, y):
+   return vercmp(self, y) != 0
+
+   @needs_version
+   def __lt__(self, y):
+   return vercmp(self, y)  0
+
+   @needs_version
+   def __le__(self, y):
+   return vercmp(self, y) = 0
+
+   @needs_version
+   def __gt__(self, y):
+   return vercmp(self, y)  0
+
+   @needs_version
+   def __ge__(self, y):
+   return vercmp(self, y) = 0
+
+class pv(str):
+   Represents a pv
+
+   __hash = None
+   __parts = ()
+   __str = 
+
+   def __new__(cls, value):
+   parts = pkgsplit(value)
+   if parts is None:
+   # Ideally a TypeError should be raised here.
+   # But to fit code using this easily, fail silently.
+   return None
+   else:
+   new_pv = str.__new__(cls, parts)
+   new_pv.__hash = hash(parts) + hash(value)
+   new_pv.__parts = (parts[0], 

Re: [gentoo-portage-dev] [RFC/PATCH] New objects cpv, pv and version to be used instead of raw strings.

2008-07-18 Thread René 'Necoro' Neumann
On Fri, 18 Jul 2008 12:41:52 +0300, Ali Polatel [EMAIL PROTECTED] wrote:
 Hi,
 Attached patch adds objects cpv, pv and version to portage.versions. This
 is
 meant as a thin layer over functions vercmp(), pkgcmp(), pkgsplit() and
 catpkgsplit().
 Using these objects instead of the mentioned functions allows us to write
 cleaner code and remove deprecated stuff like:
 list.sort(pkgcmp)
 which won't exist in py3k.
 
 Please comment.

Is there a reason, why you are using __new__ instead of __init__?

Regards,
René

-- 
gentoo-portage-dev@lists.gentoo.org mailing list



[gentoo-portage-dev] Re: [RFC/PATCH] New objects cpv, pv and version to be used instead of raw strings.

2008-07-18 Thread Ali Polatel
René 'Necoro' Neumann yazmış:
 On Fri, 18 Jul 2008 12:41:52 +0300, Ali Polatel [EMAIL PROTECTED] wrote:
  Hi,
  Attached patch adds objects cpv, pv and version to portage.versions. This
  is
  meant as a thin layer over functions vercmp(), pkgcmp(), pkgsplit() and
  catpkgsplit().
  Using these objects instead of the mentioned functions allows us to write
  cleaner code and remove deprecated stuff like:
  list.sort(pkgcmp)
  which won't exist in py3k.
  
  Please comment.
 
 Is there a reason, why you are using __new__ instead of __init__?

__new__ is about object creation and the __new__ methods of these
objects create the objects from raw strings.

__init__ is for initializing and customizing objects and that method
is for application writers who want to customize these objects to suit
their needs.

 
 Regards,
 René
 
 
-- 
Regards,
Ali Polatel


pgpd2HlXjRUEi.pgp
Description: PGP signature


[gentoo-portage-dev] Sue Gitzlaff/Northcentral Technical College is out of the office.

2008-07-18 Thread Sue Gitzlaff/Northcentral Technical College

I will be out of the office starting  06/09/2008 and will not return until
08/04/2008.

I will be out of the office until August 4, 2008.  If you need assistance,
please contact Michelle Behm, Ext. 1266 or Shawn Sullivan, Ext. 1267.
Otherwise, I will respond to your message when I return.

-- 
gentoo-portage-dev@lists.gentoo.org mailing list