CurseForge.com

Ovale Spell Priority

181 - New parser for Ovale scripts

The current parser in OvaleCompile.lua is using a string.gsub() technique to implement a script grammar, but there are problems with this approach:

  • It constantly creates new Lua strings which causes a lot of overhead.
  • It takes an indeterminate number of passes over the code text to parse and generate an AST.
  • It's slow: all reports of the "script ran too long" error have been from the Compile() method; it needs to execute within 200ms at most.

The parser should be rewritten as an LR parser that can parse the code in a single pass.

User When Change
jlam Mar 14, 2013 at 14:41 UTC Changed type from Defect to Enhancement
jlam Jan 24, 2013 at 20:13 UTC Changed type from Enhancement to Defect

Changed priority from Low to Medium
jlam Oct 25, 2012 at 21:30 UTC Changed priority from High to Low
jlam Oct 12, 2012 at 21:41 UTC Changed status from Accepted to Started
jlam Oct 12, 2012 at 21:40 UTC Create

You must login to post a comment. Don't have an account? Register to get one!

  • 3 comments
  • Avatar of jlam jlam Jan 24, 2013 at 20:14 UTC - 0 likes

    Raising this to a higher priority as current MoP users are apparently running into this problem again.

  • Avatar of jlam jlam Oct 25, 2012 at 21:33 UTC - 0 likes

    Dropping this ticket to low priority for now. Speed-ups have been achieved in an alternative way i the existing compile code by splitting the compilation into phases and avoiding a full compilation unless absolutely needed.

    I will revisit this project at a later time.

  • Avatar of jlam jlam Oct 15, 2012 at 03:00 UTC - 0 likes

    Blue post regarding Lua execution time:

    Limited lua execution time - In order to keep the game client running smoothly, the lua runtime will break if it is executing a single lua call for too long. This also applies to macros, and will mark the macro as disabled until you reload the UI. Currently this only applies in combat (example: Taint is active).

    This comment from Cyberolas in AceEvent ticket #296 has a suggested maximum execution time to avoid running into this error:

    In my own testing with debugprofilestop(), the execution cap is around 200ms, but errors can start to happen around 185ms, so 150ms should be a safe enough limit.

  • 3 comments

Facts

Last updated
Mar 14, 2013
Reported
Oct 12, 2012
Status
Started - Work on this issue has begun.
Type
Enhancement - A change which is intended to better the project in some way
Priority
Medium - Normal priority.
Votes
0

Reported by

Possible assignees