I raised the priority as crashes are really serious. I disagree with your item 3), though. [route pointer] should not route GPointers, but meta-messages starting with the symbol "pointer" e.g.
[pointer 1 2 3(
|
[route pointer]
|
It does that just fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm, I'm just not understanding something about gpointers-- I'd just assumed when you send a pointer message it consists of the selector "pointer" followed by the gpointer itself (gridflow's [display] seems to confirm this). But clearly something else is going on because [route pointer] doesn't currently work for gpointers, nor will [pointer] accept a gpointer that has passed through [pointer $1( (though [route] will, without crashing, and output a usable gpointer that has the selector "list").
It also seems like "pointer 1 2 3" is an unchecked case of "bad arguments to message 'pointer'". So I guess I'm saying I agree that [route pointer] should route according to the selector "pointer", I just don't understand why a gpointer wouldn't match under those conditions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yep, a gpointer is not simply a message composed of "pointer" and some actual pointer blob. I don't know the exact details myself and don't really understand the source code, but they seem to be something very "special" just like signals are. As you know, [print] shows them as a not very helpful "(gpointer)", but if you pass a pointer to [list prepend set]-[list trim] and into a message box: There pointers show up as "(pointer)" with the "g" missing. Anyway don't bother trying [route (pointer)], it doesn't work either. :)
In the end we probably have to accept that gpointers don't have a "printable" selector, just like audio signals don't have one. Introducing a print- and routable selector as "pointer" may be useful, or maybe it's not, as some people may already use "pointer" as a meta-message in their patches, for example to handle mouse-"pointer" events or so.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(pointer) with the g missing is what is specified in m_atom.c for displaying a pointer atom. So I assume there's a difference between a pointer message and a pointer atom.
There are two reasons to [route] pointer messages.
1) Didactic-- [route] is a common object people use to learn about the behavior of messages in Pd. It would be nice to show all the predefined message types going to different outlets, which can't currently happen because [route] doesn't differentiate between pointers and anythings.
2) Because anythings and pointers aren't differentiated, this diminishes the flexibility of an abstraction inlet. So a data-structure related abstraction that wants to take "set," "flush", "clear", and pointer messages to the left inlet and do something else with the right inlet has to add an additional inlet. The [pointer] object can differentiate between a pointer and "rewind," for example. An abstraction should be able to have the same flexibility.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First I have to correct myself: The selector of a pointer-message is indeed "pointer", as can be seen with zexy's new rawprint object or by exploiting the error message of an object like [select] when sent a pointer which is "no method for 'pointer'".
So "route pointer" could or maybe should indeed route a "pointer" meta-message just like it can route a "gem_state" message However as [route] also strips off the selector you would be left with just the pointer that is more or less useless just like a "gem_state" stripped of its pointer cannot be used in the gem chain anymore.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Frank,
Is it really useless? If you send a gpointer through the following, it works:
[rewind $1(
|
[pointer]
That's a meta message consisting of a symbol-atom and a pointer-atom. And the pointer atom gets sent successfully to the right inlet. However, I can't currently find a way to test sending a single pointer-atom to the left inlet. (If you try to strip it with list trim you always end up with the "list" selector.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
that's not really what I meant. You can use pointers in a list-message of course ("list <pt1> <pt2> <pt3>") or [pack/unpack] many of them and so on. Even [pipe] works with pointers and lists of pointers now.
But when you strip a lone pointer from it's selector then the pointer itself could become the selector like: "list set 2"->[route list] becomes "set 2" and this will call the "set"-method of the next object. If this is a message box it will be set to "2".
But with a pointer you'd get "pointer <pt>" -> [route pointer] -> "<pt>", so now it would try to use some "<pt>" method, which is probably undefined. BTW: I guess that's what leads to the crash here. I think selectors must be symbols.
So to make use of the pointless pointer (pun intended :) one probably has to attach a selector again with [list] or [pointer] or something.
Anyway I guess we're now talking about the usefulness of route's implementation, which is debatable and led to the development of several nicer variants in GridFlow.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oops, I didn't realize that when lists get distributed the atoms are interpreted, just like the [list] object classes. E.g., I though the following would output an error but it works fine:
[list one two(
|
[select symbol]
You know, since [route list] has different behaviors depending on whether the first element is a float or symbol, the same could be done for [route pointer]-- strip the selector off of anythings, pass gpointer messages through unchanged. That way there is at least some consistency, in the sense that the selector is always being matched.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are a number of "types" in pd:
[symbol] [float] [list] [bang] [pointer]
[trigger symbol float list bang pointer]
[route] does [route symbol float list bang] so it is inconsistent that [route pointer] would not route the "pointer" atom type, and instead route based on the "pointer" as a symbolic selector. That right there is a bug IMHO.
As for the crash, I could also reproduce it using Pd version 0.42.5-extended-20100410 or pd-gui-rewrite 0.43 on Mac OS X 10.5.8/Intel. The crash is actually in the [print], not the [route]. When I remove the [print], it doesn't crash.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hans,
The crash is caused by any object which attempts to display the output: the<crtl-4> symbol box, [set $1( -- [ ( both cause the crash as well. The [route] object is outputting a symbol message with some mutant value (I assume the selector is 'symbol' because if you hook [route] to a [vsl], for example, you get "no method for 'symbol'"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
a message from matju to the other anonymous person who wrote on march 1st : GridFlow's [print] started stripping leading "float" and "list" at one point in the last few months... and a A_POINTER can't possibly be a selector EVER. therefore, the only other possibility, is that [route] is outputting things with the "list" selector instead of "pointer", which is already what it does with "float" messages. I don't know what happens after that, with the crashes and stuff.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Notice this patch doesn't address whether [route pointer] should indeed route a pointer message. Users probably shouldn't depend on routing a pointer to the reject outlet when routing "pointer foo bar" through [route pointer]. (But that's sufficiently obscure that there's no reason to print a warning about it.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Jonathan,
I raised the priority as crashes are really serious. I disagree with your item 3), though. [route pointer] should not route GPointers, but meta-messages starting with the symbol "pointer" e.g.
[pointer 1 2 3(
|
[route pointer]
|
It does that just fine.
Hm, I'm just not understanding something about gpointers-- I'd just assumed when you send a pointer message it consists of the selector "pointer" followed by the gpointer itself (gridflow's [display] seems to confirm this). But clearly something else is going on because [route pointer] doesn't currently work for gpointers, nor will [pointer] accept a gpointer that has passed through [pointer $1( (though [route] will, without crashing, and output a usable gpointer that has the selector "list").
It also seems like "pointer 1 2 3" is an unchecked case of "bad arguments to message 'pointer'". So I guess I'm saying I agree that [route pointer] should route according to the selector "pointer", I just don't understand why a gpointer wouldn't match under those conditions.
Yep, a gpointer is not simply a message composed of "pointer" and some actual pointer blob. I don't know the exact details myself and don't really understand the source code, but they seem to be something very "special" just like signals are. As you know, [print] shows them as a not very helpful "(gpointer)", but if you pass a pointer to [list prepend set]-[list trim] and into a message box: There pointers show up as "(pointer)" with the "g" missing. Anyway don't bother trying [route (pointer)], it doesn't work either. :)
In the end we probably have to accept that gpointers don't have a "printable" selector, just like audio signals don't have one. Introducing a print- and routable selector as "pointer" may be useful, or maybe it's not, as some people may already use "pointer" as a meta-message in their patches, for example to handle mouse-"pointer" events or so.
(pointer) with the g missing is what is specified in m_atom.c for displaying a pointer atom. So I assume there's a difference between a pointer message and a pointer atom.
There are two reasons to [route] pointer messages.
1) Didactic-- [route] is a common object people use to learn about the behavior of messages in Pd. It would be nice to show all the predefined message types going to different outlets, which can't currently happen because [route] doesn't differentiate between pointers and anythings.
2) Because anythings and pointers aren't differentiated, this diminishes the flexibility of an abstraction inlet. So a data-structure related abstraction that wants to take "set," "flush", "clear", and pointer messages to the left inlet and do something else with the right inlet has to add an additional inlet. The [pointer] object can differentiate between a pointer and "rewind," for example. An abstraction should be able to have the same flexibility.
First I have to correct myself: The selector of a pointer-message is indeed "pointer", as can be seen with zexy's new rawprint object or by exploiting the error message of an object like [select] when sent a pointer which is "no method for 'pointer'".
So "route pointer" could or maybe should indeed route a "pointer" meta-message just like it can route a "gem_state" message However as [route] also strips off the selector you would be left with just the pointer that is more or less useless just like a "gem_state" stripped of its pointer cannot be used in the gem chain anymore.
I meant to write:
useless just like a "gem_state" stripped of its *selector*.
Hi Frank,
Is it really useless? If you send a gpointer through the following, it works:
[rewind $1(
|
[pointer]
That's a meta message consisting of a symbol-atom and a pointer-atom. And the pointer atom gets sent successfully to the right inlet. However, I can't currently find a way to test sending a single pointer-atom to the left inlet. (If you try to strip it with list trim you always end up with the "list" selector.)
Hi Jonathan,
that's not really what I meant. You can use pointers in a list-message of course ("list <pt1> <pt2> <pt3>") or [pack/unpack] many of them and so on. Even [pipe] works with pointers and lists of pointers now.
But when you strip a lone pointer from it's selector then the pointer itself could become the selector like: "list set 2"->[route list] becomes "set 2" and this will call the "set"-method of the next object. If this is a message box it will be set to "2".
But with a pointer you'd get "pointer <pt>" -> [route pointer] -> "<pt>", so now it would try to use some "<pt>" method, which is probably undefined. BTW: I guess that's what leads to the crash here. I think selectors must be symbols.
So to make use of the pointless pointer (pun intended :) one probably has to attach a selector again with [list] or [pointer] or something.
Anyway I guess we're now talking about the usefulness of route's implementation, which is debatable and led to the development of several nicer variants in GridFlow.
Oops, I didn't realize that when lists get distributed the atoms are interpreted, just like the [list] object classes. E.g., I though the following would output an error but it works fine:
[list one two(
|
[select symbol]
You know, since [route list] has different behaviors depending on whether the first element is a float or symbol, the same could be done for [route pointer]-- strip the selector off of anythings, pass gpointer messages through unchanged. That way there is at least some consistency, in the sense that the selector is always being matched.
There are a number of "types" in pd:
[symbol] [float] [list] [bang] [pointer]
[trigger symbol float list bang pointer]
[route] does [route symbol float list bang] so it is inconsistent that [route pointer] would not route the "pointer" atom type, and instead route based on the "pointer" as a symbolic selector. That right there is a bug IMHO.
As for the crash, I could also reproduce it using Pd version 0.42.5-extended-20100410 or pd-gui-rewrite 0.43 on Mac OS X 10.5.8/Intel. The crash is actually in the [print], not the [route]. When I remove the [print], it doesn't crash.
Hans,
The crash is caused by any object which attempts to display the output: the<crtl-4> symbol box, [set $1( -- [ ( both cause the crash as well. The [route] object is outputting a symbol message with some mutant value (I assume the selector is 'symbol' because if you hook [route] to a [vsl], for example, you get "no method for 'symbol'"
a message from matju to the other anonymous person who wrote on march 1st : GridFlow's [print] started stripping leading "float" and "list" at one point in the last few months... and a A_POINTER can't possibly be a selector EVER. therefore, the only other possibility, is that [route] is outputting things with the "list" selector instead of "pointer", which is already what it does with "float" messages. I don't know what happens after that, with the crashes and stuff.
Fixed with patch #3605973
Notice this patch doesn't address whether [route pointer] should indeed route a pointer message. Users probably shouldn't depend on routing a pointer to the reject outlet when routing "pointer foo bar" through [route pointer]. (But that's sufficiently obscure that there's no reason to print a warning about it.)