Re: [PD] help files was: Re: call for testing on the nightly builds!
Quoting Frank Barknecht <[EMAIL PROTECTED]>: > But you type the same with both layouts. To not have to type the prefix, > you just add the "prefix" directory directly to your path with a pd-path > setting, declare, import or whatever. The issue of help files not being > found is not related to that. frank, i agree with you (surprise:-)) rich, i don't see how putting the help-patches into doc/ relates to what you have described. (but probably i have just lost track of what you are saying) > Which brings to my mind: I think, Pd may > benefit from an option to set the -helppath dynamically, too, e.g. in > [declare] or somewhere else. i think the entire helppath-thing was a _very_ ugly klugde and it should not be mentioned any more...seriously, it tries to provide workarounds for things that should be solved straightforward; it created more confusion within me than i would have thought is proper for the topic of help-patches. mfg.da IOhannes > > Ciao > -- > Frank Barknecht > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > This message was sent using IMP, the Internet Messaging Program. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
Hallo, Rich E hat gesagt: // Rich E wrote: > On Thu, May 22, 2008 at 12:58 AM, IOhannes m zmoelnig <[EMAIL PROTECTED]> > wrote: > > > Rich E wrote: > > > >> Both layout 1 and 2 would be nice to have, for different situations. > >> > > > > i would be interested in the situations where layout 2 would be nice to > > have. > > i don't see any. > > > > For the same reason "from x import *" is in python: so you don't have to > type as much. I guess that is it. But you type the same with both layouts. To not have to type the prefix, you just add the "prefix" directory directly to your path with a pd-path setting, declare, import or whatever. The issue of help files not being found is not related to that. Which brings to my mind: I think, Pd may benefit from an option to set the -helppath dynamically, too, e.g. in [declare] or somewhere else. Ciao -- Frank Barknecht ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
On Thu, May 22, 2008 at 12:58 AM, IOhannes m zmoelnig <[EMAIL PROTECTED]> wrote: > Rich E wrote: > >> Both layout 1 and 2 would be nice to have, for different situations. >> > > i would be interested in the situations where layout 2 would be nice to > have. > i don't see any. > For the same reason "from x import *" is in python: so you don't have to type as much. I guess that is it. > > mgsdf > IOhannes > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
Rich E wrote: > Both layout 1 and 2 would be nice to have, for different situations. i would be interested in the situations where layout 2 would be nice to have. i don't see any. mgsdf IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
Both layout 1 and 2 would be nice to have, for different situations. Concerning patches that are included in pd extended, it seems best to use layout 1 that you mention, which is compatible on everyone's system, as of right now. [declare]/[import] seems like something for personal patches, where someone knows what obects they use, and there are no namespace conflicts that are effecting their setup. This system is still in flux, but it can wait, as it is only a system to make things easier. regards, rich On Tue, May 20, 2008 at 5:34 AM, Frank Barknecht <[EMAIL PROTECTED]> wrote: > Hallo, > Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > > > Pd-extended did not introduce namespace prefixes, Miller did that > > probably before I even heard of Pd. Pd-extended is just organized > > around that idea. Pd-vanilla fully supports namespace prefixes. I > > don't know how many times I have to say this, but it hasn't changed > > since the beginning. I guess its just part of the ebb and flow of > > this list to have this discussion every 6 months. ;) > > I also have a strong Deja vu. ;) > > Anyway, to reiterate the problem for others: *-help.pd files that are in > the same directory as the abstractions that they document work > everywhere: > >Directory layout 1: >extra/prefix/abst.pd >extra/prefix/abst-help.pd <= uses [abst] > >Start Pd: >$ pd -path extra -helppath extra > >Create [prefix/abst], select Help on it, "prefix/abst-help.pd" is >opened and shows [abst] > > > But this doesn't work: > >Directory layout 2: >extra/prefix/abst.pd >doc/prefix/abst-help.pd <= uses [abst] > >Start Pd as: >$ pd -path extra -helppath doc > >Create [prefix/abst], select Help on it, "prefix/abst-help.pd" is >opened, but [abst] is broken. > > This is a well-known issue and as far as I see it has two fixes > > a simple one: Use "Directory layout 1" or > > and a complex one: Make a [declare]/[import] for Pd-vanilla that > "works", agree on "prefix"es and add [declare]/[import] to the help file > to load "prefix" locally. > > There also is a bad (IMO) third fix: Make abst-help.pd use > [prefix/abst], which is bad because it breaks, if you're not using > "Directory layout 2" exactly, for example, if you make a copy of abst.pd > and abst-help.pd in your working/project directory and don't install it > globally. > > Deja vu end. > > Ciao > -- > Frank Barknecht > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > Pd-extended did not introduce namespace prefixes, Miller did that > probably before I even heard of Pd. Pd-extended is just organized > around that idea. Pd-vanilla fully supports namespace prefixes. I > don't know how many times I have to say this, but it hasn't changed > since the beginning. I guess its just part of the ebb and flow of > this list to have this discussion every 6 months. ;) I also have a strong Deja vu. ;) Anyway, to reiterate the problem for others: *-help.pd files that are in the same directory as the abstractions that they document work everywhere: Directory layout 1: extra/prefix/abst.pd extra/prefix/abst-help.pd <= uses [abst] Start Pd: $ pd -path extra -helppath extra Create [prefix/abst], select Help on it, "prefix/abst-help.pd" is opened and shows [abst] But this doesn't work: Directory layout 2: extra/prefix/abst.pd doc/prefix/abst-help.pd <= uses [abst] Start Pd as: $ pd -path extra -helppath doc Create [prefix/abst], select Help on it, "prefix/abst-help.pd" is opened, but [abst] is broken. This is a well-known issue and as far as I see it has two fixes a simple one: Use "Directory layout 1" or and a complex one: Make a [declare]/[import] for Pd-vanilla that "works", agree on "prefix"es and add [declare]/[import] to the help file to load "prefix" locally. There also is a bad (IMO) third fix: Make abst-help.pd use [prefix/abst], which is bad because it breaks, if you're not using "Directory layout 2" exactly, for example, if you make a copy of abst.pd and abst-help.pd in your working/project directory and don't install it globally. Deja vu end. Ciao -- Frank Barknecht ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
On May 20, 2008, at 10:53 AM, Frank Barknecht wrote: > Hallo, > IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: > >> Frank Barknecht wrote: >> >>> It's a packaging problem, you can do nothing about it. >> >> you can help the packager solve the problem. > > But not by changing the help file or the object itself, only by > changing the packaging or finding a good way to deal with > modules/aliases/namespaces. The reason for help-file breakage are the > custom alias-names for objects that pd-extended introduces, e.g. the > alias [mrpeach/tcpclient] for [tcpclient]. Didn't someone say aliases > are bad? ;) Pd-extended did not introduce namespace prefixes, Miller did that probably before I even heard of Pd. Pd-extended is just organized around that idea. Pd-vanilla fully supports namespace prefixes. I don't know how many times I have to say this, but it hasn't changed since the beginning. I guess its just part of the ebb and flow of this list to have this discussion every 6 months. ;) .hc > > Ciao > -- > Frank Barknecht _ > __footils.org__ > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: > Frank Barknecht wrote: > > > It's a packaging problem, you can do nothing about it. > > you can help the packager solve the problem. But not by changing the help file or the object itself, only by changing the packaging or finding a good way to deal with modules/aliases/namespaces. The reason for help-file breakage are the custom alias-names for objects that pd-extended introduces, e.g. the alias [mrpeach/tcpclient] for [tcpclient]. Didn't someone say aliases are bad? ;) Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
Frank Barknecht wrote: > It's a packaging problem, you can do nothing about it. you can help the packager solve the problem. fgmasdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
Hallo, Martin Peach hat gesagt: // Martin Peach wrote: > I open it manually it won't make [tcpclient] either. So I'm just > wondering what I can do about that... It's a packaging problem, you can do nothing about it. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
On May 19, 2008, at 6:55 PM, Martin Peach wrote: > Hans-Christoph Steiner wrote: >> On May 18, 2008, at 12:09 PM, Roman Haefeli wrote: >>> On Sun, 2008-05-18 at 05:40 -0400, Enrique Erne wrote: Roman Haefeli wrote: > On Sat, 2008-05-17 at 19:50 +0200, IOhannes m zmoelnig wrote: >> Hans-Christoph Steiner wrote: i'm not a developer but i would vote for declare i.e. [declare -stdlib mrpeach] to packOSC-help.pd then it would work with pd vanilla too. >>> The declare/namespace/import stuff is still very undefined, so I >>> think some experiementation would be good. I think you >>> should go >>> ahead and try it using what you propose. That will be a good >>> test >>> case. Then we'll figure out what works best. >> putting the helppatches besides the objects should fix most of >> the >> problems, no? >> no need for [declare] orgies and such > yo.. it would seem strange having to put [declare]s into help- > patches in > order to load the the objects, that they are explaining, IMO. maybe i miss something: to it seems _not_ strange to have a working help patch. the declare is documenting how one can use the object-class of the external (one of the 4, 5... 6 ways). >>> there are only so many in pd-extended, there aren't that many in >>> pd-vanilla ( i can think of [declare] and pd-settings file only). >>> or do you think a user should configure the plist/pdrc/registry first and restart Pd before he can use the documentation/helpfile? >>> i think, as IOhannes said, that it would make sense to put classes >>> (libraries, abstractions, single-object files) and their help- >>> files at >>> the same place. i don't see a benefit in having to tell a help-file >>> where to find the class. >> Yeah, that's the idea of libdirs. It just needs to be >> implemented fully. It's pretty close. > > > I have all my help files in the same place as the source code in > the svn repository but they end up separated in pd-extended (the > binaries go to extra/mrpeach and the help files are in doc/ > 5.reference/mrpeach). As has already been remarked, I can > instantiate for example [mrpeach/tcpclient] but not [tcpclient] but > in either case the help file isn't found and if I open it manually > it won't make [tcpclient] either. So I'm just wondering what I can > do about that... > If I put [mrpeach/tcpclient] in the help file it will work but it > doesn't do anything to make the help file findable. Is there some > make file I need to edit or does the libdir thing fix this? What would fix this well is a completed libdir format. If the help files are included in the same folder as the objectclasses, then the help files will be found either way, AFAIK. But since 0.41-4 is out, and Pd-extended 0.40 has a lot of changes that are pretty well tested, I think it makes sense to release 0.40, then work on the whole libdir/import/declare issue in 0.41 (though I really hoped to do it for 0.40). I am fine with leaving this how it is for this release, then fixing it properly for the next release. .hc ¡El pueblo unido jamás será vencido! ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
Hans-Christoph Steiner wrote: > On May 18, 2008, at 12:09 PM, Roman Haefeli wrote: > >> On Sun, 2008-05-18 at 05:40 -0400, Enrique Erne wrote: >>> Roman Haefeli wrote: On Sat, 2008-05-17 at 19:50 +0200, IOhannes m zmoelnig wrote: > Hans-Christoph Steiner wrote: >>> i'm not a developer but i would vote for declare >>> i.e. [declare -stdlib mrpeach] to packOSC-help.pd >>> then it would work with pd vanilla too. >> The declare/namespace/import stuff is still very undefined, so I >> think some experiementation would be good. I think you should go >> ahead and try it using what you propose. That will be a good test >> case. Then we'll figure out what works best. > putting the helppatches besides the objects should fix most of the > problems, no? > no need for [declare] orgies and such yo.. it would seem strange having to put [declare]s into help- patches in order to load the the objects, that they are explaining, IMO. >>> maybe i miss something: >>> >>> to it seems _not_ strange to have a working help patch. the >>> declare is >>> documenting how one can use the object-class of the external (one >>> of the >>> 4, 5... 6 ways). >> there are only so many in pd-extended, there aren't that many in >> pd-vanilla ( i can think of [declare] and pd-settings file only). >> >>> or do you think a user should configure the plist/pdrc/registry first >>> and restart Pd before he can use the documentation/helpfile? >> i think, as IOhannes said, that it would make sense to put classes >> (libraries, abstractions, single-object files) and their help-files at >> the same place. i don't see a benefit in having to tell a help-file >> where to find the class. > > Yeah, that's the idea of libdirs. It just needs to be implemented > fully. It's pretty close. I have all my help files in the same place as the source code in the svn repository but they end up separated in pd-extended (the binaries go to extra/mrpeach and the help files are in doc/5.reference/mrpeach). As has already been remarked, I can instantiate for example [mrpeach/tcpclient] but not [tcpclient] but in either case the help file isn't found and if I open it manually it won't make [tcpclient] either. So I'm just wondering what I can do about that... If I put [mrpeach/tcpclient] in the help file it will work but it doesn't do anything to make the help file findable. Is there some make file I need to edit or does the libdir thing fix this? Martin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
On 18/05/2008, at 12.16, Roman Haefeli wrote: > i don't see a benefit in having to tell _in_ a help-file where to find > the class. I agree. And the same goes for the other way around. That would be very good for giving the help browser a bash, especially (dynamically creation of) the reference section (based on path settings). If they (the helpfiles/classes/libs) are in the same dir going the route HCS surest, that is to do it in TCL, might also make auto/tab-completion in object-boxes within reach. - Humble ideas. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
On May 18, 2008, at 12:09 PM, Roman Haefeli wrote: > On Sun, 2008-05-18 at 05:40 -0400, Enrique Erne wrote: >> Roman Haefeli wrote: >>> On Sat, 2008-05-17 at 19:50 +0200, IOhannes m zmoelnig wrote: Hans-Christoph Steiner wrote: >> i'm not a developer but i would vote for declare >> i.e. [declare -stdlib mrpeach] to packOSC-help.pd >> then it would work with pd vanilla too. > The declare/namespace/import stuff is still very undefined, so I > think some experiementation would be good. I think you should go > ahead and try it using what you propose. That will be a good test > case. Then we'll figure out what works best. putting the helppatches besides the objects should fix most of the problems, no? no need for [declare] orgies and such >>> yo.. it would seem strange having to put [declare]s into help- >>> patches in >>> order to load the the objects, that they are explaining, IMO. >> >> maybe i miss something: >> >> to it seems _not_ strange to have a working help patch. the >> declare is >> documenting how one can use the object-class of the external (one >> of the >> 4, 5... 6 ways). > > there are only so many in pd-extended, there aren't that many in > pd-vanilla ( i can think of [declare] and pd-settings file only). > >> or do you think a user should configure the plist/pdrc/registry first >> and restart Pd before he can use the documentation/helpfile? > > i think, as IOhannes said, that it would make sense to put classes > (libraries, abstractions, single-object files) and their help-files at > the same place. i don't see a benefit in having to tell a help-file > where to find the class. Yeah, that's the idea of libdirs. It just needs to be implemented fully. It's pretty close. .hc > > roman > > > > ___ > Telefonate ohne weitere Kosten vom PC zum PC: http:// > messenger.yahoo.de > > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
On May 18, 2008, at 11:39 AM, Enrique Erne wrote: > Hans-Christoph Steiner wrote: >> On May 17, 2008, at 5:50 PM, Enrique Erne wrote: >>> Hans-Christoph Steiner wrote: There is much that can and should be done. Here's some ideas ranked into of difficulty: - file a bug report when a help patch is not working - write and improve help patches, and submit them to the patch tracker >>> >>> is there a convention about how to make it work? i.e. should one >>> use declare, import or namespace prefix? >>> >>> i guess all help-files that are not loaded on default would need >>> a declare/import/or-namespace in order to work... >>> >>> i want to contribute and help to make "all"/more helpfiles work. >>> i know there is pddp but afaik it does not solve the declare/ >>> import/or-namespace problem. >>> >>> could all developers express their opinion and agree on how to >>> make all helpfiles work? :) >> Starting with the PDDP template is a good place to start: >> http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/ >> pddp/templates/ >>> i'm not a developer but i would vote for declare >>> i.e. [declare -stdlib mrpeach] to packOSC-help.pd >>> then it would work with pd vanilla too. >> The declare/namespace/import stuff is still very undefined, so I >> think some experiementation would be good. I think you should go >> ahead and try it using what you propose. That will be a good test >> case. Then we'll figure out what works best. >> Personally, I would use namespace prefixes: [mrpeach/packOSC]. >> This will make more sense when there are libraries organized >> around concepts rather than authors. So something like [osc/packOSC] > > from a user point of view organizing libraries around concepts > would be a huge gain. but let's face it: will that every be the case? > (rhetorical, but still i would be very happy if somebody has an > answer:) ) It will be the case if we make it happen. I have already started the tkwidgets library, which you might guess from the title, is a set of Tk widgets. ;) I also wrote the "pan" library, which is some techniques for stereo panning. .hc > > i just found that: > http://puredata.info/dev/PdLibraries > http://puredata.info/dev/PdNamespaces > > > for now i don't know how to help and make the helpfiles work. :( > > > > > > > - add a search pane to the help panel >>> >>> is this done in tcl/tk? is there any documentation about that on >>> puredata.info? >> It is done however you want to, more or less, but I think a pure >> Tcl solution would be possible, and perhaps easiest. >> .hc >>> >>> >>> >>> >>> - help design and code a library format that bundles objectclasses, helpfiles, manuals, examples, etc then write code to index it all, and create a GUI to navigate that content At this point, I think it is mostly a waste of time to do constant little workarounds like moving around objects. We should be putting our scarce resources towards real improvements, not temporary fixes, IMHO. .hc >> - >> --- News is what people want to keep hidden and everything >> else is publicity. - Bill Moyers Access to computers should be unlimited and total. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
On May 18, 2008, at 11:30 AM, Rich E wrote: On Sat, May 17, 2008 at 9:03 AM, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote: On May 17, 2008, at 5:50 PM, Enrique Erne wrote: > Hans-Christoph Steiner wrote: >> There is much that can and should be done. Here's some ideas >> ranked into of difficulty: >> - file a bug report when a help patch is not working >> - write and improve help patches, and submit them to the patch >> tracker > > is there a convention about how to make it work? i.e. should one > use declare, import or namespace prefix? > > i guess all help-files that are not loaded on default would need a > declare/import/or-namespace in order to work... > > i want to contribute and help to make "all"/more helpfiles work. i > know there is pddp but afaik it does not solve the declare/import/ > or-namespace problem. > > could all developers express their opinion and agree on how to make > all helpfiles work? :) Starting with the PDDP template is a good place to start: http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/pddp/ templates/ > i'm not a developer but i would vote for declare > i.e. [declare -stdlib mrpeach] to packOSC-help.pd > then it would work with pd vanilla too. This isn't working for me, using the latest pd-extended. When I start pd with the '-verbose' flag and then use a [declare] statement, what I am declaring is not getting searched (or at least it isn't posting that it is. Anyways, the object in that directory isn't found). With the current [declare], you would need to do [declare -stdlib /full/path/to/mrpeach] [declare -stdpath /full/path/to/mrpeach] .hc I think this would be a good approach, similar to python's "from x import *" mechanism, but probably not good for help files, as they could introduce nameclashes that are avoided with namespaces. Personally, I would use namespace prefixes: [mrpeach/packOSC]. This will make more sense when there are libraries organized around concepts rather than authors. So something like [osc/packOSC] This seems appropriate for help files, as it also tells you where to find the object within the extra folder. Sort of self-documenting. >> - add a search pane to the help panel > > is this done in tcl/tk? is there any documentation about that on > puredata.info? It is done however you want to, more or less, but I think a pure Tcl solution would be possible, and perhaps easiest. .hc > > > > > >> - help design and code a library format that bundles >> objectclasses, helpfiles, manuals, examples, etc then write code >> to index it all, and create a GUI to navigate that content >> At this point, I think it is mostly a waste of time to do constant >> little workarounds like moving around objects. We should be >> putting our scarce resources towards real improvements, not >> temporary fixes, IMHO. >> .hc >> -- -- News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
Roman Haefeli wrote: > On Sat, 2008-05-17 at 19:50 +0200, IOhannes m zmoelnig wrote: >> Hans-Christoph Steiner wrote: i'm not a developer but i would vote for declare i.e. [declare -stdlib mrpeach] to packOSC-help.pd then it would work with pd vanilla too. >>> The declare/namespace/import stuff is still very undefined, so I >>> think some experiementation would be good. I think you should go >>> ahead and try it using what you propose. That will be a good test >>> case. Then we'll figure out what works best. >> putting the helppatches besides the objects should fix most of the >> problems, no? >> no need for [declare] orgies and such > yo.. it would seem strange having to put [declare]s into help-patches in > order to load the the objects, that they are explaining, IMO. maybe i miss something: to it seems _not_ strange to have a working help patch. the declare is documenting how one can use the object-class of the external (one of the 4, 5... 6 ways). or do you think a user should configure the plist/pdrc/registry first and restart Pd before he can use the documentation/helpfile? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
Hans-Christoph Steiner wrote: > > On May 17, 2008, at 5:50 PM, Enrique Erne wrote: > >> Hans-Christoph Steiner wrote: >>> There is much that can and should be done. Here's some ideas ranked >>> into of difficulty: >>> - file a bug report when a help patch is not working >>> - write and improve help patches, and submit them to the patch tracker >> >> is there a convention about how to make it work? i.e. should one use >> declare, import or namespace prefix? >> >> i guess all help-files that are not loaded on default would need a >> declare/import/or-namespace in order to work... >> >> i want to contribute and help to make "all"/more helpfiles work. i >> know there is pddp but afaik it does not solve the >> declare/import/or-namespace problem. >> >> could all developers express their opinion and agree on how to make >> all helpfiles work? :) > > Starting with the PDDP template is a good place to start: > > http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/pddp/templates/ > > > >> i'm not a developer but i would vote for declare >> i.e. [declare -stdlib mrpeach] to packOSC-help.pd >> then it would work with pd vanilla too. > > The declare/namespace/import stuff is still very undefined, so I think > some experiementation would be good. I think you should go ahead and > try it using what you propose. That will be a good test case. Then > we'll figure out what works best. > > Personally, I would use namespace prefixes: [mrpeach/packOSC]. This > will make more sense when there are libraries organized around concepts > rather than authors. So something like [osc/packOSC] from a user point of view organizing libraries around concepts would be a huge gain. but let's face it: will that every be the case? (rhetorical, but still i would be very happy if somebody has an answer:) ) i just found that: http://puredata.info/dev/PdLibraries http://puredata.info/dev/PdNamespaces for now i don't know how to help and make the helpfiles work. :( >>> - add a search pane to the help panel >> >> is this done in tcl/tk? is there any documentation about that on >> puredata.info? > > It is done however you want to, more or less, but I think a pure Tcl > solution would be possible, and perhaps easiest. > > .hc > > >> >> >> >> >> >>> - help design and code a library format that bundles objectclasses, >>> helpfiles, manuals, examples, etc then write code to index it all, >>> and create a GUI to navigate that content >>> At this point, I think it is mostly a waste of time to do constant >>> little workarounds like moving around objects. We should be putting >>> our scarce resources towards real improvements, not temporary fixes, >>> IMHO. >>> .hc >>> > > > > > > > News is what people want to keep hidden and everything else is > publicity. - Bill Moyers > > > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
On Sun, 2008-05-18 at 02:30 -0700, Rich E wrote: > > > > Personally, I would use namespace prefixes: > [mrpeach/packOSC]. > This will make more sense when there are libraries organized > around > concepts rather than authors. So something like [osc/packOSC] > > > This seems appropriate for help files, as it also tells you where to > find the object within the extra folder. Sort of self-documenting. personally, i don't think, that is the way to go, since it basically means having to write different help-files for pd-vanilla (with libraries installed as bundles) and pd-extended (which has most libraries as directories with single-object-files). roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
On Sun, 2008-05-18 at 12:09 +0200, Roman Haefeli wrote: > On Sun, 2008-05-18 at 05:40 -0400, Enrique Erne wrote: > > Roman Haefeli wrote: > > > On Sat, 2008-05-17 at 19:50 +0200, IOhannes m zmoelnig wrote: > > >> Hans-Christoph Steiner wrote: > > i'm not a developer but i would vote for declare > > i.e. [declare -stdlib mrpeach] to packOSC-help.pd > > then it would work with pd vanilla too. > > >>> The declare/namespace/import stuff is still very undefined, so I > > >>> think some experiementation would be good. I think you should go > > >>> ahead and try it using what you propose. That will be a good test > > >>> case. Then we'll figure out what works best. > > >> putting the helppatches besides the objects should fix most of the > > >> problems, no? > > >> no need for [declare] orgies and such > > > yo.. it would seem strange having to put [declare]s into help-patches in > > > order to load the the objects, that they are explaining, IMO. > > > > maybe i miss something: > > > > to it seems _not_ strange to have a working help patch. the declare is > > documenting how one can use the object-class of the external (one of the > > 4, 5... 6 ways). > > there are only so many in pd-extended, there aren't that many in > pd-vanilla ( i can think of [declare] and pd-settings file only). > > > or do you think a user should configure the plist/pdrc/registry first > > and restart Pd before he can use the documentation/helpfile? > > i think, as IOhannes said, that it would make sense to put classes > (libraries, abstractions, single-object files) and their help-files at > the same place. i don't see a benefit in having to tell a help-file > where to find the class. > i meant: i don't see a benefit in having to tell _in_ a help-file where to find the class. ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
On Sun, 2008-05-18 at 05:40 -0400, Enrique Erne wrote: > Roman Haefeli wrote: > > On Sat, 2008-05-17 at 19:50 +0200, IOhannes m zmoelnig wrote: > >> Hans-Christoph Steiner wrote: > i'm not a developer but i would vote for declare > i.e. [declare -stdlib mrpeach] to packOSC-help.pd > then it would work with pd vanilla too. > >>> The declare/namespace/import stuff is still very undefined, so I > >>> think some experiementation would be good. I think you should go > >>> ahead and try it using what you propose. That will be a good test > >>> case. Then we'll figure out what works best. > >> putting the helppatches besides the objects should fix most of the > >> problems, no? > >> no need for [declare] orgies and such > > yo.. it would seem strange having to put [declare]s into help-patches in > > order to load the the objects, that they are explaining, IMO. > > maybe i miss something: > > to it seems _not_ strange to have a working help patch. the declare is > documenting how one can use the object-class of the external (one of the > 4, 5... 6 ways). there are only so many in pd-extended, there aren't that many in pd-vanilla ( i can think of [declare] and pd-settings file only). > or do you think a user should configure the plist/pdrc/registry first > and restart Pd before he can use the documentation/helpfile? i think, as IOhannes said, that it would make sense to put classes (libraries, abstractions, single-object files) and their help-files at the same place. i don't see a benefit in having to tell a help-file where to find the class. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
On Sat, May 17, 2008 at 9:03 AM, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote: > > On May 17, 2008, at 5:50 PM, Enrique Erne wrote: > > > Hans-Christoph Steiner wrote: > >> There is much that can and should be done. Here's some ideas > >> ranked into of difficulty: > >> - file a bug report when a help patch is not working > >> - write and improve help patches, and submit them to the patch > >> tracker > > > > is there a convention about how to make it work? i.e. should one > > use declare, import or namespace prefix? > > > > i guess all help-files that are not loaded on default would need a > > declare/import/or-namespace in order to work... > > > > i want to contribute and help to make "all"/more helpfiles work. i > > know there is pddp but afaik it does not solve the declare/import/ > > or-namespace problem. > > > > could all developers express their opinion and agree on how to make > > all helpfiles work? :) > > Starting with the PDDP template is a good place to start: > > http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/pddp/ > templates/ > > > i'm not a developer but i would vote for declare > > i.e. [declare -stdlib mrpeach] to packOSC-help.pd > > then it would work with pd vanilla too. > This isn't working for me, using the latest pd-extended. When I start pd with the '-verbose' flag and then use a [declare] statement, what I am declaring is not getting searched (or at least it isn't posting that it is. Anyways, the object in that directory isn't found). I think this would be a good approach, similar to python's "from x import *" mechanism, but probably not good for help files, as they could introduce nameclashes that are avoided with namespaces. Personally, I would use namespace prefixes: [mrpeach/packOSC]. > This will make more sense when there are libraries organized around > concepts rather than authors. So something like [osc/packOSC] > This seems appropriate for help files, as it also tells you where to find the object within the extra folder. Sort of self-documenting. > > > >> - add a search pane to the help panel > > > > is this done in tcl/tk? is there any documentation about that on > > puredata.info? > > It is done however you want to, more or less, but I think a pure Tcl > solution would be possible, and perhaps easiest. > > .hc > > > > > > > > > > > > > >> - help design and code a library format that bundles > >> objectclasses, helpfiles, manuals, examples, etc then write code > >> to index it all, and create a GUI to navigate that content > >> At this point, I think it is mostly a waste of time to do constant > >> little workarounds like moving around objects. We should be > >> putting our scarce resources towards real improvements, not > >> temporary fixes, IMHO. > >> .hc > >> > > > > > > > News is what people want to keep hidden and everything else is > publicity. - Bill Moyers > > > > ___ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
On Sat, 2008-05-17 at 19:50 +0200, IOhannes m zmoelnig wrote: > Hans-Christoph Steiner wrote: > > > >> i'm not a developer but i would vote for declare > >> i.e. [declare -stdlib mrpeach] to packOSC-help.pd > >> then it would work with pd vanilla too. > > > > The declare/namespace/import stuff is still very undefined, so I > > think some experiementation would be good. I think you should go > > ahead and try it using what you propose. That will be a good test > > case. Then we'll figure out what works best. > > putting the helppatches besides the objects should fix most of the > problems, no? > no need for [declare] orgies and such yo.. it would seem strange having to put [declare]s into help-patches in order to load the the objects, that they are explaining, IMO. roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
Hans-Christoph Steiner wrote: > >> i'm not a developer but i would vote for declare >> i.e. [declare -stdlib mrpeach] to packOSC-help.pd >> then it would work with pd vanilla too. > > The declare/namespace/import stuff is still very undefined, so I > think some experiementation would be good. I think you should go > ahead and try it using what you propose. That will be a good test > case. Then we'll figure out what works best. putting the helppatches besides the objects should fix most of the problems, no? no need for [declare] orgies and such fgmasdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] help files was: Re: call for testing on the nightly builds!
On May 17, 2008, at 5:50 PM, Enrique Erne wrote: > Hans-Christoph Steiner wrote: >> There is much that can and should be done. Here's some ideas >> ranked into of difficulty: >> - file a bug report when a help patch is not working >> - write and improve help patches, and submit them to the patch >> tracker > > is there a convention about how to make it work? i.e. should one > use declare, import or namespace prefix? > > i guess all help-files that are not loaded on default would need a > declare/import/or-namespace in order to work... > > i want to contribute and help to make "all"/more helpfiles work. i > know there is pddp but afaik it does not solve the declare/import/ > or-namespace problem. > > could all developers express their opinion and agree on how to make > all helpfiles work? :) Starting with the PDDP template is a good place to start: http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/pddp/ templates/ > i'm not a developer but i would vote for declare > i.e. [declare -stdlib mrpeach] to packOSC-help.pd > then it would work with pd vanilla too. The declare/namespace/import stuff is still very undefined, so I think some experiementation would be good. I think you should go ahead and try it using what you propose. That will be a good test case. Then we'll figure out what works best. Personally, I would use namespace prefixes: [mrpeach/packOSC]. This will make more sense when there are libraries organized around concepts rather than authors. So something like [osc/packOSC] >> - add a search pane to the help panel > > is this done in tcl/tk? is there any documentation about that on > puredata.info? It is done however you want to, more or less, but I think a pure Tcl solution would be possible, and perhaps easiest. .hc > > > > > >> - help design and code a library format that bundles >> objectclasses, helpfiles, manuals, examples, etc then write code >> to index it all, and create a GUI to navigate that content >> At this point, I think it is mostly a waste of time to do constant >> little workarounds like moving around objects. We should be >> putting our scarce resources towards real improvements, not >> temporary fixes, IMHO. >> .hc >> News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] help files was: Re: call for testing on the nightly builds!
Hans-Christoph Steiner wrote: > > There is much that can and should be done. Here's some ideas ranked > into of difficulty: > > - file a bug report when a help patch is not working > - write and improve help patches, and submit them to the patch tracker is there a convention about how to make it work? i.e. should one use declare, import or namespace prefix? i guess all help-files that are not loaded on default would need a declare/import/or-namespace in order to work... i want to contribute and help to make "all"/more helpfiles work. i know there is pddp but afaik it does not solve the declare/import/or-namespace problem. could all developers express their opinion and agree on how to make all helpfiles work? :) i'm not a developer but i would vote for declare i.e. [declare -stdlib mrpeach] to packOSC-help.pd then it would work with pd vanilla too. > - add a search pane to the help panel is this done in tcl/tk? is there any documentation about that on puredata.info? > - help design and code a library format that bundles objectclasses, > helpfiles, manuals, examples, etc then write code to index it all, and > create a GUI to navigate that content > > At this point, I think it is mostly a waste of time to do constant > little workarounds like moving around objects. We should be putting our > scarce resources towards real improvements, not temporary fixes, IMHO. > > .hc > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
