To all whom it may concern, terragear has seen some bigger updates recently
and we are constantly working on improving the toolchain. This also includes
some cleanup and thus removal of older tools where better alternatives have
been developed in the last 12+ years.
I created a branch, named "pr
To whom it may concern, the former "terragear-cs" repositories on
Gitorious as well as on the FlightGear MapServer have been renamed to
just "terragear" without the "-cs".
Please update your .git/config files accordingly.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective
on Cox"
> > À: flightgear-devel@lists.sourceforge.net
> > Envoyé: Samedi 3 Mars 2012 23:41:41
> > Objet: [Flightgear-devel] terragear not building and installing genapts
> >
> > Hi all,
> > just checking out the lattest code as of 15min ago and found that
> >
Maybe there is a missing dependency that silently discard genapt from the build
Regards,
-Fred
- Mail original -
> De: "Jason Cox"
> À: flightgear-devel@lists.sourceforge.net
> Envoyé: Samedi 3 Mars 2012 23:41:41
> Objet: [Flightgear-devel] terragear not building
Hi all,
just checking out the lattest code as of 15min ago and found that
genapts is not being built/installed.
I checked my build process and found no errors and the program was
missing
can anyone help?
localhost terragear-cs # make install
[ 3%] Built target poly2tri
[ 10%] Built target Geome
Hi Peter,
Peter Sadrozinski wrote:
> I think I've reached a good point to start applying changes to the
> terragear repo. I can either start issuing merge requests, or, given
> access, apply changes on a dev branch.
I'd say have a branch, send me your Gitorious account name, please.
> A couple
Hello,
I think I've reached a good point to start applying changes to the
terragear repo. I can either start issuing merge requests, or, given
access, apply changes on a dev branch.
Which method is preferred by the terragear maintainers?
A couple other questions about future development.
1) Th
> FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server.
> Artifacts are archived.
And the 64 bit flavor is available too
Regards,
-Fred
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net
On Wed, 2011-11-09 at 17:56 +0100, Frederic Bouvier wrote:
> > > In Ubuntu linux, because I do NOT have OSG installed in
> > > any 'standard' place, in my makefg script, I do -
> > > export CXXFLAGS="-DNO_OPENSCENEGRAPH_INTERFACE=1"
> > > export CFLAGS="-DNO_OPENSCENEGRAPH_INTERFACE=1"
> > > to get
> > In Ubuntu linux, because I do NOT have OSG installed in
> > any 'standard' place, in my makefg script, I do -
> > export CXXFLAGS="-DNO_OPENSCENEGRAPH_INTERFACE=1"
> > export CFLAGS="-DNO_OPENSCENEGRAPH_INTERFACE=1"
> > to get terragear-cs to cmake build...
> >
> > Maybe the CFLAGS is not need
On 9 Nov 2011, at 15:32, Geoff McLane wrote:
> In Ubuntu linux, because I do NOT have OSG installed in
> any 'standard' place, in my makefg script, I do -
> export CXXFLAGS="-DNO_OPENSCENEGRAPH_INTERFACE=1"
> export CFLAGS="-DNO_OPENSCENEGRAPH_INTERFACE=1"
> to get terragear-cs to cmake build...
On Tue, 2011-11-08 at 22:15 +0100, Frederic Bouvier wrote:
> - Mail original -
> >
> > On 8 Nov 2011, at 19:59, Frederic Bouvier wrote:
> >
> > > FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server.
> > > Artifacts are archived.
> >
> > Brilliant, thanks Fred.
>
> I am still
- Mail original -
>
> On 8 Nov 2011, at 19:59, Frederic Bouvier wrote:
>
> > FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server.
> > Artifacts are archived.
>
> Brilliant, thanks Fred.
I am still not sure about the right method to exclude OSG from the build.
I added -DNO_OPE
On 8 Nov 2011, at 19:59, Frederic Bouvier wrote:
> FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server. Artifacts are
> archived.
Brilliant, thanks Fred.
James
--
RSA(R) Conference 2012
Save $700 by Nov 18
> Fred wrote:
> FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server. Artifacts are
> archived.
Wow, thanks a lot!! I've been waiting for that ever since 2009 :)
Gijs --
RS
Hi,
FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server. Artifacts are
archived.
Regards,
-Fred
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
__
On 8 Nov 2011, at 09:57, Christian Schmitt wrote:
> Done. If someone could remove the cmake branches, that'd be nice. :)
I'll do so, thanks for the merge.
Onwards with fixing the fgfs-construct crashes!
James
--
RSA(
Martin Spott wrote:
> I'm pretty certain the crash in 'fgfs-construct' is unrelated, just the
> usual issue we already know. Therefore I'd vote to merge the CMake
> branch - just in case, we'd fix the remaining issues in master.
Done. If someone could remove the cmake branches, that'd be nice. :
Christian Schmitt wrote:
> Can confirm the fix as well. It works all as expected. Waiting for your last
> feedback now, Martin, before preparing the merge.
I'm pretty certain the crash in 'fgfs-construct' is unrelated, just the
usual issue we already know. Therefore I'd vote to merge the CMake
Martin Spott wrote:
> Thanks a lot, things are looking much better now ! I'll perform a few
> more tests and will report back.
Can confirm the fix as well. It works all as expected. Waiting for your last
feedback now, Martin, before preparing the merge.
> In the meantime we managed to establi
On Mon, Nov 7, 2011 at 12:33 PM, Martin Spott wrote:
> James Turner wrote:
>
>> This is fixed now, though I don't really understand how it ever
>> worked - rawdem.c wasn't checking a particular return code nicely,
>> now it does.
>
> Thanks a lot, things are looking much better now !
Indeed, valg
On 7 Nov 2011, at 11:33, Martin Spott wrote:
> Thanks a lot, things are looking much better now ! I'll perform a few
> more tests and will report back.
> In the meantime we managed to established a method to reliably create
> topologically clean !! CORINE land cover from the publicly available
>
James Turner wrote:
> This is fixed now, though I don't really understand how it ever
> worked - rawdem.c wasn't checking a particular return code nicely,
> now it does.
Thanks a lot, things are looking much better now ! I'll perform a few
more tests and will report back.
In the meantime we mana
On 3 Nov 2011, at 18:51, James Turner wrote:
> ... going to be something really obscure when we track this down, I guess
This is fixed now, though I don't really understand how it ever worked -
rawdem.c wasn't checking a particular return code nicely, now it does.
James
-
On 3 Nov 2011, at 13:19, Christian Schmitt wrote:
>> That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
>> Glibc-2.11.2, if it matters,
>
> Ok, I observed the following: compiling the raw2ascii as "Release" leads to
> the error (on Debian). When compiling as "Debug" it works
On Thu, Nov 3, 2011 at 8:19 AM, Christian Schmitt wrote:
> Martin Spott wrote:
>
> > That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
> > Glibc-2.11.2, if it matters,
>
> Ok, I observed the following: compiling the raw2ascii as "Release" leads to
> the error (on Debian). When
Martin Spott wrote:
> That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
> Glibc-2.11.2, if it matters,
Ok, I observed the following: compiling the raw2ascii as "Release" leads to
the error (on Debian). When compiling as "Debug" it works here.
Chris
Martin Spott wrote:
> Christian Schmitt wrote:
>
>> Martin: Can you tell me under which OS this is happening? So I can try to
>> reproduce it in a VM.
>
> That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
> Glibc-2.11.2, if it matters,
>
I guess it matters, because I get e
Christian Schmitt wrote:
> Martin: Can you tell me under which OS this is happening? So I can try to
> reproduce it in a VM.
That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
Glibc-2.11.2, if it matters,
Martin.
--
Unix _IS_ user friendly - it's just selective abo
James Turner wrote:
> With some local changes to Simgear/next, but I am 'fairly sure' they don't
> relate to path/file/string handling. (Some changes in the SGOceanTile
> handling)
>
I just tested this as well (without your fix) and it works here too. Even
when using Martin's pathnames.
gl
James Turner wrote:
> On 2 Nov 2011, at 19:48, Martin Spott wrote:
>>> Fixed now, at least, it generated a ton of .dem files for me.
>>
>> Really ? And you're on simgear/next and terragear-cs/cmake-integration
>> without local changes ?
>
> With some local changes to Simgear/next, but I am 'fai
On 2 Nov 2011, at 19:48, Martin Spott wrote:
>> Fixed now, at least, it generated a ton of .dem files for me.
>
> Really ? And you're on simgear/next and terragear-cs/cmake-integration
> without local changes ?
With some local changes to Simgear/next, but I am 'fairly sure' they don't
relate
James Turner wrote:
> On 2 Nov 2011, at 18:51, James Turner wrote:
>
>>> In normal operation, "raw2ascii" should almost immediately start
>>> writing lots of files to "${WORKDIR}/SRTM-30-ASCII/e020n90/", but with
>>> current simgear/terragear-cs I'm just getting an insane number of
>>> lines:
>>
Tom
thanks for that
terragear-cs81244fb0fe41dfc9d87b28baffdd5754b3801952
simgear 6250f675db9fdd6f2aef7be43207cd0ac0b6baeb
Jason
On Wed, 2011-11-02 at 07:12 -0700, Tom P wrote:
> Hi Jason
>
>
> You can open a terminal in the terragear-cs directory and type:
>
>
> git show
>
On 2 Nov 2011, at 18:51, James Turner wrote:
>> In normal operation, "raw2ascii" should almost immediately start
>> writing lots of files to "${WORKDIR}/SRTM-30-ASCII/e020n90/", but with
>> current simgear/terragear-cs I'm just getting an insane number of
>> lines:
>
> Thanks Martin, will take a
On 2 Nov 2011, at 18:33, Martin Spott wrote:
> In normal operation, "raw2ascii" should almost immediately start
> writing lots of files to "${WORKDIR}/SRTM-30-ASCII/e020n90/", but with
> current simgear/terragear-cs I'm just getting an insane number of
> lines:
Thanks Martin, will take a look.
Martin Spott wrote:
> Yes, "raw2ascii" doesn't work with both "simgear" and "terragear-cs"
> HEAD and therefore "demchop" is still untested. I'll provide a test
> case as soon as time permits - spare time is a bit tight these days.
Ok, try this - get the data files from:
ftp://ftp.ihg.uni-dui
Hi Jason
You can open a terminal in the terragear-cs directory and type:
git show
The first lines show the commit ID, committer and short description for
the last commit, and the commit ID is the version information you are
looking for,
Hope this helps,
Tom
On Tue, Nov 1, 2011 at 2:43 P
Christian Schmitt wrote:
> Not only can I hgtchop, but also build scenery chunks again. So from my
> point of view the problems are solved. Are there any objections against
> pushing the changes to master?
Yes, "raw2ascii" doesn't work with both "simgear" and "terragear-cs"
HEAD and therefore "
James Turner wrote:
> I've pushed a fix to Simgear, updated the tests, and now I can run hgtchop
> happily with latest simgear and terragear.
Not only can I hgtchop, but also build scenery chunks again. So from my
point of view the problems are solved. Are there any objections against
pushing t
Chris,
short of knowing how to tell versions of code with git all I can say is
that I pulled the repo on the 20th of October for both terragear-cs and
compiled it against the main simgear of the same day.
If there is a way to ask git the version then let me know and I will
report back for you.
Ja
Jason Cox wrote:
> I would try a larger area, say 1x1 deg or larger and then and then you
> will see the list grow to include tiles that are no longer needed.
>
I created a 2x3 degree area. No problems. What terragear-cs version do you
use and against which simgear do you compile it?
Will now
Christian,
what I am finding i that the larger the area being built the more of
these files are being opened and not closed.
I would try a larger area, say 1x1 deg or larger and then and then you
will see the list grow to include tiles that are no longer needed.
Jason
On Mon, 2011-10-31 at 12:14
Thats correct.these are the files created from SRTM data by hgtchop and
terrafit
Jason
On Mon, 2011-10-31 at 11:30 +, Martin Spott wrote:
> Christian Schmitt wrote:
> > Jason Cox wrote:
>
> >> I ran lsof on the PID and have found that it is still holding all SRTM2
> >> arr and fit files open
Christian Schmitt wrote:
> Jason Cox wrote:
>> I ran lsof on the PID and have found that it is still holding all SRTM2
>> arr and fit files open. This is the probable cause of the memory leak
>> that I am seeing.
> What confuses me a bit is you using SRTM-2 files. What is this and how does
> hgt
Hi Jason,
I just tried to reproduce this issue here. Generating some scenery around
LOWI with 850 airport layouts, I only see always two SRTM files open: the
arr.gz and fit.gz for the tile that is currently built. So no problems here.
What confuses me a bit is you using SRTM-2 files. What is th
Ok so I am replying to myself.
after running fgfs-construct for the last 10+ hours at nice -20 and
still going I have the following info.
I ran lsof on the PID and have found that it is still holding all SRTM2
arr and fit files open. This is the probable cause of the memory leak
that I am see
Chris,
As I am not a programmer, what info do you need and who do I collect it?
Jason
On Sat, 2011-10-29 at 13:47 +0200, Christian Schmitt wrote:
> Jason Cox wrote:
>
> > is it not appropriate to issue a build of such a large area?
> > should I use smaller chunks?
> > should terragear not be r
Jason Cox wrote:
> is it not appropriate to issue a build of such a large area?
> should I use smaller chunks?
> should terragear not be releasing the memory after building a tile?
Generally speaking, sometimes it works, sometimes it doesn't. And yes, it
should free unused memory after finishing
Jason Cox wrote:
> [...]--xdist=15 --ydist=35
[...]
> is it not appropriate to issue a build of such a large area?
Not really ;-)
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
Hi all,
I am currently build a large chunk of scenery for SE Australia and have
found a problem with terragear's memory usage. most of the data I am
building is low quality until I get to around S30 to S35 however I have
only gotten to S36 using the following command ad the memory usage of
terragea
On 26 Oct 2011, at 18:43, Martin Spott wrote:
> I've tested various pairings of
> 'simgear' and 'terragear-cs', unfortunately without getting a 'hgtchop'
> creating subdirectories and/or files. Anyhow I'd like to hear from
> others being more successful with using recent versions of the
> 'terra
James Turner wrote:
> Can you describe / give me a minimal test setup?
I'm really running out of ideas and my buget of testing time for today
(maybe this week) is exhausted. I've tested various pairings of
'simgear' and 'terragear-cs', unfortunately without getting a 'hgtchop'
creating subdirect
On Wed, 2011-10-26 at 15:38 +0200, Christian Schmitt wrote:
> Geoff McLane wrote:
>
> > An error something like -
> > 'do not know how to make main.c from main.o'
> > which I did NOT understand... seems reversed!
> >
> > And why 'main.c', since the Makefile.am shows
> > only -
> > raw2ascii_SOURC
James Turner wrote:
> A fair suggestion! I originally combined them because it was easier not to
> worry about PLIB when creating the CMake files, but I wasn't expecting the
> slightly-complex changes to de-PLIB the file handling code.
>
> Let me see how hard it would be, to un-pick the changes.
Geoff McLane wrote:
> An error something like -
> 'do not know how to make main.c from main.o'
> which I did NOT understand... seems reversed!
>
> And why 'main.c', since the Makefile.am shows
> only -
> raw2ascii_SOURCES = main.cxx rawdem.c rawdem.h
> There is no main.c here???
>
Hi,
this is
James Turner wrote:
> Can you describe / give me a minimal test setup?
Difficult, because 'hgtchop' doesn't work any more either, not even
with terragear-cs/master ;-)
Try this one for the preparational step - adapt from my setup:
DATADIR=${HOME}/archive/GIS/GISData/SRTM/version2_1/HGT/SRTM3
WO
On Wed, 2011-10-26 at 13:19 +0100, James Turner wrote:
> On 26 Oct 2011, at 13:13, Martin Spott wrote:
>
> > Apparently directory path handling has been changed recently in a way
> > which prevents 'terrafit' from recursively walking the given directory
> > tree.
> > This issue is with cmake-integ
On 26 Oct 2011, at 13:34, Martin Spott wrote:
> I was interrupted when writing the above As an addition I'd
> propose to separate the de-PLIB-ifying from the 'cmake-integration'
> into a separate branch/topic/whatever because the move to CMake as a
> build system appears to be successful.
Martin Spott wrote:
> Apparently directory path handling has been changed recently in a way
> which prevents 'terrafit' from recursively walking the given directory
> tree.
> This issue is with cmake-integration/CMake, cmake-integration/Autoconf
> but master/Autoconf is fine. I'm also observing a
On 26 Oct 2011, at 13:13, Martin Spott wrote:
> Apparently directory path handling has been changed recently in a way
> which prevents 'terrafit' from recursively walking the given directory
> tree.
> This issue is with cmake-integration/CMake, cmake-integration/Autoconf
> but master/Autoconf is
Christian Schmitt wrote:
> [...] These changes are not yet in the master tree, but can be tested in the
> topics/cmake-integration branch. Please do so, if possible, so we can iron
> out any showstoppers.
Apparently directory path handling has been changed recently in a way
which prevents 'terr
Hi there,
maybe you have noticed some exceptionally high activity in recent days/weeks
on the Terragear repo. Well, there is one particular reason for it: It now
supports the cmake build system and, as of today, does no longer depend on
plib. These changes are not yet in the master tree, but ca
Martin Spott wrote:
> In order to tell FlightGear where to find its Scenery we're currently
> feeding a _directory_ name (or a list of directory names) as the
> "Scenery Path". Other formats like OpenFlight for example are using a
> _file_ name as the root Scenery handle.
BTW, I know that's a ve
Geoff McLane wrote:
> I am sorry Martin. I read your post MANY times,
> but you will have to provided more clues for this
> old brain to cotton onto ;=)). I do not quite catch
> what you can mean by "scenery root node"?
In order to tell FlightGear where to find its Scenery we're currently
feeding
Csaba Halász wrote:
> Also note, installing libgdal1-dev would have pulled in most of these
> automatically.
BTW, for those who are running Debian, I'd recommend to pull the
respective GIS packages from:
http://debian.gfoss.it/
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just
Whil I was trying to catch up with old "*Terra*"-EMail, I found this
one:
Geoff McLane wrote:
> Maybe you missed my 'little' question buried deep
> in my, as usual ;=(), quite log posts, but I was
> asking about the 'content' of mapserver
> simgear-cs git...
"simgear-cs" had been a requirement f
Martin Spott wrote:
> We're not yet there. On a first test earlier today, 'genapts' ended in
> a segfault with the recent changes but I ran out of time, thus I
> have not yet verified if the source change in 'simgear' really was the
> culprit,
>
Confirmed here. And I thought first it was th
Martin Spott wrote:
> We're not yet there. On a first test earlier today, 'genapts' ended in
> a segfault with the recent changes but I ran out of time, thus I
> have not yet verified if the source change in 'simgear' really was the
> culprit,
>
Confirmed here. And I thought first it was th
Martin Spott wrote:
> We're not yet there. On a first test earlier today, 'genapts' ended in
> a segfault with the recent changes but I ran out of time, thus I
> have not yet verified if the source change in 'simgear' really was the
> culprit,
>
Confirmed here. And I thought first it was th
Geoff McLane wrote:
> This will become even more important if the recent changes
> in sg_binobj.cxx gets rid of the 'swirlies' ;=)) thanks
> James, and Martin, and more people go for 'denser' scenery
> generation, breaking the 64K index barrier...
We're not yet there. On a first test earlier t
Hi Yves, Curt, et al,
If someone does works on, and check in a TG-cs tool patch to
handle 2 arcsec data, although I thought it always handled
integer inputs, then they should also keep in mind processing
say Canadian CDED1 0.75 arcsec data...
I did a patch to handle that back circa 2009, but
When someone wants to run "experiments" with this data, you can find
some test data in .dem format here:
http://maptest.fgx.ch/public/2arc-alaska-dem/n70w140.zip
Thanks a lot, Yves
Am 07.10.11 12:07, schrieb HB-GRAL:
> I am asking because I am currently working on Alaska elevation data for
> the
I am asking because I am currently working on Alaska elevation data for
the relief. I had to clip 6 px overlap and I converted the .flt data to
DEM format. HGT can not handle 1800x1800 px, but there is also a demchop
in terragear, right?
I like to share the data when it is useful for scenery bu
You might need to do some work with the tool that chops up the dem's into
TerraGear tile sizes. There are different terrain formats so you might need
to adapt the code to read a different format as well. This part sounds like
it should be pretty straightforward if you have clear docs for the inpu
Hi all
Can terragear handle 2 arc second elevation data ? I read only about 1
arc and 3 arc data for the terragear toolchain.
Cheers, Yves
--
All the data continuously generated in your IT infrastructure contains a
defi
While we're a it: The main "terragear-cs" repository has now moved to
Gitorious as a new repository within the FlightGear project, so those,
who'd like to develop TerraGear using Gitorious don't need to maintain
their private spin-off's.
Instead, feel invited to create personal clones of the main r
Christian Schmitt wrote:
> Hi there,
>
> i just want to announce that I added support for the 850 apt.dat runways
> to genapts. This work is thought as a compliment to the currently ongoing
> development towards curved taxiways.
> The current state is that genapts reads runways and creates them
>
Hi there,
i just want to announce that I added support for the 850 apt.dat runways to
genapts. This work is thought as a compliment to the currently ongoing
development towards curved taxiways.
The current state is that genapts reads runways and creates them
accordingly.
Features:
-different d
On Sunday, August 14, 2011 15:20:10 Durk Talsma wrote:
> Hi Adrian,
>
> I realize that it's almost three quarters of a year since your message was
> posted, but it wasn't until today that it caught my attention.
Hi Durk,
As they say, it's never too late to fix a bug. I remember encountering thes
Durk Talsma wrote:
> I'm explicitly deleting all the Triangle and Edge objects. This has
> improved performance a lot I'm still not able to process the entire
> Eurasian continent in one pass, after this fix, the total number of
> ".fit" files that can be created on my linux box has gone up fr
Hi Adrian,
I realize that it's almost three quarters of a year since your message was
posted, but it wasn't until today that it caught my attention. Earlier this
weekend I decided to pull the latest version of terragear-cs from it's GIT
repository, in order to see whether I could build some sc
Geoff McLane wrote:
> Thanks. It is good to know that the -
> Default=x, where x = 0-2 is 'normal', but
> Chris reported that it was still running after
> 6 hours, or more... and still unable to exactly
> find where this is output, in the code...
You won't be able to find Default in the sources a
On Thu, 2011-06-02 at 03:12 +0200, Geoff McLane wrote:
> Hi Jason,
>
> When you say a 'long time', do you mean more than
> this, like DAYS? ;=(( Just trying to get an idea
> of how 'patient' one MUST be... before deciding
> something is really going 'wrong'...
>
I have found that the standard
Hi Jason,
Thanks. It is good to know that the -
Default=x, where x = 0-2 is 'normal', but
Chris reported that it was still running after
6 hours, or more... and still unable to exactly
find where this is output, in the code...
When you say a 'long time', do you mean more than
this, like DAYS?
Geoff McLane wrote:
> It is certainly _NOT_ 'normal' behavior, and
> historically (I assume Curt ;=)) implemented some
> draconian 'rlimit' - setrlimit(RLIMIT_CPU,),
> to abort after a period of time, which is just
> NOT available in my WIN32 environment, to avoid
> such a 'forever' loop...
Hi,
Chris/Geoff,
I normally see reams of these and other similar lines.
I think that you are seeing some form of count for terrain type.
My usual output has other textures mixed in there and only ever <3 as
the number expressed.
If you are using a hight level of detail (OSM residental) and processing
Hi Chris,
Glad the rough 'fixes' I provided worked a little
for you... have yet to clone your 'papillon81'
clone, and try it... but...
While it is agreed on this list everyone seems to
really _LOVE_ extreme brevity, (perhaps except
me ;=)), your post just did not tell me
enough ;=((
I searc
Geoff, I applied both of your patches, see here:
https://gitorious.org/papillon81/terragear-cs
Until now I had no crashes or negative effects on the resulting scenery.
However, there IS a problem, unrelated to your patches, for which I hope to
get some help.
I create large chunks of scenery wit
On Sun, 2011-05-29 at 11:45 +0200, Christian Schmitt wrote:
> Geoff McLane wrote:
> > It certainly works better for me ;=)) And removes
> > another reason why fgfs-construct can abort
> > without apparent reason!
>
> Hi,
>
> you mean segfaults with no apparent reason? I experience them under Linu
Geoff McLane wrote:
> It certainly works better for me ;=)) And removes
> another reason why fgfs-construct can abort
> without apparent reason!
Hi,
you mean segfaults with no apparent reason? I experience them under Linux
when building huge scenery chunks and if your patch improves the situatio
On Sun, 2011-05-29 at 09:55 +0200, Anders Gidenstam wrote:
> On Sat, 28 May 2011, Geoff McLane wrote:
>
> > Hi all,
> >
> > I read (everywhere) that a vector erase invalidates
> > all current iterators - see say -
> > http://www.cplusplus.com/reference/stl/vector/erase/
> > so I really do not unde
On Sat, 28 May 2011, Geoff McLane wrote:
> Hi all,
>
> I read (everywhere) that a vector erase invalidates
> all current iterators - see say -
> http://www.cplusplus.com/reference/stl/vector/erase/
> so I really do not understand why genfans.cxx has lasted
> so long like it is ;=((
>
> When it doe
Hi all,
I read (everywhere) that a vector erase invalidates
all current iterators - see say -
http://www.cplusplus.com/reference/stl/vector/erase/
so I really do not understand why genfans.cxx has lasted
so long like it is ;=((
When it does a -
tris.erase( t_current );
it should reset
Hi Csaba,
> you have probably forgotten to run "apt-file update"
> recently.
LOL! Up until a few days ago, when you mentioned it, I
had never heard of 'apt-file' ;=)) let alone updated it!
Up until just a few wee years ago, I was a windows ONLY
person, and still do most stuff in there, but I now
On Tue, May 3, 2011 at 7:33 PM, Geoff McLane wrote:
>
> But even after that install, the command -
> $ apt-file search libodbcinst.so
> still shows 'nothing' ;=((
"apt-file search" searches the package lists, not the installed files.
If it shows nothing, that means you have probably forgotten to
On Mon, 2011-05-02 at 19:52 +0200, Csaba Halász wrote:
[]
> unixodbc-dev: /usr/lib/libodbcinst.so
> The last is the one to install (it will pull in the dependencies as needed).
Hi Csaba,
Many thanks for the pointer. Have now installed -
$ sudo apt-get install unixodbc-dev
and that certainly also
Geoff McLane wrote:
> Hi Martin,
>
> Maybe you missed my 'little' question [...]
I hear your voice, I'm just a little bit too busy with real life for
writing an appropriate response. I hope I'll be able to do so before
LinuxTag,
Martin.
--
Unix _IS_ user friendly - it's just selective
On Mon, May 2, 2011 at 7:41 PM, Geoff McLane wrote:
>
> BUT ran out of PUFF on the next -lodbcinst ;=))
>
> There seems NO libodbcinst* in my system, although
> there is a -
> /usr/bin/odbcinst
> which, when run, just outputs -
> unixODBC 2.2.11
> but how to get a 'library'???
$ apt-file search l
Hi Martin,
Maybe you missed my 'little' question buried deep
in my, as usual ;=(), quite log posts, but I was
asking about the 'content' of mapserver
simgear-cs git...
In windows I was able to build terragear-cs
using 'standard' gitorious simgear, and others,
as far as I see so far, seem to have
1 - 100 of 242 matches
Mail list logo
