[PD] Inlet - Unexpected Behaviour

[Christof Ressi]

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 at gmail.com> wrote:
>
>
> Em qui., 6 de ago. de 2020 às 16:08, Jonathan Wilkes 
> <jancsika at yahoo.com <mailto:jancsika at yahoo.com>> escreveu:
>
>     > On Thursday, August 6, 2020, 2:07:09 PM EDT, matthew brandi
>     <mfbrandi at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200829/eec83933/attachment-0001.html>