What about:
from java.lang import Thread
Thread.sleep(5000)
Etc.. better or worse?
(Saw this in some other post that it could be better)
Not better or worse. Just as evil. The problem is any kind of sleep (or infinite loop) tying up a thread. Event threads are typically part of a limited thread pool, impacting other tasks.
Do you have any example using ProcessBuilder to execute code on the gateway? (like I did with system.util.execute) ?
Thanks in advance
/M
From a quick search for ProcessBuilder on this forum:
Yes I checked all the posts on the forum that contains ProcessBuilder. 
(I did't get any wiser doh:))
Will try to give it some more time tomorrow.
I don't see anything in the best practice white paper about what files can and/or should be staged for commits. Understanding that completely ignoring resources will break things, isn't there some sort of happy middle ground and not commit every resource.json that changes? To me it makes sense to stage only resource.json files that pair with things that actually changed. So if foo/code.py is changed, then for sure stage foo/resource.json. Or is this potentially flawed as well?
1 Like
The approach that works for us is to treat any directory that contains a resource.json file as an atomic object: either stage/commit ALL of the files in it, or NONE of the files in it.
Usually, after doing some development work, I have a handful of directories that have been modified. I have to take a quick peek at each directory, and decide if I really wanted those changes and git add the whole directory, or git restore the whole directory if I didn't want those changes. After everything is either added or restored, I finally do a git commit.
If there is a directory with some changes that I want and some changes I don't want, I go back into Designer and edit that resource.
1 Like