Ernest

Hi,. this has been going on for a while, so I thought I would ask if anyone else has this problem?

After codebox reaches a certain level of complexity, and upon saving the patch, the gen~ window closes. On reopening it, the gen~ window is entirely empty. Anything in it is wiped.

I can close and reopen the patch to restore it., but now I have to do it every time I save the file. It's just a little inconvenient. I do have to be careful not to edit the gen~ file after the saving patch, or any additional changes are wiped, so it does seem a severe problem, but not not high priority as I know the reason. But I would think other users would find this very annoying if they don't know to watch for it.

I've tried working out exactly what causes it. It may be nested if statements,. or functions within functions in the same statement, or a combination of both.

The only thing I could add now is, nested peek and poke methods in other functions or conditional statements appear particularly problematic, and the compiler also often cannot spot errors in their variables, so it can be helpful to write them, outside the condition statement and do a test compile then move them to the right place.

After codebox reaches a certain level of complexity, and upon saving the patch, the gen~ window closes. On reopening it, the gen~ window is entirely empty. Anything in it is wiped. 

I can close and reopen the patch to restore it., but now I have to do it every time I save the file. It's just a little inconvenient. I do have to be careful not to edit the gen~ file after the saving patch, or any additional changes are wiped, so it does seem a severe problem, but not not high priority as I know the reason. But I would think other users would find this very annoying if they don't know to watch for it.   

I've tried working out exactly what causes it. It may be nested if statements,. or functions within functions in the same statement, or a combination of both. 

The only thing I could add now is, nested peek and poke methods in other functions or conditional statements appear particularly problematic, and the compiler also often cannot spot errors in their variables, so it can be helpful to write them, outside the condition statement and do a test compile then move them to the right place. 

Hi,. this has been going on for a while, so I thought I would ask if anyone else has this problem?
After codebox reaches a certain level of 

max-crashes-with-gen~-and-wipes-gen~-empty-after-saving-file

Well, I found an undeclared variable in a function that started causing the crashing after the code reached 500 lines, but I don't know why it suddenly started causing the crashing.

Also here. Once you reach certain level of complexity it crashes. 

A life saver is to use the title of the gen patch in the gen~ object. 

The other one is to disable auto-compile, and compile only once you saved and are sure you are not losing anything. 

Also here. Once you reach certain level of complexity it crashes. 

A life saver is to use the title of the gen patch in the gen~ object. 
The other one is to disable auto-compile, and compile only once you saved and are sure you are not losing anything. 


A related problem: if a function calls another function, and the subfunction contains History operators, then it can refuse to compile or not work as expected.

Very strange. Thankfully it only crashes gen~, although it typically just causes an unexplained refusal to compile, and sometimes doesn't, in which case the History values bleed up into the calling function, and depending on your code it might even appear to work normally, depending what your'e doing with the variables. And it's only a problem in subfunctions; Technically, t appears the main routine and functions use two separate namespaces for static variables, but the namespace for all statics is shared across all functions. But if you ALSO have undeclared variables in either function that the compiler didn't catch because they were in conditions or loops, it can crash before you get any bizarre error from the first problem.

Advisably, use unique names across the entire namespace for any variables or operators with state, such as history, change(), delta(). Also, counter(), +==(), and accum() functions tend not to work at all in functions, although sometimes they do, and it may be because of the above problem, I'm not sure yet. Also had problems with sah() in functions occasionally in the past, could be because of the new discovery of this above shared namespace bug.

A related problem: if a function calls another function, and the subfunction  contains History operators, then it can refuse to compile or not work as expected. 

Very strange. Thankfully it only crashes gen~, although it typically just causes an unexplained refusal to compile, and sometimes doesn't, in which case the History values bleed up into the calling function, and depending on your code it might even appear to work normally, depending what your'e doing with the variables. And it's only a problem in subfunctions;  Technically, t appears the main routine and functions use two separate namespaces for static variables, but the namespace for all statics is shared across all functions. But if you ALSO  have undeclared variables in either function that the compiler didn't catch because they were in conditions or loops, it can crash before you get any bizarre error from the first problem.  

Advisably, use unique names  across the entire namespace for any variables or operators with state, such as history, change(), delta(). Also, counter(), +==(), and accum() functions tend not to work at all in functions, although sometimes they do, and it may be because of the above problem, I'm not sure yet.  Also had problems with sah() in functions occasionally in the past, could be because of the new discovery of this above shared namespace bug. 

Another problem: History may not work in 3rd-level subfunctions if they are called more than once by a second-level subfunction.. When I get to it, I will put share a bunch of demo patches to illustrate the problems.

Another problem: history values in function calls more than three levels deep s are shared across multiple calls to them from the same function at the third level, even if the History operators have unique names across the entire namespace. It's advisable to keep function calls to three levels deep at most, if they contain any state.

Another problem: history values in  function calls more than three levels deep s are shared across multiple calls to them from the same function at the third level,  even if the History operators have unique names across the entire namespace. It's advisable to keep function calls to three levels deep at most, if they contain any state. 

First, If you declare buffer() or data() in the main routine, then the compiler won't let you use the same names in functions, even if you don't pass the buffer or data into them, or use them in the function. If you try to use the same name in a function, you get a cryptic error message about the variable being a wrong data type, even if it's properly declared as a History variable. It won't tell you the History variable name is unusable in the History declaration, it will tell you it's bad when you try to use the variable in the code. Very confusing.

Second problem: setting more than one variable in one line of code:

is a very useful feature, but it only works in the main routine, and even then, only outside if/then clauses or loops. If you try to set multiple variables in functions, inside conditions, and inside loops, then the compiler just ignores them, without any error message or anything, it says its fine and then just does nothing with them.

Third problem: peeks, pokes, and other such methods can't be performed within arguments to user function calls--but they do work in arguments of native functions. For example, the first of these work, but the second doesn't.

myfunc(in1){
    return in1;
}
Buffer buf ("buf");
out1 = mix(in1, buf.peek(in1), in2);     // works
out1 = myfunc(in1, buf.peek(in1), in2);  //doesn't work

The compiler doesn't catch undeclared variables if in they are in peek methods and similar that are in arguments inside a function, for example:

if (myvar0) out1 = mix(in1, buf.peek(myvar1), myvar2);

Generates a compiler error that myvar0 is undeclared, and most times, for myvar2. However, it doesn't complain myvar1 is undeclared, and works as you might want at first, but eventually causes the inexplicable crash and wipes your gen code as described at the beginning of this thread.

If other people find these problems difficult, I will file some bug reports, but when I've mentioned similar things before, I've been told most people don't try to use gen~ these ways, so it's up to you folks. 

First, If you declare buffer() or data() in the main routine, then the compiler won't let you use the same names in functions, even if you don't pass the buffer or data into them, or use them in the function. If you try to use the same name in a function, you  get a cryptic error message about the variable being a wrong data type, even if it's properly declared as a History variable. It won't tell you the History variable name is unusable in the History declaration, it will tell you it's bad when you try to use the variable in the code. Very confusing. 

is a very useful feature, but it only works in the main routine, and even then, only outside if/then clauses or loops. If you try to set multiple variables in functions, inside conditions, and inside loops, then the compiler just ignores them, without any error message or anything, it says its fine and then just does nothing with them. 

Third problem: peeks, pokes, and other such methods can't be performed within arguments to user function calls--but they do work in arguments of native functions. For example, the first of these work, but the second doesn't. 

The compiler  doesn't catch undeclared variables if in they are in peek methods and similar that are in arguments inside a function, for example:

Buffer buf("buf");
if (myvar0) out1 = mix(in1, buf.peek(myvar1), myvar2);

Generates a compiler error that myvar0 is undeclared, and most times, for myvar2. However, it doesn't complain myvar1 is undeclared, and works as you might want at first, but eventually causes the inexplicable crash and wipes your gen code as described at the beginning of this thread.   

If other people find these problems difficult, I will file some bug reports, but when I've mentioned similar things before, I've been told most people don't try to use gen~ these ways, so it's up to you folks. 


Discovered bizarre oddity. If this is insde a poly~ with 32 instances, it uses ~50% of one cpu core:

Buffer test("test");
out1 = 0;
for(i = 0; i <128; i +=1){
    out1 += test.peek(i, 1);
}

Strangely, if you put the loop inside a conditional test, the cpu usage drops almost to baseline (the output is exactly the same): :

Buffer test("test");
out1 = 0;
Param x;
if(x==0){
    for(i = 0; i <128; i +=1){
    out1 += test.peek(i, 1);
}

The same is true for functions. If the call to the function is in a conditional test, it uses much less CPU. However, you can't just put in a dummy conditional test, like "if(1==1)", I guess it gets compiled away. It has to actually test something, like a param, or it still uses 50% cpu.

Discovered bizarre oddity. If this is insde a poly~ with 32 instances, it uses ~50% of one cpu core: 

Buffer test("test");
out1 = 0;
for(i = 0; i <128; i +=1){
	out1 += test.peek(i, 1);
}

Buffer test("test");
out1 = 0;
Param x;
if(x==0){
	for(i = 0; i <128; i +=1){
	out1 += test.peek(i, 1);
}

The same is true for functions. If the call to the function is in a conditional test, it uses much less CPU. However, you can't just put in a dummy conditional test, like "if(1==1)", I guess it gets compiled away. It has to actually test something, like a param, or it still uses 50% cpu. 

Just tl let you folks know, I'm still recovering from building a Husserl2 standalone, but meanwhile I started sending Cycling74 some simple examples, in fact this one has two syntax errors not caught by the compiler, it compiles as if successfully and outputs 0 instead of 1. 

Screen Shot 2019-09-23 at 9.19.12 PM.png

Just tl let you folks know, I'm still recovering from building a Husserl2 standalone, but meanwhile I started sending Cycling74 some simple examples, in fact this one has two syntax errors not caught by the compiler, it compiles as if successfully  and outputs 0 instead of 1.  


Here's the second example. Changing values of variables in functions with the same name as history variables higher up a call tree chan changes their value. This can even happen with just one function called from the main routine, although it took me a long time to figure out this silly thing, here, the history variable p1 acquires the value of the function value p1 (not vice versa I think). The safe workaround is to ensure every single variable (and buffer, data, etc) has a unique name. bug reported this evening.

Screen Shot 2019-09-23 at 10.26.02 PM.png

The safe workaround is to ensure every single variable (and buffer, data, etc) has a unique name. 

max crashes with gen~ and wipes gen~ empty after saving file