开云体育

Hi Bob,

Re 1) Not only did I think that was the way to do it, I was also (and am still) just building my 'library of tricks' to use in the proper, big script later on. This is one of the stages of learning! I have now removed the join, and made the spawned threads daemons, and that now works a *lot* better! Not only do I now get error messages when I need them (hurray!), the user interface no longer locks up, as you predicted (double hurray!).

Re 2) The line you mention is there. I'll see next what happens when I do not create that 'sensors' variable myself. IF it still goes wrong, at least I have an error message now to tell me where and how I goofed.

It's a lot better already, so thank you very much for the help so far. I'll let you know the result of the test once I get to it, which won't be today, but I hope to find time tomorrow.

Thanks again,

Wouter

On Wed, 2 Jan 2019 at 20:03, Bob Jacobsen <rgj1927@...> wrote:

1) Why make the main thread wait with a join?? What does that do for you?

2) I’m not a Bash expert, but that looks like it should work.? Somehow, Jython isn’t initializing properly for you.? Are you getting a line like this in the log?

2019-01-02 11:58:29,512 script.JmriScriptEngineManager? ? ? ? INFO? - python 2.7 is provided by jython 2.7.0 [AWT-EventQueue-0]

When I force an error, I get output that starts like:

2019-01-02 11:58:41,099 jython.InputWindow? ? ? ? ? ? ? ? ? ? ERROR - Error executing script [AWT-EventQueue-0]
javax.script.ScriptException: NameError: name 'xo' is not defined in <script> at line number 1
? ? ? ? at org.python.jsr223.PyScriptEngine.scriptException(PyScriptEngine.java:202)
? ? ? ? at org.python.jsr223.PyScriptEngine.eval(PyScriptEngine.java:42)
? ? ? ? at org.python.jsr223.PyScriptEngine.eval(PyScriptEngine.java:31)
? ? ? ? at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)

Bob

> On Jan 2, 2019, at 8:24 AM, whmvd <vandoornw@...> wrote:
>
> Hi Bob ,
>
> Thanks for the quick reaction.
> Re 1: I actually do that in a separate thread - but then the first thread waits while 'join'ing the subthread, so that remains the same problem, really. Do I need to make the subthread a daemon one and let the main thread just go? That would seem to make sense?
>
> Re 2: I use 'Run script...' from the Tables menu. If it helps, this is the script I use to start jmri (which should be good enough):
> =============================
> #!/bin/bash
>
> cd $HOME/JMRI
> nohup ./PanelPro >>$HOME/Desktop/.PanelPro.log 2>&1 &
> =============================
> Everything I log neatly shows up in the file on the desktop. The install is squeaky-clean; everything I do is in the user files area, nothing in the installation directory. VERY interesting that 'sensors' and 'turnouts' should have been predefined...
>
> Wouter
>
>
>
> On Wed, 2 Jan 2019 at 15:52, Bob Jacobsen <rgj1927@...> wrote:
> 1) There are ways to do this. They start off looking complicated, but you have to remember that asking the program to sleep _actually_ _works_: If you do that in the main program, the main program sleeps so that you can’t click, etc.? Instead, you have to hive your turnout activity into a little separate item (called a “thread”) which can run and sleep independently.
>
>
>
> 2) How are you running your scripts?? When I run something (i.e. while debugging) from a Script Entry window, the syntax error and runtime error messages show up nicely on JMRI System console window. Perhaps you’re running them a different way or there’s something else wrong?
>
> Another clue that something is wrong is not seeing “turnouts” and “sensors” predefined.? They _definitely_ should be.
>
> Bob
>
> > On Jan 2, 2019, at 7:42 AM, whmvd <vandoornw@...> wrote:
> >
> > Hello scripting-gurus,
> >
> > For quite a while now, I've been fighting python/jython rather than using it, and frustration is building up. I want to like it, I want to work with it - but it's not making it easy. For now, I'd like to focus on two things that make life very hard:
> >
> > 1) A small test script that looks up a turnout (successfully) checks its status (thrown or closed), logs it and sleeps for 0.2 seconds before checking again until it is what I want it to be does not allow me to operate any of my four panels (3x Panel Editor, 1x Layout Editor). The only things that can be operated are the resize buttons on the window and the positioning. So I can't throw the turnout to let the test program complete (the log line appears every 0.2 seconds, so it sort of seems to work). I would have thought that the time.sleep(200/1000.0) would allow me to do things instead of the whole interface being locked up? (BTW: specifically not looking for different ways to do this; I know I should add a listener and make that react, and I will end up doing that anyway - I am trying to understand why the simple thing I'd like to do cannot work)
> >
> > 2) When I make one of my frequent coding errors, the result is the same as described above - interface locked up except for the sizing/positioning of windows). I get no error logged. Nothing on standard output or standard error,? and nothing in the console. Zilch. This leaves me having to guess where I could have gone wrong, instead of being able to look at a stack dump. For instance: I thought in my optimism that the variables 'turnouts' and 'sensors' where predefined when importing jmri, so I was happily using them. That caused the lock-up with no message at all. Finding the cause of that took me several frustrating days. I hope to turn this back into a hobby!
> >
> > Any help will be greatly appreciated.
> >
> > Wouter
> >
> > PS: using JMRI 4.14 on Linux Mint 18.3.
> >
>
> --
> Bob Jacobsen
> rgj1927@...
>
>
>
>
>
>
>

--
Bob Jacobsen
rgj1927@...