On Jan 3, 2019, at 2:06 PM, Bob Jacobsen <rgj1927@...> wrote:

I’m not seeing that directory. Link please?

What may be going on here is the scope of global variables:

Bob

On Jan 3, 2019, at 8:14 AM, whmvd <vandoornw@...> wrote:

I've now created a WoutersPythonbug directory in ProblemsBeingWorkedOn which contains just three tiny scripts, together showing that there is, as far as I can make out, really a bug here.

--
Bob Jacobsen
rgj1927@...

On Jan 3, 2019, at 10:14 AM, whmvd <vandoornw@...> wrote:

Indeed, Dave, I have.

I've now created a WoutersPythonbug directory in ProblemsBeingWorkedOn which contains just three tiny scripts, together showing that there is, as far as I can make out, really a bug here.

1) jmriShortCuts.py
Simply prints all the objects that should be predefined according to the following documentation link:

(it turns out that 'programmers' (or indeed 'programmer') is not present, which is probably a very minor documentation buglet, but masts, the one I focus on, is. So my environment does set it up correctly for me.

2) miniTest.py
A main test program that simply runs, in its own thread, my object under test.

3) util.py
Totally useless as is, but that's because it has been pruned of everything that could go while still showing the bug. As uploaded, it works, but only because of the assignment statement that creates a valid 'masts' variable. Comment that out, and things go horribly wrong, which they shouldn't if masts were properly preset. Also, edit a signalmast name into this file that is a valid one in your panelfile, instead of EastNorthOuter. I've also included my panelfile, should that be handier to use instead.

Put the three scripts into the resources directory and run:
1) jmriShortCuts.py
proving that the environment sets up the masts variable
2) miniTest.py
proving that that test shows a validly retrieved signalMast

Comment out the line that should not be in miniTest.py (masts=...)
Restart JMRI to get rid of possibly remaining classes in memory (that bit me at some point)
3) miniTest.py
proving that now it does not work anymore, with all the symptoms listed in the file itself.

I'm using JMRI 4.14 under Linux Mint 18.3

Anything more I can do to help explain why I think this is a bug?

Thanks,
Wouter

On Thu, 3 Jan 2019 at 15:02, Dave Sand <ds@...> wrote:
Wouter,

Do you have "import java" and "import jmri" at the beginning of each python file?

Dave Sand

On Jan 3, 2019, at 5:37 AM, whmvd <vandoornw@...> wrote:

Hello again, Bob,

Thanks for bearing with me on this.

It didn't go quite as planned when I went looking for the global variables 'turnouts', 'masts' and 'sensors'. Weirdly, turnouts and sensors are there, but masts is not. That is now the only little niggle left. Considering where I was only yesterday, that's a nnumber of huge leaps forward. The error reported is "global name 'masts' is not defined". I can bypass the problem easily by including the following line in my code:

masts = jmri.InstanceManager.getDefault(jmri.SignalMastManager)

but that's really cheating, shouldn't be necessary and keeps the back of my mind worried at what else could go wrong when I continue. Any advice on this?masts = jmri.InstanceManager.getDefault(jmri.SignalMastManager)

Wouter

On Wed, 2 Jan 2019 at 20:31, Wouter van Doorn <vandoornw@...> wrote:
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@...