[Pd] Stack Overflow

[Chuckk Hubbard]

I solved this problem in a far simpler way than I foresaw.
I included in the patch two experiments I used to understand the
[delay] object.  In the lower one, if you disconnect the delay and
make the connections directly to their destinations, there are stack
overflows.  This version of JInext works with no catches in all of its
roles.

-Chuckk

On 3/26/06, Frank Barknecht <fbar at footils.org> wrote:
> Hallo,
> Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
>
> > This still doesn't make sense to me.  Anything coming from the
> > second outlet of the pointer should be discarded, and the until
> > ought to keep moving the pointer forward until something comes from
> > either the first or third outlet.  If the 2nd outlet stopped the
> > [until], there would be no point having the patch, and if it is
> > connected to a [next( message, as it was before, it could lead to a
> > stack overflow, as message after message triggers that outlet when
> > searching for a single tempo marker among hundreds of notes.
>
> Ah, yes, of course you're right here, I somehow did get this wrong,
> bad coffee for breakfast. :(
>
> I'll try again - this is from your previous mail:
>
> > But I don't understand why the attached patch doesn't work.  Using
> > my recursive patch, I get no "empty pointer" errors, no matter what
> > I do in the program, from the abstraction.  However, this [until]
> > version freezes my system, and the only way that would seem to be
> > possible is if a "next" message were sent without a "bang" message
> > having been sent first.
>
> If you send a "next" before you send a "bang" to "JInextB", you get a
> stack overflow. But you *also* get a stack overflow, if you send a
> "next" *after* you have reached the end of the structures list.
>
> You get this because there is nothing stopping the until: Instead of a
> pointer out of the first or a bang out of the End_Of_List outlet of
> the pointer object, you just get a console messages saying:
>
> error: ptrobj_next: no current pointer
>
> You can check this yourself if you replace the [until] with a [bang]
> message and press [next( manually until you reach the end of the list,
> then press [next( again. There will be no output to any of the two
> outlets of [JInextB], so there will be nothing to stop the [until]
> (which thankfully only is a [bang] now).
>
> The patch I posted earlier does fix this, as it's not the incoming
> message, that starts the [until] loop, but anything, that is:
>
> a) not a wanted pointer of type $1 and
> b) not the end of the list.
>
> And this thing, that is "not a and not b", is a pointer from the
> second (middle) outlet.
>
> Ciao
> --
>  Frank Barknecht                 _ ______footils.org_ __goto10.org__
>


--
"It is not when truth is dirty, but when it is shallow, that the lover
of knowledge is reluctant to step into its waters."
-Friedrich Nietzsche, "Thus Spoke Zarathustra"