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:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…
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(
|
[pointer]
|
[route symbol]
|
[print]
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
Message:
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
Message:
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.)
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2010-03-01 12:16
Message:
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
Message:
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
Message:
(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
Message:
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
Message:
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
Message:
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:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…
Bugs item #2957058, was opened at 2010-02-23 01:11
Message generated for change (Comment added) made by jancsika1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…
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(
|
[pointer]
|
[route symbol]
|
[print]
1) a pointer message is erroneously routed as a symbol
2) this crashes Pd
3) [route pointer] doesn't route a pointer
----------------------------------------------------------------------
>Comment By: Jonathan Wilkes (jancsika1)
Date: 2010-03-01 12:48
Message:
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.)
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2010-03-01 07:16
Message:
I meant to write:
useless just like a "gem_state" stripped of its *selector*.
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2010-03-01 07:15
Message:
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-02-28 22:11
Message:
(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 11:37
Message:
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 00:54
Message:
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 03:40
Message:
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:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…
Bugs item #2957058, was opened at 2010-02-23 07:11
Message generated for change (Comment added) made by fbar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…
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(
|
[pointer]
|
[route symbol]
|
[print]
1) a pointer message is erroneously routed as a symbol
2) this crashes Pd
3) [route pointer] doesn't route a pointer
----------------------------------------------------------------------
>Comment By: Frank Barknecht (fbar)
Date: 2010-03-01 13:16
Message:
I meant to write:
useless just like a "gem_state" stripped of its *selector*.
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2010-03-01 13:15
Message:
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 04:11
Message:
(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 17:37
Message:
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 06:54
Message:
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 09:40
Message:
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:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…
Bugs item #2957058, was opened at 2010-02-23 07:11
Message generated for change (Comment added) made by fbar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…
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(
|
[pointer]
|
[route symbol]
|
[print]
1) a pointer message is erroneously routed as a symbol
2) this crashes Pd
3) [route pointer] doesn't route a pointer
----------------------------------------------------------------------
>Comment By: Frank Barknecht (fbar)
Date: 2010-03-01 13:15
Message:
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 04:11
Message:
(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 17:37
Message:
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 06:54
Message:
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 09:40
Message:
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:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…
Bugs item #2960967, was opened at 2010-02-28 21:42
Message generated for change (Comment added) made by jancsika1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2960967&group_…
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: 5
Private: No
Submitted By: Jonathan Wilkes (jancsika1)
Assigned to: Nobody/Anonymous (nobody)
Summary: pddplink weirdness with dynamic patching
Initial Comment:
In the attached patch, clicking the pddplink object will send the value from the vsl to the nonlocal receive. It only happens on the first click. It doesn't matter which order the vsl and pddplink are created in. Under normal, manual patching the bug doesn't occur.
----------------------------------------------------------------------
>Comment By: Jonathan Wilkes (jancsika1)
Date: 2010-02-28 22:13
Message:
Oh, I forgot to add: on winxp, Pd version 0.42.5-extended-20100217. And as
far as I can tell the problem only occurs when linking to a pd patch that
has the .pd extension.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2960967&group_…
Bugs item #2957058, was opened at 2010-02-23 01:11
Message generated for change (Comment added) made by jancsika1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…
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(
|
[pointer]
|
[route symbol]
|
[print]
1) a pointer message is erroneously routed as a symbol
2) this crashes Pd
3) [route pointer] doesn't route a pointer
----------------------------------------------------------------------
>Comment By: Jonathan Wilkes (jancsika1)
Date: 2010-02-28 22:11
Message:
(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 11:37
Message:
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 00:54
Message:
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 03:40
Message:
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:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…
Bugs item #2960967, was opened at 2010-02-28 21:42
Message generated for change (Tracker Item Submitted) made by jancsika1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2960967&group_…
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: 5
Private: No
Submitted By: Jonathan Wilkes (jancsika1)
Assigned to: Nobody/Anonymous (nobody)
Summary: pddplink weirdness with dynamic patching
Initial Comment:
In the attached patch, clicking the pddplink object will send the value from the vsl to the nonlocal receive. It only happens on the first click. It doesn't matter which order the vsl and pddplink are created in. Under normal, manual patching the bug doesn't occur.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2960967&group_…
Bugs item #2949009, was opened at 2010-02-10 11:06
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2949009&group_…
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: pd-devel
Group: v0.43
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: IOhannes m zmlnig (zmoelnig)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: pd-gui-rewrite unusable with NumLock
Initial Comment:
when i have NumLock enabled, pd-gui-rewrite is unusable:
when creating an object, i cannot leave the creation (and thus trigger the instantiation) unless i resort to shortcuts like Ctrl-1.
i cannot connect objects
(trying to connect a messagebox will "click" it; trying to connect a numberbox will shift-drag it)
releasing NumLock fixes all problems
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2010-03-01 02:20
Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-02-14 19:08
Message:
I don't know why its a mask, but its in the C code, so I just left it as
is. Here's my attempt at a fix, I don't really have numlock on my laptop,
so I can't really test it. Let me know if it works for you.
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=131…
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-02-10 11:32
Message:
and whatever the good reasons behind adding alt/option press to the mouse
bindings, the "key-modifier" value sent to Pd is a _mask_.
since alt/option press uses the value "3", this means that the key-modifier
is actually "Shift+Alt" rather than a separate key.
is this by intention?
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-02-10 11:26
Message:
the bug stems from binding the mouse to "Option-Buttonpress-1" in
pd_bindings.tcl:134, which was added with revision 12849:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=128…
probably on OSX the "Option-Click" has a meaning, on linux it should be
disabled.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2949009&group_…
Bugs item #2960764, was opened at 2010-02-28 17:48
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2960764&group_…
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: pd-extended
Group: v0.42
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: System Crash with PD
Initial Comment:
Hello,
I have a windows xp intel atom processor with 2 gb of ram (it's a fairly nice netbook). I'm running Pd version 0.42-5 compiled for Microsoft Windows.
After I close pd, i check my system programs and pd.exe stays running taking up like 70% of my cpu processing. If I choose to end task it the I get a blue screen system failure and the computer restarts. So two issues: one pd.exe won't close, and two when i try to close it, it crashes my computer. Also, I noticed each time I started pd an added icon of the AISO sound driver pops up and i'm not sure why thats happening but it could be connect to a driver issue I guess.
Here's some event logs.
Application log
Event Type: Error
Event Source: Application Hang
Event Category: (101)
Event ID: 1002
Date: 2/28/2010
Time: 1:39:50 AM
User: N/A
Computer: YOUR-W5VBZ7LYQ8
Description:
Hanging application wish84.exe, version 8.4.2.18, hang module hungapp, version 0.0.0.0, hang address 0x00000000.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 48 61 6e 67 ion Hang
0010: 20 20 77 69 73 68 38 34 wish84
0018: 2e 65 78 65 20 38 2e 34 .exe 8.4
0020: 2e 32 2e 31 38 20 69 6e .2.18 in
0028: 20 68 75 6e 67 61 70 70 hungapp
0030: 20 30 2e 30 2e 30 2e 30 0.0.0.0
0038: 20 61 74 20 6f 66 66 73 at offs
0040: 65 74 20 30 30 30 30 30 et 00000
0048: 30 30 30 000
System log:
Event Type: Error
Event Source: System Error
Event Category: (102)
Event ID: 1003
Date: 2/28/2010
Time: 1:35:20 AM
User: N/A
Computer: YOUR-W5VBZ7LYQ8
Description:
Error code 100000d1, parameter1 00000000, parameter2 00000002, parameter3 00000000, parameter4 a91ecab0.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 53 79 73 74 65 6d 20 45 System E
0008: 72 72 6f 72 20 20 45 72 rror Er
0010: 72 6f 72 20 63 6f 64 65 ror code
0018: 20 31 30 30 30 30 30 64 100000d
0020: 31 20 20 50 61 72 61 6d 1 Param
0028: 65 74 65 72 73 20 30 30 eters 00
0030: 30 30 30 30 30 30 2c 20 000000,
0038: 30 30 30 30 30 30 30 32 00000002
0040: 2c 20 30 30 30 30 30 30 , 000000
0048: 30 30 2c 20 61 39 31 65 00, a91e
0050: 63 61 62 30 cab0
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2960764&group_…
Feature Requests item #2960329, was opened at 2010-02-27 13:48
Message generated for change (Tracker Item Submitted) made by jancsika1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=2960329&group_…
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
Priority: 5
Private: No
Submitted By: Jonathan Wilkes (jancsika1)
Assigned to: Nobody/Anonymous (nobody)
Summary: add dollarsign variable for abstraction args
Initial Comment:
There should be a special dollarsign variable to get abstraction args. This would make it easier to build expressive abstractions, without having to rely on dynamic patching which evidently is not "officially supported."
For example, say I have an abstraction that uses comparisons to decide whether or not the incoming value should be sent out the left or right outlet. Currently I can use the relational objects-- i.e., let the user decide which one to give as args to the abstraction and just have a [$1 $2] object inside it. But then maybe at some point in using my abstraction I think it would be really handy to use [expr] for a more complicated comparison. Currently to do so requires adding dynamic patching to my abstraction, which is of course a pain. If there were one dollarsign variable for getting all the args, however, I just use that in place of [$1 $2] (and it would work seamlessly).
I've purposely avoided putting a name to this dollarsign variable because I'm fine with whatever someone who has the skills to implement it comes up with.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=2960329&group_…