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@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"