Parse Errors *&@#$

Feedback
qam1
2012-08-29
2013-02-06
<< < 1 2 (Page 2 of 2)
  • Rich Schottler
    Rich Schottler
    2013-02-06

    Alex - thanks, I'll take a look, but I suspect you're right - it's probably a bad interaction between Win7 64 and Qt.

    qam1 - you're workaround is good, but you might want to verify that the current time rate doesn't adversely affect your while loop - the docs don't say whether getJDay() is time rate dependent, but if it is (testing would tell), a zero or negative time rate will cause your while loop to never exit.

    Also, as a scripter myself, thanks for the info on the error line number change. :)

     
  • Rich Schottler
    Rich Schottler
    2013-02-06

    Alex,

    Well, still not sure if it's a problem with Win7 64 specifically, or the 64-bit compile of Stel, but the problem can be traced back to scripts running VERY slowly on Win7 64. I took the wait code from StelScriptMgr.cpp and put it directly into a test script:

    function rwswait(sleepDurationSec) {
        if (sleepDurationSec<0) return;
        var date = new Date();
        var curDate = null;
        do {
            curDate = new Date();
    core.debug("curDate="+curDate.getTime());
        }
        while(curDate-date < sleepDurationSec*1000/scriptRateReadOnly);
    }
    
    scriptRateReadOnly = core.getScriptRate();
    
    a = new Date();
    rwswait(.1);
    b = new Date();
    core.debug("diff="+(b-a));
    

    It turns out the do loop only cycles very slowly. Sometimes every 300-400 milliseconds, sometimes only once per 1000 or more milliseconds. This execution rate is what makes the win7 64 scripts terribly slow.

    So, some guesses:

    • Maybe win7 64 has a different threading priority model than 32-bit, and the script thread needs to get more CPU cycles to work "normally".

    • Maybe some other Stel thread is taking too much priority and starving the script thread.

    • Maybe the compile/build method for win7 64 introduces some performance penalties.

    I'm kinda out of my element at this point. Got any other guesses?

    One other issue I noticed on win7 64 is that the core.debug() function erases the script console output each time it is called - makes it kind of hard to see all the debug info. By the time a script exits, the only debug info in the console is the last call to core.debug(). Maybe another gotcha of the different compile?

    Don't know if any of that will give you a clue to what is wrong, but I'm past my usefulness. Good luck!

     
  • qam1
    qam1
    2013-02-06

    Oops, wrote the Parse errors out wrong

    It's 2x now and not ½ (it's a ¼ of previous versions)

    Using the example above where there error is in line 4945

    In version 0.12

    In the log file the error will output as

    "script error: "SyntaxError: Parse error" @ line 2473"

    So it's (2473*2)-1 = 4945

    In previous 0.10 & 0.11 versions

    In the log file the error will output as

    "script error: "SyntaxError: Parse error" @ line 9889"

    So it's (9889+1)/2 = 4945

     
<< < 1 2 (Page 2 of 2)


Anonymous


Cancel   Add attachments