From: Dirk D. <dir...@gm...> - 2013-09-30 07:47:50
|
Hello, Improved the Cross track error according to the great circle. http://williams.best.vwh.net/avform.htm#XTE. And make the overflight sequence configurable for the aircraft. The default is the same. /instrumentation/gps/config/over-flight-arm-angle-deg 90 /instrumentation/gps/config/over-flight-arm-distance-nm 1 /instrumentation/gps/config/over-flight-distance-nm 0 over-flight-distance-nm : - distance to waypoint - overflight -> next waypoint over-flight-arm-distance-nm: - distance to waypoint over-flight-distance-nm + over-flight-arm-distance-nm - overflight arms the cone over-flight-arm-angle-deg : - the cone left/right from LEG pointing on the waypoint - when armed and the aircraft leafs the cone -> next waypoint. branche fix-issue1164 @ my clone https://gitorious.org/fg/dirks-flightgear/source/85592ec45db2866a15197c051d97cb4014537b4b: Who should I ask for merge ? Dirk |
From: James T. <zak...@ma...> - 2013-09-30 08:00:49
|
On 30 Sep 2013, at 08:47, Dirk Dittmann <dir...@gm...> wrote: > Improved the Cross track error according to the great circle. > http://williams.best.vwh.net/avform.htm#XTE. Great,. > > And make the overflight sequence configurable for the aircraft. The default is > the same. > > /instrumentation/gps/config/over-flight-arm-angle-deg 90 > /instrumentation/gps/config/over-flight-arm-distance-nm 1 > /instrumentation/gps/config/over-flight-distance-nm 0 > > > over-flight-distance-nm : > - distance to waypoint > - overflight -> next waypoint > > over-flight-arm-distance-nm: > - distance to waypoint over-flight-distance-nm + over-flight-arm-distance-nm > - overflight arms the cone > > over-flight-arm-angle-deg : > - the cone left/right from LEG pointing on the waypoint > - when armed and the aircraft leafs the cone -> next waypoint. Great, although I do wonder if anyone will ever really adjust the cone angle. Doesn't do any harm though. > branche fix-issue1164 @ my clone > https://gitorious.org/fg/dirks-flightgear/source/85592ec45db2866a15197c051d97cb4014537b4b: > > > Who should I ask for merge ? Me, only query is that the above don't really seem to relate to issue 1164, which is about initial behaviour of the GPS when entering leg mode away from the active leg. Are you happy for me to pull from that branch to review, or would you rather send a patch, or make a merge request on Gitorious. All of those are fine with me, your choice. Regards, James |
From: Dirk D. <dir...@gm...> - 2013-09-30 08:30:03
|
Am Montag, 30. September 2013, 09:00:19 schrieb James Turner: > On 30 Sep 2013, at 08:47, Dirk Dittmann <dir...@gm...> wrote: > > Improved the Cross track error according to the great circle. > > http://williams.best.vwh.net/avform.htm#XTE. > > Great,. > > > And make the overflight sequence configurable for the aircraft. The > > default is the same. > > > > /instrumentation/gps/config/over-flight-arm-angle-deg 90 > > /instrumentation/gps/config/over-flight-arm-distance-nm 1 > > /instrumentation/gps/config/over-flight-distance-nm 0 > > > > > > over-flight-distance-nm : > > - distance to waypoint > > - overflight -> next waypoint > > > > over-flight-arm-distance-nm: > > - distance to waypoint over-flight-distance-nm + > > over-flight-arm-distance-nm - overflight arms the cone > > > > over-flight-arm-angle-deg : > > - the cone left/right from LEG pointing on the waypoint > > - when armed and the aircraft leafs the cone -> next waypoint. > > Great, although I do wonder if anyone will ever really adjust the cone > angle. Doesn't do any harm though. The over flight sequence has nothing to do with the fix its a goody. Yes no harm, it was there(90°) I just bring it out to the aircraft. > > branche fix-issue1164 @ my clone > > https://gitorious.org/fg/dirks-flightgear/source/85592ec45db2866a15197c051 > > d97cb4014537b4b: > > > > > > Who should I ask for merge ? > > Me, only query is that the above don't really seem to relate to issue 1164, > which is about initial behaviour of the GPS when entering leg mode away > from the active leg. I remind the leg course was a bearing from aircraft to waypoint, calculated once at init. Now the target course is the leg. It tries to intercept(below 45°) or going direct to waypoint. > > Are you happy for me to pull from that branch to review, or would you rather > send a patch, or make a merge request on Gitorious. All of those are fine > with me, your choice. Im happy when you pull, less to me ;) > > Regards, > James |
From: Eric v. d. B. <eva...@ho...> - 2013-09-30 11:29:38
|
It actually does solve issue 1164 (which I started). When one switches to the next waypoint, the active leg course and x-track-error relate to the leg between the previous and active waypoint of the flightplan (as it should in LEG mode). Previously the leg (-course and x-track-error) was formed between the active waypoint and the position of the aircraft at the moment of switching. The other stuff I asked Dirk to add as it makes our extra500 (GPSS) AP design a lot easier. Cheers, Eric From: zak...@ma... Date: Mon, 30 Sep 2013 09:00:19 +0100 To: fli...@li... Subject: Re: [Flightgear-devel] GPS - merge request On 30 Sep 2013, at 08:47, Dirk Dittmann <dir...@gm...> wrote:Improved the Cross track error according to the great circle. http://williams.best.vwh.net/avform.htm#XTE. Great,. And make the overflight sequence configurable for the aircraft. The default is the same./instrumentation/gps/config/over-flight-arm-angle-deg 90/instrumentation/gps/config/over-flight-arm-distance-nm 1/instrumentation/gps/config/over-flight-distance-nm 0over-flight-distance-nm : - distance to waypoint - overflight -> next waypointover-flight-arm-distance-nm: - distance to waypoint over-flight-distance-nm + over-flight-arm-distance-nm- overflight arms the cone over-flight-arm-angle-deg : - the cone left/right from LEG pointing on the waypoint- when armed and the aircraft leafs the cone -> next waypoint. Great, although I do wonder if anyone will ever really adjust the cone angle. Doesn't do any harm though. branche fix-issue1164 @ my clonehttps://gitorious.org/fg/dirks-flightgear/source/85592ec45db2866a15197c051d97cb4014537b4b:Who should I ask for merge ? Me, only query is that the above don't really seem to relate to issue 1164, which is about initial behaviour of the GPS when entering leg mode away from the active leg. Are you happy for me to pull from that branch to review, or would you rather send a patch, or make a merge request on Gitorious. All of those are fine with me, your choice. Regards,James ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: James T. <zak...@ma...> - 2013-09-30 11:47:19
|
On 30 Sep 2013, at 12:29, Eric van den Berg <eva...@ho...> wrote: > It actually does solve issue 1164 (which I started). > When one switches to the next waypoint, the active leg course and x-track-error relate to the leg between the previous and active waypoint of the flightplan (as it should in LEG mode). Previously the leg (-course and x-track-error) was formed between the active waypoint and the position of the aircraft at the moment of switching. Okay, the issue then is the behaviour with GPSs which build an 'entry leg' when activating but off-route, which was the intended behaviour of the current code. I'm fine with supporting both, the question is if we really need a distinct intercept mode for leg, and indeed radial, capture in the GPS, and a config option to control how that works. > The other stuff I asked Dirk to add as it makes our extra500 (GPSS) AP design a lot easier. Yes, no problem. BTW Dirk I would prefer separate commits for these areas of course. Kind regards, James |
From: James T. <zak...@ma...> - 2013-09-30 11:52:18
|
On 30 Sep 2013, at 12:29, Eric van den Berg <eva...@ho...> wrote: > The other stuff I asked Dirk to add as it makes our extra500 (GPSS) AP design a lot easier. Incidentally if you (Dirk) are looking at this code, the really great thing would be to get the turn-anticipation code enabled. All the pieces are there (compute a standard rate turn based on inbound / outbound leg courses, compute time before WPT to start turning based on ground-speed), but it's always been disabled because I couldn't figure out a stable formula for CDI deviation / XTK in the turn, and especially when transitioning between turn-anticipation and normal leg modes. (So there was an ugly wobble when turn anticipation starts and ends, with the AP did not like). Any comments, or contributions to this, would be great, since a few people have ended up implementing kludges at turn-anticipation in Nasal, when this code should really do it all from C++ nicely. Kind regards, James |
From: Eric v. d. B. <eva...@ho...> - 2013-09-30 12:28:09
|
To be honest I did not put any CDI in (yet). And it is coded in JSBSim, not Nasal (want to keep the plane flyable on my not so top-of-the-notch computer). I just turn the aircraft for a certain period of time (based on groundspeed, turn rate, ground track, nex leg course) and than switch over to the next leg. I also put some 'lead-in' time in as the AC wont be at the defined turn rate instantly. The AC then ends up very close to the leg-track, with the nose pointing in the right direction. The AP adjustment if needed is relatively subtle. Eric From: zak...@ma... Date: Mon, 30 Sep 2013 12:52:08 +0100 To: fli...@li... Subject: Re: [Flightgear-devel] GPS - merge request On 30 Sep 2013, at 12:29, Eric van den Berg <eva...@ho...> wrote:The other stuff I asked Dirk to add as it makes our extra500 (GPSS) AP design a lot easier. Incidentally if you (Dirk) are looking at this code, the really great thing would be to get the turn-anticipation code enabled. All the pieces are there (compute a standard rate turn based on inbound / outbound leg courses, compute time before WPT to start turning based on ground-speed), but it's always been disabled because I couldn't figure out a stable formula for CDI deviation / XTK in the turn, and especially when transitioning between turn-anticipation and normal leg modes. (So there was an ugly wobble when turn anticipation starts and ends, with the AP did not like). Any comments, or contributions to this, would be great, since a few people have ended up implementing kludges at turn-anticipation in Nasal, when this code should really do it all from C++ nicely. Kind regards,James ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Dirk D. <dir...@gm...> - 2013-09-30 14:21:18
|
Am Montag, 30. September 2013, 12:52:08 schrieb James Turner: > On 30 Sep 2013, at 12:29, Eric van den Berg <eva...@ho...> wrote: > > The other stuff I asked Dirk to add as it makes our extra500 (GPSS) AP > > design a lot easier. > Incidentally if you (Dirk) are looking at this code, the really great thing > would be to get the turn-anticipation code enabled. All the pieces are > there (compute a standard rate turn based on inbound / outbound leg > courses, compute time before WPT to start turning based on ground-speed), > but it's always been disabled because I couldn't figure out a stable > formula for CDI deviation / XTK in the turn, and especially when > transitioning between turn-anticipation and normal leg modes. (So there was > an ugly wobble when turn anticipation starts and ends, with the AP did not > like). my first thought is a fade in?/out XTK leg1 --fade--> XTK turn --fade--> XTK leg2 | switch next WPT > > Any comments, or contributions to this, would be great, since a few people > have ended up implementing kludges at turn-anticipation in Nasal, when this > code should really do it all from C++ nicely. > > Kind regards, > James |
From: James T. <zak...@ma...> - 2013-10-01 20:38:16
|
On 30 Sep 2013, at 08:47, Dirk Dittmann <dir...@gm...> wrote: > branche fix-issue1164 @ my clone > https://gitorious.org/fg/dirks-flightgear/source/85592ec45db2866a15197c051d97cb4014537b4b: Hi Dirk, this is looking pretty good, just some small nitpicks: - please make a helper function for the great-circle XTK error function, with some sane name like 'greatCircleCrossTrackError'. And please include a full URL to the aviation formulary link, for future readers of the code. (You already did this in one place I think) - where you only want course OR distance, SGGeodesy has some convenience wrappers (I realise in most places in this patch you do want both). This is just to improve readability right now (avoids useless 'az2' declarations), but in the future we might be able to do less work if only one value is needed. - Please squash commits, rebase -i is your friend - so all the evolution of the LegController should probably be squashed together. Similary the adding and removing of _mode_node will disappear with some squashing. - Avoid UTF-8 degree symbols in comments, it might upset some compilers. We recently had an issue with the older GCC on Jenkins rejecting UTF-8 BOM marker. - I would prefer arithmetic terms in conditions to *always* be parenthesised, we've had some bad bugs due to this, so: if (a < (b + c)) NOT if (a < b + c) - Where boolean conditional get complex, I often like to create explicit bools, so instead of: if ((some complex test) && (some other complex test) && ((another thing) || (still more))) I think it's more readable to do: bool answerOfTest1 = some complex text bool answerOfTest2 = some other complexTest … if (answerOfTest1 && answerOftest2 && …) The compiler will get rid of the bool vars, although you might force evaluation of more terms depending on how smart you the optimiser is, but you force yourself to give each boolean expression a name, like 'isWithinOverflightDistance' or 'isWithinInterceptAngle'. As a result it becomes much easier for someone else to evaluate the conditional logic and decide if they agree with it or not. If the boolean test is used more than once, make it into a helper method - grep-ing for methods names is*() and has*() in the codebase points to many of these. In general it looks pretty good though, let me know if you're happy to make the above changes or need any help (especially if you're new to git rebase -i, it can do terrible things) Kind regards, James |
From: Dirk D. <dir...@gm...> - 2013-10-01 21:34:50
|
Am Dienstag, 1. Oktober 2013, 21:37:58 schrieb James Turner: > On 30 Sep 2013, at 08:47, Dirk Dittmann <dir...@gm...> wrote: > > branche fix-issue1164 @ my clone > > > https://gitorious.org/fg/dirks-flightgear/source/85592ec45db2866a15197c051d97cb4014537b4b: > Hi Dirk, this is looking pretty good, just some small nitpicks: > > - please make a helper function for the great-circle XTK error function, > with some sane name like 'greatCircleCrossTrackError'. And please include a > full URL to the aviation formulary link, for future readers of the code. > > (You already did this in one place I think) > > - where you only want course OR distance, SGGeodesy has some convenience > wrappers (I realise in most places in this patch you do want both). This is > just to improve readability right now (avoids useless 'az2' declarations), > but in the future we might be able to do less work if only one value is > needed. > > - Please squash commits, rebase -i is your friend - so all the evolution of > the LegController should probably be squashed together. Similary the adding > and removing of _mode_node will disappear with some squashing. > > - Avoid UTF-8 degree symbols in comments, it might upset some compilers. We > recently had an issue with the older GCC on Jenkins rejecting UTF-8 BOM > marker. > > - I would prefer arithmetic terms in conditions to *always* be > parenthesised, we've had some bad bugs due to this, so: > > if (a < (b + c)) > > NOT > > if (a < b + c) > > - Where boolean conditional get complex, I often like to create explicit > bools, so instead of: > > if ((some complex test) && (some other complex test) && ((another thing) || > (still more))) > > I think it's more readable to do: > > bool answerOfTest1 = some complex text > bool answerOfTest2 = some other complexTest > … > > if (answerOfTest1 && answerOftest2 && …) > > The compiler will get rid of the bool vars, although you might force > evaluation of more terms depending on how smart you the optimiser is, but > you force yourself to give each boolean expression a name, like > 'isWithinOverflightDistance' or 'isWithinInterceptAngle'. As a result it > becomes much easier for someone else to evaluate the conditional logic and > decide if they agree with it or not. If the boolean test is used more than > once, make it into a helper method - grep-ing for methods names is*() and > has*() in the codebase points to many of these. > > In general it looks pretty good though, let me know if you're happy to make > the above changes or need any help (especially if you're new to git rebase > -i, it can do terrible things) I understand and will make the improvements. Thx for the hind ! I squash the commit and improve readability. Is there any code convention documentation ? Which I could read? > > Kind regards, > James |
From: James T. <zak...@ma...> - 2013-10-01 22:07:32
|
On 1 Oct 2013, at 22:34, Dirk Dittmann <dir...@gm...> wrote: > I understand and will make the improvements. Thx for the hind ! I squash the > commit and improve readability. Is there any code convention documentation ? > Which I could read? No, there's rules, since the codebase contains quite a mixture. We could start a wiki page, only things I really care about: m_ or _ prefix for members (_prefix is widely used but technically illegal by ISO C++, m_ is my slight preference now) fully brace conditions, even single line. This one is a pain but we've had several bugs with nested ifs-without-braces being modified and introducing logic errors. In several cases people forgot C++ is not Python: if (you do this) if (you keep do thing) if (you then do this) printf("terrible things can happen"); else printf("This is not python!"); :) I personally prefer lowerCamelCaseWithoutUnderscores for method and variable names, but you will find plenty of other places in the code which use all_lower_case - usually try to follow the style of the code you're working in/near. Regarding naming, longer names and fewer comments are better. Don't do: double m_vXr; /// the velocity tachyon flux better do: double m_velocityTachyonFlux; Of course only people with auto-completing editors agree with this! Shorter names are fine for locals or arguments but still aim to be descriptive. Kind regards, James |
From: James T. <zak...@ma...> - 2013-10-01 22:18:53
|
On 1 Oct 2013, at 23:07, James Turner <zak...@ma...> wrote: > No, there's rules, since the codebase contains quite a mixture. Whoops, typo. Meant to say, 'No, there's NO rules, since...' James ;) |
From: Dirk D. <dir...@gm...> - 2013-10-03 16:35:32
|
Hi James, The improved-issue1164 is ready. https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887: Dirk Am Dienstag, 1. Oktober 2013, 21:37:58 schrieb James Turner: > - please make a helper function for the great-circle XTK error function, > with some sane name like 'greatCircleCrossTrackError'. And please include a > full URL to the aviation formulary link, for future readers of the code. > > (You already did this in one place I think) done > > - where you only want course OR distance, SGGeodesy has some convenience > wrappers (I realise in most places in this patch you do want both). This is > just to improve readability right now (avoids useless 'az2' declarations), > but in the future we might be able to do less work if only one value is > needed. done > > - Please squash commits, rebase -i is your friend - so all the evolution of > the LegController should probably be squashed together. Similary the adding > and removing of _mode_node will disappear with some squashing. done > > - Avoid UTF-8 degree symbols in comments, it might upset some compilers. We > recently had an issue with the older GCC on Jenkins rejecting UTF-8 BOM > marker. done > > - I would prefer arithmetic terms in conditions to *always* be > parenthesised, we've had some bad bugs due to this, so: > > if (a < (b + c)) > > NOT > > if (a < b + c) > > - Where boolean conditional get complex, I often like to create explicit > bools, so instead of: > > if ((some complex test) && (some other complex test) && ((another thing) || > (still more))) > > I think it's more readable to do: > > bool answerOfTest1 = some complex text > bool answerOfTest2 = some other complexTest > … > > if (answerOfTest1 && answerOftest2 && …) > done > The compiler will get rid of the bool vars, although you might force > evaluation of more terms depending on how smart you the optimiser is, but > you force yourself to give each boolean expression a name, like > 'isWithinOverflightDistance' or 'isWithinInterceptAngle'. As a result it > becomes much easier for someone else to evaluate the conditional logic and > decide if they agree with it or not. If the boolean test is used more than > once, make it into a helper method - grep-ing for methods names is*() and > has*() in the codebase points to many of these. > > In general it looks pretty good though, let me know if you're happy to make > the above changes or need any help (especially if you're new to git rebase > -i, it can do terrible things) > > Kind regards, > James |
From: James T. <zak...@ma...> - 2013-10-03 20:39:04
|
On 3 Oct 2013, at 17:35, Dirk Dittmann <dir...@gm...> wrote: > The improved-issue1164 is ready. > https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887: Thanks, looks good and pushed. Unfortunately I now need to fix the route-path code to subdivide long legs along the great-circle course, since currently the map shows a visible difference at the midpoint of legs. But, that's a bug I'm glad to have :) Kind regards, James |
From: Pedro M. <pe...@fr...> - 2013-10-04 00:44:39
|
http://wiki.flightgear.org/Talk:Nasal_Style_Guide On Thu, Oct 3, 2013 at 9:38 PM, James Turner <zak...@ma...> wrote: > > On 3 Oct 2013, at 17:35, Dirk Dittmann <dir...@gm...> > wrote: > > The improved-issue1164 is ready. > > https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887: > > > Thanks, looks good and pushed. > > Unfortunately I now need to fix the route-path code to subdivide long legs > along the great-circle course, since currently the map shows a visible > difference at the midpoint of legs. But, that's a bug I'm glad to have :) > > Kind regards, > James > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > |
From: Dirk D. <dir...@gm...> - 2013-10-09 10:21:15
|
I will search for that. allways a segfault ? fg crash ? 2013/10/9 syd adams <ada...@gm...> > Not sure what went wrong but i get this error consistently now: > > Nasal runtime error: props.setValue() with non-number > at /media/FG/fgdata/Nasal/props.nas, line 29 > called from: __dlg:gps, line 20 > called from: __dlg:gps, line 134 > Segmentation fault (core dumped) > > > > On Fri, Oct 4, 2013 at 1:48 AM, Dirk Dittmann <dir...@gm... > > wrote: > >> Am Donnerstag, 3. Oktober 2013, 21:38:52 schrieb James Turner: >> > On 3 Oct 2013, at 17:35, Dirk Dittmann <dir...@gm...> >> wrote: >> > > The improved-issue1164 is ready. >> > >> > > >> https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887 >> : >> > Thanks, looks good and pushed. >> thx >> > >> > Unfortunately I now need to fix the route-path code to subdivide long >> legs >> > along the great-circle course, since currently the map shows a visible >> > difference at the midpoint of legs. But, that's a bug I'm glad to have >> :) >> i dont want to force you ;-) >> > >> > Kind regards, >> > James >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> from >> the latest Intel processors and coprocessors. See abstracts and register > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >> _______________________________________________ >> Flightgear-devel mailing list >> Fli...@li... >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel >> > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > |
From: syd a. <ada...@gm...> - 2013-10-09 19:20:32
|
No , Im not sure what caused the segfault... but the error message appears every time i try to use gps navigation ( with the b1900d).Another change in behavior is the heading needle deflection is extremely sensitive now when using nav1 slaved to gps. I could be wrong , i dont have the docs in front of me , but i was sure the gps deflection range was 5 nm. Syd On Wed, Oct 9, 2013 at 4:21 AM, Dirk Dittmann <dir...@gm...>wrote: > I will search for that. allways a segfault ? fg crash ? > > > > 2013/10/9 syd adams <ada...@gm...> > >> Not sure what went wrong but i get this error consistently now: >> >> Nasal runtime error: props.setValue() with non-number >> at /media/FG/fgdata/Nasal/props.nas, line 29 >> called from: __dlg:gps, line 20 >> called from: __dlg:gps, line 134 >> Segmentation fault (core dumped) >> >> >> >> On Fri, Oct 4, 2013 at 1:48 AM, Dirk Dittmann < >> dir...@gm...> wrote: >> >>> Am Donnerstag, 3. Oktober 2013, 21:38:52 schrieb James Turner: >>> > On 3 Oct 2013, at 17:35, Dirk Dittmann <dir...@gm...> >>> wrote: >>> > > The improved-issue1164 is ready. >>> > >>> > > >>> https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887 >>> : >>> > Thanks, looks good and pushed. >>> thx >>> > >>> > Unfortunately I now need to fix the route-path code to subdivide long >>> legs >>> > along the great-circle course, since currently the map shows a visible >>> > difference at the midpoint of legs. But, that's a bug I'm glad to have >>> :) >>> i dont want to force you ;-) >>> > >>> > Kind regards, >>> > James >>> >>> >>> ------------------------------------------------------------------------------ >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >>> from >>> the latest Intel processors and coprocessors. See abstracts and register >>> > >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Flightgear-devel mailing list >>> Fli...@li... >>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel >>> >> >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> from >> the latest Intel processors and coprocessors. See abstracts and register > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> Flightgear-devel mailing list >> Fli...@li... >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel >> >> > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > |
From: syd a. <ada...@gm...> - 2013-10-09 19:32:48
|
If its any help , the error message pops up the instant the gps dialog is opened.The dialog seems to work regardless , so Im not sure what the problem is. Syd On Wed, Oct 9, 2013 at 1:20 PM, syd adams <ada...@gm...> wrote: > No , Im not sure what caused the segfault... but the error message appears > every time i try to use gps navigation ( with the b1900d).Another change in > behavior is the heading needle deflection is extremely sensitive now when > using nav1 slaved to gps. I could be wrong , i dont have the docs in front > of me , but i was sure the gps deflection range was 5 nm. > Syd > > > On Wed, Oct 9, 2013 at 4:21 AM, Dirk Dittmann <dir...@gm... > > wrote: > >> I will search for that. allways a segfault ? fg crash ? >> >> >> >> 2013/10/9 syd adams <ada...@gm...> >> >>> Not sure what went wrong but i get this error consistently now: >>> >>> Nasal runtime error: props.setValue() with non-number >>> at /media/FG/fgdata/Nasal/props.nas, line 29 >>> called from: __dlg:gps, line 20 >>> called from: __dlg:gps, line 134 >>> Segmentation fault (core dumped) >>> >>> >>> >>> On Fri, Oct 4, 2013 at 1:48 AM, Dirk Dittmann < >>> dir...@gm...> wrote: >>> >>>> Am Donnerstag, 3. Oktober 2013, 21:38:52 schrieb James Turner: >>>> > On 3 Oct 2013, at 17:35, Dirk Dittmann <dir...@gm...> >>>> wrote: >>>> > > The improved-issue1164 is ready. >>>> > >>>> > > >>>> https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a1238850376ea2374358fd887 >>>> : >>>> > Thanks, looks good and pushed. >>>> thx >>>> > >>>> > Unfortunately I now need to fix the route-path code to subdivide long >>>> legs >>>> > along the great-circle course, since currently the map shows a visible >>>> > difference at the midpoint of legs. But, that's a bug I'm glad to >>>> have :) >>>> i dont want to force you ;-) >>>> > >>>> > Kind regards, >>>> > James >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> October Webinars: Code for Performance >>>> Free Intel webinars can help you accelerate application performance. >>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >>>> most from >>>> the latest Intel processors and coprocessors. See abstracts and >>>> register > >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Flightgear-devel mailing list >>>> Fli...@li... >>>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel >>>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >>> from >>> the latest Intel processors and coprocessors. See abstracts and register >>> > >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk >>> >>> _______________________________________________ >>> Flightgear-devel mailing list >>> Fli...@li... >>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel >>> >>> >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> from >> the latest Intel processors and coprocessors. See abstracts and register > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk >> _______________________________________________ >> Flightgear-devel mailing list >> Fli...@li... >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel >> >> > |
From: Alan T. <ajt...@v-...> - 2013-10-03 21:20:53
|
Re commit ad83e70cf5983c7b307847aa2cb92c40e42bc534 Author: James Turner Date: Thu Oct 3 17:40:17 2013 +0100 Extend built-in Nasal math. James Sorry, but MSVC does not have a round function. ;( Alan |
From: James T. <zak...@ma...> - 2013-10-03 21:53:24
|
On 3 Oct 2013, at 22:20, Alan Teeder <ajt...@v-...> wrote: > Sorry, but MSVC does not have a round function. ;( Yes, C99 is a cutting-edge spec :) I'll add a replacement for MSVC, thanks for spotting my mistake. Kind regards, James |
From: Pedro M. <pe...@fr...> - 2013-10-04 00:56:36
|
Can I make a suggestion.. What I want to do is create a "si...@fr..." as an user. The idea is to knock out the latest "bleeding edge docs" and "changes" to simgear.. Example is here.. http://docs.freeflightsim.org/simgear/ But I prefer a "sub domain".. On the server, Doxygen is installed and parses and knocks out the documentation.. This included the dependancies etc.. So the Question I am really getting down to is.. 1) can I create a "jenkins-docs-slave".. every push in simgear or fg etc, triggers build.. 2) the build if succesful,, would be immeadeate on said webbsite... So LIVE DOCS time... ;-) The end goal for me.. and my objective.. ... The area is vast of FlightGear.. and so many "parts".. ... eg OSG, sqlite, openGl, osg, simgear, files as xml, inages, vectors, blobs, terrasynv, live update with udp, http, socket et all.. 3) I figured out hoe to interlink all the parts.. Twice - first pass is for simgear to build and create index, then fg and create index - run again as one will depend upind the other by then.. and then.. U get the whole html blob.. On the decicated.. its and nginx config to a static site as user simgear eg listen { simgear.freefligtsim.org simgear.flighgear.org; root /home/simgear/jenkings/build_html/ index index.html } So its automatically build at each commit trigger.. Does that make sense james.. Not sure what to do re double build.. Expected its on the "dedicated" and "paths" between "accounts".. or alike.. The only latest doxygen is an user on machine also, so compiled to latest version.. Pete On Thu, Oct 3, 2013 at 10:53 PM, James Turner <zak...@ma...> wrote: > > On 3 Oct 2013, at 22:20, Alan Teeder <ajt...@v-...> wrote: > > Sorry, but MSVC does not have a round function. ;( > > > Yes, C99 is a cutting-edge spec :) > > I'll add a replacement for MSVC, thanks for spotting my mistake. > > Kind regards, > James > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > |
From: Gijs de R. <gij...@ho...> - 2013-10-08 09:01:23
|
Also, "double x;" needs to be declared at the top of the function (and then you will have "x = round(a.num / b.num);" of course). Cheers, Gijs |
From: Vivian M. <viv...@li...> - 2013-10-09 08:58:50
|
It's now getting on for a week since the build on Simgear was broken for Win 64/MSVC by this mistake. Any chance of a fix sometime soon? Vivian From: James Turner [mailto:zak...@ma...] Sent: 03 October 2013 22:53 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Simgear ,mathlib.c line 1 65 On 3 Oct 2013, at 22:20, Alan Teeder <ajt...@v-...> wrote: Sorry, but MSVC does not have a round function. ;( Yes, C99 is a cutting-edge spec :) I'll add a replacement for MSVC, thanks for spotting my mistake. Kind regards, James |
From: James T. <zak...@ma...> - 2013-10-09 09:52:18
|
On 9 Oct 2013, at 10:23, Vivian Meazza <viv...@li...> wrote: > It’s now getting on for a week since the build on Simgear was broken for Win 64/MSVC by this mistake. Any chance of a fix sometime soon? Yes, was just about to push one - however you can always push such a fix yourself! Regards, James |
From: Alan T. <ajt...@v-...> - 2013-10-09 10:05:51
|
James Sorry, but the patch failed. It also needs the change suggested by Gijs, with “double x,y;” e.g. static naRef f_round(naContext c, naRef me, int argc, naRef* args) { double x,y; naRef a = naNumValue(argc > 0 ? args[0] : naNil()); naRef b = naNumValue(argc > 1 ? args[1] : naNil()); if(naIsNil(a)) naRuntimeError(c, "non numeric arguments to round()"); if (naIsNil(b)) b.num = 1.0; #ifdef _MSC_VER // MSVC is not C99-compatible, no round() in math. y = a.num / b.num; x = floor(y + 0.5); #else x = round(a.num / b.num); #endif a.num = x * b.num; return VALIDATE(a); } Alan From: James Turner Sent: Wednesday, October 09, 2013 10:51 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Simgear ,mathlib.c line 1 65 On 9 Oct 2013, at 10:23, Vivian Meazza <viv...@li...> wrote: It’s now getting on for a week since the build on Simgear was broken for Win 64/MSVC by this mistake. Any chance of a fix sometime soon? Yes, was just about to push one - however you can always push such a fix yourself! Regards, James -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel |