----- Original Message -----
From: IOhannes m zmölnig zmoelnig@iem.at To: pd-list@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list