[PD-dev] [ pure-data-Bugs-2957058 ] pointer to [route symbol]-[print] crashes pd

SourceForge.net noreply at sourceforge.net
Mon Mar 1 19:41:10 CET 2010

Bugs item #2957058, was opened at 2010-02-23 06:11
Message generated for change (Comment added) made by nobody
You can respond by visiting: 

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Jonathan Wilkes (jancsika1)
Assigned to: Nobody/Anonymous (nobody)
Summary: pointer to [route symbol]-[print] crashes pd

Initial Comment:
[namecanvas foo]

[traverse foo, bang(
[route symbol]

1) a pointer message is erroneously routed as a symbol
2) this crashes Pd
3) [route pointer] doesn't route a pointer


Comment By: Nobody/Anonymous (nobody)
Date: 2010-03-01 18:41

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. 


Comment By: Jonathan Wilkes (jancsika1)
Date: 2010-03-01 17:48

Hi Frank,
     Is it really useless?  If you send a gpointer through the following,
it works:

[rewind $1(

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.)


Comment By: Frank Barknecht (fbar)
Date: 2010-03-01 12:16

I meant to write: 

useless just like a "gem_state" stripped of its *selector*.


Comment By: Frank Barknecht (fbar)
Date: 2010-03-01 12:15

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. 


Comment By: Jonathan Wilkes (jancsika1)
Date: 2010-03-01 03:11

(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.


Comment By: Frank Barknecht (fbar)
Date: 2010-02-25 16:37

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. 


Comment By: Jonathan Wilkes (jancsika1)
Date: 2010-02-25 05:54

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.


Comment By: Frank Barknecht (fbar)
Date: 2010-02-23 08:40

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. 


You can respond by visiting: 

More information about the Pd-dev mailing list