Locked
Re: Trying to get on top of jython
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@...
|
Don W,
To clarify something about adding devices, what the system name means.
Generally the field you enter is information for how JMRI will find the
device. Now for Internal devices, it is just a name field with no specific
meaning. But for everything else, here is how the system name breaks down:
1st character (and sometimes digit) tells JMRI which connection to use to
talk to this device.
Next character is about the 'type' of the device. Example is T for turnouts,
S for sensors, R for routes, X for Logix, and so on. This tells JMRI which
'manager' deals with the device.
Rest of the characters, this will vary greatly as for real hardware it has
specific meaning to picking the remote device. It may be a simple number or
something more complicated, but it will depend on the system (as picked by
the 1st character).
Note: when you are entering the name, you don't type in the first two parts,
those are provided by the pull down that selected the system name, the
screen you are in picked that it is a turnout, sensor, etc...
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
|
Locked
Re: XpressNet Session Log errors
Paul,
Excellent.? That's what I like to see...no errors.
Again, many thanks for your help.
Regards
Tom
On 05/01/2019 14:21, Paul Bender wrote:
toggle quoted message
Show quoted text
Tom,
I think I have this fixed, at least I no longer see the error
with an Atlas Commander connected to JMRI.
When you get a chance, please download a daily build from
To confirm you no longer see it either.
Thanks!
Paul
On Dec 28, 2018, at 3:43 AM, Tom Busza via Groups.Io < tombee50@...>
wrote:
Many thanks Paul, I look forward to the fix.
Meantime Happy New Year to one and all.
Tom
On 28/12/2018 07:08, Paul
Bender wrote:
On Dec 25, 2018, at 3:25 PM, Tom Busza via Groups.Io
< tombee50@...>
wrote:
I am just intrigued why this is happening.
The annoying part is that when I open JMRI, I have
to wait for JMRI to check things, give me an error
message:
System connection XpressNet provides a null
manager for interface CommandStation Unable to to
run startup due to earlier failures.?? Please
check logs for more details. The Preferences
window will open so this can be fixed.
This happens because you are using a Compact which
doesn¡¯t provide support for sending raw packets to the
rails.
BUT you shouldn¡¯t get this Error message because the
command station option should be disabled when the
compact is connected.
I¡¯ll pull out an Atlas Commander (rebadged Compact )
so I can replicate the issue and fix it. ?This might
take me a few days however.
Paul
|
Locked
Re: Decoder Pro problems
Peter, On 5 Jan 2019, at 10:00 PM, Peter Ross <peterr@...> wrote:
Maybe it is because I only see the digest, Dave, but I'm still lost. I just searched for SwissChris and only found four messages none of which was relevant.
I used to get every message but there was too little of relevance to my situation.
Maybe you could cut and paste what SwissChris said into your reply? It would be interesting to know what it said.
Regards
Peter I find all this most bizarre. Maybe Digest Mode is doing quite bizarre things. I'll send you some information privately. Dave in Australia.
|
Dick,
Thanks for the explanation of the capital "i"s. I hope they don't have to be changed when I choose which interface I use for the control panels and railroad hardware: possibly C/MRI.
I want to have turnout control from the panels, but also from my EasyDCC tethered and any JMRI wireless throttles. If the prefix is for the type of control system, I wonder which would be right for that?!
Ideally, a wireless tablet could be used as both a control panel and as a throttle. Is there an existing way to do that? I can imagine a "button" in a corner of the screen that is pressed to toggle between control panel and throttle displays, or using most of a larger tablet's display for the control panel, with a narrow band along an edge for the throttle. That could be very workable on my ASUS' seven inch display.
If any discussion follows, that paragraph about combined wireless control panels and throttles probably should be made a new topic...
Don Weigt
|
Locked
Re: Blocks not working properly
OK Marc will look into it ? Sent from for Windows 10 ?
toggle quoted message
Show quoted text
From: MarcSent: Saturday, January 5, 2019 1:40 PM To: [email protected]Subject: Re: [jmriusers] Blocks not working properly ? First off, is the BDL168 indicating the proper occupancy with it's onboard indicators ?? If this is not correct because of wiring issues, gap issues, common returns,? JMRI will not solve them and just add to the confusion.
Marc
|
Locked
Re: Marklin double-slip in layout editor
Balazs,
Use two internal turnouts for the slip. Create a small Logix which translates the two turnout positions into a single real switch machine position.
If both internal turnouts are closed or thrown, the real one is closed, etc.
Dave Sand
toggle quoted message
Show quoted text
On Jan 5, 2019, at 12:40 PM, Balazs Racz <balazs.racz@...> wrote:
Hi,
How do people represent Marklin style double slip turnouts (DKW) on layout editor panels?
These are double slips which are controlled by a single turnout motor. When the turnout is closed, it acts as a crossing (both straight routes are passable). When it is thrown, both diagonal routes are passable.
It seems to me that the double slip that exists in Layout Editor has only one of the four routes passable at any time and it needs two turnouts to define which one.
thanks,
Balazs
|
Locked
Marklin double-slip in layout editor
Hi,
How do people represent Marklin style double slip turnouts () on layout editor panels? These are double slips which are controlled by a single turnout motor. When the turnout is closed, it acts as a crossing (both straight routes are passable). When it is thrown, both diagonal routes are passable.
It seems to me that the double slip that exists in Layout Editor has only one of the four routes passable at any time and it needs two turnouts to define which one.
thanks, Balazs
|
Locked
Re: Trying to get on top of jython
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@...
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
|
I am an 86 year old new member and potential new JMRI user.
I was a member of a train club that uses JMRI to control their trains and layout. Failing health of my wife forced a retirement move and I am no longer a member.
Can you provide me with info on what I need to buy and download
so I can use JMRI on the home layout that my daughter and grandkids and I are now building
in my daughter¡¯s basement. I think it would be fun for the grandkids to control the trains with their phones like the members of the club did.
Thanks
Joe
|
On 1/5/2019 9:45 AM, Marc wrote:
No changed? but
there is an option added to? set a function key to " switch to a
continuous speed slider on Fxx "
??? That has not changed.? Options have not
changed.? What the throttle is doing does not fit any of the
options I have looked at!:-(
?
??? As I only use DP I always ugrade to the
latest test version.? Most changes are to the other part of
JMRI.?? This is on a Win7 Optiplex 760 which is not on the net
and just connected to a short test track using SPROG.
??? Also I run the simulated version on this computer
(ThinkCentre using Win10) which is connected to the net (JMRI
4.15.1 currently running) and always update however the
Simulated Digitrax LocoNet shows the old throttle.
??? Aha, found it.? For some reason it had
defaulted to "Enable button icons when available".? Have no
idea how that happened and found it by comparing Throttle
preferences between the two computers.
--
Jon Miller
For me time stopped in 1941
Digitrax Chief/Zephyr systems,
SPROG, JMRI User
NMRA Life member #2623
Member SFRH&MS
|
Hi All,
Just want to add my two cent (pennys) worth. To make my point that the English language words in the English speaking countries may have different meaning and pronounced differently. Also I was born in the US at a very young age my dad died and my mother and I went to her parents home in Germany. While in high school we learned English, the Queens English as we called it. Later I entered the US Air Force and was exposed to American English. So I can understand why Write or Read on sheets may be confusing but it nothing other then having a book of pages to enter information. Each sheet has a tab and the sheet is filled with boxes that you can click (tick) on to change info. Each of these boxes represent a CV and when you Write to the sheet it changes the info in the decoder. If you Read the changes it will show you which changes have been made. As far as I'm concerned nothing should be changed. That's my two cents worth and I want to thank all of the programmers that keep JMRI up to date for their time an effort in this endeavour.
Al Babinsky
Sent from Xfinity Connect Application
|
Locked
Re: Ops and Roster question
Thanks Ken for clarifying that. I guess what I don't want is to create more work down the road than necessary. I'm going to take a closer look at Decoder Pro to figure a few things out as suggested, but an initial question comes to mind... Would it not be sensible / possible to (maybe optionally) use the roster table and data as the source of info in ops directly, assuming somehow critical detail such as type etc could also be entered into the roster directly for each loco? Just a thought....!
John
John,
What I was meaning is the only details for a non-decoder loco would be
things like road name, locomotive type, owner, manufacturer, and comments.
For that loco, anything that entry thought of as being a CV would be
meaningless since the loco has no decoder, therefore, no CV's.
-Ken Cameron, Member JMRI Dev Team
|
Locked
Re: Trying to get on top of jython
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@...
|
Not sure what you're asking.
JMRI throttles can display either percentage or speed steps depending on how you have the properties set.
--
Peter Ulvestad
JMRI Users Group Moderator - ( )
Tam Valley Group Moderator - ( )
Sprog-DCC Group Moderator - ( )
Edmonton Model Railroad Association -
|
??? Will ask again, has the control panel, on the
throttle been changed from the 0%-50%-100%, etc.?
--
Jon Miller
For me time stopped in 1941
Digitrax Chief/Zephyr systems,
SPROG, JMRI User
NMRA Life member #2623
Member SFRH&MS
|
Locked
Re: Trying to get on top of jython
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@...
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
|
Locked
Re: Decoder Pro problems
Well, maybe the button could say "Read each CV shown on the current screen from the decoder and show the value", "Read each CV shown on the screen from the decoder if any change was made without writing to the decoder", etc.
But that is not a [button], that is a description. And after 3-4 times seeing that, you know what is happening and want the simple 3-word button text back.
Put that as the hover text.
Or sit with a mate who can explain the workings and terminology to you. If you are in Dallas, Texas, drop me a line and I will sit with you.
It takes a bit of study and practice to learn a new system, and not just JMRI.? If it works for thousands of folks, but you have issues...?
I have used this system for years, know the ins and outs of programming, and do not want anything to drastically change. (Still miss the old interface)
'nough said.
Thomas
DeSoto, TX
|
Locked
Re: Decoder Pro problems
Mark Granville said ¡°In? ?JMRI,?¡°Read¡±?means get data from the decoder and put it into the DecoderPro file.?¡°Write¡±?means take data from the DecoderPro file and put it into the decoder. Once you learn that, everything makes sense.?I find the JMRI lingo quite logical and easy to understand. I wouldn¡¯t change it.¡± I agree. I think that the buttons make sense as they are, and always have. ? Mick ________________________________ Mick Moignard m: +44 7774 652504 Skype: mickmoignard
, so please excuse the typos.
|
Locked
Re: Trying to get on top of jython
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
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
Ken Cameron
Peter Ulvestad