Daniel Berlin <[EMAIL PROTECTED]> writes:
[...]
| So i guess the first decision is "do we want to stay with cvs forever,
| or move to something different that has some advantages and some
| disadvantages for most people, and very large advantages for some
| people."
|
| This *really* is the main
Hi,
I just wanted to know what's the state of the gomp branch w.r.t
bug reports. Does it make sense to already send bug reports to
you or even add them to bugzilla?
We've got a large C++ application that uses OpenMP and we are really
interested in getting gomp work.
Here's one bug for starters:
uses "CVS" for mainline most people people can check out; it uses
"arch" for manging branches where developers do experiments.
I found arch very interesting, and I am using it for GNU sed and GNU
Smalltalk. I liked very much the idea of working offline, and the very
small requirements that
On 20 Oct 2005 08:58:36 +0200, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
>
> | Re: moving to subversion
> |
> | On Wed, Oct 19, 2005 at 12:19:52PM -0700, Mark Mitchell wrote:
> | > We've discussed this extensively at CodeSourcery, and I think everyone
> | >
Quoting steven at gcc dot gnu dot org <[EMAIL PROTECTED]>:
> --- Comment #5 from steven at gcc dot gnu dot org 2005-10-19 13:13
> ---
> That patch is yet another example of why we constantly keep having compile
> time
> problems. Just add more, and more, and more, and more. And act surp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arnaud Charlet wrote:
>
> Also, I guess that would mean having 8.5 gigs dedicated
> to the GCC rep (without talking about the check outs and builds) on
> my machine. I know that disk space is cheap, but I would need to build a
> new laptop or reformat
> 8.5G seems to be the space needed on the server, *not*
> on your local machine.
I believe you are confused: I was talking about a svk set up (as suggested
by the author of the email I was responding to) with a local
mirror of the repository in this message. 8.5G is for the local mirror,
it is no
Richard Guenther wrote:
>If it is at all possible we should probably try to keep read-only CVS working
>(and up-to-date) for HEAD and release-branches. This will allow occasional
>contributors and technically-less-provided people to continue working in
>submit-patch mode or in regular testing wit
> > Well, I haven't tried it myself yet, so what I'm going by is hearsay but
> > I do share the concern that it's looking like this is a change that may
> > make the common things harder and slower in order to make the less common
> > operations faster and/or easier. If so, that may not be the rig
> Irrespective of the other issues currently discussed, this is a very
> good idea!
Seconded!
--
Eric Botcazou
On Thu, 2005-10-20 at 09:58, Arnaud Charlet wrote:
> I was talking about a svk set up (as suggested
> by the author of the email I was responding to) with a local
> mirror of the repository in this message. 8.5G is for the local mirror,
> it is not (even) counting the check out which does take almo
On Oct 20, 2005 10:45 AM, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> I got following times:
>
> 1m37.986
> 1m37.139
> 1m38.410
>
> And _with_ patch:
>
> 1m37.264
> 1m37.352
> 1m37.383
>
> I would say that the difference is burried in noise.
It is still an extra pass over all instructions in the func
On Thu, 20 Oct 2005, Richard Guenther wrote:
> If it is at all possible we should probably try to keep read-only CVS working
> (and up-to-date) for HEAD and release-branches. This will allow occasional
> contributors and technically-less-provided people to continue working in
> submit-patch mode
On Oct 20, 2005 11:01 AM, Eric Botcazou <[EMAIL PROTECTED]>
wrote:
> - portability of svn to non-Linux systems
http://subversion.tigris.org/faq.html#portability
Gr.
Steven
On 10/20/05, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Thu, 20 Oct 2005, Richard Guenther wrote:
>
> > If it is at all possible we should probably try to keep read-only CVS
> > working
> > (and up-to-date) for HEAD and release-branches. This will allow occasional
> > contributors and techni
Eric Botcazou <[EMAIL PROTECTED]> wrote:
> I've never created/managed branches or tagged anything in the GCC
> tree. The important things to me are:
>
> - time to do a complete check-out on mainline/branch
Check-out is 30% slower because of the time needed to write the duplicate local
copy. On t
A few comments, since your message makes it sound like everything is
better, which is not true in reality.
> > - time to do a diff on mainline/branch
>
> "svn diff" is a disconnected operation, requires no server access, so it takes
> milliseconds. "cvs diff" is dominated by network connection, s
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> I'm looking forward to solutions that lower the entry barrier,
> specifically with repect too OpenSSH, diff and svk.
I'm going to write something in the wiki about svk. There's much FUD spreading
in this thread.
DanJ put up a wiki page on the OpenSSH
Giovanni Bajo writes:
> Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
>
> > I'm looking forward to solutions that lower the entry barrier,
> > specifically with repect too OpenSSH, diff and svk.
>
>
> I'm going to write something in the wiki about svk. There's much FUD
> spreading
> in t
Arnaud Charlet <[EMAIL PROTECTED]> wrote:
>>> - portability of svn to non-Linux systems
>>
>> This has been answered already. It should not be an issue.
>
> Note that I found it a real pain to have to install so much
> dependency package on my linux system, so I suspect building the
> whole depend
> DanJ put up a wiki page on the OpenSSH configuration (which really could be
> found with 3 minutes of googling, which is shorter than writing a mail asking
> information about it [not speaking of you, gaby]).
Well, with all your respect, you seem to be living in a different world than
mine.
In
On Thu, Oct 20, 2005 at 09:17:02AM +0200, Volker Reichelt wrote:
> I just wanted to know what's the state of the gomp branch w.r.t
> bug reports. Does it make sense to already send bug reports to
> you or even add them to bugzilla?
I think so. We are getting near the point where we're looking
for
On 10/20/05, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Eric Botcazou <[EMAIL PROTECTED]> wrote:
>
> > I've never created/managed branches or tagged anything in the GCC
> > tree. The important things to me are:
> >
> > - time to do a complete check-out on mainline/branch
>
> Check-out is 30% slowe
On 2005-10-20, at 11:45, Arnaud Charlet wrote:
Note that I found it a real pain to have to install so much
dependency package
on my linux system, so I suspect building the whole dependency
packages under
non linux systems might be slghtly of a pain.
This is not the case. This is only due t
On Oct 20, 2005 12:11 PM, Arnaud Charlet <[EMAIL PROTECTED]> wrote:
> And maybe if svn 1.4 will improve such important improvements, it
> would
> be a good idea to wait till svn 1.4 is outt so that people do not have
> to
> upgrade multiple times to get "the expected" behavior.
By then, I'm sure,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arnaud Charlet wrote:
>
> In your world, everyone has an up-to-date version of every tool,
> and have e.g. the latest OpenSSH and subversion clients installed
> on his machine. In mine, this is clearly far from being the case:
> no svn installed, and
Since there is a big brainstorming, I will sum up my opinion here (and
then stop spending time on this issue). From the discussion, it looks
like the switch seems the most important constraint imposed by the switch
is about hardware/software requirements, and I do strongly second this
point.
For e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Giovanni Bajo wrote:
[...]
>>- time to do an update on mainline/branch
>
>
> When updating, cvs/svn first try to find out what needs to be updated (in
> rough
> terms) and then start downloading the updates. The latter part (download) is
> obviously
On 10/20/05, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
> Since there is a big brainstorming, I will sum up my opinion here (and
> then stop spending time on this issue). From the discussion, it looks
> like the switch seems the most important constraint imposed by the switch
> is about har
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
[...]
| Even if we assume that it's impossible to upgrade OpenSSH on a given platform
| for some weird reason,
I appreciate your effort in this, but I strongly suggest that you
refrain from calling reasons why people can't install the latest
versions
On Thu, 2005-10-20 at 11:51 +0200, Giovanni Bajo wrote:
> Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
>
> > I'm looking forward to solutions that lower the entry barrier,
> > specifically with repect too OpenSSH, diff and svk.
>
>
> I'm going to write something in the wiki about svk. There's muc
On Thu, 2005-10-20 at 12:11 +0200, Arnaud Charlet wrote:
> Same for saying "this will be improved in the next version of svn".
> It is assuming that upgrading versions of svn clients for people is a no
> cost operation, which is again not the case in practice.
>
> And maybe if svn 1.4 will improv
| Even if we assume that it's impossible to upgrade OpenSSH on a given platform
| for some weird reason,
I appreciate your effort in this, but I strongly suggest that you
refrain from calling reasons why people can't install the latest
versions of supporting tools "weird".
I agree. For examp
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
>> Even if we assume that it's impossible to upgrade OpenSSH on a given
>> platform for some weird reason,
>
> I appreciate your effort in this, but I strongly suggest that you
> refrain from calling reasons why people can't install the latest
> versions
Daniel Berlin <[EMAIL PROTECTED]> writes:
[...]
| I have absolutely no reason to expect the feedback process to change if
| we waited. I have absolutely no reason to believe this won't happen
| again when svn 1.4 comes out.
So why are people asked to voice their opinions if there is so much
dis
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
[...]
| In other words, what I see mostly in this thread is that people are worried
| because of what we usually call "micro-benchmarks" (e.g. "raw cvs diff time
| for a single time across two revisions"),
People have been asked to voice their concerns
* Daniel Berlin:
> You could simply do non-recursive checkouts (svn co -N) of the dirs you
> want.
> SVN doesn't care how you piece together the working copy.
Doesn't "commit -N" cause the working copy to become fragmented, so
that you cannot issue a working-copy-wide commit or diff anymore?
On Thu, Oct 20, 2005 at 12:11:20PM +0200, Arnaud Charlet wrote:
> > DanJ put up a wiki page on the OpenSSH configuration (which really could be
> > found with 3 minutes of googling, which is shorter than writing a mail
> > asking
> > information about it [not speaking of you, gaby]).
>
> Well, wi
On Thu, 2005-10-20 at 14:09 +0200, Gabriel Dos Reis wrote:
> "Giovanni Bajo" <[EMAIL PROTECTED]> writes:
>
>
> [...]
>
> | Even if we assume that it's impossible to upgrade OpenSSH on a given
> platform
> | for some weird reason,
>
> I appreciate your effort in this, but I strongly suggest tha
> I'd also remember that this issue (diff of a single file across SSH being
> slower) can be fixed by either an OpenSSH upgrade (which should be flawless
> in many cases), or a svn:// readonly access (which I still have to
> understand if it can be done),
svn:// readonly access is up and running
Daniel Berlin <[EMAIL PROTECTED]> writes:
| > | the problem is probably going to be fixed by SVN 1.4 and
| > | the new svn+ssl:// protocol. Meanwhile, unlucky people will have to live
with a
| > | slower "svn diff -rR1 -rR2" remote operation. Sorry about that, but let's
not
| > | remember of the
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
[...]
| I think that
| was a good choice; I'm sorry that people are crawling out from
| every which way now to object to the entire idea.
I haven't seen people object to the idea of moving away
On Thu, Oct 20, 2005 at 02:47:19PM +0200, Florian Weimer wrote:
> * Daniel Berlin:
>
> > You could simply do non-recursive checkouts (svn co -N) of the dirs you
> > want.
> > SVN doesn't care how you piece together the working copy.
>
> Doesn't "commit -N" cause the working copy to become fragmen
Daniel Berlin wrote:
I'd also remember that this issue (diff of a single file across SSH being
slower) can be fixed by either an OpenSSH upgrade (which should be flawless
in many cases), or a svn:// readonly access (which I still have to
understand if it can be done),
svn:// readonly acc
Joseph S. Myers wrote:
> I don't think keeping the CVS repository up to date after the move to
> subversion is worthwhile
I agree.
I think that keeping CVS up-to-date is not a good use of resources; when
we switch, we switch. If for some reason we have to switch back, we
switch back. Let's no
I'm going to write something in the wiki about svk. There's much FUD
spreading in this thread. DanJ put up a wiki page on the OpenSSH
configuration (which really could be found with 3 minutes of googling,
which is shorter than writing a mail asking information about it [not
spe
Sorry about that, but let's not remember of the other dozens which
works on branches and can do a merge in seconds instead of literally
*hours*, and so on.
Yes, but how often do even those who work on branches a lot do merges?
If not very often, why not just start it up, background it,
Hi,
I've got an ICE during glibc build with the current mainline on
sh4-unknown-linux-gnu:
../sysdeps/ieee754/flt-32/k_rem_pio2f.c: In function '__kernel_rem_pio2f':
../sysdeps/ieee754/flt-32/k_rem_pio2f.c:213: internal compiler error:
Segmentation fault
It doesn't fail with 20051003 compiler.
Richard Kenner <[EMAIL PROTECTED]> wrote:
> Sorry about that, but let's not remember of the other dozens which
> works on branches and can do a merge in seconds instead of literally
> *hours*, and so on.
>
> Yes, but how often do even those who work on branches a lot do merges?
Less
Richard Kenner writes:
> What I keep seeing are increasingly complex solutions in order to
> keep efficiency the same as it is now. This is a very large
> distributed cost, which can't be ignored.
No, but neither should the cost be puffed up, as it is being at the
moment. SSH connection cach
Hello Steven!
> And FWIW, it is IMHO bad practice in general to just add new passes,
> instead of investigating why existing passes don't do the job and how
> they can be enhanced to do the job better.
There is no post-reload cse_condition_code_reg () pass, so perhaps we
have to add one. A cse_co
(I'm sorry that I'm breaking threading, but I don't feel to bad about this given
whom I'm replying to, it's not like I'm cutting a huge thread in two)
Richard Kenner wrote:
> I must say that I find the amount of "fiddling" and special options or
> configurations needed here very disturbing. Peop
Less often than needed or wanted, because it takes way too much time
to do one, instead of few seconds as it should. One may want to merge
a development branch every day or so, but it can't be done right now
because the overhead of the operation is too high. This causes people
t
Hello,
I'm trying to build a cross-compiler for RTEMS. Building C or C++ cross-compiler
is not a problem but building the Ada compiler does'nt work. In fact, even
building a normal compiler does'nt work at all. The main reason I found is that
the gcc driver of FreeBSD doesn't support ada and it see
Mike Stump wrote:
> On Oct 19, 2005, at 2:56 AM, François-Xavier Coudert wrote:
>
>> Or am I the only person to find that disk is expensive (or working
>> on his own hardware, maybe)?
>
>
> A checkout costs US$0.50. This is around 2.6x more expensive than a
> cvs checkout. Check around locally
Richard Guenther <[EMAIL PROTECTED]> writes:
> If it is at all possible we should probably try to keep read-only CVS working
> (and up-to-date) for HEAD and release-branches. This will allow occasional
> contributors and technically-less-provided people to continue working in
> submit-patch mode
On Thu, 2005-10-20 at 09:39 -0500, Bobby McN wrote:
> Daniel Berlin wrote:
>
> >
> Daniel, I don't have an account with the repository.
> How would I set my computer up to get the gcc code anonymously?
> All i do is compile the code to make sure it will work with i686-pc-cygwin.
> Bobby
>
You ca
On Thu, 2005-10-20 at 08:52 -0700, Ian Lance Taylor wrote:
> Richard Guenther <[EMAIL PROTECTED]> writes:
>
> > If it is at all possible we should probably try to keep read-only CVS
> > working
> > (and up-to-date) for HEAD and release-branches. This will allow occasional
> > contributors and te
On Thursday 20 October 2005 15:33, Daniel Jacobowitz wrote:
> I eagerly look forward to svn.
Yay. Agreed.
Gr.
Steven
On Oct 20, 2005, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> svn diff -r1:r2 is only slow in the very small diff case, where ssh
> handshake time dominates the amount of data to be transferred.
And then, cvs diff -r1 -r2 also requires a ssh handshake, so I don't
get what it is that people have bee
On Thursday 20 October 2005 16:57, Richard Kenner wrote:
> Sorry about that, but let's not remember of the other dozens which
> works on branches and can do a merge in seconds instead of literally
> *hours*, and so on.
>
> Yes, but how often do even those who work on branches a lot do m
On 2005-10-20, at 16:57, Richard Kenner wrote:
Sorry about that, but let's not remember of the other dozens which
works on branches and can do a merge in seconds instead of
literally
*hours*, and so on.
Yes, but how often do even those who work on branches a lot do merges?
If no
Frédéric PRACA wrote:
Hello,
I'm trying to build a cross-compiler for RTEMS. Building C or C++ cross-compiler
is not a problem but building the Ada compiler does'nt work. In fact, even
building a normal compiler does'nt work at all. The main reason I found is that
the gcc driver of FreeBSD doesn'
Frédéric PRACA wrote:
Hello,
I'm trying to build a cross-compiler for RTEMS. Building C or C++ cross-compiler
is not a problem but building the Ada compiler does'nt work. In fact, even
building a normal compiler does'nt work at all. The main reason I found is that
the gcc driver of FreeBSD doesn'
Uros Bizjak <[EMAIL PROTECTED]> writes:
> There is no post-reload cse_condition_code_reg () pass, so perhaps we
> have to add one. A cse_condition_code_reg () walks all instructions by
> itself, so I'm not sure if some existing post-reload CSE pass could be
> enhanced.
The cse_condition_code_reg
On Thu, Oct 20, 2005 at 12:20:17PM -0400, Daniel Berlin wrote:
> On Thu, 2005-10-20 at 09:39 -0500, Bobby McN wrote:
> > Daniel Berlin wrote:
> >
> > >
> > Daniel, I don't have an account with the repository.
> > How would I set my computer up to get the gcc code anonymously?
> > All i do is compi
On Oct 20, 2005, [EMAIL PROTECTED] (Richard Kenner) wrote:
> I'm very concerned that we're greating increasing the barrier to entry for
> work on GCC. cvs is very intuitive and simple to use.
The same can be said of svn, so it's not like a great barrier increase.
> I'm not seeing the same thing
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> > I'm looking forward to solutions that lower the entry barrier,
> > specifically with repect too OpenSSH, diff and svk.
On Thu, Oct 20, 2005 at 11:51:28AM +0200, Giovanni Bajo wrote:
> I'm going to write something in the wiki about svk. There's much
On Thu, Oct 20, 2005 at 11:55:30PM +0900, Kaz Kojima wrote:
> Is it assumed that peep2_next_insn never return PEEP2_EOB in change_state?
Yes. We check peep2_current_count to validate this.
> If so, what target bug is most likely?
Dunno. This peep2_current_count is a relatively recent change.
On Thu, Oct 20, 2005 at 08:42:25AM -0400, Daniel Berlin wrote:
> So far, the feedback process has looked like:
>
> 1. I've given people months to consider the change, it's not until the
> last few days that anybody who seems to complain even bothers to try it.
It always works that way. The probl
On Thu, 2005-10-20 at 10:04 -0700, Joe Buck wrote:
> Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> > > I'm looking forward to solutions that lower the entry barrier,
> > > specifically with repect too OpenSSH, diff and svk.
>
> I think we should try to optimize the read-only access case, since la
On Thu, Oct 20, 2005 at 03:12:30PM +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | I have absolutely no reason to expect the feedback process to change if
> | we waited. I have absolutely no reason to believe this won't happen
> | again when svn 1.4 com
On Thu, Oct 20, 2005 at 07:46:52AM -0700, Mark Mitchell wrote:
> Joseph S. Myers wrote:
>
> > I don't think keeping the CVS repository up to date after the move to
> > subversion is worthwhile
>
> I agree.
>
> I think that keeping CVS up-to-date is not a good use of resources; when
> we switch,
> What I keep seeing are increasingly complex solutions in order to keep
> efficiency the same as it is now.
Ah, come on. That just takes some getting used to.
In *some* cases, indeed I'm seeing "do it this way instead of that way" where
the suggested way isn't more complicated,
Ideally, once this discussion is over, some kind subversion expert will
update the wiki to contain the answers to the questions raised on this
thread.
Ideally once this discussion is over, the information will be in real
documentation, not just the wiki ...
Make that *more* efficiently. AFAIK svn is much more efficient than
cvs by default in all cases, except for disk space use.
Arno's numbers seem to disagree with you there.
So, after staring at the working copy to look at ways to reduce size, it
turns out i foo-barred the conversion command line slightly in my last
conversion, and it's setting the eol-style property on every single file
(it ignored my misspelled option :P).
I've done this conversion about 80 billion
Joe Buck wrote:
> Another possibility is to increase the frequency of snapshots after
> the switch to subversion. They will have a lower cost, since it will
> no longer be necessary to lock the database for an hour to attach the
> snapshot tag. Or maybe no tag is necessary at all for snapshots,
On Thursday 20 October 2005 18:34, Richard Kenner wrote:
> Ideally, once this discussion is over, some kind subversion expert
> will update the wiki to contain the answers to the questions raised on this
> thread.
>
> Ideally once this discussion is over, the information will be in real
> docu
There already IS real documentation, and it's very good.
http://svnbook.red-bean.com/
The online help provided by "svn help" is also very good as a quick
reference.
No, I don't mean documentation of svn (I assumed it had a manual ...),
I mean a replacement for the information
I just did an unapproved commit to the svn repository (r105372) on the
theory that it is still a test repository.
This is permitted isn't it?
One thing that happened is that all the bugzilla bugs that were
referenced got updated as well. But this is in the live bugzilla.
Did I do something
On Thu, 2005-10-20 at 07:25 -0700, Steve Kargl wrote:
> On Thu, Oct 20, 2005 at 02:47:19PM +0200, Florian Weimer wrote:
> > * Daniel Berlin:
> >
> > > You could simply do non-recursive checkouts (svn co -N) of the dirs you
> > > want.
> > > SVN doesn't care how you piece together the working copy.
On Thu, 2005-10-20 at 11:06 -0700, David Daney wrote:
> I just did an unapproved commit to the svn repository (r105372) on the
> theory that it is still a test repository.
>
> This is permitted isn't it?
Sure.
>
> One thing that happened is that all the bugzilla bugs that were
> referenced go
On Oct 20, 2005, at 10:45 AM, Daniel Berlin wrote:
For the curious, my goal for 1.4 is to have it under 500 meg in
size, if
at all possible.
svn edit (hard link, then have edit break the link), and making use
of union filesystems might be two easy things to do that can reclaim
lots of spa
On Mon, Oct 17, 2005 at 10:56:01AM -0700, Jim Wilson wrote:
>Peter Barada wrote:
>>Does the uberbaum tree exist on savanna, or is it only on
>>sources.redhat.com? If so, what is the procedure for accessing it?
>
>I would not recommend use of uberbaum. There are some old-time
>ex-Cygnus hackers t
Daniel Berlin wrote:
On Thu, 2005-10-20 at 11:06 -0700, David Daney wrote:
I just did an unapproved commit to the svn repository (r105372) on the
theory that it is still a test repository.
This is permitted isn't it?
Sure.
One thing that happened is that all the bugzilla bugs th
Joe Buck <[EMAIL PROTECTED]> writes:
| On Thu, Oct 20, 2005 at 03:12:30PM +0200, Gabriel Dos Reis wrote:
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | I have absolutely no reason to expect the feedback process to change if
| > | we waited. I have absolutely no reason to
Ian Lance Taylor wrote:
Uros Bizjak <[EMAIL PROTECTED]> writes:
There is no post-reload cse_condition_code_reg () pass, so perhaps we
have to add one. A cse_condition_code_reg () walks all instructions by
itself, so I'm not sure if some existing post-reload CSE pass could be
enhanced.
Ian Lance Taylor wrote:
Richard Guenther <[EMAIL PROTECTED]> writes:
If it is at all possible we should probably try to keep read-only CVS working
(and up-to-date) for HEAD and release-branches. This will allow occasional
contributors and technically-less-provided people to continue workin
On Oct 20, 2005, at 2:45 AM, Arnaud Charlet wrote:
Note that I found it a real pain to have to install so much
dependency package
on my linux system, so I suspect building the whole dependency
packages under
non linux systems might be slghtly of a pain.
I'm on darwin, grabbed tarball, built
I have been using the gcc 3.4.4 GNAT compiler to compile an existing Ada
program on an HP-UX 11 system.
We have noticed that generated images of floating-point numbers often
appear with the least-significant digit incremented by 1. Since the
application is used in a calibration laboratory, this
Kevin Handy <[EMAIL PROTECTED]> writes:
> Would it be possible to write a cvs read-only interface to the
> svn database? i.e. replace the cvs server with a svn-cvs emulation
> layer.
In principle, sure, why not? The CVS client server protocol is well
documented.
In practice sounds like quite a
There already IS real documentation, and it's very good.
http://svnbook.red-bean.com/
Actually, I just went to that site and the latest printable (i.e., PDF)
version I can find there is for version 1.1. Is that going to be good enough?
Snapshot gcc-4.0-20051020 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20051020/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20051020
You'll
x z wrote:
Is gcc optimized for thread level parallelism, in view of the recent
development of SMT and multicore architectures?
No, but we are working on OpenMP support, which is somewhat related.
This isn't automatic parallelization; it requires programmer
instrumentation via pragmas. This
Piotr Wyderski wrote:
Why isn't c destroyed at the very end? Is it a bug or a correct behaviour?
It is a bug. Where the bug lies depends on lots of info you left out,
such as the gcc version, the binutils version, and the target. See
http://gcc.gnu.org/bugs.html
for info on how to submi
Daniel Berlin <[EMAIL PROTECTED]> writes:
| > I'd also remember that this issue (diff of a single file across SSH being
| > slower) can be fixed by either an OpenSSH upgrade (which should be flawless
| > in many cases), or a svn:// readonly access (which I still have to
| > understand if it can be
On Thu, Oct 20, 2005 at 06:15:38PM -0400, Richard Kenner wrote:
> There already IS real documentation, and it's very good.
>
> http://svnbook.red-bean.com/
>
> Actually, I just went to that site and the latest printable (i.e., PDF)
> version I can find there is for version 1.1. Is that
Alexandre Oliva <[EMAIL PROTECTED]> writes:
| On Oct 20, 2005, Daniel Berlin <[EMAIL PROTECTED]> wrote:
|
| > svn diff -r1:r2 is only slow in the very small diff case, where ssh
| > handshake time dominates the amount of data to be transferred.
|
| And then, cvs diff -r1 -r2 also requires a ssh
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Oct 20, 2005, [EMAIL PROTECTED] (Richard Kenner) wrote:
>
>> I'm very concerned that we're greating increasing the barrier to entry for
>> work on GCC. cvs is very intuitive and simple to use.
>
> The same can be said of svn, so it's not like a gre
1 - 100 of 113 matches
Mail list logo
