I would like to rename the Pd core help files in CVS so that they conform to the naming convention *-help.pd. Currently, they are in the deprecated format help-*.pd. There are two ways for this to happen: add and remove the files from CVS, or put in a support request to sourceforge to have them rename them in CVS. The later option is preferred because then the CVS history is preserved.
This script will rename the files for you if you run it in pd/doc:
#------------ #!/bin/sh
for helpfile in help-*.pd ; do mv "$helpfile" "`echo $helpfile | sed 's/^help-(.*).pd$/\1-help.pd/'`" done #------------
Once we agree to this, I'll put in the SourceForge support request. It generally takes them less than a week to fulfill such requests.
.hc
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Good idea... I've updated my copy, and thanks for the 'sed' magic. Note also pd/extra, some of whose subdirs also have "help" files in them.
I'll hold off on checking the new version in until the CVS repository "main" branch starts showing the *-help.pd names...
cheers Miller
On Fri, May 20, 2005 at 11:18:05PM -0400, Hans-Christoph Steiner wrote:
I would like to rename the Pd core help files in CVS so that they conform to the naming convention *-help.pd. Currently, they are in the deprecated format help-*.pd. There are two ways for this to happen: add and remove the files from CVS, or put in a support request to sourceforge to have them rename them in CVS. The later option is preferred because then the CVS history is preserved.
This script will rename the files for you if you run it in pd/doc:
#------------ #!/bin/sh
for helpfile in help-*.pd ; do mv "$helpfile" "`echo $helpfile | sed 's/^help-(.*).pd$/\1-help.pd/'`" done #------------
Once we agree to this, I'll put in the SourceForge support request. It generally takes them less than a week to fulfill such requests.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
The doc/5.reference move is complete:
http://sourceforge.net/tracker/? func=detail&atid=200001&aid=1206229&group_id=1
"cvs update" to get the properly named versions. I am going to submit a request to change the extra/help-*.pd files in the SourceForge CVS now.
.hc
On May 20, 2005, at 9:36 PM, Miller Puckette wrote:
Good idea... I've updated my copy, and thanks for the 'sed' magic. Note also pd/extra, some of whose subdirs also have "help" files in them.
I'll hold off on checking the new version in until the CVS repository "main" branch starts showing the *-help.pd names...
cheers Miller
On Fri, May 20, 2005 at 11:18:05PM -0400, Hans-Christoph Steiner wrote:
I would like to rename the Pd core help files in CVS so that they conform to the naming convention *-help.pd. Currently, they are in the deprecated format help-*.pd. There are two ways for this to happen: add and remove the files from CVS, or put in a support request to sourceforge to have them rename them in CVS. The later option is preferred because then the CVS history is preserved.
This script will rename the files for you if you run it in pd/doc:
#------------ #!/bin/sh
for helpfile in help-*.pd ; do mv "$helpfile" "`echo $helpfile | sed 's/^help-(.*).pd$/\1-help.pd/'`" done #------------
Once we agree to this, I'll put in the SourceForge support request. It generally takes them less than a week to fulfill such requests.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
If you are not part of the solution, you are part of the problem. - Eldridge Cleaver
Hey again,
The current draft implimentation system for help file searching expects the *-help.pd files to be all in one place, along side the externals in extra/ Is it reasonable to organize PD in this way and make some beta installers/packages of PD to work this way?
I still need to take a look at Thomas O.'s installer to see where he is thinking...
B.
They should all be named *-help.pd, and currently, they should all be in one folder. But that folder should be separate from "extra". Its currently "doc/5.reference".
In the long run, once we have a way to do "include", "using", "import", whatever you want to call it, it would probably make more sense to have all of the externals and help files in one folder.
.hc
On May 24, 2005, at 10:56 AM, B. Bogart wrote:
Hey again,
The current draft implimentation system for help file searching expects the *-help.pd files to be all in one place, along side the externals in extra/ Is it reasonable to organize PD in this way and make some beta installers/packages of PD to work this way?
I still need to take a look at Thomas O.'s installer to see where he is thinking...
B.
________________________________________________________________________ ____
Hmmm... (this IS a greeting),
If all -help (and perhaps other) patches are not put along side the binaries (as is now possible) or abstractions if that is the case, then why is it possible to put the help file next to the binary? I don't think the other stuff (examples etc..) make sense to be next to the binaries.
What purpose does it serve to support help patches next to binaries if the standard place for help patches is not where the binaries are?
For the help-patch registration: (Which states that all -help patches need to be in the same place probably extra/)
I see two alternatives:
1. Put the help files in subdirectories of some standard place like extra/. 2. Put help files all over the place (which seems to be the current case).
To solve #1 we just need to decend into subdirs. No problem. To solve #2 we need a list of all the -paths PD finds on the tcl side. This seems like a problem.
I am confused about the "feature" of being able to put help patches next to externals. What I don't get is the point of this if the structure of PD does not reflect this feature? Should I just go along the assumption that all help files will be in 5.reference and forget about the new feature?
Clarification please.
I'm planning on testing the tcl code on the wiki and creating a prototype PD with the help searching system next week. Probably based on HC's extended since it has all the goodies.
B>
Hans-Christoph Steiner wrote:
They should all be named *-help.pd, and currently, they should all be in one folder. But that folder should be separate from "extra". Its currently "doc/5.reference".
In the long run, once we have a way to do "include", "using", "import", whatever you want to call it, it would probably make more sense to have all of the externals and help files in one folder.
.hc
On May 24, 2005, at 10:56 AM, B. Bogart wrote:
Hey again,
The current draft implimentation system for help file searching expects the *-help.pd files to be all in one place, along side the externals in extra/ Is it reasonable to organize PD in this way and make some beta installers/packages of PD to work this way?
I still need to take a look at Thomas O.'s installer to see where he is thinking...
B.
http://at.or.at/hans/
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
hi Ben,
B. Bogart wrote: ...
What purpose does it serve to support help patches next to binaries if the standard place for help patches is not where the binaries are?
that is the easiest way to maintain documentation for project-specific, user-specific, site-specific abstractions and externals
Krzysztof
-
B. Bogart -
Hans-Christoph Steiner -
Krzysztof Czaja -
Miller Puckette