"Selector table too big" error

Questions
1

hello list

i’m getting the error below trying to run a very simple sequence of statements in a file.

ERROR: Selector table too big: too many classes, method selectors or function definitions in this function. Simplify the function.

for instance the text you get by running:

256.do({ arg i; “{%.postln}.value;”.format(i).postln; })

can’t be executed as “sclang text.scd”

is there a way around this, short of splitting up the input file?

thanks in advance
rd

2

One could say, if the function has so many functions within it, then it’s no longer a “very simple sequence.”

You could break it up like this, though:

{
    {
        { 0.postln }.value;
        { 1.postln }.value;
        ...
        { 199.postln }.value;
    }.value;

    {
        { 200.postln }.value;
        { 201.postln }.value;
        ...
        { 399.postln }.value;
    }.value;

    ... etc
}.value;

Only elements directly within a block contribute to the selector count, not elements within sub-blocks. So, if you stop at 399 there, the outermost block would have two functions and the symbol value as selectors, and the two inner blocks would both have 200 functions and the symbol value, and no single block would overflow the limit.

McCartney didn’t support arbitrarily large functions because large functions are not normally a good programming practice (though there are exceptional cases such as the auto-generated code here).

hjh

3

hmmm, except the file doesn’t define a function, it’s just a list of statements.

{ defineSomething; }.doSomething;
{ defineSomethingElse; }.doSomethingElse;
...

perhaps sclang puts it in a function implicitly?

at the moment i’m writing the file in pieces, and running sclang at each step.

this works but it seems a bit odd.

is there a nicer way?

thanks again,
rd

4

Yes. Sclang has no facility to evaluate any interactively-submitted code without putting it in a function.

Or, another way to say it is, the byte code interpreter needs some sort of function definition as a context. (What about class library methods? Method is a subclass of FunctionDef.) There is no way for the interpreter to do anything outside of a function-def context. So, for interactive evaluation, the compiler does produce a Function object, which is then evaluated.

"1+1".compile;

-> a Function

AFAIK the nicer way is to split them up into sub-functions. In theory you should be able to go arbitrarily large. Even if each sub-function is limited to 100 member functions, it should be possible to nest as deeply as needed. Because every sub-level has access to every parent scope, you could even declare variables at the top of the outermost level, and every nested function would have access to them.

Alternately… is it really necessary to structure the generated code in terms of a large number of separate functions?

hjh

5

ah, interesting, thanks for details!

and yes in this case there really are just lots of functions to evaluate, but splitting is fine.

thanks again,
rd