Hallo, I'm just adding my voice to the choir here before falling asleep after playing with this in my setup tonight - I definitely think [declare -path] should be re-enabled inside abstractions, and should be relative to the abstraction's file location.
My goal is to remove all directories from the global path because I discovered the ~40 that come with Pd-extended plus the other 15 I added personally were playing a very significant role in the rapidly increasing (now ~15 minute) loadtime of my large performance patch.
My layout (in a cartoon rendering) is something like this: Drum-modules/ Datastructure-abs/ MIDI-abs/ Helper-abs/ Performance-patches/
If I'd like to load DrumModules abstractions from within a Performance-patch (with [declare -path ../Drum-modules]), and DrumModules abstractions use Helper-abs abstractions, I need [declare -path ../Helper-abs] to work within a Drum-modules abstraction.
If no Helper-abs are used within Performance-patch, then I don't want to put [declare -path ../Helper-abs] there, because it would mean Performance-patch would be looking in Helper-abs when all I want are Drum-modules, slowing down the search process.*
Is it true that having more files in any one path increases the lookup time? I'd think it a good thing to encourage breaking large patch collections into folders for organization reasons alone, and if there are performance benefits to that too, then all the better!
Best Luke
*and, to drive the point home further, say I also had "Score-modules" inside Performance-patch that needed MIDI-abs and Datastructure-abs: I /really/ don't want to put [declare -path ../MIDI-abs -path ../Datastructure-abs] in Performance-patch because now Performance-patch is looking for Drum-modules in MIDI-abs and Datastructure-abs for no reason.
Worse, Drum-modules inherit these paths too and are looking fruitlessly for their Helper-abs in MIDI-abs and Datastructure-abs, which is what I was trying to avoid in the first place when switching from global to local namespaces.
On Sun, Aug 3, 2008 at 12:33 PM, marius schebella marius.schebella@gmail.com wrote:
Hans-Christoph Steiner wrote:
On Jul 30, 2008, at 3:15 PM, marius schebella wrote:
Hans-Christoph Steiner wrote:
If we want to have namespaces working, then I suggest we use the tried-n-true model of other languages. If people are really interested in experimenting with ideas of how to handle namespaces, then we could try other options. Either way, we should start by getting the tried-n-true model working first, IMHO. Then if people want to experiment with things like inheriting namespaces from the parent, there will be a solid, working foundation to build upon.
what's the tried-n-true model? and why is expanding namespaces to (sub)classes not part of tried-n-true? I think an inheritance model should be introduced into pd.
declare is intended to load libraries or objectclasses only locally (only available to the patch that holds the declare object - since 0.41 this should be the case.)
for nested abstractions there are three possibilities: (1) don't inherit anything, (2) inherit from parent to child, (3) inherit from child to parent. (or several declare options that allow all three possibilities.)
I would like to "vote" for solution 2. but I think there are technical problems with this option: afaik it is not possible to "overwrite" a declaration. for now it is first come first serve. so if an abstraction inside a nested patch wanted to use a certain objectclass which is in conflict with the parent patch, that would just not be possible. and another problem seems to be that abstractions get loaded first, so the first come - first serve works even worse right now, because it loads declarations of abstractions before the parent patch. please correct me, if I am wrong.
I see usecases for method (3), too. if you want to throw a certain set of declarations into all your patches as abstractions. but I think this causes more problems than it solves. what if you have two conflicting abstractions in parallel, that both try to set the namespace for the parent patch?
marius.
I think it is essential that each object be complete and functional no matter what other things are setup in the namespace. Having one patch inherit the namespace of the other could cause an object to break if a different [prepend] was loaded first, for example.
In order for objectclasses to be self-contained, there needs to be a canvas-local namespace for every patch that is checked before any inherited namespace. That is missing right now. There could then be a "parent" namespace, then there is already the global namespace. Personally, I think this is overly complicated. I think that global and canvas-local is enough. Those two are the essential ones.
Python, for example, does have more levels, like the "module" level namespace, which could be seen as a kind of parallel to a "parent" namespace. As long as there is a true canvas-local namespace, then this is a workable option.
.hc
hi, I realized that the example I gave in the beginning of this thread was bad, because it did not use declare at all! And reading also the discussion on the similar thread (loooooooong) clarified some things. My intention is still to give patches a better structure for the future. One of the things that changed my thinking was the fact that there is a difference between namespaces and searchpaths. If local patch/canvas namespaces are working, the whole "loading before" and "loading after" would become irrelevant. relying only on searchpaths means everything is dependend on the loading order of libraries, or object classes respectively. but include, define, require, declare, import, loadlib, loadpath all have slightly different meanings... It would be cool, if the behaviour would be better pointed out; the current and the future one, too. that would make the whole mechanism more clear, comprehensible and traceable. that said, back to the problem of declaring relative search paths in abstractions. the idea of adding a relative path is that instead of writing path/to/my/folder/someresource1.xyz one could write [declare -path path/to/my/folder] and then references someresource1.xyz without the need to type the path over and over again. that is useful for resources like images or soundfiles, (the question whether this should also work for abstractions too, is still undecided). situation 1: the abstraction depends on resorces that are relative to the abstraction directory. no question this situation will appear and can only be managed, if relative paths are relative to the file location of the abstraction. situation 2: An abstraction wants to access a folder that is relative to the file location of the pd-patch file that nests the abstraction. for example a slideshow-abstraction that should grab 20 images of a folder relative to the parent patch. in this case [declare -path $1] inside the abstraction would try to find the folder relative to the abstraction location instead of the "parent" patch loacation. This is already the case if sending a relative path to an object in an abstraction like [open path/to/resource.xyz(, which is/was always relative to the file loaction of the abstraction, even if you use [open $1( and feed the path from outside. so after all, I guess Reverend Roman was right. the solution for situation 2 would be to put the declare object in the patchfile to which the directory is relative to. cheers, marius.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list