Fire and forget scripts
  • Is it currently possible (or can it be a request) to have time consuming scripts be started by FastScripts but not restrict one from starting another script. It seems that with the messaging and also using growl or other system notices, there is not a need to tie up fastscript for notice that a task is finished...
  • Thanks for asking - the feature is definitely "on the drawing board" and has been gradually gathering momentum for quite a while now. The fundamental complication is that it's very difficult to run multiple scripts at the same time from a single application. In fact, even applications like Script Editor that do it exhibit clunky behavior and slow responsiveness while doing so. Applications that appear to run multiple scripts simultaneously are usually running smaller "script runner" programs to do the execution invisibly to the user. Up until now, I've emphasized running scripts from the main FastScripts application, because it has always been a priority to run as quickly as possible, and I didn't want to risk slowing things down by launching a separate process for each script.

    I've been thinking of switching to a mechanism by which a number of "script runners" could be running at any time. There would only be one most of the time, but if you happened to try running another script while the main one was busy, another could be launched. I think this might be a good compromise between the performance of running instantly from the FastScripts process, and the flexibility of having separate processes for each script. This infrastructure would pave the way not only for running multiple scripts, but also for improving the user experience, for instance, when a buggy script hangs forever (and requires the user to force-quit FastScripts).

    As a short-term workaround, I suggest saving those time-consuming scripts as "script applications." This will cause them to open a bit slower but as they are independent applications, they will be left by FastScripts to finish on their own. For the longer term, know that I am definitely considering all of my options and hope to improve this behavior in a future release of FastScripts!

    Thanks again for stopping by...

    Daniel
  • I'd like to second this and encourage it. I run several complex scripts first thing in the morning, several of which post notices and they get bogged down waiting for the applications to respond. I don't care who responds first, I'd like to get them all up as fast as possible.
  • Thanks for the vote, Nova... it's not the only thing that drives implementation priority, but it sure helps!
  • The "save as application" workaround does not allow multiple instances of the same script to run in parallel. I'd vote for child processes, too.
  • Yeah I've run into that shortcoming a few times, myself. I think at least running child processes would make a good option.
  • I would like to have this too.

    I don't usually need to run *same* script simultaneously.

    I cant use "save as application" for all my scripts.
  • Is "fire and forget" feature in latest version of FastScripts? I really need this feature. Thanks
  • gabriella - sorry, it's still not implemented. Does saving the script as an application help as a workaround in the mean time?
  • I can save few scripts as apps, but most of my scripts need to be script documents. Thanks
  • Understood. Sorry I can't offer a better solution at the moment. It might be necessary to use Apple's script menu, or another launcher, to get the fire-and-forget behavior.
  • Hmm... maybe getting the Unix subsystem to do it? Just a random thought.
  • What if FastScripts has queue? When user tries to launch second item when FastScripts is still running first one, FastScripts puts second item to queue and runs it after first one.

    This is better than nothing and is propably easier to program.

    "Hmm... maybe getting the Unix subsystem to do it? Just a random thought."

    What this means? Can i do it somehow?
  • A queue might be a good idea, but then again, if the first scripts takes a long time to finish, what if the conditions that exist when the second script finally fires are no longer desirable? It's a bit tricky when doing anything other than simply firing the script right when the user wants it.

    I'm not sure exactly what Boodlums is alluding to.
Start a New Discussion

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!