Mark wrote:Hmm, run each cam command in its own thread. I'll have to look into that. I took a peek at your link for that, Jay, a bit beyond my Python skills at this point, but I'll study some more. I think I ran into that, or something similar, when I was searching for the timeout solution, as others have had similar issues trying to speed up Python requests.get calls. I read things like "multiprocessing.dummy.Pool" and "pool.apply_async(requests.get, [params])" but stumbled on exactly how to implement those in my case (if those even apply to my case!).
Yeah, it's definitely not a beginner topic. I'll see if I can cook up an example.
Mark wrote:Matt, you mentioned that Python scripts run parallel to other Indigo Server processing. Does that mean I could turn on a light even while my long-winded embedded python script was running? If so, then why the 10 second limit (and error) for python script execution?
The Indigo Server is threaded - that is, when possible, it does things as much as it can in parallel. Embedded scripts run in their own shared process, so every time the server needs to run one it just adds it to a queue that the shared process uses to execute scripts (one at a time). However, the server's other processes continue to run in parallel. So, the answer is yes, lights should continue to turn on and off, schedules run, etc. The only thing that's serial are any embedded scripts, which run one at a time in their own process and thus have the 10 second limitation. Why not just run them all in their own process? Because starting up a script execution process takes more time and a few more resources on your Mac. And, in fact, that's exactly what executing from a file does.
Anyway, it's working well enough for now. So I'll revisit this later.
Mark wrote:By the way, it was a pleasant surprise that my .py files find each other (for importing) without any special installation, as long as they're in the same directory. And that they can find Indigo (to be able to import "indigo"), too (for logging). Is that because they're in the attachments folder? Or would a py script be able execute, and be able to import "indigo", no matter where it was located?
Python interpreters have something called a path, on which they search for modules that are imported. The first place they look is where the directory where the current script is running, so any other files in the same directory will be found automatically. Indigo uses a special wrapper environment, called the IndigoPluginHost, which runs all Indigo script. One of it's jobs is to add to the PYTHONPATH such that anything in the /Scripts/Attachments folder in the Indigo installation directory is on python's search path. Another thing IPH does is automatically add the indigo module so it's always available for you without an explicit import.
Mark wrote:So many questions... when I modify a py script, what is the proper way to reintroduce it to Indigo? I can see that something compiles my script (creates a .pyc version). after it first executes. Is Indigo doing that, or the OS's python interpreter? Also, I was using the "Reload Libraries and Attachments" menu command after each edit, but when looking at the log, I'm not convinced that is doing anything for python attachments. So how best to "tell" Indigo I've modified a py attachment?
The python interpreter automatically creates a bytecode file (.pyc) from your script source whenever the script is run IF there is no .pyc file or if your .py file is newer. Reload Libraries and Attachments basically shuts down the IndigoPluginHost shared process that runs embedded scripts. Because it's a shared environment, if a script has already imported a module, it may not pick up any changes (because of how we wrap it). Also, and I'm not positive on this, but it may also not find any new files added to the path after it started up (though, again, I could be wrong on this one).
Mark wrote:And thanks for all your support and walking me through this obscure issue...
No problem, it was a head scratcher.