[PD] array size (was Re: arraysize)

[Hans-Christoph Steiner]

On 10/02/2012 10:56 AM, Hans-Christoph Steiner wrote:
> On 09/28/2012 11:43 AM, Claude Heiland-Allen wrote:
>> On 28/09/12 16:23, Miller Puckette wrote:
>>> Well, I'm persuadable on this front.  I'm concerned with unduly hogging
>>> the object namespace - in general, every time I add an object name I
>>> potentially introduce incompatiblities with someone's abstraction that
>>> might have the same name.  And there are 50 or so new classes (!) to
>>> provide.
>>> I don't even have a list yet (no pun intended)
>> Perhaps it would be better to refactor the object / abstraction /
>> binary / loading / namespace mechanism first, something along the
>> lines of an old discussion I had with HCS:
>>
>> http://claudiusmaximus.goto10.org/cm/2010-07-16_pure-data_libraries_conversation.html
>>
>>
>> Once that is fixed to something less baroque/crufty then it should be
>> easier for everyone to go nuts and have their own namespaces without
>> clobbering or hogging anything, and make patches more portable between
>> Pd variants.
>>
>> I have no time to work on this for the forseeable future, but it's
>> something that needs doing sooner rather than later...
>>
> I totally agree with this.  I think the easiest place to start would be
> to rework the load order, so that instead of going by file type, it goes
> by directory.  Right now, the load order first looks for .pd_linux files
> in every dir in the path, then looks for .pd files in every dir in the
> path.
>
> Instead it should start by searching or .pd_linux and .pd in the patch's
> own dir, then .pd_linux and .pd the canvas-local path, then  .pd_linux
> and .pd  in the global path, then  .pd_linux and .pd  in the built-in path.
>
> Currently, if you don't know that there is a 'foo.pd_linux' installed in
> your path, and your project folder includes 'foo.pd', your project will
> always load 'foo.pd_linux'.
>
> .hc


      Here's a good sketch of the idea
      (http://puredata.info/dev/PdSearchPath):


      Proposed Functionality

   for path in paths do -- the core does this bit
     for loader in loaders do
       loader(path, library, object)


      Existing Functionality

  for loader in loaders do
    for path in paths do -- the loader does this bit
      loader(path, library, object)

.hc