Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: Re: KDE 3.5.2-r1 emerged Issue!
Date: Sat, 13 May 2006 09:44:45
Message-Id: e449jg$hig$1@sea.gmane.org
In Reply to: Re: [gentoo-amd64] Re: KDE 3.5.2-r1 emerged Issue! by Christopher E
1 "Christopher E" <sensory.access@×××××.com> posted
2 184c54640605121306u43e268fbhb5640ada1c584c9c@××××××××××.com, excerpted
3 below, on Fri, 12 May 2006 16:06:45 -0400:
4
5 >> Q: What is wrong with top posting, bottom quoting.
6 >
7 > I don't know what top posting is, so I am sorry if I am doing it. ok I
8 > may know what ist is but I am not sure. Is it when posting above a
9 > quoting area?
10
11 Yes. Altho the vast majorities of AOLer net newbies have pretty much
12 overwhelmed the traditionalists, the way most folks who've been on lists
13 and newsgroups for awhile prefer it is to quote the point you are replying
14 to (not the whole post, particularly if it's long, just the single point),
15 then type your reply within that context. Then if you have another point
16 to reply to, you quote it, and reply to it. The idea is that you never
17 quote a huge block (more than a page) at once (if you are replying to a
18 general point in a huge block, it's best to try summarizing it), so
19 there's always some of your reply visible, it's never a whole page of
20 quoted text. Of course, some folks have larger display pages than others,
21 but that's the idea.
22
23 What happens is that the effort of figuring out what point you are
24 replying to and editing the quote to that, often makes your reply clearer
25 than it would be otherwise. It's also much clearer what point you were
26 intending to reply to, than if you'd simply replied at the top and left
27 the entire multi-page multi-point previous post intact at the bottom.
28
29 This post was a good example of how to do it right. The previous post,
30 well, lets just say it made things frustrating for me, as I would have
31 liked to include a bit of the grandparent post as well, for context, and
32 the way it was, had I done that it would have been out of order and rather
33 more confusing to follow, so I just left it out.
34
35 >> Have you ensured that you have the latest gentoolkit? A version not long
36 >> ago had a bug that caused it to skip some stuff on amd64.
37 >>
38 >> My current version (~arch): gentoolkit-0.2.2_pre4
39 >
40 > Yes I went and emerged it today with the accept keyword ~amd64 thing
41 > in my make.conf file. I am still waiting for the kdelibs ... to
42 > finish compiling as its taking for ever. it did the fist 8 depencies I
43 > would say much fast then the last one with would be the kdelibs ...
44 > one
45
46 Good. It seems to be working better then. You must have had the bad one.
47
48 As for kdelibs, yes, it's a very big compile. If you think about it,
49 it's actually the equivalent of about 10-20 regular sized packages, all
50 rolled up into one, because they are all general KDE libraries assumed to
51 be on any KDE system by any KDE app, so they all have to be merged anyway,
52 and due to the interdependedness -- the build process builds part of one,
53 as necessary to build part of a second component, which is necessary to
54 build a third component, which is necessary to finish building the first
55 component. Thus, it'd be very difficult if not impossible to separate
56 them effectively, and since they are all needed anyway, they might as well
57 just be built together. So yes, it's a huge compile that takes quite some
58 time, but when you think of it as the roughly 20 regular packages all
59 rolled into one that it effectively is, it doesn't seem so bad, after all.
60
61 Of course, making all this worse is the fact that g++ works much harder to
62 compile C++ than gcc has to, to compile C. That's because it takes fewer
63 lines in C++ to program the same stuff, yet g++ compiles it to code of
64 roughly the same performance. If 10 lines of C++ does the same as 20
65 lines of C, resulting in native binary code of the same efficiency, then
66 g++ will have to work twice as hard to do it as the C compiler part of
67 gcc. That's why C++ based packages require so much more memory and time
68 for gcc/g++ to compile than C based packages. The tradeoff is basically
69 that it's easier to program in C++, making the programmer more efficient,
70 at the expense of making the compiler do all the work that the programmer
71 was able to skip.
72
73
74
75 --
76 Duncan - List replies preferred. No HTML msgs.
77 "Every nonfree program has a lord, a master --
78 and if you use the program, he is your master." Richard Stallman
79
80 --
81 gentoo-amd64@g.o mailing list

Replies

Subject Author
Re: [gentoo-amd64] Re: Re: KDE 3.5.2-r1 emerged Issue! Paul de Vrieze <pauldv@g.o>