Re: Two volunteers needed: New scheduler and aliasing code

Re: Two volunteers needed: New scheduler and aliasing code

[Jeffrey A Law]

  >     Richard> CVS is now being used for the GCC tree, but the system
  >     Richard> administration folks at FSF are still waiting for
  >     Richard> information about CVS in order to turn on anonymous
  >     Richard> access.
Well, it's pretty simple.

You set up an entry for pcvs in /etc/inetd.conf:

pcvs    stream tcp nowait root  /usr/local/bin/cvs      /usr/local/bin/cvs --allow-root=/egcs/carton/cvsfiles pserver


Replace "/usr/local/bin/cvs" with the path to your cvs binary

Replace "/egcs/carton/cvsfiles" with the path to the CVS directory
(ie a path to the directory which contains the dir CVSROOT).


Then in the file CVSROOT/passwd create an entry for your anonymous
CVS user:

anoncvs:fNyTMsxBpvSjg:anoncvs

This particular entry has an encoded password of "anoncvs".


Then create the file CVSROOT/readers.  The contents of that file
would be the username of the anonymous CVS user "anoncvs" in this
example.


I believe  you also need to make an "anoncvs" user in your main
password file (or change the last entry on the one line in
CVSROOT/passwd).  The directories and files in the repository must
be owned by the anoncvs user so that locks and such can be created.

Additional information can be obtained by reading the CVS manual,
look for "Password server" and the like.

jeff

Re: Two volunteers needed: New scheduler and aliasing code

[Mark Mitchell]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

    Richard>     This would be much easier to do if GCC already had a
    Richard> publicly-accessible anonymous CVS tree.  In fact, I'd say
    Richard> this would be very hard to do without CVS support.

My apologies for my mail software; I know that Kenner did not say the
above.

    Richard> CVS is now being used for the GCC tree, but the system
    Richard> administration folks at FSF are still waiting for
    Richard> information about CVS in order to turn on anonymous
    Richard> access.

I made this suggestion once before, but I'll try it again now that
Kenner and the FSF have moved forward with using CVS for GCC.

The merge work that Kenner has asked for, and that it was pointed out
above would be easier if there were public access to the CVS tree GCC2
sources, would be main even easier if GCC2 and EGCS shared a common
CVS tree.  This is technically very feasible since CVS supports
branches.  The branches are named, and there is no way that work on
one branch can affect another branch, unless an explict command to do
so is issued.  A shared setup like that would make it much easier to
do merges back and forth, and to compute the differences between the
branches, thereby facilitating collaboration.

I believe that Jeff agreed at one point that Cygnus would be willing
to host the common tree, and provide access to Kenner and other FSF
maintainers.  

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

Re: Two volunteers needed: New scheduler and aliasing code

[Jason Merrill]

The FSF already has a pserver set up, it just doesn't support anonymous
access.  The problem with anonymous CVS at the FSF is that they're only
running 1.9, which does not support 'readers' or '--allow-root', so they're
not sure which version to run.  The latest versions don't support working
on the RCS files directly; if someone checks something in via RCS, the next
time you try to update your tree CVS complains that the head revision
doesn't match the one it cached, and dies.

So the question is, what version to run?

Jason

Re: Two volunteers needed: New scheduler and aliasing code

[ian]

In gcc2 jason@cygnus.com (Jason Merrill) writes:

>The FSF already has a pserver set up, it just doesn't support anonymous
>access.  The problem with anonymous CVS at the FSF is that they're only
>running 1.9, which does not support 'readers' or '--allow-root', so they're
>not sure which version to run.  The latest versions don't support working
>on the RCS files directly; if someone checks something in via RCS, the next
>time you try to update your tree CVS complains that the head revision
>doesn't match the one it cached, and dies.

The head revision cache is only in the Cygnus version of CVS.  It is
not in the CVS releases distributed by Cyclic.

I have not submitted the patches into Cyclic precisely because of
problems like these.  We avoid them at Cygnus by draconian control
over the CVS repository, but they can cause problems for other people.
My plan is to eventually submit them into Cyclic controlled by a
parameter in the relatively new config file.

I recommend that the FSF use the CVS 1.9.26 release from Cyclic.  It
should not have the problem described above.

Ian

Re: Two volunteers needed: New scheduler and aliasing code

[Richard Kenner]

I'd like to first renew the call for volunteers, since nobody has yet
stepped forward to do the work with either of these changes.

    Unfortunately, the sources are not getting closer, because both gcc2
    and egcs are continuing to be developed. 

The fact they are both being developed does not mean that the sources
are either necessarily diverging or converging.  I hope the latter is
the case and intend to aim towards making it the case.  I suspect once
we get organized, we'll find that only 2-4 changes per year need to go
to EGCS first.

    This means that if you want a common CVS tree, it should happen ASAP,
    or it will only be harder to do in the future. 

I disagree since the steps of "catching up" are mostly manual. 

    I believe that doing a common CVS tree sooner rather than later will
    actually facilitate the process of bringing the sources closer, since
    you basically have to conduct a merge operation, and it's much easier
    to do this with CVS support than manually.

No, I don't see that at all.  The way I understand things, merges can
only be done automatically if the change is moved verbatum.  Even for
small changes that's not that common since, historically, most changes
I receive need some sort of minor editing before installation and if I
even have to change one character, I gain nothing from the merge
capability.

For a situation like this, where what's needed is to extract a large
set of diffs and work with them, I don't see anything but the most trivial
time savings in having a common tree.

Basically, automated (or semi-automated) merging works best when the
underlying sources are closest, and that's what I went to try to do
first.

But there's another issue: having the capability to do autonmated
merging seriously hurts quality control because the relative cost of
doing minor edits when installing changes is so much higher that
there's a very large temptation not to do it.  And making those minor
changes are usually what's very important in keeping the quality of
the code high.

I suspect whether or not having a common repository makes sense or not
depends strongly on what kinds of procedures Jeff and I end up
employing as we work towards keeping the sources closer.  We're still
discussing those.

    Cygnus is not only on the west coast; last time I checked, Jeff Law's
    in Utah, Michael Meissner is in Cambridge near the FSF.  So two of the
    four folks listed as having "Blanket Write Privs." in the egcs
    MAINTAINERS file are not on the West Coast.  Furthermore, some of the
    folks who have write-after-approval access to the egcs CVS tree are in
    Europe.  They seem to be managing OK.  So I believe this to be a
    non-issue.

Since it seems like I'm the only one concerned about speed, it sounds like
if we do have a common repository, it should be at the FSF, right? ;-)

Re: Two volunteers needed: New scheduler and aliasing code

[Ulrich Drepper]

Alexandre Oliva <oliva@dcc.unicamp.br> writes:

> Well, it sounds ok, but, OTOH, I've heard lots of complaints about FSF 
> hosts being off-line recently, whereas egcs.cygnus.com has been much
> more reliable.  That's another important issue to be considered.

I can only tell from my experiences with the FSF machines, if you rely
on the your development will have many stops.  cvs sometimes simply
crashes the machines or halts them.  I only keep a mirror of the cvs
archiv on the FSF machines now since I'm not nly concerned about speed
but also only reliability of the system and getting techsupport to
play in a tape if necessary.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: Two volunteers needed: New scheduler and aliasing code

[Jeffrey A Law]

  In message < oru38pbba9.fsf@zecarneiro.lsd.dcc.unicamp.br >you write:
  > Well, it sounds ok, but, OTOH, I've heard lots of complaints about FSF 
  > hosts being off-line recently, whereas egcs.cygnus.com has been much
  > more reliable.  That's another important issue to be considered.
Yes, this is a very serious issue.

As is performance of the CVS server.  Cygnus purchased dedicated
machine to handle egcs related activity.

jeff

Re: Two volunteers needed: New scheduler and aliasing code

[Alexandre Oliva]

Richard Kenner writes:

> Since it seems like I'm the only one concerned about speed, it sounds like
> if we do have a common repository, it should be at the FSF, right? ;-)

Well, it sounds ok, but, OTOH, I've heard lots of complaints about FSF 
hosts being off-line recently, whereas egcs.cygnus.com has been much
more reliable.  That's another important issue to be considered.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Two volunteers needed: New scheduler and aliasing code

[Michael Meissner]

Joe Buck writes:
| Cygnus is not only on the west coast; last time I checked, Jeff Law's in Utah,
| Michael Meissner is in Cambridge near the FSF.  So two of the four folks
| listed as having "Blanket Write Privs." in the egcs MAINTAINERS file are
| not on the West Coast.  Furthermore, some of the folks who have
| write-after-approval access to the egcs CVS tree are in Europe.  They seem
| to be managing OK.  So I believe this to be a non-issue.  Perhaps Michael
| M. can fill you in on how well CVS access works from the east coast,
| based on his own experience.

Cygnus is all over the globe.  We have offices in England,
Massachusetts, Toronto, Atlanta, Japan, Austrailia as well as
California.  Cvs works just fine bicoastally, and even world wide.  If
the network is slow, you just let it run, pop down the xterm, and work
on something else.  I've done cvs through a 28k modem line (check
files in, update, etc. ALL of the time).  At least one of our
engineers is still using a 14k modem (you obviously don't want to
check out whole trees over a modem line, but you can if that's all you
have, and you do not pay by the minute phone charges :-).  I will say,
on a tree that is undergoing rapid development, you sometimes have to
update the ChangeLog files once or twice to make sure they are in sync
(if the ChangeLog file is out of date, you remove your entries, cvs
update it, put your entries back in, and then do the commit).

| > I don't know CVS well enough: is there some kind of a mirroring capability
| > that can allow there to be two repositories and have changes migrate in
| > the background (sort of like the way news works)?
| 
| Not as far as I know (and commercial systems I'm aware of that do have a
| "multisite" capability generally require manual merges), but the checkins
| and checkouts can go in the background even with the one CVS database.
| 
| 

Re: Two volunteers needed: New scheduler and aliasing code

[Jeffrey A Law]

  In message < 199803202027.PAA01289@tiktok.cygnus.com >you write:
  > California.  Cvs works just fine bicoastally, and even world wide.  If
  > the network is slow, you just let it run, pop down the xterm, and work
  > on something else.  I've done cvs through a 28k modem line (check
  > files in, update, etc. ALL of the time). 
Yup.  I've done the same thing while switching from one ISP to another;
I've also used remote CVS to work on a repository where round trip
times for packets was > 1second and drop rates of 30%.  

Neither situation is ideal, but remote CVS handles it just fine; just
takes longer than on a good network link :-)  And as I've mentioned
before, you don't have to interact with the remote machine at all
which is a huge win if the network is flakey/slow.

  > At least one of our
  > engineers is still using a 14k modem 
Worse yet, he's a 14.4 into another engineer's house, and they
share the outgoing connection from the second engineer's house :-)

jeff

Re: Two volunteers needed: New scheduler and aliasing code

[Alexandre Oliva]

Mark Mitchell wrote:

>     The merge work that Kenner has asked for, and that it was pointed out
>     above would be easier if there were public access to the CVS tree GCC2
>     sources, would be main even easier if GCC2 and EGCS shared a common
>     CVS tree.

[snip]

Richard Kenner writes:

> At present, though, I think it will just make life more complex.

How so?

>     I believe that Jeff agreed at one point that Cygnus would be willing
>     to host the common tree, and provide access to Kenner and other FSF
>     maintainers.

> The site of the repository is indeed what I suspect will make this the
> most problematical.  Cygnus and the FSF are on opposite coasts and
> cross-country Internet access has been quite poor lately.

I'm not sure what you mean by `poor', but I'm perfectly able to
remotely work on Amanda CVS tree, located in US, from my hosts in the
Brazilian academic network, that's got just permanently overloaded
few-Mb/s connection with US.

> Whichever coast is chosen for the repository will greatly
> inconvenience the people on the other coast.

I could set up a CVS server in Brazil, so both would be annoyed :-D

> I don't know CVS well enough: is there some kind of a mirroring capability
> that can allow there to be two repositories and have changes migrate in
> the background (sort of like the way news works)?

I'm aware of mirroring capabilities of CVS servers, but, AFAIK, there
must be a master site, that must handle all check-ins.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Two volunteers needed: New scheduler and aliasing code

[Joe Buck]

>     A shared setup like that would make it much easier to do merges back
>     and forth, and to compute the differences between the branches,
>     thereby facilitating collaboration.
> 
> I agree.  However, I think this will become much more useful once
> we've gotten the sources closer, which is what these volunteers are
> needed for.

Unfortunately, the sources are not getting closer, because both gcc2
and egcs are continuing to be developed.  This means that if you want
a common CVS tree, it should happen ASAP, or it will only be harder
to do in the future.  I believe that doing a common CVS tree sooner
rather than later will actually facilitate the process of bringing the
sources closer, since you basically have to conduct a merge operation,
and it's much easier to do this with CVS support than manually.

>     I believe that Jeff agreed at one point that Cygnus would be willing
>     to host the common tree, and provide access to Kenner and other FSF
>     maintainers.
> 
> The site of the repository is indeed what I suspect will make this the
> most problematical.  Cygnus and the FSF are on opposite coasts and
> cross-country Internet access has been quite poor lately.  Whichever
> coast is chosen for the repository will greatly inconvenience the
> people on the other coast.

Cygnus is not only on the west coast; last time I checked, Jeff Law's in Utah,
Michael Meissner is in Cambridge near the FSF.  So two of the four folks
listed as having "Blanket Write Privs." in the egcs MAINTAINERS file are
not on the West Coast.  Furthermore, some of the folks who have
write-after-approval access to the egcs CVS tree are in Europe.  They seem
to be managing OK.  So I believe this to be a non-issue.  Perhaps Michael
M. can fill you in on how well CVS access works from the east coast,
based on his own experience.

> I don't know CVS well enough: is there some kind of a mirroring capability
> that can allow there to be two repositories and have changes migrate in
> the background (sort of like the way news works)?

Not as far as I know (and commercial systems I'm aware of that do have a
"multisite" capability generally require manual merges), but the checkins
and checkouts can go in the background even with the one CVS database.

Re: Two volunteers needed: New scheduler and aliasing code

[Richard Kenner]

[Note: I'm not on the egcs list, but am replying there as well.]

    The merge work that Kenner has asked for, and that it was pointed out
    above would be easier if there were public access to the CVS tree GCC2
    sources, would be main even easier if GCC2 and EGCS shared a common
    CVS tree.  This is technically very feasible since CVS supports
    branches.  The branches are named, and there is no way that work on
    one branch can affect another branch, unless an explict command to do
    so is issued.

A technical question here is if this can be done by merging the two
existing sets of files and still keep all the revision histories.  I
don't know enough about CVS to answer that.

    A shared setup like that would make it much easier to do merges back
    and forth, and to compute the differences between the branches,
    thereby facilitating collaboration.

I agree.  However, I think this will become much more useful once
we've gotten the sources closer, which is what these volunteers are
needed for.  Automatic or even semi-automatic merges are really only
viable if the sources are relatively close.  My hope is that if we
spend a couple of months working on things, we can have the sources
close enough together that the only differences are that EGCS has some
of the larger changes that aren't in the FSF sources yet.  At that
point having a common code base will indeed make things a lot easier.
At present, though, I think it will just make life more complex.

    I believe that Jeff agreed at one point that Cygnus would be willing
    to host the common tree, and provide access to Kenner and other FSF
    maintainers.

The site of the repository is indeed what I suspect will make this the
most problematical.  Cygnus and the FSF are on opposite coasts and
cross-country Internet access has been quite poor lately.  Whichever
coast is chosen for the repository will greatly inconvenience the
people on the other coast.

I don't know CVS well enough: is there some kind of a mirroring capability
that can allow there to be two repositories and have changes migrate in
the background (sort of like the way news works)?

Two volunteers needed: New scheduler and aliasing code

[Richard Kenner]

We need two volunteers to work on helping to move the completed new
("Haifa") insn scheduler and aliasing code from EGCS to GCC.

One volunteer is needed for each of those pieces.  Each volunteer
should be familiar with the code they are helping to move and will
need to perform the following four tasks:

(1) Extract a patch for that code from the differences between the
current EGCS and GCC development trees.

(2) Test the patch in the GCC tree.

(3) Send the patch to me.

(4) Answer any questions I might have about the patch and help me make any
changes that may be needed to it before installation into GCC.

Once this is done, fixes for these can be put simultaneously into EGCS
and GCC.

Note that I am not on the EGCS list, so please send any responses to
the gcc2 list or directly to me.  Normally, I do not send mail to a
list I'm not on, but am making an exception here.

Re: Two volunteers needed: New scheduler and aliasing code

[Alexandre Oliva]

Richard Kenner writes:

> We need two volunteers to work on helping to move the completed new
> ("Haifa") insn scheduler and aliasing code from EGCS to GCC.

> Each volunteer should be familiar with the code they are helping to
> move

This disqualifies me completely :-(

> (1) Extract a patch for that code from the differences between the
> current EGCS and GCC development trees.

> (2) Test the patch in the GCC tree.

This would be much easier to do if GCC already had a
publicly-accessible anonymous CVS tree.  In fact, I'd say this would
be very hard to do without CVS support.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil