Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Its already is in CVS, as "sigpack", following the convention of the CVS having all lib/project folder names all lower case. Having both sIgpAck and sigpack will cause problems on case-aware filesystems used on Windows and Mac OS X since they are two folders with the exact same name in that situation.
Oh, damn! I hadn't seen this and wasn't following pd-cvs close enough.
(Btw: The lowercase-convention is already broken with "miXed", although I, too, generally prefer all-lowercase names. I asked Martin, what he would prefer.)
Plus, I see no need to have two copies of one project.
No, of course not.
It should be quite easy to make the sources that are in CVS already compile as a lib with the sp_ prefixes. You can do something like this to each source file, in this case externals/sigpack/source/chop~.c:
The version, I checked in, has all help files renamed and the "sp." replaced by "sp_" everywhere already.
Now, how should we proceed? (Better on pd-dev)
Ciao
On Jan 19, 2006, at 5:59 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Its already is in CVS, as "sigpack", following the convention of the CVS having all lib/project folder names all lower case. Having both sIgpAck and sigpack will cause problems on case-aware filesystems used on Windows and Mac OS X since they are two folders with the exact same name in that situation.
Oh, damn! I hadn't seen this and wasn't following pd-cvs close enough.
(Btw: The lowercase-convention is already broken with "miXed", although I, too, generally prefer all-lowercase names. I asked Martin, what he would prefer.)
Plus, I see no need to have two copies of one project.
No, of course not.
It should be quite easy to make the sources that are in CVS already compile as a lib with the sp_ prefixes. You can do something like this to each source file, in this case externals/sigpack/source/chop~.c:
The version, I checked in, has all help files renamed and the "sp." replaced by "sp_" everywhere already.
Now, how should we proceed? (Better on pd-dev)
If the changes that I mentioned in my previous email were made to the externals/sigpack code, then it would compile into a lib with the sp_ and compile into a libdir for Pd-extended.
I think that's the quickest route with the most flexibility.
.hc
________________________________________________________________________ ____
"Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies." - Amy Smith
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
If the changes that I mentioned in my previous email were made to the externals/sigpack code, then it would compile into a lib with the sp_ and compile into a libdir for Pd-extended.
The changes you proposed aren't necessary for the latest released source of sigpack.
I now removed all files in externals/sIgpAck, hopefully the directory will be gone with that, too.
I will later check in the newsest version of sIgpAck into the externals/sigpack directory and move all files to their new names.
Ciao
On Jan 20, 2006, at 1:38 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
If the changes that I mentioned in my previous email were made to the externals/sigpack code, then it would compile into a lib with the sp_ and compile into a libdir for Pd-extended.
The changes you proposed aren't necessary for the latest released source of sigpack.
I now removed all files in externals/sIgpAck, hopefully the directory will be gone with that, too.
"cvs update -P" will purge empty dirs. If you really want it deleted, you need to submit a SourceForge support request.
I will later check in the newsest version of sIgpAck into the externals/sigpack directory and move all files to their new names.
I'd prefer it if the file names stayed the same, otherwise that will break the Pd-extended stuff. The code in externals/sigpack is setup in the way sigpack was in its previous release, and in a way that's that everything else in CVS is. AFAIK, there are no libs in CVS that have prefixes like "sp_" in the filename. For the objects that have used prefixes, they were setup using "addcreator()" calls in C. Plus, I think that these prefixes should be deprecated since they are no longer necessary or useful.
.hc ________________________________________________________________________ ____
"I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits." - Martin Luther King, Jr.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I'd prefer it if the file names stayed the same, otherwise that will break the Pd-extended stuff. The code in externals/sigpack is setup in the way sigpack was in its previous release, and in a way that's that everything else in CVS is. AFAIK, there are no libs in CVS that have prefixes like "sp_" in the filename.
If I understand this correctly, the sigpack externals in CVS now behave differently and have different names than the externals on Martin's page? I don't like this, it is something that should be avoided, IMO, unless there is a very good reason, so this should be sorted out somehow.
Ciao
On Jan 20, 2006, at 12:40 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I'd prefer it if the file names stayed the same, otherwise that will break the Pd-extended stuff. The code in externals/sigpack is setup in the way sigpack was in its previous release, and in a way that's that everything else in CVS is. AFAIK, there are no libs in CVS that have prefixes like "sp_" in the filename.
If I understand this correctly, the sigpack externals in CVS now behave differently and have different names than the externals on Martin's page? I don't like this, it is something that should be avoided, IMO, unless there is a very good reason, so this should be sorted out somehow.
They should behave exactly the same, since the code is exactly same. The prefix to the name is the only difference.
Since the sp_ prefix is a recent switch for Martin AFAIK, I hope I can convince everyone that its a bad thing with the namespaces, or at best unnecessary. If people want the lib with prefixes, that's fine, and my proposed changes will accommodate both ways of working quite cleanly. I just hope that Martin will accept them.
.hc
________________________________________________________________________ ____
"Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism." - retired U.S. Army general, William Odom
Hans-Christoph Steiner schrieb:
On Jan 20, 2006, at 12:40 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I'd prefer it if the file names stayed the same, otherwise that will break the Pd-extended stuff. The code in externals/sigpack is setup in the way sigpack was in its previous release, and in a way that's that everything else in CVS is. AFAIK, there are no libs in CVS that have prefixes like "sp_" in the filename.
If I understand this correctly, the sigpack externals in CVS now behave differently and have different names than the externals on Martin's page? I don't like this, it is something that should be avoided, IMO, unless there is a very good reason, so this should be sorted out somehow.
They should behave exactly the same, since the code is exactly same. The prefix to the name is the only difference.
Since the sp_ prefix is a recent switch for Martin AFAIK, I hope I can convince everyone that its a bad thing with the namespaces, or at best unnecessary. If people want the lib with prefixes, that's fine, and my proposed changes will accommodate both ways of working quite cleanly. I just hope that Martin will accept them.
.hc
"Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism." - retired U.S. Army general, William Odom
salut if both ways working doesnt this make things a little bit confusing? you can compile it as lib with or without or as single objects with or without and why is a prefix bad? i ve done the namespace prefix only to avoid nameclashin for example the round~ object it exists also in iemlib and cyclone just wanna use all round objects and just want to make developping for me easier gruss m.weiss
On Jan 21, 2006, at 2:01 PM, m.weiss wrote:
Hans-Christoph Steiner schrieb:
On Jan 20, 2006, at 12:40 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I'd prefer it if the file names stayed the same, otherwise that will break the Pd-extended stuff. The code in externals/sigpack is setup in the way sigpack was in its previous release, and in a way that's that everything else in CVS is. AFAIK, there are no libs in CVS that have prefixes like "sp_" in the filename.
If I understand this correctly, the sigpack externals in CVS now behave differently and have different names than the externals on Martin's page? I don't like this, it is something that should be avoided, IMO, unless there is a very good reason, so this should be sorted out somehow.
They should behave exactly the same, since the code is exactly same. The prefix to the name is the only difference. Since the sp_ prefix is a recent switch for Martin AFAIK, I hope I can convince everyone that its a bad thing with the namespaces, or at best unnecessary. If people want the lib with prefixes, that's fine, and my proposed changes will accommodate both ways of working quite cleanly. I just hope that Martin will accept them. .hc ______________________________________________________________________ __ ____ "Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism." - retired U.S. Army general, William Odom
salut if both ways working doesnt this make things a little bit confusing? you can compile it as lib with or without or as single objects with or without and why is a prefix bad? i ve done the namespace prefix only to avoid nameclashin for example the round~ object it exists also in iemlib and cyclone just wanna use all round objects and just want to make developping for me easier gruss m.weiss
Using CVS helps to make developing easier. Plus having sIgpAck in Pd-extended means that you don't have to make your own releases, saving you work. But in exchange for this labor savings, you'll need to change a few minor things about how you work so that it fits in with how the CVS repository and Pd-extended is organized.
The lib stuff that I suggested is just for backwards compatibility. Since its easy to do and doesn't affect the Pd-extended layout, I have no problem having that around.
As for Pd-extended/CVS repository guidelines developed over time on this list, here are some (which should be properly documented):
- all lib names and all sections in CVS are lowercase only (name them how ever you want in the web-page, etc. but the lib and the directory in CVS /externals/ need to be all lowercase (there are only three exceptions AFAIK, Gem, miXed, and OSCx, and these are legacy)
- the objects need to compiled in the single-object/single-file format
- the geiger namespace makes object name prefixes like "sp_" unnecessary, but if you really want them, that's ok. But I consider them deprecated and ugly. A better solution would be a more descriptive name if you want to differentiate from iemlib's and cyclone's [round~], unless they all do similar things. With the geiger namespaces in Pd-extended, you can use all three at the same time even if they have the same name.
I pasted this into a wiki page to start documenting this stuff. Please edit, add, etc.
http://puredata.org/docs/developer/CodeGuidelines
.hc
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
Using CVS helps to make developing easier.
i do agree with that ...
As for Pd-extended/CVS repository guidelines developed over time on this list, here are some (which should be properly documented):
well, please differentiate between pd-extended and cvs repository guidelines. pd-extended is your (hans's) pd distribution, the cvs external repository is a repository of pd externals. some of the externals are included in pd-extended, some of them are not ...
- the objects need to compiled in the single-object/single-file format
i think, this is a pd-extended guideline, not a cvs repository guideline ... as i stated several times, i prefer to use libraries if possible ...
- the geiger namespace makes object name prefixes like "sp_"
unnecessary, but if you really want them, that's ok. But I consider them deprecated and ugly. A better solution would be a more descriptive name if you want to differentiate from iemlib's and cyclone's [round~], unless they all do similar things. With the geiger namespaces in Pd-extended, you can use all three at the same time even if they have the same name.
well, i don't think that having a sp_ prefix is that bad ...
tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
- the objects need to compiled in the single-object/single-file format
i think, this is a pd-extended guideline, not a cvs repository guideline ... as i stated several times, i prefer to use libraries if possible ...
I don't think, this applies to sigpack anyway, as it already can be compiled both ways, even with prefix "sp_", thanks to the recent changes I did and which Martin accepted, and it's not a very intrusive change, so every user can make his/her own choice if to compile as single or as library.
- the geiger namespace makes object name prefixes like "sp_"
unnecessary, but if you really want them, that's ok. But I consider them deprecated and ugly. A better solution would be a more descriptive name if you want to differentiate from iemlib's and cyclone's [round~], unless they all do similar things. With the geiger namespaces in Pd-extended, you can use all three at the same time even if they have the same name.
well, i don't think that having a sp_ prefix is that bad ...
There are some "prior art" examples of prefixed externals, like "pdp_" or "k_", or "rrad." This really is a matter of taste and IMO the taste of the original author is, what should be respected as guideline in this regard. (I'll probably drop the "rrad." in the future and switch to directory/geiger namespaces, but Kjetil should keep his "k_" and martin his "sp_", if they want to.)
Regarding the directory names being in miXed case: I think, we never talked about a guideline for this, but I would suggest we do?
I would vote for using only lowercase names for (toplevel) directories, overriding author's tastes. ;) Lets vote!!
Ciao
On Jan 21, 2006, at 5:42 PM, Frank Barknecht wrote:
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
- the objects need to compiled in the single-object/single-file
format
i think, this is a pd-extended guideline, not a cvs repository guideline ... as i stated several times, i prefer to use libraries if possible ...
I don't think, this applies to sigpack anyway, as it already can be compiled both ways, even with prefix "sp_", thanks to the recent changes I did and which Martin accepted, and it's not a very intrusive change, so every user can make his/her own choice if to compile as single or as library.
- the geiger namespace makes object name prefixes like "sp_"
unnecessary, but if you really want them, that's ok. But I consider them deprecated and ugly. A better solution would be a more descriptive name if you want to differentiate from iemlib's and cyclone's [round~], unless they all do similar things. With the geiger namespaces in Pd-extended, you can use all three at the same time even if they have the same name.
well, i don't think that having a sp_ prefix is that bad ...
There are some "prior art" examples of prefixed externals, like "pdp_" or "k_", or "rrad." This really is a matter of taste and IMO the taste of the original author is, what should be respected as guideline in this regard. (I'll probably drop the "rrad." in the future and switch to directory/geiger namespaces, but Kjetil should keep his "k_" and martin his "sp_", if they want to.)
Regarding the directory names being in miXed case: I think, we never talked about a guideline for this, but I would suggest we do?
I would vote for using only lowercase names for (toplevel) directories, overriding author's tastes. ;) Lets vote!!
I think there are some assumed rules, like all lowercase, since basically everyone has made their CVS directories all lowercase. But it would be good to get things documented.
Here are some fully fleshed out guidelines to look at for ideas:
http://fedoraproject.org/wiki/DocsProject/CvsUsage
http://openacs.org/forums/message-view?message_id=185506
http://dotat.at/writing/cvs-guidelines.html
.hc ________________________________________________________________________ ____
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
On Jan 21, 2006, at 4:48 PM, Tim Blechmann wrote:
Using CVS helps to make developing easier.
i do agree with that ...
As for Pd-extended/CVS repository guidelines developed over time on this list, here are some (which should be properly documented):
well, please differentiate between pd-extended and cvs repository guidelines. pd-extended is your (hans's) pd distribution, the cvs external repository is a repository of pd externals. some of the externals are included in pd-extended, some of them are not ...
- the objects need to compiled in the single-object/single-file format
i think, this is a pd-extended guideline, not a cvs repository guideline ... as i stated several times, i prefer to use libraries if possible ...
- the geiger namespace makes object name prefixes like "sp_"
unnecessary, but if you really want them, that's ok. But I consider them deprecated and ugly. A better solution would be a more descriptive name if you want to differentiate from iemlib's and cyclone's [round~], unless they all do similar things. With the geiger namespaces in Pd-extended, you can use all three at the same time even if they have the same name.
well, i don't think that having a sp_ prefix is that bad ...
tim
Pd-extended is actually the work of many people, I am currently the primary contributor and cheerleader. Plus its the only current distro that I know of (some others were based off of the same build system, like pd++. The pd++ changes were then incorporated into Pd-extended).
I still hope that one day all of the users and devs will use the same distro. It would make our work much more efficient and we could spent our time on things that actually make Pd better. Right now we reinvent the build system wheel again and again; people have spent probably man-years of work building custom Pd setups; people are afraid to use externals because managing it is so painful; and we seem to argue endlessly about the same issues.
Imagine if we spent all that time on writing SIMD code for all of Pd, or making good documentation, or writing python and ruby APIs and loaders, or porting PDP to Windows, etc. etc.
.hc
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Hans-Christoph Steiner wrote:
primary contributor and cheerleader. Plus its the only current distro that I know of (some others were based off of the same build system, like pd++. The pd++ changes were then incorporated into Pd-extended).
well, the only _current_ pd-distro that i know of, is debian (holding pd-0.39 plus a bunch of externals)
which shouldn't make your (and other's) efforts less...
just my 2$
mfg.asr IOhannes
On Jan 22, 2006, at 5:30 AM, IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
primary contributor and cheerleader. Plus its the only current distro that I know of (some others were based off of the same build system, like pd++. The pd++ changes were then incorporated into Pd-extended).
well, the only _current_ pd-distro that i know of, is debian (holding pd-0.39 plus a bunch of externals)
which shouldn't make your (and other's) efforts less...
I didn't realize that the Debian packages were being updated (Not that I am faulting Guenter at all, Pd-extended was built upon his work). The newest "pd-externals" and "pd-zexy" packages that I see are both from 2004-06-25. The "puredata" package is more up-to-date than Pd-extended. "gem" seems up to date, and PDP hasn't changed in a long while, so "pd-pdp" is up to date. pidip is missing from Debian tho.
If you go outside of Debian repositories, you can get some up-to-date stuff here: http://sindominio.net/~caedes/debian/readme
.hc ________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
On Jan 22, 2006, at 11:22 AM, Hans-Christoph Steiner wrote:
On Jan 22, 2006, at 5:30 AM, IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
primary contributor and cheerleader. Plus its the only current distro that I know of (some others were based off of the same build system, like pd++. The pd++ changes were then incorporated into Pd-extended).
well, the only _current_ pd-distro that i know of, is debian (holding pd-0.39 plus a bunch of externals)
which shouldn't make your (and other's) efforts less...
I didn't realize that the Debian packages were being updated (Not that I am faulting Guenter at all, Pd-extended was built upon his work). The newest "pd-externals" and "pd-zexy" packages that I see are both from 2004-06-25. The "puredata" package is more up-to-date than Pd-extended. "gem" seems up to date, and PDP hasn't changed in a long while, so "pd-pdp" is up to date. pidip is missing from Debian tho.
If you go outside of Debian repositories, you can get some up-to-date stuff here: http://sindominio.net/~caedes/debian/readme
Oops, I almost forgot flext & externals. The only Debian packages I see for flext are "pd-flext" and "pd-flext-dev", none for externals. The two existing one are in experimental and haven't been updated in a while.
My point in all this is that hopefully we can get the Debian packages generated from Pd-extended also, so that we can join forces on all this building grunt work. I believe Frank has started. I am hoping that pure::dyne will merge with Pd-extended build system as well, the more the merrier! Share the grunt work!
.hc
________________________________________________________________________ ____
Hans-Christoph Steiner wrote:
I didn't realize that the Debian packages were being updated (Not that I am faulting Guenter at all, Pd-extended was built upon his work). The newest "pd-externals" and "pd-zexy" packages that I see are both from 2004-06-25. The "puredata" package is more up-to-date than Pd-extended. "gem" seems up to date, and PDP hasn't changed in a long while, so "pd-pdp" is up to date. pidip is missing from Debian tho.
If you go outside of Debian repositories, you can get some up-to-date stuff here: http://sindominio.net/~caedes/debian/readme
i don't know which apt-repository you are using, but mine is etch/sid (standard debian), and they give me: puredata: 0.39.2-1 pd-zexy: 2.1-2 (which is from 2005-08-16) gem: 1:0.90.0-18 (which is the last stable release, though rather old...my fault)
i have to admit, that my "currency" was based on a quick glance at the zexy version number, which is rather recent...
My point in all this is that hopefully we can get the Debian packages generated from Pd-extended also, so that we can join forces on all this building grunt work. I believe Frank has started. I am hoping that
yes that would be really great. i was recently thinking of a pd-netinstaller, which would download and install collections of objects on demand, rather than having one huge pd-extended which provides all. (for those who have fat connectivity and want to get all at once, we can still provide the "ISO-image"...)
mf.ads.r IOhannes
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I didn't realize that the Debian packages were being updated (Not that I am faulting Guenter at all, Pd-extended was built upon his work). The newest "pd-externals" and "pd-zexy" packages that I see are both from 2004-06-25. The "puredata" package is more up-to-date than Pd-extended. "gem" seems up to date, and PDP hasn't changed in a long while, so "pd-pdp" is up to date. pidip is missing from Debian tho.
I think that Debian's Pd-packages will profit a lot from the pd-extended make-system in the near future. Being able to do a "make install DESTDIR=debian/tmp" in /CVS/externals is a huge help for packaging externals for Debian.
Ciao
On Jan 22, 2006, at 11:38 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I didn't realize that the Debian packages were being updated (Not that I am faulting Guenter at all, Pd-extended was built upon his work). The newest "pd-externals" and "pd-zexy" packages that I see are both from 2004-06-25. The "puredata" package is more up-to-date than Pd-extended. "gem" seems up to date, and PDP hasn't changed in a long while, so "pd-pdp" is up to date. pidip is missing from Debian tho.
I think that Debian's Pd-packages will profit a lot from the pd-extended make-system in the near future. Being able to do a "make install DESTDIR=debian/tmp" in /CVS/externals is a huge help for packaging externals for Debian.
Just a reminder, relative paths currently don't work with DESTDIR and Pd-extended. I think its possible to get them working, but unfortunately not easy.
.hc ________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Jan 22, 2006, at 11:38 AM, Frank Barknecht wrote:
I think that Debian's Pd-packages will profit a lot from the pd-extended make-system in the near future. Being able to do a "make install DESTDIR=debian/tmp" in /CVS/externals is a huge help for packaging externals for Debian.
Just a reminder, relative paths currently don't work with DESTDIR and Pd-extended. I think its possible to get them working, but unfortunately not easy.
Actually I was making up this command, the real Debian scripts use full paths everywhere anyway, I think, taken from `pwd` etc.
Ciao
On Sun, 22 Jan 2006, Frank Barknecht wrote:
I think that Debian's Pd-packages will profit a lot from the pd-extended make-system in the near future. Being able to do a "make install DESTDIR=debian/tmp" in /CVS/externals is a huge help for packaging externals for Debian.
We already had a big build system for everything once, but I dropped the all encompassing pd-externals because it was hard to maintain.
What is left is pd-zexy, gem, and pdp. pdp is sort of co-maintained by Caedes. These packages are in stable, testing and unstable.
pd-flext in experimental, because it is not cross platform and I have to find the time to fix that.
Well, thats all that is there in Debian currently.
Günter
Hallo, geiger hat gesagt: // geiger wrote:
On Sun, 22 Jan 2006, Frank Barknecht wrote:
I think that Debian's Pd-packages will profit a lot from the pd-extended make-system in the near future. Being able to do a "make install DESTDIR=debian/tmp" in /CVS/externals is a huge help for packaging externals for Debian.
We already had a big build system for everything once, but I dropped the all encompassing pd-externals because it was hard to maintain.
Does "hard to maintain" mean hard to get running on all Debian platforms or was it just the build, that made problems? Because with Hans' Makefile in externals, things should be a bit easier at least on the build-side. Fixing externals to build on, say, "arm", of course still is hard work.
Ciao
-
Frank Barknecht -
geiger -
Hans-Christoph Steiner -
IOhannes m zmölnig -
m.weiss -
Tim Blechmann