Hello,
i have recently created many bigger scenery chunks with Corine Landcover and
OSM line data. Yesterday I wanted to do the same for all of the UK and
Ireland. Then I encountered some problems:
I encountered unknown runway surface errors, caused by some strange
heliport runways (see EGTG).
Hi Christian,
Christian Schmitt wrote:
I encountered unknown runway surface errors, caused by some strange
heliport runways (see EGTG). I created a patch to circumvent this for now:
https://gitorious.org/papillon81/terragear-
cs/commit/263a1cdd537bd07e2d5a503b38043f8faee29e38
I don't
Martin Spott wrote:
I don't remember all the details from the top of my head, but I'm
pretty certain that processing heliports requires a few more changes. I
usually pre-process the 'apt.dat' files, making simple tarmac from the
helipad squares (thus loosing the helipad-tag, but better than
Martin Spott wrote:
After that genapts segfaulted during EGKK processing [...]
Did you use the 'public' apt.dat file from MapServer ?
Yes, indeed. I hope i'll be able to really get down to the problem today. I
still have no exact clue what caused it, although I recompiled with several
Martin Spott wrote:
http://mapserver.flightgear.org/Heliport.pl
Well, I'd rather get it right in genapts and I'm sure it's not too difficult
to accomplish.
Chris
--
Benefiting from Server Virtualization: Beyond
Christian Schmitt wrote:
Martin Spott wrote:
http://mapserver.flightgear.org/Heliport.pl
Well, I'd rather get it right in genapts [...]
Sure, would be preferred. The above is just a quick hack (but
functional) and was meant as a hint to which places might be worth
looking at.
[...]
Christian Schmitt wrote:
After that genapts segfaulted during EGKK processing and right until now I
have still not much of a clue what exactly is going on. I thought it was a
problem with compiling TG against SG and not SG-CS (all from GIT). That
showed to be wrong. Next guess was
On Sun, 17 Apr 2011 14:02:02 +0200, Christian wrote in message
20110417120036.a62241318...@mail.sigmos.de:
Christian Schmitt wrote:
After that genapts segfaulted during EGKK processing and right
until now I have still not much of a clue what exactly is going on.
I thought it was a
Christian Schmitt wrote:
-#define __FLT_EVAL_METHOD__ 0
+#define __FLT_EVAL_METHOD__ 2
I think a simple -O2 should be permitted. Does it still fail with
setting just this single option ?
I encountered this problem on an Atom-based machine and an AMD Phenom
machine. So, yes, I should
Martin Spott wrote:
-#define __FLT_EVAL_METHOD__ 0
+#define __FLT_EVAL_METHOD__ 2
I think a simple -O2 should be permitted. Does it still fail with
setting just this single option ?
The O2 flag was set for all tries but it's not the problem here. The problem
are certain -march options.
Arnt Karlsen wrote:
..who's code, F|S|TG, or GCC? Which gcc version(s) did you use here?
Where the problem lies in the code I don't know. But it would be SG or TG.
My GCC version is 4.4.5, OS is Gentoo.
Debian has updated gcc-4.4 and gcc-4.6 yesterday and today, may
be updating gcc-4.5 now
On Sun, 17 Apr 2011, Torsten Dreyer wrote:
Merge commit 'refs/merge-requests/84' of
git://gitorious.org/fg/fgdata into integration
commit 4a25745ea96dac35a1069a2f85f0b6e72e38ed14
Author: Victor Slavutinsky
Date: Wed Apr 13 16:19:53 2011 +0400
1) Initial adding of Vostok-1 spacecraft
On Sun, 17 Apr 2011 16:08:35 +0200, Christian wrote in message
20110417140707.e067a1318...@mail.sigmos.de:
Arnt Karlsen wrote:
..who's code, F|S|TG, or GCC? Which gcc version(s) did you use
here?
Where the problem lies in the code I don't know. But it would be SG
or TG.
..aye, and
On 16.04.2011 21:16, Anders Gidenstam wrote:
If I'm not mistaken the particles issue has been around since we got
particles, so it is apparently not that bad (leak and race
condition) in practice.
Ok, thanks! I've create a bug issue as a reminder, in case someone else
noticed the issue some
I noticed the crash appeared to be in gpc.c. This is the general polygon
clipping library code. I've spent a lot of time in that code and here are
some things for people to be aware of:
1. I believe the code is algorithmically correct.
2. The problem is primarily binary floating point
On Sun, 17 Apr 2011 16:04:17 +0200, Christian wrote in message
20110417140253.11d101318...@mail.sigmos.de:
Martin Spott wrote:
-#define __FLT_EVAL_METHOD__ 0
+#define __FLT_EVAL_METHOD__ 2
I think a simple -O2 should be permitted. Does it still fail with
setting just this single
Personal experience speaking here:
Any time you run off to find a bug in gcc, or in a driver, or you think
there' s a bug in the optimizer, or your operating system: STOP! These are
all loud and bright flashing warnings for something stupid in your own code.
If people want to spend hours
Christian Schmitt wrote:
Martin Spott wrote:
The O2 flag was set for all tries but it's not the problem here. The problem
are certain -march options. -march=core2 -mfpmath=sse for the Atom showed
the error. Settung it to a more conservative -march=prescott makes it
work. In this case it
Gene couldn't resist
-Original Message-
From: Buckle [mailto:ge...@deltasoft.com]
Sent: 17 April 2011 16:19
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Vostok-1
On Sun, 17 Apr 2011, Torsten Dreyer wrote:
Merge commit 'refs/merge-requests/84' of
On Sun, Apr 17, 2011 at 11:37 AM, Martin Spott wrote:
Christian Schmitt wrote:
Martin Spott wrote:
The O2 flag was set for all tries but it's not the problem here. The
problem
are certain -march options. -march=core2 -mfpmath=sse for the Atom
showed
the error. Settung it to a more
I thought I was going to post the first rocket but it looks like you beat me to
it! :-)
Cool!
Jon
Sent from my Samsung Captivate(tm) on ATT
--
Benefiting from Server Virtualization: Beyond Initial Workload
What perfect timing for this model too, given the recent 50th anniversary of
Yuri Gagarin's first human spaceflight.
Jon
Sent from my Samsung Captivate(tm) on ATT
--
Benefiting from Server Virtualization: Beyond Initial
Martin Spott wrote:
Well, to be more precise, it's been optimization for an incompatible
platfom ;-)
The Core2 has a slightly different instruction set from the Pentium
III, thus, if I were you, I'd let the 'native' compiler choose the
right platform optimization for you - as long as you
Jon wrote:
-Original Message-
From: S. Berndt [mailto:jonsber...@comcast.net]
Sent: 17 April 2011 18:10
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Vostok-1
What perfect timing for this model too, given the recent 50th anniversary
of Yuri Gagarin's first
Jon wrote:
-Original Message-
From: S. Berndt [mailto:jonsber...@comcast.net]
Sent: 17 April 2011 18:10
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Vostok-1
What perfect timing for this model too, given the recent 50th anniversary
of Yuri Gagarin's first
Curtis Olson wrote:
[...]
I'm trying not to add yet another iteration to the debate about the two
terms topologically correct vs. good enough, everything's already
been said (details upon request, if required), but I think one point
ought to be made very clear in this context, for those who are
Curtis Olson wrote:
Generally terragear is going to be more IO bound that compute bound anyway.
I don't think you buy yourself a whole lot by trying to squeeze a few
instructions savings into your build.
Agreed,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its
It's good to get the view from both sides of the coin. :-)
Hopefully the larger point to be made is that we are moving forward with
terragear-cs and my main point of jumping in here is to try to give some
context and hints and understanding of the basic system. There's no point
in chasing down
I wrote:
[...] Nowadays
people are creating their own public forks (ah, clones ;-) of
terragear-cs before submitting _anything_ - which is't that bad at
all [...]
This typo could be misleading as well :-)
which isn't that bad at all is what
On Sun, 17 Apr 2011, Vivian Meazza wrote:
Gene couldn't resist
-Original Message-
From: Buckle [mailto:ge...@deltasoft.com]
Sent: 17 April 2011 16:19
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Vostok-1
On Sun, 17 Apr 2011, Torsten Dreyer wrote:
Merge
Christian Schmitt wrote:
I can agree, it was surely not the 100% correct setting. But for my Phenom I
still have no clue what to do.
Does it fail even without _any_ additional compiler flag ?
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
Curtis Olson wrote:
Hopefully the larger point to be made is that we are moving forward with
terragear-cs and my main point of jumping in here is to try to give some
context and hints and understanding of the basic system. There's no point
in chasing down the wrong paths in search of bugs
On Sun, 17 Apr 2011 11:24:32 -0500, Curtis wrote in message
BANLkTim3mv6zJ9bmDE1XRK=x1foslzg...@mail.gmail.com:
Personal experience speaking here:
Any time you run off to find a bug in gcc, or in a driver, or you
think there' s a bug in the optimizer, or your operating system:
STOP! These
On Sun, 17 Apr 2011 19:41:31 + (UTC), Martin wrote in message
ioffpb$ak4c$1...@osprey.mgras.de:
Curtis Olson wrote:
Hopefully the larger point to be made is that we are moving forward
with terragear-cs and my main point of jumping in here is to try to
give some context and hints and
On Sun, Apr 17, 2011 at 2:56 PM, Arnt Karlsen a...@c2i.net wrote:
..searching this list for TerrorGear will dig up the horror
stories of its use too. ;o)
GIS on a global scale is a really really hard thing. There are tremendous
challenges in terms of data set sizes, processing time,
People who have never seen unix before and are diving in expecting to be
able to click next a couple times and have something useful pop out the
other end 3 seconds later probably will be a little terrorized by what
they find. But others who enjoy seeing dozens of machines cranking away
in
Hi,
Well, I'm glad it helps. The patch should not affect the
solution
too much in most cases, I've checked this myself.
I have tested it, and well, at least for helicopters there seems a difference.
No idea how long we have this bug now- but I guess a very long time.
I was working on
Curtis Olson wrote:
GIS on a global scale is a really really hard thing. There are tremendous
challenges in terms of data set sizes, processing time, numerical
representations, manipulating and crunching data, etc. Terrorgear is a
clever play on words, but any one who is ready to dive in
On 17 Apr 2011, at 18:10, ThorstenB wrote:
The effect/texture mystery is also solved - alas - explained. There is
a global cache in simgear/makeEffect.cxx (effectMap), and it has no
condition to ever drop anything. So, created effects always stay in
memory until shutdown - hence also
Actually, I find it rather odd that it should have all this trouble to climb in
an hover at sea level. I love the Bo105, it's my plane of choice, but making a
neat vertical take off is very hard.
Alessandro
Date: Sun, 17 Apr 2011 21:37:42 +0100
From: aeitsch...@yahoo.de
To:
Actually, I find it rather odd that it should have all this trouble to
climb in an hover at sea level. I love the Bo105, it's my plane of choice,
but making a neat vertical take off is very hard.
Alessandro
I had a fix locally but with the patch fixing the YASim issue I have now to
begin
On Sun, Apr 17, 2011 at 6:37 PM, Martin Spott martin.sp...@mgras.net wrote:
Christian Schmitt wrote:
Martin Spott wrote:
The O2 flag was set for all tries but it's not the problem here. The problem
are certain -march options. -march=core2 -mfpmath=sse for the Atom showed
the error. Settung
42 matches
Mail list logo
