hi sf-admins...
talking with thomas and iohannes from the iem on irc, i realized, that i'm not a complete sf admin ...
could one of you commit this: --- avail.~1.10.~ 2004-12-17 07:42:50.000000000 +0100 +++ avail 2005-03-01 16:47:08.911396176 +0100 @@ -20,8 +20,10 @@ # so changes here would have to be merged unavail | | externals/maxlib avail | eighthave,olafmatt | externals/maxlib + +# at thomas musil's request only he will be able to work on the iemlib unavail | | externals/iemlib -avail | eighthave,zmoelnig | externals/iemlib +avail | tmusil | externals/iemlib
# restrict the MAIN branch of "pd" to prevent accidental # commits that should go to devel_0_37 or impd_0_37 @@ -30,4 +32,4 @@
# this line ALWAYS needs to be the last line in this file # otherwise, its possible to lock everyone out of the CVS -avail | adamlindsay,eighthave,fbar,ggeiger,millerpuckette | CVSROOT +avail | adamlindsay,eighthave,fbar,ggeiger,millerpuckette,timblech | CVSROOT
to CVSROOT/avail?
thanks ... tim
First off, you should _always_ post to the pd-dev list before making any changes to that file. Period. That goes for any of the files in CVSROOT. Its too easy to seriously break things by editing those files. And you should have confirmation from all those involved that its ok.
Second, "tmusil" is not an existing user. If Thomas wants to maintain iemlib in the sourceforge CVS, that would be great. But just locking everyone out of the iemlib directory is not helpful to anyone.
For iemlib, I imported the IEM sources so that they could be part of the build system. This was discussed on this list. I put on access restrictions so that people wouldn't mistakenly commit to iemlib there since its maintained elsewhere. If someone wants to work on iemlib in the SourceForge CVS, they can make a branch, then submit patches.
.hc
On Mar 1, 2005, at 10:55 AM, Tim Blechmann wrote:
hi sf-admins...
talking with thomas and iohannes from the iem on irc, i realized, that i'm not a complete sf admin ...
could one of you commit this: --- avail.~1.10.~ 2004-12-17 07:42:50.000000000 +0100 +++ avail 2005-03-01 16:47:08.911396176 +0100 @@ -20,8 +20,10 @@ # so changes here would have to be merged unavail | | externals/maxlib avail | eighthave,olafmatt | externals/maxlib
+# at thomas musil's request only he will be able to work on the iemlib unavail | | externals/iemlib -avail | eighthave,zmoelnig | externals/iemlib +avail | tmusil | externals/iemlib
# restrict the MAIN branch of "pd" to prevent accidental # commits that should go to devel_0_37 or impd_0_37 @@ -30,4 +32,4 @@
# this line ALWAYS needs to be the last line in this file # otherwise, its possible to lock everyone out of the CVS -avail | adamlindsay,eighthave,fbar,ggeiger,millerpuckette | CVSROOT +avail | adamlindsay,eighthave,fbar,ggeiger,millerpuckette,timblech | CVSROOT
to CVSROOT/avail?
thanks ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
________________________________________________________________________ ____
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it."
- Thomas Jefferson
Hans-Christoph Steiner wrote:
First off, you should _always_ post to the pd-dev list before making any changes to that file. Period. That goes for any of the files in CVSROOT. Its too easy to seriously break things by editing those files. And you should have confirmation from all those involved that its ok.
true
Second, "tmusil" is not an existing user. If Thomas wants to maintain
wrong, we just created that user (on sf) yesterday; i told tim to add "tmusil" _after_ the user was created. since tim was not able to add him to the devs, i added him to pd-gem in the meantime, which worked like a charm (about 14h ago) (to all gem-devs: this is just temporary so i could help him to set up his ssh-keys)
iemlib in the sourceforge CVS, that would be great. But just locking
yes
everyone out of the iemlib directory is not helpful to anyone.
of course i cannot speak for thomas, but: he prefers to be the sole maintainer of his sources. i agree that this is not very like "community based development", but this is how things are. there are other people with the same policy (e.g. like tom who is just mirroring his own cvs into pure-data)
therefore i asked tim on the irc (because he was the only admin online) to make the iemlib's readonly (except for thomas who should have write-perms of course)
For iemlib, I imported the IEM sources so that they could be part of the build system. This was discussed on this list. I put on access restrictions so that people wouldn't mistakenly commit to iemlib there since its maintained elsewhere. If someone wants to work on iemlib in the SourceForge CVS, they can make a branch, then submit patches.
which is perfectly ok.
it is just to ensure that no one fu**s up tom's sources, or at least _his_ MAIN branch (either by accident or evil purpose (i do know that this sounds paranoid, but there is no arguing about that; tom's reason to _not_ use the puredata-CVS for so long has been born from this fear - after he had his first look at the CVS-version of pd itself and what people had done to it))
please do accept other people's attitudes.
mfg.ad.r IOhannes
Hi,
I think there is no reason for thomas to fear (man cvs). The CVS is a place for collaboration, not a marketplace for externals. If Thomas doesn't want to collaborate, then why does he want to put his externals there ? Did you talk him into that, or is it his own decision ? There is also no reason for his paranoia, obviously he did not understand what the purpose of the devel version of pd is.
Since the existance of CVS there has not been a single case where we had problems.
Anyhow, I think giving Tim the administrative rights is a good idea.
Guenter
On Wed, 2 Mar 2005, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
First off, you should _always_ post to the pd-dev list before making any changes to that file. Period. That goes for any of the files in CVSROOT. Its too easy to seriously break things by editing those files. And you should have confirmation from all those involved that its ok.
true
Second, "tmusil" is not an existing user. If Thomas wants to maintain
wrong, we just created that user (on sf) yesterday; i told tim to add "tmusil" _after_ the user was created. since tim was not able to add him to the devs, i added him to pd-gem in the meantime, which worked like a charm (about 14h ago) (to all gem-devs: this is just temporary so i could help him to set up his ssh-keys)
iemlib in the sourceforge CVS, that would be great. But just locking
yes
everyone out of the iemlib directory is not helpful to anyone.
of course i cannot speak for thomas, but: he prefers to be the sole maintainer of his sources. i agree that this is not very like "community based development", but this is how things are. there are other people with the same policy (e.g. like tom who is just mirroring his own cvs into pure-data)
therefore i asked tim on the irc (because he was the only admin online) to make the iemlib's readonly (except for thomas who should have write-perms of course)
For iemlib, I imported the IEM sources so that they could be part of the build system. This was discussed on this list. I put on access restrictions so that people wouldn't mistakenly commit to iemlib there since its maintained elsewhere. If someone wants to work on iemlib in the SourceForge CVS, they can make a branch, then submit patches.
which is perfectly ok.
it is just to ensure that no one fu**s up tom's sources, or at least _his_ MAIN branch (either by accident or evil purpose (i do know that this sounds paranoid, but there is no arguing about that; tom's reason to _not_ use the puredata-CVS for so long has been born from this fear - after he had his first look at the CVS-version of pd itself and what people had done to it))
please do accept other people's attitudes.
mfg.ad.r IOhannes
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
I think there is no reason for thomas to fear (man cvs). The CVS is a place for collaboration, not a marketplace for externals. If Thomas doesn't want to collaborate, then why does he want to put his externals there ?
for pd, the cvs is both ... the external build system is the best way to get most of the important externals ...
cheers .... t
� wrote:
Hi,
I think there is no reason for thomas to fear (man cvs). The CVS is a
i do not know a way to explain fear. but i don't think "man cvs" will help. (nor does "man freedom")
place for collaboration, not a marketplace for externals. If Thomas
aren't there projects there that are already read-only for other devs ? why ? what makes tom schouten's approach better (sorry ts that i keep abusing your way of usage: no criticism intended): overwriting any changes made to the CVS via a daily cron-job ?
doesn't want to collaborate, then why does he want to put his externals there ? Did you talk him into that, or is it his own decision ?
we talked him into that. we are currently restructuring development at the iem (this is: using collaborative development of projects with cvs-alike systems). we try to minimize administrative overhead: for us of course; but also for other people who obviously felt the need to put "iemlib" into the CVS (which i think was a good idea) and who now have to manually (or scripted or ...) sync it with the releases.
There is also no reason for his paranoia, obviously he did not understand what the purpose of the devel version of pd is.
i told him so
Since the existance of CVS there has not been a single case where we had problems.
i know
still, why should it not be possible for tm if it is possible ?
mfg.asd.r IOhannes
On Wed, 2 Mar 2005, IOhannes m zmoelnig wrote:
� wrote:
Hi,
I think there is no reason for thomas to fear (man cvs). The CVS is a
i do not know a way to explain fear. but i don't think "man cvs" will help. (nor does "man freedom")
place for collaboration, not a marketplace for externals. If Thomas
aren't there projects there that are already read-only for other devs ? why ? what makes tom schouten's approach better (sorry ts that i keep abusing your way of usage: no criticism intended): overwriting any changes made to the CVS via a daily cron-job ?
I think there is nothing better with tom shouten's approach. It is a great achievment having Thomas' code directly in CVS, but the way it is done could have been better.
Anyhow, who cares,
Guenter
doesn't want to collaborate, then why does he want to put his externals there ? Did you talk him into that, or is it his own decision ?
we talked him into that. we are currently restructuring development at the iem (this is: using collaborative development of projects with cvs-alike systems). we try to minimize administrative overhead: for us of course; but also for other people who obviously felt the need to put "iemlib" into the CVS (which i think was a good idea) and who now have to manually (or scripted or ...) sync it with the releases.
There is also no reason for his paranoia, obviously he did not understand what the purpose of the devel version of pd is.
i told him so
Since the existance of CVS there has not been a single case where we had problems.
i know
still, why should it not be possible for tm if it is possible ?
mfg.asd.r IOhannes
Hello,
I think there is no reason for thomas to fear (man cvs). The CVS is a
i do not know a way to explain fear. but i don't think "man cvs" will help. (nor does "man freedom")
place for collaboration, not a marketplace for externals. If Thomas
aren't there projects there that are already read-only for other devs ? why ? what makes tom schouten's approach better (sorry ts that i keep abusing your way of usage: no criticism intended): overwriting any changes made to the CVS via a daily cron-job ?
I think there is nothing better with tom shouten's approach. It is a great achievment having Thomas' code directly in CVS, but the way it is done could have been better.
Anyhow, who cares,
we care ;-)))
Anyway, there was a solution that there is a main branch in PD, where miller checks in his version and there is a dev tree as a branch. So Thomas thinks the same modell is good for his iemlib.
I think its good to have iemlib not just as a forgotten copy in cvs but the main branch lively patched and growing. And anybody can make branches and they can be merged in, if it makes sense. If there is another main developer of iemlib he also get the rights for the main branch. I always thought that is the way it works on sourceforge. I dont think it makes sense we set up a own sourceforge project page since everyone is sharing source here.
mfg winfried ritsch
PS: Beside I suspect OpenSource is already a marketing modell and sourceforge is a marketingplace for that.
Well, the last thing that I wanted to do was start a flame war... my only point is that the CVS is a group environment, and we need to respect and communicate with each other. It sounds like Thomas Musil is going to maintain iemlib in the SourceForge CVS, that is great, that makes me happy and its less work for me. The problem is that there was zero communication about the change with pd-dev or me, who imported those sources.
Now that this is clear, I think there is no problem changing the CVS ACLs. I just committed the change. A little bit of communication beforehand would have saved us this storm of email. Communication is key to making collaboration work.
I would like to add my two bits about working in CVS. I think locking everyone out of iemlib is bad idea if that code is indeed going to be maintained in the SourceForge CVS. The code that does have access restrictions has them because that code is just imported from somewhere else, so directly modifying the code in the SourceForge CVS doesn't make sense.
But if iemlib commit access is not restricted, then people can fix minor bugs, typos, etc. without a whole patch process, and therefore will be much more likely to do so. For example, I probably wouldn't bother to make a patch to fix a typo, but I would make the change and commit it, if I could. _All_ changes in CVS are easily tracked, easily reversible and announced to the pd-cvs list, so recovering from disasterous commits is quite easy.
And lastly, I must say, being an admin means that you need to take the extra effort to communicate, especially when editing CVSROOT files, which affect everyone. Personally, this episode makes me a bit concerned that Tim is a bit too quick to act without considering the repercussions, so I would rather wait a bit before granting him full access. That's just my two bits, it is, of course, a community decision.
.hc
On Mar 2, 2005, at 8:01 AM, Winfried Ritsch wrote:
Hello,
I think there is no reason for thomas to fear (man cvs). The CVS is a
i do not know a way to explain fear. but i don't think "man cvs" will help. (nor does "man freedom")
place for collaboration, not a marketplace for externals. If Thomas
aren't there projects there that are already read-only for other devs ? why ? what makes tom schouten's approach better (sorry ts that i keep abusing your way of usage: no criticism intended): overwriting any changes made to the CVS via a daily cron-job ?
I think there is nothing better with tom shouten's approach. It is a great achievment having Thomas' code directly in CVS, but the way it is done could have been better.
Anyhow, who cares,
we care ;-)))
Anyway, there was a solution that there is a main branch in PD, where miller checks in his version and there is a dev tree as a branch. So Thomas thinks the same modell is good for his iemlib.
I think its good to have iemlib not just as a forgotten copy in cvs but the main branch lively patched and growing. And anybody can make branches and they can be merged in, if it makes sense. If there is another main developer of iemlib he also get the rights for the main branch. I always thought that is the way it works on sourceforge. I dont think it makes sense we set up a own sourceforge project page since everyone is sharing source here.
mfg winfried ritsch
PS: Beside I suspect OpenSource is already a marketing modell and sourceforge is a marketingplace for that.
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste
which affect everyone. Personally, this episode makes me a bit concerned that Tim is a bit too quick to act without considering the repercussions, so I would rather wait a bit before granting him full access. That's just my two bits, it is, of course, a community decision.
no problem with me ... maybe it's better to give my admin account to iohannes or someone else from the iem ...
since the iem is _the_ institution supporting pd and a lot of development is done there, it's kind of silly, that i'm admin, but none from the iem ...
so kill my account and add iohannes or someone from the iem ...
i really don't want to make any trouble to anyone
t
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
no problem with me ... maybe it's better to give my admin account to iohannes or someone else from the iem ...
since the iem is _the_ institution supporting pd and a lot of development is done there, it's kind of silly, that i'm admin, but none from the iem ...
so kill my account and add iohannes or someone from the iem ...
i really don't want to make any trouble to anyone
I think, this issue should cool down a bit first. I totally agree with Hans, that a change to files like those in CVSROOT should be discussed openly before this is done. Nothing is gained by quickly changing something, but it's possible to break other people's work habits by doing this to fast.
However of course we also need to find out which issues are those issues that need an open discussion first. In this regard I would say, that unless something was already discussed, it should be discussed if there could be doubts about the opinions of the other developers and admins.
This of course applies to the "who is an admin" question or more widely to the "who should be a registered developer" question. Before I added you to be an admin I mailed the other admins and asked if that would be okay or if someone objects to this. Noone objected, some agreed through silence, some agreed explicitly to my question. IMO this habit of "first ask, then act" should go without saying. I always announced beforehandi here, if I intended to add someone as a developer to the repository.
Things like this must be made open on this list or at least to all admins before action is taken, period. I'm sure you also understand this, even if this issue is a bit "flamy" here currently. But this is the common ground for a project like the repository, and it is important that everyone involved understands and adheres to it.
Ciao
On Mar 2, 2005, at 1:17 PM, Tim Blechmann wrote:
which affect everyone. Personally, this episode makes me a bit concerned that Tim is a bit too quick to act without considering the repercussions, so I would rather wait a bit before granting him full access. That's just my two bits, it is, of course, a community decision.
no problem with me ... maybe it's better to give my admin account to iohannes or someone else from the iem ...
since the iem is _the_ institution supporting pd and a lot of development is done there, it's kind of silly, that i'm admin, but none from the iem ...
so kill my account and add iohannes or someone from the iem ...
i really don't want to make any trouble to anyone
First and foremost, your work is much appreciated for sure, don't get me wrong, I don't want to cast doubt on that. I just think you should ease into the admin role a bit more slowly.
Since most of these roles involve work that usually isn't fun, people have been volunteering to take them on, just like you did. So far, no one from IEM has volunteered to be an admin on the SourceForge site and I think that is the only reason why there isn't an IEM person there. FWIW, guenter was at IEM when the admins for the site were set up.
.hc
t
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
________________________________________________________________________ ____
"The arc of history bends towards justice." Dr. Martin Luther King, Jr.
Hans-Christoph Steiner wrote:
Since most of these roles involve work that usually isn't fun, people have been volunteering to take them on, just like you did. So far, no one from IEM has volunteered to be an admin on the SourceForge site and I think that is the only reason why there isn't an IEM person there. FWIW, guenter was at IEM when the admins for the site were set up.
well, so probably it _is_ a good idea to add one of us to the admins. i'd volunteer to be the "iem-person" (and even "private")
if this is ok for all of you, i would then opt to not get write access to the CVSROOT in the first place ;-)
mfg.ads.r IOhannes
On Fri, 4 Mar 2005, IOhannes m zmoelnig wrote:
well, so probably it _is_ a good idea to add one of us to the admins. i'd volunteer to be the "iem-person" (and even "private")
if this is ok for all of you, i would then opt to not get write access to the CVSROOT in the first place ;-)
Seems that noone subjects, so I add you as an administrator.
Guenter
On Wed, 2 Mar 2005, Winfried Ritsch wrote:
Anyhow, who cares,
we care ;-)))
Ok, thats a good point to start. I hope that we can also resolve the "gate" nameclash sometime in the future.
Guenter
Anyway, there was a solution that there is a main branch in PD, where miller checks in his version and there is a dev tree as a branch. So Thomas thinks the same modell is good for his iemlib.
I think its good to have iemlib not just as a forgotten copy in cvs but the main branch lively patched and growing. And anybody can make branches and they can be merged in, if it makes sense. If there is another main developer of iemlib he also get the rights for the main branch. I always thought that is the way it works on sourceforge. I dont think it makes sense we set up a own sourceforge project page since everyone is sharing source here.
mfg winfried ritsch
PS: Beside I suspect OpenSource is already a marketing modell and sourceforge is a marketingplace for that.
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
hi Winfried,
Winfried Ritsch wrote: ...
Ok, thats a good point to start. I hope that we can also resolve the "gate" nameclash sometime in the future.
yes and thats not the only one we have on the iem, the matrix stuff will be solved soon too....
does it involve cyclone's gate and matrix~, or all you are talking about are intra-iem clashes?
Krzysztof
Hello,
Winfried Ritsch wrote: ...
Ok, thats a good point to start. I hope that we can also resolve the "gate" nameclash sometime in the future.
yes and thats not the only one we have on the iem, the matrix stuff will be solved soon too....
does it involve cyclone's gate and matrix~, or all you are talking about are intra-iem clashes?
yes and yes.
mfg winfried
Winfried Ritsch wrote:
does it involve cyclone's gate and matrix~, or all you are talking about are intra-iem clashes?
yes and yes.
no and no ;-)
it involves cyclone's and iemlib's [gate].
the [matrix~] clashes wini was talking about were not name-clashes (yes i know that there is a conflict between zexy and cyclone) but rather inconsistancies between my object and tm's objects.
these will be hopefully be fixed soon in a "iemtx" (or alike) library. while moving the objects to the new lib and resolving the inconsistancies (as far as they are solvable) most objects will be renamed (although the old deprecated names will still have to stay there for compatibility): so (zexy's) [matrix~] will (on the long run) disappear and be replaced by something like [mtx_*~].
jfyi: the major inconsistancy with zexy's [matrix~] is, that when multiplying a vector of signals with a matrix the actual operation that takes place is "x^ = a^ * A", while in literature normally we find things like "y^ = B * b^", which is only the same if we assume x^=y^' and A=B'.
anyone has an idea how to find an elegant solution to this problem (while still maintaining an intuitive object) ?
mfg.ad.r IOhannes
PS: so wini's "yes and yes" was right, although the [matrix~] issue is rather a side effect
On Thu, 3 Mar 2005, IOhannes m zmoelnig wrote:
Winfried Ritsch wrote: jfyi: the major inconsistancy with zexy's [matrix~] is, that when multiplying a vector of signals with a matrix the actual operation that takes place is "x^ = a^ * A", while in literature normally we find things like "y^ = B * b^", which is only the same if we assume x^=y^' and A=B'.
GridFlow's @inner was originally doing something like the latter, actually R = A*transpose(B), of which the latter is a special case (because of the commutativity of Real Dot Product).
At a certain point in 2002, I changed it so that @inner is R=A*B, and @inner2 is R=A*transpose(B). In the new system (2005) there is #inner and #transpose.
The other differences are that matrix~ is for signals only, and handles only two dimensions.
anyone has an idea how to find an elegant solution to this problem (while still maintaining an intuitive object) ?
just write your matrices pretransposed.
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
yes and thats not the only one we have on the iem, the matrix stuff will be solved soon too....
does it involve cyclone's gate and matrix~, or all you are talking about are intra-iem clashes?
for the record ... cyclone/date vs. zexy/date ...
maybe it's a good idea to add a wiki to puredata.org to collect / discuss nameclashes ....
t
Tim Blechmann wrote:
for the record ... cyclone/date vs. zexy/date ...
just to get not annoyed: i checked cyclone out of the CVS and found [date] in shadow/dummies.
how should this be resolved ? throwing it out of zexy would result in a non-functional object.
i am really tired of all those zexy objects in max. probably i should go and talk to them.
mfg.a.dsr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
just to get not annoyed: i checked cyclone out of the CVS and found [date] in shadow/dummies.
IIRC then it will only load if Cyclone is loaded as lirbary and in "max-compatibility" mode, so it's not a "real" nameclash.
Ciao
just to get not annoyed: i checked cyclone out of the CVS and found [date] in shadow/dummies.
IIRC then it will only load if Cyclone is loaded as lirbary and in "max-compatibility" mode, so it's not a "real" nameclash.
since i installed cyclone and zexy as libraries from the cvs and wasn't able to access zexy's date without changing the loading order, i consider it as name clash!
t
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
just to get not annoyed: i checked cyclone out of the CVS and found [date] in shadow/dummies.
IIRC then it will only load if Cyclone is loaded as lirbary and in "max-compatibility" mode, so it's not a "real" nameclash.
since i installed cyclone and zexy as libraries from the cvs and wasn't able to access zexy's date without changing the loading order, i consider it as name clash!
Maybe then I did Not Remember Correctly how max-compatibility mode in Cyclone works. Sorry, I've got no time for a deep check now, but the docs say this:
DONE for cyclone ... alpha51 * dummies loaded by maxmode, not cyclone ... alpha50 * max-compatibility mode switch for cyclone . turned on by loading cyclone libs through "-lib maxmode" . affects max-compatibility of prepend and Append, controls compatibility warnings ...
As I understood this, dummies are only to be loaded if "-lib maxmode" is used. If A) it does work this way and if B) [date] is such a dummy, then we do not have a nameclash. If not A) and B) then Nameclash.
Ciao
Frank Barknecht wrote: ...
As I understood this, dummies are only to be loaded if "-lib maxmode" is used. If A) it does work this way and if B) [date] is such a dummy, then we do not have a nameclash. If not A) and B) then Nameclash.
yes, dummies are now loaded only in maxmode, and I think Tim is using an older cyclone version. Some of them, those unlikely to ever be cloned, have names prefixed with "c74." Others may clash in maxmode, which is potentially harmful, because cyclone's modes are global, currently.
There should be a possibility of resolving class names in abstraction scope, and in a persistent way. I will try to describe a simple scheme in a separate posting.
Dummies were introduced for two reasons. One was preserving connections of missing objects in imported patches. Since Pd .38, this is no longer a valid reason. The second one was making inter-platform name clashes explicit. This is still a valid reason, but how important it is, who knows...
It all depends on whether computer music people actually want to have common standards for basic things.
Krzysztof
yes, dummies are now loaded only in maxmode, and I think Tim is using an older cyclone version. Some of them, those unlikely to ever be cloned, have names prefixed with "c74." Others may clash in maxmode, which is potentially harmful, because cyclone's modes are global, currently.
checked out last week ... t
hi Tim,
would you mind checking for the version in the welcome-warning message? The miXed externals have to be manually installed, unless .../miXed/bin is in the -path.
Anyway, there is no longer any reference to dummies in cyclone.c from cvs...
k
Tim Blechmann wrote:
yes, dummies are now loaded only in maxmode, and I think Tim is using an older cyclone version. Some of them, those unlikely to
...
checked out last week ... t
First off, you should _always_ post to the pd-dev list before making any changes to that file. Period. That goes for any of the files in CVSROOT. Its too easy to seriously break things by editing those files. And you should have confirmation from all those involved that its ok.
hans,
then please, YOU commit the following changes, too: --- cvswrappers.~1.4.~ 2005-03-01 16:35:16.000000000 +0100 +++ cvswrappers 2005-03-02 08:52:02.664068016 +0100 @@ -80,3 +80,6 @@
# MACOS X FILES *.pmsp -k 'b' + +# PD PATCHES +*.pd -k 'b'
On Wed, 2 Mar 2005, Tim Blechmann wrote:
then please, YOU commit the following changes, too:
there is no reason to shout. hc. is right, a case like this needs discussion.
Guenter
--- cvswrappers.~1.4.~ 2005-03-01 16:35:16.000000000 +0100 +++ cvswrappers 2005-03-02 08:52:02.664068016 +0100 @@ -80,3 +80,6 @@
# MACOS X FILES *.pmsp -k 'b'
+# PD PATCHES +*.pd -k 'b'
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
then please, YOU commit the following changes, too: --- cvswrappers.~1.4.~ 2005-03-01 16:35:16.000000000 +0100 +++ cvswrappers 2005-03-02 08:52:02.664068016 +0100 @@ -80,3 +80,6 @@
# MACOS X FILES *.pmsp -k 'b'
+# PD PATCHES +*.pd -k 'b'
Please NOT! (Sorry for shouting.)
There was a discussion here about this some time ago already and several people don't want these entries to appear in the CVS. You can always add them to your ~/.cvswrappers. I did. But adding them to SF is considered harmful.
Ciao
+# PD PATCHES +*.pd -k 'b'
Please NOT! (Sorry for shouting.)
There was a discussion here about this some time ago already and several people don't want these entries to appear in the CVS. You can always add them to your ~/.cvswrappers. I did. But adding them to SF is considered harmful.
well, iirc the conclusion of the discussion was that diffs of pd's file format are not human readable ... but i might be wrong ...
still, i work a lot with pd patches on cvs and i never was able to get useful information from a diff ...
t
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
well, iirc the conclusion of the discussion was that diffs of pd's file format are not human readable ... but i might be wrong ...
still, i work a lot with pd patches on cvs and i never was able to get useful information from a diff ...
Yes, me too, but still: some people don't want it for whatever reasons, so this should and must be kept a personal, not a system-wide setting.
Ciao
Yes, me too, but still: some people don't want it for whatever reasons, so this should and must be kept a personal, not a system-wide setting.
ok ... can the pd-cvs log be changed to a personal, not system-wide setting?
t
Tim Blechmann wrote:
Yes, me too, but still: some people don't want it for whatever reasons, so this should and must be kept a personal, not a system-wide setting.
ok ... can the pd-cvs log be changed to a personal, not system-wide setting?
t
so that i only get emails containing dirty words ? unfortunately not.
mfg.asd.gtz IOhannes
On Mar 2, 2005, at 4:40 AM, Tim Blechmann wrote:
+# PD PATCHES +*.pd -k 'b'
Please NOT! (Sorry for shouting.)
There was a discussion here about this some time ago already and several people don't want these entries to appear in the CVS. You can always add them to your ~/.cvswrappers. I did. But adding them to SF is considered harmful.
well, iirc the conclusion of the discussion was that diffs of pd's file format are not human readable ... but i might be wrong ...
still, i work a lot with pd patches on cvs and i never was able to get useful information from a diff ...
Please, read the archives on this one. This change does not do what you think it does. I really wish we didn't have to discuss this once every month or so. And yes, I use diffs on Pd patches frequenly.
.hc
t
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
________________________________________________________________________ ____
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it."
- Thomas Jefferson
-
Frank Barknecht -
g�nter geiger -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Krzysztof Czaja -
Mathieu Bouchard -
Tim Blechmann -
Winfried Ritsch