# Parser stack overflow



## Nickie Fønshauge (Sep 11, 2006)

:?: :?: :?: 
Why, oh why do I keep getting "Parser stack overflow" error messages in K2's script editor? :cry: I can sometimes narrow the "culprit" down to "1" perfectly legitimate source line. If I remove this (not necessarily the same line each time), everything is fine.

Are 4340 lines of compiled code too many? I find this hard to believe.

Any ideas, please :!:


----------



## kotori (Sep 11, 2006)

Hi Nickie,
I remember seeing this error message once, but I can't remember the context. Could you please send the line where the error is reported along with a couple of lines before and after. Could it be that you have nested too many block statements (like if, select, while) inside each other? :???: 

Cheers,
Nils


----------



## Nickie Fønshauge (Sep 11, 2006)

Hi Nils,

It is not one particular line. If I compile with compression, it is one line, and if I compile without compression it is another line. And when I have narrowed the problem down to 1 line, I can remove any one of various lines, that correct the problem.

Last time I compiled without compression, the error ocurred in


{begin Shift_information}
$info_pointer := ($info_pointer + 1) mod $info_length
@_info_line := ""
$_i := $info_pointer
while ($_i <= ($info_length - 1))
* @_info_line := @_info_line & !info[$_i]*
inc($_i)
end while
$_i := 0
while ($_i <= ($info_pointer - 1))
@_info_line := @_info_line & !info[$_i]
inc($_i)
end while
set_text($information,@_info_line)
{end Shift_information}

at the boldfaced line. This is the "on init" block. There are no surrounding blocks except "on init".

The source code reads:

*function* Shift_information
``````*declare* global info_pointer
``````*declare* @info_line
``````*declare* i
``````info_pointer := (info_pointer + 1) mod info_length
``````@info_line := ""
``````*for* i := info_pointer *to* (info_length - 1)
````````@info_line := @info_line & !info_
``````*end for*
``````*for* i := 0 *to* (info_pointer - 1)
````````@info_line := @info_line & !info
``````*end for*
``````set_text(information,@info_line)
````*end function*_


----------



## Dynamitec (Sep 11, 2006)

Hi Nickie, 

i got this error once too. 

There are some problems in KSP:

- the on init callback may only have limited number of lines (don't know the number anymore, around 1000 i think)
- if you have too much UI Elements or too much variables this error may occure too. I got this once i had more than 80 UI Elements.

But: i wasn't sure if this problem was there due to the number of variables or the number of lines in the on init callback! (Or both: more variables => more declares in "on init")

What can you do? Try to minimize lines in on init callback, try to declare NO local variables (since they have to be declared all in "on init"). Try to use for example i,j,k for every loop you use, etc...



> function Shift_information
> ``````declare global info_pointer
> ``````declare @info_line
> ``````declare i



See what i mean? You declare i in this function. If you have 10 functions you'll ad 10 lines of code to your "on init" callback. If you have 3 local loop counter variables in each function you add 30 lines to on init. I know code gets better readable if you do those local declares. It's a pitty those limitations of KSP make a lot of Nil's work almost useless in big projects :(

This was one of the most anoying error messages i got. Because i had to rewrite a lot. But after all: now i try to keep the size of the "on init" callback as small as possible.

Somewhere there should be a thread were i already posted this (i think it was in the "welcome back big bob" thread.

I hope i could help a little bit.


----------



## Dynamitec (Sep 11, 2006)

BTW: Could you please send the number of lines in your "on init" callback and the number of variables you use? Because if you do, i can say for sure if this is your problem.

What i really hate about NI and KSP: they had set some limits and nobody knows these limits! How many variables may be declared? How many ui elements? How many callbacks? How many lines per callback? It's really anonying!


----------



## Nickie Fønshauge (Sep 11, 2006)

Hi Benjamin,

I have the nasty feeling, you are right. If you are, it is really bad news.  There are 1485 "on init" lines in the uncompressed compiled code and 1130 in the compressed, and 384 variables. I'll try and reduce the size of "on init". Thank you for your help, both of you. :smile:


----------



## kotori (Sep 11, 2006)

I think I found the problem :smile:. It seems that the number of top-level statements (or statements at the same level) is restricted to about 995. However, you can work around this by introducing some artificial nesting. Eg. change this:


```
line1
line2
...
line1500
```
_into:_

```
if (1=1)
  line1
  line2
  ...
  line750
end if
if (1=1)
  line751
  line752
  ...
  line 1500
end if
```

Cheers,
Nils


----------



## Nickie Fønshauge (Sep 11, 2006)

kotori @ 11th September 2006 said:


> I think I found the problem :smile:. It seems that the number of top-level statements (or statements at the same level) is restricted to about 995. However, you can work around this by introducing some artificial nesting. Eg. change this:
> 
> 
> ```
> ...



I'll try your solution. Thanks!

Right now I am struggling with a (declared!) variable, which Kontakt claims is *not* declared. Yeah, right! :evil:


----------



## kotori (Sep 11, 2006)

Nickie Fønshauge @ Mon Sep 11 said:


> Right now I am struggling with a (declared!) variable, which Kontakt claims is *not* declared. Yeah, right! :evil:


You might want to watch out for empty if-statements (commented out code counts as empty) and assigning to builtin variables. I think there are some bugs related to these. Good luck!


----------



## Nickie Fønshauge (Sep 11, 2006)

kotori @ 11th September 2006 said:


> You might want to watch out for empty if-statements (commented out code counts as empty) and assigning to builtin variables. I think there are some bugs related to these. Good luck!


Thanks. 

In this case it is the variable carrying the value of a "set_controller" statement. The statement has been parsed successfully before, so obviously the problem is somewhere else, possibly far away from the error line. :roll:


----------



## Thonex (Sep 11, 2006)

Wow Nickie... over 1000 lines for an init... what are you working on?

Cheers,

T


----------



## Nickie Fønshauge (Sep 11, 2006)

Thonex @ 11th September 2006 said:


> Wow Nickie... over 1000 lines for an init... what are you working on?
> 
> Cheers,
> 
> T


Version 2 of the G Strings script for the Garritan Solo Strings. I am improving the GUI and adding some new features. It keeps growing and growing and... Apparently I can't stop getting ideas for new features :lol:


----------



## Nickie Fønshauge (Sep 11, 2006)

Well, I finally got rid of the "parser stack overflow" messages. Oddly enough with the same variables and almost the same number of compressed "on init" lines (1112 against the 1130, that caused trouble). I just basically shuffled everything around.


----------



## Thonex (Sep 11, 2006)

Nickie Fønshauge @ Mon Sep 11 said:


> Well, I finally got rid of the "parser stack overflow" messages. Oddly enough with the same variables and almost the same number of compressed "on init" lines (1112 against the 1130, that caused trouble). I just basically shuffled everything around.



Heh... the ol' software equivalent to kicking it :lol:


----------



## Nickie Fønshauge (Sep 11, 2006)

Thonex @ 12th September 2006 said:


> Heh... the ol' software equivalent to kicking it :lol:


Yeah, something like that - if only it was as easy as kicking :smile: The kicking took me the better part of a day - "The long Kick Goodnight"! :wink:


----------



## Dynamitec (Sep 12, 2006)

Hi Nickie, i'm glad to hear that you've managed it...and: thanks Nils for figuring out what exactly is the problem. Amazing KSP  It's good to know the limits to get around them.


----------



## Nickie Fønshauge (Sep 12, 2006)

Dynamitec @ 12th September 2006 said:


> thanks Nils for figuring out what exactly is the problem. Amazing KSP  It's good to know the limits to get around them.


Yes, indeed. It would be a time saver, if the limits were better documented.


----------



## kotori (Sep 12, 2006)

Nickie Fønshauge @ Mon Sep 11 said:


> Right now I am struggling with a (declared!) variable, which Kontakt claims is *not* declared. Yeah, right! :evil:


Another cause of this problem might be initializing variables to non-constant values. It seems that Kontakt doesn't always report this problem, and in some cases it causes declared variables to be considered undeclared. Please split declarations and assignments to two different rows, eg:
_declare $x := find_group("test")_
change into:
_declare $x
$x := find_group("test")_


----------



## Nickie Fønshauge (Sep 12, 2006)

kotori @ 12th September 2006 said:


> Another cause of this problem might be initializing variables to non-constant values. It seems that Kontakt doesn't always report this problem, and in some cases it causes declared variables to be considered undeclared. Please split declarations and assignments to two different rows, eg:
> _declare $x := find_group("test")_
> change into:
> _declare $x
> $x := find_group("test")_



Yes, I did figure this out eventually - after I had spent a lot of time moving assignments to declaration lines in order to reduce the number of lines :wink: :roll: But thanks anyway :smile:


----------



## Nickie Fønshauge (Sep 12, 2006)

Nils, I just tried your artificial nesting idea, but, alas, it doesn't seem to work - back at square one :cry:


----------



## Dynamitec (Sep 12, 2006)

Maybe in the end it's the number of variables problem :( ...this is strange. Did you try to minimize variables? Or ui elements?


----------



## Nickie Fønshauge (Sep 12, 2006)

Dynamitec @ 12th September 2006 said:


> Did you try to minimize variables? Or ui elements?


No, not yet. I did at first get rid of the error message without deleting variables, just by rearranging the "on init" block. I thought I could use Nils' suggestion, if I ran into trouble again. Apparently I balance on the edge of what Kontakt's Script Processor can handle. I'll have to try and use second hand variables now, like you suggested. It is not an ideal solution, though. I hope NI is going to address this issue in their next update.


----------



## kotori (Sep 12, 2006)

Hi Nickie,
If you want please feel free to send me (attach to a forum post or PM) the script and I'll have a look at it. I tested the articifical nesting workaround so I know it's helpful in some situations, although apparently not in all it seems.

Cheers,
Nils


----------



## Nickie Fønshauge (Sep 12, 2006)

kotori @ 12th September 2006 said:


> Hi Nickie,
> If you want please feel free to send me (attach to a forum post or PM) the script and I'll have a look at it. I tested the articifical nesting workaround so I know it's helpful in some situations, although apparently not in all it seems.
> 
> Cheers,
> Nils



Thanks Nils,

Right now I am below the magic line (in the green zone). I had added a label and a few add-text-line's for debugging purposes - that was all it took to cross the thin red line. But I do have more features in store, so a more permanent solution would be very much appreciated. I'll PM it to you. I hope you can figure something out. I need it to work yesterday.


----------



## kotori (Sep 12, 2006)

Nickie Fønshauge @ Tue Sep 12 said:


> I hope you can figure something out. I need it to work yesterday.


Hmm - maybe if I change the time zone of my forum profile... :razz: 
Anyway, I sent a reply to your PM. In case anyone else is curious it seems that using multiple dummy-if statements works (in this case much less than 995 lines was acceptable).


----------



## Dynamitec (Sep 12, 2006)

> I hope NI is going to address this issue in their next update.



I really like to see some optimistic people around here...sorry, for my sarcasm...
Yeah, Nickie, i really like to see this fixed too. Because this limits can drive one crazy. Remember the time i posted much about my guitar library. I almost had finished one version and than i runned into serious trobule with exactly the same problems you have now. Since there was still some stuff to do and i couldn't write code anymore because of this stack overflow error, i had to rewrite it from scratch.
Ok, now it's much better and clearer than i every thought it could get (thanks to Nils with his new import statments) but i lost 2 month...

That's why i now write smaller scripts that are connected with each other. I need more script slots but t i don't get those problem you're having now and the large script slow down in the current version of kontakt doesn't appear, too.

It's strange: one script with 6000 lines slows kontakt down like hell. But three 2000 lines scripts are runnning smooth.


----------



## Nickie Fønshauge (Sep 12, 2006)

Yes Benjamin,

I am afraid I will have to follow your route.

I have started work on a successor to this script, but in light of the current problems, I guess I have to redesign it completely. I was only going to make some minor adjustments/bug fixes to the current version, so I can use it with the Garritan Gofriller Solo cello, which I have recieved a beta version of for testing and demo production. That is why I need the script yesterday. I really don't have time for this circus.

I am glad to hear everything eventually turned out well for you. 

To follow up on Nils's last post, in case anybody is interested, I tried his suggestion, and K2 did parse the script successfully. So, the cure worked. Unfortunately the patient died - when I tried to close K2's script editor, Kontakt crashed 3 out of 3 times.


----------



## kotori (Oct 13, 2006)

Hi Nickie,
Thanks for the suggestion but I wonder if it wouldn't hurt readability and increase the line count too much (causing trouble with the slow K2 editor). I'll consider allowing families inside any blocks in the next update.

Glad that the problem was solvable. :smile: One always get a little nervious when one runs into one of these arbitrary limitations.

Cheers,
Nils


----------



## Nickie Fønshauge (Oct 13, 2006)

kotori @ 13th October 2006 said:


> I wonder if it wouldn't hurt readability and increase the line count too much (causing trouble with the slow K2 editor).


Hi Nils,

which readability do you have in mind? Surely not the compacted code!? :shock:  

I counted the number of families in the biggest of my scripts: 217 families would add 434 lines to a script with close to 6500 compiled and compacted lines. I could live with that; it wouldn't make any significant difference - the K2 editor is slow anyway.



kotori @ 13th October 2006 said:


> Glad that the problem was solvable. One always get a little nervious when one runs into one of these arbitrary limitations.



You bet I was nervous, until I knew for sure your workaround would work.


----------

