So after a little chatting with Cyrille, and looking thru lots of various issues in deploying projects, I came up with something that I think is a solution for including libs like list-abs, mapping, etc. as a folder then using namespace prefixes (something that has been supported for a very long time in all versions of Pd).
Basically, one reason to include a library of abstractions with a project is to make sure that the project will continue to work on new versions of Pd and in many people's different installs. One key thing is getting the right code when you load an object with a name. For example, when you type [scale], and you get the one you want. One key problem here is that binaries will always override abstractions. So if you make an abstraction called threshold.pd in your project, and someone's install or some version of Pd includes a 'threshold' binary, you will not be able to load your threshold.pd in anyway on that setup.
So if you use a namespace prefix, then the binary would have to be in a folder of the same name and have the same name in order to prevent the abstraction from loading. So the question I wanted to answer was an easy way to support using folders for namespaces while including the library with the project. So here's the solution i came up with, you make a 'lib' folder in your project, stick the libraries as folders in 'lib', then use [declare -path lib]. Here's an example:
http://puredata.info/Members/hans/vanilla_libdir.tar.bz2
.hc
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
So here's the solution i came up with, you make a 'lib' folder in your project, stick the libraries as folders in 'lib', then use [declare -path lib].
This is actually the way, we are "installing" the rj and other libraries in RjDj scenes since the start of the project. (though rj-files aren't used with namespace prefixes generally)
As every RjDj scene always has a single topmost parent patch called _main.pd, this is where you put a [declare -path rj] object (plus a [declare -path .]) to let it find the "rj" subdirectory patches. (Here the declare "bug" of not working in child abstractions does not apply because _main.pd always is the toplevel patch)
If a scene wants to use e.g. list-abs, it can drop that directory into the scene directory, too, and use an appropriate declare again. Works perfectly, including help files.
But if libraries have complicated interdependencies or assume certain global path layouts, then this approach fails, which was the case with the old mapping files, at least partly.
Frank
On 02/05/2009, at 3.31, Hans-Christoph Steiner wrote:
So here's the solution i came up with, you make a 'lib' folder in your project, stick the libraries as folders in 'lib', then use [declare -path lib]. Here's an example:
But what about "sorry, couldn't find help patch for "mapping/ curve.pd"" ?
On May 5, 2009, at 12:09 PM, Steffen Juul wrote:
On 02/05/2009, at 3.31, Hans-Christoph Steiner wrote:
So here's the solution i came up with, you make a 'lib' folder in your project, stick the libraries as folders
in 'lib', then use [declare -path lib]. Here's an example:But what about "sorry, couldn't find help patch for "mapping/ curve.pd"" ?
I should have said, due to bugs in [declare], this only works on GNU/
Linux. Since Miller uses Linux, I was assuming that its the reference
platform in terms of how [declare] works. It currently works
differently/less on Mac OS X, for example.
But if libraries have complicated interdependencies or assume
certain global path layouts, then this approach fails, which was the case with the
old mapping files, at least partly.
Part of my point with this examples is to show that you can have a
simple setup while using namespace prefixes in the project, libraries
as folders, and in the libraries that a project uses. I couldn't find
any issues with the setup illustrated in that tarball, have you found
some?
.hc
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On May 5, 2009, at 12:09 PM, Steffen Juul wrote:
On 02/05/2009, at 3.31, Hans-Christoph Steiner wrote:
So here's the solution i came up with, you make a 'lib' folder in your project, stick the libraries as folders
in 'lib', then use [declare -path lib]. Here's an example:But what about "sorry, couldn't find help patch for "mapping/ curve.pd"" ?
I should have said, due to bugs in [declare], this only works on GNU/ Linux. Since Miller uses Linux, I was assuming that its the reference
platform in terms of how [declare] works. It currently works
differently/less on Mac OS X, for example.
What are these differences? In our RjDj sprints, most people use OS-X with no problems, and on Linux, the help files still aren't found either - which is a known issue of directory prefixes since ages: You have to set the help-path as well.
But if libraries have complicated interdependencies or assume certain global path layouts, then this approach fails, which was the case with the
old mapping files, at least partly.Part of my point with this examples is to show that you can have a
simple setup while using namespace prefixes in the project, libraries as folders, and in the libraries that a project uses. I couldn't find any issues with the setup illustrated in that tarball, have you found some?
"mapping" still assumes that it is installed in a subdirectory called "mapping" whose parent is in the search path. It's not possible for a user to just drop the patches from "mapping" into her project folder directly or into a differently named subdir made know with declare. A user has to mimick the directory layout set in mapping. And do so for purepd as well. That's not a problem with the tarball, it just a - deliberate - restriction of "mapping".
Frank
On May 6, 2009, at 1:54 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On May 5, 2009, at 12:09 PM, Steffen Juul wrote:
On 02/05/2009, at 3.31, Hans-Christoph Steiner wrote:
So here's the solution i came up with, you make a 'lib' folder in your project, stick the libraries as folders in 'lib', then use [declare -path lib]. Here's an example:
But what about "sorry, couldn't find help patch for "mapping/ curve.pd"" ?
I should have said, due to bugs in [declare], this only works on GNU/ Linux. Since Miller uses Linux, I was assuming that its the
reference platform in terms of how [declare] works. It currently works differently/less on Mac OS X, for example.What are these differences? In our RjDj sprints, most people use OS- X with no problems, and on Linux, the help files still aren't found either -
which is a known issue of directory prefixes since ages: You have to set the
help-path as well.
Ah yes, sorry there was a little crack smoking on my part. There are
so many myriad details to the current arrangement, I forgot some. I
don't think the outstanding bugs in declare were affecting this issue:
https://sourceforge.net/tracker/index.php?func=detail&aid=1714473&gr... https://sourceforge.net/tracker/index.php?func=detail&aid=1828573&gr... https://sourceforge.net/tracker/index.php?func=detail&aid=1917574&gr...
So help files work with the namespace prefixes with .pd_linux objects,
but not with abstractions. This is how IOhannes organized Gem in Pd-
extended and it works well there. For example, consider these files
in the same setup as the original vanilla_libdir example:
lib/cyclone/prepend.pd_linux lib/cyclone/prepend-help.pd lib/mapping/local_min.pd lib/mapping/local_min-help.pd
Then [declare -path lib] [cyclone/prepend] [mapping/local_min]
The help patch will work for the binary external [cyclone/prepend] but
not for the abstraction [mapping/local_min]. For the libdir loader,
it sets the helppath so this will work with loading libdirs as
libraries with the help patches embedded.
But if libraries have complicated interdependencies or assume
certain global path layouts, then this approach fails, which was the case with the old mapping files, at least partly.Part of my point with this examples is to show that you can have a simple setup while using namespace prefixes in the project,
libraries as folders, and in the libraries that a project uses. I couldn't find
any issues with the setup illustrated in that tarball, have you found
some?"mapping" still assumes that it is installed in a subdirectory
called "mapping" whose parent is in the search path. It's not possible for a user to
just drop the patches from "mapping" into her project folder directly or into a differently named subdir made know with declare. A user has to
mimick the directory layout set in mapping. And do so for purepd as well.
That's not a problem with the tarball, it just a - deliberate - restriction of
"mapping".
Well, its not really a 'mapping' question so much as a question of
using folders as libraries. This is to address a very real and
problematic issue caused by the fact that a binary external will
_always_ override an abstraction of the same name, no matter what the
setup. In the interest of making the libraries like 'mapping' and
'purepd' function in as many setups as possible, organizing them to
use namespace prefixes is the only existing method that I know of for
dealing with this issue. For me the key question is how to make this
organization work easily for people on multiple setups.
To quote previous emails to describe this issue: http://lists.puredata.info/pipermail/pd-dev/2009-04/013432.html
With abstractions the situation is worse. If you make your you
make your
abstraction called [threshold] and include it in the same folder as your project. Then you use a patch that uses smlib's [threshold] and close it. Reopen your patch and [threshold] will be the smlib one, _not_ your threshold.pd. Or say Miller adds [threshold] to Pd- vanilla, same story, except there is no way to ever load your threshold.pd, unless you stick into a folder and call it [myfolder/ threshold].
.hc
Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Mistrust authority - promote decentralization. - the hacker ethic
Jumped the gun a bit, forgot to include the new demo, here's an
updated zip file:
http://puredata.info/Members/hans/vanilla_libdir-20090506.zip
Basically, my point is, it would be great if abstractions also looked
in '.' for their helppatch just like externals.
.hc
On May 6, 2009, at 1:54 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On May 5, 2009, at 12:09 PM, Steffen Juul wrote:
On 02/05/2009, at 3.31, Hans-Christoph Steiner wrote:
So here's the solution i came up with, you make a 'lib' folder in your project, stick the libraries as folders in 'lib', then use [declare -path lib]. Here's an example:
But what about "sorry, couldn't find help patch for "mapping/ curve.pd"" ?
I should have said, due to bugs in [declare], this only works on GNU/ Linux. Since Miller uses Linux, I was assuming that its the
reference platform in terms of how [declare] works. It currently works differently/less on Mac OS X, for example.What are these differences? In our RjDj sprints, most people use OS- X with no problems, and on Linux, the help files still aren't found either -
which is a known issue of directory prefixes since ages: You have to set the
help-path as well.But if libraries have complicated interdependencies or assume
certain global path layouts, then this approach fails, which was the case with the old mapping files, at least partly.Part of my point with this examples is to show that you can have a simple setup while using namespace prefixes in the project,
libraries as folders, and in the libraries that a project uses. I couldn't find
any issues with the setup illustrated in that tarball, have you found
some?"mapping" still assumes that it is installed in a subdirectory
called "mapping" whose parent is in the search path. It's not possible for a user to
just drop the patches from "mapping" into her project folder directly or into a differently named subdir made know with declare. A user has to
mimick the directory layout set in mapping. And do so for purepd as well.
That's not a problem with the tarball, it just a - deliberate - restriction of
"mapping".Ciao
Frank
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne