I set up the cvswrappers on Sourceforge to handle binary files correctly. To see or edit the file: cvs co CVSROOT/cvswrappers
Here's the list that I put in, feel free to add more: # IMAGES *.gif -k 'b' *.png -k 'b' *.jpg -k 'b' *.jpeg -k 'b' *.tif -k 'b' *.tiff -k 'b'
# WEB FILES *.swf -k 'b' *.fla -k 'b' *.mov -k 'b'
# SOUND FILES *.wav -k 'b' *.snd -k 'b' *.aif -k 'b' *.aiff -k 'b' *.au -k 'b' *.mp2 -k 'b' *.mp3 -k 'b'
# DOCUMENTS *.pdf -k 'b' *.doc -k 'b' *.dot -k 'b' *.xlt -k 'b' *.ps -k 'b'
# EXECUTABLES *.exe -k 'b' *.dll -k 'b' *.pd_linux -k 'b' *.pd_darwin -k 'b'
# WINDOWS FILES *.lnk -k 'b'
Does that mean that we can have a module in cvs with all win32 externals and library dll's along with their documentation? Or even a complete extended PD distribution (with a complete list of objects documented somewhere).
I think this would be useful for many people (including me). It takes a lot of time to search the net for externals/libraries, find the most recent and compiled version, and then unpack+install it.
Or am I missing something that is already available?
thanks
j#|@
We could do that, but I don't think it would be a good use of CVS. I think pure-data.sf.net project is nearing the point of releasing files, but nothing has been yet.
CVS binary handling is for .wav files, .jpgs, etc., files that are used in example patches and stuff like that.
Once some binaries are ready, I am sure they'll be put up on the 'Files' section of the SourceForge site.
.hc
On Thursday, Dec 5, 2002, at 06:04 America/New_York, Johannes Taelman wrote:
Does that mean that we can have a module in cvs with all win32 externals and library dll's along with their documentation? Or even a complete extended PD distribution (with a complete list of objects documented somewhere).
I think this would be useful for many people (including me). It takes a lot of time to search the net for externals/libraries, find the most recent and compiled version, and then unpack+install it.
Or am I missing something that is already available?
thanks
j#|@
To repeat that and make it clear.
The idea of the CVS is exactly what you suggest.
Making it easier for the user to access the pd externals.
But, there will not be binaries in the CVS, but we will do file releases.
Another goal of the CVS is to attempt to establish some sort of developers community.
There may be a moment when I am able to make the build system for windows and OSX, and try to clean up documentation etc. After that there will be a release.
The problem is that up to now I could only do the linux build system, because of lack of time. Until now noone stepped forward to do the build system for other architectures. This means we have to wait until I find the time to do that. Same for going through documentation, etc, etc
Guenter
On Fri, 6 Dec 2002, Hans-Christoph Steiner wrote:
We could do that, but I don't think it would be a good use of CVS. I think pure-data.sf.net project is nearing the point of releasing files, but nothing has been yet.
CVS binary handling is for .wav files, .jpgs, etc., files that are used in example patches and stuff like that.
Once some binaries are ready, I am sure they'll be put up on the 'Files' section of the SourceForge site.
.hc
On Thursday, Dec 5, 2002, at 06:04 America/New_York, Johannes Taelman wrote:
Does that mean that we can have a module in cvs with all win32 externals and library dll's along with their documentation? Or even a complete extended PD distribution (with a complete list of objects documented somewhere).
I think this would be useful for many people (including me). It takes a lot of time to search the net for externals/libraries, find the most recent and compiled version, and then unpack+install it.
Or am I missing something that is already available?
thanks
j#|@
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Hi, Guenter, all.
guenter geiger said this at Fri, 6 Dec 2002 16:05:55 +0100:
There may be a moment when I am able to make the build system for windows and OSX, and try to clean up documentation etc. After that there will be a release.
I've been giving some thought to that on the OSX side, mostly with regards to the packaging system. I'm not sure what's the most convenient way to make installable packages on the MacOSX side of things. Apple's .pkg is attractive, but the current package format doesn't seem to be very manipulable by the command-line.
Also--where do they go? The /usr/local tree (where I personally prefer to put pd) is typically hidden from the user. It would be nice to be able to put files in a place like /Library/Pd, where an ordinary user has the capability to scre^H^H^H^Hmanipulate their installation in the finder.
We could emulate your debian approach--how does that lay out files for externals (and their associated source, help, and other files)?
Also, regarding the CVS, are there any plans of a merge of version 0.36- final into the CVS tree? (or, alternatively, giving me clear-enough pointers that I could spend time with it and not screw it up?)
best, adam
Hi, Adam Lindsay schrieb:
I've been giving some thought to that on the OSX side, mostly with regards to the packaging system.
We could emulate your debian approach--how does that lay out files for externals (and their associated source, help, and other files)?
Did you take a look at Fink: http://fink.sourceforge.net/ It seems to be very much like Debian, at least it uses the Debian tools like dpkg and apt-get to distribute packages.
As Debian packages of pure-data.sf.net are almost ready to go, this might even save some work.
ciao
Hi Frank.
I'm very familiar with fink from my MacOSX 10.0-10.1.5 days. I have since stopped using it, as it tends to be "selfish" with the filesystem, and generally inflexible. IMHO, of course.
Um, err... fink had crossed my mind as being a way to start with debian packages, though. It does indeed use the debian distribution system for binaries.
So but is it better to get a jump-start with a non-optimal system, and then try to get users to switch later, or spend a bit of time trying to get it closer-to-optimal on the first try?
adam
Frank Barknecht said this at Fri, 6 Dec 2002 17:20:18 +0100:
Hi, Adam Lindsay schrieb:
I've been giving some thought to that on the OSX side, mostly with regards to the packaging system.
We could emulate your debian approach--how does that lay out files for externals (and their associated source, help, and other files)?
Did you take a look at Fink: http://fink.sourceforge.net/ It seems to be very much like Debian, at least it uses the Debian tools like dpkg and apt-get to distribute packages.
As Debian packages of pure-data.sf.net are almost ready to go, this might even save some work.
ciao
Frank Barknecht
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
I've been giving some thought to that on the OSX side, mostly with regards to the packaging system. I'm not sure what's the most convenient way to make installable packages on the MacOSX side of things. Apple's .pkg is attractive, but the current package format doesn't seem to be very manipulable by the command-line.
why even bother with a packaging system for the binary? how about this for an install on OSX:
step one: download binary step two: un-tar/zip/stuff downloaded file step three: open pd folder and double click on CLICK_ME_TO_RUN_PD smiley face icon
for step three to happen, write a pdstart.command that has ./pd -options and put it in the pd/bin dir. make an alias to it with that big smiley face icon at the root of the pd folder.
i don't think you can assume that the typical Mac user uses the command line at all, so OSX apps should take that into account. the above approach seems to be in line with most free/shareware applications distributed for OSX, which will make Mac users feel right at home.
one thing to work out is explaining how the runtime options are used. this could be a point of confusion for people when they first try to setup their midi/audio and add various libs to pd.
Also--where do they go? The /usr/local tree (where I personally prefer to put pd) is typically hidden from the user. It would be nice to be able to put files in a place like /Library/Pd, where an ordinary user has the capability to scre^H^H^H^Hmanipulate their installation in the finder.
i think you have answered your own question. the OSX version of pd should go where the user wants it to go. if you install to /usr/local that would make pd vanish to the majority of mac users!
We could emulate your debian approach--how does that lay out files for externals (and their associated source, help, and other files)?
why emulate debian at all? it's not debian it's OSX. if anything it should more closely resemble the win32 version.
cgc
I have just purchased a PowerBook, so I will be working on the OS X side of things a lot in the future. I definitely have an interest in being a/the OS X package maintainer, but it will probably be a slow ramp up since I am currently in grad school and it takes up lots of my time.
On Friday, Dec 6, 2002, at 13:31 America/New_York, chris clepper wrote:
why even bother with a packaging system for the binary? how about this for an install on OSX:
We should use a packaging system because that is the way most people install software. As you mentioned, the average Mac user will expect such things. I could see doing pd in a .dmg style package with a README and the pure-data.app which the user copies to their Applications folder. This would be pretty easy to deal will, with everything related to pd going in the pure-data.app folder.
We could emulate your debian approach--how does that lay out files for externals (and their associated source, help, and other files)?
why emulate debian at all? it's not debian it's OSX. if anything it should more closely resemble the win32 version.
The other idea for a OS X package for pd is a fink package (http://fink.sf.net). It uses the debian package tools so it should be an easy port from the debian packages that Günter is working on. A fink package could also install a pure-data.app in Applications for the non-power users. The fink X11 packages do this, for example, and it works quite well.
Ideally, I think there would be both package types, the .dmg/.app package for the standard Mac user, and the fink package for the command line user.
.hc
cgc
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
On Fri, 6 Dec 2002, Adam Lindsay wrote:
Hi, Guenter, all.
Hi,
guenter geiger said this at Fri, 6 Dec 2002 16:05:55 +0100:
There may be a moment when I am able to make the build system for windows and OSX, and try to clean up documentation etc. After that there will be a release.
I've been giving some thought to that on the OSX side, mostly with regards to the packaging system.
I would prefer having the externals build before packaging them, is packageing really such a problem on OSX ? I just thought that the externals get thrown into a directroy somewhere.
Also, regarding the CVS, are there any plans of a merge of version 0.36- final into the CVS tree? (or, alternatively, giving me clear-enough pointers that I could spend time with it and not screw it up?)
Well, as I did not know that myself, I tried to screw it personally. The result of all that should be in the devel_0_36 branch, together with a log message that is completely unrelated.
Anyhow, here is how I did it:
1) Download the new pd source 2) cd pd-X.XX-X 3) cvs -d:.... import pd source_dist devel_0_36-0 4) cd to/my/cvs/pd/dir 5) do the merge (locally): cvs update -j devel_0_36-0 6) clean up conflicts 7) cvs commit -m 'some meaningless log message'
Actually I wanted to have a "meaningful" log message in step 7, but I happend to fix something else, and commited all together with the 'fixed initialization problem with makeout' message ... sorry.
Now we can take a look if our enhancements survived ....
Guenter
guenter geiger said this at Mon, 9 Dec 2002 19:57:36 +0100:
I've been giving some thought to that on the OSX side, mostly with regards to the packaging system.
I would prefer having the externals build before packaging them, is packageing really such a problem on OSX ?
Yes, the idea is to package the pre-built externals.
I just thought that the externals get thrown into a directroy somewhere.
Well, maybe I'm making things more complicated than necessary for myself, but I find I need to: 1) Throw the external into a directory 2) Make a symbolic link from the 'extra' directory to the .pd_darwin binary 3) Make symbolic links from doc/5.reference to all of the .pd help files [or 3a) Make a correctly named symbolic link from doc/5.reference to the help directory] 4) Make sure abstractions are taken care of. 5) Make sure miscellaneous data, audio, video, and text files are linked.
I don't think there are enough similarities between existing externals to script this process. I'm used to being a spoiled (Mac) user, and think that there has to be a better way of installing these things.
Also, regarding the CVS, are there any plans of a merge of version 0.36- final into the CVS tree? (or, alternatively, giving me clear-enough pointers that I could spend time with it and not screw it up?)
Well, as I did not know that myself, I tried to screw it personally. The result of all that should be in the devel_0_36 branch, together with a log message that is completely unrelated.
Anyhow, here is how I did it:
- Download the new pd source
- cd pd-X.XX-X
- cvs -d:.... import pd source_dist devel_0_36-0
- cd to/my/cvs/pd/dir
- do the merge (locally): cvs update -j devel_0_36-0
- clean up conflicts
- cvs commit -m 'some meaningless log message'
Actually I wanted to have a "meaningful" log message in step 7, but I happend to fix something else, and commited all together with the 'fixed initialization problem with makeout' message ... sorry.
Well, I clearly still have a lot to learn about CVS myself... That worked like a charm, as close as I can tell. All of the bugs that I was aware of seem to have matched 0.36-0's status.
Oh, I just put Miller's updated install documentation (x3.htm) into the CVS, for completeness's sake.
adam
Hi Adam, hi all, are those timing problems in PD@OSX gone with version 0.36?
When i use a [delay 5000] with your packaged version the delay is more like 1,5 seconds, which makes PD rather unusable for a lot of tasks. Am i the only one experiencing this? (using the [timer] object to measure the time reports the correct delay, which may indicate that i'm stuck in a time-hole or whatever)
best greetings, Thomas
Thomas
i get a bang delayed 5 seconds with a [delay 5000] using pd-0.35-0 on OSX. i timed it with my watch as well as with the [timer] object.
cgc
Hi Adam, hi all, are those timing problems in PD@OSX gone with version 0.36?
When i use a [delay 5000] with your packaged version the delay is more like 1,5 seconds, which makes PD rather unusable for a lot of tasks. Am i the only one experiencing this? (using the [timer] object to measure the time reports the correct delay, which may indicate that i'm stuck in a time-hole or whatever)
best greetings, Thomas
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
i get a bang delayed 5 seconds with a [delay 5000] using pd-0.35-0 on OSX. i timed it with my watch as well as with the [timer] object.
cgc
Hmmm, that's strange, maybe i should move to another flat. However, there's (which means here's) no noticable difference between [delay 5000] and [delay 15000] which brings about some deeper philosophical questions.
greetings, Thomas
I believe Thomas Grill said this around Tue, 10 Dec 2002:
i get a bang delayed 5 seconds with a [delay 5000] using pd-0.35-0 on OSX. i timed it with my watch as well as with the [timer] object.
cgc
Hmmm, that's strange, maybe i should move to another flat.
Perhaps it's because you're already moving too fast... (~ c ....sorry.)
However, there's (which means here's) no noticable difference between [delay 5000] and [delay 15000] which brings about some deeper philosophical questions.
That's odd, I can't say I've ever noticed that. I tried on both the current, up-to-date CVS build and a build that I think dates from my pre- packaged version, and don't encounter it, either.
That reminds me... Are people interested in another pre-packaged OSX PD build, with Tcl/Tk?
I tried preparing one today (tedious), but ran into some minor snags. If a double-click-able package is something people want, I'll try again.
adam
-- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Adam Lindsay +44(0)1524 594 537 atl@comp.lancs.ac.uk http://www.comp.lancs.ac.uk/computing/users/atl/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
On Tue, 10 Dec 2002, Adam Lindsay wrote:
That reminds me... Are people interested in another pre-packaged OSX PD build, with Tcl/Tk?
I have just inherited an osx 10.2 powerbook and would definitely welcome a pre-packaged build (although advice on how to deal with tcl/tk probs is welcome too, having trouble here even with latest miller advice)...
d
david casal --0+ --- d.casal@uea.ac.uk --9+ --- www.ariada.uea.ac.uk/~dcasal --)+
-
Adam Lindsay -
chris clepper -
david casal -
Frank Barknecht -
guenter geiger -
Hans-Christoph Steiner -
Johannes Taelman -
Thomas Grill