On Sat, 21 Feb 2004, Mathieu Bouchard wrote:
On Sat, 21 Feb 2004, guenter geiger wrote:
To add one thing. Except the devel_0_37 branch everything is a bit chaotic on CVS. Before starting to branch further we have to discuss how, where to branch from etc.
Good, my plan was actually to fork at the current devel_0_37 branch. Anyway I want to make use of the print-hook and the tooltips, and those are only in devel_0_37.
May I ?
From my point of view, you may :)
I will try to fix the HEAD branch over the weekend, I have to figure out what created the mess there. A TODO is still to incorporate the latest version of Miller into the devel_0_37, maybe I get to that too. Rainy weeking in Barcelona :(
Guenter
On Sat, 21 Feb 2004, guenter geiger wrote:
Good, my plan was actually to fork at the current devel_0_37 branch. Anyway I want to make use of the print-hook and the tooltips, and those are only in devel_0_37. May I ? From my point of view, you may :)
I will try to fix the HEAD branch over the weekend, I have to figure out what created the mess there. A TODO is still to incorporate the latest version of Miller into the devel_0_37, maybe I get to that too. Rainy weeking in Barcelona :(
Ok, thank you very much for your help.
Now I screwed the devel_0_37 branch further, as I committed some of my files in it. I did the "cvs tag -b" but not the "cvs update -r". It was the first time I was a creating a branch...
I think I fixed it, by committing older versions back on top of my versions.
In any case, I think I had to tell you...
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
On Sun, 22 Feb 2004, Mathieu Bouchard wrote:
I think I fixed it, by committing older versions back on top of my versions.
In any case, I think I had to tell you...
Ok, thanks, everything seems to be ok. I updated the HEAD to 0.37-1test6 and merged in the changes from millers version into devel_0_37.
Guenter
On Sun, 22 Feb 2004, guenter geiger wrote:
On Sun, 22 Feb 2004, Mathieu Bouchard wrote:
I think I fixed it, by committing older versions back on top of my versions. In any case, I think I had to tell you...
Ok, thanks, everything seems to be ok. I updated the HEAD to 0.37-1test6 and merged in the changes from millers version into devel_0_37.
Ok, I have three questions:
1. All those changes you just merged in seem to have changed almost every line in a lot of files. I thought it could be something like messing with newline codes or switching between tabs and spaces, but it seems that lines that only have one brace on it don't get modified. What is this? Is it a change of indentation style? I usually try to avoid those, as they make it more difficult to apply diffs / merge branches... What is your opinion on this?
2. I got several mails from pd-cvs saying my messages (sent from cvs commit) were frozen waiting for moderator approval. Who is in charge of approving those?
3. How often does SourceForge update their mirrors? is it every 2 or 4 hours or...? Because I work with people who don't have dev accounts and somehow it ain't quite as snappy in SourceForge than on Artengine's CVS (that doesn't use mirrors/delays). How do you people do? Do you send temporary diffs by email?
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
On Sunday 22 February 2004 13:39, Mathieu Bouchard wrote:
On Sun, 22 Feb 2004, guenter geiger wrote:
On Sun, 22 Feb 2004, Mathieu Bouchard wrote:
I think I fixed it, by committing older versions back on top of my versions. In any case, I think I had to tell you...
Ok, thanks, everything seems to be ok. I updated the HEAD to 0.37-1test6 and merged in the changes from millers version into devel_0_37.
Ok, I have three questions:
- All those changes you just merged in seem to have changed almost
every line in a lot of files. I thought it could be something like messing with newline codes or switching between tabs and spaces, but it seems that lines that only have one brace on it don't get modified. What is this? Is it a change of indentation style? I usually try to avoid those, as they make it more difficult to apply diffs / merge branches... What is your opinion on this?
<rant>
I brought this up a while ago, complaining about people still using hard tabs in source code. I don't know if this is the problem in this case. In the mean time, someone mentioned a switch for CVS to ignore whitespace - I don't remember it this applied to checkin, checkout, or both. Really, whitespace and newline differences should be none of the version control system's business, but I don't know how Sourceforge is configured by default.
Apologies in advance if this isn't the cause of your problem, but hard tabs are very, very bad, unless you're programming on a C64 and need to conserve floppy space. IMO If a programmer insists on using hard tabs, he or she should put a comment at the top of the source file specifying the tab spacing.
</rant>
Larry Troxler
On Sun, Feb 22, 2004 at 01:44:13PM -0500, Larry Troxler wrote:
On Sunday 22 February 2004 13:39, Mathieu Bouchard wrote:
On Sun, 22 Feb 2004, guenter geiger wrote:
On Sun, 22 Feb 2004, Mathieu Bouchard wrote:
I think I fixed it, by committing older versions back on top of my versions. In any case, I think I had to tell you...
Ok, thanks, everything seems to be ok. I updated the HEAD to 0.37-1test6 and merged in the changes from millers version into devel_0_37.
Ok, I have three questions:
- All those changes you just merged in seem to have changed almost
every line in a lot of files. I thought it could be something like messing with newline codes or switching between tabs and spaces, but it seems that lines that only have one brace on it don't get modified. What is this? Is it a change of indentation style? I usually try to avoid those, as they make it more difficult to apply diffs / merge branches... What is your opinion on this?
<rant>
I brought this up a while ago, complaining about people still using hard tabs in source code. I don't know if this is the problem in this case. In the mean time, someone mentioned a switch for CVS to ignore whitespace - I don't remember it this applied to checkin, checkout, or both. Really, whitespace and newline differences should be none of the version control system's business, but I don't know how Sourceforge is configured by default.
Apologies in advance if this isn't the cause of your problem, but hard tabs are very, very bad, unless you're programming on a C64 and need to conserve floppy space. IMO If a programmer insists on using hard tabs, he or she should put a comment at the top of the source file specifying the tab spacing.
</rant>
Larry Troxler
Alright, I'll bite; what are your logical reasons for disliking hard tabs?
Chris. --------------------------------- chris@mccormick.cx http://www.mccormick.cx http://www.sciencegirlrecords.com ---------------------------------
On Sun, 22 Feb 2004, Larry Troxler wrote:
<rant>
I brought this up a while ago, complaining about people still using hard tabs in source code. I don't know if this is the problem in this case. In the mean time, someone mentioned a switch for CVS to ignore whitespace - I don't remember it this applied to checkin, checkout, or both. Really, whitespace and newline differences should be none of the version control system's business, but I don't know how Sourceforge is configured by default.
Hi Larry,
If it really disturbes you that much, the most efficient solution would be to make yourself clever about the topic and contribute.
I am all for spaces instead of tabs.
Apologies in advance
accepted.
Guenter
if this isn't the cause of your problem, but hard tabs are very, very bad, unless you're programming on a C64 and need to conserve floppy space. IMO If a programmer insists on using hard tabs, he or she should put a comment at the top of the source file specifying the tab spacing.
</rant>
Larry Troxler
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Sun, 22 Feb 2004, Larry Troxler wrote:
I brought this up a while ago, complaining about people still using hard tabs in source code. [...] but hard tabs are very, very bad, unless you're programming on a C64 and need to conserve floppy space.
You make it seems like it was a completely outdated that only a few rare programmers would use, out of nostalgia. However many rather recent (and sometimes huge) projects have hard tabs as their only allowed indentation.
IMO If a programmer insists on using hard tabs, he or she should put a comment at the top of the source file specifying the tab spacing.
There are two usual ways of thinking of hard tabs:
1. One tab per indentation level. All hard tabs are at the beginning of lines: no tabs in the middle. This allows the tabwidth to be customized to whatever value without the code looking too weird.
2. The church of EMACS: hard tabs don't exist in the editor, but they are used in files to save space. Tab width is always 8 here.
Frankly I'm more of a (1) guy, and so is (for example) the source code of the Linux kernel... but even then, playing around with a lot of different projects (many of which CVS'd), one cannot have everything in his own indentation style, and in a CVS context it pays more to keep each chunk of code in whatever format it's written it.
I don't know if this is the problem in this case. In the mean time, someone mentioned a switch for CVS to ignore whitespace - I don't remember it this applied to checkin, checkout, or both. Really, whitespace and newline differences should be none of the version control system's business, but I don't know how Sourceforge is configured by default.
What do you mean that it's none of its business, that it should ignore whitespace, or that it should not change from its current behaviour? And if the latter, why wouldn't that be a good idea?
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
On Sunday 22 February 2004 21:56, Mathieu Bouchard wrote:
On Sun, 22 Feb 2004, Larry Troxler wrote:
I brought this up a while ago, complaining about people still using hard tabs in source code. [...] but hard tabs are very, very bad, unless you're programming on a C64 and need to conserve floppy space.
You make it seems like it was a completely outdated that only a few rare programmers would use, out of nostalgia. However many rather recent (and sometimes huge) projects have hard tabs as their only allowed indentation.
IMO If a programmer insists on using hard tabs, he or she should put a comment at the top of the source file specifying the tab spacing.
There are two usual ways of thinking of hard tabs:
- One tab per indentation level. All hard tabs are at the beginning of
lines: no tabs in the middle. This allows the tabwidth to be customized to whatever value without the code looking too weird.
That's a nice ideal, and is in fact what the hard tab character was intended to be used for, but show me a project which follows these guidelines, and doesn't in fact mix hard tabs and spaces. I guess you'll throw the linux kernel source at me ... :-)
- The church of EMACS: hard tabs don't exist in the editor, but they
are used in files to save space. Tab width is always 8 here.
Terribly brain-damaged, that. The very essence of the tab character is that it is up to the renderer to decide the indentation level. That in itself would be fine, except that it gets misused, for example, to line up expressions that are too long for one line. I already have to work on legacy projects at my day job, where people have in the past used hard tabs set to 2, 3, or 4 spaces; You're telling me that I now have to also consider 8? I'm tired of playing this game.
I don't know if this is the problem in this case. In the mean time, someone mentioned a switch for CVS to ignore whitespace - I don't remember it this applied to checkin, checkout, or both. Really, whitespace and newline differences should be none of the version control system's business, but I don't know how Sourceforge is configured by default.
What do you mean that it's none of its business, that it should ignore whitespace, or that it should not change from its current behaviour? And if the latter, why wouldn't that be a good idea?
CVS should ignore whitespace differences.
Cheers!
Larry
On Sun, 22 Feb 2004, Mathieu Bouchard wrote:
On Sun, 22 Feb 2004, Larry Troxler wrote:
I brought this up a while ago, complaining about people still using hard tabs in source code. [...] but hard tabs are very, very bad, unless you're programming on a C64 and need to conserve floppy space.
You make it seems like it was a completely outdated that only a few rare programmers would use, out of nostalgia. However many rather recent (and sometimes huge) projects have hard tabs as their only allowed indentation.
(quoting notes.txt): -------------------------------------------- 1.5. Spacing. Tabs are 8 spaces; indentation is 4 spaces. Indenting curly brackets are by themselves on their own lines, as in:
if (x) { x = 0; }
Lines should fit within 80 spaces. -------------------------------------------
So the rules are set. Although IMO it leaves a bit room for interpretation, but I understand it as using spaces only.
Guenter
IMO If a programmer insists on using hard tabs, he or she should put a comment at the top of the source file specifying the tab spacing.
There are two usual ways of thinking of hard tabs:
- One tab per indentation level. All hard tabs are at the beginning of
lines: no tabs in the middle. This allows the tabwidth to be customized to whatever value without the code looking too weird.
- The church of EMACS: hard tabs don't exist in the editor, but they
are used in files to save space. Tab width is always 8 here.
Frankly I'm more of a (1) guy, and so is (for example) the source code of the Linux kernel... but even then, playing around with a lot of different projects (many of which CVS'd), one cannot have everything in his own indentation style, and in a CVS context it pays more to keep each chunk of code in whatever format it's written it.
I don't know if this is the problem in this case. In the mean time, someone mentioned a switch for CVS to ignore whitespace - I don't remember it this applied to checkin, checkout, or both. Really, whitespace and newline differences should be none of the version control system's business, but I don't know how Sourceforge is configured by default.
What do you mean that it's none of its business, that it should ignore whitespace, or that it should not change from its current behaviour? And if the latter, why wouldn't that be a good idea?
Mathieu Bouchard http://artengine.ca/matju
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Sun, 22 Feb 2004, Mathieu Bouchard wrote:
On Sun, 22 Feb 2004, guenter geiger wrote:
On Sun, 22 Feb 2004, Mathieu Bouchard wrote:
I think I fixed it, by committing older versions back on top of my versions. In any case, I think I had to tell you...
Ok, thanks, everything seems to be ok. I updated the HEAD to 0.37-1test6 and merged in the changes from millers version into devel_0_37.
Ok, I have three questions:
- All those changes you just merged in seem to have changed almost
every line in a lot of files. I thought it could be something like messing with newline codes or switching between tabs and spaces, but it seems that lines that only have one brace on it don't get modified. What is this? Is it a change of indentation style? I usually try to avoid those, as they make it more difficult to apply diffs / merge branches... What is your opinion on this?
My opinion on this is that you are wrong, please see the attched pd-merge file to get an idea about what was changed.
Question 2: Johannes handles the mailing lists at IEM Question 3: The easiest solution would be to have the CVS somewhere else. The BEST solution would be to have it at Millers place.
Guenter
- I got several mails from pd-cvs saying my messages (sent from cvs
commit) were frozen waiting for moderator approval. Who is in charge of approving those?
- How often does SourceForge update their mirrors? is it every 2 or 4
hours or...? Because I work with people who don't have dev accounts and somehow it ain't quite as snappy in SourceForge than on Artengine's CVS (that doesn't use mirrors/delays). How do you people do? Do you send temporary diffs by email?
Mathieu Bouchard http://artengine.ca/matju
On Sun, 22 Feb 2004, guenter geiger wrote:
On Sun, 22 Feb 2004, Mathieu Bouchard wrote:
Ok, I have three questions:
- All those changes you just merged in seem to have changed almost
every line in a lot of files. I thought it could be something like messing with newline codes or switching between tabs and spaces, but it seems that lines that only have one brace on it don't get modified. What is this? Is it a change of indentation style? I usually try to avoid those, as they make it more difficult to apply diffs / merge branches... What is your opinion on this?
My opinion on this is that you are wrong, please see the attched pd-merge file to get an idea about what was changed.
Ok, is it possible that the cvs->mail tool gets some stuff wrong? what options does it use with "diff" ?
Question 3: The easiest solution would be to have the CVS somewhere else. The BEST solution would be to have it at Millers place.
Any updates on this? when would this be done?
I'm also pretty sure that Artengine.CA would be very pleased to host the CVS, but I don't want to make it look like a takeover ;-)
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
On Fri, 5 Mar 2004, Mathieu Bouchard wrote:
On Sun, 22 Feb 2004, guenter geiger wrote:
On Sun, 22 Feb 2004, Mathieu Bouchard wrote:
Ok, I have three questions:
- All those changes you just merged in seem to have changed almost
every line in a lot of files. I thought it could be something like messing with newline codes or switching between tabs and spaces, but it seems that lines that only have one brace on it don't get modified. What is this? Is it a change of indentation style? I usually try to avoid those, as they make it more difficult to apply diffs / merge branches... What is your opinion on this?
My opinion on this is that you are wrong, please see the attched pd-merge file to get an idea about what was changed.
Ok, is it possible that the cvs->mail tool gets some stuff wrong? what options does it use with "diff" ?
Question 3: The easiest solution would be to have the CVS somewhere else. The BEST solution would be to have it at Millers place.
Any updates on this? when would this be done?
I'm also pretty sure that Artengine.CA would be very pleased to host the CVS, but I don't want to make it look like a takeover ;-)
Well, this is actually the main problem. I have tried hard to make clear that the CVS is not trying to split from pd, but it is trying to help and coordinate the different improvment efforts.
The problem is not the bandwith or server space, its a political one, and the last thing that I want to happen is that pd gets split.
Finally, I do not know how Miller thinks about all of this.
So, chances that anything will change are slim :(
Guenter
Oh, well, first I have to learn how CVS works (particularly in its social aspect)... I don't have any opinions yet...
cheers Miller
On Mon, Mar 08, 2004 at 01:15:50AM +0100, guenter geiger wrote:
On Fri, 5 Mar 2004, Mathieu Bouchard wrote:
On Sun, 22 Feb 2004, guenter geiger wrote:
On Sun, 22 Feb 2004, Mathieu Bouchard wrote:
Ok, I have three questions:
- All those changes you just merged in seem to have changed almost
every line in a lot of files. I thought it could be something like messing with newline codes or switching between tabs and spaces, but it seems that lines that only have one brace on it don't get modified. What is this? Is it a change of indentation style? I usually try to avoid those, as they make it more difficult to apply diffs / merge branches... What is your opinion on this?
My opinion on this is that you are wrong, please see the attched pd-merge file to get an idea about what was changed.
Ok, is it possible that the cvs->mail tool gets some stuff wrong? what options does it use with "diff" ?
Question 3: The easiest solution would be to have the CVS somewhere else. The BEST solution would be to have it at Millers place.
Any updates on this? when would this be done?
I'm also pretty sure that Artengine.CA would be very pleased to host the CVS, but I don't want to make it look like a takeover ;-)
Well, this is actually the main problem. I have tried hard to make clear that the CVS is not trying to split from pd, but it is trying to help and coordinate the different improvment efforts.
The problem is not the bandwith or server space, its a political one, and the last thing that I want to happen is that pd gets split.
Finally, I do not know how Miller thinks about all of this.
So, chances that anything will change are slim :(
Guenter
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
Oh, well, first I have to learn how CVS works (particularly in its social aspect)... I don't have any opinions yet...
Recently I've found this introduction to version control systems, which is explaining Subversion, not CVS, but still gets a lot of the social things right:
http://svnbook.red-bean.com/html-chunk/ch02.html
ciao
On Mon, 8 Mar 2004, guenter geiger wrote:
On Fri, 5 Mar 2004, Mathieu Bouchard wrote:
Question 3: The easiest solution would be to have the CVS somewhere else. The BEST solution would be to have it at Millers place.
Any updates on this? when would this be done? I'm also pretty sure that Artengine.CA would be very pleased to host the CVS, but I don't want to make it look like a takeover ;-)
Well, this is actually the main problem. I have tried hard to make clear that the CVS is not trying to split from pd, but it is trying to help and coordinate the different improvment efforts. The problem is not the bandwith or server space, its a political one, and the last thing that I want to happen is that pd gets split.
As long as it's clear, it's fine with me. Hosting is supposed to be first and foremost a service. I don't mean it as a way of imposing anything, like deciding who gets a developer account and such. Whoever does the hosting should be neutral.
Note that although I make impd and am associated with Artengine, and although people at Artengine are likely to be quite enthusiastic about impd, Artengine is first a not-for-profit organisation and a hosting service for artists, and just like they let their artists do pretty much what they want, they wouldn't interfere with the existing developer team.
I am not suggesting that we should move the CVS to Artengine, only that it's possible to do so and it wouldn't be bad. However, centralization sometimes makes things simpler, and so, it would probably be better to cluster the CVS services with other services, and so IEM.At might be a better candidate.
The complain I heard the most about SourceForget is that their anonymous-cvs servers are saturated. That's mostly over these days (I don't know for how long). The second complain, which is a current one, is about how they fixed this first problem... they use a delayed mirroring system, which means I can't interact with anonymous-cvs users the way I'd do it on another similar system, because there's a delay of several hours for the mirroring. (I don't know how long exactly; the worst case is at most 24 hours, but it's often quicker)
Now that I think of it, there's a workaround, which is that everyone who wants no-delay CVS would get a SourceForget account. There is little barrier to entry, AFAIK, except that it's annoying, and it inflates SourceForget's developer count figures =)
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
Mathieu Bouchard wrote:
On Sun, 22 Feb 2004, guenter geiger wrote:
Ok, I have three questions:
- I got several mails from pd-cvs saying my messages (sent from cvs
commit) were frozen waiting for moderator approval. Who is in charge of approving those?
me.
access to the pd-cvs mailing-list is restricted to members of pd@sf. when checking things into the cvs, a mail is autogenerated at sourceforge. there are 2 drawbacks: a) the mails generated have a "from:"-field with individual addresses for all sf-users. b) i have no possibility to allow posting for all sourceforge-accounts (due to our list-server)
thus i have to add cvs'ers by hand to the allowed senders of pd-cvs. i do this when i get approval-requests, which i accept (this is different to the other pd-lists, where i never accept postings that are held for approval)
matju-AT-users-DOT-sourceforge-DOT-net has thus been already added. sorry for any inconvenience.
mfg.a.sdr IOhannes
-
Chris McCormick -
Frank Barknecht -
guenter geiger -
IOhannes m zmoelnig -
Larry Troxler -
Mathieu Bouchard -
Miller Puckette