Re: [PD] Inlet - Unexpected Behaviour

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