I'm running 0.43.3-extended on a MacBook Pro Retina (Intel Core i7), with OSX 10.8.3.
I've only noticed in the last couple of days that some objects are not loading. For instance, if I bring up the netserver-help.pd help file, the netclient object loads, but netserver doesn't.
I also notice that some objects in iemmatrix do not load. For instance mtx_mul loads, but not mtx_mul~. Confusingly, the mtx_+ object in mtx+mul-help.pd doesn't load, but it does if I open mtx_add-help.pd.
I'm very confused. Can anyone enlighten me?
(For the record: I've deleted my .plist file and replaced the Pd-extended app with another fresh copy. No difference.)
Many thanks,
- martin
On Mon, 2013-04-22 at 16:01 +0100, Martin Dupras wrote:
I also notice that some objects in iemmatrix do not load. For instance mtx_mul loads, but not mtx_mul~. Confusingly, the mtx_+ object in mtx +mul-help.pd doesn't load, but it does if I open mtx_add-help.pd.
This is related to how those libraries are built in Pd-extended. It works if you load hexloader first. Somehow it was decided that hexloader is not loaded automatically, which is a pity. However, you can do it from your patch with [import hexloader], or - in your case - [import hexloader iemmatrix].
Roman
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.
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.
- martin
On 22 April 2013 16:40, Roman Haefeli reduzent@gmail.com wrote:
On Mon, 2013-04-22 at 16:01 +0100, Martin Dupras wrote:
I also notice that some objects in iemmatrix do not load. For instance mtx_mul loads, but not mtx_mul~. Confusingly, the mtx_+ object in mtx +mul-help.pd doesn't load, but it does if I open mtx_add-help.pd.
This is related to how those libraries are built in Pd-extended. It works if you load hexloader first. Somehow it was decided that hexloader is not loaded automatically, which is a pity. However, you can do it from your patch with [import hexloader], or - in your case - [import hexloader iemmatrix].
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
fgamsdr IOhannes
----- 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
On 04/23/2013 02:26, Jonathan Wilkes wrote:
I cannot figure out where the code is,
externals/loaders/hexloader/
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.
yes kind of.
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.
sounds like a good idea, though....
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.
i'm pretty sure there is a catch somewhere when it comes to loading abstractions.
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.
not sure whether this should be handled automatically or explicitely within an external.
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.
what's that "complexity"? having to have to look up some characters in an ascii table?
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.
just check the various loaders in externals/loaders/
gmdrs IOhannes
----- Original Message -----
From: IOhannes m zmölnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Tuesday, April 23, 2013 3:01 AM Subject: Re: [PD] Missing objects in Pd-Extended Intel OSX?
On 04/23/2013 02:26, Jonathan Wilkes wrote:
[...]
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.
i'm pretty sure there is a catch somewhere when it comes to loading abstractions.
Can you explain what the catch is? Is it intractable?
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.
not sure whether this should be handled automatically or explicitely within an external.
For [block~]/[switch~] level flexibility I think it has to be explicit. I need to think about it more...
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.
what's that "complexity"? having to have to look up some characters in an ascii table?
Plus telling the user, "To not get broken objects load this library that has a bug that is the reason it didn't already load."
But yes, having to look up characters in a table or even notice them in a filename in the help browser or search plugin is more complex than looking at human readable filenames and/or _setup routines.
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.
just check the various loaders in externals/loaders/
Ok thanks.
-Jonathan
gmdrs IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-04-23 18:30, Jonathan Wilkes wrote:
i'm pretty sure there is a catch somewhere when it comes to loading abstractions.
Can you explain what the catch is? Is it intractable?
no. this was a generic "i'm sure there is one but i cannot name it now" message.
mfgasdr IOhannes
Ignore my issue with netserver. It loads fine, I had a netreceive object open on the same port which prevented netserver to instantiate. It loads fine.
- martin
On 22 April 2013 16:01, Martin Dupras martindupras@gmail.com wrote:
I'm running 0.43.3-extended on a MacBook Pro Retina (Intel Core i7), with OSX 10.8.3.
I've only noticed in the last couple of days that some objects are not loading. For instance, if I bring up the netserver-help.pd help file, the netclient object loads, but netserver doesn't.
I also notice that some objects in iemmatrix do not load. For instance mtx_mul loads, but not mtx_mul~. Confusingly, the mtx_+ object in mtx+mul-help.pd doesn't load, but it does if I open mtx_add-help.pd.
I'm very confused. Can anyone enlighten me?
(For the record: I've deleted my .plist file and replaced the Pd-extended app with another fresh copy. No difference.)
Many thanks,
- martin
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jonathan Wilkes -
Martin Dupras -
Roman Haefeli