Page 2 of 2 FirstFirst 1 2
Results 11 to 20 of 20

Thread: Calling function upon interruption of ASH script

  1. #11
    Developer
    Join Date
    Aug 2009
    Posts
    2,794

    Default

    That is, if you're running in a headless environment, can't you just use a virtual framebuffer, and the dialog box will just be silently generated and closed? I don't see any problem with that.

  2. #12
    Developer Veracity's Avatar
    Join Date
    Mar 2006
    Location
    The Unseelie Court
    Posts
    11,386

    Default

    When you execute script A for the first time, ASH parses it (including all of its imports) into a parse tree which is stored in an interpreter associated with that script. That is cached with the "last modified date". Every time you want to execute script A, ASH checks the modified date and, if it is unchanged, uses the cached version. If it has changed, it re-parses and re-caches.

    Imported files are inserted into the code of script A at the time of import and are therefore parsed only when script A is parsed. If you modify them after script A is parsed and cached, script A does not see that. Script A will pick them up again next time it is parsed, but that won't happen until script A is modified or you restart KoLmafia.

    We could save a dependency tree for a script, saving the modification dates of the script and its (recursive) dependencies, and reparse/recache if the script or any of its dependencies change, but we don't do that. That would be a reasonable feature request: clear cached scripts when the script or any of its dependencies change. It would not allow you change a library file while a script using it is currently running and have the new version picked up; although ASH "interprets" scripts, it compiles them into a parse tree and interprets that, rather than interpreting the raw text.

  3. #13
    Senior Member
    Join Date
    Apr 2018
    Posts
    129

    Default

    Maybe I should move this to a feature request.

    I want my program to run specific code if I want to interrupt it. I want to be able to interrupt it in a headless environment, so anything that relies on a GUI is useless. If I could type input into the CLI during operation to accomplish that, that would be fine.

    If the abort or exit commands lead to code in the Ďfinallyí section of a try-finally control structure being run, that will also work.

    Iíve had issues with those in a headless environment before, but thatís outside the scope of this thread. Iíll open a bug report once I have the time to make sure it is, in fact, a bug.

  4. #14
    Senior Member
    Join Date
    Apr 2018
    Posts
    129

    Default

    Huh. So you cache scripts within a KoLmafia session, updating them based on the filesystemís modification times, and have a linker collate imported files from that cache at execution time? Interesting.

  5. #15
    Senior Member
    Join Date
    Jun 2016
    Posts
    219

    Default

    Maybe I should move this to a feature request.

    I want my program to run specific code if I want to interrupt it. I want to be able to interrupt it in a headless environment, so anything that relies on a GUI is useless. If I could type input into the CLI during operation to accomplish that, that would be fine.
    Originally Posted by Saklad5 View Post
    Typing 'abort' in the cli works for me.

    If the abort or exit commands lead to code in the ‘finally’ section of a try-finally control structure being run, that will also work.
    Originally Posted by Saklad5 View Post
    If you're in a try block when you give the above 'abort', the finally block (and anything after it) should be executed. That said, I don't know of a specific way to detect that an abort happens: if you successfully make it through the try block, it would also execute the finally block. Though you could of course code the try block in such a way that that can't unless an abort happened.
    Alternately, you could do what cc_ascend does, where you use the relay script to set a safely abort property (in the cli, that would be: 'set stop_this_now = true'), which gets checked by the script at convenient points. ( get_property("stop_this_now").to_boolean() )
    Last edited by the dictator; 07-11-2018 at 03:44 PM.

  6. #16
    Senior Member
    Join Date
    Oct 2014
    Posts
    166

    Default

    cc_ascend checks a preference for graceful abort. The preference can be set via a relay script while cc_ascend is running.

    The Dictator ninjaed me by 6 hours. But yeah, he explained what I do.
    Last edited by cheesecookie; 07-11-2018 at 10:03 PM. Reason: Derp.

  7. #17
    Senior Member
    Join Date
    Apr 2009
    Posts
    1,807

    Default

    That said, I don't know of a specific way to detect that an abort happens: if you successfully make it through the try block, it would also execute the finally block.
    Originally Posted by the dictator View Post
    Possibly something to the effect of
    Code:
    boolean aborted = true;
    try {
      ...
      aborted = false;
    } finally {
     if (aborted) {
       ...
     }
    }
    ?

    (unless you also return from inside the try {} block; any non-abort way of leaving the block would need its own aborted=false)

  8. #18
    Developer
    Join Date
    Aug 2009
    Posts
    2,794

    Default

    I thought finally blocks execute even if you return from the function (even in other more general-purpose languages).

    Finally blocks are weird.

  9. #19
    Developer Veracity's Avatar
    Join Date
    Mar 2006
    Location
    The Unseelie Court
    Posts
    11,386

    Default

    Finally blocks execute no matter how you exit from the try block.

  10. #20
    Senior Member
    Join Date
    Apr 2018
    Posts
    129

    Default

    I’ve established that the “abort” CLI command does not work correctly in headless mode (that is, it only skips the queue of existing commands when entered through the gCLI).

    Thanks to the advice in this thread, I’ve added a workaround for even that. I wrapped everything in a try block, then added the following behavior to the start of one of the main loops of the program:
    1. Read map from file
    2. If map has value of “true” at specific index, change it to false, overwrite the file with the updated map, then abort


    This seems to work quite well. It’s rather sloppy, of course, but it is much better than my previous approach of sending SIGTERM, cleaning up everything manually, and restarting KoLmafia.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •