On 08/11/2007, at 14.50, Frank Barknecht wrote:
Hallo, Steffen Juul hat gesagt: // Steffen Juul wrote:
This is what i did for testing:
Made a folder in extra called test. In that i made an abstraction called testing.pd which was just a wrapper around a [print].
Then i made a new test patch which as: [declare -stdpath extra/test] [testing]
Okay, here's another test you could do to find out where declare tries to add the stdpath
Make a patch with [declare -stdpath funkypathname] or another unique name you definitely know doesn't exist, then load it while Pd was started with "-verbose". Try to create an unknown object like [unknown] and search for "funkypathname" in Pd's error output.
Verbose. Clever, Frank!
Now i also got the awnser to the other question. It will look for
[fiddle~] in a fiddle~ folder in extra - or any other folder in the
path. I had no idea.
That basically mean that if an objectclass live in a folder baring
the same name as the objectclass the it will be found. Fx having
extra/grid/grid.pd(_<platform>)
will mean that a [grid] object will be fund and created _without_
specifying it in the search-path settings...
Btw.: When doing this on Linux with a testpatch in "/tmp/funkytest.pd" my Pd searches for [unknown] give only /tmp/funkypathname/ as possible results with the funky pathname,
Here, on OS X, it looks for funkypathname in ${HOME}/Desktop. There
is no search in /tmp.
which is wrong: according to the docs, -stdpath should search relative to the Pd binary, not relative to the path, which is what [declare -path ...] should do.
On OS X, when Pd is installed as a .app application, the binary isn't
located such that extra is one step up in the folder tree. So as such
the example and the definition of the behavior in the help file
contradicts.
Looks like another [declare]-bug. (Maybe already reported?)
Don't know if Roman already did. Searching for 'declare' in the
tracker only shows up your report.