[PD] Missing objects in Pd-Extended Intel OSX?

[Jonathan Wilkes]

----- Original Message -----
> From: IOhannes m zmölnig <zmoelnig at iem.at>
> To: pd-list at iem.at
> Cc: 
> Sent: Monday, April 22, 2013 1:51 PM
> Subject: Re: [PD] Missing objects in Pd-Extended Intel OSX?
> 
> On 04/22/2013 18:27, Martin Dupras wrote:
>>  Thanks for that, I don't think I would have found that out by myself.
>> 
>>  I'm just reading on hexloader right now. From what I understand, it
>>  allows the loading of library objects with (among other characters) 
> "~"
>>  in their name. 
> 
> hexloader allows to load externals whose name contains anything bbut
> A-Za-z0-9.
> (trailing) "~" is about the only non-trivial character that Pd had
> always supported in externals, the problem is more along the lines of
> "*". (so you got a detail wrong, but i guess you figured the greater 
> image).
> 
>>  Does anyone know why it was decided that it should not load by default?
>>  I'm a bit puzzled, because not having it loaded by default seems to
>>  break a number of help patches.
> 
> i haven't decided to not include it, but as the main author of the
> hexloader patch i know that there are some issues when it comes to
> loading of abstractions.

I cannot figure out where the code is, but I'm assuming there is a loop
that goes through each path in search of $object_name.$whatever to
load the setup routine, and then goes through each path for
$object_name.{pd, max} for loading abstractions.

Is this the case?  If so why not say for each directory, check if there
is a $directory-meta.pd, and if there is parse it to find a comment in the
form of:
ALIAS normal_characters_name weird_characters_name1 weird_characters_name2 etc.

Then if $object_name matches any of the atoms that follow ALIAS, look for any files inside
$directory that match any of the aliases.  If you find a match, follow the current loading logic
(i.e., look for $objectname_setup, etc.).  This has the benefit that the external/abstraction
developer doesn't have to care about what order to put the atoms after ALIAS, only that
one of the atoms uses "normal" characters that correspond to the characters of the filename
(minus the file extension) that contains the class/abstraction.

Finally, if there was a match, and there was a $normal_characters_name_setup that
was executed without error, then Pd should automatically do a "class_addcreator" for
each of the remaining aliases.

With this method you can have multiple "ALIAS name1 name2 etc." comments inside
$libdir-meta.pd.  Pd can just keep parsing until it finds a match-- if there is no match then
it just searches for the binary/abstraction as it already does.  If there is a match it would
check each filename inside the libdir against all the aliases of $object_name, which would
increase load time but only for that particular libdir which defines one or more ALIASes.
It's also trivial to support mutiple ALIAS comments-- the parser would stop on the first match,
and if there are overlapping aliases between classes _within_ a libdir that's the fault/responsibility
of the external/abstraction author.

I suppose its easier to require $1 of the "ALIAS" comment to be normal_characters_name.
I think it's better for the external/abstraction author if it can be an unordered list, but honestly
anything is better than the current hexloader complexity.

If someone can explain to me where the loop is in the source code where Pd looks for
binaries/abstractions, I'll try to code it myself.

-Jonathan

> 
> fgamsdr
> IOhannes
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>