Newer models of C172 has landing and taxi lights located in the front
edge of the left wing. This can be seen on Cessna web site and I've seen
it on planes built in 2008. Of course, if fg's C172 is from 1981 then
the new placement of the lights probably does not apply.
Cheers,
Jari
On
On 2012-01-01 16.40, Clément de l'Hamaide wrote:
When I remove all 21 | tee -a $LOGFILE and I replace it by a
simple $LOGFILE I see many less information in terminal when
script is running. It's very annoying to haven't information about
step in terminal... For example, when the script
On 2012-01-01 20.17, Geoff McLane wrote:
But in doing this, as you point out, there is NO OUTPUT
to the console...
Except as Jari pointed out, you can start the script
as a background process, and use a repeated tail
command to view the end of the LOG in a console...
Or even start the
On 2011-12-26 10.56, James Turner wrote:
On 25 Dec 2011, at 22:45, Jari Häkkinen wrote:
The FlighGear package created in Build #871 (Dec 25, 2011 12:05:44
PM) does not run on two of my macs.
1. On the Snowleopard machine I get:
What version of Xcode/Mac OS X is the Jenkins server using
The FlighGear package created in Build #871 (Dec 25, 2011 12:05:44 PM)
does not run on two of my macs.
1. On the Snowleopard machine I get:
Dyld Error Message:
Library not loaded: /usr/lib/libapr-1.0.dylib
Referenced from: /Users/jari/Desktop/FlightGear.app/Contents/MacOS/fgfs
Reason:
Hi,
This message is to the get started manual maintainers.
There are some files with the executable permission bit set in the git
repo. To reset the file mode please apply the attached a patch to the
getstart git repo.
The patch was created with command: git format-patch origin
Cheers,
On 2011-12-07 09.02, Robert wrote:
Does METAR contain this information?
Not directly. METAR may contain information about gusty winds which is
an indication of turbulence.
Jari
--
Cloud Services Checklist: Pricing
OSX can be case sensitive. It is not case sensitive by default however
some of the OSX machines I use are.
Do not assume OSX to be case-insensitive.
Cheers,
Jari
Michael Sgier skrev 2011-11-05 13.38:
Windows and OSX are not case sensitive, but Linux is.
On 2011-10-27 10.24, James Turner wrote:
Actually, that's not quite accurate, but, the procedure is to ask,
*having demonstrated yourself to be a sane and reasonable person
who's likely to stick around longer than four weeks*. I'm a bit more
liberal in this regard, but essentially anyone who's
On 2011-10-27 11.35, Heiko Schulz wrote:
And who makes sure and decides that those people really keeps to all those
rules?
The project lead (or leader) should make decisions and of course be well
in tune with the lead developers, developers, and with the fg community.
As a bystander it is
On 2011-10-27 14.29, Curtis Olson wrote:
On Thu, Oct 27, 2011 at 7:09 AM, James Turner wrote:
On 27 Oct 2011, at 12:58, Jari Häkkinen wrote:
Sorry for the rant-like appearance of this message.
No need to apologise, I'd say it's 100% accurate - including the lack of a
single leader
Try http://wayback.archive.org/web/*/http://www.flightgear.org
I found the attached sunset over Grand Canyon from February 1999.
Jari
On 2011-10-23 20.07, Durk Talsma wrote:
Hi All,
I'm planning to give a talk at the upcoming FSWeekend, and hope to tell
something about FlightGear's
, I keep the changes
that didn't make it into the official repository in my local repo.
Cheers,
Jari
On 2011-10-20 10.07, Martin Spott wrote:
Jari Häkkinen wrote:
I support the split if only for the reason that aircraft maintainers
will get commit rights to their private spheres in fg-land
I actually lost track of who is doing what in the splitting of fgdata
but there is a tremendous response pointing out issues related to the
split. I want to express support for the splitting team.
I support the split if only for the reason that aircraft maintainers
will get commit rights to
On 2011-10-19 21.12, Torsten Dreyer wrote:
Another example: For the last release, we branched and tagged the
repositories and well defined states. This was OK for three repositories
(fg+sg+fgdata). Doing this manually for 300+ repos is a no and doing
this scripted calls for trouble.
But is
On 2011-07-28 14.33, Gene Buckle wrote:
On Thu, 28 Jul 2011, Stefan Seifert wrote:
On Thursday 28 July 2011 01:00:10 Hal V. Engel wrote:
But there is one minor and very common issue with the code that should be
fixed. In the for loop
for (..; ..; j++)
should be
for (..; ..; ++j)
if
On 2011-07-28 15.22, Gene Buckle wrote:
On Thu, 28 Jul 2011, Jari Häkkinen wrote:
Are you sure about that? I just tried it with a little example and
at least
gcc compiles both variants to the exact same assembly code. Tried it
with and
without -O2.
That would freak me out. Doesn't ++j
On 2011-07-28 14.52, Jari Häkkinen wrote:
That would freak me out. Doesn't ++j mean increment j, then test
whereas j++ means test j, then increment?
No, for a for loop
for ( [1]; [2]; [3] )
where [3] is ++j will increment j before use. However, in an
if-statement the complete statement
Hi all,
I cannot use material shaders on my iMac (late 2009 model) equipped with
an ATI graphics card (ATI Radeon HD 4670 256 MB VRAM). I only get a few
fps standing on ground at an isolated airfield. There is almost no
objects. Every 10 times I get 60 fps in cockpit view with no changes
On 2011-06-25 17.34, Gene Buckle wrote:
On Sat, 25 Jun 2011, Vivian Meazza wrote:
The most _likely_ cause is the ATI Radeon HD 4670/256 MB VRAM. The GeForce
8600M GT is known to be better at handling shaders. 256 Mb VRAM is in both
cases a bit small for FG nowadays. There are other possible
On 2011-06-25 16.06, Vivian Meazza wrote:
The most _likely_ cause is the ATI Radeon HD 4670/256 MB VRAM. The GeForce
8600M GT is known to be better at handling shaders. 256 Mb VRAM is in both
cases a bit small for FG nowadays. There are other possible contributors to
a low framerate - AI
Torsten Dreyer skrev 2011-06-17 21.47:
Anticipating the release 2.4.0, we reached our first milestone today.
The development streams for flightgear, simgear and fgdata on gitorious
are now declared frozen.
The above states quite clearly that testing is expected to be against
the source
On 2011-04-06 14.08, HB-GRAL wrote:
- Do other contributors of the origin repo have the right to change my
origin licence assignment from GPLv2 to GPLv3, when they just pull and
push the same code? (I really think: No.)
I think anyone has the right to redistribute the code under GPLv3 if
26 feb 2011 kl. 19:37 skrev Heiko Schulz aeitsch...@yahoo.de:
The question is still: how to proceed?
Just pretend this discussion never was. That is, do whatever we did before the
issue was raised. Are we prepared for the consequences of negative responses?
Cheers,
I have no time for detailed legalities of the message but one should
note regarding GPL (at least v3 and probably v2, maybe it is time for fg
to go v3?)
1) It is legal to fork a GPL project at any time if some conditions are
met. In simple terms the forked project must provide their
On 2011-01-09 17.52, Michael Sgier wrote:
mich...@ubuntu:/media/Suse-Home/fgfs$ cd install/fgrun/bin
mich...@ubuntu:/media/Suse-Home/fgfs/install/fgrun/bin$ ./fgrun
./fgrun: error while loading shared libraries: libosgParticle.so.70: cannot
open shared object file: No such file or directory
The problem was introduced in November 2010 in commit
http://gitorious.org/fg/flightgear/commit/a6458c2ed64757b1f416b0035df142d29359239e
The change of line 17 triggers the change of string 'FlightGear' to
'flightgear' in the Makefile. However, the change of AM_INIT_AUTOMAKE is
preferred since
be a way to retain
backward compatibility. But it will complicate autotools usage since it
breaks standard autotools behaviour.
Jari
On 2011-01-08 21.47, James Turner wrote:
On 8 Jan 2011, at 19:46, Jari Häkkinen wrote:
The problem was introduced in November 2010 in commit
http
It looks like there is a stray 2.0.0 version.h somewhere or your
cpp-flags are pointing to the wrong place. In your fg/source directory
there is a config.log file. Search for the string 'checking for SimGear
2.2.0 or newer' and you'll see some more details. Specifically the
compile command
For newcomers I'd say it is essential that there are close buttons. When
new users try out software they won't browse any documentation. And I'd
say that many (most?) users would get confused without close buttons.
This seems to be an important non-issue. Maybe there already is an
expert
ThorstenB skrev 2010-12-20 19.58:
So, unfortunately, divisons-by-zero, processing with infinity or
NaN (not-a-number) values isn't really uncommon for FG. And since
the FG default is to ignore any FPE (i.e. not to use the
--enable-fpe option), few people care (I guess).
Personally I don't
On 2010-12-19 16.18, James Turner wrote:
I've just pushed my work on CMake build files for SimGear and
Flightgear, to Gitorious. These files are completely orthogonal to
the existing autoconf/automake build, and are still a work in
progress - a few people have been experimenting with them (big
On 2010-12-13 17.36, John Denker wrote:
On 07/23/2010 05:12 AM, Csaba Halász wrote:
./configure: line 10540: apr-1-config: command not found
./configure: line 10541: apr-1-config: command not found
That configure test is broken.
I agree.
I agree too but I do not agree on your solution.
On 2010-12-13 21.11, Jari Häkkinen wrote:
If we do not want to change the default behaviour wrt libsvn, then
configure should check for svn_client.h before using apr-1-config. If
svn devlibs are in place then apr is also installed since apr is a
prerequisite for svn devlibs.
Well
Hi Mac developers,
In my quest to compile all fg related packages for 64 bit architecture
(x86_64) I finally decided to compile the mac fg start up GUI
(FlightGear) for 64 bits. The binary does not work, it starts up and
exits with
2010-12-08 00:20:50.408 FlightGear[29071:903]
Hi Mac developers,
I decided to get rid of the message
2010-12-06 21:32:32.569 FlightGear[26052:903] ***
__NSAutoreleaseNoPool(): Object 0x10020a330 of class NSThread
autoreleased with no pool in place - just leaking
coming from the Mac flightgear start up GUI. The Net wisdom seems to be
mapserver git URL for fgdata works for me now. I get fg and simgear from
gitorious. Thanks,
Jari
Martin Spott skrev 2010-12-03 18.55:
Martin Spott wrote:
Yup. The new machine is already alive (the web map should be available)
but I'm still awaiting a chance to sync the latest changes from
I am trying to update fg data with 'git pull' but keep getting
connection refused:
mapserver.flightgear.org[0: 137.110.116.31]: errno=Connection refused
fatal: unable to connect a socket (Connection refused)
In my .git/config I have
url = git://mapserver.flightgear.org/fgdata/
Can someone
On 2010-12-02 15.07, Csaba Halász wrote:
On Thu, Dec 2, 2010 at 2:58 PM, Jari Häkkinenj...@flygarna.se wrote:
I am trying to update fg data with 'git pull' but keep getting
connection refused:
Can someone resolve the issue on mapserver or explain what I am doing
wrong if the problem is on
On 2010-12-01 15.18, Vivian Meazza wrote:
The point is that your rating system can't possibly pick this up. It is a
subjective opinion of the attractiveness of a cockpit. Or, as I said, a
beauty contest. This does have some value, and we certainly gain from
drawing attention to those models
On 2010-11-21 18.01, manday wrote:
Once you tell me what exactly I should file the bug on I will get some
screenshots to give you a better idea.
There is a bugs page at the wiki,
http://wiki.flightgear.org/index.php/Bugs, and an issue tracker at
http://code.google.com/p/flightgear-bugs/
On 2010-11-21 12.44, James Turner wrote:
On 21 Nov 2010, at 01:43, Heiko Schulz wrote:
I prefer fixing instead of releasing
Fixers and releasers can be different people. Of course, releasers need
to be given the power of steering fixers focus. (Yes I know that people
are working voluntarily
To set environment variables in Windows 7 (and Vista) see
http://yuji.wordpress.com/2009/08/31/django-on-windows-setting-path-environment-variable/
or http://www.itechtalk.com/thread3595.html
Wikipedia article on environment variables,
http://en.wikipedia.org/wiki/Environment_variable
In this
In subversion this is solved with svn property svn:eol-style set to
'native' for text files. When clients checks out files they will
automatically get the eol-style appropriate for their OS. Subversion
won't accept files with mixed line endings. Surely git has something
similar?
Jari
On
On 6/26/10 7:36 PM, Alan Teeder wrote:
Is there any need for this to be done by all new cloners before compilation?
It seems to be an unnecessary complication.
The reason for having autoconf to replace the version string is that
there should only be one place where the version string is set
Hi David,
This post will probably not be taken well by many subscribers but I
understand your frustration. The build process works but to get the
first clean compile is a highly non-trivial task as you noticed. Your
post is not very descriptive so I can only give you general pointers.
You
Read James' post:
On Linux, the steps are (from a clean Ubuntu/Fedora install)
- install various -dev packages using apt-get/yum/synaptic
(openAL-dev, compiler, freetype-dev, libpng-dev, boost, cmake,
cvs/svn/git clients etc)
- download OSG, cmake, make and make install
- download PLIB
On 3/3/10 5:16 PM, Curtis Olson wrote:
Proftpd has the ability to limit the number of connections from any single
host. Otherwise one person often ends up grabbing all the available
download slots. Anyone want to look into a torrent? Is there an easy
recipe for setting one up? What's the
Maybe using torrents could help in distributing flightgear packages? I
haven't used this distribution method myself but the mirror maintainers
could maybe create seeds and announce them though the flightgear web
site(s).
Jari
On 2/24/10 5:15 PM, Curtis Olson wrote:
This message is
Isn't this related to my report
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg26160.html
where I found issues with mismatch of runways in
/path/to/fg/data/Airports/apt.dat.gz and /path/to/fg/data/Navaids/nav.dat.gz
EDDB is one of the reported airports. In apt.dat.gz
On 2/11/10 9:36 AM, Stuart Buchanan wrote:
James Turner wrote:
As James and Martin have already said - it is absolutely critical that this
is a
defect list rather than a feature request. So, even missing features need
to be
pruned aggressively for this to succeed. Peter I suggest you do
On 2/11/10 6:40 PM, Geoff McLane wrote:
Hi Curt, Melchior, Emmanuel, Syd, Detlef, Erik, or ...
As requested before, to HELP WIN32 users, could we PLEASE
have only ONE of EACH of the following PAIRS in FG data ;=()
And mac users ... by default the filesystem is case-insensitive on macs.
Maybe
On 2010-02-09 11.08, Erik Hofman wrote:
Erik Hofman wrote:
I've updated configure of both FlightGear and SimGear to bail out if the
OpenScenegraph libraries are not found. SimGear has a simple check for
OpenThreads and OSG version number and a more extensive error report.
FlightGear checks
On 2/8/10 6:58 PM, Geoff McLane wrote:
As you have read, I have suggested that we abort
during the configure step in case of this 'no',
for this important library, but that is only a
'choice'.
If the person 'sees' the 'no', says oops, and does
something to fix it, like install the OSG
Wow, what a debate. This is a reply to an early post in this thread.
On 2/5/10 6:21 PM, Martin Spott wrote:
Jari Häkkinen wrote:
Actually I think subversion support in terrasync should be removed
altogether or fixed. If removed then all svn checks could be removed.
Oh my, could you
, thanks for the pointer.
Still, the inconsitencies remain but that maybe is okay?
Jari
On 2/5/10 11:53 AM, Martin Spott wrote:
Jari Häkkinen wrote:
Maybe the issues described above are valid only for my local build
[...]
You might check if things look differently when using a build from
On 2/5/10 4:04 PM, Geoff McLane wrote:
Hi Jari,
I read _LOUDLY_ your 'fear' that changing anything
to do with the 'svn' may cause some unwanted
change... but feel this is totally unfounded...
Yes, I agree. My bad. I added your checks to my configure.ac.
Jari
On 2/5/10 4:04 PM, Geoff McLane wrote:
But I have had more time to write, and test a
BETTER patch attached that :-
(a) does NOT change the svn_client.h lines ;=((,
(a) should be changed, I agree with your original proposal.
Actually I think subversion support in terrasync should be removed
The suggested patch to configure.ac may have unwanted side effects in
that if may trigger a build of a terrasync binary with builtin
subversion calls rather than use of external svn calls. The problem with
terrasync using builtin subversion calls is that the current
implementation does don't
, 2010-02-04 at 17:08 +0100, Jari Häkkinen wrote:
The suggested patch to configure.ac may have unwanted side effects in
that if may trigger a build of a terrasync binary with builtin
subversion calls rather than use of external svn calls. The problem with
terrasync using builtin subversion calls
I am trying to get Tats macflightgear 32-bit binary package to run on
iMac (64 bit Mac OS X 10.6.2) but it simply crashes with no information.
The package works on my Macbook Pro also running 64-bit Snowleopard.
Now, after some tweaking I finally got Tat's source package to compile
in 32bit
Hi,
I tested pre3 on my two macs.
Dual core 27 iMac report: As previously fg won't work on my iMac. As
with the previous pre-releases fg crashes during initialization. I am
working on getting a debug compile of Tats code. I've reached the end of
compiling all the packages but fail on getting
Jensen wrote:
On Thu, 2010-01-28 at 21:59 +0100, Jari Häkkinen wrote:
For me the Nasal function looks strange. I can't understand what the
addition of 0.001 to freq does? For me it seems to be a waste of
precious CPU time.
Jari
var bar=int((freq+0.001)*10)-int(freq)*10;
The 0.001 ensures
Thanks.
Jari
On 1/29/10 4:07 PM, Ron Jensen wrote:
On Fri, 2010-01-29 at 15:34 +0100, Anders Gidenstam wrote:
On Fri, 29 Jan 2010, Jari Häkkinen wrote:
Ok, and then the final step is the bits.test(bar,0). I spent a couple of
minutes searching the web but could not find docs
I can't read Nasal so I can't say if the function below is correct. For
what it is worth: A frequency between 108.100 and 111.950 (including end
points) is a localizer frequency if the first decimal is an odd number.
Jari
On 2010-01-28 04.45, Ron Jensen wrote:
On Wed, 2010-01-27 at 09:06
Why change the subject? James did not ask for deprecating Nasal, he
simply wanted to avoid multiple implementation of functionality. Less
error prone and if the available functionality does not fit ones need,
then fall back on Nasal (or C++).
Cheers,
Jari
On 2010-01-28 16.20, Ron Jensen
should be pretty confident that what you think nasal is
doing is what it's actually doing. Writing nasal code from scratch is
harder of course because it requires knowledge of all the picky language
syntax details.
Curt.
On Thu, Jan 28, 2010 at 2:21 PM, Jari Häkkinen wrote:
I can't read
The new apt.dat.gz works for me. Thanks,
Jari
On 2010-01-28 11.17, Martin Spott wrote:
Jari Häkkinen wrote:
Atlas does not like the current apt.dat.gz because of string 'SOUTH' on
line 119725:
I've fixed hepilad name assignments for two airfields, please pull the
current file from
Hi,
I am cross-posting this to atlas and fg developer lists.
Atlas does not like the current apt.dat.gz because of string 'SOUTH' on
line 119725:
10 51.889770 -2.162530 SOUTH 174.36080 . . 80
11 08 0 0 0.25 0 0300.0300
Looking at other lines in apt.dat.gz
With the latest repository version of fg and support the sound works for
me on 64bit iMac. Previously I had problems with fly-by view sound but
now the doppler effect in fly-by view now sounds reasonable. Nice work Erik.
Jari
On 1/20/10 3:02 PM, Erik Hofman wrote:
Erik Hofman wrote:
I
Judging from the extension .gz the command to use is gzip not tar. For
compressed tar I'd expect extension .tgz or .tar.gz. Try 'gzip apt.dat'
instead.
Jari
On 1/19/10 11:51 AM, Andrew Gillanders wrote:
Hello all,
I am having trouble with an updated apt.dat file. I think it is with
On 1/10/10 10:13 PM, Benoît Laniel wrote:
I updated the snapshots and now have a functional (probably not bug
free) terrasync with svn support built-in:
Not really a win32-build issue but terrasync does not behave well with
svn built into it. When terrasync is killed it does not exit
Consulting my course material for passing the ATPL tests in Europe I
read that the glide path is required to be usable up to a distance of 10
NM (which I interpret from the touch down zone not the distance to an
DME that may or may not be at destination). This distance should be
valid +-8
John Denker wrote:
Curtis Olson wrote:
I'm not sure the best way to handle this but if you start at the top and
run ./autogen.sh followed by ./configure --options I think the error
will be cleaned up. Switching files from abc.c to abc.cxx confuses the
dependency tracking of automake.
.
Cheers,
Jari
Jari Häkkinen wrote:
John Denker wrote:
Curtis Olson wrote:
I'm not sure the best way to handle this but if you start at the top and
run ./autogen.sh followed by ./configure --options I think the error
will be cleaned up. Switching files from abc.c to abc.cxx confuses
Eh, a bugtracker?
Jari
Heiko Schulz wrote:
Hi,
Every one of those bug reports has a date. There are
so many
bugs that I can't check them all every day.
Yep, exactly that makes me woender! Even with the newest date, you must
probably missed some things.
Generally I found some other
to this issue, so please feel free to tell your opinion
all developers.
On Nov 30, 2009, at 5:37 AM, Jari Häkkinen wrote:
I am not sure if this thread is going anywhere. This will be my
last post in this thread.
I think we (Eric and Tat) should decide for one strategy. They may
already have
Terragear complains about missing directory in the subversion repository:
URL
'http://terrascenery.googlecode.com/svn/trunk/data/Scenery/Objects/e010n50/e014n54'
doesn't exist
Can someone please add it?
Jari
--
Thanks.
Tim Moore wrote:
On 11/29/2009 01:59 AM, Csaba Halász wrote:
On Sun, Nov 29, 2009 at 12:54 AM, Jari Häkkinen j...@flygarna.se wrote:
I traced the problem to changeset 10838 in OSG. I cannot say what goes
wrong but maybe one of the list readers do.
http://www.openscenegraph.org
Häkkinen wrote:
On 2009-11-28 23.01, Erik Hofman wrote:
Jari Häkkinen wrote:
My comments was to elaborate on the consequences of the removed alut
support by Apple. It is dangerous to use any alut.h you find on the web.
As you point out using Creatives alut.h may make things simpler
(macports.org
Hi all,
I only get a blank single colour screen when I run fg (latest cvs/svn
versions of plib/osg/simgear/fg). The colour changes with time settings,
it is grey at noon, bluish at dusk, and black in night time. I can see
the top menu and I have sound. I get the message saying which runway I
Tatsuhiro Nishioka wrote:
Hi Jari,
First, I made patches for configure.ac in both SimGear and FlightGear
(except svn lib part) so please give it a try.
I tried your changes and they work well. However, I have a slightly
different strategy so I took your changes and adopted them to my
that
for a while. (Now I changed strategy as outlined in other postings in
this thread.)
Cheers,
Jari
Tatsuhiro Nishioka wrote:
Jari Häkkinen wrote:
Tatsuhiro Nishioka wrote: Ah, so there is no real need for alut.h
at all. Hm, so the alut.h issue should rather go in to simgear. I
now tested
On 2009-11-28 23.01, Erik Hofman wrote:
Jari Häkkinen wrote:
My comments was to elaborate on the consequences of the removed alut
support by Apple. It is dangerous to use any alut.h you find on the web.
As you point out using Creatives alut.h may make things simpler
(macports.org is another
On 2009-11-28 16.55, jean pellotier wrote:
Jari Häkkinen a écrit :
Hi all,
I only get a blank single colour screen when I run fg (latest cvs/svn
versions of plib/osg/simgear/fg). The colour changes with time settings,
it is grey at noon, bluish at dusk, and black in night time. I can see
Jari Häkkinen wrote:
Tatsuhiro Nishioka wrote:
Ah, so there is no real need for alut.h at all. Hm, so the alut.h issue
should rather go in to simgear. I now tested with a zero length alut.h
and no libalut. Compiling works but the linker fails with alut-complaints
Undefined symbols
Tatsuhiro Nishioka wrote:
Hi Jari,
Thanks for your patch, and sorry for my very late reply.
No worries, I have a working development environment. I post my findings
and hope the information helps others facing similar issues as I have.
If my pathces are useful they might end up in the the
Jari Häkkinen wrote:
Anyway, we have to either install OpenAL with alut.h to
/Library/Frameworks or manually add alut.h to
/Developer/SDKs/*/System/Library/Frameworks/OpenAL.frameworks/Headers/
Shouldn't we make simgear ignore #include OpenAL/alut.h when compiling
on OSX instead of adding
Map will only generate the maps downloaded by terragear and the ones in
fg data CVS repository. It is not that much assuming you haven't crossed
the globe a few times.
Jari
Alex Perry wrote:
The computer isn't too slow, no. I'm just hoping to avoid having to
download the entire global
Yes, see
http://sourceforge.net/mailarchive/forum.php?thread_name=514CC37C-DA62-45F3-BC1F-1B929429B09C%40gmail.comforum_name=flightgear-devel
or you might get away with g++ 4.3 as hinted in the thread.
Surely there is a way to upgrade separate packages in Ubuntu? I am using
Snow Leopard on mac
On 2009-11-15 09.38, Vivian Meazza wrote:
Tim Moore wrote
I've just checked in code that applies effects to all models in FG.
There's no
documentation yet for how to use new features -- and not really any
examples
either; I want to shake out what the changes may have broken first.
According to http://wiki.flightgear.org/index.php/Plib there should be
no dependency on PLIP windowing library (pw). I found that
FG/src/GUI/layout_test.cxx uses plip/pw.h. Since I am building flighgear
on a 64-bit mac layout_test.cxx does not compile. This is a consequence
from the fact that
I have made changes (improvements?) to the configure script. I have
attached a patch file for configure.ac with changes targeting issues
with building flightgear on my mac. The changes will only impact mac
users.
Changes made:
1) Fixed mixup in AC_ARG_WITH between osg and plib.
2) Added check
Hi again,
Another patch, this time targeting the check of subversion library
support. The current checks in configure.ac are useless, the attached
patch detects subversion appropriately if it is intalled.
Can someone review it and commit to the flightgear source CVS.
Cheers,
Jari
Index:
Erik Hofman wrote:
I've committed the current state of my local code to see if it fixes
anything.
Erik
Erik, there is a typo in SIMGEAR/simgear/sound/Makefile.am, see diff below.
Cheers,
Jari
Index: simgear/sound/Makefile.am
SIMGEAR/simgear/compiler.h needs a minor change to compile on my mac
running 64-bit Snow Leopard. The proposed change is attached to this
mail. It should be safe to apply it. Can someone please commit it to
simgear CVS.
Jari
Index: simgear/compiler.h
I have a question about a code segment in SIMGEAR/simgear/compiler.h
lines 133-147 (latest CVS version).
133 #ifdef __APPLE__
134 # ifdef __GNUC__
135 #if ( __GNUC__ = 3 ) ( __GNUC_MINOR__ = 3 )
136 inline int (isnan)(double r) { return !(r = 0 || r = 0); }
137 #else
138// any C++
John Denker wrote:
The simplest approach might be:
0) For naive users, and even experienced VFR users,
they don't know and don't care about this issue,
and everybody would like to keep it that way.
1) At startup, we shall set every reversible ILS to
the higher-numbered end (19
leee wrote:
On Friday 07 Aug 2009, Anders Gidenstam wrote:
On Fri, 7 Aug 2009, leee wrote:
I'm just wondering how much hardwood there is in Sweden.
Sweden's Firs might have been ok for the masts and spars but
hardwood was needed for the hull and superstructure, typically
Oak for the keel
Tatsuhiro Nishioka wrote:
Jari,
On Jun 16, 2009, at 8:47 AM, Jari Häkkinen wrote:
Last week I realized that I miss the OSX lancher. I checked out the OSX
launcher from the repository (trunk branch ... I don't get latest fixes
to the launcher :-0),
FYI, the latest fix on GUI launcher
1 - 100 of 109 matches
Mail list logo
