[PD-dev] library proposal WAS: pow~ in Cyclone [was: Re: stripping down Pd-extended's default libs]

[Hans-Christoph Steiner]

On Feb 19, 2009, at 6:26 PM, Roman Haefeli wrote:

> On Wed, 2009-02-18 at 12:59 -0500, Hans-Christoph Steiner wrote:
>
>> Here's how I think this all should work:
>>
>> - classes of any implementation language are treated the same
>> (i.e. .pd_linux, .pd, .pdlua, etc).
>> 	- single library format for all implementation methods
>> 	- possibility for shared code for objectclasses in library
>> 	- check for objectclasses in paths in same order for any
>> implementation method
>> 	- one objectclass per file
>> 	- help patch in same folder as objectclass file
>>
>> - search "." first, then canvas-local paths, then global paths
>>
>> - search using registered loaders (i.e. implementation langauges) one
>> dir at a time:
>> 	- first search "." for .pd .pd_linux .pdlua etc.
>> 	- then search first dir in canvas-local path  
>> for .pd .pd_linux .pdlua
>> etc.
>> 	- then search second dir in canvas-local path
>> for .pd .pd_linux .pdlua etc.
>> 	- ...
>> 	- then search first dir in global path for .pd .pd_linux .pdlua etc.
>> 	- then search second dir in global path for .pd .pd_linux .pdlua  
>> etc.
>> 	- ...
>>
>> - the loaded class names should follow the above rules of loading
>> classes
>>
>> - namespace prefixes stay as part of classname and do not load  
>> basename
>> 	- i.e. [cyclone/pow~] does not claim the name [pow~]
>>
>
> i rather don't want this to drip away into the deep ocean of pd list
> discussions.
>
> this sounds very reasonable to me and (please correct me) it would
> address most problems, that are currently in discussion.  i kind of  
> feel
> to be the wrong person to say that, since i haven't contributed
> code-wise to all those ideas, but i think it would be good to stick  
> that
> on a wikipage (dev section on puredata.info?), if people agree on  
> those
> 'guidelines'.
>
> i hope to see more comments on this....
>
> roman


Hey,

Thanks for the feedback, I hope there will be more discussion over  
it.  Just to be clear, I am not claiming that I came up with all those  
ideas, it is a collection of ideas from many people that has been  
developed over time.

I was hoping to get this all implemented in Pd-extended 0.41.4, but  
it'll require quite a bit of code, and probably a lot more testing to  
make sure that new bugs aren't introduced.  This might break some  
patches that rely on the current loading order, which is different  
than described.  Right now it searches by file type through all the  
paths, which is the opposite of what is outlined above. so like this:

- search for foo.pd_linux in "."
- search for foo.pd_linux in first dir of path
- search for foo.pd_linux in second dir of path
- ...
- search for foo.pd in "."
- search for foo.pd in first dir of path
- search for foo.pd in second dir of path
- ...

The current setup means that you can override a pd-vanilla abstraction  
using a binary class in ".", but you can't override a pd_vanilla  
binary using an abstraction in "."  That seems to treat .pd  
objectclasses as second class classes and I don't like that ;)

.hc




>
>
>
> 	
> 		
> ___________________________________________________________
> Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo!  
> Mail: http://mail.yahoo.de



----------------------------------------------------------------------------

Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.  Now that he can realize them, he must either  
change them, or perish.    -William Carlos Williams