[PD] declare [was: Re: Idiomatic Pd]

[Luke Iannini]

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 at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>