heya,
...back to working on the app_pkg stuff, and I have a question: how are we supposed to access the internally-kept abstractions? Currently, pd++.app/Contents/Resources/extra & pd++.app/Contents/ Resources/doc/5.reference seem to be the only places that are in pd's path by default, yet there is also the pd++.app/Contents/Resources/ doc/abstractions folder that includes footils/list-abs, among other things: what is the strategy to access this?
...I've tried adding relative paths via the path preference (ie. ./../ doc/abstractions/footils/list-abs), but that doesn't seem to work...I'd really like to solve this, because then we can have easier access to more of the "meat of the bundle", like the nusmuk/iemlib/ rradical/creb/cyclone/etc. abstractions...
james
Hallo, james tittle hat gesagt: // james tittle wrote:
...back to working on the app_pkg stuff, and I have a question: how are we supposed to access the internally-kept abstractions? Currently, pd++.app/Contents/Resources/extra & pd++.app/Contents/ Resources/doc/5.reference seem to be the only places that are in pd's path by default, yet there is also the pd++.app/Contents/Resources/ doc/abstractions folder that includes footils/list-abs, among other things: what is the strategy to access this?
Actually this may be a good time to generally discuss how to deal with abstractions. In my opinion there should be a common place for abstractions like "extra" is for externals. No messing with the Pd-path should be necessary to see these abstractions.
Of course we could simply use "extra" as well. Personally I prefer to keep abstractions and externals apart. But I would really like to see an "install target" for abstractions as well. I would vote for "PD_ROOT/abs/", and maybe also a special help path "PD_ROOT/doc/6.abs.reference/" to put the help files for these abstractions. (All [list]-abs files contain proper help patches.)
Ciao
On Nov 15, 2005, at 12:55 PM, Frank Barknecht wrote:
Hallo, james tittle hat gesagt: // james tittle wrote:
...back to working on the app_pkg stuff, and I have a question: how are we supposed to access the internally-kept abstractions? Currently, pd++.app/Contents/Resources/extra & pd++.app/Contents/ Resources/doc/5.reference seem to be the only places that are in pd's path by default, yet there is also the pd++.app/Contents/Resources/ doc/abstractions folder that includes footils/list-abs, among other things: what is the strategy to access this?
Actually this may be a good time to generally discuss how to deal with abstractions. In my opinion there should be a common place for abstractions like "extra" is for externals. No messing with the Pd-path should be necessary to see these abstractions.
Of course we could simply use "extra" as well. Personally I prefer to keep abstractions and externals apart. But I would really like to see an "install target" for abstractions as well. I would vote for "PD_ROOT/abs/", and maybe also a special help path "PD_ROOT/doc/6.abs.reference/" to put the help files for these abstractions. (All [list]-abs files contain proper help patches.)
One of the problems is the vague definition of "abstraction" and "external". I think that "application" and "object" are much more useful distinctions.
When talking about the distros, I think we should group objects by functionality, not how they are implemented. So objects written in Pd, C, C++, Ruby, whatever would all into the same structure. That's how you think about the objects when you are using them within Pd.
As for the CVS structure, it makes sense to me to group objects, etc. by how they are implemented so that they can have a common build system. For example, "abstractions" in CVS is a good place to put objects written in Pd, then there would be a common Makefile for building the abstractions distro. It seems to me that the CVS would best be organized around build systems. So ideally, at the root of the CVS, we would have "abstractions" (or whatever) for Pd objects, "externals" for C, "flext" for C++/flext, "Gem" for Gem/GemLibs (unless it could be integrated into the externals/build system), 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
Depends on whether that abstraction is meant to be an application or an object. If its meant to be an object, like RRADical stuff, for example, it should go into "extra" with the rest of the objects, and have a help patch in 5.reference. The list-abs stuff are objects written in Pd, so they should be treated any other Pd objects.
As for applications, like demo patches, examples, etc., I am planning on making an "Examples" tree that included the example trees from Gem, PMPD, etc., as well as anything else along those lines. The RRADical showcase is another example.
I am now in the process of creating the cross-platform extended package maker, basically a port of the Pd.app stuff, with some new stuff thrown in. My current idea is to make a Makefile for CVS/abstractions and CVS/doc which would build into a "build" directory like "externals". Then the "abstractions" repository in CVS would basically be a repository of code that uses the common build method, kind of like "externals", though that's more mixed up.
.hc
On Nov 15, 2005, at 12:15 PM, james tittle wrote:
heya,
...back to working on the app_pkg stuff, and I have a question: how are we supposed to access the internally-kept abstractions? Currently, pd++.app/Contents/Resources/extra & pd++.app/Contents/Resources/doc/5.reference seem to be the only places that are in pd's path by default, yet there is also the pd++.app/Contents/Resources/doc/abstractions folder that includes footils/list-abs, among other things: what is the strategy to access this?
...I've tried adding relative paths via the path preference (ie. ./../doc/abstractions/footils/list-abs), but that doesn't seem to work...I'd really like to solve this, because then we can have easier access to more of the "meat of the bundle", like the nusmuk/iemlib/rradical/creb/cyclone/etc. abstractions...
james
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"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