Re: [Flightgear-devel] [PATCH] overflow in Instrumentation/gps.cxx
On Friday 02 January 2009 18:32:58 Csaba Halász wrote:
0x007e1c50 in GPS::updateTTWNode (this=0xce164c0,
c...@0x7fff664fdee0, distance_m=12822604.584446406,
no...@0x7fff664fddd0) at src/Instrumentation/gps.cxx:483
483 unsigned int TTW_seconds = (int) (TTW + 0.5);
(gdb) p TTW
$10 = 62278235905.950584
Not sure what it is calculating anyway. This happened with the
hurricane just at startup.
And all the while loops look silly too.
Please apply this patch to extract the hours minutes and seconds without using
silly while loops.
--
Roy Vegard Ovesen
diff --git a/src/Instrumentation/gps.cxx b/src/Instrumentation/gps.cxx
index 913aba7..424ed3e 100644
--- a/src/Instrumentation/gps.cxx
+++ b/src/Instrumentation/gps.cxx
@@ -485,14 +485,9 @@ GPS::updateTTWNode(UpdateContext ctx, double distance_m, SGPropertyNode_ptr nod
unsigned int TTW_minutes = 0;
unsigned int TTW_hours = 0;
char TTW_str[9];
- while (TTW_seconds = 3600) {
-TTW_seconds -= 3600;
-TTW_hours++;
- }
- while (TTW_seconds = 60) {
-TTW_seconds -= 60;
-TTW_minutes++;
- }
+ TTW_hours = TTW_seconds / 3600;
+ TTW_minutes = (TTW_seconds / 60) % 60;
+ TTW_seconds = TTW_seconds % 60;
snprintf(TTW_str, 9, %02d:%02d:%02d,
TTW_hours, TTW_minutes, TTW_seconds);
node-setStringValue(TTW_str);
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] overflow in Instrumentation/gps.cxx
On 3 Jan 2009, at 13:17, Roy Vegard Ovesen wrote: Please apply this patch to extract the hours minutes and seconds without using silly while loops. Thanks (and I will apply this!), but to re-iterate, I have a re-write of the entire GPS code pending - but I'm holding off committing until the 1.9.x issue is decided, since my changes will require updates to panel instruments. So I'd urge people to no to worry unduly about this particular file (or any of the DCLGPS / KLN89 code) Regards, James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dots, degrees and magic '5's
On 2 Jan 2009, at 22:28, Alex Perry wrote: No. The standard design is based around 3 degrees slope. With that design, the usable range is 1.4 degrees high, from 2.1 to 3.7 degrees and offers 0.35 degrees per dot. Therefore, a dot equals 50ft per mile range from the touchdown zone of the runway. When the standard design is scaled for terrain or other approach spaces, all that is modified is where the antenna array has the intensity maximuma. Consequently all those numbers grow by up to 8% or shrink by up to 16%. From the point of view of implementation in a simulator, just take the actual slope number for a specific runway and combine that with the aircraft's position to generate a ratio. Repair the ratio to allow for the side lobes (which as I recall are the standard series with a negative at 6 and one you can follow at 9). Then pass that ratio to the instrument implementation. The instrument should probably show full scale from 0.6 to 1.4 with center at 1.0 and dots at 0.77 0.88 1.11 1.23 Okay, trying to steer this back to things I have more of a handle on: - everyone seems agreed that the GS is a 1.4 degree volume, so 0.7 degrees above and below the GS line. And the '0.35' degrees per dot comes up, which basically implies 2 dots from the center line to the 0.7 degree limit. Referring back to the ICAO docs that John Denker posted, and the Mk-VIII manual, which says 0.0875 DDM per dot on the GS, and the ICAO docs say the GS 'sector' is 0.175, and the half- sector is 0.0875. I.e two 'dots' would be the very edge of the sector (0.175 DDM). This is important because the 'soft' alert limit is defined as 1.3 dots, and the hard limit is 2 dots. Which again makes sense, and brings us back to the fact that most high-end GS indicators (Primus, Honeywell/ Boeing) use two dots either side for the indicator. So my inclination is to add the degrees deviation properties as discussed, and to avoid 'dots' in the navradio code, but to add - ddm properties. Obviously I won't touch the existing 'deflection' properties, but I hope over time they'll rot. For the Mk-VIII, I'll convert to 'dots' using the terms defined in the INSTALL manual, which of course match the ICAO 'half-sector' values exactly. I'm not sure where all of this leaves Syd, or other panel designers. Working in DDM seems a little awkward, unless we define the maximum deflection as a property (entirely possible) or provide a normalised version (also entirely possible). A normalised version would probably be the easiest thing to use in simple displays (like in the current C172) but also in glass displays. Comments? James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dots, degrees and magic '5's
On 01/03/2009 06:58 AM, James Turner wrote: - everyone seems agreed that the GS is a 1.4 degree volume, so 0.7 degrees above and below the GS line. I concur. And the '0.35' degrees per dot comes up, which basically implies 2 dots from the center line to the 0.7 degree limit. Sorry, no. Here's a counterexample: http://www.aircraftspruce.com/catalog/graphics/11-05106.gif Referring back to the ICAO docs that John Denker posted, and the Mk-VIII manual, which says 0.0875 DDM per dot on the GS, and the ICAO docs say the GS 'sector' is 0.175, and the half- sector is 0.0875. Please let's not confuse ICAO (which is quite general) with Mk-VIII (which is just one instrument). I.e two 'dots' would be the very edge of the sector (0.175 DDM). This is important because the 'soft' alert limit is defined as 1.3 dots, and the hard limit is 2 dots. Which again makes sense, and brings us back to the fact that most high-end GS indicators (Primus, Honeywell/ Boeing) use two dots either side for the indicator. Please let's write code that works for all instruments, not most instruments or most high-end instruments. So my inclination is to add the degrees deviation properties as discussed, and to avoid 'dots' in the navradio code, Yes, dots are to be avoided. Anything involving dots is just begging to be misunderstood. While we're on the subject: It is good practice to spell out what is meant by full scale. It could be either center-to-side or side-to-side. (I've made this mistake myself :-) Talking about 1.4 degrees full sector (peg to peg) seems reasonably convenient and unambiguous. Also talking about an interval in the form [0 ± 0.7] is unambiguous. but to add - ddm properties. DDM? I can't imagine why anyone would want to mess with that level of detail. Deflection as a fraction of full sector is all any Sim World instrument designer needs. Maybe once in ten years somebody should check that the full-sector width is what we think it is, but that's been done now. Obviously I won't touch the existing 'deflection' properties, but I hope over time they'll rot. I think they're just fine. I don't see any need for additional complexity. If it ain't broke, don't fix it. For the Mk-VIII, I'll convert to 'dots' using the terms defined in the INSTALL manual, which of course match the ICAO 'half-sector' values exactly. Since the deflection values are exact, why not use them? I'm not sure where all of this leaves Syd, or other panel designers. Working in DDM seems a little awkward, Agreed, awkward and unnecessary. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dots, degrees and magic '5's
On 3 Jan 2009, at 15:04, John Denker wrote: On 01/03/2009 06:58 AM, James Turner wrote: - everyone seems agreed that the GS is a 1.4 degree volume, so 0.7 degrees above and below the GS line. I concur. Please let's not confuse ICAO (which is quite general) with Mk-VIII (which is just one instrument). Please let's write code that works for all instruments, not most instruments or most high-end instruments. Understood, see below... So my inclination is to add the degrees deviation properties as discussed, and to avoid 'dots' in the navradio code, Yes, dots are to be avoided. Anything involving dots is just begging to be misunderstood. Right :) DDM? I can't imagine why anyone would want to mess with that level of detail. Deflection as a fraction of full sector is all any Sim World instrument designer needs. Maybe once in ten years somebody should check that the full-sector width is what we think it is, but that's been done now. Understood Obviously I won't touch the existing 'deflection' properties, but I hope over time they'll rot. I think they're just fine. I don't see any need for additional complexity. If it ain't broke, don't fix it. No, the *deflection* properties really are broken, because they're in ambiguous units, I think (especially the magic factor-of-5 multiple that started this thread). I am going to add 'deviation-degrees' for both the LOC and GS, and I think that's what should be preferred going forwards, especially once the full-sector is defined - which it seems to be, now. I'd still be inclined to include deviation-norm alongside deviation- deg, i.e just do the divide by full-sector deviation inside the navradio code, since I am sure this would make panel designers much happier. So: /instruments/navradio[n]/heading-deviation-deg: [-10.0 to 10.0 for a VOR, -2.5 to 2.5 for a LOC] (i.e no 'magic 4' multiple for LOCs) /instruments/navradio[n]/heading-deviation-norm: [-1.0 .. 1.0] /instruments/navradio[n]/gs-deviation-deg: [-0.7 to 0.7] /instruments/navradio[n]/gs-deviation-norm: [-1.0 to 1.0] Does this seem reasonable to all concerned? I'm happy to make these changes, and then we can (separately!) consider using John's sensitivity-as-a-function-of-runway-length logic, which seems to be generally agreed as better than the current situation, but which I am profoundly under-qualified to given an opinion upon :) James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dots, degrees and magic '5's
On 01/03/2009 08:34 AM, James Turner wrote: snip Lots of stuff we agree on /snip No, the *deflection* properties really are broken, because they're in ambiguous units, I think (especially the magic factor-of-5 multiple that started this thread). As always, I look at things primarily from the _user_ point of view. We should do what's best for the _users_. They don't care what local units are used to communicate between the tuner and the CDI head. It could be gallons as Torsten mentioned. The existing code uses [0 ± 10] gallons for the left/right needle and [0 ± 3.5] gallons for the up/down needle. The xml instrument designers have come to terms with this. Some comments here and there, documenting this convention, wouldn't hurt. IMHO nothing more than comments is worth bothering with. On the scale of things, this is not broken. There are dozens upon dozens of things far more broken than this. I am going to add 'deviation-degrees' for both the LOC and GS, and I think that's what should be preferred going forwards, especially once the full-sector is defined - which it seems to be, now. Not a great idea, for reasons discussed below, including the fact that it fails miserably for RNAV units. I'd still be inclined to include deviation-norm alongside deviation- deg, i.e just do the divide by full-sector deviation inside the navradio code, since I am sure this would make panel designers much happier. That would make instrument designers much happier, because VOR sensitivity is different from LOC sensitivity, and LOC sensitivity varies from place to place. Real World LOC sensitivity is *not* half a degree per dot, no matter how many non-experts say it is. Also RNAV units drive the left/right needle in units that have nothing to do with degrees. In the Real World, there is an industry standard that is used to communicate from the tuner to the CDI head, namely CDI Left/Right 150 mV into 1K load CDI Up/Down150 mV into 1K load CDI Glide Slope Flag 300 mV into 1K load CDI VOR/LOC Flag 300 mV into 1K load which has never been and cannot be denominated in degrees. Sending degrees to the CDI head is a waste of time. Why do things the hard way when the easy (and almost realistic) way is already implemented? The existing scheme, which puts out a normalized full-scale deflection, is almost realistic and has proven perfectly adequate over the years. The choice of what the normalization constant should be is a private matter between the tuner-designers and the CDI-designers. Fussing over private matters doesn't do the users much good. There are dozens and dozens of bugs that *do* adversely affect real users who really fly the sim ... and IMHO those should get priority. After the real bugs are fixed we can fuss over things users don't see. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dots, degrees and magic '5's
/instruments/navradio[n]/heading-deviation-deg: [-10.0 to 10.0 for a VOR, -2.5 to 2.5 for a LOC] (i.e no 'magic 4' multiple for LOCs) /instruments/navradio[n]/heading-deviation-norm: [-1.0 .. 1.0] /instruments/navradio[n]/gs-deviation-deg: [-0.7 to 0.7] /instruments/navradio[n]/gs-deviation-norm: [-1.0 to 1.0] Does this seem reasonable to all concerned? Yes - allmost. But please don't clamp the xxx-deviation-deg to +/-10.0 or +/-0.7. When I look at my KI525a HSI (real life, not simuland), the glideslope markers move out of sight when I am more than 0.7deg off the center of the glide slope. That will be hard to model when the values are clamped to +/- 0.7. In other words: The glideslope receiver notices deviations of more than 0.7 degrees off center, only the display shows the range of +/-0.7deg. The CDI needle can move a little further out, than the outermost dot on the scale. Here, also the receiver detects offsets of more than 10deg, just the display is limited to full deflection. So my question is: why clamp the xxx-deviation-deg properties at all? Shouldn't it be a duty of the instrument to define where it hits the border? Torsten -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dots, degrees and magic '5's
On 3 Jan 2009, at 16:17, John Denker wrote: They don't care what local units are used to communicate between the tuner and the CDI head. It could be gallons as Torsten mentioned. The existing code uses [0 ± 10] gallons for the left/right needle and [0 ± 3.5] gallons for the up/down needle. The xml instrument designers have come to terms with this. Some comments here and there, documenting this convention, wouldn't hurt. IMHO nothing more than comments is worth bothering with. On the scale of things, this is not broken. There are dozens upon dozens of things far more broken than this. Except that, it caused the GPWS code to misbehave, and I am enough of pedant that I am not prepared to accept an arbitrary scale of gallons just because that's what's gone before. My dislike of magic numbers / units / scales is really quite intense. I understand that from a strictly pragmatic point of view, the easiest thing would be to just do one more magic conversion in the Mk-VIII code, but, yuck. Not a great idea, for reasons discussed below, including the fact that it fails miserably for RNAV units. Well, in the medium term, I have another idea on that front, but I really want to get the GPWS working better, so that's a discussion for another day. For now, let's just say that navradio is a very bad fit for RNAV or GPS units, and that things there will have to change, but not as part of this work. One thing at a time, and all that. The existing scheme, which puts out a normalized full-scale deflection, is almost realistic and has proven perfectly adequate over the years. The choice of what the normalization constant should be is a private matter between the tuner-designers and the CDI-designers. Fussing over private matters doesn't do the users much good. Except it's normalised to these somewhat arbitrary values, so rather than just agreeing on some bad values because they exist, why not add/ migrate to some that actually make sense, and stop people (eg, Syd) guessing what full-range is. I.e, let's just normalise to [-1.0 .. 1.0] and be done with it. (Except, as Torsten just noted, the values can probably go slightly beyond that, since any clamping should be done at the panel-instrument level, not the receiver level). James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dots, degrees and magic '5's
On 01/03/2009 08:49 AM, Torsten Dreyer wrote: So my question is: why clamp the xxx-deviation-deg properties at all? Shouldn't it be a duty of the instrument to define where it hits the border? I completely agree with TD. Currently there is no clamp on the GS deflection in navradio.cxx. The existing clamp on CDI deflection is unrealistic and should be removed IMHO. = BTW t A) The existing navradio implements target radial and actual radial for the azimuth (CDI) which is realistic for some instruments B) It doesn't implement the corresponding things for the glideslope. Is there anything unrealistic about item (B)? Is there any instrument/system in the world that expects the nav tuner to put out the GS angle in degrees? The only MK-VIII known to me is a GPWS, and I very much doubt it needs to know any GS info beyond the usual position within the GS beam as a fraction of the peg-to-peg sector. Is there any realistic market for gs-deg information? Should model instruments depend on info not available to the corresponding RW instruments? -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dots, degrees and magic '5's
On 3 Jan 2009, at 17:12, John Denker wrote: Is there anything unrealistic about item (B)? Is there any instrument/system in the world that expects the nav tuner to put out the GS angle in degrees? The only MK-VIII known to me is a GPWS, and I very much doubt it needs to know any GS info beyond the usual position within the GS beam as a fraction of the peg-to-peg sector. When I write 'Mk -VIII' I was assuming everyone realised I was talking about the GPWS unit, since it's what I'm trying to fix, and the only thing we have with that name in FG. And what it actually uses is mV CDI deflection if driven by analogue volts, or ARINC 429 words expressing DDM. The problem is driving this sensibly from what we have at present from navradio.cxx. If I add a gs-deviation-norm, I'll assume (based on the INSTALL docs for the Mk-VIII, and the ICAO spec) that their 'dots' correspond to the half- and full- sector deviations for both LOC and GS purposes, i.e two dots to full-sector. But that's entirely a problem for me and the GPWS code :) That would be absolutely fine - as you say, the fraction of peg-to-peg is what's needed - but we don't have that at this moment. I greatly dislike working in 'peg-to-peg percentage multiplied by 3.5', which is what we sort of have right now, for the GS, and 'peg to peg multiplied by 10' for the LOC. Especially when people then *think* that those numbers correspond to degrees, when we have pretty clearly established that quite often they do not :) The Mk-VIII is guilty of all of the above - assuming degrees, *and* being oblivious to the factor of 5 multiple. Since the author was clearly not a fool, I don't think better documentation is a 'sufficient' fix, but normalising to -1..1 is. (And letting the actual panel instrument clamp, i.e remove the clamping in navradio.cxx ... but that needs to be done with considerable care, lest we break something) James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dots, degrees and magic '5's
On 01/03/2009 10:04 AM, James Turner wrote: I.e, let's just normalise to [-1.0 .. 1.0] and be done with it. (Except, as Torsten just noted, the values can probably go slightly beyond that, since any clamping should be done at the panel-instrument level, not the receiver level). OK So A) We are now agreed that deflection as a fraction of full scale is a supported feature, not deprecated, not scheduled to rot, right? B) The proposal is to add a new output, just like the old output, but with a different normalization factor. That's the main point of this thread, right? C) The old oddly-normalized output will continue to be supported for the foreseeable future, since is doesn't interfere with new features and preserves compatible interoperation with older CDIs, right? D) Lesser points include: -- Outputs should not be clamped by the tuner. Each CDI head may choose to peg the needles, or not, in its own way. -- Localizer sensitivity is runway-dependent. -- Dozens of other navradio.cxx bugs as discussed elsewhere. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dots, degrees and magic '5's
On 3 Jan 2009, at 17:38, John Denker wrote: A) We are now agreed that deflection as a fraction of full scale is a supported feature, not deprecated, not scheduled to rot, right? Err, I would say that we don't have that as a current feature, but I think that's getting into semantics of what 'normalised' means, and my opinion as a graphics coder may be different to an engineering meaning. Anyway, there is certainly no way (even if it was desired) of getting rid of heading-deflection or gs-deflection, and they have to continue to work. B) The proposal is to add a new output, just like the old output, but with a different normalization factor. That's the main point of this thread, right? At this point, I think so. There's code that would be simpler if it could talk about degrees deviation rather than peg-to-peg percentage (eg, all the autopilots that 'capture with 0.5 degrees (or whatever)' of the localiser) but I think a degree based definition will always be troublesome. Clearly real world autopilots know about a signal from the navradio, not real degrees, so when the manual specifies a value in degrees they're applying some approximate conversion factor. C) The old oddly-normalized output will continue to be supported for the foreseeable future, since is doesn't interfere with new features and preserves compatible interoperation with older CDIs, right? Yep, sadly that's too far baked in to be removed at this point, at least for the amount of effort required. D) Lesser points include: -- Outputs should not be clamped by the tuner. Each CDI head may choose to peg the needles, or not, in its own way. Yep, but someone needs to verify what the fallout of such a change might be. -- Localizer sensitivity is runway-dependent. -- Dozens of other navradio.cxx bugs as discussed elsewhere. Indeed, but again not the core thing I'm worrying about here. James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] overflow in Instrumentation/gps.cxx
On Sat, Jan 3, 2009 at 2:30 PM, James Turner zakal...@mac.com wrote: On 3 Jan 2009, at 13:17, Roy Vegard Ovesen wrote: Please apply this patch to extract the hours minutes and seconds without using silly while loops. Thanks (and I will apply this!) But you credited it to the wrong person ... -- Csaba/Jester -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] overflow in Instrumentation/gps.cxx
On 3 Jan 2009, at 18:10, Csaba Halász wrote: But you credited it to the wrong person ... Ooops, yes. Apologies to Roy and Ron for the confusion. (I could make a poor excuse about names that start 'Ro-' and end with '-sen', but I think I'd be laughed at) James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [BUG] overflow in Network/native_fdm.cxx
Program received signal SIGFPE, Arithmetic exception. 0x00894c9f in FGProps2NetFDM (net=0xc5601e8, net_byte_order=false) at src/Network/native_fdm.cxx:183 183 net-oil_px[i] = node-getDoubleValue( oil-pressure-psi ); Value of oil-pressure-psi is 1.4350219318567242e+73 which is probably a bug in itself. (Using: --aircraft=737-300 --airport=KHWD) However lot of double-float conversions in other places as well, such as: 0x00a75d3b in SGPropertyNode::getFloatValue (this=0xb6d7e20) at simgear/props/props.cxx:1163 1163return float(get_double()); Do we have some policy what the correct behavior in these cases should be? -- Csaba/Jester -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dots, degrees and magic '5's
On Sat, Jan 3, 2009 at 7:49 AM, Torsten Dreyer tors...@t3r.de wrote: /instruments/navradio[n]/heading-deviation-deg: [-10.0 to 10.0 for a VOR, -2.5 to 2.5 for a LOC] (i.e no 'magic 4' multiple for LOCs) /instruments/navradio[n]/heading-deviation-norm: [-1.0 .. 1.0] /instruments/navradio[n]/gs-deviation-deg: [-0.7 to 0.7] /instruments/navradio[n]/gs-deviation-norm: [-1.0 to 1.0] Does this seem reasonable to all concerned? The CDI needle can move a little further out, than the outermost dot on the scale. Here, also the receiver detects offsets of more than 10deg, just the display is limited to full deflection. Yeah, please don't clamp any of the deviation properties to the nominal instrument full scale. The instrument designer will determine how much travel exists beyond full scale (if any) and apply the appropriate value. I think a clamp is a good idea, but at maybe double full scale, which is probably slightly beyond where the electronic drivers give out anyway. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] overflow in Instrumentation/gps.cxx
On 3 Jan 2009, at 18:47, Roy Vegard Ovesen wrote: marginally less silly ;-) IMHO this is the most elegant code I've submitted in a lng time, but if it's only marginally less silly, then perhaps I don't mind not getting credit for it. :-D Heh :) Roy, your code is fine, it's the entire GPS code that's pretty silly, and most especially the TTW to string computation. If one patch could reduce the total silliness by a large amount, that'd be an impressive patch :) James -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [PATCH] fix uninitialized _aspect_ratio member in Main/viewer.cxx
Subject says it all.
--
Csaba/Jester
Index: src/Main/viewer.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/viewer.cxx,v
retrieving revision 1.29
diff -u -r1.29 viewer.cxx
--- src/Main/viewer.cxx 26 Dec 2008 12:28:06 - 1.29
+++ src/Main/viewer.cxx 3 Jan 2009 19:57:24 -
@@ -84,6 +84,7 @@
_scaling_type(FG_SCALING_MAX),
_location(0),
_target_location(0),
+_aspect_ratio(0),
_cameraGroup(CameraGroup::getDefault())
{
_absolute_view_pos = SGVec3d(0, 0, 0);
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] NASAL_NAN64 causes SIGFPE with gcc optimization
Hi Andy! Nice trick, but gcc likes to reorder loads and causes SIGFPE when converting to integer (assuming exceptions are enabled). Such as here: lib.c:67: int len = 0, start = (int)naNumValue(args[1]).num; if(argc 2) return naNil(); nlen = argc 2 ? naNumValue(args[2]) : naNil(); if(!naIsNil(nlen)) len = (int)nlen.num; gcc creates code that performs: len = (int)nlen.num; if(naIsNil(nlen)) nlen = 0; 0x986256 f_subvec+70: xor%r13d,%r13d 0x986259 f_subvec+73: callq 0x986b50 naIsNil 0x98625e f_subvec+78: mov%rbx,(%rsp) 0x986262 f_subvec+82: movlpd 0x8(%rsp),%xmm2 0x986268 f_subvec+88: test %eax,%eax 0x98626a f_subvec+90: movlpd (%rsp),%xmm0 0x98626f f_subvec+95: mov%r14,%rdi 0x986272 f_subvec+98: cvttsd2si %xmm2,%ebp 0x986276 f_subvec+102:cvttsd2si %xmm0,%edx 0x98627a f_subvec+106:cmove %edx,%r13d This may qualify as a gcc bug. I am using version 4.1.2, I guess I need to try a newer version. -- Csaba/Jester -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NASAL_NAN64 causes SIGFPE with gcc optimization
On Sat, Jan 3, 2009 at 10:15 PM, Csaba Halász csaba.hal...@gmail.com wrote: lib.c:67: int len = 0, start = (int)naNumValue(args[1]).num; if(argc 2) return naNil(); nlen = argc 2 ? naNumValue(args[2]) : naNil(); if(!naIsNil(nlen)) len = (int)nlen.num; gcc creates code that performs: len = (int)nlen.num; if(naIsNil(nlen)) nlen = 0; 0x986256 f_subvec+70: xor%r13d,%r13d 0x986259 f_subvec+73: callq 0x986b50 naIsNil 0x98625e f_subvec+78: mov%rbx,(%rsp) 0x986262 f_subvec+82: movlpd 0x8(%rsp),%xmm2 0x986268 f_subvec+88: test %eax,%eax 0x98626a f_subvec+90: movlpd (%rsp),%xmm0 0x98626f f_subvec+95: mov%r14,%rdi 0x986272 f_subvec+98: cvttsd2si %xmm2,%ebp 0x986276 f_subvec+102:cvttsd2si %xmm0,%edx 0x98627a f_subvec+106:cmove %edx,%r13d This may qualify as a gcc bug. I am using version 4.1.2, I guess I need to try a newer version. Tim was kind enough to show what his gcc 4.3 generated (thanks!), and that looks okay: 0x962936 f_subvec+70: xor%r12d,%r12d 0x962939 f_subvec+73: callq 0x9632c0 naIsNil 0x96293e f_subvec+78: test %eax,%eax 0x962940 f_subvec+80: jne0x96294e f_subvec+94 0x962942 f_subvec+82: mov%rbx,0x8(%rsp) 0x962947 f_subvec+87: cvttsd2si 0x8(%rsp),%r12d The last instruction is the cast to int, and it is only performed if the naIsNil test returns false. Hopefully gcc always does the right thing, and it wasn't just a coincidence here. -- Csaba/Jester -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
