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 <[EMAIL PROTECTED]> 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. > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
