Re: [Flightgear-devel] GIT : Nasal runtime error: No such member: asin

[grtuxhangar team]

Hello Anders,

Thanks for the quick reply, yes we had some sync issue with our Git.
right now  that's OK

Kind regards,

Ahmad


On 14 October 2013 14:15, Anders Gidenstam  wrote:

> On Mon, 14 Oct 2013, grtuxhangar team wrote:
>
>  Hello,
>>
>> with FG 2.99 Data  i am getting
>>
>> Nasal runtime error: No such member: asin
>>   at /devel/fgdata_git/Nasal/geo.**nas, line 173
>>   called from: /devel/fgdata_git/Nasal/view.**nas, line 306
>> called from: /devel/fgdata_git/Nasal/view.**nas, line 265
>> called from: /devel/fgdata_git/Nasal/view.**nas, line 217
>> called from: /devel/fgdata_git/Nasal/view.**nas, line 719
>>
>
> Please verify that your SimGear build is up to date. The math.asin
> function was moved to C++ code over a week ago and I have seen no other
> breakage reports and as far as I've noticed my own FG build works.
>
>
> Cheers,
>
> Anders
> --
> --**--**
> ---
> Anders Gidenstam
> WWW: http://gitorious.org/anders-**hangar
>  
> http://www.gidenstam.org/**FlightGear/
>
> --
> 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
> 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=60135031&iu=/4140/ostg.clktrk___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT : Nasal runtime error: No such member: asin

[Anders Gidenstam]

On Mon, 14 Oct 2013, grtuxhangar team wrote:


Hello,

with FG 2.99 Data  i am getting

Nasal runtime error: No such member: asin
  at /devel/fgdata_git/Nasal/geo.nas, line 173
  called from: /devel/fgdata_git/Nasal/view.nas, line 306
called from: /devel/fgdata_git/Nasal/view.nas, line 265
called from: /devel/fgdata_git/Nasal/view.nas, line 217
called from: /devel/fgdata_git/Nasal/view.nas, line 719


Please verify that your SimGear build is up to date. The math.asin 
function was moved to C++ code over a week ago and I have seen no 
other breakage reports and as far as I've noticed my own FG build works.



Cheers,

Anders
--
---
Anders Gidenstam
WWW: http://gitorious.org/anders-hangar
 http://www.gidenstam.org/FlightGear/--
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
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git help request

[Curtis Olson]

On Thu, Aug 9, 2012 at 11:50 AM, Tim Moore wrote:

> If you are going to keep a branch for a long time that you are not
> merging  back into e.g., master, there are a couple of possibilities.
> One is to merge (pull) master into your branch. Another is to check
> out git-rerere (I kid you not), which records merge conflict
> resolutions and reapplies them automatically when needed. With that
> you can either rebase repeatedly or never rebase and periodically do
> test merges with master.
>

My typical workflow is to pull the master branch (daily at least) and then
when there are updates, checkout my private branch and "git merge master".
 That's worked fine, except it is my understanding that this is frowned
upon because some day if I ever cherry pick something back into the master
branch, the commit log will get prefaces with a couple hundred "merge"
messages.  The rebase supposedly puts my local changes at the top.  Every
thing generally works as it's supposed to I think, except the double
directory mv in a single commit seemed to completely confuse the subsequent
rebase.  I think I'm just going to file this under: git gives you more than
enough rope to hang yourself by, especially when you venture away from the
simple/common usage cases and don't have a complete understanding of what
git does under the hood and how each command manipulates the internal
state.  I haven't lost anything (other than 2 days of my life) :-) -- and I
still have my old branch, now renamed with all the history; so for the
moment I've created a new branch, moved all the different stuff to that (I
hope) and will continue on from there.

Regards,

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git help request

[Tim Moore]

On Thu, Aug 9, 2012 at 2:45 PM, Curtis Olson  wrote:
> It looks like every time you rebase you have to reapply the same set of
> patches over top the target branch.  So even if I figure out a way through
> it once, I'll have to repeat the same conconction of craziness each time I
> rebase.  I think I'm going to create a new branch, untar my changes on top,
> lose all my history and forget about it.  I didn't budget 2 full days to
> fiddle with this and I'm frustrated and annoyed now and unsure
> what/if/anything I've lost or broken -- blahhh ... little things you might
> not notice for 6 months because you don't work with every file every day ...
>
> Curt.
>
If you are going to keep a branch for a long time that you are not
merging  back into e.g., master, there are a couple of possibilities.
One is to merge (pull) master into your branch. Another is to check
out git-rerere (I kid you not), which records merge conflict
resolutions and reapplies them automatically when needed. With that
you can either rebase repeatedly or never rebase and periodically do
test merges with master.

Tim
>
> On Thu, Aug 9, 2012 at 1:56 AM, Renk Thorsten 
> wrote:
>>
>> > The typical fix is to edit the conflicting files and "git add" them the
>> > run "git rebase --continue".
>> > But these files don't exist so I can't edit them, git add fails, git rm
>> > also fails since they don't exist.
>>
>> If the files no longer exist, I think one solution is to tell the system
>> to skip the patch:
>>
>> git rebase --skip
>>
>> did the trick for me on a similar occasion. The rebase operation then goes
>> on with the next patch. If you actually want the files,
>>
>> git checkout  -- 
>>
>> should fetch them from the branch where they still exist.
>>
>> I also frequently use
>>
>> git status
>>
>> to track what exactly the problem is. Although I am probably not the best
>> source for GIT troubleshooting, I feel your pain. I've had similar trouble a
>> few times.
>>
>> Cheers,
>>
>> * Thorsten
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> Flightgear-devel mailing list
>> Flightgear-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>
>
>
> --
> Curtis Olson:
> http://www.atiak.com - http://aem.umn.edu/~uav/
> http://www.flightgear.org - http://gallinazo.flightgear.org
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git help request

[John Denker]

On 08/09/2012 07:45 AM, Curtis Olson wrote:
> It looks like every time you rebase you have to reapply the same set of
> patches over top the target branch. 

Not true in general.  I've never had a problem like that.

>  So even if I figure out a way through
> it once, I'll have to repeat the same conconction of craziness each time I
> rebase. 

Ditto.

> It complains about whitespace errors, then falls back to a 3-way merge,
> then reports conflicts with all the files in the 2 old directories,

If whitespace were the only problem, you could make the problem
go away using --no-verify.

Also, as others have suggested, when in doubt, doing "git status"
is always a good idea.

>  I think I'm going to create a new branch, untar my changes on top,
> lose all my history and forget about it. 

Creating new branches is cheap and often an excellent idea,
especially if you are uncertain about something and want to
experiment.

> untar my changes on top,
> lose all my history and forget about it. 

It's not possible to be sure exactly what the problem is without
further information, but it seems likely that there is a simpler
way to get a similar result without losing history, namely:

  git rebase -Xours

or

  git rebase -s 'recursive -Xours'

You can read the manpage and/or google for more information about
what these options do.

I believe these options require git version 1.7.3 or later.  If you 
need to install a newer git, that's easy and well worthwhile.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git help request

[Curtis Olson]

On Thu, Aug 9, 2012 at 10:44 AM, Anders Gidenstam
wrote:

> If you can figure out which commits cause the problems you can edit them
> out of your branch (or, better, out of a copy of it) using
>
> git rebase -i HEAD~42
>
> (change 42 to the number of commits back from HEAD that you need to
> touch).
>
> See also the manual page for git rebase and
>
> http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages


I appreciate all the suggestions, it is getting slightly more complicated
than I want to deal with today. :-)  I did play with interactive git
rebase, but my brain overheated trying to imagine what happens and what
downstream breakage might occur if I skip a commit that involves renaming
directories?  And then I'd still have to remember the exact sequence of
steps each time I did a new rebase.  Apparently rebase doesn't quite do
what I expected it to do -- it catches you up, but later if you do another
rebase apparently it redoes all your changes from day 1 of your branch.
 There is probably a good reason for doing it this way, but I was imagining
that a rebase was a one time operation and future rebases would be able to
start from where the previous one finished off.  Maybe that doesn't make
any sense?  I'm probably a bit confused in either case -- flightgear seems
to force you to jump into the deep end of the git pool right away. :-)
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git help request

[Anders Gidenstam]

On Thu, 9 Aug 2012, Curtis Olson wrote:

> It looks like every time you rebase you have to reapply the same set of
> patches over top the target branch.  So even if I figure out a way through
> it once, I'll have to repeat the same conconction of craziness each time I
> rebase.  I think I'm going to create a new branch, untar my changes on top,
> lose all my history and forget about it.  I didn't budget 2 full days to
> fiddle with this and I'm frustrated and annoyed now and unsure
> what/if/anything I've lost or broken -- blahhh ... little things you might
> not notice for 6 months because you don't work with every file every day ...

If you can figure out which commits cause the problems you can edit them 
out of your branch (or, better, out of a copy of it) using

git rebase -i HEAD~42

(change 42 to the number of commits back from HEAD that you need to 
touch).

See also the manual page for git rebase and
http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages


Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://gitorious.org/anders-hangar
  http://www.gidenstam.org/FlightGear/

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git help request

[Curtis Olson]

It looks like every time you rebase you have to reapply the same set of
patches over top the target branch.  So even if I figure out a way through
it once, I'll have to repeat the same conconction of craziness each time I
rebase.  I think I'm going to create a new branch, untar my changes on top,
lose all my history and forget about it.  I didn't budget 2 full days to
fiddle with this and I'm frustrated and annoyed now and unsure
what/if/anything I've lost or broken -- blahhh ... little things you might
not notice for 6 months because you don't work with every file every day ...

Curt.


On Thu, Aug 9, 2012 at 1:56 AM, Renk Thorsten wrote:

> > The typical fix is to edit the conflicting files and "git add" them the
> run "git rebase --continue".
> > But these files don't exist so I can't edit them, git add fails, git rm
> also fails since they don't exist.
>
> If the files no longer exist, I think one solution is to tell the system
> to skip the patch:
>
> git rebase --skip
>
> did the trick for me on a similar occasion. The rebase operation then goes
> on with the next patch. If you actually want the files,
>
> git checkout  -- 
>
> should fetch them from the branch where they still exist.
>
> I also frequently use
>
> git status
>
> to track what exactly the problem is. Although I am probably not the best
> source for GIT troubleshooting, I feel your pain. I've had similar trouble
> a few times.
>
> Cheers,
>
> * Thorsten
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>



-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git help request

[Renk Thorsten]

> The typical fix is to edit the conflicting files and "git add" them the run 
> "git rebase --continue".  
> But these files don't exist so I can't edit them, git add fails, git rm also 
> fails since they don't exist.

If the files no longer exist, I think one solution is to tell the system to 
skip the patch: 

git rebase --skip

did the trick for me on a similar occasion. The rebase operation then goes on 
with the next patch. If you actually want the files,

git checkout  -- 

should fetch them from the branch where they still exist.

I also frequently use

git status

to track what exactly the problem is. Although I am probably not the best 
source for GIT troubleshooting, I feel your pain. I've had similar trouble a 
few times.

Cheers,

* Thorsten
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git help request

[Curtis Olson]

On Wed, Aug 8, 2012 at 12:06 PM, Tim Moore wrote:

> It sounds like your local tree has not been completely committed. See
> what "git status" says. Check out the man page for git-mv. I can't say
> more right at the moment, but I'll see if I can add more details
> later.
>

There are a couple other random untracked changes, but nothing inside any
of the directories that were renamed and now failing on the rebase.

Curt;.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git help request

[Tim Moore]

It sounds like your local tree has not been completely committed. See
what "git status" says. Check out the man page for git-mv. I can't say
more right at the moment, but I'll see if I can add more details
later.

Tim

On Wed, Aug 8, 2012 at 5:45 PM, Curtis Olson  wrote:
> A quick update here.  Rob pointed out the "git rebase --abort" command which
> got me back to a sensible working state.  I was able to reevaluate my
> original problem which turned out to be a simple merge conflict in my branch
> vs. changes in "master" and I was able to fix that and successfully merge --
> so I'm in a reasonable working state again.
>
> But I would mind rebasing my local changes, but I still get an error.
>
> I think what happened originally is I changed the directory name of my
> aircraft from Malolo1 to Resolution, then thought for a second and changed
> it again to ATI-Resolution -- and then did that all as a single commit.  Now
> the rebase throws fits on that patch.
>
> It complains about whitespace errors, then falls back to a 3-way merge, then
> reports conflicts with all the files in the 2 old directories, for example:
>
> Aircraft/Malolo1/Engines/18x8.xml: needs merge
> Aircraft/Resolution/Engines/18x8.xml: needs merge
>
> The typical fix is to edit the conflicting files and "git add" them the run
> "git rebase --continue".  But these files don't exist so I can't edit them,
> git add fails, git rm also fails since they don't exist.
>
> I suppose I could abandon this branch, figure out the diffs against "master"
> manually, create a new branch, and copy those diffs into my new branch --
> but then I would lose all my history and that just doesn't seem very git-ish
> -- I hate to go against the spirit of "git" which is more along the lines of
> performing brain surgery on myself when I don't quite feel happy -- what
> could go wrong?  Or what do I do when something goes wrong? :-)
>
> Curt.
>
>
> On Wed, Aug 8, 2012 at 9:27 AM, Curtis Olson  wrote:
>>
>> I've run into a problem with git and I seem to hit a dead end no matter
>> which way I turn.  I'm hoping this is something easy to solve, but the
>> details might be complicated to communicate?  I'll try to start simple --
>> I'm working with the fgdata repository.  I created my own branch and have
>> been tracking some experimental stuff there.  This has been working well and
>> when I do a "git pull" I will checkout my local branch and merge with the
>> master to make sure everything is tracking well and stays compatible.
>>
>> With my most recent attempt to merge my local branch with master I got an
>> error (unfortunately now I do not remember what the exact error was, and I
>> had to do a reboot for other reasons in the mean time.)  My first thought
>> after getting an error trying to merge was maybe I should rebase since I've
>> just been merging all along.
>>
>> So I ran "git rebase" and that ran did a lot of work, but then generated
>> some error messages about whitespace, and then displayed some message that
>> it had to fall back to a 3-way diff.  That ran and ran for quite some time
>> and (I think?) errored out.  Again, I don't have the message any more. :-(
>>
>> Now after my reboot, I'm trying to figure out what's going on.  If I run
>> "git branch" I get:
>>
>> $ git branch
>> * (no branch)
>>
>> If I try to checkout any branch I get a list of files that need merge and
>> then the message: "error: you need to resolve your current index first".
>>
>> If I "git add" any of these files, what branch am I adding them to and
>> merging them into?  (no branch)?
>>
>> It seems like all the git help I can find for these error messages
>> presumes I can checkout a branch -- but I can't.  Any suggestions?
>>
>> Thanks,
>>
>> Curt.
>> --
>> Curtis Olson:
>> http://www.atiak.com - http://aem.umn.edu/~uav/
>> http://www.flightgear.org - http://gallinazo.flightgear.org
>>
>
>
>
> --
> Curtis Olson:
> http://www.atiak.com - http://aem.umn.edu/~uav/
> http://www.flightgear.org - http://gallinazo.flightgear.org
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl0

Re: [Flightgear-devel] git help request

[Curtis Olson]

On Wed, Aug 8, 2012 at 10:45 AM, Curtis Olson  wrote:

> A quick update here.  Rob pointed out the "git rebase --abort" command
> which got me back to a sensible working state.  I was able to reevaluate my
> original problem which turned out to be a simple merge conflict in my
> branch vs. changes in "master" and I was able to fix that and successfully
> merge -- so I'm in a reasonable working state again.
>
> But I would mind rebasing my local changes, but I still get an error.
>
> I think what happened originally is I changed the directory name of my
> aircraft from Malolo1 to Resolution, then thought for a second and changed
> it again to ATI-Resolution -- and then did that all as a single commit.
>  Now the rebase throws fits on that patch.
>
> It complains about whitespace errors, then falls back to a 3-way merge,
> then reports conflicts with all the files in the 2 old directories, for
> example:
>
> Aircraft/Malolo1/Engines/18x8.xml: needs merge
> Aircraft/Resolution/Engines/18x8.xml: needs merge
>
> The typical fix is to edit the conflicting files and "git add" them the
> run "git rebase --continue".  But these files don't exist so I can't edit
> them, git add fails, git rm also fails since they don't exist.
>
> I suppose I could abandon this branch, figure out the diffs against
> "master" manually, create a new branch, and copy those diffs into my new
> branch -- but then I would lose all my history and that just doesn't seem
> very git-ish -- I hate to go against the spirit of "git" which is more
> along the lines of performing brain surgery on myself when I don't quite
> feel happy -- what could go wrong?  Or what do I do when something goes
> wrong? :-)
>

brain surgery --abort :-)

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git help request

[Curtis Olson]

A quick update here.  Rob pointed out the "git rebase --abort" command
which got me back to a sensible working state.  I was able to reevaluate my
original problem which turned out to be a simple merge conflict in my
branch vs. changes in "master" and I was able to fix that and successfully
merge -- so I'm in a reasonable working state again.

But I would mind rebasing my local changes, but I still get an error.

I think what happened originally is I changed the directory name of my
aircraft from Malolo1 to Resolution, then thought for a second and changed
it again to ATI-Resolution -- and then did that all as a single commit.
 Now the rebase throws fits on that patch.

It complains about whitespace errors, then falls back to a 3-way merge,
then reports conflicts with all the files in the 2 old directories, for
example:

Aircraft/Malolo1/Engines/18x8.xml: needs merge
Aircraft/Resolution/Engines/18x8.xml: needs merge

The typical fix is to edit the conflicting files and "git add" them the run
"git rebase --continue".  But these files don't exist so I can't edit them,
git add fails, git rm also fails since they don't exist.

I suppose I could abandon this branch, figure out the diffs against
"master" manually, create a new branch, and copy those diffs into my new
branch -- but then I would lose all my history and that just doesn't seem
very git-ish -- I hate to go against the spirit of "git" which is more
along the lines of performing brain surgery on myself when I don't quite
feel happy -- what could go wrong?  Or what do I do when something goes
wrong? :-)

Curt.


On Wed, Aug 8, 2012 at 9:27 AM, Curtis Olson  wrote:

> I've run into a problem with git and I seem to hit a dead end no matter
> which way I turn.  I'm hoping this is something easy to solve, but the
> details might be complicated to communicate?  I'll try to start simple --
> I'm working with the fgdata repository.  I created my own branch and have
> been tracking some experimental stuff there.  This has been working well
> and when I do a "git pull" I will checkout my local branch and merge with
> the master to make sure everything is tracking well and stays compatible.
>
> With my most recent attempt to merge my local branch with master I got an
> error (unfortunately now I do not remember what the exact error was, and I
> had to do a reboot for other reasons in the mean time.)  My first thought
> after getting an error trying to merge was maybe I should rebase since I've
> just been merging all along.
>
> So I ran "git rebase" and that ran did a lot of work, but then generated
> some error messages about whitespace, and then displayed some message that
> it had to fall back to a 3-way diff.  That ran and ran for quite some time
> and (I think?) errored out.  Again, I don't have the message any more. :-(
>
> Now after my reboot, I'm trying to figure out what's going on.  If I run
> "git branch" I get:
>
> $ git branch
> * (no branch)
>
> If I try to checkout any branch I get a list of files that need merge and
> then the message: "error: you need to resolve your current index first".
>
> If I "git add" any of these files, what branch am I adding them to and
> merging them into?  (no branch)?
>
> It seems like all the git help I can find for these error messages
> presumes I can checkout a branch -- but I can't.  Any suggestions?
>
> Thanks,
>
> Curt.
> --
> Curtis Olson:
> http://www.atiak.com - http://aem.umn.edu/~uav/
> http://www.flightgear.org - http://gallinazo.flightgear.org
>
>


-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[James Turner]

On 25 Apr 2012, at 07:04, Renk Thorsten wrote:

> A quick 3 minute test flight with the ufo looks very promising - I didn't see 
> any obvious issues with the version pulled 10 minutes ago. I will do longer 
> tests later toady.

Thanks Thorsten!

James


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Renk Thorsten]

> What about the mentioned problems? Better? Worse?

A quick 3 minute test flight with the ufo looks very promising - I didn't see 
any obvious issues with the version pulled 10 minutes ago. I will do longer 
tests later toady.

* Thorsten
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Mathias Fröhlich]

Hi,

On Tuesday, April 24, 2012 22:51:34 James Turner wrote:
> Okay, I guess I was assuming I can use SGreferenced the same way I use
> release/retain in Cocoa, or addRef/decRef in COM/XPCOM. But it seems as if
> this is not the case, from looking at your commit - I can't use
> SGreferenced as a virtual base, and I have to make the delete call by hand.
> 
> I guess this is to avoid virtual method overhead on SGreferenced?
Yes.

SGReferenced should exactly *not* contain any virtual table. This is supposed 
to be the helper class for reference counting, but it should be as lightweight 
as possible. Imagine we want at some time have a variable size mathematical 
vector container that works with a copy on write semantics, I definitely want 
to use SGReferenced there and have no vtable at all.

If you want something that you can just use a general base class for 
heavyweight stuff, invent a class derived from SGReferenced or better 
SGWeakReferenced that introduces this vtable stuff. And since we are looking 
then for something more heavy, I would tend to use SGWeakReferenced as base 
class for an SGObject 

class SGObject : public SGWeakReferenced {
public:
virtual ~SGObject() {}
}

The weak referenced class provides the ability to have weak pointers to such a 
WeakReferenced derived class. That are pointers that know about when the last 
reference to the instance it points to is deleted and provides a 
SGSharedPtr SGWeakPtr::lock() method that atomically and thread safe 
returns either a valid shared pointer to the still alive object or a null 
pointer since the objects reference count was already zero and the object is 
at least being deleted or already dead.

If you want the destructor protected, I need to backport something more from 
OpenRTI and stuff to simgear.

What about the mentioned problems? Better? Worse?

Mathias

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[James Turner]

On 24 Apr 2012, at 22:33, Mathias Fröhlich wrote:

> I could by the length of the thread not exactly find what is going wrong and 
> how to reproduce this. But jut having a quick look at NasalPositiond.cxx, I 
> can see that this does not match the intented use of SGReferenced.
> I have checked in what is needed to match how it's intented to be used.
> 
> Given that you seem to experience dangling pointers and now things are 
> actually deleted when the reference count drops to zero - that did not happen 
> before, I guess that this makes things worse at first. But you might be able 
> to 
> find the real cause of the problem a little better now.
> 
> Else, I am online again tomorrow evening.

Okay, I guess I was assuming I can use SGreferenced the same way I use 
release/retain in Cocoa, or addRef/decRef in COM/XPCOM. But it seems as if this 
is not the case, from looking at your commit - I can't use SGreferenced as a 
virtual base, and I have to make the delete call by hand. 

I guess this is to avoid virtual method overhead on SGreferenced?

James


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Mathias Fröhlich]

Hi,

On Tuesday, April 24, 2012 13:39:59 James Turner wrote:
> Okay, then I realise this isn't useful for you, but I'm stumped why it
> crashes for you. In particular, the hashForAirport function is being passed
> something that looks like a valid pointer (I think), and it crashing on a
> line that should only really happen if the pointer is invalid, or there's
> other memory corruption going on.

Just stepping into this discussion somehow.
I could by the length of the thread not exactly find what is going wrong and 
how to reproduce this. But jut having a quick look at NasalPositiond.cxx, I 
can see that this does not match the intented use of SGReferenced.
I have checked in what is needed to match how it's intented to be used.

Given that you seem to experience dangling pointers and now things are 
actually deleted when the reference count drops to zero - that did not happen 
before, I guess that this makes things worse at first. But you might be able to 
find the real cause of the problem a little better now.

Else, I am online again tomorrow evening.

Greetings

Mathias

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Frederic Bouvier]

James,

I wasn't affected by a crash until I realized that hashForAirport was never 
called. Then I enabled animated jetways and the segfault came, after few 
successful calls.
I am not able to tell why though

HTH
-Fred

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[syd adams]

Im assuming my crash is related, but it only happens when i open the
route-manager dialog...
Syd

On Tue, Apr 24, 2012 at 10:24 AM, Curtis Olson  wrote:
> On Tue, Apr 24, 2012 at 11:09 AM, James Turner  wrote:
>>
>>
>> As far as the FGPositioned Octree is concerned (which is what findClosest
>> uses internally), it's holding an owning ref and hence things can't be
>> removed from it, for the moment.
>>
>> So what I guess is happening, is that I'm breaking the ref-counting scheme
>> *somehow*, and hence the Octree is left holding a dead reference as you say.
>> And somehow how I get away with this on Mac.
>>
>> But this feels a little implausible, since in other similar scenarios the
>> Mac crashes quite happily!
>
>
> I've manage to have a run or two on Linux that didn't crash if that makes
> you feel any better. :-)  But I'll give you that it's much easier to fix a
> problem that you can observe versus one you can't observe.
>
> Perhaps the ref counting problem isn't getting triggered on your Mac for
> some other subtle reason?
>
> Curt.
> --
> Curtis Olson:
> http://www.atiak.com - http://aem.umn.edu/~uav/
> http://www.flightgear.org - http://gallinazo.flightgear.org
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Curtis Olson]

On Tue, Apr 24, 2012 at 11:09 AM, James Turner  wrote:

>
> As far as the FGPositioned Octree is concerned (which is what findClosest
> uses internally), it's holding an owning ref and hence things can't be
> removed from it, for the moment.
>
> So what I guess is happening, is that I'm breaking the ref-counting scheme
> *somehow*, and hence the Octree is left holding a dead reference as you
> say. And somehow how I get away with this on Mac.
>
> But this feels a little implausible, since in other similar scenarios the
> Mac crashes quite happily!


I've manage to have a run or two on Linux that didn't crash if that makes
you feel any better. :-)  But I'll give you that it's much easier to fix a
problem that you can observe versus one you can't observe.

Perhaps the ref counting problem isn't getting triggered on your Mac for
some other subtle reason?

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[James Turner]

On 24 Apr 2012, at 16:50, Curtis Olson wrote:

> If an FGAirport object was ref-counted and deleted because the ref-count went 
> to zero, then why would  FGAirport::findClosest() still be returning a 
> pointer to it it as the closest airport?  Is it not getting fully/properly 
> deleted or removed from the list and you just getting lucky on the Mac that 
> it's not segfaulting?

As far as the FGPositioned Octree is concerned (which is what findClosest uses 
internally), it's holding an owning ref and hence things can't be removed from 
it, for the moment.

So what I guess is happening, is that I'm breaking the ref-counting scheme 
*somehow*, and hence the Octree is left holding a dead reference as you say. 
And somehow how I get away with this on Mac.

But this feels a little implausible, since in other similar scenarios the Mac 
crashes quite happily!

James


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Frederic Bouvier]

Hi James,

just a guess here, but in the past, I had to fix issues brought when converting 
raw pointers to smart pointers and ending up deleting the pointer given by the 
smart pointer explicitly. For example :

SGSharedPtr myPtr = new MyClass;

then

delete myPtr;
or
delete myPtr.get();

afterward, the destructor of SGSharedPtr does another delete on the 
same memory and may crash, depending the system and the memory layout


Regards,
-Fred

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Curtis Olson]

On Tue, Apr 24, 2012 at 10:35 AM, James Turner  wrote:

>
> On 24 Apr 2012, at 16:31, Curtis Olson wrote:
>
> > Based on two runs with out crashing, that seems to prevent the crash ...
>
> Okay, so that's good  but leaves me wondering why it doesn't crash on
> Mac the same way. And also, how I've got the ref-counting wrong.


If an FGAirport object was ref-counted and deleted because the ref-count
went to zero, then why would  FGAirport::findClosest() still be returning a
pointer to it it as the closest airport?  Is it not getting fully/properly
deleted or removed from the list and you just getting lucky on the Mac that
it's not segfaulting?

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[James Turner]

On 24 Apr 2012, at 16:31, Curtis Olson wrote:

> Based on two runs with out crashing, that seems to prevent the crash ...

Okay, so that's good  but leaves me wondering why it doesn't crash on Mac 
the same way. And also, how I've got the ref-counting wrong.

James


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Curtis Olson]

On Tue, Apr 24, 2012 at 10:06 AM, James Turner  wrote:

> It's probably a reference counting issue. FGAirport is a FGPositioned and
> hence reference counted. The Nasal Ghost is supposed to deal with this -
> when we create a ghost around the airport, we take a reference
> (SGReferenced::get) and when Nasal garbage-collects the ghost, the
> reference count is decremented. (SGReferenced::put)
>
> If the reference count hits zero, the airport will be freed, leading to
> the issue you see. But that would imply there's nothing else holding a
> reference to the airport, and that's not the case, because the the spatial
> index (the octree) in positioned.cxx holds a reference to everything at the
> moment.
>
> If I'd screwed up the ref-counting logic completely, I'd expect it to be
> crashing for me exactly the same, and it's not. Very weird.
>
> So likely I have made a subtle screw-up that only affects Linux. You could
> test this by commenting out the call to
>
>SGreferencd::put()
>
> in sgrefGhostDestroy - references will be leaked, but if it stops the
> crash then we can be sure it's a ref-counting bug.


Hi James,

Based on two runs with out crashing, that seems to prevent the crash ...

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[James Turner]

On 24 Apr 2012, at 15:57, Curtis Olson wrote:

> I tried running with valgrind and the error didn't happen -- hmmm...
> 
> Trying it again, but a valgrind startup is excruciatingly slow ...

It's probably a reference counting issue. FGAirport is a FGPositioned and hence 
reference counted. The Nasal Ghost is supposed to deal with this - when we 
create a ghost around the airport, we take a reference (SGReferenced::get) and 
when Nasal garbage-collects the ghost, the reference count is decremented. 
(SGReferenced::put)

If the reference count hits zero, the airport will be freed, leading to the 
issue you see. But that would imply there's nothing else holding a reference to 
the airport, and that's not the case, because the the spatial index (the 
octree) in positioned.cxx holds a reference to everything at the moment.

If I'd screwed up the ref-counting logic completely, I'd expect it to be 
crashing for me exactly the same, and it's not. Very weird.

So likely I have made a subtle screw-up that only affects Linux. You could test 
this by commenting out the call to

SGreferencd::put()

in sgrefGhostDestroy - references will be leaked, but if it stops the crash 
then we can be sure it's a ref-counting bug.

James


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Curtis Olson]

Hi James,

Here is a bit more information.

I added some printf's before the call to findClosest(pos, maxRange,
&filter) in f_airportinfo()

The first time through, this seems to work, it returns a valid pointer,
which gets passed to hashForAirport(c, apt) a few lines later.

In hashForAirport() I also printed the name and id that FGAirport *apt
points to.  The first time through it prints "id = 58Q  name = Mazza"

The crash happens on the second time through this call sequence.

The second call to f_airportinfo() seems to follow the same logic and get
the same answer.  The FGAirport *apt pointer returned by findClosest() is
the same value as previously.  However when passing this to
hashForAirport() it appears that the references it apt->ident() and
apt->name() trigger a segfault.

I tried running with valgrind and the error didn't happen -- hmmm...

Trying it again, but a valgrind startup is excruciatingly slow ...

Curt.


On Tue, Apr 24, 2012 at 8:45 AM, James Turner  wrote:

>
> On 24 Apr 2012, at 14:39, Curtis Olson wrote:
>
> > For what it's worth, I'm seeing nearly the same thing ... similar back
> trace-- crashing in hashforairport() about 10-15 seconds after the splash
> screen has been removed and the sim presented for use.
>
> Okay, that's good news since it rules out something Thorsten specific. Can
> you see if the FGAirport* being passed to hashForAirport looks like a valid
> pointer?
>
> James
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>



-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Scott Hamilton]

  

See if this makes sense?? 

(gdb) frame 1
#1 0x0088fb79 in
hashForAirport (c=0x19e62860, apt=0x6a128d0) at
/home/scotth/Download/Flightgear/git-repo/flightgear/src/Scripting/NasalPositioned.cxx:113
113
std::string name = apt->name();
(gdb) print apt
$1 = (const FGAirport
*) 0x6a128d0
(gdb) print c
$2 = (Context *) 0x19e62860
(gdb) print
apt->name
$3 = {const std::string &(const FGAirport * const)} 0x6609c0

(gdb) print apt->name()
Program received signal SIGSEGV, Segmentation
fault.0x006609c0 in ?? ()
The program being debugged was
signaled while in a function called from GDB.
GDB remains in the frame
where the signal was received.
To change this behavior use "set
unwindonsignal on".
Evaluation of the expression containing the
function(at 0x0x6609c0) will be abandoned.
When the function is done
executing, GDB will silently stop.
(gdb)  

S. 

On Tue, 24 Apr 2012
14:45:17 +0100, James Turner wrote: 

> On 24 Apr 2012, at 14:39, Curtis
Olson wrote:
> 
>> For what it's worth, I'm seeing nearly the same thing
... similar back trace-- crashing in hashforairport() about 10-15
seconds after the splash screen has been removed and the sim presented
for use.
> Okay, that's good news since it rules out something Thorsten
specific. Can you see if the FGAirport* being passed to hashForAirport
looks like a valid pointer? James
--
Live Security Virtual Conference Exclusive live event will cover all
the ways today's security and threat landscape has changed and how IT
managers can respond. Discussions will include endpoint security, mobile
security and the latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ [1]
___ Flightgear-devel mailing
list Flightgear-devel@lists.sourceforge.net [2]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel [3]

 


Links:
--
[1]
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
[2]
mailto:Flightgear-devel@lists.sourceforge.net
[3]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[James Turner]

On 24 Apr 2012, at 14:39, Curtis Olson wrote:

> For what it's worth, I'm seeing nearly the same thing ... similar back 
> trace-- crashing in hashforairport() about 10-15 seconds after the splash 
> screen has been removed and the sim presented for use.

Okay, that's good news since it rules out something Thorsten specific. Can you 
see if the FGAirport* being passed to hashForAirport looks like a valid pointer?

James


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Curtis Olson]

On Tue, Apr 24, 2012 at 7:39 AM, James Turner  wrote:

>
> On 24 Apr 2012, at 12:07, Renk Thorsten wrote:
>
> > It doesn't depend - I got a crash at TNCM as well, also using both c172p
> and the ufo. So this must be something more generic.
> >
> >> Just to check, you have updated simgear as well? There's a bugfix in
> >> there I applied at the same time.
> >
> > I did pull simgear, when I retry now I get 'Already up-to-date.' and I
> did recompile both simgear and flightgear after 'make clean' in both build
> directories using the same procedures I've been using since we migrated to
> cmake. So to my best ability to tell, my simgear is up to date.
>
> Okay, then I realise this isn't useful for you, but I'm stumped why it
> crashes for you. In particular, the hashForAirport function is being passed
> something that looks like a valid pointer (I think), and it crashing on a
> line that should only really happen if the pointer is invalid, or there's
> other memory corruption going on.
>
> Again, I realise this doesn't help you, I'm just confused by the failure
> mode.


For what it's worth, I'm seeing nearly the same thing ... similar back
trace-- crashing in hashforairport() about 10-15 seconds after the splash
screen has been removed and the sim presented for use.

Linux, fedora 15, nvidia graphics ...

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[James Turner]

On 24 Apr 2012, at 12:07, Renk Thorsten wrote:

> It doesn't depend - I got a crash at TNCM as well, also using both c172p and 
> the ufo. So this must be something more generic. 
> 
>> Just to check, you have updated simgear as well? There's a bugfix in  
>> there I applied at the same time.
> 
> I did pull simgear, when I retry now I get 'Already up-to-date.' and I did 
> recompile both simgear and flightgear after 'make clean' in both build 
> directories using the same procedures I've been using since we migrated to 
> cmake. So to my best ability to tell, my simgear is up to date.

Okay, then I realise this isn't useful for you, but I'm stumped why it crashes 
for you. In particular, the hashForAirport function is being passed something 
that looks like a valid pointer (I think), and it crashing on a line that 
should only really happen if the pointer is invalid, or there's other memory 
corruption going on.

Again, I realise this doesn't help you, I'm just confused by the failure mode.

James


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Renk Thorsten]

> Okay, this is my fault, but I don't know why / how it's crashing for  
> you. Presumably you have some aircraft or nasal that makes additional  
> airportinfo() calls, and you've managed to find a test-case that my  
> testing has not encountered. Unfortunately we need to find out the  
> relevant bit of Nasal I guess.
>
> I can see it's an airportinfo() call with no arguments, which location  
> are you at? KSFO right? H.

It doesn't depend - I got a crash at TNCM as well, also using both c172p and 
the ufo. So this must be something more generic. 

> Just to check, you have updated simgear as well? There's a bugfix in  
> there I applied at the same time.

I did pull simgear, when I retry now I get 'Already up-to-date.' and I did 
recompile both simgear and flightgear after 'make clean' in both build 
directories using the same procedures I've been using since we migrated to 
cmake. So to my best ability to tell, my simgear is up to date.

* Thorsten


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[James Turner]

On 24 Apr 2012, at 11:41, Renk Thorsten wrote:

> Here's the output:
> 
> (gdb) bt
> #0  0x5e3d9a08 in ?? ()
> #1  0x088dd542 in hashForAirport (c=0x13bedd28, apt=0xdcd3988)
>at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:113
> #2  0x088ddc29 in f_airportinfo (c=0x13bedd28, me=
>{num = nan(0xf6789), ref = {ptr = {obj = 0x0, str = 0x0, vec = > 0
> x0, hash = 0x0, code = 0x0, func = 0x0, ccode = 0x0, ghost = 0x0}, reftag = 
> 2147
> 444617}}, argc=0, args=0x13bee934)
>at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:416
> #3  0x08c89a55 in setupFuncall (ctx=0x13bedd28, nargs=0, mcall=0, named=0)

Okay, this is my fault, but I don't know why / how it's crashing for you. 
Presumably you have some aircraft or nasal that makes additional airportinfo() 
calls, and you've managed to find a test-case that my testing has not 
encountered. Unfortunately we need to find out the relevant bit of Nasal I 
guess.

I can see it's an airportinfo() call with no arguments, which location are you 
at? KSFO right? H.

If I launch at KSFO, I get no crash, and I can make airportinfo() calls in the 
Nasal console with no problems.

Just to check, you have updated simgear as well? There's a bugfix in there I 
applied at the same time.

James


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Renk Thorsten]

Oops, missed that part of the instructions *blush*

Here's the output:

(gdb) bt
#0  0x5e3d9a08 in ?? ()
#1  0x088dd542 in hashForAirport (c=0x13bedd28, apt=0xdcd3988)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:113
#2  0x088ddc29 in f_airportinfo (c=0x13bedd28, me=
{num = nan(0xf6789), ref = {ptr = {obj = 0x0, str = 0x0, vec = 0
x0, hash = 0x0, code = 0x0, func = 0x0, ccode = 0x0, ghost = 0x0}, reftag = 2147
444617}}, argc=0, args=0x13bee934)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:416
#3  0x08c89a55 in setupFuncall (ctx=0x13bedd28, nargs=0, mcall=0, named=0)
at /home/fgfs/CMake/simgear/simgear/nasal/code.c:316
#4  0x08c8ca02 in run (ctx=0x13bedd28)
at /home/fgfs/CMake/simgear/simgear/nasal/code.c:681
#5  0x08c8d4e0 in naCall (ctx=0x13bedd28, func=
{num = nan(0xf6789151a161c), ref = {ptr = {obj = 0x151a161c, str = 0x151
a161c, vec = 0x151a161c, hash = 0x151a161c, code = 0x151a161c, func = 0x151a161c
, ccode = 0x151a161c, ghost = 0x151a161c}, reftag = 2147444617}}, argc=0, 
args=0x0, obj=
{num = nan(0xf6789), ref = {ptr = {obj = 0x0, str = 0x0, vec = 0
x0, hash = 0x0, code = 0x0, func = 0x0, ccode = 0x0, ghost = 0x0}, reftag = 2147
444617}}, locals=
{num = nan(0xf67891503efc0), ref = {ptr = {obj = 0x1503efc0, str = 0x150
3efc0, vec = 0x1503efc0, hash = 0x1503efc0, code = 0x1503efc0, func = 0x1503efc0
, ccode = 0x1503efc0, ghost = 0x1503efc0}, reftag = 2147444617}})
---Type  to continue, or q  to quit---
at /home/fgfs/CMake/simgear/simgear/nasal/code.c:846
#6  0x088cba4b in FGNasalSys::call (this=0x13f77098, code=
{num = nan(0xf6789151a161c), ref = {ptr = {obj = 0x151a161c, str = 
0x151a161c, vec = 0x151a161c, hash = 0x151a161c, code = 0x15
1a161c, func = 0x151a161c, ccode = 0x151a161c, ghost = 0x151a161c}, reftag = 
2147444617}}, argc=0, 
args=0x0, locals=
{num = nan(0xf6789), ref = {ptr = {obj = 0x0, str = 0x0, vec = 
0x0, hash = 0x0, code = 0x0, func = 0x0, ccode = 0x0, gh
ost = 0x0}, reftag = 2147444617}}) at 
/home/fgfs/CMake/flightgear/src/Scripting/NasalSys.cxx:113
#7  0x088cbe27 in FGNasalSys::handleTimer (this=0x13f77098, t=0xa115d1a8)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalSys.cxx:879
#8  0x088cbe5d in FGNasalSys::NasalTimer::timerExpired (this=0xa115d1a8)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalSys.cxx:897
#9  0x088cfbb3 in SGMethodCallback::operator() (this=0xa115d1e0)
at /home/fgfs/FG/include/simgear/structure/callback.hxx:117
#10 0x08cfd50a in SGTimer::run (this=0xa115d1f8)
at /home/fgfs/CMake/simgear/simgear/structure/event_mgr.cxx:38
#11 0x08cfdd4a in SGTimerQueue::update (this=0xaca3824, 
deltaSecs=0.1)
at /home/fgfs/CMake/simgear/simgear/structure/event_mgr.cxx:112
#12 0x08cfe07d in SGEventMgr::update (this=0xaca37f0, 
delta_time_sec=0.1)
---Type  to continue, or q  to quit---
at /home/fgfs/CMake/simgear/simgear/structure/event_mgr.cxx:43
#13 0x08d01252 in SGSubsystemGroup::Member::update (this=0x12e496d8, 
delta_time_sec=0.1)
at /home/fgfs/CMake/simgear/simgear/structure/subsystem_mgr.cxx:361
#14 0x08d01a18 in SGSubsystemGroup::update (this=0xaca3780, 
delta_time_sec=0.1)
at /home/fgfs/CMake/simgear/simgear/structure/subsystem_mgr.cxx:221
#15 0x08cffb94 in SGSubsystemMgr::update (this=0xaca3650, 
delta_time_sec=0.1)
at /home/fgfs/CMake/simgear/simgear/structure/subsystem_mgr.cxx:448
#16 0x08577c44 in fgMainLoop ()
at /home/fgfs/CMake/flightgear/src/Main/main.cxx:220
#17 0x0855c69f in fgOSMainLoop ()
at /home/fgfs/CMake/flightgear/src/Main/fg_os_osgviewer.cxx:284
#18 0x08575979 in fgMainInit (argc=6, argv=0xbf8aba94)
at /home/fgfs/CMake/flightgear/src/Main/main.cxx:549
#19 0x08541a33 in main (argc=6, argv=0xbf8aba94)
at /home/fgfs/CMake/flightgear/src/Main/bootstrap.cxx:252

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[James Turner]

On 24 Apr 2012, at 11:31, Renk Thorsten wrote:

> Program received signal SIGSEGV, Segmentation fault.
> 0x5e3d9a08 in ?? ()
> Missing separate debuginfos, use: debuginfo-install e2fsprogs.i386 gcc.i386 
> glibc.i686 libICE.i386 libSM.i386 libX11.i386 libXau.i386 libXcursor.i386 
> libXdmcp.i386 libXext.i386 libXfixes.i386 libXrender.i386 libjpeg.i386 
> libpng.i386 libxcb.i386 mesa.i386 zlib.i386
> 
> Not sure that helps... certainly doesn't look very telling to me...

Okay, if you type 'bt' at that point you should get the backtrace, which should 
help.

Although the fact you're getting '??()' is slightly worrying that your fgfs 
lacks debug information.

James


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Renk Thorsten]

>>> Can you get a backtrace?

Okay, following your instructions I did make clean in any of my build folders, 
ran cmake with -DCMAKE_BUILD_TYPE=Debug added, recompiled simgear and 
flightgear, and did


gdb ./fgfs
run --log-level=info --airport=KSFO --disable-real-weather-fetch 
--disable-fullscreen --geometry=1200x900


There follows a long log of essentially normal status messages (which I can 
also get you if your really like), terminating rather suddenly with

(...)
Loading tile 942040.stg
  Generating ocean tile
Loading tile 942072.stg
Loading stg file 
/home/fgfs/FGData/fgdata/Scenery/Terrain/w130n30/w123n37/942072.stg
Loading tile 958424.stg
Loading stg file 
/home/fgfs/FGData/fgdata/Scenery/Objects/w130n30/w122n37/958424.stg

Program received signal SIGSEGV, Segmentation fault.
0x5e3d9a08 in ?? ()
Missing separate debuginfos, use: debuginfo-install e2fsprogs.i386 gcc.i386 
glibc.i686 libICE.i386 libSM.i386 libX11.i386 libXau.i386 libXcursor.i386 
libXdmcp.i386 libXext.i386 libXfixes.i386 libXrender.i386 libjpeg.i386 
libpng.i386 libxcb.i386 mesa.i386 zlib.i386

Not sure that helps... certainly doesn't look very telling to me...

Cheers,

* Thorsten
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Renk Thorsten]

> I had similar problem this weekend, and a full rebuild (simgear +
> flightgear) solved the issue. I have the sentiment that changes
> to SGReferenced (in simgear) could have created this instability

I pulled everything fresh and compiled both simgear and flightgear new, so 
things shouldn't be out of sync...

> That's much more likely to be me - does disabling traffic stop the crash?

The problem does occur despite 

--prop=/sim/traffic-manager/enabled=false

in the commandline. It appears rather regular though, so there's not much 
scattering in the timescale associated.

> (re-)Build fgfs with debug symbols:
>
>   -DCMAKE_BUILD_TYPE=Debug
>
> when running cmake, might need to make clean + make again
>
> then run fgfs
>
> gdb fgfs
> run --log-level=info --airport=KSFO --some-other-options-to-fgfs
>
>  wait for the crash ...
>
> bt
>  copy and paste what gets spewed out into email 


I will have a look at that, but that takes more time than I have on my hands 
right now :-(

* Thorsten
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[James Turner]

On 24 Apr 2012, at 09:20, Renk Thorsten wrote:

>> Can you get a backtrace?
> 
> I can try if you tell me what I need to do...

(re-)Build fgfs with debug symbols:

-DCMAKE_BUILD_TYPE=Debug

when running cmake, might need to make clean + make again

then run fgfs

gdb fgfs
run --log-level=info --airport=KSFO --some-other-options-to-fgfs

 wait for the crash ...

bt
 copy and paste what gets spewed out into email 

> 
>> I've made a change to the startup sequence,  
>> yesterday, but I would expect it to crash later (after scenery loading),  
>> ten seconds sounds too early.
> 
> Misunderstanding: After scenery loading and I find myself in the cockpit, I 
> have 10 seconds to look around, then comes the crash.

That's much more likely to be me - does disabling traffic stop the crash?

(And does re-winding Git to yesterday morning also stop it?)

James


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Frederic Bouvier]

Hi Thorsten,

> > Can you get a backtrace?
> 
> I can try if you tell me what I need to do...
> 
> >  I've made a change to the startup sequence,
> > yesterday, but I would expect it to crash later (after scenery
> > loading),
> > ten seconds sounds too early.
> 
> Misunderstanding: After scenery loading and I find myself in the
> cockpit, I have 10 seconds to look around, then comes the crash.

I had similar problem this weekend, and a full rebuild (simgear +
flightgear) solved the issue. I have the sentiment that changes 
to SGReferenced (in simgear) could have created this instability

Regards,
-Fred


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[Renk Thorsten]

> Can you get a backtrace?

I can try if you tell me what I need to do...

>  I've made a change to the startup sequence,  
> yesterday, but I would expect it to crash later (after scenery loading),  
> ten seconds sounds too early.

Misunderstanding: After scenery loading and I find myself in the cockpit, I 
have 10 seconds to look around, then comes the crash. 

* Thorsten
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT as of today unstable

[James Turner]

On 24 Apr 2012, at 09:04, Renk Thorsten wrote:

> I've just pulled and compiled simgear and flightgear and pulled a fresh 
> FGData to start package the next lightfield shader version, but it turns out 
> the resulting binary is unstable.
> 
> I get segfaults about 10 seconds after startup with the master branch, no 
> other errors written to the console, apparently independent on what I do or 
> how I set options on startup. Memory consumption in the system monitor looks 
> normal, reverting back to the old version pulled two weeks ago restores 
> stability, so it's not just some fluke of my machine.

Can you get a backtrace? I've made a change to the startup sequence, yesterday, 
but I would expect it to crash later (after scenery loading), ten seconds 
sounds too early.

James


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git question

[Ron Jensen]

On Sunday 19 February 2012 15:28:05 Scott wrote:
> On Sun, 2012-02-19 at 14:40 -0700, dave perry wrote:
> > On 02/19/2012 02:06 PM, Torsten Dreyer wrote:
> > > Am 19.02.2012 21:54, schrieb dave perry:
> > >> Hi All,
> > >>
> > >> I have been gone for almost a year.  I want to start new source trees
> > >> for simgear and flightgear and track on going development.  Which git
> > >> branches should I "check out" in this new set of directories?  And
> > >> from the e-mails I have read from the developers list, is appears that
> > >> fgdata still has all the aircraft under development.
> > >>
> > >> I plan to rate all the AC I have made significant contributions to via
> > >> the published rules and push them to the repository.
> > >
> > > Hi Dave,
> > >
> > > welcome back! The latest development is in 'next' for SimGear and
> > > FlightGear and 'master' for fgdata. Yes, fgdata still holds all
> > > aircraft.
> > >
> > > Some basic instructions are in the wiki:
> > > http://wiki.flightgear.org/Git
> > >
> > > Torsten
> > >
> > > ---
> > >--- Virtualization&  Cloud Management Using Capacity Planning
> > > Cloud computing makes use of virtualization - but cloud computing
> > > also focuses on allowing computing to be delivered as a service.
> > > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > > ___
> > > Flightgear-devel mailing list
> > > Flightgear-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/flightgear-devel
> >
> > Thanks Torsten,
> >
> > The wiki link is just what I needed to refresh my memory.  I their a
> > similar reference for the change to cmake?
> >
> > Dave P.
>
> There is a README.cmake in the top level directory once you clone the
> repository that is quite helpful. There is also the wiki page at
> http://wiki.flightgear.org/Building_using_CMake
>
> Typing cmake and hitting the search button will find that for you from
> the wiki front page :)
>
>
> S.



http://wiki.flightgear.org/Talk:Building_using_CMake

I put some notes on the discussion page for that page, too...

Ron


--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git question

[Scott]

On Sun, 2012-02-19 at 14:40 -0700, dave perry wrote:
> On 02/19/2012 02:06 PM, Torsten Dreyer wrote:
> > Am 19.02.2012 21:54, schrieb dave perry:
> >> Hi All,
> >>
> >> I have been gone for almost a year.  I want to start new source trees
> >> for simgear and flightgear and track on going development.  Which git
> >> branches should I "check out" in this new set of directories?  And from
> >> the e-mails I have read from the developers list, is appears that fgdata
> >> still has all the aircraft under development.
> >>
> >> I plan to rate all the AC I have made significant contributions to via
> >> the published rules and push them to the repository.
> > Hi Dave,
> >
> > welcome back! The latest development is in 'next' for SimGear and
> > FlightGear and 'master' for fgdata. Yes, fgdata still holds all aircraft.
> >
> > Some basic instructions are in the wiki:
> > http://wiki.flightgear.org/Git
> >
> > Torsten
> >
> > --
> > Virtualization&  Cloud Management Using Capacity Planning
> > Cloud computing makes use of virtualization - but cloud computing
> > also focuses on allowing computing to be delivered as a service.
> > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > ___
> > Flightgear-devel mailing list
> > Flightgear-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/flightgear-devel
> >
> Thanks Torsten,
> 
> The wiki link is just what I needed to refresh my memory.  I their a 
> similar reference for the change to cmake?
> 
> Dave P.


There is a README.cmake in the top level directory once you clone the
repository that is quite helpful. There is also the wiki page at
http://wiki.flightgear.org/Building_using_CMake

Typing cmake and hitting the search button will find that for you from
the wiki front page :)


S.



--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git question

[dave perry]

On 02/19/2012 02:06 PM, Torsten Dreyer wrote:
> Am 19.02.2012 21:54, schrieb dave perry:
>> Hi All,
>>
>> I have been gone for almost a year.  I want to start new source trees
>> for simgear and flightgear and track on going development.  Which git
>> branches should I "check out" in this new set of directories?  And from
>> the e-mails I have read from the developers list, is appears that fgdata
>> still has all the aircraft under development.
>>
>> I plan to rate all the AC I have made significant contributions to via
>> the published rules and push them to the repository.
> Hi Dave,
>
> welcome back! The latest development is in 'next' for SimGear and
> FlightGear and 'master' for fgdata. Yes, fgdata still holds all aircraft.
>
> Some basic instructions are in the wiki:
> http://wiki.flightgear.org/Git
>
> Torsten
>
> --
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
Thanks Torsten,

The wiki link is just what I needed to refresh my memory.  I their a 
similar reference for the change to cmake?

Dave P.


--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git question

[Torsten Dreyer]

Am 19.02.2012 21:54, schrieb dave perry:
> Hi All,
>
> I have been gone for almost a year.  I want to start new source trees
> for simgear and flightgear and track on going development.  Which git
> branches should I "check out" in this new set of directories?  And from
> the e-mails I have read from the developers list, is appears that fgdata
> still has all the aircraft under development.
>
> I plan to rate all the AC I have made significant contributions to via
> the published rules and push them to the repository.

Hi Dave,

welcome back! The latest development is in 'next' for SimGear and 
FlightGear and 'master' for fgdata. Yes, fgdata still holds all aircraft.

Some basic instructions are in the wiki:
http://wiki.flightgear.org/Git

Torsten

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Git rebase, not merge (for simgear / flightgear commits)

[Gijs de Rooy]

Hi James,

thanks for bringing this up (again)! Last Sunday I actualy started documenting 
the use of rebase when 
applying mere-requests: http://wiki.flightgear.org/Git#Merge_requests Would be 
nice if you (and others,
like our Git-pro AndersG) could extend/correct it ;)

In the "new" git rules we encourage people to use merge requests whenever 
possible, so we better 
document how to apply them nicely!



Gijs  --
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits? 
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Git rebase, not merge (for simgear / flightgear commits)

[James Turner]

On 14 Dec 2011, at 09:32, Anders Gidenstam wrote:

> If your topic is freshly rebased it will just be a fast-forward merge, 
> that is, your new commits are just added to the history of master.
> Nice and linear IMHO.. :)

Yes, sorry, I didn't express that clearly at all - thanks Anders!

James


--
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits? 
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Git rebase, not merge (for simgear / flightgear commits)

[Anders Gidenstam]

On Wed, 14 Dec 2011, James Turner wrote:

> Of course, when you do finally merge your topic into next, that's a 
> merge - because we do all care about recording that action in the 
> history.

If your topic is freshly rebased it will just be a fast-forward merge, 
that is, your new commits are just added to the history of master.
Nice and linear IMHO.. :)

Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://gitorious.org/anders-hangar
  http://www.gidenstam.org/FlightGear/

--
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits? 
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT add airplane/scenery

[Durk Talsma]

As far as my (still limited) understanding goes, gitorious needs to know the 
public SSH key of the machine you're uploading from.  Just login at gitorious, 
go to dashboard, and click Manage SSH keys.

HTH,
Durk

On 03 Nov 2011, at 09:03, Michael Sgier wrote:

> Ok I did a fgdata clone:
> 
> https://gitorious.org/~scrat/fg/scrats-fgdata
> 
> 
> 
> and pulled that ~3.5GB. Now I've added the aircrafts but push gives:
> 
> 
> 
> michael@ubuntu:/media/DATA/FGFS/install/fgfs/fgdata$ git push origin master
> fatal: protocol error: expected sha/ref, got '
> --
> The git:// protocol is read-only.
> 
> Please use the push url as listed on the repository page.
> --'
> michael@ubuntu:/media/DATA/FGFS/install/fgfs/fgdata$ git push 
> git://gitorious.org/~scrat/fg/scrats-fgdata.git
> fatal: protocol error: expected sha/ref, got '
> --
> The git:// protocol is read-only.
> 
> Please use the push url as listed on the repository page.
> --'
> 
> 
> 
> 
> 
> Thanks again. fgdata is still not splitted? It also seems to be incompatible 
> 
> to my fgfs git...maybe need to update that as well?
> 
> 
> 
> 
> 
> 
> 
> --
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT add airplane/scenery

[Martin Spott]

Michael Sgier wrote:

> Ok I did a fgdata clone:https://gitorious.org/~scrat/fg/scrats-fgdata

Why did you go through all the hassle of creating an isolated workspace
instead of cloning the repo directly at Gitorious ?

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT add airplane/scenery

[Michael Sgier]

Ok I did a fgdata clone:https://gitorious.org/~scrat/fg/scrats-fgdata

and pulled that ~3.5GB. Now I've added the aircrafts but push gives:
michael@ubuntu:/media/DATA/FGFS/install/fgfs/fgdata$ git push origin master
fatal: protocol error: expected sha/ref, got '
--
The git:// protocol is read-only.

Please use the push url as listed on the repository page.
--'
michael@ubuntu:/media/DATA/FGFS/install/fgfs/fgdata$ git push 
git://gitorious.org/~scrat/fg/scrats-fgdata.git
fatal: protocol error: expected sha/ref, got '
--
The git:// protocol is read-only.

Please use the push url as listed on the repository page.
--'


Thanks again. fgdata is still not splitted? It also seems to be incompatible 
to my fgfs git...maybe need to update that as well?


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT add airplane/scenery

[Gijs de Rooy]

> Michael wrote:> If I do a git merge, as above, it seems to put into a wrong 
> directory? Any changes needed? 
> And how/who to ask for Flightgear inclusion?
You cannot simply merge a subdirectory. You should clone fgdata, add your 
aircraft to your
clone and then request a merge from that one.
See http://wiki.flightgear.org/FlightGear_and_Git#Cloning_fgdata
and http://wiki.flightgear.org/FlightGear_Git_on_Windows (written for windows,
but the commands work similar on other OS)

Gijs  --
RSA® Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT add airplane/scenery

[Michael Sgier]

Ok so now I've added it as:

http://www.flightgear.org/forums/viewtopic.php?f=4&t=11040&start=60

If I do a git merge, as above, it seems to put into a wrong directory? Any 
changes needed? 
And how/who to ask for Flightgear inclusion?
Thanks
Michael



--
RSA® Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT

[thorsten . i . renk]

>> Yes, true, we noticed that already. Hence we'll have to leave it as it
>> is right now. A bit unfortunate, this would have really shrunk the
>> archive significantly. But we may still be able to do that one day...
>
> The two biggest chunks in Models/ are Weather/ (110 MByte) and
> Geometry/ (35 MByte).  If we'd rip these out - just as a thought
> experiment - the rest which somehow relates to Scenemodels would be
> only 100 MByte.  That's quite small compared to most other
> subdirectories.

Half of the textures in /Weather/ will be obsolete soon (= as soon as the
new cloud rendering system runs reliably and is tested, i.e. in a month
from now?). That can potentially reduce the size here.

* Thorsten


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT

[Torsten Dreyer]

>> Um... not true. Cloud textures and models currently reside in
>> /Models/Weather/ and as far as I know are modified within fgdata, but are
>> not in the scenery database.
>
> Yes, true, we noticed that already. Hence we'll have to leave it as it
> is right now. A bit unfortunate, this would have really shrunk the
> archive significantly. But we may still be able to do that one day...
We have an Environment directory in fgdata. If we move Weather, this 
should be the right place for it.

Torsten

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT

[Martin Spott]

ThorstenB,

ThorstenB wrote:

> Yes, true, we noticed that already. Hence we'll have to leave it as it 
> is right now. A bit unfortunate, this would have really shrunk the 
> archive significantly. But we may still be able to do that one day...

The two biggest chunks in Models/ are Weather/ (110 MByte) and
Geometry/ (35 MByte).  If we'd rip these out - just as a thought
experiment - the rest which somehow relates to Scenemodels would be
only 100 MByte.  That's quite small compared to most other
subdirectories.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT

[thorsten . i . renk]

> Yes, true, we noticed that already. Hence we'll have to leave it as it
> is right now. A bit unfortunate, this would have really shrunk the
> archive significantly. But we may still be able to do that one day...

It's a finite task to move the Weather/ folder elsewhere (i.e. out of
Models/) and do a search/replace in the weather code to change to a new
location.

If you want to get it done after the airplanes have been taken out of the
repo, just let me know and I'll change the code.

* Thorsten


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT

[ThorstenB]

On 17.10.2011 09:11, thorsten.i.r...@jyu.fi wrote:
>> The "Models" folder for example, since that's not maintained there -
>> it's just a copy of what is  maintained in the scenery database
>> and we shouldn't modify it directly in fgdata.
>
> Um... not true. Cloud textures and models currently reside in
> /Models/Weather/ and as far as I know are modified within fgdata, but are
> not in the scenery database.

Yes, true, we noticed that already. Hence we'll have to leave it as it 
is right now. A bit unfortunate, this would have really shrunk the 
archive significantly. But we may still be able to do that one day...

cheers,
Thorsten



--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT

[thorsten . i . renk]

> The "Models" folder for example, since that's not maintained there -
> it's just a copy of what is  maintained in the scenery database
> and we shouldn't modify it directly in fgdata.

Um... not true. Cloud textures and models currently reside in
/Models/Weather/ and as far as I know are modified within fgdata, but are
not in the scenery database.

* Thorsten


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT

[ThorstenB]

Am 16.10.2011 20:01, schrieb Alan Teeder:
> Flightgear already has such a system for scenery.  You only download
> what you want, or need. Very few users need scenery for the whole
> world.
> Extending this concept to the bloated aircraft section of fgdata
> seems quite logical.

It's important though to see the difference between the end-user 
front-end and our developer's back-end of the system.

In fact, for end-users, we already have such a front-end for aircraft: 
http://www.flightgear.org/download/aircraft-v2-4/  ;-)
Users get a base package and only download what they need - same for 
scenery as for aircraft. It's just that the aircraft front-end is 
completely manual - which can be improved.

Now, we're changing the aircraft repository back-end, which is what 
developers are supposed to use. Note that scenery developers also don't 
use the terrasync/SVN front-end for submitting their work. And now that 
we're creating separate aircraft GIT repositories, it still isn't the 
best idea to use these for end-user deployment. GIT is great for 
development - you can merge/branch/stash nicely. But it's not really 
what an end-user needs.

> I don´t think that anyone is talking about splitting apart the core
> parts of fgdata, just the optional aircraft.

Not sure :). Once we're at it, we can also move other things out of 
fgdata, which don't really belong there. The "Models" folder for 
example, since that's not maintained there - it's just a copy of what is 
maintained in the scenery database and we shouldn't modify it directly 
in fgdata. And it's also fairly large and the second biggest part of the 
remaining archive. When all aircraft have gone, just the Texture & 
Models folders make up 50% of the remaining git archive. And their 
archive is much larger than the even biggest of our aircraft (and 
spacecraft... ;-)).
Once we start using git submodules, we can also go for a cleaner 
solution here. One or two more submodules won't make much of a difference.

> Perhaps one day someone will come up with a terrasync-like option to
> one of the front-ends ( fgrun) which will get chosen aircraft on-the
> fly when needed.

Yes, like what James is currently working on? ;-)
http://sourceforge.net/mailarchive/message.php?msg_id=27707002
http://wiki.flightgear.org/Aircraft_deployment#Proposal_from_James

He's made the proposal a while ago and is still working on it. Note, 
this is planned as an end-user front-end and supposed to be as automatic 
and convenient as downloading scenery already is. But all this is 
completely independent of the solution/repository type we're using for 
development.

cheers,
Thorsten

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT

[Alan Teeder]

Flightgear already has such a system for scenery.  You only download what 
you want, or need. Very few users need scenery for the whole world.

Extending this concept to the bloated aircraft section of fgdata seems quite 
logical.

I don´t think that anyone is talking about splitting apart the core parts of 
fgdata, just the optional aircraft.

Perhaps one day someone will come up with a terrasync-like option to one of 
the front-ends ( fgrun) which will get chosen aircraft on-the fly when 
needed.

Alan

-Original Message- 
From: Martin Spott
Sent: Saturday, October 15, 2011 7:29 PM Newsgroups: list.flightgear-devel
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] GIT

Cedric Sodhi wrote:

> Developers have buoyantly indulged in their lethargy as ever before and
> passionately ignored the topic wherever it came up.

I don't know everybody's favourites but, anyhow, maybe it's also a
matter of preferences.  Personally I'd hate having to pull dozends of
repositories just to retrieve the current state of 'fgdata'.  Therefore
I'm quite happy with the current state.

Cheers,
Martin.
-- 
Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel 


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT

[Hal V. Engel]

On Saturday, October 15, 2011 02:41:15 PM TDO_Brandano - wrote:
> Really, couldn't we just split off all the aircrafts to a separate SVN
> repository? Or to several GIT repositories? That way they could be checked
> out individually. I don't think we need the level of detailed history that
> GIT provides when it comes to aircraft data, and that way it would be
> possible for the Flightgear frontends to grab the aircrafts dynamically,
> if not even FGFS itself when using the multiplay protocol. And a developer
> should not need to download EVERY aircraft that was ever made for FGFS,
> One aircraft to test FGFS itself would be enough in most cases, and when
> checking aircraft specific issues it's a quick job updating only the one
> plane under exam.
> 
> Cheers,
> Alessandro

I don't think one aircraft is enough to test FGFS with.  Too many differences 
between these aircraft.  YASim vs. JSBSim and vastly different use of Nasal are 
just two examples.  But I think it should be possible to test everything in 
FGFS with perhaps 8 or10 aircraft and there is definitly no need to have every 
aircraft in GIT for this testing.  So the basis idea that we don't need all of 
the aircraft in GIT for testing is correct. 

Hal

> 
> > Date: Sat, 15 Oct 2011 23:33:14 +0200
> > From: flightg...@sablonier.ch
> > To: flightgear-devel@lists.sourceforge.net
> > Subject: Re: [Flightgear-devel] GIT
> > 
> > Am 15.10.11 22:41, schrieb Christopher Baines:
> > > I know of another project who's main git repository contains a script,
> > > that manages the other git repositories, this allows them to split the
> > > gigs of data they have in to more sensible chunks, without having to
> > > pull every repository individually.
> > > 
> > > Though the current state will be annoying for new developers on average
> > > speed internet connections as afaik, git cannot clone, stop half way,
> > > then continue.
> > 
> > Looks like we have to live with a mix of clueless git experience and
> > personal preferences of some administrators ?
> > 
> > Cheers, Yves
> > 
> > -
> > - All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity and more. Splunk takes this data
> > and makes sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2d-oct
> > ___
> > Flightgear-devel mailing list
> > Flightgear-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT

[Martin Spott]

Christopher Baines wrote:

> Though the current state will be annoying for new developers on average
> speed internet connections as afaik, git cannot clone, stop half way,
> then continue. 

Someone's providing a starter-package containing just the bare
repository for download via HTTP.  I don't remember the site but it
should be pretty easy to find.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT

[TDO_Brandano -]

Really, couldn't we just split off all the aircrafts to a separate SVN 
repository? Or to several GIT repositories? That way they could be checked out 
individually. I don't think we need the level of detailed history that GIT 
provides when it comes to aircraft data, and that way it would be possible for 
the Flightgear frontends to grab the aircrafts dynamically, if not even FGFS 
itself when using the multiplay protocol. And a developer should not need to 
download EVERY aircraft that was ever made for FGFS, One aircraft to test FGFS 
itself would be enough in most cases, and when checking aircraft specific 
issues it's a quick job updating only the one plane under exam.

Cheers,
Alessandro

> Date: Sat, 15 Oct 2011 23:33:14 +0200
> From: flightg...@sablonier.ch
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] GIT
> 
> Am 15.10.11 22:41, schrieb Christopher Baines:
> > I know of another project who's main git repository contains a script,
> > that manages the other git repositories, this allows them to split the
> > gigs of data they have in to more sensible chunks, without having to
> > pull every repository individually.
> >
> > Though the current state will be annoying for new developers on average
> > speed internet connections as afaik, git cannot clone, stop half way,
> > then continue.
> >
> 
> Looks like we have to live with a mix of clueless git experience and 
> personal preferences of some administrators ?
> 
> Cheers, Yves
> 
> --
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
  --
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT

[HB-GRAL]

Am 15.10.11 22:41, schrieb Christopher Baines:
> I know of another project who's main git repository contains a script,
> that manages the other git repositories, this allows them to split the
> gigs of data they have in to more sensible chunks, without having to
> pull every repository individually.
>
> Though the current state will be annoying for new developers on average
> speed internet connections as afaik, git cannot clone, stop half way,
> then continue.
>

Looks like we have to live with a mix of clueless git experience and 
personal preferences of some administrators ?

Cheers, Yves

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT

[Christopher Baines]

I know of another project who's main git repository contains a script,
that manages the other git repositories, this allows them to split the
gigs of data they have in to more sensible chunks, without having to
pull every repository individually. 

Though the current state will be annoying for new developers on average
speed internet connections as afaik, git cannot clone, stop half way,
then continue. 

On Sat, 2011-10-15 at 18:29 +, Martin Spott wrote:
> Cedric Sodhi wrote:
> 
> > Developers have buoyantly indulged in their lethargy as ever before and
> > passionately ignored the topic wherever it came up.
> 
> I don't know everybody's favourites but, anyhow, maybe it's also a
> matter of preferences.  Personally I'd hate having to pull dozends of
> repositories just to retrieve the current state of 'fgdata'.  Therefore
> I'm quite happy with the current state.
> 
> Cheers,
>   Martin.



signature.asc
Description: This is a digitally signed message part
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT

[Martin Spott]

Cedric Sodhi wrote:

> Developers have buoyantly indulged in their lethargy as ever before and
> passionately ignored the topic wherever it came up.

I don't know everybody's favourites but, anyhow, maybe it's also a
matter of preferences.  Personally I'd hate having to pull dozends of
repositories just to retrieve the current state of 'fgdata'.  Therefore
I'm quite happy with the current state.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[Durk Talsma]

Hi Michael,


On 30 Sep 2011, at 12:33, Michael Sgier wrote:


> Durk, I only saw now the lszh ai. How should I create such for other airports?
> 
> 
> 
The LSZH network was done by a very early version of taxidraw and misses a lot 
of features that were subsequently added. I still need to find some time to go 
back and work on these. I'd recommend downloading taxidraw and having a look at 
one of the more developed airports (EHAM for example, as it makes use of pretty 
much all the features available. For more background information, see: 
http://wiki.flightgear.org/Interactive_Traffic

and more specifically, see: 
http://wiki.flightgear.org/Interactive_Traffic#Ground_networks

The page needs some updating, but most information should still be adequate.

Cheers,
Durk--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[Michael Sgier]

Durk, I only saw now the lszh ai. How should I create such for other airports?
Martin, I've no problem releasing all on GPL but I won't go asking all 
authors for permission nor be responsibly for any violations.Anyone having all 
permissions, feel free to integrate my Suisse04 airports in fgfs.
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[Martin Spott]

Michael Sgier wrote:

> Martin ur a jerk.

I know  :-)

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[Michael Sgier]

Martin ur a jerk. I've told to have submitted to 850 airports maintained by 
Robin.
Pls read before rant about things you have no clue of.
Durk, sure I can also add AI if you can give me an example groundnetwork.For 
now, I took lszh as pattern.


--- On Fri, 9/30/11, Martin Spott  wrote:

From: Martin Spott 
Subject: Re: [Flightgear-devel] git
To: flightgear-devel@lists.sourceforge.net
Date: Friday, September 30, 2011, 10:05 AM

Durk Talsma wrote:

> If you have committed apt.dat files, to robin peel [...]

That's quite interesting. As far as I understood from Michael's various
rants, he doesn't license his work under the GPL - please correct me if
I'm wrong.  On the other hand, you automagically license under the GPL
by the act of submissing to Robin.
Unfortunately Robin's v8.10 file, the format which we're still using,
has been unmaintained for three years now, therefore, if I'm correct
about the licensing, Michael's effort is pretty pointless, whichever
route we take: Either we're not permitted to use it because of his
incompatible licensing or we can't because Robin's v8.10 file is
unmaintained.

Cheers,
    Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[Martin Spott]

Durk Talsma wrote:

> If you have committed apt.dat files, to robin peel [...]

That's quite interesting. As far as I understood from Michael's various
rants, he doesn't license his work under the GPL - please correct me if
I'm wrong.  On the other hand, you automagically license under the GPL
by the act of submissing to Robin.
Unfortunately Robin's v8.10 file, the format which we're still using,
has been unmaintained for three years now, therefore, if I'm correct
about the licensing, Michael's effort is pretty pointless, whichever
route we take: Either we're not permitted to use it because of his
incompatible licensing or we can't because Robin's v8.10 file is
unmaintained.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[Durk Talsma]

Hi Michael,

On 29 Sep 2011, at 08:44, Michael Sgier wrote:


> 
> Durk: I've only seen some lone hangars with terrasync but no probably not all 
> as they are for 850 format. As HB-GRAL stated some airports are way off in 
> old 810 format, so using a custom start or tower view location from my 
> groundnetworks might put you anywhere. But I've even had a dispute with 
> Robin, so I've to check back 850 airport locations as soon as they're in git.
> 
> 
> 

If you have committed apt.dat files, to robin peel than I think that we could 
consider committing your ground networks to the terrasync repository. We 
currently have already quite a few (if not most) ground networks  in the 
scenery that are based on future improvement of the scenery (in anticipation of 
the improved scenery generation process that Martin is putting a lot of effort 
into). So, if you have contributed new apt.dat info that would be used in this 
buidl process then it would be okay.  But, I suspect that your ground networks 
contain parking information only? I would rather see fully developed ground 
networks, that can also be used for AI purposes. 

So, in the end, I would recommend that instead of committing these data to the 
fgdata repository, you bundle them with your own scnery distribution instead 
(i.e. you in addition to the Terrain/ and Objects/ directories, you'd provide 
an additional Airports/ directory in your package. FlightGear 2.4.0 should be 
able to read the parking data when you include the new scenery folder in your 
path. 

Cheers
Durk--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[Anders Gidenstam]

On Thu, 29 Sep 2011, Anders Gidenstam wrote:

> For example:
>
> git remote add g...@gitorious.org:~andersg/fg/anders-fgdata.git my-fgdata

Oups, that should be

git remote add my-fgdata g...@gitorious.org:~andersg/fg/anders-fgdata.git

Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[Anders Gidenstam]

On Thu, 29 Sep 2011, Frederic Bouvier wrote:

> If you cloned the official data repository on your own machine, you 
> won't be allowed to push anything.
>
> What you have to do is to clone the repository in your own 
> gitorious.org project and then clone that clone on your own machine. As 
> it is your own project, you will be able to push into it and then submit 
> merge requests.

Now, before anyone unnecessarily goes through the pain of cloning fgdata 
again, you just need to add the git URL to your new personal 
clone at gitorious as a remote in your local fgdata clone to be able to 
push to gitorious.

For example:

git remote add g...@gitorious.org:~andersg/fg/anders-fgdata.git my-fgdata

Stores the URL to my fgdata clone at gitorious under the name my-fgdata in 
my local git clone of fgdata. (You want the gitorious SSH URL for your 
repository)


git push my-fgdata my-branch:master

Pushes the local branch named my-branch to my-fgdata (i.e. my clone of 
fgdata at gitorious) where the branch will be named master.

Cheers,

Anders
-- 
---
Anders Gidenstam
WWW: http://www.gidenstam.org/FlightGear/

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[Frederic Bouvier]

- Mail original -

> Thorsten: I had an account and created a ssh key. Now it has a red
> cross
> below ready in gitorious. Something wrong with that?

> Now the fgdata clone should be on my pc alike the fgfs wiki or where?
> How to push or put a merge request??

If you cloned the official data repository on your own machine, you won't be 
allowed to push anything. 

What you have to do is to clone the repository in your own gitorious.org 
project and then clone that clone on your own machine. As it is your own 
project, you will be able to push into it and then submit merge requests. 

Regards, 
-Fred 
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[Michael Sgier]

Thorsten: I had an account and created a ssh key. Now it has a red cross below 
ready in gitorious. Something wrong with that?
Now the fgdata clone should be on my pc alike the fgfs wiki or where? How to 
push or put a merge request??
Durk: I've only seen some lone hangars with terrasync but no probably not all 
as they are for 850 format. As HB-GRAL stated some airports are way off in old 
810 format, so using a custom start or tower view location from my 
groundnetworks might put you anywhere. But I've even had a dispute with Robin, 
so I've to check back 850 airport locations as soon as they're in git.Are 850 
already in git? Peter, I've also to adjust scenery height. Suisse04 scenery 
won't be GPL'd mainly because it uses different licences. In fact I didn't 
bother all authors about such, also because I don't like the idea of some 
people making money with freeware. Daniel Gauthier for example told me that it 
must be free of charge! Not GPL compatible then!...
http://www.swissfir.org/downloads/Scenery/Gauthier/Gauthier.html
Thanks and cheers
Michael
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[Durk Talsma]

> create mode 100644 Scenery/Airports/L/S/G/LSGS.groundnet.xml
> create mode 100644 Scenery/Airports/L/S/G/LSGS.twr.xml
> create mode 100644 Scenery/Airports/L/S/M/LSMP.groundnet.xml
> create mode 100644 Scenery/Airports/L/S/M/LSMP.twr.xml
> create mode 100644 Scenery/Airports/L/S/Z/LSZB.groundnet.xml
> create mode 100644 Scenery/Airports/L/S/Z/LSZB.twr.xml
> create mode 100644 Scenery/Airports/L/S/Z/LSZC.groundnet.xml
> create mode 100644 Scenery/Airports/L/S/Z/LSZC.twr.xml
> create mode 100644 Scenery/Airports/L/S/Z/LSZS.groundnet.xml
> create mode 100644 Scenery/Airports/L/S/Z/LSZS.twr.xml
> 


To everyone: Please note that it is our policy not to upload Scenery 
information to the fgdata repository directly. For logistical reasons, scenery 
data is committed to the custom scenery project and from there it is synched 
into the Scenery directory. For scene models and landclass data Martin Spott 
and Jon Stockill would be the first points of contact, for groundnetworks and 
possibly also tower locations, you can correct me. 

To Michael: Are your groundnet and tower files compatible with the current 
scenery, and are the released under the GPL licence? 

Cheers,
Durk--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[ThorstenB]

On 28.09.2011 14:57, Michael Sgier wrote:
> Am I doing something wrong or do I need permissions etc.?

Did you create an account on gitorious.org and add your SSH key? Next 
step then is to create a personal fgdata clone with your gitorious 
account. The idea is to push your personal changes to your own clone, 
and then place a merge request to fg/fgdata. You can't push updates 
directly to fg/fgdata (at least not unless you've been using and got 
accustomed to git + gitorious for a while - and are a regular fgdata 
contributor).

cheers,
Thorsten

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[Michael Sgier]

Weather is still broken... Ok now I try my first upload and 
get:--michael@ubuntu:/media/DATA/FGFS/install/fgfs/fgdata$ git commit 
--amend --author='Michael Sgier '
[master 8a14694] Michael Sgier first git uploads
 Author: Michael Sgier 
 Committer: michael 
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:

git config --global user.name "Your Name"
git config --global user.email y...@example.com

If the identity used for this commit is wrong, you can fix it with:

git commit --amend --author='Your Name '

 11 files changed, 874 insertions(+), 0 deletions(-)
 create mode 100644 Input/Joysticks/CH/pro-yoke-usb-zoomKeys.xml
 create mode 100644 Scenery/Airports/L/S/G/LSGS.groundnet.xml
 create mode 100644 Scenery/Airports/L/S/G/LSGS.twr.xml
 create mode 100644 Scenery/Airports/L/S/M/LSMP.groundnet.xml
 create mode 100644 Scenery/Airports/L/S/M/LSMP.twr.xml
 create mode 100644 Scenery/Airports/L/S/Z/LSZB.groundnet.xml
 create mode 100644 Scenery/Airports/L/S/Z/LSZB.twr.xml
 create mode 100644 Scenery/Airports/L/S/Z/LSZC.groundnet.xml
 create mode 100644 Scenery/Airports/L/S/Z/LSZC.twr.xml
 create mode 100644 Scenery/Airports/L/S/Z/LSZS.groundnet.xml
 create mode 100644 Scenery/Airports/L/S/Z/LSZS.twr.xml
michael@ubuntu:/media/DATA/FGFS/install/fgfs/fgdata$ git push origin master
fatal: The remote end hung up unexpectedly
michael@ubuntu:/media/DATA/FGFS/install/fgfs/fgdata$ git push 
fatal: The remote end hung up unexpectedly
michael@ubuntu:/media/DATA/FGFS/install/fgfs/fgdata$ 



Am I doing something wrong or do I need permissions etc.?
Cheers Michael




--- On Tue, 9/27/11, Curtis Olson  wrote:

From: Curtis Olson 
Subject: Re: [Flightgear-devel] git
To: "FlightGear developers discussions" 
Date: Tuesday, September 27, 2011, 5:25 PM

On Tue, Sep 27, 2011 at 4:00 AM, Michael Sgier wrote:


HiI've messed up weather in fgdata. How could i discard local changes and only 
get changes/original files? Git says to be up to date but weather is broken.

Later I'll do my first upload. (groundnetworks.xml etc.) I do alike the wiki 
and after commit simply do a git push?
Hi Michael,


If you know the specific file(s) that need to be returned to official git head 
version, then just run:
git checkout file1 file2 file3 ...
That (unceremoniously and without any confirmation) will discard your local 
changes to those named files.


Curt.-- 
Curtis Olson:http://www.atiak.com - http://aem.umn.edu/~uav/

http://www.flightgear.org - http://gallinazo.flightgear.org


-Inline Attachment Follows-

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
-Inline Attachment Follows-

___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[TDO_Brandano -]

if you just want to discard EVERYTHING back to the head version (make sure you 
are on the master branch) try this: git checkout -- .
the full stop is part of the command, btw

Alessandro.

From: curtol...@gmail.com
Date: Tue, 27 Sep 2011 10:25:56 -0500
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] git

On Tue, Sep 27, 2011 at 4:00 AM, Michael Sgier wrote:


HiI've messed up weather in fgdata. How could i discard local changes and only 
get changes/original files? Git says to be up to date but weather is broken.

Later I'll do my first upload. (groundnetworks.xml etc.) I do alike the wiki 
and after commit simply do a git push?
Hi Michael,


If you know the specific file(s) that need to be returned to official git head 
version, then just run:
git checkout file1 file2 file3 ...
That (unceremoniously and without any confirmation) will discard your local 
changes to those named files.


Curt.-- 
Curtis Olson:http://www.atiak.com - http://aem.umn.edu/~uav/

http://www.flightgear.org - http://gallinazo.flightgear.org


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel   
  --
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git

[Curtis Olson]

On Tue, Sep 27, 2011 at 4:00 AM, Michael Sgier wrote:

> Hi
>
> I've messed up weather in fgdata. How could i discard local changes and
> only get changes/original files? Git says to be up to date but weather is
> broken.
>
> Later I'll do my first upload. (groundnetworks.xml etc.) I do alike the
> wiki and after commit simply do a git push?
>

Hi Michael,

If you know the specific file(s) that need to be returned to official git
head version, then just run:

git checkout file1 file2 file3 ...

That (unceremoniously and without any confirmation) will discard your local
changes to those named files.

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT source

[Tim Moore]

Sorry that I've dropped the ball on this. I will take a look at that
code soon and try to get it into the source tree.

Tim

On Tue, May 17, 2011 at 9:58 PM,   wrote:
>> Hi Jack,
>>
>> I'm kind of slogging through a stressful day today with some other stuff
>> hanging over my head.  If the patches are intended to go into the main
>> line,
>> I'd love to have Tim take a pass at reviewing them.  For a quick hack you
>> could just do a traditional "diff -c" sort of patch if you wanted to share
>> the changes and let other people try them or take a look at the code.
>>
> Ok, let me try that.
>
> The goal is to move them into the main line at some point and a review is
> definitely in order. In the near term, a quicky would work
>
> ATM slogging through the code to understand how shaders work.  The edge
> blending will be a shader program, most likely a fragment shader at the
> pixel level. But having a tough time getting my head around how to include
> the shader in the code as part of the scene graph.  The Docs help, but
> more info than what is needed ( at least that's my impression ).  Just
> need to understand how to incorporate, say, an "edgeblend.frag" chunk of
> GLSL code into the scenegraph, It's pretty much a static set of functions
> with zero options, no fancy animation, techniques, quality-levels, or
> other predicates.
>
> The code will test the pixels in the overlap region, adjust the RGB values
> based on position and then apply a gamma correction.
>
> Any thoughts or examples from the community of a basic template and a
> howto for adding a fragment shader would help.
>
> Thanks
> Jack
>
>> Curt.
>>
>>
>> On Mon, May 16, 2011 at 11:45 PM,  wrote:
>>
>>> Hi Curt,
>>>
>>>  A while back Tim Moore offered to post the image warping code onto the
>>> GIT site. Since then I've not heard from him and emails have gone
>>> unanswered --  no idea as to why... :-(
>>>
>>> At any rate, tried to setup a GIT library myself and nothing but
>>> frustration and zero success in setting up a branch or whatever to make
>>> the code public.
>>>
>>> Might you have a moment to help me get it posted?  Would tomorrow be a
>>> good time? And best time and number to call if you have the patience to
>>> walk me through the process. Or if you're too busy, no problem -- sooner
>>> or later I'll get it figured out.  is there a good howto somewhere
>>> that would do the trick?
>>>
>>> Regards
>>> Jack
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Achieve unprecedented app performance and reliability
>>> What every C/C++ and Fortran developer should know.
>>> Learn how Intel has extended the reach of its next-generation tools
>>> to help boost performance applications - inlcuding clusters.
>>> http://p.sf.net/sfu/intel-dev2devmay
>>> ___
>>> Flightgear-devel mailing list
>>> Flightgear-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>>>
>>
>>
>>
>> --
>> Curtis Olson:
>> http://www.atiak.com - http://aem.umn.edu/~uav/
>> http://www.flightgear.org - http://gallinazo.flightgear.org
>> --
>> Achieve unprecedented app performance and reliability
>> What every C/C++ and Fortran developer should know.
>> Learn how Intel has extended the reach of its next-generation tools
>> to help boost performance applications - inlcuding clusters.
>> http://p.sf.net/sfu/intel-dev2devmay___
>> Flightgear-devel mailing list
>> Flightgear-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>>
>
>
>
> --
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by

[Heiko Schulz]

> Ron beat me to it, but I was going to suggest the same thing ... create 
> an alouette2-easy-set.xml ... or aloutte2-beginner-set.xml or something
> along those lines.  Then we can have both FDM's available and the end 
> user can choose which one they want.  A git commit war would be no fun.

I'm not sure if my sentences could be misunderstood, but exactly this was what 
I meant with "another version beside".

I don't want a "commit war" myself so I see this as well as a good solution.
And if helijah will provide something, I would be more as happy.

Heiko

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by

[Curtis Olson]

Ron beat me to it, but I was going to suggest the same thing ... create an
alouette2-easy-set.xml ... or aloutte2-beginner-set.xml or something along
those lines.  Then we can have both FDM's available and the end user can
choose which one they want.  A git commit war would be no fun.

On Wed, May 18, 2011 at 9:52 PM, Ron Jensen wrote:

> On Wednesday 18 May 2011 18:39:50 Heiko Schulz wrote:
>
> > I would like to have the old fdm back, maybe it is possible to have
> another
> > version with the easy-to-fly-fdm beside the original one.
> >
> > Any opinions about, something I missed?
> >
> > Heiko
>
> Helijah's workflow should make it dead simple to create another -set file,
> maybe alouette2-easy-set.xml to load the easy fdm. All the settings are in
> aloutte2-base.xml anyway.
>
> My $0.02
>
> Ron
>
>
> --
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>



-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by

[Ron Jensen]

On Wednesday 18 May 2011 18:39:50 Heiko Schulz wrote:

> I would like to have the old fdm back, maybe it is possible to have another
> version with the easy-to-fly-fdm beside the original one.
>
> Any opinions about, something I missed?
>
> Heiko

Helijah's workflow should make it dead simple to create another -set file, 
maybe alouette2-easy-set.xml to load the easy fdm. All the settings are in 
aloutte2-base.xml anyway.

My $0.02 

Ron

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by

[Heiko Schulz]

Hello all,


> Does anyone know, if JM-26, the author of the new fdm, is
> reading the 
> devel list or has an email address for me to contact him
> directly?
> 
> Regards
> Maik
> 

I found the author on another french FlightGear Forum.
Here you go:
http://equipe-flightgear.forumactif.com/t504-l-alouette-2

Summary of the reasons why the fdm has changed for those not able to understand 
french: 

The author JM-26 and helijah wasn't happy with the fdm, as it wasn't able that 
easy to fly as they want to have. JM-26 proposed a much more easier-to-fly-fdm.
Helijah is aware of the fact that Maik usually uses real datas, and that it is 
quite convincing. But he is just sad beeing not able to fly his own model.

Just simply because helijah wants to fly helicopters in FG but he isn't able 
to, he replaced the fdm with the changed fdm by JM-26. It may be easily to fly- 
but it is horrorible wrong. The same applies to the R44 in the repository.

I don't want to judge about, but I must admit that I'm dissapointed. I must 
admit I had no problems to fly the AlouetteII before, and I know a lot of 
others users which didn't have problems as well with this. 

I wonder why if there is a need for an easy-to-fly-helicopter, why not create a 
mod for those who need it?
But I don't think it is in the spirit of FGFS to replace a plausible and 
correct fdm with a wrong one and destroy the work of another author without 
asking him.

I would like to have the old fdm back, maybe it is possible to have another 
version with the easy-to-fly-fdm beside the original one.

Any opinions about, something I missed?

Heiko







--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by

[Maik Justus]

Hi,
Am 18.05.2011 21:09 schrieb Heiko Schulz:
>
>> If the drawbacks introduced by the new
>> FDM are really that
>> obvious and serious as you've stated here, I'd say you/we
>> should take a
>> revert of the latter change into account.
> At least the author of the first and in my eyes much more realistic fdm has 
> to decide if he accepts the new made changes or not.
>
actually I don't have a up to date Flightgear installation on my 
computer. Therefore I was not able to make a testflight with the new 
fdm. But I had a look to the xml file of the fdm and I am 99% sure, that 
this fdm has nothing to do with the flight behavior of the real aloutte 2.
Does anyone know, if JM-26, the author of the new fdm, is reading the 
devel list or has an email address for me to contact him directly?

Regards
Maik



--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by

[Heiko Schulz]

> 
> In general I'd recommend first to discuss the item with the
> author of
> the change.  

In general it is my prefered way as well. With any author just but not this one 
for some reasons.

> If the drawbacks introduced by the new
> FDM are really that
> obvious and serious as you've stated here, I'd say you/we
> should take a
> revert of the latter change into account.

At least the author of the first and in my eyes much more realistic fdm has to 
decide if he accepts the new made changes or not.

> Cheers,
>     Martin - being a veritable admirer of
> the old Alouette II (the
>              
>    real one, I mean).

Thanks
Heiko
-beeing a veritable admirer of the real one as well - I miss the sound-

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by

[Martin Spott]

Heiko Schulz wrote:

> I hate to say it, but the the new fdm is completly wrong and doesn't
> apply to the real one in any way.

In general I'd recommend first to discuss the item with the author of
the change.  If the drawbacks introduced by the new FDM are really that
obvious and serious as you've stated here, I'd say you/we should take a
revert of the latter change into account.

Cheers,
Martin - being a veritable admirer of the old Alouette II (the
 real one, I mean).
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT source

[castle]

> Hi Jack,
>
> I'm kind of slogging through a stressful day today with some other stuff
> hanging over my head.  If the patches are intended to go into the main
> line,
> I'd love to have Tim take a pass at reviewing them.  For a quick hack you
> could just do a traditional "diff -c" sort of patch if you wanted to share
> the changes and let other people try them or take a look at the code.
>
Ok, let me try that.

The goal is to move them into the main line at some point and a review is
definitely in order. In the near term, a quicky would work

ATM slogging through the code to understand how shaders work.  The edge
blending will be a shader program, most likely a fragment shader at the
pixel level. But having a tough time getting my head around how to include
the shader in the code as part of the scene graph.  The Docs help, but
more info than what is needed ( at least that's my impression ).  Just
need to understand how to incorporate, say, an "edgeblend.frag" chunk of
GLSL code into the scenegraph, It's pretty much a static set of functions
with zero options, no fancy animation, techniques, quality-levels, or
other predicates.

The code will test the pixels in the overlap region, adjust the RGB values
based on position and then apply a gamma correction.

Any thoughts or examples from the community of a basic template and a
howto for adding a fragment shader would help.

Thanks
Jack

> Curt.
>
>
> On Mon, May 16, 2011 at 11:45 PM,  wrote:
>
>> Hi Curt,
>>
>>  A while back Tim Moore offered to post the image warping code onto the
>> GIT site. Since then I've not heard from him and emails have gone
>> unanswered --  no idea as to why... :-(
>>
>> At any rate, tried to setup a GIT library myself and nothing but
>> frustration and zero success in setting up a branch or whatever to make
>> the code public.
>>
>> Might you have a moment to help me get it posted?  Would tomorrow be a
>> good time? And best time and number to call if you have the patience to
>> walk me through the process. Or if you're too busy, no problem -- sooner
>> or later I'll get it figured out.  is there a good howto somewhere
>> that would do the trick?
>>
>> Regards
>> Jack
>>
>>
>>
>>
>>
>> --
>> Achieve unprecedented app performance and reliability
>> What every C/C++ and Fortran developer should know.
>> Learn how Intel has extended the reach of its next-generation tools
>> to help boost performance applications - inlcuding clusters.
>> http://p.sf.net/sfu/intel-dev2devmay
>> ___
>> Flightgear-devel mailing list
>> Flightgear-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>>
>
>
>
> --
> Curtis Olson:
> http://www.atiak.com - http://aem.umn.edu/~uav/
> http://www.flightgear.org - http://gallinazo.flightgear.org
> --
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>



--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT source

[Curtis Olson]

Hi Jack,

I'm kind of slogging through a stressful day today with some other stuff
hanging over my head.  If the patches are intended to go into the main line,
I'd love to have Tim take a pass at reviewing them.  For a quick hack you
could just do a traditional "diff -c" sort of patch if you wanted to share
the changes and let other people try them or take a look at the code.

Curt.


On Mon, May 16, 2011 at 11:45 PM,  wrote:

> Hi Curt,
>
>  A while back Tim Moore offered to post the image warping code onto the
> GIT site. Since then I've not heard from him and emails have gone
> unanswered --  no idea as to why... :-(
>
> At any rate, tried to setup a GIT library myself and nothing but
> frustration and zero success in setting up a branch or whatever to make
> the code public.
>
> Might you have a moment to help me get it posted?  Would tomorrow be a
> good time? And best time and number to call if you have the patience to
> walk me through the process. Or if you're too busy, no problem -- sooner
> or later I'll get it figured out.  is there a good howto somewhere
> that would do the trick?
>
> Regards
> Jack
>
>
>
>
>
> --
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>



-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT strangeness

[Heiko Schulz]

Hello Luuk,

First I have to say Thanks for answering!

> When you use git rebase, it tries to
> replay your local commits on top
> of the new commits in the master branch.  If you have
> multiple commits
> to the same files locally that have also been committed
> upstream, you
> will be trying to replay old changes on top of new
> ones.  A better
> solution when you have committed upstream is probably to do
> a merge
> rather than a rebase.

I tried your method always at my beginning of using GIT, but this gaves me 
often merge errors as well especially on my edited preferences.xml.

It might be that my problem the config for the line endings was. I had changed 
it accidently and didn't noticed it. Though I'm still surprised that it worked 
a long time so I#m not sure if this was the real cause, so I will keep your 
proposal in mind.

Heiko



--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GIT strangeness

[Luuk Paulussen]

When you use git rebase, it tries to replay your local commits on top
of the new commits in the master branch.  If you have multiple commits
to the same files locally that have also been committed upstream, you
will be trying to replay old changes on top of new ones.  A better
solution when you have committed upstream is probably to do a merge
rather than a rebase.

e.g
git checkout master   # switch to master branch
git pull  # update it
git checkout master.local # switch back to the individual branch
git merge master # update it

which would leave your repository looking something like this:
*   Merge branch 'master' into master.local (master.local points to here)
|\
| * local commit 5
| * local commit 4
| * local commit 3
| * local commit 2
| * local commit 1
* | commit 10 (master points to here)
* | commit 9
* | commit 8
* | commit 7
* | commit 6
|/
* commit 5
* commit 4
* commit 3
* commit 2
* commit 1

On Thu, Mar 3, 2011 at 7:00 AM, Heiko Schulz  wrote:
> Hi,
>
> Working on my projects I usually commit my changes to my local branch several 
> time the week.
> And to be update, I pull to master and rebase from master to my local branch.
> Like that:
> git checkout master           # switch to master branch
> git pull                      # update it
> git checkout master.local     # switch back to the individual branch
> git rebase master             # update it
>
> That has been working all the time without any problem.
>
> Now I noticed a strange thing:
> At the weekend Gijs had commited my latest changes on the Ec130.
>
> After that I did the same procedure like always. But with that I got now 
> several merging conflicts messages, even regarding older commits to the ec130.
>
> That's something I wonder: only my changes to the ec130 are affected, all 
> others not.
>
> What can be the cause, and how to prevent it?
>
> Thanks
> Heiko
>
>
>
> --
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git clone -l question and observations

[Curtis Olson]

Ok, I think I figured this out.  The clue was in the error message I posted.
 I had the branch in question checked out in my main repository clone, so
the system couldn't push changes from my --local clone of the branch back
into that branch in the primary clone.

I guess that makes some sort of sense ... it avoids (reduces?) the chance of
problems pushing the changes if there are competing/conflicting changes in
the other copy of the branch.

This is almost worth a facebook status update. :-)  I just updated my
--local clone branch, made  some changes, and pushed them back into the
primary branch!   :-)

So any time someone pushes a change to the gitorious repository here is the
approximate procedure to update my local clones/branches (this is the git
replacement for the old cvs update command):

cd "primary-fgdata"
git pull
 - oops I have a branch checked out currently
git checkout master
 - oops commit any changes in the current branch
 - git diff
 - git commit
git checkout master (try again, it works)
git pull (now it works)
git checkout "primary-branch"
git merge master (to sync the upstream changes with my own "wip" branch)

But this is just in the main fgdata clone, Now cd over to my --local branch
clone.

cd "../fgdata-clone"
git pull (merge upstream changes from my local master repository that have
been merged into the master branch in the previous step.)
git diff (see what I changed locally)
git commit (commit my local changes)
git push (push these changes back into the primary branch in my original
clone of the gitoriious repository)
 - oops I have the branch checked out in my primary local  repository
- cd "../fgdata-primary"
- git checkout master
 - cd ../fgdata-clone"
git push (now it works!)

Woohoo, everything should now be consistent and in sync and all the upstream
changes should be fully merged.

Ok, so this is how I keep all my branches up to date here when ever anyone
pushes a change to the upstream gitorious repository.  Isn't that so much
superior to a one-line "cvs update" command which all this replaces ?!?!?
:-) :-) :-)

Curt.



On Sun, Feb 6, 2011 at 10:44 AM, Curtis Olson wrote:

> No one has answered yet which makes me guess (a) I didn't ask very well or
> (b) no one knows the answer, so let me try again here.
>
> I created a local clone of my fgdata repository using the --local option
> which builds hard links to the master original repository and saves lots of
> space.  The clone repository has one branch ... the one that was active in
> the source repository when I made the clone.
>
> When others push changes to the gitorious fgdata.git repository, I can then
> do a "git pull" in my "master" branch of my primary local fgdata repository.
>  Then I can switch to a branch in my master repository (git checkout) and
> run "git merge master" to merge the changes from the master branch into my
> local branch and keep the local branch in sync with everyone
> else's development work.
>
> This is all done in the original clone from gitorious.  None of this
> affects or alters my local clone repository with its mirror of a local
> branch.  However, I can go over to that local clone and run "git pull"
> (after I've merged the changes to the same branch in the master repository)
> and all those changes from the source branch get merged over into my local
> copy branch.  So git seems to be aware of the connection between the branch
> in my primary gitorious clone and the same branch in my --local clone.
>
> Here is what I can't figure out.
>
> If I make changes in my --local clone branch and commit them, they are
> there in the local clone, but don't show up in the same branch in the
> original gitorious clone repository.  It seems like it would make sense to
> run "git push" after "git commit" in my --local clone branch, but that
> produces an error:
>
> $ git push
> Counting objects: 33, done.
> Delta compression using up to 2 threads.
> Compressing objects: 100% (22/22), done.
> Writing objects: 100% (22/22), 2.79 KiB, done.
> Total 22 (delta 14), reused 0 (delta 0)
> Unpacking objects: 100% (22/22), done.
> remote: error: refusing to update checked out branch:
> refs/heads/drone-f-14b
> remote: error: By default, updating the current branch in a non-bare
> repository
> remote: error: is denied, because it will make the index and work tree
> inconsistent
> remote: error: with what you pushed, and will require 'git reset --hard' to
> match
> remote: error: the work tree to HEAD.
> remote: error:
> remote: error: You can set 'receive.denyCurrentBranch' configuration
> variable to
> remote: error: 'ignore' or 'warn' in the remote repository to allow pushing
> into
> remote: error: its current branch; however, this is not recommended unless
> you
> remote: error: arranged to update its work tree to match what you pushed in
> some
> remote: error: other way.
> remote: error:
> remote: error: To squelch this message and still keep the default
> behaviour, set
> remote: error: 'receive.d

Re: [Flightgear-devel] git clone -l question and observations

[Curtis Olson]

No one has answered yet which makes me guess (a) I didn't ask very well or
(b) no one knows the answer, so let me try again here.

I created a local clone of my fgdata repository using the --local option
which builds hard links to the master original repository and saves lots of
space.  The clone repository has one branch ... the one that was active in
the source repository when I made the clone.

When others push changes to the gitorious fgdata.git repository, I can then
do a "git pull" in my "master" branch of my primary local fgdata repository.
 Then I can switch to a branch in my master repository (git checkout) and
run "git merge master" to merge the changes from the master branch into my
local branch and keep the local branch in sync with everyone
else's development work.

This is all done in the original clone from gitorious.  None of this affects
or alters my local clone repository with its mirror of a local branch.
 However, I can go over to that local clone and run "git pull" (after I've
merged the changes to the same branch in the master repository) and all
those changes from the source branch get merged over into my local copy
branch.  So git seems to be aware of the connection between the branch in my
primary gitorious clone and the same branch in my --local clone.

Here is what I can't figure out.

If I make changes in my --local clone branch and commit them, they are there
in the local clone, but don't show up in the same branch in the original
gitorious clone repository.  It seems like it would make sense to run "git
push" after "git commit" in my --local clone branch, but that produces an
error:

$ git push
Counting objects: 33, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (22/22), done.
Writing objects: 100% (22/22), 2.79 KiB, done.
Total 22 (delta 14), reused 0 (delta 0)
Unpacking objects: 100% (22/22), done.
remote: error: refusing to update checked out branch: refs/heads/drone-f-14b
remote: error: By default, updating the current branch in a non-bare
repository
remote: error: is denied, because it will make the index and work tree
inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to
match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration
variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing
into
remote: error: its current branch; however, this is not recommended unless
you
remote: error: arranged to update its work tree to match what you pushed in
some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour,
set
remote: error: 'receive.denyCurrentBranch' configuration variable to
'refuse'.
To /home/curt/Projects/FlightGear/fgdata
 ! [remote rejected] drone-f-14b -> drone-f-14b (branch is currently checked
out)
error: failed to push some refs to '/home/curt/Projects/FlightGear/fgdata'

Does anyone understand what I am trying to do here?  Am I trying to solve
the wrong problem?  Is there a way to go forward here and keep my two copies
of my branch in sync?  Am I lost beyond the fringes of "git kludge" land?
 :-)  What's the point of creating a --local clone if you can't push the
changes back into your main repository? ... especially when you have to
leverage the matching mirrror in the main repository to keep your --local
branch in sync with upstream changes?

Thanks,

Curt.


On Sat, Feb 5, 2011 at 1:19 PM, Curtis Olson  wrote:

> Here locally I made a local clone of the fgdata repository using "git clone
> -l fgdata fgdata-wip".  That seemed to work as advertised.
>
> I noticed that the only branch available in the new local
> clone "fgdata-wip" is the branch that is active in fgdata at the time the
> clone is made  that's good to know.  It doesn't make a complete clone of
> ever branch, not even the master.
>
> I noticed that if I do a "git pull" inside fgdata-wip it *seems* to merge
> in changes from the original fgdata respository (master branch) ... I'm not
> 100% confident in that, I need to try it a few more times after some remote
> updates get pushed to the central repository.  I don't know if all the
> changes to fgdata/master are brought over, or just the ones that I'm merged
> to fgdata/wip after doing a git pull in fgdata/master.  (Isn't this fun,
> anyone still with me here?) :-)  At least if I update the branch wip branch
> in the oringal fgdata repository, the changes seemed to get brought over to
> "fgdata-wip" when I do a pull there.
>
> Now here's my question.  If I make a change inside the cloned wip branch of
> the cloned repository "fgdata-wip" and then commit it.  I don't see it show
> up in the "wip" branch of the original "fgdata" respository.  It occurred to
> me that maybe I need to do a git push to send the changes over to the
> original repository, but I get an error that is a lot of git-ese that's way
> over my head.
>
> What'

Re: [Flightgear-devel] git work flow question

[Curtis Olson]

On Wed, Jan 26, 2011 at 1:21 AM, Stefan Seifert  wrote:

> Well you don't. Often you just can leave modified files in place while
> switching
> branches. If it's not working, you still can simply git stash before
> switching. git stash creates a temporary branch and commits your local
> changes
> to that branch. git stash apply lets you get back those changes, even if
> you're on a different branch than before (it's just like a git merge
> stash).
>

Hi Stefan,

I created a new branch and then in that branch created some new files and
committed them to that subbranch.  I'm working on those new files.  Any time
I make a change to one of those files and then want to quickly switch to the
master branch I get a lot of these...

$ git checkout master
error: You have local changes to 'Aircraft/foo/bar/newfile'; cannot switch
branches (because this file doesn't exist in master and the branch switch
requires deleting it.)

Ok, I could see git stash helping, but wow, if I start getting a few
branches going, that could potentially be a lot of extra typing and a lot of
things to remember (or go and check) every time I switch branches.  When I
return to a branch do I have to remember to unstash some changes?  If I
forget (life gets complicated sometimes) am I going to waste time chasing
issues I've already fixed?

If I have several branches in play, and someone pushes an important change
to fgdata/master (possibly tied to an important change in flightgear/next)
that can almost lead to an hour of just getting my branches up to date (even
with no direct conflicting files.)

I agree that some changes that have not been committed can float back and
forth through branch switching (just not the ones I'm making right now.) :-)

I found the book "Version control with git" quite useful. Yes it's somehow
> strange to need a book for a simple tool like a VCS, but git's features are
> IMHO worth having to read a little.


I've barely had a chance to crack open my applying RCS and SCCS O'Reilly
book, and now I have to buy a new book? ... :-)

I personally wouldn't call git a simple tool.  Git takes a highly complex
problem (version control) and splits it up into just about the smallest
possible logical chunks.  Then it leaves it up to the end user to remember
which chunks to stitch together and in which order to achieve the highly
complex task.

Many common tasks are easy in git.  But some things start to become a royal
pain.  Part of this is because I need to "adapt" my work flow to be more git
compatible.  But I think part of this is that git has some limitations and
weaknesses too, and isn't completely perfect itself.

-- switching gears --

Another thing I do a lot of is work on projects that put me out in the field
or traveling.  So I like to maintain my projects across multiple machines
... my office desktop pc, my laptop, possibly other machines too depending
on the project.

If I'm doing FlightGear based work, and I want to create a special branch
for my little project, *and* I want to share that branch across multiple
PC's and possibly do work at times from any of these PC's ... then I need to
create that branch on a server some place.  Do I want to pollute the
official flightgear repository with a bunch of branches solely for the
purpose of my little side adventures?  Do I create a separate clone on a
separate server and then try to keep those in sync?  At some point I'm going
to have to sit down and think through the whole process of the best way to
share a "private" branch across multiple PC's ... and keep those all in sync
with each other and the official master repository.

It should be doable I think, but sounds to me like it will require typing a
lot of commands in the right order to make it work right ...

I'm sure there are many ways to make this all work cleanly, but the question
I have is if there's a way to do it that isn't too kludgey/hackish, isn't
too brittle and easily broken by upstream changes, and doesn't require an
unreasonable amount of command steps to accomplish.

Regards,

Curt.
-- 
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org -
http://www.flightgear.org/blogs/category/curt/
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git work flow question

[Andy Ross]

[saw this in time to de-lurk]

On 01/25/2011 11:22 AM, Anders Gidenstam wrote:
> I suspect the option --local to git clone might be useful.
> I have not tried myself, though.

Yeah, this is the best answer for this kind of problem.

The .git directory ends up being near-zero size (so long as the deltas
between trees are small), and you pay only for the copy of the active
tree.  So resource consumption is more or less the same as having two
"checkouts" of a remote tree.

You do have to manage the extra steps required to push/pull/merge
between the trees though.

Andy

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] git work flow question

[Martin Spott]

Curtis Olson wrote:

> The other implication here is that it would be extremely handy to have
> multiple branches checked out simultaneously for other reasons.  git makes
> branching easy, yes, but if you find yourself bouncing between branches with
> changes for separate projects, and external events may require you to jump
> to a different branch at a moments notice, It's a major PITA to have to
> commit every little thing you are in the middle of to switch to another
> branch.
> 
> This is like having to completely clean up your desk before you can work on
> a new task, and then clean it up again completely before you can jump to the
> next.

I think you're looking after having multiple local clones of the same
repository where you're checking out a different branch in each of
them,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel