From: Bob J. <Bob...@lb...> - 2007-08-29 16:45:31
|
Currently, the jmri.jar in our distributions does _not_ include debug information. This means when we get a stack trace from somebody, it tends to look like: >java.lang.NullPointerException > at jmri.util.JmriJFrame.getMaximumSize (Unknown Source) > at jmri.util.JmriJFrame.getPreferredSize (Unknown Source) > at java.awt.Window.pack (Window.java:272) > at apps.SplashWindow.SplashWindow (Unknown Source) > at apps.Apps.splash (Unknown Source) > at apps.DecoderPro.DecoderPro.main (Unknown Source) > at java.lang.VirtualMachine.invokeMain (VirtualMachine.java) > at java.lang.VirtualMachine.main (VirtualMachine.java:108) with the "Unknown Source" instead of file and line numbers. We can usually tell the file name (from the page name), but I often find I wish I knew what line number was involved. Of course, I can mail the user a jmri.jar file with debug info included, but that takes time, can cause confusion, etc. Should we start distributing JMRI with debug information in jmri.jar? I just did a head-of-CVS build and found that the jmri.jar file without debugging was 2567756 bytes (2.568MB), and with debug was 3189273 bytes (3.189MB), for a difference of 631kB. I doubt this will compress very much, so let's assume that would be the increase in size of a distribution. It ends up being about 10%. A _long_ time ago, we were concerned that the debug information significantly slowed the startup. On my laptop, that no longer seems to be a large effect. (If it's there are all, it's less than 0.2 seconds at 90% confidence level according to some tests) It's easy to change the build scripts to use either "ant compile" or "ant debug", so what do people prefer for 9.1.1 and later? Bob -- Bob Jacobsen, UC Berkeley jac...@be... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG |
From: Dave F. <fa...@ma...> - 2007-08-29 18:38:34
|
I vote to ship with debugging on all the time... :-) - Dave On Aug 29, 2007, at 9:34 AM, Bob Jacobsen <Bob...@lb...> wrote: > Currently, the jmri.jar in our distributions does _not_ include debug > information. This means when we get a stack trace from somebody, it > tends to look like: > >> java.lang.NullPointerException >> at jmri.util.JmriJFrame.getMaximumSize (Unknown Source) >> at jmri.util.JmriJFrame.getPreferredSize (Unknown Source) >> at java.awt.Window.pack (Window.java:272) >> at apps.SplashWindow.SplashWindow (Unknown Source) >> at apps.Apps.splash (Unknown Source) >> at apps.DecoderPro.DecoderPro.main (Unknown Source) >> at java.lang.VirtualMachine.invokeMain (VirtualMachine.java) >> at java.lang.VirtualMachine.main (VirtualMachine.java:108) > > with the "Unknown Source" instead of file and line numbers. We can > usually tell the file name (from the page name), but I often find I > wish I knew what line number was involved. > > Of course, I can mail the user a jmri.jar file with debug info > included, but that takes time, can cause confusion, etc. > > Should we start distributing JMRI with debug information in jmri.jar? > > I just did a head-of-CVS build and found that the jmri.jar file > without debugging was 2567756 bytes (2.568MB), and with debug was > 3189273 bytes (3.189MB), for a difference of 631kB. I doubt this > will compress very much, so let's assume that would be the increase > in size of a distribution. It ends up being about 10%. > > A _long_ time ago, we were concerned that the debug information > significantly slowed the startup. On my laptop, that no longer seems > to be a large effect. (If it's there are all, it's less than 0.2 > seconds at 90% confidence level according to some tests) > > It's easy to change the build scripts to use either "ant compile" or > "ant debug", so what do people prefer for 9.1.1 and later? > > Bob > -- > Bob Jacobsen, UC Berkeley > jac...@be... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype > JacobsenRG > > --- > ---------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Jmri-developers mailing list > Jmr...@li... > https://lists.sourceforge.net/lists/listinfo/jmri-developers |
From: Ken C. <kca...@st...> - 2007-08-29 19:18:51
|
I don't know how much it would complicate the distribution, but I'd say both might be in order. Either something like the 'production' version doesn't include the debug but the 'test' versions always include the debug. Then an additional step would be to offer both of those 'with or without' and let the user pick which they want. Main idea is that if somebody runs into an error, they could download with the debug version but not have to deal with it the rest of the time. I'd also say to have some folk with the older or slower systems to see what the difference is on their systems between the debug and without. Then we could craft the 'main' with the appropriate version that fits 'most' people. If the data supports that only minor differences in speed between the two, then go with debug all the time. -ken cameron Syracuse Model Railroad Club http://www.syrmodelrr.org/ CNY Model Railroad Club http://www.cnymrrc.com/ mailto: kca...@st... |
From: Dave F. <fa...@ma...> - 2007-08-30 05:04:19
|
On Aug 29, 2007, at 12:18 PM, Ken Cameron wrote: > Main idea is that if somebody runs into an error, they could download > with the debug version but not have to deal with it the rest of the > time. This was my original thought as well, but given the general nature of most of the bugs we see, do you really think the "average user" of JMRI is going to be able to handle swapping in a new jar file? Perhaps test versions always have debugging, and "production" versions, which are few and far between lately get built with only "INFO" level messages & debug info. -Dave |
From: Daniel B. <dab...@ho...> - 2007-08-29 20:08:03
|
My vote would be for debug on for non-production releases, and debug off for production. My assumption is that the production release is more stable, would run faster and would also take less space. And that our interim releases might have a bug or two that might need fixing, so the debug info would be helpful. :) If we're voting on things, I still would like to see "info" messages enabled in our releases. I'll even go though all of the code and clean up any info messages that don't meet the standard of being useful and understandable to the end user. Dan -----Original Message----- From: jmr...@li... [mailto:jmr...@li...] On Behalf Of Bob Jacobsen Sent: Wednesday, August 29, 2007 12:35 PM To: jmr...@li... Subject: [Jmri-developers] Distribute JMRI with debug info in jmri.jar? Currently, the jmri.jar in our distributions does _not_ include debug information. This means when we get a stack trace from somebody, it tends to look like: >java.lang.NullPointerException > at jmri.util.JmriJFrame.getMaximumSize (Unknown Source) > at jmri.util.JmriJFrame.getPreferredSize (Unknown Source) > at java.awt.Window.pack (Window.java:272) > at apps.SplashWindow.SplashWindow (Unknown Source) > at apps.Apps.splash (Unknown Source) > at apps.DecoderPro.DecoderPro.main (Unknown Source) > at java.lang.VirtualMachine.invokeMain (VirtualMachine.java) > at java.lang.VirtualMachine.main (VirtualMachine.java:108) with the "Unknown Source" instead of file and line numbers. We can usually tell the file name (from the page name), but I often find I wish I knew what line number was involved. Of course, I can mail the user a jmri.jar file with debug info included, but that takes time, can cause confusion, etc. Should we start distributing JMRI with debug information in jmri.jar? I just did a head-of-CVS build and found that the jmri.jar file without debugging was 2567756 bytes (2.568MB), and with debug was 3189273 bytes (3.189MB), for a difference of 631kB. I doubt this will compress very much, so let's assume that would be the increase in size of a distribution. It ends up being about 10%. A _long_ time ago, we were concerned that the debug information significantly slowed the startup. On my laptop, that no longer seems to be a large effect. (If it's there are all, it's less than 0.2 seconds at 90% confidence level according to some tests) It's easy to change the build scripts to use either "ant compile" or "ant debug", so what do people prefer for 9.1.1 and later? Bob -- Bob Jacobsen, UC Berkeley jac...@be... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Jmri-developers mailing list Jmr...@li... https://lists.sourceforge.net/lists/listinfo/jmri-developers |
From: <pau...@ac...> - 2007-08-30 02:15:26
|
Hi Bob, On 29 Aug, Bob Jacobsen wrote: > Currently, the jmri.jar in our distributions does _not_ include debug > information. This means when we get a stack trace from somebody, it > tends to look like: [snip] > Should we start distributing JMRI with debug information in jmri.jar? [snip] > A _long_ time ago, we were concerned that the debug information > significantly slowed the startup. On my laptop, that no longer seems > to be a large effect. (If it's there are all, it's less than 0.2 > seconds at 90% confidence level according to some tests) My general preference, and I believe the preference of most software engineers, is to NEVER release code with debugging information turned on. I've seen "debug release code" placed into commercial production environments lead to really ugly results.... I haven't checked to see how the java compiler and the jvm interact in this instance, but here are the thoughts I have... If all the compiler is doing is adding symbols to the file so that line numbers can be printed, then that may be ok. There still may be some performance degradation however, particularly on older systems If the compiler changes how it optimizes code based on whether or not debugging is on or off, the code may behave differently in each situation. This can lead to some really strange results Perhaps what we can do is tell the compiler to generate partial debugging information. That would reduce amount of debugging information, but still give us a better clue as to where things are going wrong. Paul -- ______________________________________________________________________________ "Quality is a Characteristic of thought and statement that is recognized by a nonthinking process. Because definitions are a product of rigid formal thinking, quality cannot be defined." Robert M. Pirsig Zen and The Art of Motorcycle Maintenance |
From: Dick B. <di...@rr...> - 2007-08-31 02:51:46
|
Bob, Dave, and anyone else interested, I have posted several files on my web site for some developer comments. (no links yet except from this e-mail) The content of the Sounds.zip file is not for public release as yet, and at least two or three of them will need to be updated first. However they give you the general idea. The new sound files go into your "sounds" folder where you would expect them. The image "traffic.gif" goes into the "...\JMRI\resources\icons\USS\background\ folder along with the panel backgrounds because I didn't know where else to put it. The file "PP-07-Clinic-10.xml" of course goes with your other panels. This demo should be run with the LocoNet Simulator so as to not mess with a real layout. The two images show a mock-up of an idea that I need the comments and help with. The files: http://www.rr-cirkits.com/Clinics/Sounds.zip http://www.rr-cirkits.com/Clinics/traffic.gif http://www.rr-cirkits.com/Clinics/PP-07-Clinic-10.xml http://www.rr-cirkits.com/Clinics/CTC-L-6.png http://www.rr-cirkits.com/Clinics/CTC-R-10.png The idea is to have a CTC Wizard that will show an empty set of input fields per these example images. Following the plan of SSL input I think I could get that far. However what is then needed is that these input values get translated into a set of Logix and Route entries. At this point in the process I have the feeling that it is beyond my abilities. The values are mostly related to the internal sensors used to create the panel interface, and the numbers that I have used in the examples are based on the plate numbers used for the location of the various icons. The graphical part of the Wizard screens is purely intended to give visual hints to the user, and not intended to be 'live' nor to show any actual information. The "left/right" radio button just switches the screen to match the direction of the plant that the user is currently entering. I did not include any fields for creating the linking Logix for driving turnouts or receiving sensor inputs. It would be helpful and probably should also be included, but it is also easy to explain how to do it for different systems. If anyone wants to tackle this project I would be glad to edit my mock up to include the extra fields. There are no direct links from the panel images to or from the layout due to the delays required for code unit sounds. (except for the turnout track image) I have experienced some sound glitches during operation. Sometimes when you press a code button it doesn't click properly, and also occasionally the code unit does not play when it should. Is this a known problem when playing sounds from Logix? Maybe I should have made an individual Logix for clicking each code button rather than one for all. ....I just did that change, and it helps, and it should be easier for the Wizard as well. As best as I currently understand the classic USS CTC panel, this example follows its operation quite closely. One thing I did not do was to serialize the code commands. It would have added a lot of complexity and increased the delays to the point of frustration on a model RR. Instead it just plays the sounds as if each plant had its own dedicated code line instead of a single line for everything per the prototype. (the result is that you can create a lot more clattering than the prototype ever did) <g> The 'time' feature for changing a signal indication in the face of a train is set to just 10 seconds in this demo. In actual operation it needs to be 20% longer than the time required for a train to pass through a block from one signal to the next. Am I on the right track, or is someone else working on a simpler solution? All I know is that manually creating all the Logix required for this job is not something for newbies to tackle. Dick :) |
From: Dave F. <fa...@ma...> - 2007-08-31 04:24:29
|
On Aug 30, 2007, at 7:51 PM, Dick Bronson wrote: > Am I on the right track, or is someone else working on a simpler > solution? All I know is that manually creating all the Logix required > for this job is not something for newbies to tackle. I think this looks great! BTW: I'm in the process of making some new detailed graphics for building a US&S-like panel. When I'm complete, I'll contribute them-- I'm trying to use some "real world" examples from our club layout to prove out the diagrams & controls. -Dave |
From: Bob J. <Bob...@lb...> - 2007-08-31 05:00:29
|
Very, very nice stuff! There's the beginnings of the code in jmri.jmrit.ussctc for creating objects that use Routes & Logix to do various CTC components. I haven't gotten anywhere useful on creating a user interface, but there is some useful code there for going back and forth from Routes & Logix to objects. This might be useful in implementing the underlying logic for your GUI. Basically, the idea is that there's a class representing something that knows how to behave. You can configure it by e.g. telling it what sensors and turnouts to use, and you can query that configuration to get information for a GUI. But objects of that class really only exist to make it convenient to do that configuration; the actual performance, including loading and storing, is done after the objects have been transformed into Route and/or Logix object(s). The first example of this was sensor groups. If you create a sensor group, and then store it in a panel file, you won't see anything in the file that looks like a single sensor group object. The sensor group is actually a coherent set of Route objects, and that's what's stored When you later query that sensor group, the code goes out and finds the related Routes, sucks information out of them, and presents it to you. If you change and store it, updated Route objects are created. Etc. I haven't looked at your Logix, etc, and unfortunately won't have time until late this weekend. Are there logical "chunks" to it, e.g. maybe a "Logix runnign turnout lever 3", "Route handling code sound 4", etc? If so, maybe we could collaborate by you defining the Logix/Route contents for those, and me writing the code to load/store it, and then you working on the GUI? I'm happy to write code to create and manipulate Routes and Logix, because I have a lot of that stuff in my notebook already. Bob At 10:51 PM -0400 8/30/07, Dick Bronson wrote: >Bob, Dave, and anyone else interested, >I have posted several files on my web site for some developer comments. >(no links yet except from this e-mail) The content of the Sounds.zip >file is not for public release as yet, and at least two or three of them >will need to be updated first. However they give you the general idea. >The new sound files go into your "sounds" folder where you would expect >them. The image "traffic.gif" goes into the >"...\JMRI\resources\icons\USS\background\ folder along with the panel >backgrounds because I didn't know where else to put it. The file >"PP-07-Clinic-10.xml" of course goes with your other panels. This demo >should be run with the LocoNet Simulator so as to not mess with a real >layout. The two images show a mock-up of an idea that I need the >comments and help with. > >The files: >http://www.rr-cirkits.com/Clinics/Sounds.zip >http://www.rr-cirkits.com/Clinics/traffic.gif >http://www.rr-cirkits.com/Clinics/PP-07-Clinic-10.xml >http://www.rr-cirkits.com/Clinics/CTC-L-6.png >http://www.rr-cirkits.com/Clinics/CTC-R-10.png > >The idea is to have a CTC Wizard that will show an empty set of input >fields per these example images. Following the plan of SSL input I think >I could get that far. However what is then needed is that these input >values get translated into a set of Logix and Route entries. At this >point in the process I have the feeling that it is beyond my abilities. >The values are mostly related to the internal sensors used to create the >panel interface, and the numbers that I have used in the examples are >based on the plate numbers used for the location of the various icons. >The graphical part of the Wizard screens is purely intended to give >visual hints to the user, and not intended to be 'live' nor to show any >actual information. The "left/right" radio button just switches the >screen to match the direction of the plant that the user is currently >entering. I did not include any fields for creating the linking Logix >for driving turnouts or receiving sensor inputs. It would be helpful and >probably should also be included, but it is also easy to explain how to >do it for different systems. If anyone wants to tackle this project I >would be glad to edit my mock up to include the extra fields. There are >no direct links from the panel images to or from the layout due to the >delays required for code unit sounds. (except for the turnout track image) > >I have experienced some sound glitches during operation. Sometimes when >you press a code button it doesn't click properly, and also occasionally >the code unit does not play when it should. Is this a known problem when >playing sounds from Logix? Maybe I should have made an individual Logix >for clicking each code button rather than one for all. ....I just did >that change, and it helps, and it should be easier for the Wizard as well. > >As best as I currently understand the classic USS CTC panel, this >example follows its operation quite closely. One thing I did not do was >to serialize the code commands. It would have added a lot of complexity >and increased the delays to the point of frustration on a model RR. >Instead it just plays the sounds as if each plant had its own dedicated >code line instead of a single line for everything per the prototype. >(the result is that you can create a lot more clattering than the >prototype ever did) <g> > >The 'time' feature for changing a signal indication in the face of a >train is set to just 10 seconds in this demo. In actual operation it >needs to be 20% longer than the time required for a train to pass >through a block from one signal to the next. > >Am I on the right track, or is someone else working on a simpler >solution? All I know is that manually creating all the Logix required >for this job is not something for newbies to tackle. > >Dick :) > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. >Still grepping through log files to find problems? Stop. >Now Search log events and configuration files using AJAX and a browser. >Download your FREE copy of Splunk now >> http://get.splunk.com/ >_______________________________________________ >Jmri-developers mailing list >Jmr...@li... >https://lists.sourceforge.net/lists/listinfo/jmri-developers -- Bob Jacobsen, UC Berkeley jac...@be... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG |
From: Dick B. <di...@rr...> - 2007-08-31 14:15:38
|
Bob, Thank you. As usual, laziness is the true mother of invention. I have clinics to present and a 60 position and 30 position panel to create. A tool seems like the best way out. The other option is cut and paste with consistent changes. The Logix and Routes are already fairly atomic, and I can surely improve some on that. I have already commented on two improvements of that nature, making the click for each code button into a separate Logix, and re-doing the system names. Following your suggestion I will work to make them even more distinct and formatted. Your offer to do the code for translating back and forth is just what I was hoping for. If I spent the next year on it, I could probably come up with a rough draft of what is already in your notebook. <VBG> I was calling it a 'Wizard' because I originally didn't even visualize it being able to suck data back out of the Routes and Logix to edit things, but that capability would be icing on the cake, and upgrade it to "Simple CTC Logic". I realize that the interface also needs to identify a switch # as well as a plant #, because on the real world panels they did not always line up directly one above the other. That also is required info when naming the Logix and Routes systematically. I am still undecided on the automatic addition of the layout sensor to panel indicator Logix. It is a many to one relationship, because the 'intermediate' block may actually be formed from a random number of signal blocks logically ORed together. Also it does not correspond cleanly to one plant. In fact each sensor indicator is used in two different plants. I think it is best dealt with separately. Dick :) Bob Jacobsen wrote: > Very, very nice stuff! > > There's the beginnings of the code in jmri.jmrit.ussctc for creating > objects that use Routes & Logix to do various CTC components. I > haven't gotten anywhere useful on creating a user interface, but > there is some useful code there for going back and forth from Routes > & Logix to objects. This might be useful in implementing the > underlying logic for your GUI. > > Basically, the idea is that there's a class representing something > that knows how to behave. You can configure it by e.g. telling it > what sensors and turnouts to use, and you can query that > configuration to get information for a GUI. But objects of that > class really only exist to make it convenient to do that > configuration; the actual performance, including loading and storing, > is done after the objects have been transformed into Route and/or > Logix object(s). > > The first example of this was sensor groups. If you create a sensor > group, and then store it in a panel file, you won't see anything in > the file that looks like a single sensor group object. The sensor > group is actually a coherent set of Route objects, and that's what's > stored When you later query that sensor group, the code goes out and > finds the related Routes, sucks information out of them, and presents > it to you. If you change and store it, updated Route objects are > created. Etc. > > I haven't looked at your Logix, etc, and unfortunately won't have > time until late this weekend. Are there logical "chunks" to it, e.g. > maybe a "Logix runnign turnout lever 3", "Route handling code sound > 4", etc? If so, maybe we could collaborate by you defining the > Logix/Route contents for those, and me writing the code to load/store > it, and then you working on the GUI? > > I'm happy to write code to create and manipulate Routes and Logix, > because I have a lot of that stuff in my notebook already. > > Bob > > <snip> |
From: Dick B. <di...@rr...> - 2007-08-31 05:48:13
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi,<br> If anyone has already downloaded:<br> <blockquote><a class="moz-txt-link-freetext" href="http://www.rr-cirkits.com/Clinics/PP-07-Clinic-10.xml">http://www.rr-cirkits.com/Clinics/PP-07-Clinic-10.xml</a> <br> </blockquote> before reading this message, I have updated it with more logical (?) Logix names.<br> <br> Dick :)<br> </body> </html> |
From: Bob J. <Bob...@lb...> - 2007-08-31 13:55:08
|
I was looking at Dick's excellent panel file example <http://www.rr-cirkits.com/Clinics/PP-07-Clinic-10.xml> with a web browser and "show source", and it suddenly occurred to me that we could make it readable using the same XSLT technology as we're now using with decoder files: <http://jmri.sourceforge.net/xml/decoders/BLI_Blueline_diesel.xml> Would this be a good thing to do? (I'm not proposing to make them editable via forms, like the decoder files, but just to format them so they now are readable directly in the browser). "Save as..." will still work, as will the usual download tools, etc. If so, what should they look like? Bob -- Bob Jacobsen, UC Berkeley jac...@be... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG |
From: Dick B. <di...@rr...> - 2007-08-31 16:21:14
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Ken,<br> The multi-sensor icon requires that you target the icon inside of the area where it exists. In practice this means that you need to target just to the right or left of center inside of the lever tip travel. I have gotten used to it, and usually aim for the 'screw' that mounts the plate. (just left or right of it) The code button should immediately move and click, even if it does not do anything else due to conflicts. I did not add any 'click' to the occupancy simulator switches because they would not exist on a real panel. <br> <br> Both the code buttons and levers should have little if any delay before they respond with both sound and motion. It is just the program's response time to the mouse action. I did notice that the lever's actions are on "mouse button up", not "mouse button down" like the code button. Are you using a really slow machine? I find that even if I am in another window (such as this e-mail) when I click there is only a fraction of a second delay before action. I suppose that if the panel has been swapped into cache memory there could be more delay, but there is none at all by design. Of course the responses are all delayed by the code sending and receiving plus any turnout motion.<br> <br> Dick :)<br> <br> Ken Cameron wrote: <blockquote cite="mid:F9F...@sl...NY.local" type="cite"> <meta http-equiv="Content-Type" content="text/html; "> <meta content="MSHTML 6.00.6000.16525" name="GENERATOR"> <div><span class="342114015-31082007"><font color="#0000ff" face="Arial" size="2">Ok, now I've got it working.</font></span></div> <div><span class="342114015-31082007"></span> </div> <div><span class="342114015-31082007"><font color="#0000ff" face="Arial" size="2">But there seems to be either a lot of time where the signal selector doesn't respond (can't move the handle) or the spot you have to click to make the handle move is awful small and I keep missing it. I can see that there's lots of time where hitting the code button wouldn't do anything because of conflicts and timeouts. But I can't even move the handle. The left seems worse than the right on this issue.</font></span></div> <div><span class="342114015-31082007"></span> </div> <div><span class="342114015-31082007"><font color="#0000ff" face="Arial" size="2">-ken c</font></span></div> <br> <hr size="4" width="90%"><br> <table class="header-part1" border="0" cellpadding="0" cellspacing="0" width="100%"> <tbody> <tr> <td> <div class="headerdisplayname" style="display: inline;">Subject: </div> Re: [Jmri-developers] Wizard for Classic CTC panel with sound</td> </tr> <tr> <td> <div class="headerdisplayname" style="display: inline;">From: </div> "Dick Bronson" <a class="moz-txt-link-rfc2396E" href="mailto:di...@rr..."><di...@rr...></a></td> </tr> <tr> <td> <div class="headerdisplayname" style="display: inline;">Date: </div> Fri, 31 Aug 2007 10:50:04 -0400</td> </tr> <tr> <td> <div class="headerdisplayname" style="display: inline;">To: </div> "Ken Cameron" <a class="moz-txt-link-rfc2396E" href="mailto:kca...@st..."><kca...@st...></a></td> </tr> </tbody> </table> <table class="header-part2" border="0" cellpadding="0" cellspacing="0" width="100%"> <tbody> <tr> <td> <div class="headerdisplayname" style="display: inline;">To: </div> "Ken Cameron" <a class="moz-txt-link-rfc2396E" href="mailto:kca...@st..."><kca...@st...></a></td> </tr> </tbody> </table> <br> Ken,<br> The panel should initialize itself with a crash of noise. (presuming you have added the sound files and traffic icon to your resources) All the rest should just work. (using the LocoNet Simulator) Of course you need to know how to run a CTC panel. VBG Turnouts may only be changed when unoccupied and 'Signals Normal' is showing. (red signal lamp) Signals will only show aspects when a traffic direction is set. The corrected version will work better. The error prevented one of the direction levers from working properly.<br> <br> Dick :)<br> <br> <br> Ken Cameron wrote: <blockquote cite="mid:F9F...@sl...NY.local" type="cite"> <meta http-equiv="Content-Type" content="text/html; "> <meta content="MSHTML 6.00.6000.16525" name="GENERATOR"> <div><span class="886383714-31082007"><font color="#0000ff" face="Arial" size="2">That's why I figured it needed posting (the error).</font></span></div> <div><span class="886383714-31082007"></span> </div> <div><span class="886383714-31082007"><font color="#0000ff" face="Arial" size="2">Also were there any instructions for a 'simple walk through' on how to make it do stuff?? I figure it has something to do with the 'occupancy toggles' but what other things need to be 'preset' to get things going??</font></span></div> <div><span class="886383714-31082007"></span> </div> <div><span class="886383714-31082007"><font color="#0000ff" face="Arial" size="2">-ken c</font></span></div> <br> <hr size="4" width="90%"><br> <table class="header-part1" border="0" cellpadding="0" cellspacing="0" width="100%"> <tbody> <tr> <td> <div class="headerdisplayname" style="display: inline;">Subject: </div> Re: [Jmri-developers] Wizard for Classic CTC panel with sound</td> </tr> <tr> <td> <div class="headerdisplayname" style="display: inline;">From: </div> "Dick Bronson" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:di...@rr..."><di...@rr...></a></td> </tr> <tr> <td> <div class="headerdisplayname" style="display: inline;">Date: </div> Fri, 31 Aug 2007 10:34:04 -0400</td> </tr> <tr> <td> <div class="headerdisplayname" style="display: inline;">To: </div> "Ken Cameron" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:kca...@st..."><kca...@st...></a></td> </tr> </tbody> </table> <table class="header-part2" border="0" cellpadding="0" cellspacing="0" width="100%"> <tbody> <tr> <td> <div class="headerdisplayname" style="display: inline;">To: </div> "Ken Cameron" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:kca...@st..."><kca...@st...></a></td> </tr> </tbody> </table> <br> Ken,<br> Just testing to see who really tried it out. <g> Just kidding. The -871 was my bad! I use a dual monitor system, and I was editing and saving the panel on my left screen. The IX1C7 error was due to an incomplete find and replace operation when I redid the Logix names. Hopefully both errors have been corrected in the version currently posted. At least you knew how to fix the position error. <g> The naming error would have been harder to figure out.<br> <br> Dick :)<br> <br> Ken Cameron wrote: <blockquote cite="mid:F9F...@sl...NY.local" type="cite"> <meta http-equiv="Content-Type" content="text/html; "> <meta content="MSHTML 6.00.6000.16525" name="GENERATOR"> <div><span class="954430512-31082007"><font color="#0000ff" face="Arial" size="2">Found that the panel X was a -871 which moved it right off my display. I couldn't find a better way to get it back other than to edit the xml and change the value.</font></span></div> <div><span class="954430512-31082007"></span> </div> <div><span class="954430512-31082007"><font color="#0000ff" face="Arial" size="2">Also got the following error from the load:</font></span></div> <div><span class="954430512-31082007"></span> </div> <div><span class="954430512-31082007"><font color="#0000ff" face="Arial" size="2">0 jmri.DefaultLogix ERROR - Bad system name for conditional "IX1C7" when setting up Logix listener [AWT-EventQueue-0]</font></span></div> <div><span class="954430512-31082007"></span> </div> <div><span class="954430512-31082007"></span> </div> <div><span class="954430512-31082007"><!-- Converted from text/plain format --> <p><font size="2">-ken cameron<br> Syracuse Model Railroad Club <a moz-do-not-send="true" href="http://www.syrmodelrr.org/">http://www.syrmodelrr.org/</a><br> CNY Model Railroad Club <a moz-do-not-send="true" href="http://www.cnymrrc.com/">http://www.cnymrrc.com/</a><br> mailto: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:kca...@st...">kca...@st...</a></font> </p> </span></div> <br> <hr size="4" width="90%"><br> <table class="header-part1" border="0" cellpadding="0" cellspacing="0" width="100%"> <tbody> <tr> <td> <div class="headerdisplayname" style="display: inline;">Subject: </div> Re: [Jmri-developers] Wizard for Classic CTC panel with sound</td> </tr> <tr> <td> <div class="headerdisplayname" style="display: inline;">From: </div> "Dick Bronson" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:di...@rr..."><di...@rr...></a></td> </tr> <tr> <td> <div class="headerdisplayname" style="display: inline;">Date: </div> Thu, 30 Aug 2007 23:58:25 -0400</td> </tr> <tr> <td> <div class="headerdisplayname" style="display: inline;">To: </div> <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:di...@rr..."><di...@rr...></a>, "Discussions about changes to the code; design, intent, etc" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:jmr...@li..."><jmr...@li...></a></td> </tr> </tbody> </table> <table class="header-part2" border="0" cellpadding="0" cellspacing="0" width="100%"> <tbody> <tr> <td> <div class="headerdisplayname" style="display: inline;">To: </div> <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:di...@rr..."><di...@rr...></a>, "Discussions about changes to the code; design, intent, etc" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:jmr...@li..."><jmr...@li...></a></td> </tr> </tbody> </table> <br> Hi,<br> If anyone has already downloaded:<br> <blockquote><a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.rr-cirkits.com/Clinics/PP-07-Clinic-10.xml">http://www.rr-cirkits.com/Clinics/PP-07-Clinic-10.xml</a> <br> </blockquote> before reading this message, I have updated it with more logical (?) Logix names.<br> <br> Dick :)<br> </blockquote> <br> </blockquote> <br> </blockquote> <br> </body> </html> |
From: Bob J. <Bob...@lb...> - 2007-09-02 20:04:44
|
At 10:24 PM -0400 8/29/07, pau...@ac... wrote: >If all the compiler is doing is adding symbols to the file so that line >numbers can be printed, then that may be ok. The compiler's -g option only adds information, it doesn't change the generated bytecodes. What we call "debug" in the ant build.xml file is the default: Info about files, lines and local variables. >There still may be some >performance degradation however, particularly on older systems True, but only at load time as I understand it. At 4:08 PM -0400 8/29/07, Daniel Boudreau wrote: >My vote would be for debug on for non-production releases, and debug off for >production. My assumption is that the production release is more stable, >would run faster and would also take less space. And that our interim >releases might have a bug or two that might need fixing, so the debug info >would be helpful. :) I think this is a good idea. We might turn it off for the "last test release" before a production release, just to see if there are any effects once in the wild, but that's a question for the future. Bob -- Bob Jacobsen, UC Berkeley jac...@be... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG |