Dear people
In my role as village idiot, I am asking whether the string "fwd" in a message has a special meaning to inlet.
Naively, I was expecting inlet to pass the string to the subpatch, but it seems not to. See example patch attached.
Outlet behaves as I was expecting and inlet will pass "symbol fwd".
Clearly, I have failed to grasp something simple, but what?
In case this is version specific behaviour, I am using Pd 0.51.0 on Linux.
All the best
m
matthew brandi
Oops - this apparently crept in as part of the inlet~ message outlet feature. I think I have a simple fix, will stage for a bugfix release.
cheers Miller
On Thu, Aug 06, 2020 at 06:31:29PM +0100, matthew brandi wrote:
Dear people
In my role as village idiot, I am asking whether the string "fwd" in a message has a special meaning to inlet.
Naively, I was expecting inlet to pass the string to the subpatch, but it seems not to. See example patch attached.
Outlet behaves as I was expecting and inlet will pass "symbol fwd".
Clearly, I have failed to grasp something simple, but what?
In case this is version specific behaviour, I am using Pd 0.51.0 on Linux.
All the best
m
matthew brandi
#N canvas 645 195 817 288 12; #N canvas 5 93 331 138 in-out 0; #X obj 45 38 inlet; #X obj 45 64 outlet; #X connect 0 0 1 0; #X restore 436 133 pd in-out; #X msg 455 65 bck; #X msg 491 65 rnd; #X msg 417 65 fwd; #X msg 335 65 symbol fwd; #X obj 436 159 symbol; #X symbolatom 436 185 10 0 0 0 - - -; #X msg 185 66 bck; #X msg 221 66 rnd; #X msg 149 66 fwd; #X msg 67 66 symbol fwd; #X obj 149 160 symbol; #X symbolatom 149 186 10 0 0 0 - - -; #N canvas 1068 494 333 218 out 0; #X obj 46 38 inlet; #X obj 46 64 bang; #X msg 46 90 fwd; #X obj 46 165 outlet; #X msg 101 90 bck; #X obj 101 38 inlet; #X obj 101 64 bang; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 4 0 3 0; #X connect 5 0 6 0; #X connect 6 0 4 0; #X restore 621 129 pd out; #X obj 621 155 symbol; #X symbolatom 621 181 10 0 0 0 - - -; #X msg 621 71 bang; #X msg 660 71 bang; #X text 591 72 fwd; #X text 700 71 bck; #X connect 0 0 5 0; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 0 0; #X connect 4 0 0 0; #X connect 5 0 6 0; #X connect 7 0 11 0; #X connect 8 0 11 0; #X connect 9 0 11 0; #X connect 10 0 11 0; #X connect 11 0 12 0; #X connect 13 0 14 0; #X connect 14 0 15 0; #X connect 16 0 13 0; #X connect 17 0 13 1;
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
Hi Miller,
I didn't get your e-mail on time, so I've already a pushed a trivial fix to the "develop" branch in the meantime.
Christof
On 06.08.2020 20:44, Miller Puckette via Pd-list wrote:
Oops - this apparently crept in as part of the inlet~ message outlet feature. I think I have a simple fix, will stage for a bugfix release.
cheers Miller
On Thu, Aug 06, 2020 at 06:31:29PM +0100, matthew brandi wrote:
Dear people
In my role as village idiot, I am asking whether the string "fwd" in a message has a special meaning to inlet.
Naively, I was expecting inlet to pass the string to the subpatch, but it seems not to. See example patch attached.
Outlet behaves as I was expecting and inlet will pass "symbol fwd".
Clearly, I have failed to grasp something simple, but what?
In case this is version specific behaviour, I am using Pd 0.51.0 on Linux.
All the best
m
matthew brandi #N canvas 645 195 817 288 12; #N canvas 5 93 331 138 in-out 0; #X obj 45 38 inlet; #X obj 45 64 outlet; #X connect 0 0 1 0; #X restore 436 133 pd in-out; #X msg 455 65 bck; #X msg 491 65 rnd; #X msg 417 65 fwd; #X msg 335 65 symbol fwd; #X obj 436 159 symbol; #X symbolatom 436 185 10 0 0 0 - - -; #X msg 185 66 bck; #X msg 221 66 rnd; #X msg 149 66 fwd; #X msg 67 66 symbol fwd; #X obj 149 160 symbol; #X symbolatom 149 186 10 0 0 0 - - -; #N canvas 1068 494 333 218 out 0; #X obj 46 38 inlet; #X obj 46 64 bang; #X msg 46 90 fwd; #X obj 46 165 outlet; #X msg 101 90 bck; #X obj 101 38 inlet; #X obj 101 64 bang; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 4 0 3 0; #X connect 5 0 6 0; #X connect 6 0 4 0; #X restore 621 129 pd out; #X obj 621 155 symbol; #X symbolatom 621 181 10 0 0 0 - - -; #X msg 621 71 bang; #X msg 660 71 bang; #X text 591 72 fwd; #X text 700 71 bck; #X connect 0 0 5 0; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 0 0; #X connect 4 0 0 0; #X connect 5 0 6 0; #X connect 7 0 11 0; #X connect 8 0 11 0; #X connect 9 0 11 0; #X connect 10 0 11 0; #X connect 11 0 12 0; #X connect 13 0 14 0; #X connect 14 0 15 0; #X connect 16 0 13 0; #X connect 17 0 13 1; _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
D'oh, I've seen that you've pushed your fix on Master. I've reverted mine on develop.
On 06.08.2020 21:30, Christof Ressi wrote:
Hi Miller,
I didn't get your e-mail on time, so I've already a pushed a trivial fix to the "develop" branch in the meantime.
Christof
On 06.08.2020 20:44, Miller Puckette via Pd-list wrote:
Oops - this apparently crept in as part of the inlet~ message outlet feature. I think I have a simple fix, will stage for a bugfix release.
cheers Miller
On Thu, Aug 06, 2020 at 06:31:29PM +0100, matthew brandi wrote:
Dear people
In my role as village idiot, I am asking whether the string "fwd" in a message has a special meaning to inlet.
Naively, I was expecting inlet to pass the string to the subpatch, but it seems not to. See example patch attached.
Outlet behaves as I was expecting and inlet will pass "symbol fwd".
Clearly, I have failed to grasp something simple, but what?
In case this is version specific behaviour, I am using Pd 0.51.0 on Linux.
All the best
m
matthew brandi #N canvas 645 195 817 288 12; #N canvas 5 93 331 138 in-out 0; #X obj 45 38 inlet; #X obj 45 64 outlet; #X connect 0 0 1 0; #X restore 436 133 pd in-out; #X msg 455 65 bck; #X msg 491 65 rnd; #X msg 417 65 fwd; #X msg 335 65 symbol fwd; #X obj 436 159 symbol; #X symbolatom 436 185 10 0 0 0 - - -; #X msg 185 66 bck; #X msg 221 66 rnd; #X msg 149 66 fwd; #X msg 67 66 symbol fwd; #X obj 149 160 symbol; #X symbolatom 149 186 10 0 0 0 - - -; #N canvas 1068 494 333 218 out 0; #X obj 46 38 inlet; #X obj 46 64 bang; #X msg 46 90 fwd; #X obj 46 165 outlet; #X msg 101 90 bck; #X obj 101 38 inlet; #X obj 101 64 bang; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 4 0 3 0; #X connect 5 0 6 0; #X connect 6 0 4 0; #X restore 621 129 pd out; #X obj 621 155 symbol; #X symbolatom 621 181 10 0 0 0 - - -; #X msg 621 71 bang; #X msg 660 71 bang; #X text 591 72 fwd; #X text 700 71 bck; #X connect 0 0 5 0; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 0 0; #X connect 4 0 0 0; #X connect 5 0 6 0; #X connect 7 0 11 0; #X connect 8 0 11 0; #X connect 9 0 11 0; #X connect 10 0 11 0; #X connect 11 0 12 0; #X connect 13 0 14 0; #X connect 14 0 15 0; #X connect 16 0 13 0; #X connect 17 0 13 1; _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 06/08/2020 19:44, Miller Puckette wrote:
Oops - this apparently crept in as part of the inlet~ message outlet feature. I think I have a simple fix, will stage for a bugfix release.
Thanks, Miller, Christof, and Jonathan.
I did wonder whether it was related to the change in inlet~, but I thought it best not to assume it was.
All the best
m
since we're touching "inlet/inlet~", here's another issue :)
https://github.com/pure-data/pure-data/issues/1111
Em qui., 6 de ago. de 2020 às 18:27, matthew brandi mfbrandi@outlook.com escreveu:
On 06/08/2020 19:44, Miller Puckette wrote:
Oops - this apparently crept in as part of the inlet~ message outlet feature. I think I have a simple fix, will stage for a bugfix release.
Thanks, Miller, Christof, and Jonathan.
I did wonder whether it was related to the change in inlet~, but I thought it best not to assume it was.
All the best
m
-- matthew brandi | 020 8882 4616
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I am asking whether the string "fwd" in a message has a special meaning to inlet.
You have hit a bug! "fwd" is internally used by signal inlets to forward messages to the (new) second outlet, but it accidentally broke "fwd" messages for non-signal inlets. I've just pushed a fix to the develop branch.
Christof
On 06.08.2020 19:31, matthew brandi wrote:
Dear people
In my role as village idiot, I am asking whether the string "fwd" in a message has a special meaning to inlet.
Naively, I was expecting inlet to pass the string to the subpatch, but it seems not to. See example patch attached.
Outlet behaves as I was expecting and inlet will pass "symbol fwd".
Clearly, I have failed to grasp something simple, but what?
In case this is version specific behaviour, I am using Pd 0.51.0 on Linux.
All the best
m
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Thursday, August 6, 2020, 2:07:09 PM EDT, matthew brandi mfbrandi@outlook.com wrote: Dear people
In my role as village idiot, I am asking whether the string "fwd" in a message has a
special meaning to inlet.
Naively, I was expecting inlet to pass the string to the subpatch, but it seems not
to. See example patch attached.
AFAICT that's a regression due to the way Pd Vanilla implemented message forwarding for [inlet~ fwd]. That's a feature that allows a signal inlet of a subpatch/abstraction to forward non-signal messages to the right outlet of [inlet~ fwd]. (The right outlet sprouts when the "fwd" argument is present.) Another regression-- there is no longer an error if you try to send a non-signal message to [inlet~]. Another regression-- [inlet~ fwd] unconditionally allocates space on the stack to copy the entire incoming message. If you generate a long enough message this will blow the stack and cause Pd to crash. Esp. important given that Windows stack is much smaller than the RAM available for heap allocation on most machines. Also-- I *think* Pd Vanilla doesn't forward pointer messages through [inlet~ fwd]. It appeared to be an oversight-- at least I didn't see any comment about it.
A GSoC student spent some time reimplementing this in Purr Data, so none of thiese should be issues there. Best,Jonathan
Another regression-- [inlet~ fwd] unconditionally allocates space on the stack to copy the entire incoming message. Also-- I *think* Pd Vanilla doesn't forward pointer messages through [inlet~ fwd]
Good points!
On 06.08.2020 21:05, Jonathan Wilkes wrote:
On Thursday, August 6, 2020, 2:07:09 PM EDT, matthew brandi
mfbrandi@outlook.com wrote:
Dear people
In my role as village idiot, I am asking whether the string "fwd" in
a message has a special meaning to inlet.
Naively, I was expecting inlet to pass the string to the subpatch,
but it seems not to. See example patch attached.
AFAICT that's a regression due to the way Pd Vanilla implemented message forwarding for [inlet~ fwd]. That's a feature that allows a signal inlet of a subpatch/abstraction to forward non-signal messages to the right outlet of [inlet~ fwd]. (The right outlet sprouts when the "fwd" argument is present.)
Another regression-- there is no longer an error if you try to send a non-signal message to [inlet~].
Another regression-- [inlet~ fwd] unconditionally allocates space on the stack to copy the entire incoming message. If you generate a long enough message this will blow the stack and cause Pd to crash. Esp. important given that Windows stack is much smaller than the RAM available for heap allocation on most machines.
Also-- I *think* Pd Vanilla doesn't forward pointer messages through [inlet~ fwd]. It appeared to be an oversight-- at least I didn't see any comment about it.
A GSoC student spent some time reimplementing this in Purr Data, so none of thiese should be issues there.
Best, Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em qui., 6 de ago. de 2020 às 16:08, Jonathan Wilkes jancsika@yahoo.com escreveu:
On Thursday, August 6, 2020, 2:07:09 PM EDT, matthew brandi <
mfbrandi@outlook.com> wrote:
Dear people
In my role as village idiot, I am asking whether the string "fwd" in a
message has a special meaning to inlet.
Naively, I was expecting inlet to pass the string to the subpatch, but
it seems not to. See example patch attached.
AFAICT that's a regression due to the way Pd Vanilla implemented message forwarding for [inlet~ fwd]. That's a feature that allows a signal inlet of a subpatch/abstraction to forward non-signal messages to the right outlet of [inlet~ fwd]. (The right outlet sprouts when the "fwd" argument is present.)
Another regression-- there is no longer an error if you try to send a non-signal message to [inlet~].
Another regression-- [inlet~ fwd] unconditionally allocates space on the stack to copy the entire incoming message. If you generate a long enough message this will blow the stack and cause Pd to crash. Esp. important given that Windows stack is much smaller than the RAM available for heap allocation on most machines.
Also-- I *think* Pd Vanilla doesn't forward pointer messages through [inlet~ fwd]. It appeared to be an oversight-- at least I didn't see any comment about it.
A GSoC student spent some time reimplementing this in Purr Data, so none of thiese should be issues there.
I think it's a good idea if you're changing and fixing stuff to also send a PR to vanilla as a proposal. Would you consider doing that as well?
On Saturday, August 29, 2020, 03:04:25 PM EDT, Alexandre Torres Porres <porres@gmail.com> wrote:
Em qui., 6 de ago. de 2020 às 16:08, Jonathan Wilkes jancsika@yahoo.com escreveu:
On Thursday, August 6, 2020, 2:07:09 PM EDT, matthew brandi mfbrandi@outlook.com wrote: Dear people
In my role as village idiot, I am asking whether the string "fwd" in a message has a
special meaning to inlet.
Naively, I was expecting inlet to pass the string to the subpatch, but it seems not
to. See example patch attached.
AFAICT that's a regression due to the way Pd Vanilla implemented message forwarding for [inlet~ fwd]. That's a feature that allows a signal inlet of a subpatch/abstraction to forward non-signal messages to the right outlet of [inlet~ fwd]. (The right outlet sprouts when the "fwd" argument is present.) Another regression-- there is no longer an error if you try to send a non-signal message to [inlet~]. Another regression-- [inlet~ fwd] unconditionally allocates space on the stack to copy the entire incoming message. If you generate a long enough message this will blow the stack and cause Pd to crash. Esp. important given that Windows stack is much smaller than the RAM available for heap allocation on most machines. Also-- I *think* Pd Vanilla doesn't forward pointer messages through [inlet~ fwd]. It appeared to be an oversight-- at least I didn't see any comment about it.
A GSoC student spent some time reimplementing this in Purr Data, so none of thiese should be issues there.
I think it's a good idea if you're changing and fixing stuff to also send a PR to vanilla as a proposal. Would you consider doing that as well?
Before you ask that, have a look at the PRs. You can view the list of open PRs for Pure Data Vanilla here: https://github.com/pure-data/pure-data/pulls
It appears Christof (Spacechild1) submitted a patch for this almost a month ago. So it wouldn't make sense to send another PR for this same fix. Christof's patch should work just fine to solve these issues. If you're asking in general, that's unfortunately just not practical. We'd have to manually create a new patch set and test it for Vanilla, for (nearly) every single change we make. It's much easier to just report here when I find crashers-- Miller and Christof are quite quick to fix them. They know the Vanilla build/test/development process much better than I do so that seems the much preferable route for everyone involved. Best,Jonathan
Em sáb., 29 de ago. de 2020 às 16:58, Jonathan Wilkes jancsika@yahoo.com escreveu:
Before you ask that, have a look at the PRs. You can view the list of open PRs for Pure Data Vanilla here:
yeah, I'm quite aware. If you check there, you can see I usually participate with PRs, so I obviously know about it. Actually, I also get emails every time a new PR is made.
If you're asking in general
yup, exactly, sorry for not being clearer.
that's unfortunately just not practical. We'd have to manually create a new patch set and test it for Vanilla, for (nearly) every single change we make. It's much easier to just report here when I find crashers -- Miller and Christof are quite quick to fix them. They know the Vanilla build/test/development process much better than I do so that seems the much preferable route for everyone involved.
ok, that's alright, it didn't occur to me that was a system, just let me please also suggest using the issue tracker.
Best, Jonathan
cheers.
I agree that it's not practical for you to submit patches both to Pd vanilla and PurrData. After all, it is mostly trivial to backport the changes. Just let us know occasionally when you've found some critical issues :-)
Christof
On 29.08.2020 21:58, Jonathan Wilkes via Pd-list wrote:
On Saturday, August 29, 2020, 03:04:25 PM EDT, Alexandre Torres Porres porres@gmail.com wrote:
Em qui., 6 de ago. de 2020 às 16:08, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> escreveu:
> On Thursday, August 6, 2020, 2:07:09 PM EDT, matthew brandi <mfbrandi@outlook.com> wrote: > Dear people > In my role as village idiot, I am asking whether the string "fwd" in a message has a special meaning to inlet. > Naively, I was expecting inlet to pass the string to the subpatch, but it seems not to. See example patch attached. AFAICT that's a regression due to the way Pd Vanilla implemented message forwarding for [inlet~ fwd]. That's a feature that allows a signal inlet of a subpatch/abstraction to forward non-signal messages to the right outlet of [inlet~ fwd]. (The right outlet sprouts when the "fwd" argument is present.) Another regression-- there is no longer an error if you try to send a non-signal message to [inlet~]. Another regression-- [inlet~ fwd] unconditionally allocates space on the stack to copy the entire incoming message. If you generate a long enough message this will blow the stack and cause Pd to crash. Esp. important given that Windows stack is much smaller than the RAM available for heap allocation on most machines. Also-- I *think* Pd Vanilla doesn't forward pointer messages through [inlet~ fwd]. It appeared to be an oversight-- at least I didn't see any comment about it. A GSoC student spent some time reimplementing this in Purr Data, so none of thiese should be issues there.I think it's a good idea if you're changing and fixing stuff to also
send a PR to vanilla as a proposal. Would you consider doing that as well?
Before you ask that, have a look at the PRs. You can view the list of open PRs for Pure Data Vanilla here:
https://github.com/pure-data/pure-data/pulls
It appears Christof (Spacechild1) submitted a patch for this almost a month ago. So it wouldn't make sense to send another PR for this same fix. Christof's patch should work just fine to solve these issues.
If you're asking in general, that's unfortunately just not practical. We'd have to manually create a new patch set and test it for Vanilla, for (nearly) every single change we make. It's much easier to just report here when I find crashers-- Miller and Christof are quite quick to fix them. They know the Vanilla build/test/development process much better than I do so that seems the much preferable route for everyone involved.
Best, Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I agree that it's not practical for you to submit patches both to Pd vanilla and PurrData. After all, it is mostly trivial to backport the changes. Just let us know occasionally when you've found some critical issues :-)
Will do. Best,Jonathan
Christof
On 29.08.2020 21:58, Jonathan Wilkes via Pd-list wrote:
On Saturday, August 29, 2020, 03:04:25 PM EDT, Alexandre Torres Porres <porres@gmail.com> wrote:
Em qui., 6 de ago. de 2020 às 16:08, Jonathan Wilkes <jancsika@yahoo.com> escreveu:
> On Thursday, August 6, 2020, 2:07:09 PM EDT, matthew brandi <mfbrandi@outlook.com> wrote:
Dear people
In my role as village idiot, I am asking whether the string "fwd" in a message has a
special meaning to inlet.
Naively, I was expecting inlet to pass the string to the subpatch, but it seems not
to. See example patch attached.
AFAICT that's a regression due to the way Pd Vanilla implemented message forwarding for [inlet~ fwd]. That's a feature that allows a signal inlet of a subpatch/abstraction to forward non-signal messages to the right outlet of [inlet~ fwd]. (The right outlet sprouts when the "fwd" argument is present.) Another regression-- there is no longer an error if you try to send a non-signal message to [inlet~]. Another regression-- [inlet~ fwd] unconditionally allocates space on the stack to copy the entire incoming message. If you generate a long enough message this will blow the stack and cause Pd to crash. Esp. important given that Windows stack is much smaller than the RAM available for heap allocation on most machines. Also-- I *think* Pd Vanilla doesn't forward pointer messages through [inlet~ fwd]. It appeared to be an oversight-- at least I didn't see any comment about it.
A GSoC student spent some time reimplementing this in Purr Data, so none of thiese should be issues there.
I think it's a good idea if you're changing and fixing stuff to also send a PR to vanilla as a proposal. Would you consider doing that as well?
Before you ask that, have a look at the PRs. You can view the list of open PRs for Pure Data Vanilla here: https://github.com/pure-data/pure-data/pulls
It appears Christof (Spacechild1) submitted a patch for this almost a month ago. So it wouldn't make sense to send another
PR for this same fix. Christof's patch should work just fine to solve these issues.
If you're asking in general, that's unfortunately just not practical. We'd have to manually create a new patch set and test it for Vanilla, for (nearly) every single change we make. It's much easier to just report here when I find crashers-- Miller and Christof are quite quick to fix them. They know the Vanilla build/test/development process much better than I do so that seems the much preferable route for everyone involved.
Best, Jonathan
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I already made a PR which addresses the issues pointed out by Jonathan: https://github.com/pure-data/pure-data/pull/1112
On 29.08.2020 21:04, Alexandre Torres Porres wrote:
Em qui., 6 de ago. de 2020 às 16:08, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> escreveu:
> On Thursday, August 6, 2020, 2:07:09 PM EDT, matthew brandi <mfbrandi@outlook.com> wrote: > Dear people > In my role as village idiot, I am asking whether the string "fwd" in a message has a special meaning to inlet. > Naively, I was expecting inlet to pass the string to the subpatch, but it seems not to. See example patch attached. AFAICT that's a regression due to the way Pd Vanilla implemented message forwarding for [inlet~ fwd]. That's a feature that allows a signal inlet of a subpatch/abstraction to forward non-signal messages to the right outlet of [inlet~ fwd]. (The right outlet sprouts when the "fwd" argument is present.) Another regression-- there is no longer an error if you try to send a non-signal message to [inlet~]. Another regression-- [inlet~ fwd] unconditionally allocates space on the stack to copy the entire incoming message. If you generate a long enough message this will blow the stack and cause Pd to crash. Esp. important given that Windows stack is much smaller than the RAM available for heap allocation on most machines. Also-- I *think* Pd Vanilla doesn't forward pointer messages through [inlet~ fwd]. It appeared to be an oversight-- at least I didn't see any comment about it. A GSoC student spent some time reimplementing this in Purr Data, so none of thiese should be issues there.I think it's a good idea if you're changing and fixing stuff to also send a PR to vanilla as a proposal. Would you consider doing that as well?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Christof Ressi -
Jonathan Wilkes -
matthew brandi -
Miller Puckette