Thank you guys!
My conclusion in this case is to stick with the load script method. It concerns a server process that has been working well for years this way – and never have to be restarted because of memory leaks or performance issues.
It uses the loaded script for a certain task: exporting and delivering files that has been made in Indesign by the main process. Reloading the script just means the property containing the loaded script is redefined, and there is no dependencies other than
the parameters passed to and returned från the script when it is performing its task.
Maybe it would be more by the book to use ”run script” for this task instead. But this script is also used by a client application, and I prefer "load script” since it is then easier to use the event log for debugging.
However, one little drawback with ”load script”, compared to a Script Library, is that I cannot refer to the loaded scripts name and version as stored in its info.plist.
Example:
--- Task.scptd:
on
getVersion()
return {my
name, my
version}
end
getVersion
-- Main.app, using script library
set
theTask to
script "Task"
theTask's
getVersion()
--> {"Task", "1.0"}
-- Main.app, using load method
set
theTask
to load script
scriptPath
theTask's
getVersion()
--> {missing value, missing value}
Any solution to that?
27 jan. 2016 kl. 22:55 skrev Shane Stanley <email@hidden>:
On 28 Jan 2016, at 8:47 AM, has <email@hidden> wrote:
If you make a change to your script libraries, I'm pretty sure you'll have to restart AS-based apps for them to see those changes.
A quick and simple test shows that to be so, as expected, at least in the case of an app that uses a single AS component instance (InDesign in my test), and in practice that probably means pretty much any app. It won't matter for stuff run from the Script menu.
FWIW, I've been doing a heck of a lot of quit-and-relaunch during testing recently. I'm convinced this is what autosaving and state-restoration were really invented for...
--
Shane Stanley <email@hidden>
<www.macosxautomation.com/applescript/apps/>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden
Jörgen Stahle wrote:
To explain my question… "So is there a way to reload a script library immediately after an update of it?"
I want to distribute some applescript code – used by several applescript applications – as a Script Library. This code might be updated every now and then, and I wan’t to use the changes immediately in the referring apps, without any need to restart them.
Without knowing details, it's impossible to give exact advice, but some general thoughts...
If you make a change to your script libraries, I'm pretty sure you'll have to restart AS-based apps for them to see those changes. The AS interpreter doesn't expose the APIs you'd need to reload those libraries in-situ, never mind doing it in a way that is
guaranteed to be safe. Bear in mind that dynamically *re*loading code into an already running process is one of those tasks that looks simple on paper but very rapidly becomes a Non Trivial Problem when you actually try to do it. (e.g. Consider a library that
returns objects which the rest of your code shares: what happens to any extant objects when the code and context that birthed them suddenly vanishes from the process?) You might want to consider if this is something you genuinely require, or if you're just
being unnecessarily clever for the sake of it when a far simpler solution would do. So honestly, if you _can_ solve the problem with a simple app restart, that's what you should do.
If you absolutely must reload certain behaviors on the fly, I'd suggest you use `load script` for those, packaging them as self-contained plugins that live in their own dedicated folder which can be monitored for file updates via e.g. Folder Actions. Alternatively,
you might package those behaviors as separate stay-open applets which your main app launches when it needs to send them commands. You'll need to give some consideration to error tolerance, designing your main code to deal with e.g. the possibility of an applet
being quit in the middle of performing an operation, catching the disconnection error, and trying again. Fault tolerant systems are often built to operate as collections of distributed processes, where an individual process can fail or be restarted without
affecting data integrity or reliability of the system as a whole. But you're talking about significantly increasing code complexity for a problem that's most trivially solved with a quick restart.
If you're concerned about important data being lost because your current app keeps it all in-memory, you might want to consider moving that data into an external store; e.g. OS X includes PostgreSQL, which is extremely robust and well supported (although you'll
need to find an ASOC-friendly framework to talk to it). Or, if your app needs to be constantly listening for incoming AE/HTTP/etc requests from external clients, maybe you want to split that interface into a separate background process that can stay constantly
running and simply puts new requests into a temporary queue while it's waiting for your main process to restart.
Lastly, if you're serious about this stuff, there's no shortage of literature and advice out there (good and bad) on how to build high reliability systems. Cliff notes version: generally the right way to do it is to accept errors and restarts are an _inevitable_
fact of life, and so engineer your system to cope with process failures while still maintaining service uptime and data integrity. And once you've built a system like that, the need to do live *in-process* updates tends to go away by itself anyway.:)
HTH
has
|