Trying to get on top of jython

whmvd · 2022-01-04T03:17:51-08:00

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

Trying to get on top of jython

whmvd All Messages By This Member #155255 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 All Messages By This Member #155257 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@...
whmvd All Messages By This Member #155261 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 toggle quoted message Show quoted text 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 All Messages By This Member #155267 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@...
whmvd All Messages By This Member #155271 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 toggle quoted message Show quoted text 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@...
whmvd All Messages By This Member #155342 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 toggle quoted message Show quoted text 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@...
Dave Sand All Messages By This Member #155351 Wouter, Do you have "import java" and "import jmri" at the beginning of each python file? Dave Sand toggle quoted message Show quoted text 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@...
whmvd All Messages By This Member #155354 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 toggle quoted message Show quoted text 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@... > > > > > > >
Dave Sand All Messages By This Member #155361 Wouter, I have uploaded 2 files to your folder. It appears to me that the issue deals with scope and how import actually works. I don’t think it is a JMRI issue. Most likely something with Jython or maybe how you are structuring your program. miniTest DS.py uses the AbstractAutomaton class to handle the threading. It does not import util and the method calls to util where changed. The existing def in util DS.py was changed to act as static method. To run miniTest, util DS is run first which sets up the util environment with the util methods becoming global, then miniTest DS is run. This approach works but I am sure there are others. Dave Sand toggle quoted message Show quoted text 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@...
Bob Jacobsen All Messages By This Member #155363 instead of programmers, it should say addressedProgrammers and globalProgrammers, will fix. Bob On Jan 3, 2019, at 8:14 AM, whmvd <vandoornw@...> wrote: 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. -- Bob Jacobsen rgj1927@...
Bob Jacobsen All Messages By This Member #155364 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@...
Dave Sand All Messages By This Member #155365 Bob, The directory is up one level. Dave Sand toggle quoted message Show quoted text 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@...
Bob Jacobsen All Messages By This Member #155368 Thanks. Wouter, what version of JMRI are you using? Re this: 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. I simply don’t understand this at all. The comment says that the print statement shows in the log, but there’s nothing to invoke it. With the masts assignment commented or not, I get: masts= jmri.managers.DefaultSignalMastManager@2f7c2f4f so something else is going on in your installation. Have you messed with the python.properties file? (Whether or not you have, the right answer is “don’t”) Bob On Jan 3, 2019, at 12:10 PM, Dave Sand <ds@...> wrote: Bob, The directory is up one level. Dave Sand 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@... -- Bob Jacobsen rgj1927@...
whmvd All Messages By This Member #155374 Hi Bob, It's 4.14 (I'm on Linux Mint 18.3), and no, I did not mess with properties. I'm no believer in fresh downloads, but if you think it's any use I'll happily try it - just let me know. I've also got 4.12 still ready to run. Up to yesterday, it gave me all the same results as 4.14 did, and I've more or less let that branch of investigation go. I'll look at Dave Sands approach tomorrow or the day after (big shopping day tomorrow) and see if that'll work for me. My problem is that if a totally valid approach does not work, then my trust in 'it' (in this case python) goes swiftly down the drain. <rant ignore=true> Where are the good old days of reliable software (C compilers just didn't go wrong or if they did it got fixed)... I know - complexity... I chucked my job because I positively hated having to work with javascript, bane of my professional life. I chucked Windows because over 90% of my time over the last three years was spent doing system maintainance and problem seeking (what a relief Linux is)! And now I want to spend my time enjoying railway automation with JMRI, and railway film editing/DVD production, which Windows also killed and I need to get that started from scratch on Linux. In short, I am in really desperate need of some success, and will fight tooth and nail to get there! </rant> I'm very grateful for the help I get here - this community is as supportive as they come. I am already way beyond where I'd ever have been without you. Wouter toggle quoted message Show quoted text On Thu, 3 Jan 2019 at 20:25, Bob Jacobsen <rgj1927@...> wrote: Thanks. Wouter, what version of JMRI are you using? Re this: > 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. I simply don’t understand this at all.? The comment says that the print statement shows in the log, but there’s nothing to invoke it. With the masts assignment commented or not, I get: masts= jmri.managers.DefaultSignalMastManager@2f7c2f4f so something else is going on in your installation. Have you messed with the python.properties file? (Whether or not you have, the right answer is “don’t”) Bob > On Jan 3, 2019, at 12:10 PM, Dave Sand <ds@...> wrote: > > Bob, > > The directory is up one level. > > Dave Sand > > >> 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@... >> >> >> >> >> >> > > > > -- Bob Jacobsen rgj1927@...
whmvd All Messages By This Member #155489 Hi Dave, Bob, Dave, that version must earn 10 out of 10 for conciseness! It also challenges me, as to how the tester class finds the setSignalHeld method in a different file without any apparent reference except that it happens to be in the same directory. Yikes, that hurts my poor traditional eyes! So it looks like I have studying to do before I find the answer to the question 'why is the masts variable not reachable in my code' - which continues to irritate the heck out of me. I'll see if I can get your solution reshaped to suit my sensibilities - meaning to include some declaration mechanism without which the call must fail (sorry but I am like that...!) - without breaking anything else. But most of all I need to get a grip on understanding how all that is supposed? to work in python. Just working on expectation is not going to cut it, as I have already proved to everyone's satisfaction! Thanks both for your time Wouter toggle quoted message Show quoted text On Thu, 3 Jan 2019 at 18:42, Dave Sand <ds@...> wrote: Wouter, I have uploaded 2 files to your folder. It appears to me that the issue deals with scope and how import actually works.? I don’t think it is a JMRI issue.? Most likely something with Jython or maybe how you are structuring your program. miniTest DS.py uses the AbstractAutomaton class to handle the threading.? It does not import util and the method calls to util where changed. The existing def in util DS.py was changed to act as static method. To run miniTest, util DS is run first which sets up the util environment with the util methods becoming global, then miniTest DS is run. This approach works but I am sure there are others. Dave Sand > 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@... > > > > > > > > > > > > > > > > > > >
whmvd All Messages By This Member #155492 Dave, Not nice of me, but I'm almost happy to report that I get an error that I rather like the look of: 2019-01-05 16:45:13,187 automat.AbstractAutomaton???????????? WARN? - Unexpected Exception ends AbstractAutomaton thread [__builtin__$Tester$0] Traceback (most recent call last): ? File "<script>", line 7, in handle NameError: global name 'setSignalHeld' is not defined ??? at org.python.core.Py.NameError(Py.java:284) ??? at org.python.core.PyFrame.getglobal(PyFrame.java:265) ??? at org.python.pycode._pyx2.handle$2(<script>:9) ??? at org.python.pycode._pyx2.call_function(<script>) ??? at org.python.core.PyTableCode.call(PyTableCode.java:167) ??? at org.python.core.PyBaseCode.call(PyBaseCode.java:307) ??? at org.python.core.PyBaseCode.call(PyBaseCode.java:198) ??? at org.python.core.PyFunction.__call__(PyFunction.java:482) ??? at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:237) ??? at org.python.core.PyMethod.__call__(PyMethod.java:228) ??? at org.python.core.PyMethod.__call__(PyMethod.java:218) ??? at org.python.core.PyMethod.__call__(PyMethod.java:213) ??? at org.python.core.PyObject._jcallexc(PyObject.java:3626) ??? at org.python.core.PyObject._jcall(PyObject.java:3658) ??? at org.python.proxies.__builtin__$Tester$0.handle(Unknown Source) ??? at jmri.jmrit.automat.AbstractAutomaton.run(AbstractAutomaton.java:151) ??? at java.lang.Thread.run(Thread.java:748) Maybe it was trimmed just a bit too much? Wouter toggle quoted message Show quoted text On Thu, 3 Jan 2019 at 18:42, Dave Sand <ds@...> wrote: Wouter, I have uploaded 2 files to your folder. It appears to me that the issue deals with scope and how import actually works.? I don’t think it is a JMRI issue.? Most likely something with Jython or maybe how you are structuring your program. miniTest DS.py uses the AbstractAutomaton class to handle the threading.? It does not import util and the method calls to util where changed. The existing def in util DS.py was changed to act as static method. To run miniTest, util DS is run first which sets up the util environment with the util methods becoming global, then miniTest DS is run. This approach works but I am sure there are others. Dave Sand > 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@... > > > > > > > > > > > > > > > > > > >
Dave Sand All Messages By This Member #155495 Wouter, I have uploaded two new files to your folder: test_ds.py and util_ds.py. The execfile loads the util contents as global methods. See if this approach makes sense. Dave Sand toggle quoted message Show quoted text On Jan 5, 2019, at 10:49 AM, whmvd <vandoornw@...> wrote: Dave, Not nice of me, but I'm almost happy to report that I get an error that I rather like the look of: 2019-01-05 16:45:13,187 automat.AbstractAutomaton WARN - Unexpected Exception ends AbstractAutomaton thread [__builtin__$Tester$0] Traceback (most recent call last): File "<script>", line 7, in handle NameError: global name 'setSignalHeld' is not defined at org.python.core.Py.NameError(Py.java:284) at org.python.core.PyFrame.getglobal(PyFrame.java:265) at org.python.pycode._pyx2.handle$2(<script>:9) at org.python.pycode._pyx2.call_function(<script>) at org.python.core.PyTableCode.call(PyTableCode.java:167) at org.python.core.PyBaseCode.call(PyBaseCode.java:307) at org.python.core.PyBaseCode.call(PyBaseCode.java:198) at org.python.core.PyFunction.__call__(PyFunction.java:482) at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:237) at org.python.core.PyMethod.__call__(PyMethod.java:228) at org.python.core.PyMethod.__call__(PyMethod.java:218) at org.python.core.PyMethod.__call__(PyMethod.java:213) at org.python.core.PyObject._jcallexc(PyObject.java:3626) at org.python.core.PyObject._jcall(PyObject.java:3658) at org.python.proxies.__builtin__$Tester$0.handle(Unknown Source) at jmri.jmrit.automat.AbstractAutomaton.run(AbstractAutomaton.java:151) at java.lang.Thread.run(Thread.java:748) Maybe it was trimmed just a bit too much? Wouter On Thu, 3 Jan 2019 at 18:42, Dave Sand <ds@...> wrote: Wouter, I have uploaded 2 files to your folder. It appears to me that the issue deals with scope and how import actually works. I don’t think it is a JMRI issue. Most likely something with Jython or maybe how you are structuring your program. miniTest DS.py uses the AbstractAutomaton class to handle the threading. It does not import util and the method calls to util where changed. The existing def in util DS.py was changed to act as static method. To run miniTest, util DS is run first which sets up the util environment with the util methods becoming global, then miniTest DS is run. This approach works but I am sure there are others. Dave Sand 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@...
whmvd All Messages By This Member #155502 Dave, It does in that it works for this example. When I think of what's going to happen when my util-script becomes (it is already, I just gave the simplified version that reproduced the error) three separate util-scripts that may import one another, then my mind gives up and I sort of lose the will to live. What I need to figure out first and foremost is why my original works in Bob's environment and yours, but not in mine. That must be the real key to my problem. As a total python beginner, I am unfortunate in not being qualified at all to begin figuring it out. I guess I am beyond help in this. I'll keep on experimenting for a few days, but I do need to see myself make some progress soon or, instead of a hobby, this will have become a pain. That's not the plan! Thanks for your thoughts! Wouter toggle quoted message Show quoted text On Sat, 5 Jan 2019 at 17:35, Dave Sand <ds@...> wrote: Wouter, I have uploaded two new files to your folder:? test_ds.py and util_ds.py. The execfile loads the util contents as global methods. See if this approach makes sense. Dave Sand > On Jan 5, 2019, at 10:49 AM, whmvd <vandoornw@...> wrote: > > Dave, > > Not nice of me, but I'm almost happy to report that I get an error that I rather like the look of: > 2019-01-05 16:45:13,187 automat.AbstractAutomaton? ? ? ? ? ? ?WARN? - Unexpected Exception ends AbstractAutomaton thread [__builtin__$Tester$0] > Traceback (most recent call last): >? ?File "<script>", line 7, in handle > NameError: global name 'setSignalHeld' is not defined > >? ? ?at org.python.core.Py.NameError(Py.java:284) >? ? ?at org.python.core.PyFrame.getglobal(PyFrame.java:265) >? ? ?at org.python.pycode._pyx2.handle$2(<script>:9) >? ? ?at org.python.pycode._pyx2.call_function(<script>) >? ? ?at org.python.core.PyTableCode.call(PyTableCode.java:167) >? ? ?at org.python.core.PyBaseCode.call(PyBaseCode.java:307) >? ? ?at org.python.core.PyBaseCode.call(PyBaseCode.java:198) >? ? ?at org.python.core.PyFunction.__call__(PyFunction.java:482) >? ? ?at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:237) >? ? ?at org.python.core.PyMethod.__call__(PyMethod.java:228) >? ? ?at org.python.core.PyMethod.__call__(PyMethod.java:218) >? ? ?at org.python.core.PyMethod.__call__(PyMethod.java:213) >? ? ?at org.python.core.PyObject._jcallexc(PyObject.java:3626) >? ? ?at org.python.core.PyObject._jcall(PyObject.java:3658) >? ? ?at org.python.proxies.__builtin__$Tester$0.handle(Unknown Source) >? ? ?at jmri.jmrit.automat.AbstractAutomaton.run(AbstractAutomaton.java:151) >? ? ?at java.lang.Thread.run(Thread.java:748) > > Maybe it was trimmed just a bit too much? > > Wouter > > On Thu, 3 Jan 2019 at 18:42, Dave Sand <ds@...> wrote: > Wouter, > > I have uploaded 2 files to your folder. > > It appears to me that the issue deals with scope and how import actually works.? I don’t think it is a JMRI issue.? Most likely something with Jython or maybe how you are structuring your program. > > miniTest DS.py uses the AbstractAutomaton class to handle the threading.? It does not import util and the method calls to util where changed. > > The existing def in util DS.py was changed to act as static method. > > To run miniTest, util DS is run first which sets up the util environment with the util methods becoming global, then miniTest DS is run. > > This approach works but I am sure there are others. > > Dave Sand > > > > > 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@... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Bob Jacobsen All Messages By This Member #155515 Can I give some advice that’s meant to be constructive? Stop with the complexity. Just stop. If you’re already thinking in terms of a future with "three separate util-scripts that may import one another”, you’re trying to approach this in a way that simply doesn’t work in Python. Python is fundamentally a scripting language where things are meant to be built up as needed. In that sense, it’s have a lot of things that make that approach simple, but will (of necessity) make more Big Program Waterfall approaches hard. That’s a deliberate choice on the part of the Python community: You can’t change this. There are ten’s of millions of people who like the way Python works, and Python’s approach is not going to change. There are hundreds or perhaps thousands of people who use Python scripting as embedded in JMRI, in a straight-forward way, and that embedding is not going to change. So what now? Well, there are alternatives: You can try JMRI’s embedded JavaScript, which might have a structure you like more. Or you can interface Java of your own to JMRI as quite a few other people do. You can even write code for JMRI in Scala or PHP; though those seem odd choices to me, people have done it. Or, if you’d prefer something that’s native C/C++, you should check out RocRail (RocRail changed to a proprietary software license in 2015, from GPL, but the source is perhaps still available by request: ) Or you could write standalone code that talks to JMRI, RocRail or Railroad & Co over network connections. If you want to stay with Python scripting in JMRI, which for many people is a great choice, you should reconsider your approach. When you see "it works for this example”, that shouldn’t cause doubt and search for further issues. Instead, that should be followed by “great, I can now move on the next thing”. Large, very powerful Python system are built as sequence of “this examples” that are sequentially completed in the simplest possible way (the Minimal Viable Product idea), without worrying about lots of future details (the You Ain’t Gonna Need It principle). If something comes up later, yes, you might have to redo something; that’s expected. The idea of Python is to make the first part so fast and easy that you have time for the second, which by the way is also fast and easy. Specifically, I recommend you start over. Throw out (or archive) your JMRI preferences directory, your scripts, even install a new JMRI download to make sure that you haven’t gotten any modified JMRI configuration files and scripts. Then start writing simple scripts that do simple things, one at a time, individually, with the least possible complexity. Forget about joins or importing your utility files or anything beyond “what does this do on the railroad right now?". As each one works, _declare_ _victory_ and move on to the next. I understand that this is a hobby, believe me I understand that, and that some people don’t like to code that way for their hobby. That’s fine, everybody has preferences. If you don’t like Python’s approach, well, you’re not going to like Python’s approach. In that case, you might be better off picking another tool set. Bob On Jan 5, 2019, at 10:32 AM, whmvd <vandoornw@...> wrote: Dave, It does in that it works for this example. When I think of what's going to happen when my util-script becomes (it is already, I just gave the simplified version that reproduced the error) three separate util-scripts that may import one another, then my mind gives up and I sort of lose the will to live. What I need to figure out first and foremost is why my original works in Bob's environment and yours, but not in mine. That must be the real key to my problem. As a total python beginner, I am unfortunate in not being qualified at all to begin figuring it out. I guess I am beyond help in this. I'll keep on experimenting for a few days, but I do need to see myself make some progress soon or, instead of a hobby, this will have become a pain. That's not the plan! Thanks for your thoughts! Wouter On Sat, 5 Jan 2019 at 17:35, Dave Sand <ds@...> wrote: Wouter, I have uploaded two new files to your folder: test_ds.py and util_ds.py. The execfile loads the util contents as global methods. See if this approach makes sense. Dave Sand On Jan 5, 2019, at 10:49 AM, whmvd <vandoornw@...> wrote: Dave, Not nice of me, but I'm almost happy to report that I get an error that I rather like the look of: 2019-01-05 16:45:13,187 automat.AbstractAutomaton WARN - Unexpected Exception ends AbstractAutomaton thread [__builtin__$Tester$0] Traceback (most recent call last): File "<script>", line 7, in handle NameError: global name 'setSignalHeld' is not defined at org.python.core.Py.NameError(Py.java:284) at org.python.core.PyFrame.getglobal(PyFrame.java:265) at org.python.pycode._pyx2.handle$2(<script>:9) at org.python.pycode._pyx2.call_function(<script>) at org.python.core.PyTableCode.call(PyTableCode.java:167) at org.python.core.PyBaseCode.call(PyBaseCode.java:307) at org.python.core.PyBaseCode.call(PyBaseCode.java:198) at org.python.core.PyFunction.__call__(PyFunction.java:482) at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:237) at org.python.core.PyMethod.__call__(PyMethod.java:228) at org.python.core.PyMethod.__call__(PyMethod.java:218) at org.python.core.PyMethod.__call__(PyMethod.java:213) at org.python.core.PyObject._jcallexc(PyObject.java:3626) at org.python.core.PyObject._jcall(PyObject.java:3658) at org.python.proxies.__builtin__$Tester$0.handle(Unknown Source) at jmri.jmrit.automat.AbstractAutomaton.run(AbstractAutomaton.java:151) at java.lang.Thread.run(Thread.java:748) Maybe it was trimmed just a bit too much? Wouter On Thu, 3 Jan 2019 at 18:42, Dave Sand <ds@...> wrote: Wouter, I have uploaded 2 files to your folder. It appears to me that the issue deals with scope and how import actually works. I don’t think it is a JMRI issue. Most likely something with Jython or maybe how you are structuring your program. miniTest DS.py uses the AbstractAutomaton class to handle the threading. It does not import util and the method calls to util where changed. The existing def in util DS.py was changed to act as static method. To run miniTest, util DS is run first which sets up the util environment with the util methods becoming global, then miniTest DS is run. This approach works but I am sure there are others. Dave Sand 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@... -- Bob Jacobsen rgj1927@...
whmvd All Messages By This Member #155528 Hi Bob, Those are wise words, I'm sure of it. That's the sort of sentence that usually builds up to 'but...', isn't it? Well, no. Not this time. I'll get out of python altogether, as my way of thinking about what I want to achieve isn't going to change. And when my way and a tool's way don't match, then I won't persist with pressing the square peg down the round hole. And one of the python Zen principles you linked to ('Although that way may not be obvious at first unless you're Dutch') makes me, as a Dutchman, even more sure that it's the wrong track! I'll have a good old think about what I do want instead. From the options you mention, which I'm certain aren't exhaustive, but which I'm also certain are the most obvious and therefore wisest choices to make, Java is by far the most appealing. Because I know it, because it's native to JMRI, because others do it. All good reasons adding up to a compelling argument. I think that part of the choice is really already a given. In a small way that'll mean starting over, but honestly - I hadn't got far down this blind alley and I can chuck it with no hard feelings. Better to find out really early. I will ask for more advice, though. And that is: what's good tooling for me to start out with (on Linux)? I'm familiar with Eclipse, but not so in-depth that I'd hate to use anything else. And what are gotchas with how I set up my coding bit separately enough so that a new JMRI-release slots in nicely and easily? I do not, at the moment, think that what I want to do is generic enough to be something deliverable back to the project (I might surprise myself, but that's just the current feeling). On the other hand, it might be handy to have a setup that allows me to chase and fix JMRI bugs when I encounter them. Again, I'll be happily led by your expertise. [Just so you have an idea about what I can do/have done: Java certified for J5, 25+ years as a professional programmer and occasional tech writer, last 10-15 years exclusively OO (Java and C++), C and (ka/b)sh at guru level up to some 5 years ago - that sort of thing. Retired into B&B business, continued professionally for a year or two on the side until that turned too much into uniquely javascript, which hates me about as much as I detest it... :-) ] Thank you for the reality check. I think that was perfectly timed. Wouter toggle quoted message Show quoted text On Sat, 5 Jan 2019 at 20:05, Bob Jacobsen <rgj1927@...> wrote: Can I give some advice that’s meant to be constructive? ? ? ? ?Stop with the complexity.? Just stop. If you’re already thinking in terms of a future with "three separate util-scripts that may import one another”, you’re trying to approach this in a way that simply doesn’t work in Python. Python is fundamentally a scripting language where things are meant to be built up as needed.? In that sense, it’s have a lot of things that make that approach simple, but will (of necessity) make more Big Program Waterfall approaches hard.? That’s a deliberate choice on the part of the Python community: You can’t change this.? There are ten’s of millions of people who like the way Python works, and Python’s approach is not going to change.? There are hundreds or perhaps thousands of people who use Python scripting as embedded in JMRI, in a straight-forward way, and that embedding is not going to change. So what now?? Well, there are alternatives:? You can try JMRI’s embedded JavaScript, which might have a structure you like more.? Or you can interface Java of your own to JMRI as quite a few other people do.? You can even write code for JMRI in Scala or PHP; though those seem odd choices to me, people have done it.? Or, if you’d prefer something that’s native C/C++, you should check out RocRail (RocRail changed to a proprietary software license in 2015, from GPL, but the source is perhaps still available by request: ) Or you could write standalone code that talks to JMRI, RocRail or Railroad & Co over network connections. If you want to stay with Python scripting in JMRI, which for many people is a great choice, you should reconsider your approach. When you see "it works for this example”, that shouldn’t cause doubt and search for further issues.? Instead, that should be followed by “great, I can now move on the next thing”. Large, very powerful Python system are built as sequence of “this examples” that are sequentially completed in the simplest possible way (the Minimal Viable Product idea), without worrying about lots of future details (the You Ain’t Gonna Need It principle).? If something comes up later, yes, you might have to redo something; that’s expected.? The idea of Python is to make the first part so fast and easy that you have time for the second, which by the way is also fast and easy. Specifically, I recommend you start over.? Throw out (or archive) your JMRI preferences directory, your scripts, even install a new JMRI download to make sure that you haven’t gotten any modified JMRI configuration files and scripts.? Then start writing simple scripts that do simple things, one at a time, individually, with the least possible complexity. Forget about joins or importing your utility files or anything beyond “what does this do on the railroad right now?". As each one works, _declare_ _victory_ and move on to the next. I understand that this is a hobby, believe me I understand that, and that some people don’t like to code that way for their hobby.? That’s fine, everybody has preferences.? If you don’t like Python’s approach, well, you’re not going to like Python’s approach.? In that case, you might be better off picking another tool set. Bob > On Jan 5, 2019, at 10:32 AM, whmvd <vandoornw@...> wrote: > > Dave, > > It does in that it works for this example. > > When I think of what's going to happen when my util-script becomes (it is already, I just gave the simplified version that reproduced the error) three separate util-scripts that may import one another, then my mind gives up and I sort of lose the will to live. > > What I need to figure out first and foremost is why my original works in Bob's environment and yours, but not in mine. That must be the real key to my problem. As a total python beginner, I am unfortunate in not being qualified at all to begin figuring it out. > > I guess I am beyond help in this. I'll keep on experimenting for a few days, but I do need to see myself make some progress soon or, instead of a hobby, this will have become a pain. That's not the plan! > > Thanks for your thoughts! > Wouter > > On Sat, 5 Jan 2019 at 17:35, Dave Sand <ds@...> wrote: > Wouter, > > I have uploaded two new files to your folder:? test_ds.py and util_ds.py. > > The execfile loads the util contents as global methods. > > See if this approach makes sense. > > Dave Sand > > > > > On Jan 5, 2019, at 10:49 AM, whmvd <vandoornw@...> wrote: > > > > Dave, > > > > Not nice of me, but I'm almost happy to report that I get an error that I rather like the look of: > > 2019-01-05 16:45:13,187 automat.AbstractAutomaton? ? ? ? ? ? ?WARN? - Unexpected Exception ends AbstractAutomaton thread [__builtin__$Tester$0] > > Traceback (most recent call last): > >? ?File "<script>", line 7, in handle > > NameError: global name 'setSignalHeld' is not defined > > > >? ? ?at org.python.core.Py.NameError(Py.java:284) > >? ? ?at org.python.core.PyFrame.getglobal(PyFrame.java:265) > >? ? ?at org.python.pycode._pyx2.handle$2(<script>:9) > >? ? ?at org.python.pycode._pyx2.call_function(<script>) > >? ? ?at org.python.core.PyTableCode.call(PyTableCode.java:167) > >? ? ?at org.python.core.PyBaseCode.call(PyBaseCode.java:307) > >? ? ?at org.python.core.PyBaseCode.call(PyBaseCode.java:198) > >? ? ?at org.python.core.PyFunction.__call__(PyFunction.java:482) > >? ? ?at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:237) > >? ? ?at org.python.core.PyMethod.__call__(PyMethod.java:228) > >? ? ?at org.python.core.PyMethod.__call__(PyMethod.java:218) > >? ? ?at org.python.core.PyMethod.__call__(PyMethod.java:213) > >? ? ?at org.python.core.PyObject._jcallexc(PyObject.java:3626) > >? ? ?at org.python.core.PyObject._jcall(PyObject.java:3658) > >? ? ?at org.python.proxies.__builtin__$Tester$0.handle(Unknown Source) > >? ? ?at jmri.jmrit.automat.AbstractAutomaton.run(AbstractAutomaton.java:151) > >? ? ?at java.lang.Thread.run(Thread.java:748) > > > > Maybe it was trimmed just a bit too much? > > > > Wouter > > > > On Thu, 3 Jan 2019 at 18:42, Dave Sand <ds@...> wrote: > > Wouter, > > > > I have uploaded 2 files to your folder. > > > > It appears to me that the issue deals with scope and how import actually works.? I don’t think it is a JMRI issue.? Most likely something with Jython or maybe how you are structuring your program. > > > > miniTest DS.py uses the AbstractAutomaton class to handle the threading.? It does not import util and the method calls to util where changed. > > > > The existing def in util DS.py was changed to act as static method. > > > > To run miniTest, util DS is run first which sets up the util environment with the util methods becoming global, then miniTest DS is run. > > > > This approach works but I am sure there are others. > > > > Dave Sand > > > > > > > > > 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@... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Bob Jacobsen rgj1927@...

Previous Topic Next Topic

开云体育

Locked Trying to get on top of jython

Trying to get on top of jython