Bizarre GenExpr codebox error

Quince de l'Argent

I recently (as of the day of posting this) am getting an error that has seemingly rendered the gen codebox basically useless. It seems gen can no longer run a codebox's code if I at all use any explicit reference to inputs (in, in1, in2, etc...), which basically means I can no longer use codeboxes at all that deal with any signal inputs . I should also note that I obtain this error both in the gen.codebox~ object outside of the gen environment, as well as with codeboxes within a dedicated gen~ subpatch. There's more to this error that I will get into, but first here's some simple example code I've written:

some_function(x) {

return 0; // return 0 for simplicity

}

out1 = some_function(in1); // apply the function directly to explicitly stated input will give error

x = in1;

out2 = some_function(x); // also gives error when using a transitive variable as the input

So the above code would have in all of my previous work in gen, and to my current understanding, be syntactically correct and compilable. In fact, when I write this code, and allow it to compile in real-time it appears that there is no error initially. It is only when I connect actual signal sources to the input(s) of the gen codebox (if this is a gen.codebox~ object in the top-level max/msp environment) or to a gen~ object containing this codebox that produces this following error in the max console:

gen~: 2692:28:use of undeclared identifier 'in1'
gen~: failed to compile patcher

Which I'm very perplexed by considering "in", "in1", etc... have always referred to a codebox's inputs. As you can imagine, this is quite frustrating considering the majority of my work in gen involves the use of the codebox, and this has rendered basically all of my max patches and max4live objects that use gen codeboxes to be unusable, so any insight into this issue would be greatly appreciated!

Graham Wakefield

Hmm, yes it looks like you found a rare bug! However from my testing, this isn't actually linked to in1 etc., it is about the function definition. I narrowed it down to this:

fun(x) {
    return 1;
}
out1 = fun(in1);

But interestingly, this works fine, no errors, and the input passes through fine:

fun(x) {
    return x;
}
out1 = fun(in1);

And this also works, where the input is not used at all:

fun() {
    return 1;
}
out1 = fun(in1);

So somehow, it seems like it doesn't like it when a function argument is not used in the function body.

From looking at the code generation output I believe this may have been caused by an over-aggressive "dead code elimination" pass in the gen~ compiler. There's some work being done recently to streamline some of the gen~ compiler passes and these have ironed out a couple of similar issues, so it is possible that this has already been fixed for the next update.

In the meantime, it seems that so long as you do use the argument in the function body the error should go away :-)

Graham