plib-devel

RE: [Plib-devel] PLIB developers needed.

[Vallevand, M. K <Mar...@UN...>]

This is almost what I did!
The difference is that when I checked out the files again under
my userid using cvs/ssh, I only checked out the three files that
were being changed.  And, I only committed the three files that
were changed.  Could this make a difference?

If I commit *all* of plib, is cvs clever enough to only commit
the files that are actually changed?

Regards.
Mark K Vallevand   ma...@rs...
Never try and teach a pig to sing: it's a waste of time, and it annoys
the pig.

> I'm unclear what the problem is.
> 
> I have write access to a sourceforge project and I want to be 
> able to switch
> between anonymous CVS and CVS writing.
> 
> I want to use anonymous CVS when I'm updating my tree, but 
> CVS writes when
> checking something into the tree.
> 
> At the top level of the tree, I can do the following to 
> update my tree:
> cvs 
> -d:pserver:ano...@cv...:/cvsroot/quake update
> 
> And the following to do writes (with CVS_RSH set to ssh):
> cvs -d...@cv...:/cvsroot/quake commit
> 
> Once I do the write, I can do the former to reset CVS/Root to be the
> anonymous version.  It's just that simple when your CVS tree 
> isn't deep, but
> it gets more complicated when you have a deep hierarchy.  If 
> you are only
> operating from the root, you are fine with this scenario.   If you are
> running cvs commands from other directories, you'd have to 
> use the cvs update
> command in those directories to fix up CVS/Root
> 
> Loring

Re: [Plib-devel] PLIB developers needed.

[Curtis L. O. <cu...@me...>]

I didn't see that anyone replied to this so my apologies if I'm
duplicating what someone else wrote.

Steve Baker writes:
> The 'P' in PLIB stands for "Portability" - and the rest is just a "LIBrary"!
> 
> ...which reminds me...  :-)
> 
>  I tried to compile PLIB on an SGI machine at work - and your
> 'const-ification' of the clock routine stopped it from compiling on
> the IRIX compiler.
> 
> You had:
> 
>   class ulClock
>   {
>     ...
>     public:
>       ...
>       int getSomething () const { return something ; }
>       ...
>    } ;
> 
> The 'const' seemed to do *bad* things to the SGI compiler.
> 
> Could you remind me what exactly a 'const' right there actually *does*? 

As best as I can tell, this indicates to the compiler that a call to
foo->getSomething() does not modify foo in anyway.

So if you had a const instance of your class such as:

    const ulClock foo;

Then calling foo.getSomething() is legal.  

It's all part of maintaining const consistancy.

> ...and then remove them anyway!

Const is pretty handy if used correctly ... :-)

Regards,

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

RE: [Plib-devel] PLIB developers needed.

[Vallevand, M. K <Mar...@UN...>]

Norman, you are a fountain of information.  Perl.  One of
my favs.

Regards.
Mark K Vallevand   ma...@rs...
Never try and teach a pig to sing: it's a waste of time, and it annoys
the pig.


> -----Original Message-----
> From: Norman Vine [mailto:nh...@ca...]
> Sent: Thursday, August 10, 2000 1:11 PM
> To: pli...@li...
> Subject: RE: [Plib-devel] PLIB developers needed.
> 
> 
> >
> >And the rub is "python installed."  :-)
> 
> Tsk Tsk :-)
> 
> Perl versions here
> 
> http://www.red-bean.com/cvsutils/
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

RE: [Plib-devel] PLIB developers needed.

[Norman V. <nh...@ca...>]

>
>And the rub is "python installed."  :-)

Tsk Tsk :-)

Perl versions here

http://www.red-bean.com/cvsutils/

RE: [Plib-devel] PLIB developers needed.

[Loring H. <ls...@cs...>]

> And the rub is "python installed."  :-)

I'm unclear what the problem is.

I have write access to a sourceforge project and I want to be able to switch
between anonymous CVS and CVS writing.

I want to use anonymous CVS when I'm updating my tree, but CVS writes when
checking something into the tree.

At the top level of the tree, I can do the following to update my tree:
cvs -d:pserver:ano...@cv...:/cvsroot/quake update

And the following to do writes (with CVS_RSH set to ssh):
cvs -d...@cv...:/cvsroot/quake commit

Once I do the write, I can do the former to reset CVS/Root to be the
anonymous version.  It's just that simple when your CVS tree isn't deep, but
it gets more complicated when you have a deep hierarchy.  If you are only
operating from the root, you are fine with this scenario.   If you are
running cvs commands from other directories, you'd have to use the cvs update
command in those directories to fix up CVS/Root

Loring

> > If you do not want to recheckout all the files and have 
> > python installed
> > here is a little script that will change the local cvs/root 
> > files for you
> > http://www.vso.cape.com/~nhv/files/python/cvs_chroot.py
> > 
> > Norman

RE: [Plib-devel] PLIB developers needed.

[Vallevand, M. K <Mar...@UN...>]

And the rub is "python installed."  :-)

Regards.
Mark K Vallevand   ma...@rs...
Never try and teach a pig to sing: it's a waste of time, and it annoys
the pig.

> If you do not want to recheckout all the files and have 
> python installed
> here is a little script that will change the local cvs/root 
> files for you
> http://www.vso.cape.com/~nhv/files/python/cvs_chroot.py
> 
> Norman

[Plib-devel] RE: Util - ulNet

[Ben W. <be...@bg...>]

Sorry Dave

I thought that the attachment was not on the message in the mailing list, I
was looking at the archive from the homepage so and I did a few updates
since then, changed the class to fit in the ul.h header file. And I mailed
all the changes to steve. 

Thanks Ben

RE: [Plib-devel] PLIB developers needed.

[Norman V. <nh...@ca...>]

Sam Stickland writes:
>
>Ah, I see.. No this won't work... CVS will look for a 
>directory called CVS, and if it finds it it will use the 
>contents of CVS/root
>to do the checkout - so it will still be anonymous@blah.  It's 
>actually a "feature" to stop you accidently mixing the contents of
>two different CVS stores.

If you do not want to recheckout all the files and have python installed
here is a little script that will change the local cvs/root files for you
http://www.vso.cape.com/~nhv/files/python/cvs_chroot.py

Norman

RE: [Plib-devel] Work outstanding.

[Dave M. <Dav...@dy...>]

>   * Dave has been worrying about ssgSelector nodes with more 
> than 32 children, and how to time ssgTimedSelector in
> *realtime* instead of frame-time.  I maintain that you
> need both options - either as a flag inside ssgTimedSelector
> or as a derived class that does realtime timing. This really
> does need to be done soon because it's holding up some of
> the loader work.  What's tricky (with the >32 kids problem) 
> is keeping it backwards compatible.  Notice especially the
> need to have MULTIPLE children selectable at one - which
> is needed for some derived classes.

I already fixed ssgTimedSelector to handle >32 kids and still made it
backward compatible.  I also am able to override the _ssgFrameCounter by
calling ssgSetFrameCounter.  The only thing left is to add an elegant
realtime/frametime switch to the ssgTimedSelector class to manage this
automatically.

>   * There have been some comments about the need to delete 
> PUI nodes during their own callback functions.  This turns
> out to be incredibly useful - but it's not legal C++ to
> delete a class object whilst inside a member function
> that belongs to that same object.  There is an idea for a 
> fix for this but it's very tricky.  Read the thread:
>       [Plib-devel] listbox and filepicker
>       Fri, 4 Aug 2000 10:51:38 -0700

i'll fix this shortly when i need it

--Dave

RE: [Plib-devel] PLIB developers needed.

[Dave M. <Dav...@dy...>]

Steve wrote:
>  I tried to compile PLIB on an SGI machine at work - and your 
> 'const-ification' of the clock
> routine stopped it from compiling on the IRIX compiler.
> 
> You had:
> 
>   class ulClock
>   {
>     ...
>     public:
>       ...
>       int getSomething () const { return something ; }
>       ...
>    } ;
> 
> The 'const' seemed to do *bad* things to the SGI compiler.
> 
> Could you remind me what exactly a 'const' right there 
> actually *does*? 
> 
> ...and then remove them anyway!
>
I use 'const' in only two ways:

1) const data -- const Type* foo ;
2) const method -- Type getSomething () const ;

#1 means you can't change what foo points to.  You already use this heavily
in SG.  #2 means that the class method getSomething cannot change its
instance.  it is commonly used for inline 'query' methods.  #1 and #2 are
often used together.  for example, if you write a function like this:

void checkfoo ( const Type* foo )
{
  return ( foo -> getSomething () == 42 ) ;
}

if getSomething() is not a 'const' method then you get a warning because it
thinks you are changing what foo points to.  the alternative is casting away
the 'const' of foo ala ((Type*)foo) which is not as clear.

I really thought 'Type getSomething () const' was a very portable and
standard idiom.  Could you check the SGI documentation on that?  If needed,
I will remove the 'const' methods as you advise.

--Dave

RE: [Plib-devel] Work outstanding.

[Dave M. <Dav...@dy...>]

here's my current code:
http://www.pond.net/~davem/stuff/blender_import/

i just got started with it so you can start over if you want. i was going to
use the ssgParser class in ssg. the WRL files in test_wrl.zip come from
exporting the blender examples.  they should be useful regardless of your
approach

i was thinking about an ssgInvisible node to handle the VRML switch and then
making references back to those entities when the visible nodes are
encountered.

--Dave

Gil Carter wrote:
> >   * Dave has shelved his Blender-VRML loader for a while 
> and asks for 
> > help with
> >     continued development.  If this 'Blender-VRML' subset 
> is the best 
> > interchange
> >     format between Blender and PLIB then we'd better write 
> an exporter 
> > too so that
> >     Blender and PrettyPoly can exchange files too.
> 
> That sounds like me...  I'll have a look at where Dave's up 
> to with this 
> loader tonight.  I assume it's somewhere in the CVS repository?
> 

RE: [Plib-devel] Utility - ulNet class

[Dave M. <Dav...@dy...>]

Ben wrote:
> This is just a hack of steves code for the networking code, 
> just renamed with a minor change in recvMessage.
only UDP? will TCP be left out? I'm currently using TCP via SDL_net which
doesn't have any other dependencies but I'm interested in ulNet because of
Steve's proposed special permission for embedded system development.

> ps Attached is the code. Could someone tell me the best
> location for sending updates.
this is the correct place. would you like me to commit to CVS?

--Dave

Re: Documentation - doxygen (was Re: [Plib-devel] Work outstanding.)

[Joel U. <joe...@ya...>]

Sam Stickland wrote:
> 
> > Comments?
> 
> I really would like to suggest doxygen. :)

I tried doxygen, and five other packages, many seemed very buggy -
doxygen crashed. I was impressed with it up to that point (!) But I
couldn't get it to generate docs for me. I didn't spend too long on it -
eventually deciding on using perceps. It is an 80k perl script which
does autogenerated docs. Its used by the ClanLib project. I don't think
it does some of the nifty things the latest doxygen does (from your
sample pages) but it is easy to ship inside your source package,
therefore not adding any dependencies. It also uses style templates to
generate its html - so you can make the manual pages all have the same
look of your choosing.

I agree very much with inline docs - javadoc is lovely (I just started
using it at Uni 2 weeks ago), and with an api as changing as SSg is
right now...

Whatever you choose, I'd be willing to comment any of the ssg classes in
the required style, from the current manual. 

Bye - Joel.

RE: Documentation - doxygen (was Re: [Plib-devel] Work outstandin g.)

[Dave M. <Dav...@dy...>]

> Hi,
> 
> > I'd *really* like to help with this.  Documentation is a 
> pretty vital part
> > of getting newbies running, so I'll see what I can do in 
> this regard.  I'm
> > thinking of HTML page per class, with member variables and methods
> > documented.
> 
> Yes, the advantages of having the functions (and variables) 
> documented in the source code can't be under estimated.  I was first
> introduced to this when programing on the Amiga (all the 
> public OS functions were documented in this way).  It's _very_ useful.
> 
> It means that if someone adds a function they can document 
> before the cvs commit, and the documentation automatically 
> gets updated.
> And you won't believe the number of bugs you catch when you 
> start documenting  functions individually :)
> 
The Amiga used ROBODOC, which is what I'm using at work.
http://www.xs4all.nl/~rfsber/Robo/robodoc.html.  ROBODoc can format the
documentation in HTML, ASCII, AmigaGuide, LaTeX, or RTF format. It is even
possible to include parts of the source code with function names that point
their the documentation. It also can create index tables for all your
variables, classes, functions, etc.  for example:

/****f* ROBODoc/RB_Add_Link [3.0b]
 * NAME
 *   RB_Add_Link -- add a reference link to the list
 * SYNOPSIS
 *   void RB_Add_Link ()
 * FUNCTION
 *   Adds a reference from a xref file to the linked list
 *   with references.
 * INPUTS
 *   Uses the global variable line_buffer and first_link.
 * NOTES
 *   Makes sneaky use of the function RB_Insert_In_List.
 * SEE ALSO
 *   RB_Analyse_Xrefs, RB_link.
 * SOURCE
 */

The syntax of ROBODOC headers is more natural looking than other auto-doc
generators, IMO.  You can use the keywords INPUTS, ARGUMENTS, and PARAMETERS
interchangeably.  Same goes for FUNCTION, DESCRIPTION, and PURPOSE.  I
ported RoboDOC to windows if you want it.  Frans may have that in the latest
release, but I'm not sure.

--Dave

Re: [Plib-devel] PLIB developers needed.

[Sam S. <sa...@sp...>]

----- Original Message -----
From: "Vallevand, Mark K" <Mar...@UN...>
To: <pli...@li...>
Sent: Thursday, August 10, 2000 5:16 PM
Subject: RE: [Plib-devel] PLIB developers needed.


> I'm pretty sure I did this correctly.  I'll check my scripts.
> I did checkout the changed files as 'markus5' after I checked
> out all of plib anonymously.  Maybe there is some residue from
> the anonymous checkout getting in the way, even though I did
> check the files our again as 'markus5'.


Ah, I see.. No this won't work... CVS will look for a directory called CVS, and if it finds it it will use the contents of CVS/root
to do the checkout - so it will still be anonymous@blah.  It's actually a "feature" to stop you accidently mixing the contents of
two different CVS stores.


You check out plib into CVS-devel/plib with your plib user id.
You change CVSROOT and then check out, say, Mesa into CVS-devel/mesa3d
You go back to CVS-devel/plib and type cvs update.

If it didn't use CVS/root as your CVSROOT it would attempt to update from the mesa cvs store.

You'll have to check the whole of plib out as markus5 and then the commits will work.

Sam

RE: [Plib-devel] PLIB developers needed.

[Vallevand, M. K <Mar...@UN...>]

This must be it.  Thanks.

Regards.
Mark K Vallevand   ma...@rs...
Never try and teach a pig to sing: it's a waste of time, and it annoys
the pig.

> You wrote:
> 
> >But, cvs still reports "needing write access to update repository"
> >when trying to commit.
> 
> I think you are bitten by the same feature I fought with some time
> ago. When you import a module anonymously, cvs somewhere
> remembers that these files belong to Mister anonymous. 
> Checking out individual files doesn't change this. So, when 
> you try to commit them, it doesn't work, since the "files are
> anonymous" and Mr anonymous has no write access rights. 
> 
> I hope the explanation is at least half-way correct,
> the end result is: Import the complete module plib into a new
> directory using ssh. Then you should be able to change the files and
> commit them back into CVS.
> 
> >Regards.
> >Mark K Vallevand   ma...@rs...
> 
> Bye bye,
> Wolfram.

Re: [Plib-devel] PLIB developers needed.

[Wolfram K. <w_...@rz...>]

You wrote:

>But, cvs still reports "needing write access to update repository"
>when trying to commit.

I think you are bitten by the same feature I fought with some time
ago. When you import a module anonymously, cvs somewhere
remembers that these files belong to Mister anonymous. 
Checking out individual files doesn't change this. So, when 
you try to commit them, it doesn't work, since the "files are
anonymous" and Mr anonymous has no write access rights. 

I hope the explanation is at least half-way correct,
the end result is: Import the complete module plib into a new
directory using ssh. Then you should be able to change the files and
commit them back into CVS.

>Regards.
>Mark K Vallevand   ma...@rs...

Bye bye,
Wolfram.

RE: [Plib-devel] PLIB developers needed.

[Vallevand, M. K <Mar...@UN...>]

I'm pretty sure I did this correctly.  I'll check my scripts.
I did checkout the changed files as 'markus5' after I checked
out all of plib anonymously.  Maybe there is some residue from
the anonymous checkout getting in the way, even though I did
check the files our again as 'markus5'.

I'll save plib, start over, and checkout a completely new copy
of plib as 'markus5'.  Then, I'll copy the changed files from
the saved plib into plib.  I'll try committing after that.

This *does* make sense in a way.  But, I am sure that checking
out the files a second time (after deleting them first) as
'markus5' did work.  Then updating them and committing them
as 'markus5' should work, too.  But, it didn't.  So, maybe the
anonymous checkout is getting in the way.  Also, there are
some environment variables that need to be setup.  Maybe I've
got something mis-typed there.

Regards.
Mark K Vallevand   ma...@rs...
Never try and teach a pig to sing: it's a waste of time, and it annoys
the pig.


> -----Original Message-----
> From: Norman Vine [mailto:nh...@ca...]
> Sent: Thursday, August 10, 2000 10:57 AM
> To: pli...@li...
> Subject: RE: [Plib-devel] PLIB developers needed.
> 
> 
> Mark K Vallevand writes:
> >
> >I'm supposed to have CVS write access to PLIB, but it doesn't
> >work.  
> >
> >Here is what I did:
> >- anonymous checkout of all of plib;
> >- verify that plib still works for me (it does);
> >- checkout (as markus5, my sourceforge ID) the 3 files that 
> >are changing;
> >- change the files;
> >- commit (as markus5) the 3 files that changed.
> >
> >The commit says I don't have write access.
> >Any ideas?
> 
> Mark 
> 
> You wouldn't perchance be trying to update from a branch 
> where the ./cvs/root file reads as
> :pserver:ano...@cv...:/cvsroot/plib
> 
> would you ??
> 
> if so try changing it to read
> ma...@cv...:/cvsroot/plib
> 
> You can only update from a tree / branch checked out by a 
> 'known' user in a SSH CVS repository.
> 
> This might not have been set correctly since you did the 
> initial checkout annonymously.
> 
> Norman
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

RE: [Plib-devel] PLIB developers needed.

[Norman V. <nh...@ca...>]

Mark K Vallevand writes:
>
>I'm supposed to have CVS write access to PLIB, but it doesn't
>work.  
>
>Here is what I did:
>- anonymous checkout of all of plib;
>- verify that plib still works for me (it does);
>- checkout (as markus5, my sourceforge ID) the 3 files that 
>are changing;
>- change the files;
>- commit (as markus5) the 3 files that changed.
>
>The commit says I don't have write access.
>Any ideas?

Mark 

You wouldn't perchance be trying to update from a branch 
where the ./cvs/root file reads as
:pserver:ano...@cv...:/cvsroot/plib

would you ??

if so try changing it to read
ma...@cv...:/cvsroot/plib

You can only update from a tree / branch checked out by a 
'known' user in a SSH CVS repository.

This might not have been set correctly since you did the 
initial checkout annonymously.

Norman

RE: [Plib-devel] An example of ssgVtxArray usage

[Vallevand, M. K <Mar...@UN...>]

Thanks.  I've got about 9 FAQs and How-To lists.  I've printed
this one out, too.  The answer is in one of them, somewhere.

Regards.
Mark K Vallevand   ma...@rs...
Never try and teach a pig to sing: it's a waste of time, and it annoys
the pig.

> 
> I use WinCVS to (www.wincvs.org). I haven't tried it with SSH 
> yet, but it has this page on the site dedicated to WinCVS + SSH:
> 
> http://www.wincvs.org/ssh.html
> 
> Sam

Re: [Plib-devel] An example of ssgVtxArray usage

[Sam S. <sa...@sp...>]

Hi,


> Thanks.  I'd have put it in myself, but I still am fighting cvs/ssh to
> commit
> changes.

I use WinCVS to (www.wincvs.org). I haven't tried it with SSH yet, but it has this page on the site dedicated to WinCVS + SSH:

http://www.wincvs.org/ssh.html

Sam

RE: [Plib-devel] An example of ssgVtxArray usage

[Vallevand, M. K <Mar...@UN...>]

Thanks.  I'd have put it in myself, but I still am fighting cvs/ssh to
commit
changes.
 
The class still has bugs (I've already fixed some since I posted it), and
really needs commentary.  But, it was fun to write.  I'm working another
class for ocean waves.  That's cool.  I've got it mostly working, but I'm
waiting for the library to get me a copy of a 1986 SIGGRAPH article that
has the details of the technique I'm using.  The articles and source code
that I have as examples are incomplete and uncommented.
 

Regards. 
Mark K Vallevand   ma...@rs... 
Never try and teach a pig to sing: it's a waste of time, and it annoys the
pig. 

 

-----Original Message-----
From: Dave McClurg [mailto:Dav...@dy...]
Sent: Wednesday, August 09, 2000 7:48 PM
To: 'pli...@li...'
Subject: RE: [Plib-devel] An example of ssgVtxArray usage



pretty cool. i wrote a glut main() for it and added it to plib cvs (in
examples/src/ssg/tux). it's a good example of how to manually setup a leaf
without using a loader.

--Dave 

> I've uploaded a very preliminary version of a useful class for 
> animation in games.  Its also useful for seeing how ssgVtxArray 
> can be used and its limitations. 
> 
> http://vallevand.homepage.com/plib/WavingFlag.h
<http://vallevand.homepage.com/plib/WavingFlag.h>  
> http://vallevand.homepage.com/plib/WavingFlag.cpp
<http://vallevand.homepage.com/plib/WavingFlag.cpp>  
> 
> The class implements a flag waving in the wind.  Its optionally 
> textured on both sides.  The flag is 1.0 by 1.0 units and is in 
> the y-plane with lower left coords (0,0,0) and upper right coords 
> (1,0,1).  The wind blows from -x to +x.  You can translate and 
> scale it as needed, and rotate it around the z-axis for wind 
> direction.  But, it should not be rotated about other axis because 
> you'll loose the effect.  
> 
> The class illustrates ssgVtxArray usage to share vertex info 
> between triangle strips.  It also illustrates one limitation: 
> if a vertex is used for both faces of an object, the normal for 
> the vertex will be outward-facing on one side and inward-facing 
> on the other.  So far, this hasn't caused any problems for me. 
> 
> Regards. 
> Mark K Vallevand   ma...@rs... 
> Never try and teach a pig to sing: it's a waste of time, and it annoys 
> the pig. 

RE: [Plib-devel] Work outstanding.

[Vallevand, M. K <Mar...@UN...>]

The change to use short indices is ready.  I hadn't considered some
of these other improvements.  Doing this correctly requires some
thought.  My first thought is templates.  But, the P in PLIB is
*portable*, not *painful*.

Anyway, the short indices change to ssgVtxArray and ssgIndexArray
is ready, but I can't get cvs/ssh to commit the changes.
*sigh*
Welcome to *my* small corner of hell.

Regards.
Mark K Vallevand   ma...@rs...
Never try and teach a pig to sing: it's a waste of time, and it annoys
the pig.

> 
>   * The new ssgVtxArray class could be made more efficient 
> (especially for GeForce
>     cards) if we added the option to pass Normal arrays as 
> 'short' or 'byte' and
>     Colour arrays as 'byte'.  At present, we have both of 
> those as 'float' - so
>     to send a vertex to T&L hardware like GeForce or Radion 
> is taking ~48 bytes.
>     If we could cut the precision, we'd only send ~27 bytes.  
> Since data transfer
>     to the card is very often the limiting factor with 
> hardware T&L, we could perhaps
>     double performance on those cards without harming non-T&L 
> cards.  The loss in
>     precision doesn't matter because normals are pretty much 
> only used for lighting -
>     which in the end produces an 8 bit result - and colours 
> are hardly every more
>     than 8 bits - even with 32 bits per pixel frame buffer depth.
> 
>     (Notice that for *environment mapping* you may need more 
> precise normals).
> 
> 
> Well, welcome to my hell!
> 
> -- 
> Steve Baker   

RE: [Plib-devel] PLIB developers needed.

[Vallevand, M. K <Mar...@UN...>]

I've got several FAQs, but still haven't got things working.  :-(

I've got a version of ssh that *does* work.  I can do
  ssh -l markus5 plib.sourceforge.com
and I can login, etc.  So far, so good.

I've got a version of cvs that works for :pserver: and can
anonymously checkout and update.  I've configuring cvs to use
:ext: and set the CVS_RSH variable to use ssh.  It looks like
cvs *is* using ssh rather than the internal :pserver: stuff.
Again, so far, so good.

I used cvs/ssh to checkout the files.  Again, so far, so good.

But, cvs still reports "needing write access to update repository"
when trying to commit.

?wha?
Well, a guy has to see his family sometime, so I quit.
Something is still not right.  After some sleep I've got a few
ideas, but any suggestions are welcome.

Regards.
Mark K Vallevand   ma...@rs...
Never try and teach a pig to sing: it's a waste of time, and it annoys
the pig.

> 
> "Vallevand, Mark K" wrote:
> > 
> > I'm supposed to have CVS write access to PLIB, but it doesn't
> > work.
> 
> Well, I've checked - and you certainly ARE on the write access list:
> 
>    markus5   - Mark
>    mcdave    - Dave
>    sjbaker   - Steve
>    sps196    - Sam
> 
> There are at least 4 HOWTO/FAQ documents specifically for 
> Windoze users
> somewhere on Sourceforge...erm....here:
> 
>        http://sfdocs.sourceforge.net/sfdocs/
> 
> -- 
> Steve Baker

Re: [Plib-devel] PLIB developers needed.

[Sam S. <sa...@sp...>]

----- Original Message -----
From: "Gil Carter" <g.c...@ca...>
To: <pli...@li...>
Sent: Thursday, August 10, 2000 7:13 AM
Subject: Re: [Plib-devel] PLIB developers needed.


>
> >Linux people: Please don't do this:
> >
> >     for ( int i = 0 ; i < 10 ; i++ ) whatever ;
> >     for ( int i = 0 ; i < 20 ; i++ ) whatever ;
> >
> >(Although it's perfectly legal C++ - MSVC barfs on it - I forget
> >  about this *every* time - sorry Windoze dudes!)
>
> But to credit Leath Muller (I think), this will fix that problem:
>
>      { for ( int i = 0 ; i < 10 ; i++ ) whatever ; }
>      { for ( int i = 0 ; i < 20 ; i++ ) whatever ; }
>
> But it's daggy and isn't something you'd write given a choice :-)

I believe the revised ANSI C++ scoping rules now forbid declaration of variables in a for statement, completely.  But this is fairly
recent, so different compilers are still tolerating it in different ways.

The scoping for this sort of declaration was always cloudy at best, so it's probably for the best.

Bottom line - don't do it.

Sam