Re: [Flightgear-devel] GPS - merge request

2013-10-09 Thread syd adams
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
dirk.dittmann@gmail.comwrote:

 Am Donnerstag, 3. Oktober 2013, 21:38:52 schrieb James Turner:
  On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com
 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=60134791iu=/4140/ostg.clktrk
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 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=60134071iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-10-09 Thread Dirk Dittmann
Am Mittwoch, 9. Oktober 2013, 01:37:27 schrieb syd adams:
 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)

i think it's intern in the Dialog 

line:26 
dlg.getNode(scratch-index, 1).setValue(index); 
raise the fault.

called from line:140
updateSearchResults(0, dlg.getNode(scratch-index, 1).getValue());

the line are in the runtime error are viewed from nasal so it can' see the xml 
head.

it looks like the scratch-index is create by the getNode function and not 
bound to a type. In the Property Browser it shows type none. so getValue() 
return not a number.

dlg.initNode(scratch-index,0,INT) is maybe a better interface to crate the 
Node.


 
 
 
 On Fri, Oct 4, 2013 at 1:48 AM, Dirk Dittmann
 
 dirk.dittmann@gmail.comwrote:
  Am Donnerstag, 3. Oktober 2013, 21:38:52 schrieb James Turner:
   On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com
  
  wrote:
The improved-issue1164 is ready.
  
  https://gitorious.org/fg/dirks-flightgear/source/778cc8c6a0abb88a123885037
  6ea2374358fd887 
   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=60134791iu=/4140/ostg.clktr
  k
  ___
  Flightgear-devel mailing list
  Flightgear-devel@lists.sourceforge.net
  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=60134071iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-10-09 Thread syd adams
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
dirk.dittmann@gmail.comwrote:

 I will search for that. allways a segfault ? fg crash ?



 2013/10/9 syd adams adams@gmail.com

 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 
 dirk.dittmann@gmail.com wrote:

 Am Donnerstag, 3. Oktober 2013, 21:38:52 schrieb James Turner:
  On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com
 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=60134791iu=/4140/ostg.clktrk
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 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=60134071iu=/4140/ostg.clktrk

 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 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=60134071iu=/4140/ostg.clktrk
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 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=60134071iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-10-09 Thread syd adams
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 adams@gmail.com 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 dirk.dittmann@gmail.com
  wrote:

 I will search for that. allways a segfault ? fg crash ?



 2013/10/9 syd adams adams@gmail.com

 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 
 dirk.dittmann@gmail.com wrote:

 Am Donnerstag, 3. Oktober 2013, 21:38:52 schrieb James Turner:
  On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com
 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=60134791iu=/4140/ostg.clktrk
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 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=60134071iu=/4140/ostg.clktrk

 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 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=60134071iu=/4140/ostg.clktrk
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 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=60134071iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-10-04 Thread Dirk Dittmann
Am Donnerstag, 3. Oktober 2013, 21:38:52 schrieb James Turner:
 On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com 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=60134791iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-10-03 Thread Dirk Dittmann
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

--
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=60134791iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-10-03 Thread James Turner

On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com 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=60134791iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-10-03 Thread Pedro Morgan
http://wiki.flightgear.org/Talk:Nasal_Style_Guide


On Thu, Oct 3, 2013 at 9:38 PM, James Turner zakal...@mac.com wrote:


 On 3 Oct 2013, at 17:35, Dirk Dittmann dirk.dittmann@gmail.com
 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=60134791iu=/4140/ostg.clktrk
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 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=60134791iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-10-01 Thread James Turner

On 30 Sep 2013, at 08:47, Dirk Dittmann dirk.dittmann@gmail.com 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





--
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=60134791iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-10-01 Thread Dirk Dittmann
Am Dienstag, 1. Oktober 2013, 21:37:58 schrieb James Turner:
 On 30 Sep 2013, at 08:47, Dirk Dittmann dirk.dittmann@gmail.com 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

--
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=60134791iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-10-01 Thread James Turner

On 1 Oct 2013, at 22:34, Dirk Dittmann dirk.dittmann@gmail.com 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

--
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=60134791iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-09-30 Thread James Turner

On 30 Sep 2013, at 08:47, Dirk Dittmann dirk.dittmann@gmail.com 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

--
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=60133471iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-09-30 Thread Dirk Dittmann
Am Montag, 30. September 2013, 09:00:19 schrieb James Turner:
 On 30 Sep 2013, at 08:47, Dirk Dittmann dirk.dittmann@gmail.com 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

--
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=60133471iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-09-30 Thread Eric van den Berg


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: zakal...@mac.com
Date: Mon, 30 Sep 2013 09:00:19 +0100
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] GPS - merge request


On 30 Sep 2013, at 08:47, Dirk Dittmann dirk.dittmann@gmail.com 
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=60133471iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
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=60133471iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-09-30 Thread James Turner

On 30 Sep 2013, at 12:29, Eric van den Berg evan_den_b...@hotmail.com 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


--
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=60133471iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-09-30 Thread James Turner

On 30 Sep 2013, at 12:29, Eric van den Berg evan_den_b...@hotmail.com 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=60133471iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-09-30 Thread Eric van den Berg
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: zakal...@mac.com
Date: Mon, 30 Sep 2013 12:52:08 +0100
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] GPS - merge request


On 30 Sep 2013, at 12:29, Eric van den Berg evan_den_b...@hotmail.com 
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=60133471iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
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=60133471iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] GPS - merge request

2013-09-30 Thread Dirk Dittmann
Am Montag, 30. September 2013, 12:52:08 schrieb James Turner:
 On 30 Sep 2013, at 12:29, Eric van den Berg evan_den_b...@hotmail.com 
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

--
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=60133471iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel