Re: [Flightgear-devel] Updated Cub and c172p for Rembrandt
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 2012-04-03 12:26, Martin Spott wrote: Martin Spott wrote: Service manual says: [...] Beginning with 1971 Models, the landing and taxi lights are located in the nose cowl. The D-EEQA (on the picture, sitting in wet grass) is a 1978's Cessna F 172N (serial 1697) and FlightGear's is, as far as I remember, a 1981's C172P. Therefore I'd say the lights belong into the cowling. Cheers, Martin. -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to compile Terragear-cs ?
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 downloading OSG from SVN there is nothing written in terminal... I wait during some minute without know if my script is running. Before, with 21 | tee -a $LOGFILE I could see all downloading files in real time. (1) Have you an other solution about 2$1 | tee -a $LOGFILE ? (Or may be re-explain me again with an example) Start your script as a background process and then you can do 'tail -f logfile' to follow the progress on screen. Jari -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to compile Terragear-cs ?
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 script in a terminal, and open another terminal to do the tail command, repeatedly... The -f option to tail will make tail output everything added to the file by one single start of the tail command. Jari -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Jenkins mac build #871 fails to run on Snowleopard 10.6.8 and Lion 10.7.2
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? It's my local box, running 10.7/Lion. I need to find a copy of the 10.6 SDK to build against for Hudson, to fix this issue - thanks for catching. I don't have access to my Lion right now so I cannot check but I think the 10.6 SDK is included already. Jari -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Jenkins mac build #871 fails to run on Snowleopard 10.6.8 and Lion 10.7.2
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: Incompatible library version: fgfs requires version 5.0.0 or later, but libapr-1.0.dylib provides version 4.0.0 Obviously I have a problem with my installed libapr. I am running the latest Xcode (3.2.6) available for Snowleopard. Is there a work around? I haven't tested apr provided by macports since it is out of bounds in this case. What version of Xcode/Mac OS X is the Jenkins server using? 2. On the Lion machine I get: Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_PROTECTION_FAILURE at 0xbf835ffc VM Regions Near 0xbf835ffc: Stack b0083000-b0104000 [ 516K] rw-/rwx SM=COW -- Stack bc036000-bf836000 [ 56.0M] ---/rwx SM=NUL Stack bf836000-c0036000 [ 8192K] rw-/rwx SM=COW Application Specific Information: /Users/jari/Desktop/FlightGear.app/Contents/MacOS/../Frameworks/libosgFX.80.dylib objc[31118]: garbage collection is OFF Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 org.flightgear.FlightGear 0x00574ab0 sinf + 16 1 org.flightgear.FlightGear 0x00574ab5 sinf + 21 2 org.flightgear.FlightGear 0x00574ab5 sinf + 21 3 org.flightgear.FlightGear 0x00574ab5 sinf + 21 4 org.flightgear.FlightGear 0x00574ab5 sinf + 21 5 org.flightgear.FlightGear 0x00574ab5 sinf + 21 which doesn't help me. Has anyone else successfully tried the build? Or any mac build on Jenkins lately? I have lately begun to use the Lion machine to compile fg et al from their respective repositories but I haven't had the time to test the created binaries. When I do I'll post whether it works or crashes. Cheers, Jari -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [Patch] Suggestion to change file permissions of files in getstart git repository
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, Jari From 615d0c7c5cab8592ff0e1d03351ae8234ced91fd Mon Sep 17 00:00:00 2001 From: Jari Hakkinen j...@flygarna.se Date: Sun, 11 Dec 2011 20:48:10 +0100 Subject: [PATCH] Removing executable bit from file permissions. --- source/img/VOR1.eps | Bin 694548 - 694548 bytes 1 files changed, 0 insertions(+), 0 deletions(-) mode change 100755 = 100644 source/basic.tex mode change 100755 = 100644 source/features.tex mode change 100755 = 100644 source/helicopter.tex mode change 100755 = 100644 source/img/Bo105_auto.eps mode change 100755 = 100644 source/img/Bo105_cockpit.eps mode change 100755 = 100644 source/img/Bo105_landed.eps mode change 100755 = 100644 source/img/DH_plane_clipped.eps mode change 100755 = 100644 source/img/Ec135_in_the_air.eps mode change 100755 = 100644 source/img/IAFs.eps mode change 100755 = 100644 source/img/KRHV.eps mode change 100755 = 100644 source/img/MAP.eps mode change 100755 = 100644 source/img/NDB.eps mode change 100755 = 100644 source/img/NDB_flying.eps mode change 100755 = 100644 source/img/Oakland.eps mode change 100755 = 100644 source/img/PT.eps mode change 100755 = 100644 source/img/S76c_landed.eps mode change 100755 = 100644 source/img/VOR1.eps mode change 100755 = 100644 source/img/ap_alt.eps mode change 100755 = 100644 source/img/ap_vs.eps mode change 100755 = 100644 source/img/big_plate.eps mode change 100755 = 100644 source/img/ident_knob.eps mode change 100755 = 100644 source/img/localizer.eps mode change 100755 = 100644 source/img/murk.eps mode change 100755 = 100644 source/img/panel_labelled.eps mode change 100755 = 100644 source/img/sectional_labelled.eps mode change 100755 = 100644 source/img/somewhere.eps diff --git a/source/basic.tex b/source/basic.tex old mode 100755 new mode 100644 diff --git a/source/features.tex b/source/features.tex old mode 100755 new mode 100644 diff --git a/source/helicopter.tex b/source/helicopter.tex old mode 100755 new mode 100644 diff --git a/source/img/Bo105_auto.eps b/source/img/Bo105_auto.eps old mode 100755 new mode 100644 diff --git a/source/img/Bo105_cockpit.eps b/source/img/Bo105_cockpit.eps old mode 100755 new mode 100644 diff --git a/source/img/Bo105_landed.eps b/source/img/Bo105_landed.eps old mode 100755 new mode 100644 diff --git a/source/img/DH_plane_clipped.eps b/source/img/DH_plane_clipped.eps old mode 100755 new mode 100644 diff --git a/source/img/Ec135_in_the_air.eps b/source/img/Ec135_in_the_air.eps old mode 100755 new mode 100644 diff --git a/source/img/IAFs.eps b/source/img/IAFs.eps old mode 100755 new mode 100644 diff --git a/source/img/KRHV.eps b/source/img/KRHV.eps old mode 100755 new mode 100644 diff --git a/source/img/MAP.eps b/source/img/MAP.eps old mode 100755 new mode 100644 diff --git a/source/img/NDB.eps b/source/img/NDB.eps old mode 100755 new mode 100644 diff --git a/source/img/NDB_flying.eps b/source/img/NDB_flying.eps old mode 100755 new mode 100644 diff --git a/source/img/Oakland.eps b/source/img/Oakland.eps old mode 100755 new mode 100644 diff --git a/source/img/PT.eps b/source/img/PT.eps old mode 100755 new mode 100644 diff --git a/source/img/S76c_landed.eps b/source/img/S76c_landed.eps old mode 100755 new mode 100644 diff --git a/source/img/VOR1.eps b/source/img/VOR1.eps old mode 100755 new mode 100644 diff --git a/source/img/ap_alt.eps b/source/img/ap_alt.eps old mode 100755 new mode 100644 diff --git a/source/img/ap_vs.eps b/source/img/ap_vs.eps old mode 100755 new mode 100644 diff --git a/source/img/big_plate.eps b/source/img/big_plate.eps old mode 100755 new mode 100644 diff --git a/source/img/ident_knob.eps b/source/img/ident_knob.eps old mode 100755 new mode 100644 diff --git a/source/img/localizer.eps b/source/img/localizer.eps old mode 100755 new mode 100644 diff --git a/source/img/murk.eps b/source/img/murk.eps old mode 100755 new mode 100644 diff --git a/source/img/panel_labelled.eps b/source/img/panel_labelled.eps old mode 100755 new mode 100644 diff --git a/source/img/sectional_labelled.eps b/source/img/sectional_labelled.eps old mode 100755 new mode 100644 diff --git a/source/img/somewhere.eps b/source/img/somewhere.eps old mode 100755 new mode 100644 -- 1.7.4.4 -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure___ Flightgear-devel mailing list
Re: [Flightgear-devel] Snow line based on METAR
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 and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Misspelled aircraft name ?
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. -- 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] fgdata: Important note
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 contributed a moderate quality aircraft, or provided 10+ 'good' patches to existing aircraft, I'd be happy to grant them access. I'm aware that the bar *appears* to be set higher than this, but personally I'm happy to liberalise it a bit - the problem is keeping the sense of etiquette that other contributors assume and rely upon. So a period of indoctrination is good, of submitting merge requests and getting some feedback, but it can become a habit, when it doesn't need too. 'we' (the infamous FlightGear we) should probably write a wiki page of aircraft-contributor-etiquette, so we have grounds to revoke people's access if they break the rules. Though just about the only rules I'm aware of : keep it GPL; don't modify other people's work without asking, or trying to ask; try to avoid copy-and-pasting when you can share files or scripts between aircraft One could have a section like (changing references to subversion to git of course) the one below. We use it it some of the open source projects I am a part of, w.r.t. fg I am still a spectator cheering and booing from the stands. I want to contribute Please send an email to the flightgear-devel@lists.sourceforge.net mailing list! If you are not subscribed to the list, you should first register your email address. Tell us what you want to do, download the source using git and hack away. Copied from the Subversion book: If you think that your work is usable for the rest of the community, you should donate your changes to the project. After making your modifications to the source code, compose a clear and concise log message to describe those changes and the reasons for them. Then, send an email to the developers list containing your log message and the output of svn diff (from the top of your Subversion working copy). If the community members consider your changes acceptable, someone who has commit privileges (permission to make new revisions in the Subversion source repository) will add your changes to the public source code tree. Recall that permission to directly commit changes to the repository is granted on merit - if you demonstrate comprehension of Subversion, programming competency, and a team spirit, you will likely be awarded that permission. Cheers, Jari -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata: Important note
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 difficult to see a project lead in fg. What I observe is that some people have more weight in their arguments and as committers they have de facto veto power. What I see is a subset of contributors in fg that could be defined as the project lead. Of course, since this group is not (well)defined there is no control of responsibilities or clear sharing of duties(1). And I also note, fg seems to be thriving without a well defined project lead. Yes, the status seems to create some frustration and changing the structure may do more harm than good. There are many developers doing a really nice effort. (1) Yes, I know, fg is an open source voluntary effort. No one has duties and who can impose work on others? Well, a clearly defined project lead could at least highlight expectations, prioritize and define what needs to be done, and how it should be done to be accepted into fg. And what is not acceptable. Today these decisions seems to be made more or less by single developers. For those of you who make decision remember With great powers comes great responsibility. Sorry for the rant-like appearance of this message. Cheers, Jari -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata: Important note
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, the fact that project does 'okay' without very tight central leadership, mostly, and the attendant responsibility on the people making the decisions :) Let me add a couple comments -- Jari, think through the work load of what you'd like a single leader to do. To be intimately involved in all the major projects and efforts going on. Respond to every issue and question in a timely manner. Have a deep understanding of every corner of the code and the project. I might have use Project lead wrongly, I mean Project lead loosely as an group of people (that is why I did not say Project leader). Ideally a group of people would share the responsibility of the project. This group does not even have to be the lead developers but such a structure would require some loss of freedom that potentially hurt the project. (Didn't Franz Melchior loose some interest in fg due to a freedom clash. We now he is still watching us.) Anyhow, I am drifting off topic but my response was to Heikos questions on who makes the decision and acts as police. It was not meant as criticism of any single person in the project. And not even an attempt to change the project structure. Cheers, Jari - with a full time job not related to flying and with a family needing attention. But, I do need strong coffee during the hours I can play with fg ;) Now imagine people who have day jobs -- who might need to be focused on something else for a good chunk of the day so they can eat and provide shelter for themselves. Oh, and imagine some of these people could have families and kids and spouses that want to have some interaction once in a while. Oh, and not everyone lives on redbull and doritos so there needs to be some sleep planned into the schedule. Should a flightgear leader be allowed to take the night off to watch a sports game or visit friends? So just remember we are doing this all for free on top of all our other life commitments. Maybe I'm wrong, but I suspect that for someone to fulfill your expectations, they would need to be 100% full time dedicated to that single task. And if the FlightGear project can't offer full time pay to that person, how can we expect them to dedicate all their available work time to the task? From my perspective, the FlightGear project has grown way beyond what a single person can hold in their head all at once. This is why we work towards systems that distribute the load and give more access. We aren't perfect and maybe we don't always act quickly enough and certainly we all are human beings and are open for heavy criticism if that's the direction we would want to take this. We are a group of individuals coming together with a common interest. I would hope we realize our own limits and flaws and thus are a somewhat flexible when encountering the limits and flaws in other people. But yet despite our collective limits and imperfections, together we are doing our best to make positive contributions to this wonderful project. Best regards, Curt. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Historic Screenshots
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 history (among others). Does anybody have any screenshots from the early days? Preferably from the 1996 to 2000 period? (Basically from before the implementation of the F3 key. :-) ) Cheers, Durk -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel attachment: sunset2.jpg-- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
I am happy to accept the privileges when/if I begin an aircraft project. I even have plans for that but then again those plans are already 2 years old with no progress :) No, currently I am happy with trying to convince the dev team to accept my small and sporadic contributions. And with git, 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 (if I understand things properly). With the previous monolithic fgdata only a selected group of people had commit privileges. Maybe now, that 'fgdata' is open again, one of the admins should simply add Jari to the list of data maintainers ;-) Cheers, Martin. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after
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 their private spheres in fg-land (if I understand things properly). With the previous monolithic fgdata only a selected group of people had commit privileges. Once the dust settles I think we will see the benefits of giving aircraft developers direct access to their repos. At least the need for setting up other repos will decrease (assuming that not all aircraft developers are anti-GPL) because I think one major reason for setting up external repos are (lack of) commit privileges in fgdata. For those of you who are impatient with the progress, is the now frozen fgdata unusable? Why not stay with it until the new fgdata is to your liking? I haven't pulled the latest fg-state lately so I don't know if this is possible to stay old-school? Cheers, Jari -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
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 there a need to tag all 300+? Only a handful aircraft are part of fg releases. I do understand that some/many have the need to download all aircraft, I will for sure do that. For me the download size is not the issue. I genuinely think that the split will benefit the project. Of course, if it alienates developers then the change may turn out to be a bad move. Why not wait and see how the new repository structure plays out? It is easy to revert if needed. What is the cost? A short delay in committed fgdata changes. Development doesn't have to stop since all of us have a clone of the old fgdata that can be used to keep track of our changes. Jari -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Improved forests
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 you use j++ the compiler has to make a copy of j with each iteration of the loop but if you use ++j it does not have to make a copy. This will make the loop more efficient although only by a small amount. 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 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 [3] is evaluated before the test [2] is done. If the compiler is smart it will produce the fastest binary code regardless ++j or j++. However, if the [3] is more complicated like a hypothetical i = ++j + k the compiler will most probably generate different binary code (compared to i = ++j + k). Jari -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Improved forests
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 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 [3] is evaluated before the test [2] is done. If the compiler is smart it will produce the fastest binary code regardless ++j or j++. However, if the [3] is more complicated like a hypothetical i = ++j + k the compiler will most probably generate different binary code (compared to i = ++j + k). Right, but j++ will increment _after_ it's used, correct? So how could ++j vs j++ generate the same assembly code and be correct? Yes, j++ will increment j after use. The same assembly code in this case is probably because gcc makes optimizations for simple statements like j++; or ++j; These are straight forward for the compiler to perform optimizations for (at least for standard types like doubles, integers, chars etc). For general classes it is probably not legal for the compiler to make similar assumptions when optimizing since the operators ++C and C++ can in principle behave completely differently/unexpectedly ... we are in the mercy of the programmer here. Jari -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Improved forests
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 [3] is evaluated before the test [2] is done. If the compiler is smart it will produce the fastest binary code regardless ++j or j++. However, if the [3] is more complicated like a hypothetical i = ++j + k the compiler will most probably generate different binary code (compared to i = ++j + k). The last line should say ... different binary code (compared to i = j++ + k). Sorry for the typo. Jari -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Shaders and ATI Radeon HD 4670
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 except restarting flightgear. Toggling through different view gives different frame rates where the tower views always gives around 60 fps and the others give 2-5 fps (except the occasional 60 fps I get in the cockpit view). In cases when I get 60 fps in cockpit view my computer maintains 60 fps with 3D clouds and skydome scattering turned on. The frame rate is stable even flying through the magnificently rendered clouds. If I turn of material shaders I always get 60 fps in all different views. (Is 60 fps a maximum reading, I never seem to get higher readings?) On my Macbook Pro (early 2008) model, I always get 60 fps staying away from the 3D clouds but the frame rate drops to 20 fps when I fly through clouds. The MBP has a GeForce 8600M GT 256 MB VRAM. The test on my iMac was done on yesterdays source from the various repositories and everything is compiled with -g -O3 (-O2 gives the same numbers). I have also tested a couple of Tat's git snapshots from the macflightgear site and they give similar negative shader effect. I read through many posts on flightgear and shaders on the web but nothing has resolved my issue. Is the above a flightgear issues or is it my hardware? I haven't noticed anything strange with my iMac and Apples extended hardware test does not report anything. Cheers, Jari -- 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-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and ATI Radeon HD 4670
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 contributors to a low framerate - AI traffic is one. Wow. That's an incredibly small amount of video RAM for a video card that new. Can you upgrade it to something with more RAM? Otherworldcomputing.com has two options; ATI Radeon HD 5670/512MB (USD180) and ATI Radeon HD 5750/1GB (USD400). 400 is a lot, will the cheaper 512MB card make a noticeable difference? And, opening an iMac isn't for the faint-hearted. Jari -- 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-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders and ATI Radeon HD 4670
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 traffic is one. 60 fps could be a maximum if you are using this option - --prop:/sim/frame-rate-throttle-hz=60 It might well be on by default. I am not using the frame-rate-throttle option but I tried it with a lower limit. This will naturally decrease the frame rate so it seems like 60 is a limiting number. I have to decide if the 3D clouds are worth a graphics card upgrade. Thanks for the response. Jari -- 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-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear development entered state feature-freeze until July, 17th 2011
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 repositories for fg source/data and simgear. There are many other 3rd party software dependencies whereof the most prominent are plib and osg. Which version of these packages should be used for 2.4.0 testing? Cheers, Jari -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is FlightGear GPL2 and later or GPL2 only?
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 there is a GPLv2 or later statement in the original license. A GPLv2 only clause may block redistribution under GPLv3, I do not know and really I do not care. Pulling all fg related material under GPLv2 or later license and pushing to another repository, i.e. forking, and changing the license to GPLv3 is legal. Pulling the material from the repo and simply pushing it back to the same repository may pose interesting legal questions. Can such an act be considered redistribution? Is a redistribution required to change license to GPLv3? The legality is really irrelevant because making such a move without the consent of the authors of code under GPLv2 and later will probably alienate contributors. The fg project should avoid making license changes without the consent of authors in the repositories it controls, but the fg project cannot prohibit 3rd parties from actually changing their redistribution license to GPLv3 (if GPLv2 or later was used originally). A resolution maybe be that all contributors to single files agrees to revoke or later from each single file (note, all contributors must agree or the file must be replaced with independent art). As time goes by new improved code in the GPLv2 only files will supersede the files with loose GPLv2 or later clauses and deem the files obsolete. Open source GPL contributors should remember, we _choose_ to release our work under GPL. The GPL ideology is to keep the or later clause. Why fight it? If the GPL way of licensing is not for you then you should find another license that fits your needs and optimally it is GPL friendly so that files/code can co-exist. I heard the argument: This project is so cool, I want to contribute but I don't like the license. Well, then this project is obviously not for you. Remember, many times the coolness comes because of GPL. I agree that files in fg controlled repositories that were changed by accident from GPLv2 to v3 should be restored to the original license. Cheers, Jari -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos and licensing
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, Jari-- 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
Re: [Flightgear-devel] Pro Flight Simulator disclaimer, accurate?
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 modification in machine readable form. 2) It is legal to try to make money out of GPL software Comments on 1). A simple google search (I used source site:proflightsimulator.com) will lead to http://www.proflightsimulator.com/downloads716/ReadMe.txt where we can read Source Code: Full source code has not been included in the download area, however it is available on request. Please contact us if you require this. http://proflightsimulator.com/support/ So I suppose one could test them by requesting the source. They should provide it in machine readable form and then we can scrutinize their modification and use them if we choose to (and this would actually benefit proflightsim!). If they do not provide the source then they break the license agreement. But are we prepared to battle this in courts? Probably this is the only licence breaking proflightsim does? Comment on 2). If they provide a better user experience (as they claim to do) then go ahead an charge your user base but remember to provide source to whoever requests it. I do not support their business model mostly because they make it hard to get their source code modifications (i.e., no simple download source link) and are somewhat obscure with their relation to fg. However, we must accept that others may be able to make money out of GPLd software. The way to counter the above is to make sure that flightgear.org is so much better than the opposition that the opposition fade away. Unfortunately this does not always mean technical brilliance from a user point of view but rather user experience. That is something proflight may have realized, I have not tried their package so I cannot make a judgement whether they improve user experience or not. I think that the single most important thing fg could do to fight flightpro and similar is to improve user experience and release often. I think that the latter is being worked on. I know that user experience is getting better all the time but there is a lot more that could be done for the non-technical user. But these two points are assuming that we want to expand the user base. Cheers, Jari - not affiliated with any commercial or shady flight simulator business but a user of Microsoft flight simulators and FlightGear (git next branch) On 2011-01-14 11.08, Chris Wilkinson wrote: http://www.proflightsimulator.com/fg-help.htm Any comments into the accuracy of this statement? Regards, Chris Wilkinson, YBBN/BNE. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] new install git hung up // xplane airport format
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 mich...@ubuntu:/media/Suse-Home/fgfs/install/fgrun/bin$ You need to set up LD_LIBRARY_PATH so that your machine can locate fg required libraries. Try adding something like LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/media/Suse-Home/fgfs/install/fgrun/lib to the beginning of fgrun. I guess the lib-path above but it should be the directory where you install OSG. Cheers, Jari -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Datapath name
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 the previous usage of the macro in flightgear is deprecated. The pre-Npv2010 usage of AM_INIT_AUTOMAKE does not match the default automake naming scheme. Remember autotools is created by unix-people and they are generally not CamelCase friendly. The AC_INIT line sets many strings (such as PACKAGE_NAME to FlightGear) but not string PACKAGE that is actually set by AM_INIT_AUTOMAKE to flightgear. The PACKAGE string is used to derive the tar-ball name. There is probably ways around it but I suggest that FlightGear data directories are renamed to flightgear. Or follow Curt's --fg-root advice Cheers, Jari On 2011-01-08 17.38, Curtis Olson wrote: I'm not seeing where PACKAGE is explicitly set anywhere in configure.ac or Makefile.am This might not be a change we made, but perhaps a change in the underlying autotools software defaults? In configure.ac we have: AC_INIT(FlightGear, m4_esyscmd([cat ./version | tr -d '\n']), [ http://www.flightgear.org]) I *think* that this is where @PACKAGE@ get's defined for the autoconf system, and as you can see, it's still properly capitalized in our configuration. Perhaps the autotools are forcing everything to lower case? If you add --fg-root= into your ~/.fgfsrc then it shouldn't matter ... Regards, Curt. On Tue, Jan 4, 2011 at 5:42 PM, Ron Jensen wrote: I haven't pulled from git for a while. I built last night and discovered the name of the data paths has changed from FlightGear to flightgear. I assume this is unintentional? Would someone give me a hint on how to change this back? Thanks Ron (old source Makefile) pkgdatadir = $(datadir)/FlightGear pkglibdir = $(libdir)/FlightGear pkgincludedir = $(includedir)/FlightGear (new source Makefile) pkgdatadir = $(datadir)/flightgear pkglibdir = $(libdir)/flightgear pkgincludedir = $(includedir)/flightgear -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Datapath name
Adding the next two lines dnl Next line is to retain backward compatibility for PACKAGE variable AC_SUBST([PACKAGE],[$PACKAGE_NAME]) after AM_INIT_AUTOMAKE([dist-bzip2]) will give back FlightGear in Makefile and other places. I cannot safely say that there won't be any side effects. It may 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://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 the previous usage of the macro in flightgear is deprecated. The pre-Npv2010 usage of AM_INIT_AUTOMAKE does not match the default automake naming scheme. Remember autotools is created by unix-people and they are generally not CamelCase friendly. The AC_INIT line sets many strings (such as PACKAGE_NAME to FlightGear) but not string PACKAGE that is actually set by AM_INIT_AUTOMAKE to flightgear. The PACKAGE string is used to derive the tar-ball name. There is probably ways around it but I suggest that FlightGear data directories are renamed to flightgear. Or follow Curt's --fg-root advice As Jari notes, this was an unintentional effect of me updating configure.ac to use the currently-recommened _INIT_ macros for autoconf and automake. My concern was to get the version number encoded in a way that other builds tools besides configure could 'see' - hence the ugly 'm4_esyscmd' trick which is apparently the standard way of accomplishing this. Obviously I didn't change the package name when I made the change - it's still 'FlightGear' - but the autoconf docs do state that the package name (eg, for 'make dist' tarbballs) is created by changing this to lowercase, and replacing all non-alphanumeric characters with an underscore. I presume the autoconf maintainers would say this is a feature, but it's subjective :) Unfortunately I don't have a solution to restore the old naming scheme - perhaps we can simply override the value of the autoconf PACKAGE variable after invoking AC_INIT? I don't know what other paths and names are derived from this value, and if that will trigger other problems. The path of least resistance would be to accept autoconf's naming scheme, but maybe that's unpalatable. Regards, James -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs configure error
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 used to test the simgear version. Are the -I options pointing to the proper location? And are the locations really free from the old version.h? Remember to also check the default header file locations like /usr/include. As a final step I'd do a search like find / -name version.h | grep simgear to locate all simgear version.h files. Is FG_ROOT pointing to /usr/local? Cheers, Jari On 2011-01-06 06.29, dave perry wrote: With today's simgear and flightgear source from git, after compiling and installing simgear, fgfs ./configure CFLAGS=-march=native CXXFLAGS=-march=native --prefix=$FG_ROOT fails with checking simgear/version.h usability... yes checking simgear/version.h presence... yes checking for simgear/version.h... yes checking for SimGear 2.2.0 or newer... [found 2.0.0] ... wrong version configure: error: Install latest SimGear first... make: *** [config.status] Error 1 I assume that it is checking the file /usr/local/include/simgear/version.h that was written by the simgear sudo make install. That file contains #ifndef _SIMGEAR_VERSION_H #define _SIMGEAR_VERSION_H #define SIMGEAR_VERSION 2.2.0 #endif // _SIMGEAR_VERSION_H which should have passed the test. I do have a source folder for SimGear 2.0.0 that contains simgear/version.h that would not pass. But I did a make uninstall in that folder before compiling and installing the git simgear. Suggestions? -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor menu renaming
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 option in fg, if not why not add one, and then use this option to generate different dialogues? Cheers, Jari Stuart Buchanan skrev 2010-12-28 01.44: On Mon, Dec 27, 2010 at 8:51 PM, Gijs de Rooy wrote: (Why) do we need two buttons to close a dialog? I recently removed the ones that say Close on most dialogs, replacing them with small buttons in the top right corner. There are quite some dialogs that don't have a normal close button (like Route manager, Aircraft help, Common keys, Property Browser). I personally very much prefer those. You are an expert user, who already knows that the unlabeled box in the top right corner is a button, and what it does. Don't over-estimate the computing knowledge of a new user - they have none of that knowledge, and simply won't know how to dismiss the dialog. Remember - the FG Plib-based FG UI is going to be quite alien to them, as it's not got the same look and feel to the window systems they might be used to. They aren't going to guess that the object in to the top right corner is a button that acts like the X button in the top right of their Windows box, assuming that they even use that. Putting this another way, I'm not aware of any other GUI targetted at non-expert users (i.e. people specifically trained to use that software) that does not provide a clearly labeled button (OK/Cancel/Close) to dismiss every single dialog box within the UI. Frankly, if I'd been aware that you'd removed all the Close buttons, I'd have complained very loudly. I consider that to be a serious usability regression. The reason I've left the top-right button in place is partly for consistency with some of the expert and long-lifed dialogs, and partly so that the top of the dialog box looks like a title bar, with the title of the dialog, the small close button, and a horizontal line. The Close buttons just take up space and block my view on the instruments and environment even more... The dialogs I have added it to are ones which a user will use and then dismiss. I have not added it to dialogs such as the MP Pilot List and Stopwatch, nor do I intend to add it to expert dialogs such as the Property Browser. What other dialogs do you leave open for prolonged periods while flying? IMO, much worse is cluttering up a new users display with dialogs that they cannot dismiss! :) We should teach our users to use the small button in topright corner, else they will have a problem in those dialogs that only have such small button. Besides that, less buttons make things look easier, something that FlightGear lacks accordint to a lot of users. How would you teach our new users? They don't read our documentation. We cannot teach our users to use a small unlabeled button in the top right corner. There simply has to be a clearly labeled button to close the dialog, which is what I'm attempting to ensure it present on all dialogs. On Mon, Dec 27, 2010 at 9:07 PM, Gary Neely wrote: I'd like to back Gijs up here. I've worked in usability studies, and these things make a difference in the user's experience. Minimizing clicking and placing buttons in consistent locations makes for a considerably more pleasant experience. I've also worked on usability studies. One consistent result from them is not to over-estimate the competance of the average user. The change I've made has improved consistency and usability by ensuring that there are clearly labeled buttons to dismiss the dialog on (almost) all the dialogs. I think I've covered all the XML dialogs. In my next pass, I'll go through and modify the C- and Nasal generated ones, with the exception of the dialogs that are clearly intended to remain active for a long time (pilot list, stopwatch), and dialogs targeted specifically at expert users, like the Property Browser. -Stuart -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise,
Re: [Flightgear-devel] FPE while in-flight
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 like ignoring such exceptions, since it often hides real programming errors. So, yes, I think it'd be great if someone had a look into these issues, finds all the bad computations and fixes them. However, since everyone (?) else in FlightGear keeps FPEs disabled, it may turn out to be a Sisyphean task to rid _all_ such occurrences... It is always possible to throw in asserts (http://www.cplusplus.com/reference/clibrary/cassert/assert/) in the code and later use NDEBUG to disable the asserts for production code. Cheers, Jari -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
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 thanks to Olaf Flebbe for moving things forwards on Windows), but they're still immature. Does this indicate that autotools support will be discontinued for fg et al? My motivation for creating these was my Mac Xcode projects becoming outdated as the tree (and config) evolves - so I'll be maintaining these, but of course if you're adding or removing files from the build, I would be delighted if you update the CMakeLists.txt file at the same time as you update the Makefile.am. The current autotools set up builds everything on Mac, no need for Xcode. Cheers, Jari -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flightgear ./configure apr-1-config
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. The problem is really that the default is to try to use libsvn but the default should be the other way around, i.e., require './configure --with-libsvn' rather than, as it is today, require disabling usage of libsvn with option --without-libsvn to configure. 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. Currently apr is a pre-requisite for building flightgear cleanly in default mode of configure. Cheers, Jari It has been broken for a long time ... since well before the previous release. The fix is available at http://gitorious.org/~jsd/fg/sport-model/commits/minor in particular http://gitorious.org/~jsd/fg/sport-model/commit/fd10a6803f36c383cb9acf4882cbdd0c1a880d20 -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flightgear ./configure apr-1-config
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, it is difficult to check for svn headers without apr since most of the svn headers include apr headers. So there is a need to check for apr before checking for libsvn. We can include the find_apr.m4 macro found in the svn repository, http://svn.apache.org/viewvc/subversion/trunk/build/ac-macros/ to the fg/source tree (e.g. in a directory source/m4 where this and other build support macros could be added). I can produce a better libsvn et al. checking configure.ac if there is any chance it will make into the repository. One of the committers is welcome to respond if they can consider to review such as change. Cheers, Jari -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] MacOSX Flightgear 64bit observation (patch included)
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]
AircraftOptions#awakeFromNib: OSX::OCDataConvException: Cannot register
the given selector 'applicationWillTerminate:' as an informal protocol
method of type 'v...@0:8...@16', because another informal protocol method is
already registered with the same signature (but with another type,
'v...@0:4...@8'. Please rename your selector.
/System/Library/Frameworks/RubyCocoa.framework/Resources/ruby/osx/objc/oc_wrapper.rb:50:in
`ocm_send'
/System/Library/Frameworks/RubyCocoa.framework/Resources/ruby/osx/objc/oc_wrapper.rb:50:in
`method_missing'
/Users/jari/projects/fg/macbundle/FlightGear.app/Contents/Resources/SearchableOptions.rb:41:in
`awakeFromNib'
/Users/jari/projects/fg/macbundle/FlightGear.app/Contents/Resources/SearchableOptions.rb:40:in
`each'
/Users/jari/projects/fg/macbundle/FlightGear.app/Contents/Resources/SearchableOptions.rb:40:in
`awakeFromNib'
/Users/jari/projects/fg/macbundle/FlightGear.app/Contents/Resources/AircraftOptions.rb:37:in
`awakeFromNib'
/Users/jari/projects/fg/macbundle/FlightGear.app/Contents/Resources/rb_main.rb:38:in
`NSApplicationMain'
/Users/jari/projects/fg/macbundle/FlightGear.app/Contents/Resources/rb_main.rb:38
A 32bit FlightGear will work without any message. The issue is trivially
removed by renaming methods named applicationWillTerminate in a few
places (see the attached patch for details).
I have search the Net for an explanation for the problem with no success.
Can some one apply the patch to repository
https://macflightgear.svn.sourceforge.net/svnroot/macflightgear/trunk/FlightGearOSX
? It resolves the 64bit problem and does not affect i386 binaries.
Another way to resolve the issue is simply to continue compile the
startup GUI for 32bit (i386) architecture rather than x86_64. But where
is the beauty in that?
Cheers,
Jari
Index: FavoriteOptions.rb
===
--- FavoriteOptions.rb (revision 284)
+++ FavoriteOptions.rb (arbetskopia)
@@ -88,7 +88,7 @@
end
end
- def applicationWillTerminate(notification=nil)
+ def theApplicationWillTerminate(notification=nil)
@dictionary.save()
super()
end
Index: FlightGearController.rb
===
--- FlightGearController.rb (revision 284)
+++ FlightGearController.rb (arbetskopia)
@@ -104,7 +104,7 @@
@path = NSBundle.mainBundle.resourcePath.to_s
notifier = OSX::NSNotificationCenter.defaultCenter
-{'applicationWillTerminate:' =
OSX::NSApplicationWillTerminateNotification,
+{'theApplicationWillTerminate:' =
OSX::NSApplicationWillTerminateNotification,
'windowDidBecomeKeyNotification:' =
OSX::NSWindowDidBecomeKeyNotification,
'reloadAircraft:' = 'FGReloadAircraftNotification',
'selectAircraft:' = 'FGAircraftDidSelectNotification',
@@ -247,7 +247,7 @@
NSNotificationCenter.defaultCenter.removeObserver_name_object(self,
NSWindowDidBecomeKeyNotification, nil)
end
- def applicationWillTerminate(notification=nil)
+ def theApplicationWillTerminate(notification=nil)
# save all the instances of Option
ObjectSpace.each_object(Option) {|option| option.update(); option.save()}
Preferences.setValue('advanced', @advanced.state.to_i)
Index: SearchableOptions.rb
===
--- SearchableOptions.rb(revision 284)
+++ SearchableOptions.rb(arbetskopia)
@@ -35,7 +35,7 @@
def awakeFromNib()
@table.setDataSource(@dictionary)
notifier = OSX::NSNotificationCenter.defaultCenter
-{'applicationWillTerminate:' =
OSX::NSApplicationWillTerminateNotification,
+{'theApplicationWillTerminate:' =
OSX::NSApplicationWillTerminateNotification,
'synchronize:' = OSX::NSWindowDidBecomeKeyNotification
}.each do |selector, name|
notifier.addObserver_selector_name_object(self, selector, name, nil)
@@ -69,7 +69,7 @@
@table.reloadData()
end
- def applicationWillTerminate(notification=nil)
+ def theApplicationWillTerminate(notification=nil)
NSNotificationCenter.defaultCenter.removeObserver(self)
end
--
What happens now with your Lotus Notes apps - do you make another costly
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more.
[Flightgear-devel] MacOSX FlightGear patch and question
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
that there is a NSAutoreleasePool missing somewhere. Looking into main.m
(https://macflightgear.svn.sourceforge.net/svnroot/macflightgear/trunk/FlightGearOSX/main.m)
there is a line containing 'detachNewThreadSelector' that causes the
problem. I have modified the code to get rid of the message (see
attached patch).
However I am confused about the code in main.m. Why is the
LauncherThread implemented? In my test set up main.m can be 5 (five)
straightforward lines:
--- working main.m ---
#import RubyCocoa/RBRuntime.h
int main(int argc, const char *argv[])
{
return RBApplicationMain(rb_main.rb, argc, argv);
}
--
Is there any need to include LauncherThread? The main.m code is four
years old, maybe there was plans to do something that never was
finished? Or maybe it is remains from old code? My Objective-C knowledge
is very limited so can someone confirm my findings and, if appropriate,
update main.m to something like the above or at least to apply the
attached patch to remove the annoying message about leaking.
Cheers,
Jari
Index: main.m
===
--- main.m (revision 284)
+++ main.m (arbetskopia)
@@ -23,6 +23,9 @@
int main(int argc, const char *argv[])
{
+ NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[NSThread detachNewThreadSelector:@selector(entry:)
toTarget:[LauncherThread class] withObject:nil];
-return RBApplicationMain(rb_main.rb, argc, argv);
+ int retval=RBApplicationMain(rb_main.rb, argc, argv);
+ [pool release];
+ return retval;
}
--
What happens now with your Lotus Notes apps - do you make another costly
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem updating fgdata from mapserver
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 the old hardware before I'm going to declare the transition as being complete. Ok, I _think_ the GIT mirror on the new machine is functional now (at least using git-URL's), please test and enjoy, Martin. -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Problem updating fgdata from mapserver
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 resolve the issue on mapserver or explain what I am doing wrong if the problem is on my side. Cheers, Jari -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem updating fgdata from mapserver
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 my side. You missed this email: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg29756.html about Scenemodels/MapServer.flightgear.org, planned outage Thanks, I remember reading that mail but obviously didn't take notice of the message. I reverted to update fgdata from gitorious: git pull git://gitorious.org/fg/fgdata.git Jari -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft model/cockpit rating
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 that have no, or only rudimentary, cockpit interior details. Vivian Can't we just accept Thorsten's list as a review? Just like films have reviewers and their taste might fit yours. Either you trust the film review or not, and follow the recommendation. After a while you find your favourite reviewers and know which ones actually have similar film taste as you, or even better, draws your attention to films that you might miss otherwise. The same goes with Thorsten's list, either you think the ratings are useful or not. Or better yet, create your own reviews based on more or less subject scores. I hope that Thorsten will keep his list up to date with the development of the different models ... and one day all models have a wow factor! As several others stated before me, I think the list is useful and I'll test a few of the higher ranked planes. Cheers, Jari -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Weather, Nredering and environment bugs
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/ -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] QA
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 and can spend their time on what they want so please spare me the rant). There's a key point here - in the past, people only test release builds - despite pre-relases being made Part of the hope of Hudson, though I didn't get it working yet, is to make it trivial to produce pre-release binaries. Once we do that, people (that's people 'not developers') need to test them, and submit bugs. If you aren't a coder, and want to make FG better, that's the single most useful thing you can do. The only QA resource we have, to make the official releases better, is the end users. That's not ideal, but it's how it goes. (The annual stable release cycle also hinders us here, but that's another thing we can hopefully improve by making stable releases happen a bit more often - one month after the 2.0 release, Git/CVS was in a much better, more stable state than the 2.0 release) In the meantime, test the nightlies, or your own build, or any other recent build, and *file bugs* - and be prepared to re-test them, or check which open bugs you filed are still hanging around three months later. If it's a crash, provide a stack-trace, or some consistent steps to reproduce the crash. I concur with James and like to emphasis the usefulness of releasing often, http://en.wikipedia.org/wiki/Release_early,_release_often Releasing often will enable developers to fix bugs against well defined states of the software and testers to report problems found in well defined releases. Today, there is a fairly short list of people reporting and testing the development branch and flightgear is missing out from the massive parallel testing potentially available. Harvesting the user base for testing is only possible if packages are made available regularly and easily accessibly. The problem of having users, non-developers, reporting bugs is that is fairly hard to find the proper place to file bug reports for flightgear _AND_ the responses on this list can be ... let us say, dismissive. If non-developers are going to report problems (more than once) they should be met with respect even if they did not file a full report. Developers and hobbyist flightgear builders like me should be able to provide good bug reports but people responding to bug reports must be able to discriminate between types of reporters. I think Hudson is a very good effort and I hope Hudson will soon be able to produce a full (64bit) mac application with the GUI starter and the works. I'd rather be on the user/tester side than keep building flightgear myself. Cheers, Jari -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Help needed for Flight Gear compilation
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 specific case the PATH variable is used by the OS to find binaries (programs) in the directory location specified in PATH. Cheers, Jari On 2010-11-09 10.27, Deborah Tay wrote: Hey guys! Many thanks to Fred :D I found out what was wrong with my first build, the version.h file wasn't saved correctly, now I've got it! (: As I was saying I wasn't sure what this step meant: 15. Addany_directory_on_any_drive/install/msvc90/OpenSceneGraph/bin andany_directory_on_any_drive/3rdParty/bin to your PATH environment variable I'm not sure what the PATH environment variable means...where am i suppose to add the two bin folders to? Once ive cleared that, whenever i make changes and rebuild FG, i will be able to run it from fgfs in the Release folder right? (: -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] line endings in GIT
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 2010-10-11 20.28, Torsten Dreyer wrote: Hi, we currently have a variety of combinations of line endings in text files. Most use *nix style LF, some (increasing number) DOS style CRLF and I even saw a few that used both styles within a single file. Can some of our GIT gurus explain a best practice how locally configure git so we get a consistent handling of line endings? Or is there a way to configure our gitorious repository to enforce one single style? Thanks, Torsten -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows config.h-mscxx
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 (configure.ac or some associated file depending on the build system setup). (Some) Mac and all(?) linux users use autoconf and there is no issue. I suppose the problem of copying the file and changing the string manually affects windows and mac xcode (I think) users. The source file is the .in file and that should be in the repository and nothing else. All GIT users should be currently working with the same version (2.0.0) in both simgear and flightgear. As and when a new version comes about both these files can be updated and committed by whoever is responsible for raising the issue number. Well, technically git users are working on 2.x (or 2.0.x or what ever the next version will be called). Again, the idea is that the version number should only be changed in one place and propagated by the build system. In your case it is a header for MSVC and for other developers the version will be propagated to other files. This type of scenario is error prone. Cheers, Jari -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] toow many bugs on flightgear sources
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 need to build the different dependencies in proper order using the build tools provided in the different packages (cmake and autotools). You are best of installing the different modules (make install) and use the install location in subsequent build steps. Create a build script that automates the compilation of all packages, run it regularly. Usually you need to use the latest synchronized CVS versions of simgear and flightgear (assuming you are using repository version, replace with git if that is were you fetch the sources). I haven't had time to build flightgear et al. since two months back so cannot say if my set up compiles cleanly today. I expect that it needs some tweaking ... as always. Which isn't a bad thing and should be expected since using the repository stuff is to live on the edge. Cheers, Jari On 5/5/10 12:10 PM, Ingels David wrote: There is a lot of bugs in the structure of the project None of .cpp/.cxx files include all the files they needs, they includes files which includes other files that this .cpp/.cxx depends on. Then if you modify the first include and the consequence is the first include does nt include the other files needed by the .cpp/.cxx then this .cpp/.cxx doesnt compile and its become to be very expensive to detect which include is missing. In collaborative project its really a problem ! The hierarchy of directory is not good enought, The includes directives are bugged: the files includes with absolute reference path and not relative than we have to guess what include directories to set on the path search: A project doesnt have to set include path for all the subproject: you must use relative path on the source code. The interdepencies are chaotics In first attemp to compil i took 3 days to resolve dependencies. Today, after succesfully compile flightgear since a week, I have got the new jsbsim sources and tried to include it on the Flightgear: then i got a lot of dependencies errors (includes, namespace disapeared ect ...) Before to continue to develop the project, structure and hierarchies must be cleaned !! David Ingels -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RE : toow many bugs on flightgear sources
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 tarball, configure, make and make install
- download Simgear, configure,make, make install
- download FlightGear, configure, make, make install
And as James points out there are more tweaking needed on macs.
The build system works, try it. simgear is built independent of
flightgear and flighgear is build with simgear installed somewhere
(normally) outside its own build directory. If you follow the path above
everything should compile.
Do not pursue your include strategy below.
OSG 2.9.7 works for me, and if I remember correctly even 2.9.8 works.
Please search the mailing list archive on building fg et al. There is a
lot of information there.
Still, we do not know what OS you are working on? But then again you
aren't really asking for help.
Jari - is it really me writing this? Is this what happens after a while
with fg? ;-)
On 5/5/10 8:18 PM, Ingels David wrote:
Example taken from hasard: the file fg_props.hxx
the begining of the file is:
// fg_props.hxx - Declarations and inline methods for property handling.
// Written by David Megginson, started 2000.
//
// This file is in the Public Domain, and comes with no warranty.
#ifndef __FG_PROPS_HXX
#define __FG_PROPS_HXX 1
#includeiosfwd
#includesimgear/structure/subsystem_mgr.hxx
#includesimgear/math/SGMath.hxx
#includeMain/globals.hxx
== it didnt include the file /simgear/props.hxx which defines namespace
props and enum simgear::props:STRING
but later it uses namespace and the enum defined in it:
class FGMakeUpperCase : public SGPropertyChangeListener {
public:
void valueChanged(SGPropertyNode *node) {
if (node-getType() != simgear::props::STRING)== here
return;
char *s = const_castchar *(node-getStringValue());
for (; *s; s++)
*s = toupper(*s);
}
== if any of the 4 files included in top of source doesnt include
/simgear/props.hxx than this file doesnt compile: it s abnormal.
The
#includesimgear/structure/subsystem_mgr.hxx
is absolute includes and depends on the search path added on the project
configuration
If the directory hierarchie is well defined, you can set for example a
relative path
#include “../../../../simgear/structure/subsystem_mgr.hxx”
the reader of the source can find immediately where the file included is
and can read it quickly without searching.
I am not against include directory path in project configuration for
example to set up dependencys from external project
Like openscenegraph in flightgear, but, simgear is semi-external, like
jsbsim the sources are compiled in flightgear project
Than it can be considered internal and no include path have to be added
on project, or it can be considered external in the form of a simple lib
to link with and include path in the project are added.
there are other examples where the part simgear/ is missing because the
project configuration include the path:
“../../../../simgear”
other example : the project configuration include the paths :
“../../../src”
“../../../src/include”
= its abnormal use only one of the two solution and set #include
directive in accordance
other example:
in my first atempt to compile flightgear i have used
Openscenegraph2.9.7 because in the doc it is say that
openSceneGraph2.9.6 and above is needed
OpenSceneGraph2.9.7 doesnt link, an obscure probleme of zlib version
used in openscenegraph2.9.7. I have decided to delete 2.9.7 and using
OpenSceneGraph2.9.6
Than i can link with 2.9.6 version
There must be someone designed to decide wich version of external
software to use and responsible of the good integration and test of the
external modules.
Do not tell to “use Version2.9.6 and above”, tell “use only version
2.9.6“ flightgear validated with 2.9.6.
Okay there are tools to setup a new jsbsim in flightgear for example, i
didnt know that before my mail, but i find its not very normal to have
to using tools.
Ok, i am returning to learn how integrate the new jsbsim in FG.
Cordialy,
David Ingels
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Password SOMETIMES required
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 bandwidth required to seed it? I am no expert on this at all, I haven't even created a seed yet. I suppose I am a leech but I browsed the web for a short while and came up with these suggestions: 1) Urgently, someone who has a decent upload speed and has his computer on-line 24/7 could seed the packages and publish them on fg web site and torrent tracker sites ... after reasonable time there would be enough copies available. Assuming that there are not too many leeches I don't think bandwidth is an issue. 2) Maybe web seeding could solve the problem? http://en.wikipedia.org/wiki/BitTorrent_%28protocol%29#Web_seeding 3) Or maybe one of the current ftp site maintainers could utilize http://www.torrentflux.com/ which may help? 4) There are seed boxes that can be used for a cost, http://filesharefreak.com/2009/01/15/10-really-cheap-seedboxes-that-anyone-can-afford/ As I understand the problem for fg is that we cannot rely on someone seeding just to be nice, it must be a more central source. Naively I think this is accomplished by setting up a tracker for the fg torrents only (or use a public tracker) and providing a seed that is always online. This would guarantee the availability (avoid the swarm to die http://en.wikipedia.org/wiki/BitTorrent_%28protocol%29#The_leech_problem) of the packages but benefit from other peers during peak traffic. I think this is something that should be set up by the current bandwidth providers. They would benefit from the set up also. Surely, there must be someone among the list readers who knows more about these things? Jari -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An important message for mirror maintainers
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 primarily directed to those of you who maintain mirrors of the FlightGear ftp content. Heads up! :-) For quite some time ftp.flightgear.org has resided on a machine I manage myself. This worked out pretty well mostly when I set it up, but since then my work situation has changed and I no longer have physical access to the machine. In addition, the ftp drive on this machine has died. It's an older machine, it's not convenient for me to get to it, and I think it's time to start looking at moving on. Currently I am able to push content to 3 ftp sites. So if you maintain a mirror, please stop mirroring from ftp.flightgear.org and point to one of the following machines. mirrors.ibiblio.org is probably the preferred source if you were going to pick just one. ftp://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/ ftp://ftp.kingmont.com/flightsims/flightgear/ ftp://ftp.goflyflightgear.com/flightgear/ I notice that mirrors.ibiblio.org does offer an anonymous rsync daemon with flightgear as one of the available targets (run rsync mirrors.ibiblio.org:: to see the available ibiblio.org rsync targets, and note the double colon in the syntax.) I am hopefully that as many of our mirror maintainers as possible can get their mirroring source adjusted quickly to help distribute the load of the upcoming v2.0.0 release across as many servers as possible. Best regards, Curt. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ILS problem at EDDB
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 you'll find this row 10 52.372560 013.505561 07R 68.77 9807 . 0984.0984 148 351351 1 0 3 0.25 1 0300.0300 and in nav.dat.gz you'll find rows like 4 52.37906900 013.53301100157 11070 18 68.790 ISSE EDDB 07 ILS-cat-I I assume that the above mismatch will create the assert (now removed by James in CVS) reported by Jacob. James' fix will now simply ignore the issue of a missing runway and report some default value. It maybe that fg knows to map 07 to 07R by some magic or to xxx (there are many xxx fields in apt.dat.gz) but reading the dat files indicates that something is wrong. Jari - I am not Lithuanian but apparently litanian. On 2/15/10 2:26 AM, Jacob Burbach wrote: Start at EDDB and tune nav radio to ils frequency 110.70 fgfs: ../../../src/Instrumentation/navradio.cxx:920: double FGNavRadio::localizerWidth(FGNavRecord*): Assertion `rwy' failed. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Code.google bug tracking
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 that. How about setting up a specific feature request list and ask people to use that rather than the defect list? The moderator of the defect list could just move feature requests that wrongly was added as a defect to the feature request list. Having a feature request list would allow people to discuss suggested features and discussions would be recorded for all to read (rather than searching through the mailing lists). The request list should be moderated too. Jari -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] DELETE DUPLICATE FG DATA FILES
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 this is a homage to Microsoft ;-) Jari U Aircraft/A380/Models/A380.rgb C Aircraft/A380/Models/a380.rgb U Aircraft/A380/Textures/Livery/House/COWLING.RGB C Aircraft/A380/Textures/Livery/House/COWLING.rgb U Aircraft/A380/Textures/Livery/House/ENDPLATE.RGB C Aircraft/A380/Textures/Livery/House/ENDPLATE.rgb U Aircraft/Long-EZ/Nasal/Electrical.nas C Aircraft/Long-EZ/Nasal/electrical.nas U Aircraft/Zlin-50lx/Models/Lights/WhiteLight.xml C Aircraft/Zlin-50lx/Models/Lights/Whitelight.xml U Aircraft/dhc2/Models/Instruments/KN53.png C Aircraft/dhc2/Models/Instruments/kn53.png U Aircraft/eurofighter/Models/Typhoon.xml C Aircraft/eurofighter/Models/typhoon.xml U Aircraft/fokker50/Models/instruments/general/NAV.RGB C Aircraft/fokker50/Models/instruments/general/nav.rgb As stated before, since WIN32 is NOT case sensitive to file names, this causes CVS to always print a message of the form - cvs update: move awayfile-name; it is in the way and only ONE file is downloaded - probably not always the 'right' one ;=((. To try to HELP I have looked up the LAST CVS modifications, and that is where I got the above name list from ;=)) For the first 3, it seems Curt should delete the 5 year old initial version, leaving the 'mfranz' 20 month old files in place, assuming these are the 'correct' ones? The 4 and 5, it seems Emmanuel (helijah) just checked in a duplicate with a different case spelling, but then perhaps was NOT able to DELETE the 'bad' one, or 'forgot'... Likewise 6 and 7 are different case spellings almost the same time, by Syd and Detlef respectively, but the 'bad' one should be deleted. The 8th is also be different parties - Melchior and Erik - not so far apart, so again, the 'bad' one should be DELETED. Last CVS modifications :- A380.rgb 1.1 20 months mfranz Ampere K: All credits go to Fahim Dalvi for this impressive work. This update... a380.rgb 1.1 5 years curt Initial revision of A380, flight model is not yet flyable, but external 3d model... COWLING.rgb 1.1 20 months mfranz Ampere K: All credits go to Fahim Dalvi for this impressive work. This update... COWLING.RGB 1.1 5 years curt Initial revision of A380, flight model is not yet flyable, but external 3d model... ENDPLATE.rgb 1.1 20 months mfranz Ampere K: All credits go to Fahim Dalvi for this impressive work. This update... ENDPLATE.RGB 1.1 5 years curt Initial revision of A380, flight model is not yet flyable, but external 3d model... electrical.nas 1.2 7 months helijah - new instruments, new avionics, all by Viper. Thanks to him Electrical.nas 1.1 8 months helijah - new instruments, new avionics, all by Viper. Thanks to him WhiteLight.xml 1.1 3 months helijah - Add IFR mod by Victhor Whitelight.xml 1.1 3 months helijah - Add IFR mod by Victhor KN53.png 1.1 17 months sydadams Remapped , added liveries , switched to OSG hotspots, PNG textures... kn53.png 1.1 17 months sydadams Remapped , added liveries , switched to OSG hotspots, PNG textures... Typhoon.xml 1.3 19 months dfaber Cockpit improvements, livery select, FDM adjustments typhoon.xml 1.1 20 months dfaber Eurofighter Typhoon, model by MaverickAlex, FDM and animationd D. Faber, initial... nav.rgb 1.1 12 months mfranz fix fg-check reported problems (dos line endings etc.) NAV.RGB 1.3 10 months ehofman latest updates from FokkerCharlie et all I hope these 8 data duplications can be cleared up sometime SOON ;=)) Regards, Geoff. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
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 for every required library separately.
I did comment out some lines for MacOS framework users in SimGear
because I don't think they are needed there. Please report if I was wrong.
I had to remove one line in the simgear/configure.ac to get through
compilation:
@@ -497,7 +509,6 @@ case ${host} in
dnl instead of OSG frameworks on Mac OS X
dnl
AC_CHECK_LIB(OpenThreads,OpenThreadsGetVersion)
-LDFLAGS=$LDFLAGS -L$with_osg
fi
;;
*)
The problem is that -L$with_osg will evaluate to a plain -L resulting in
linker issues during build.
Otherwise the changes works for me on a mac setup with no use of OSG
frameworks.
Jari
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
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 libraries in a 'standard' place... then there is no reason to have aborted the configure step... and they can continue with make... But I agree, it does seem better to abort, but not essential. I think it is helpful to actually report potential problems found in the end of the configure script. For each important 'no' found a flag can be set and in the end of the configure script a warning message AC_MSG_WARN (or a fatal message AC_MSG_ERROR) can be displayed to inform the user that there are unresolved issues. The problem is that there are quite a few 'no's that are not fatal and for newcomers to fg/sg it is not easy to understand which 'no' to ignore. Personally I keep track of failed checks and report them in the end of my configure.ac's. I even conclude with printing all important variables like # Some more messages. AC_MSG_NOTICE([ Ready to compile the executables of svndigest $VERSION The following flags and libs will be used: +++ Compiler: $CXX Preprocessor flags: $SD_CPPFLAGS $CPPFLAGS CPPFLAGS: $CPPFLAGS DEFAULT_CPPFLAGS: $DEFAULT_CPPFLAGS APR_CPPFLAGS: $APR_CPPFLAGS SVN_CPPFLAGS: $SVN_CPPFLAGS PLPLOT_CPPFLAGS: $PLPLOT_CPPFLAGS C++ flags: CXXFLAGS: $CXXFLAGS DEFAULT_CXXFLAGS: $DEFAULT_CXXFLAGS Linker flags: LDFLAGS: $LDFLAGS APR_LDFLAGS: $APR_LDFLAGS SVN_LDFLAGS: $SVN_LDFLAGS PLPLOT_LDFLAGS: $PLPLOT_LDFLAGS Libraries: LIBS $LIBS APR_LIBS $APR_LIBS SVN_LIBS $SVN_LIBS PLPLOT_LIBS $PLPLOT_LIBS +++]dnl ) and I even end with AC_MSG_NOTICE([Now type 'make all check'.]) to indicate what the user should do next. Of course, any fatal failures will make configure to not display the last message. sg/fg configure.ac is not providing the above service (sg/fg does print some final messages) is not a bug but could be added to some list as a feature request. Cheers, Jari -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration info (svn part)
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 _please_ stop this litany ? One posting of this sort per day should really be enough, two or more are a nuisance. According to my experience you're trying to make people throw the baby out with the bath water, which is not appropriate here. Well, I am only trying to suggest improvements to the code/build environment. I think this is the first time I actually suggest a feature to be thrown out. I remember trying to convince developers to remove dependencies on PLIB parts that are implicitly stated to not being used according to the fg build instructions. I have suggested that some code should be conditionally built (i.e. by doing make check). I had a few more posts but my hope and intent is that my postings actually improves fg. Nae, sorry Martin I have something more to say about terragear and subversion. I posted my previous message with a few things in mind 1) Document for other newcomers (I been around for one year soon but still consider me a fg code beginner since I only look at the code occasionally) that there are some strange features wrt subversion and terragear. They might catch this thread through their favourite search engine. 2) I wanted to report the bug (oups there I used the nasty word) in terrasync ... it locks directories. I gave a reference to another posting where I think it was clear that the issue was not being fixed by the father of the baby. 3) Also, on my machine with subversion development libs the configuration script fails out of the box. Therefore I attached a patch for others to use or ignore. 4) I also acknowledged the fact that Geoffs was right but I wanted to highlight that the terragear flaw is still valid. Geoffs response to my posting explains why he is not experiencing the issues I see. If we were to drop every feature which _might_ occasionally have a malfunction here or there, then we would end up with having no FlightGear at all, The problem is that the terrasync issue happens almost every time I run fg but then of course terragear is started each time I run fg (even for short tests). There are many directories to sync each time terrasync stars. I don't want to drop features and I am crazy enough to run terragear with the current subversion flaw ... hoping it will be fixed some day. Am I the only one using subversion built-in terragear? Cheers, Jari -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Inconsistencies in nav.dat.gz and apt.dat.gz
Ok, so this really bounces to Tat. Tat, the flightgear source you use is based on what's in git ... looking into fg/source/src/Navaids/navrecord.cxx reveals that the CVS version has some more control code that avoid the issues I reported in this thread. Tat, can you look into this? Martin, 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 current CVS, Martin. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration info
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 -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration info (svn part)
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 altogether or fixed. If removed then all svn checks could be removed. And I hope your other 'svn' changes also make it into CVS... I attach my suggested svn related changes to configure.ac for reference for other new builders of fg. Note, apply the patch cautiously since having svn calls in terrasync may lock the terrasync-WC directories in some cases (with fairly high probability). Maybe there should be a check for APR but I suppose that if svn-devel package are installed then also apr will be available. Geoff, how do you make it through the svn check in configure.ac or really building terrasync? Jari Index: configure.ac === RCS file: /var/cvs/FlightGear-0.9/source/configure.ac,v retrieving revision 1.166 diff -u -p -r1.166 configure.ac --- configure.ac5 Feb 2010 05:40:15 - 1.166 +++ configure.ac5 Feb 2010 16:40:26 - @@ -787,10 +803,9 @@ fi dnl Check for Subversion library support save_LIBS=$LIBS save_CPPFLAGS=$CPPFLAGS -LIBS= +LIBS=`apr-1-config --link-ld` CPPFLAGS=-I/usr/include/subversion-1 `apr-1-config --includes` -AC_CHECK_LIB(svn_client-1, svn_client_checkout3) -AC_CHECK_HEADERS([svn_client.h glut.h]) +AC_CHECK_HEADERS([svn_client.h]) if test x$ac_cv_header_svn_client_h != xyes; then echo TerraSync will shell out for command line subversion svn_LIBS= @@ -798,6 +813,11 @@ if test x$ac_cv_header_svn_client_h != else echo TerraSync will use integrated subversion library AC_SEARCH_LIBS(svn_client_checkout, svn_client-1) + AC_SEARCH_LIBS(svn_delta_version, svn_delta-1) + AC_SEARCH_LIBS(svn_diff_version, svn_diff-1) + AC_SEARCH_LIBS(svn_ra_initialize, svn_ra-1) + AC_SEARCH_LIBS(svn_pool_create_ex, svn_subr-1) + AC_SEARCH_LIBS(svn_wc_version, svn_wc-1) svn_LIBS=$LIBS svn_CPPFLAGS=$CPPFLAGS AC_SUBST(svn_LIBS) -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration info
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 behave well when terrasync is interrupted (svn working copies ends up in locked state). This has been recently discussed on the mailing list. Jari On 2/4/10 2:44 PM, Geoff McLane wrote: On Wed, 2010-02-03 at 08:47 -0700, John Denker wrote: There is a little script to collect that information: http://www.av8n.com/fly/fgfs/barf Thanks John for your 'barf' script. I modified it to suit my Ubuntu environment. My script is at :- http://geoffair.net/tmp/fgfs-info In it I noted you run tests/gl-info, and to my surprise this produced the output :- GL Utility Toolkit (glut) was not found on this system. which is CRAZY since I _DO_ have 'glut' installed! freeglut3 2.4.0-6 freeglut3-dev 2.4.0-6 glutg33.7-25 glutg3-dev3.7-25 libglut3 3.7-25 libglut3-dev 3.7-25 Looking in src/Include/config.h showed the reason. 'HAVE_GLUT_H' was undefined! So that led me back to configure.ac... Yes, it does a check for [... glut.h], and of course does NOT find this... But tests/gl-info.cxx does NOT includeglut.h, but includes GL/glut.h (if not __APPLE__)... It also checks for, and finds glutGetModifiers, and adds the library - result: -lglut So adding a test to configure.ac - AC_CHECK_HEADERS(GL/glut.h) which added - #define HAVE_GL_GLUT_H 1 to src/Include/config.h... So one would have to ask how did you compile gl-info? ... Of course I also then changed 'HAVE_GLUT_H' to 'HAVE_GL_GLUT_H' in gl-info.cxx source, then all is honky dorey... I hope someone will take the time to fix this in FG CVS... Attached below is my diff... Of course this would need to be further adjusted for __APPLE__ Or maybe just remove the - #ifdef HAVE_GLUT_H completely from tests/gl-info.cxx, since fgfs defaults to using the osgviewer. Does fgfs useGL/glut.h anywhere else but in this tests/gl-info??? 'glut.h' appears only mentioned in the old (2005) docs-mini/ README.mingw... HTH Geoff. PS: My info is at - http://geoffair.net/tmp/tempinfo.txt There also seems some problems with tests/alcinfo, but have yet to look into this... attached: fg200-diff01.patch -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration info
On 2/4/10 6:16 PM, Geoff McLane wrote: Hi Jari, HOW? I have nothing against your patch, actually I have thrown away the check for glut.h completely in my local configure.ac. The check for glut.h is not needed. On my machine (Mac OS X 10.6) the AC_CHECK_HEADERS([svn_client.h glut.h]) always fail and in consequence the failure will trigger command line use in terrasync as stated in configure.ac after the AC_CHECK_HEADERS if test x$ac_cv_header_svn_client_h != xyes; then echo TerraSync will shell out for command line subversion svn_LIBS= svn_CPPFLAGS= else ... While I am writing this I realize that one of course need development libs for svn to pass the AC_CHECK_HEADERS so I suppose my statement was not perfectly accurate. I have the devlibs for svn installed and I actually go further in my local change of configure.ac and look for several svn libs: ... else echo TerraSync will use integrated subversion library AC_SEARCH_LIBS(svn_client_checkout, svn_client-1) + AC_SEARCH_LIBS(svn_delta_version, svn_delta-1) + AC_SEARCH_LIBS(svn_diff_version, svn_diff-1) + AC_SEARCH_LIBS(svn_ra_initialize, svn_ra-1) + AC_SEARCH_LIBS(svn_pool_create_ex, svn_subr-1) + AC_SEARCH_LIBS(svn_wc_version, svn_wc-1) svn_LIBS=$LIBS svn_CPPFLAGS=$CPPFLAGS AC_SUBST(svn_LIBS) and build a terrasync with builtin subversion calls. This is not really a good thing since terrasync with builtin subversion calls behaves badly when terrasync is interrupted during subversion calls. An issue acknowledge by Alex Perry in http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25662.html Again, the patch is valid I just wanted to highlight the fact that it may lead to unwanted changes in the build process. Cheers, Jari My patch separated the check for 'svn_client.h' from the check for 'glut.h'... I have no idea why these two checks were put together in the first place... they are nothing to do with each other... And if you checked the config.log you would see that these were always done as two separate, unrelated, checks... So really can NOT understand why you would suggest the patch would 'trigger a build of a terrasync binary' different to anything currently built... It does nothing more that putting #define HAVE_GL_GLUT_H 1 in Include/config.h Please read the patch again... Regards, Geoff. On Thu, 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 is that the current implementation does don't behave well when terrasync is interrupted (svn working copies ends up in locked state). This has been recently discussed on the mailing list. Jari On 2/4/10 2:44 PM, Geoff McLane wrote: On Wed, 2010-02-03 at 08:47 -0700, John Denker wrote: There is a little script to collect that information: http://www.av8n.com/fly/fgfs/barf Thanks John for your 'barf' script. I modified it to suit my Ubuntu environment. My script is at :- http://geoffair.net/tmp/fgfs-info In it I noted you run tests/gl-info, and to my surprise this produced the output :- GL Utility Toolkit (glut) was not found on this system. which is CRAZY since I _DO_ have 'glut' installed! freeglut3 2.4.0-6 freeglut3-dev 2.4.0-6 glutg33.7-25 glutg3-dev3.7-25 libglut3 3.7-25 libglut3-dev 3.7-25 Looking in src/Include/config.h showed the reason. 'HAVE_GLUT_H' was undefined! So that led me back to configure.ac... Yes, it does a check for [... glut.h], and of course does NOT find this... But tests/gl-info.cxx does NOT includeglut.h, but includes GL/glut.h (if not __APPLE__)... It also checks for, and finds glutGetModifiers, and adds the library - result: -lglut So adding a test to configure.ac - AC_CHECK_HEADERS(GL/glut.h) which added - #define HAVE_GL_GLUT_H 1 to src/Include/config.h... So one would have to ask how did you compile gl-info? ... Of course I also then changed 'HAVE_GLUT_H' to 'HAVE_GL_GLUT_H' in gl-info.cxx source, then all is honky dorey... I hope someone will take the time to fix this in FG CVS... Attached below is my diff... Of course this would need to be further adjusted for __APPLE__ Or maybe just remove the - #ifdef HAVE_GLUT_H completely from tests/gl-info.cxx, since fgfs defaults to using the osgviewer. Does fgfs useGL/glut.h anywhere else but in this tests/gl-info??? 'glut.h' appears only mentioned in the old (2005) docs-mini/ README.mingw... HTH Geoff. PS: My info is at - http://geoffair.net/tmp/tempinfo.txt There also seems some problems with tests/alcinfo, but have yet to look into this... attached: fg200-diff01.patch
[Flightgear-devel] Inconsistencies in nav.dat.gz and apt.dat.gz files
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 version on my iMac with debug information and I am trying to find the point of failure. I have not found the problem yet since it took me a while to go through and remove inconsistencies between apt.dat.gz and nav.dat.gz that makes fg to abort (I use the latest CVS version of these files). All inconsitencies are listed below. I get a lot of no such runway '26' at airport CYKF Fatal error: unknown runway 26 at airport:CYKF (received from FGAirport::getRunwayByIdent) Uncaught Exception: you should see a meaningful error message here, but your GLUT (or SDL) library was apparently compiled and/or linked without exception support. Please complain to its provider! Examining the issue reveals that there is no runway 26 in CYKF. There are lines 07x, 14x, and xxx in apt.dat.gz. Just to get further I do changes that resolves the inconsistencies. Then the following message type starts to appear: navaid ENSG 24 ILS-cat-I associated with bogus airport ID:ENSG This message is from function FGRunway* getRunwayFromName(const std::string aName) in file navdb.cxx. The message says it all ... the airport is not in apt.dat.gz This is not really a inconsistency but a missing airport in apt.dat.gz The interesting part is that my 64bit binary does not crash with the above inconsistencies and also Tats 32-bit binary works on my Macbook Pro. Maybe the issues described above are valid only for my local build but there are a many inconsistent entries in the dat-files. I list them below as reference if someone decides to fix the issues and update the dat-files. Cheers, Jari Each inconsitency is reported once but several entries in nav.dat.gz shows similar errors: no such runway '26' at airport CYKF no such runway '07' at airport EDDB no such runway '05' at airport KGVL no such runway '01C' at airport KIAD no such runway '08L' at airport KONT no such runway '01' at airport KSAV no such runway '15' at airport LFSB no such runway '13' at airport LMML no such runway '12L' at airport MMUN no such runway '19' at airport ENNK no such runway '23' at airport LFRU navaid ENSG 24 ILS-cat-I associated with bogus airport ID:ENSG Sogndal, Norway navaid PAED 06 ILS-cat-I associated with bogus airport ID:PAED PAED Elmendorf Air Force Base Anchorage, Alaska, USA navaid PAKU 05 ILS-cat-I associated with bogus airport ID:PAKU PAKU Ugnu-Kuparuk Airport Kuparuk, Alaska, USA navaid PAYA 11 ILS-cat-I associated with bogus airport ID:PAYA PAYA Yakutat Airport Yakutat, Alaska, USA navaid WADD 27 ILS-cat-I associated with bogus airport ID:WADD Ngurah Rai International Airport (IATA: DPS, ICAO: WADD), also known as Denpasar International Airport, is located in southern Bali Indonesia navaid WALL 25 ILS-cat-I associated with bogus airport ID:WALL Sepinggan International Airport map (BPN/WALL) Indonesia navaid WAOO 10 ILS-cat-I associated with bogus airport ID:WAOO Syamsudin Noor Airport (IATA: BDJ, ICAO: WAOO) is an airport serving Banjarmasin in South Kalimantan, Indonesia. navaid WAOP 34 ILS-cat-I associated with bogus airport ID:WAOP Tjilik Riwut Airport (IATA: PKY, ICAO: WAOP), formerly Panarung Airport, is an airport in Palangkaraya, Central Kalimantan, Indonesia navaid WARJ 09 ILS-cat-I associated with bogus airport ID:WARJ Adisucipto (or Adisutjipto) International Airport (IATA: JOG, ICAO: WARJ) is the principal airport serving the Yogyakarta area on the island of Java, Indonesia. navaid WARQ 26 ILS-cat-I associated with bogus airport ID:WARQ Adisumarmo International Airport (IATA: SOC, ICAO: WARQ) is an airport located on Solo, Central Java, Indonesia. navaid WARR 10 ILS-cat-I associated with bogus airport ID:WARR Juanda International Airport (Indonesian: Bandar Udara Internasional Juanda) (IATA: SUB, ICAO: WARR), is an airport located in Sidoarjo, a small town near Surabaya, East Java. navaid WIDD 04 ILS-cat-I associated with bogus airport ID:WIDD Hang Nadim Airport (IATA: BTH, ICAO: WIDD), also known as Hang Nadim International Airport, is located in Batam, Riau Islands (part of Sumatra), Indonesia navaid WIHH 24 ILS-cat-I associated with bogus airport ID:WIHH Halim Perdanakusuma International Airport (Indonesian: Bandar Udara Internasional Halim Perdanakusuma) (IATA: HLP, ICAO: WIHH) is located the Indonesian capital Jakarta navaid ZULS 27R ILS-cat-I associated with bogus airport ID:ZULS Lhasa Gonggar Airport is an airport that serves the city of Lhasa, Tibet, China. navaid ENBL 07 LOC associated with bogus airport ID:ENBL Førde Airport, Bringeland (IATA: FDE, ICAO: ENBL) (Norwegian: Førde lufthamn, Brigeland) is located 400 metres above sea level at Bringelandsåsen in Gaular
Re: [Flightgear-devel] FlightGear Mac OS X pre3
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 the linker to produce fgfs - the linker complains about not being able to find fopen!! I have started a new repoupdate and compile of macflightgear with debug flags using Tat's localbuild script. Atlas crashes too, more about this below. Dual core 2 year old MacBook Pro: fg and terrasync works. Atlas fails. Atlas: The issue with Atlas crashing is that the apt.dat.gz in the package outdated. If I replace apt.dat.gz with the latest CVS version Atlas works. The issue with ATLAS/apt.dat.gz was reported some days ago and fixed in CVS. There is another issue with Atlas. The map goes black when starting from another airport than San Fransisco. Restarting fg will not generated the needed png's. Is Map run properly? Cheers, Jari On 2/3/10 2:53 AM, Tatsuhiro Nishioka wrote: Hi there, I've released the pre3 package of FlightGear Mac OS X at the macflightgear site. http://macflightgear.sourceforge.net Please check it out very quickly so I can have improve the quality of 2.0.0. Best, Tat p.s. Many mac users who gave me emails in the past week: Sorry for my very late reply. I'll be replying one by one tonight. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
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 for the bits.test function. I assume bits.test(oddnumber,0) returns 1 and something else for even numbers, presumably 0? Jari - learning Nasal On 1/29/10 2:34 AM, Ron 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 we get the proper number since 'int' truncates and doesn't round. For example, 111.70 is stored internally as 111.6... since base 2 and base 10 don't play well together below the decimal point. int((111.69...)*10) returns 1116 when what was expected and desired was 1117. 0.001 is large enough to correct the result but small enough not to push us to the next station, station spacing is assumed at 0.05. (The same problem exists in C++.) Ron -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
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 for the bits.test function. I assume bits.test(oddnumber,0) returns 1 and something else for even numbers, presumably 0? You'll find bits.test() in Nasal/bits.nas (it is an FG local extension to the Nasal bits module). The return value is true (i.e.0) or false (i.e. ==0), I would not dare to assume that 1 is always returned for true. Cheers, Anders Right, bits.test(n,b) # checks whether bitb is set in numbern So bits.test(oddnumber,0) is actually a test for oddness. the 0th bit being the only bit that is not a power of two. Ron --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
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 +, Pete Morgan wrote:
I just noticed the info below about localiser on the Flight Simulation
Naviagtion site
http://www.navfltsm.addr.com/
Is there an easy way to determine is the NAV is a Lcoaliser, I cant see
that in Prop tree.
pete
Localizers are found on a few of the NAV frequencies:
http://en.wikipedia.org/wiki/Instrument_landing_system#Frequency_list
Here is a nasal function to determine if a frequency is a localizer. It
accepts a frequency in megahertz and returns 1 if the frequency is an
ILS frequency.
var isILS=func(freq) {
if(freq 108.10) return 0;
if(freq 111.95) return 0;
var bar=int((freq+0.001)*10)-int(freq)*10;
return(bits.test(bar,0));
}
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Deprecating Nasal?
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 wrote:
On Thu, 2010-01-28 at 09:24 +, James Turner wrote:
On 28 Jan 2010, at 03:45, Ron Jensen wrote:
Here is a nasal function to determine if a frequency is a localizer. It
accepts a frequency in megahertz and returns 1 if the frequency is an
ILS frequency.
var isILS=func(freq) {
if(freq 108.10) return 0;
if(freq 111.95) return 0;
var bar=int((freq+0.001)*10)-int(freq)*10;
return(bits.test(bar,0));
}
A general observation - it'd be much better to request C++
properties / native-nasal functions that implement such logic, rather
than coding it up in Nasal (in each aircraft / instrument).
Actually, I disagree with this statement, and it represents a
fundamental shift in attitude from the way I've seen flightgear's
development progressing over the past year or two.
- Hard-coding every instrument in C++ instead of nasal means only
developers following/building the latest cvs head code get to use
whatever until the next release cycle.
- Hard coding every instrument/flight control in C++ means my WW-II
storch (et.al.) is stuck with an autobrake functionality it doesn't have
nor need.
- The pool of people with commit rights to C++ code is very, very small.
Thanks,
Ron
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot tuning
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
On 2010-01-28 21.39, Curtis Olson wrote:
Nasal is like C, C++, perl, and php in many ways so if you can read any
of those, you 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 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 +, Pete Morgan wrote:
I just noticed the info below about localiser on the Flight
Simulation
Naviagtion site
http://www.navfltsm.addr.com/
Is there an easy way to determine is the NAV is a Lcoaliser, I
cant see
that in Prop tree.
pete
Localizers are found on a few of the NAV frequencies:
http://en.wikipedia.org/wiki/Instrument_landing_system#Frequency_list
Here is a nasal function to determine if a frequency is a
localizer. It
accepts a frequency in megahertz and returns 1 if the frequency
is an
ILS frequency.
var isILS=func(freq) {
if(freq 108.10) return 0;
if(freq 111.95) return 0;
var bar=int((freq+0.001)*10)-int(freq)*10;
return(bits.test(bar,0));
}
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in
the business
Choose flexible plans and management services without long-term
contracts
Personal 24x7 support from experience hosting pros just a phone
call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
mailto:Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the
business
Choose flexible plans and management services without long-term
contracts
Personal 24x7 support from experience hosting pros just a phone call
away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
mailto:Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Curtis Olson: http://baron.flightgear.org/~curt/
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atlas assert on apt.dat.gz
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 FlightGear's CVS and check if it's now working as expected. Actually this bunch of airfield improvements grew out of the need of doing _something_ wrt. collecting people's contributions and was never planned to grow that big :-) If this is going to continue, then I'll certainly be going to implement a proper solution which includes automated consistency checking - which it currently does not. Cheers, Martin. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Atlas assert on apt.dat.gz
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 starting with 10 hints on that SOUTH should be changed to S. If the above line is correct the Atlas must be changed (assert triggers on line 409 in AirportsOverlay.cxx, variable rwyid becomes corrupt). If the above line is incorrect it would be nice if someone fixes apt.dat.gz. If the line is correct please comment on that so I can change Atlas to accept SOUTH. Cheers, Jari -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SoundSystem on MacOS
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 have read a report an bad doppler for MacOS then asked for some information but got no reply. If this problem still persists could the MacOS users try this patch? Never mind this patch contains an error so I've put it in CVS. If it's wrong please tell me and I'll remove it again. Erik -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with modified apt.dat file
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 compressing it. I used the command 'tar cfz apt.dat.gz apt.dat'. Is this correct? When I put the compressed file into FG, but there were problems loading. First, it fell over on line 2 (the version number and copyright), so I removed that. It then gets through the file, but seems to get stuck in an infinite loop, not recognising the end of the file. The log looks like this: Logging priority is bulk Setting geometry to 1280x800 Finished command line arguments Initializing splash screen Reading image /Applications/Games/FlightGear191/FlightGear.app/ Contents/Resources/data/Aircraft/SenecaII/splash.rgb Intel GMA 950 OpenGL Engine Max texture size = 2048 Depth buffer bits = 24 Splash screen progress reading aircraft list Splash screen progress reading airport navigation data Loading Airport Database ... #1 './._apt.dat' #2 '' #3 '13799 0 1 E46 02 Ranch' Next airport = E46 3799 [snip] #367972 '1 1 0 0 EHYB [X] Ypenburg The Hague' Next airport = EHYB 1 Adding NV26 pos = -115.069, 36.0791 elev = 1913 #367973 '10 52.053471 004.341159 22x 222.00 7020 . . 148 343243 2 0 2 0.25 0 0300.0300' #367974 '10 52.053955 004.339983 xxx 100.00 800 0.0 0.0 110 161161 1 0 0 0.25 0 ' #367975 '10 52.046864 004.329772 xxx 132.00 702 0.0 0.0 176 161161 1 0 0 0.25 0 ' #367976 '10 52.060818 004.350292 xxx 132.00 702 0.0 0.0 180 161161 1 0 0 0.25 0 ' #367977 '10 52.054977 004.338323 xxx 42.00 1000 0.0 0.0 400 11 1 0 0 0.25 0 ' #367978 '10 52.053928 004.339871 xxx 42.00 6690 0.0 0.0 130 11 1 0 0 0.25 0 ' #367979 '10 52.054462 004.338961 xxx 222.00 7000 0.0 0.0 125 161161 1 0 0 0.25 0 ' #367980 '10 52.053768 004.339871 xxx 356.00 880 0.0 0.0 110 161161 1 0 0 0.25 0 ' #367981 '99' End of file reached #367982 '' #367983 '' #367984 '' #367985 '' and thus it continues indefinitely. The text it is reading from the file is correct, so it seems to be some subtle character set encoding thing, perhaps? Thanks Andrew -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Win32-built -Towards the new Release
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 gracefully, i.e., if the kill signal is not catched then the subversion command in progress will lock the WC of tbe repository. In such cases the affected repository will be locked when terrasync is run later. Terrasync will report this to stdout (or stderr) and a 'svn cleanup' must be issued in the affected WC of the repository. I haven't looked into the code but the kill signal should be catched and proper svn action should be taken to avoid locks. Cheers, Jari -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glide slope (ILS) range
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 degrees from the runway extended centre line in the horizontal plane. The vertical lower limit is 0.45 times the nominal glide path angle and the upper is 1.75 the nominal glide path angle. The localizer is required to work up to 25 NM within +-10 degress, and up to 17 NM within +-35 degrees (angles in the horizontal plane against runway extended centre line). In vertically the signal should cover up to 7 degrees inclination within the stated distances. The lower bound in the vertical is harder to explain without a figure to support the text. Furthermore, the literature states to never trust signals outside the above limits. I agree with John that some randomness at the limits would be nice. Cheers, Jari On 2009-12-17 21.19, John Denker wrote: On 12/17/2009 11:44 AM, Curtis Olson wrote: I had a squawk here from a (real) King Air pilot because on an ILS approach, our glideslope indicator doesn't become active/in-range until about 7-8 miles out. Beyond this range the indicator just stays centered at zero. With a standard 3 degree glide slope, 7 miles out equates to about 2000' AGL, outside of this range the FlightGear glideslope does nothing. Tell him we need a more detailed bug report: -- what airport, what approach procedure -- what simulated aircraft -- what version of FG The GS and LOC code was broken for years, but I think it got fixed recently. I see our database lists the GS ranges at 10nm usually. As it should. However, our code seems to be clamping the range to something significantly less than that. I've been poking around in navdb.cxx and navradio.cxx but haven't been able to connect all the dots yet. The GS range calculation looks OK to me. It's only a couple of lines. I don't have personal knowledge of what is correct, but this change to glideslope range impacts our ability to practice ILS approaches and I have a current King Air pilot complaining about the behavior. Pulling out some old approach plates for KMSP here I see a 14nm distance and 5000' MSL entry altitude (4000'+ AGL) referenced in the approach to 30R. That's not a correct interpretation of the chart. The _localizer_ can be intercepted 18.5 nm from the _localizer_ antenna, but that's got little to do with the glideslope. The pilot needs to see the glideslope alive at least a little bit before JACKO intersection, which is 6.7nm from the DME station and therefore something like 5.7nm from the GS transmitter. So there should be miles and miles of margin, even if the GS range is only 10nm. To be clear: Standard procedure is to intercept the localizer and fly inbound for a few miles without reference to the glideslope until the glideslope starts working. The approach plate has series of altitudes to use during this phase of the approach. THere are some approaches that require an ESV (expanded service volume) on the GS but there is no evidence that KMSP ILS RWY 30R is one of them. It does look like the localizer needs a slightly expanded service volume, but that's a separate issue. Is 7-8 miles a realistic range for the glide slope? No. The GS should be working at 10+ DME on this approach. Is my King Air pilot contact smoking something? The 10nm service volume is an FAA-guaranteed minimum. Due to the nature of the beast, in practice the signal is usually usable much farther out than that ... depending on what model of receiver you are using, how clean your antenna is, et cetera. Having the GS suddenly spring to life at exactly 10nm from the antenna is not realistic ... but it is not tragic. You could argue that it represents worst-case behavior, which has some advantages during training. But it ought to have at least some randomness to it, so that wise-guy pilots don't treat it as a virtual DME indication. Still, this is pretty low down on the priority list. There are dozens and dozens of more serious issues to worry about. == Having the GS needle park at zero when the signal is out of range is not realistic for the type of equipment normally found in King Airs ... although it would be typical in older and less fancy equipment. This is fixable in the xml, but it is a lot easier with a little help from navradio.cxx. I submitted a patch to implement proper parking over a year ago. It was discarded without explanation. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and
Re: [Flightgear-devel] fgfs compile error, today's cvs
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. It may be even worse than that. I had to rm tests/.deps/* before doing ./autogen.sh configure --whatever On 12/10/2009 02:04 AM, Erik Hofman wrote: Indeed.that's a pity. Yes. And I think it is possible to avoid the problem with autotools. I'll have a look. = Suggestion: Perhaps make clean should clear out all the .deps directories. No, it should not. Try 'make distclean' before updating configure.ac or Makefile.am files. This will remove most of the generated files based on the current autotools setup. Then update, autogen, configure, make. Performing 'make distclean' after update will usually leave stray obsolete files. It would also be nice if the automake system handled 64-bit libraries properly. http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit I really like your bug tracker. Jari -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs compile error, today's cvs
After consulting our local autotools Guru and the web our conclusion is that the cost effective way is to remove the dependency file, rerun configure and then make. In this case this means rm test/.deps/est-epsilon.Po ./configure make This will work for est-epsilon since the .Po is regenerated. However there were more filenames changed so rm -rf tests/.deps/ ./configure make is required and new dependency files are regenerated for files in tests. The above will minimize compile time. 'make distclean' or a new checkout of the source will trigger a complete recompilation of the source. 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 the dependency tracking of automake. It may be even worse than that. I had to rm tests/.deps/* before doing ./autogen.sh configure --whatever On 12/10/2009 02:04 AM, Erik Hofman wrote: Indeed.that's a pity. Yes. And I think it is possible to avoid the problem with autotools. I'll have a look. = Suggestion: Perhaps make clean should clear out all the .deps directories. No, it should not. Try 'make distclean' before updating configure.ac or Makefile.am files. This will remove most of the generated files based on the current autotools setup. Then update, autogen, configure, make. Performing 'make distclean' after update will usually leave stray obsolete files. It would also be nice if the automake system handled 64-bit libraries properly. http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit I really like your bug tracker. Jari -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] releases +- bugs
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 things, which was improved. But as I use win32, it might be that some things aren't working on your system but on others, so should name your system specs (GPU, OS etc...) as well. HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL / ALUT problem on Mac (was PATCH Suggested configure.ac changes/improvements affecting mac users)
Hi Tat, I have a working dev setup which I rebuild automatically more often I'd should thanks to your scripts and others input. Once everything compiles and the scripts are tuned the effort to update to latest repository versions of all packages is minimal. Patience is required though since the compile time can be very long. I just saw an opportunity to decrease the compile time dependencies. For me personally there is no need to provide prebuilt partial packages but thanks anyway. I'll start to compile the OSXLauncher soon so maybe there'll be a new thread opening soon ;-) Cheers, Jari Tatsuhiro Nishioka wrote: Hi Jari, I really appreciate your passion, time and effort on this. However, embedding a part of alut.h code to SimGear is not a good idea even if it is a very limited lines of code, and this is why I haven't added my alut.h patch to SG/cvs. The reason is very easy. Adding something that doesn't belong to your project may increase the maintenance cost in the near future (when ALUT changes, you may need to change your code as well). Moreover, your fix won't allow other developers/users to use free-alut with SG/Mac. That's not a good idea, and the same to my alut patch. For developer-friendliness, we can add --with-openal-framework= option for letting you specify the path to your own OpenAL.framework. You can add one (or more) of alut.h, free-alut, and a fix for OpenAL (like http://playcontrol.net/ewing/jibberjabber/defective_core_audio_mac_os.html as James posted). This way we don't have to mess with the sysmtem-default framework and the users can build FG with or without free-alut by using their own OpenAL.framework. I can also provide a prebuilt OpenAL.framework for saving your time. With combination of configure option, prebuilt OpenAL.framework, and my helper build script, users can built FG right out of the box. Of course you need to either add the framework to FlightGear.app/Contents/Frameworks or specify DYLD_FRAMEWORK_PATH, but it won't be a big problem, I believe. Tat p.s. I'm open 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 done so but this is my last try to persuade a change in alut usage. As Tat outlines below there are several ways to deal with alut on mac and I use a fourth variant myself. The reason to keep bugging you on this issue is that there are many patches required to compile fg on mac. I would like to see a flighgear et al. code base that actually compiles everywhere without requiring patches. In this case it is possible to make the build path simpler on mac, removing Tats patching or the need to compile freealut. Ideally for macs, alut should be removed altogether but that is probably not an viable option. The second best option would be to include alut function declarations for the 5 backward compatibility function in the Apple OpenAL framework in soundmgr_openal.hxx (or cxx if they does not need to be exposed, alut is only used in soundmgr_openal.cxx, I think ... I still have a lot of fg code to read). Is there planned increased use of alut functionality? If not, then the choice is a no-brainer. A third option is to use freealut as Eric does and I did until recently. A forth is to use Tats strategy with adding alut.h from Creatives OpenAL framework. Which one of the four above to use depends on the implementers but when you decide please take into account that every step of user (and developer) friendliness is a good thing. And believe me, fg needs developer friendliness. Some background: I work on macs with 64-bit SnowLeopard (10.6.2) and I do not cross compile (i.e., I do not create universal binaries) and use terminal tools in the compilation process (no xcode). The discussion in this thread has been confusing since the code itself is slightly confusing, at least for an outsider, and the preprocessor makes different code selections depending on which alut.h is used. In simgear/simgear/sound/soundmgr_openal.cxx there are several #if statements. Naively one would think that compiling on macs the code path is to go through section inside #if defined( __APPLE__ ) conditionals. However, what happens depends on which alut.h is used by the preprocessor because of conditionals like #if defined(ALUT_API_MAJOR_VERSION) ALUT_API_MAJOR_VERSION = 1 and consequently the requirements on the underlying alut library changes. 1) Adopting my strategy to not include any alut.h at all and simply adding a declaration for alutLoadWAVFile will make the preprocessor to select the code inside the __APPLE__ conditionals. 2) Adopting Tats strategy to use Creatives alut.h will also make the preprocessor to use code
[Flightgear-devel] Can someone please add missing terrasync scenery to the repository
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 -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fg shows a blank screen
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/projects/osg/changeset/10838/OpenSceneGraph/trunk Good job pinpointing the trouble! Since that commit introduces a change in default behaviour, I suppose restoring the previous behaviour by explicitly specifying the mask should fix it. This works for me: http://gitorious.org/fg/jesters-clone/commit/e80075464dc67e868cfc42d209a4ca7c7be234f1 But we shall wait until one of our OSG experts takes a look. We might also want to make it conditional on the OSG version (always fun, that) because this enum value hasn't existed before. I committed your patch with an autoconf test. Any Windows friends using OSG from svn will need to #define HAVE_CULLSETTINGS_CLEAR_MASK. Tim -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
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 done so but this is my last try to persuade a change in alut usage. As Tat outlines below there are several ways to deal with alut on mac and I use a fourth variant myself. The reason to keep bugging you on this issue is that there are many patches required to compile fg on mac. I would like to see a flighgear et al. code base that actually compiles everywhere without requiring patches. In this case it is possible to make the build path simpler on mac, removing Tats patching or the need to compile freealut. Ideally for macs, alut should be removed altogether but that is probably not an viable option. The second best option would be to include alut function declarations for the 5 backward compatibility function in the Apple OpenAL framework in soundmgr_openal.hxx (or cxx if they does not need to be exposed, alut is only used in soundmgr_openal.cxx, I think ... I still have a lot of fg code to read). Is there planned increased use of alut functionality? If not, then the choice is a no-brainer. A third option is to use freealut as Eric does and I did until recently. A forth is to use Tats strategy with adding alut.h from Creatives OpenAL framework. Which one of the four above to use depends on the implementers but when you decide please take into account that every step of user (and developer) friendliness is a good thing. And believe me, fg needs developer friendliness. Some background: I work on macs with 64-bit SnowLeopard (10.6.2) and I do not cross compile (i.e., I do not create universal binaries) and use terminal tools in the compilation process (no xcode). The discussion in this thread has been confusing since the code itself is slightly confusing, at least for an outsider, and the preprocessor makes different code selections depending on which alut.h is used. In simgear/simgear/sound/soundmgr_openal.cxx there are several #if statements. Naively one would think that compiling on macs the code path is to go through section inside #if defined( __APPLE__ ) conditionals. However, what happens depends on which alut.h is used by the preprocessor because of conditionals like #if defined(ALUT_API_MAJOR_VERSION) ALUT_API_MAJOR_VERSION = 1 and consequently the requirements on the underlying alut library changes. 1) Adopting my strategy to not include any alut.h at all and simply adding a declaration for alutLoadWAVFile will make the preprocessor to select the code inside the __APPLE__ conditionals. 2) Adopting Tats strategy to use Creatives alut.h will also make the preprocessor to use code inside __APPLE__ conditionals. I have not tried it myself but I have deduced it from Tats postings. 3) Use freeglut libraries and headers. This will actually make use of alut functionality not included in the Apple OpenAL framework (remember there is only 5 of them left) because of #if defined(ALUT_API_MAJOR_VERSION) ALUT_API_MAJOR_VERSION = 1 conditionals. The preprocessor will include code inside this type of conditionals, and actually ignore one __APPLE__ conditional. (Interestingly the code ignored is the only Apple compatibility alut function, alutLoadWAVFile, call in simgear ... is it coincidence or made on purpose?) However, this is all valid since freeglut of course provides the required underlying functionality. My experience is that this works perfectly without any need to change API names as claimed by Tat. One further confusion is that the alut.h is unnecessarily included in soundmgr_openal.hxx and alut becomes exposed to code that includes soundmgr_openal.hxx, i.e., fg source. To compile fg/source you need to have alut.h as the code is today. If nothing else, please remove the include in soundmgr_openal.hxx, the file itself does not use anything from alut.h. All alut.h usages is in the cxx-file. One of my coding rules is to avoid including header files not needed. I post this with good intent, Cheers Jari On 2009-11-29 19.35, Tatsuhiro Nishioka wrote: On Nov 29, 2009, at 8:12 AM, Jari 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 is another option). I used freealuts alut.h which made the compiler to choose an unexpected path (for macs) in the source during compilation. The path chosen by the compiler required more alut functionality than provided by my mac. However, using freealut libs and alut.h, and Apples OpenAL framework works perfectly, I have done that for a while. (Now I changed strategy as outlined in other postings in this thread.) From what I understand Apple is depreciating those old alut functions
[Flightgear-devel] fg shows a blank screen
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 am located at. On the startup terminal I get messages like this one Sat Nov 28 16:27:15 signori.local fgfs[54344] Error: CGBitmapContextCreate: unsupported parameter combination: 8 integer bits/component; 16 bits/pixel; 1-component color space; kCGImageAlphaLast; 512 bytes/row. Sat Nov 28 16:27:15 signori.local fgfs[54344] Error: CGContextDrawImage: invalid context 0x0 It worked for me a few day ago. I am compiling/running on a 64-bit mac 10.6.2. I'll try to find the problem but I am hoping for a pointer where to begin (excluding the option to roll back to a previous CVS state). Maybe someone has a hunch of a recent change that may have caused my blank screen. Cheers, Jari -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
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
configure.ac files.
I have added a check for the OpenAL framework in my fg configure.ac, in
your diff you simply assume that OpenAL is available. It may be true but
better safe than sorry. (See fg-check4OpenAL-confgure.diff for details.)
I added a same check to sg configure.ac (sg-check4OpenAL-configure.diff)
Your strategy with adding alut.h to your mac and use your patch to the
sg/fg configure.ac files works well. I would like you to consider the
below replacement strategy
# This assumes you have alut.h (that comes with Creative's
OpenAL.framework) in
/Developer/SDKs/MacOSX10.6/System/Library/OpenAL.framework/Headers
As I wrote in my previous posting I removed all dependency on alut.h.
This was trivial and required only changes in a few files in directory
simgear/simgear/sound. My understanding of the code is that the only
alut function used in simgear for mac is alutLoadWAVFile. If the changes
proposed in my previous post in this thread are made to simgear CVS
there is no need to add alut.h (and my sg configure.ac diff provided
here can be used with the trivial change outlined in the diff).
My proposed changes could be augmented with declarations of all five
alut functions in the OpenAL framework supplied by Apple. Use of any
other alut functionality will break simgear on default mac OpenAL
installation anyway. (It is possible to install freealut 1.1 and get
support for more alut functionality).
My point is, we can add some declarations to
simgear/simgear/sound/soundmgr_openal.hxx (or cxx) and get rid of
alut.h. This is how I do it and it works.
Cheers,
Jari
Index: configure.ac
===
RCS file: /var/cvs/SimGear-0.3/source/configure.ac,v
retrieving revision 1.118
diff -u -p -r1.118 configure.ac
--- configure.ac22 Nov 2009 22:23:01 - 1.118
+++ configure.ac28 Nov 2009 20:34:19 -
@@ -303,12 +303,6 @@ case ${host} in
*-apple-darwin*)
dnl Mac OS X
-LIBS=$LIBS -framework IOKit -framework OpenAL
-openal_LIBS=$LIBS
-# not sure how to test if OpenAL exists on MacOS (does it come by default?)
-OPENAL_OK=yes
-ALUT_OK=yes
-
dnl Thank you Christian Bauer from SheepSaver
dnl Modified by Tatsuhiro Nishioka for accepting a given framework path
dnl AC_CHECK_FRAMEWORK($1=NAME, $2=INCLUDES, $3=FRAMEWORK_PATH) ; $3 is
optional
@@ -338,6 +332,32 @@ case ${host} in
AS_VAR_POPDEF([ac_Framework])dnl
])
+LIBS=$LIBS -framework IOKit -framework OpenAL
+openal_LIBS=$LIBS
+
+if test x$with_openal_lib != x; then
+echo libopenal is not supported on Mac OS platform.
+openal_LIBS=
+else
+dnl Check that OpenAL framework can be found
+save_CPPFLAGS=$CPPFLAGS
+CPPFLAGS=
+AC_CHECK_FRAMEWORK(OpenAL,[#include OpenAL/al.h])
+if test x$ac_cv_framework_OpenAL = xyes ; then
+openal_LIBS=$FRAMEWORKS
+OPENAL_OK=yes
+# alut backward compatibility libs are provided by Apple
+# OpenAL (at least for OSX 10.5 and 10.6), no alut.h file
+# is provided. Just un-comment below line, and remove the
+# check in alut.h header.
+# ALUT_OK=yes
+dnl Looking for alut.h, if found assume that it is a part
+dnl of the OpenAL package.
+AC_CHECK_HEADERS([OpenAL/alut.h],[ALUT_OK=yes])
+fi
+CPPFLAGS=$save_CPPFLAGS
+fi
+
;;
*)
Index: configure.ac
===
RCS file: /var/cvs/FlightGear-0.9/source/configure.ac,v
retrieving revision 1.156
diff -u -p -r1.156 configure.ac
--- configure.ac22 Nov 2009 22:23:40 - 1.156
+++ configure.ac28 Nov 2009 20:28:04 -
@@ -399,11 +410,22 @@ case ${host} in
*-apple-darwin*)
dnl Mac OS X
-LIBS=$LIBS -framework IOKit -framework OpenAL
-openal_LIBS=$LIBS
-# not sure how to test if OpenAL exists on MacOS (does it come by default?)
-OPENAL_OK=yes
-ALUT_OK=yes
+if test x$with_openal_lib != x; then
+# Check for openal libs with AC_CHECK_LIB() missing here!
+openal_LIBS=
+else
+# Check that OpenAL framework can be found
+save_CPPFLAGS=$CPPFLAGS
+CPPFLAGS=
+AC_CHECK_FRAMEWORK(OpenAL,[#include OpenAL/al.h])
+if test x$ac_cv_framework_OpenAL = xyes ; then
+openal_LIBS=$FRAMEWORKS
+OPENAL_OK=yes
+ALUT_OK=yes
+fi
+CPPFLAGS=$save_CPPFLAGS
+fi
+
;;
*)
--
Let Crystal
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
Hi again, Tanks for the pointers. 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 option). I used freealuts alut.h which made the compiler to choose an unexpected path (for macs) in the source during compilation. The path chosen by the compiler required more alut functionality than provided by my mac. However, using freealut libs and alut.h, and Apples OpenAL framework works perfectly, I have done 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 with a zero length alut.h and no libalut. Compiling works but the linker fails with alut-complaints Undefined symbols: _alutInitWithoutContext, referenced from: SGSoundMgr::SGSoundMgr()in libsgsound.a(soundmgr_openal.o) I guess you're using SG from Tim's git repository (or similar). To get simgear I of course had to provide an alut.h but the one I have is from freealut-1.1 which gives me unwanted consequences. I am not sure about the #if statements on ALUT_API_MAJOR_VERSION in simgear/soundmgr_openal.cxx but I think that the compiler should not compile code calling alutInitWithoutContext on Apple computers. With my below suggested changes this issue will go away. Using alut.h from freealut-1.1 with Apple's OpenAL.framework (0.0.8) is a big problem. You need to use alut.h that comes with OpenAL.framework in Creative's OpenAL installer. SimGear's sound_manager.cxx uses free-alut's ALUT functions only if ALUT_API_MAJOR_VERSION is defined (free-alut's alut.h defines it, but (older) alut.h in OpenAL.framework doesn't), so using alut.h that comes with Creative's OpenAL.framework gets rid of your linker error. As a matter of fact, I have no linker errors in compiling SG @ Tim's git with alut.h that comes with Creative's OpenAL installer. and more. Listing alut-related functions in the OpenAL framwork only gives a short list of alut related functions: # nm openAL | grep alut 00013133 T _alutExit 00013168 T _alutInit 00013a2e T _alutLoadWAVFile 000136f8 T _alutLoadWAVMemory 0001311e T _alutUnloadWAV I have freealut installed to resolve the above linker problem Browsing through simgear/soundmgr_openal.cxx it looks like the calls to non-supported alut functions can be avoided. I look into that. I removed all dependencies on alut.h which all seems to be in simgear/sound only. I simply removed a few include statements and added one function declaration (see attached patch file). All of the fg components now compiles without any alut/freealut added (except for the backward compatibility stuff in OpenAL framework supplied by Apple). Isn't there non-alut replacement for alutLoadWAVFile? If there is then alut could be removed completely. I have not yet had the possiblity to extensively test the changes suggested in the patch but during a short flight the changes seems to work. If the proposed changes is pushed to the official simgear CVS then the configure scripting will be easier for simgear and fg/source wrt alut (at least for mac developers). Using the alut.h in Creative's OpenAL.framework will get the job done, so you don't have to do this yourself. If you want to use more embedded way rather than adding alut.h to Mac's Developer SDK, then you can locally add alut.h to simgear/sound folder. I used this way to avoid changing headers on every OS update. You can also use the following patches for this purpose. http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk/patches/SimGear-0.3-cvs-20061203-MacOSX.diff?revision=170view=markup http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk/patches/alc.patch?revision=217view=markup First one is a patch for local alut.h inside SimGear and the second one is a patch to alc.h for compiling with gcc 4.2.x (optional) Maybe you want to change the folder name from MacOSX10.5.sdk to MacOSX10.6.sdk in the second patch. Best, Tat -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
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 option). I used freealuts alut.h which made the compiler to choose an unexpected path (for macs) in the source during compilation. The path chosen by the compiler required more alut functionality than provided by my mac. However, using freealut libs and alut.h, and Apples OpenAL framework works perfectly, I have done that for a while. (Now I changed strategy as outlined in other postings in this thread.) From what I understand Apple is depreciating those old alut functions (but still keeps hem in the library for backwards compatibility) and is encouraging everyone to use the freealut package instead. And so do I. Erik Yes, you are right. Jari -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fg shows a blank screen
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 the top menu and I have sound. I get the message saying which runway I am located at. same here with the last OSG svn, menu and hud is working and the plane too, but i only have black to blue screen, taking an old OSG solved the problem for me (i used the 10820 revision). 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/projects/osg/changeset/10838/OpenSceneGraph/trunk Is this a mac specific problem or does it occur in other OSs too? Jari -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
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:
_alutInitWithoutContext, referenced from:
SGSoundMgr::SGSoundMgr()in libsgsound.a(soundmgr_openal.o)
To get simgear I of course had to provide an alut.h but the one I have
is from freealut-1.1 which gives me unwanted consequences. I am not sure
about the #if statements on ALUT_API_MAJOR_VERSION in
simgear/soundmgr_openal.cxx but I think that the compiler should not
compile code calling alutInitWithoutContext on Apple computers. With my
below suggested changes this issue will go away.
and more. Listing alut-related functions in the OpenAL framwork only
gives a short list of alut related functions:
# nm openAL | grep alut
00013133 T _alutExit
00013168 T _alutInit
00013a2e T _alutLoadWAVFile
000136f8 T _alutLoadWAVMemory
0001311e T _alutUnloadWAV
I have freealut installed to resolve the above linker problem
Browsing through simgear/soundmgr_openal.cxx it looks like the calls to
non-supported alut functions can be avoided. I look into that.
I removed all dependencies on alut.h which all seems to be in
simgear/sound only. I simply removed a few include statements and added
one function declaration (see attached patch file). All of the fg
components now compiles without any alut/freealut added (except for the
backward compatibility stuff in OpenAL framework supplied by Apple).
Isn't there non-alut replacement for alutLoadWAVFile? If there is then
alut could be removed completely.
I have not yet had the possiblity to extensively test the changes
suggested in the patch but during a short flight the changes seems to work.
If the proposed changes is pushed to the official simgear CVS then the
configure scripting will be easier for simgear and fg/source wrt alut
(at least for mac developers).
Cheers,
Jari
? simgear_sound4mac.patch
Index: simgear/sound/openal_test1.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/openal_test1.cxx,v
retrieving revision 1.13
diff -u -p -r1.13 openal_test1.cxx
--- simgear/sound/openal_test1.cxx 22 Oct 2009 08:32:04 - 1.13
+++ simgear/sound/openal_test1.cxx 27 Nov 2009 11:04:22 -
@@ -13,7 +13,6 @@ static unsigned int sleep(unsigned int s
# define AL_ILLEGAL_COMMAND AL_INVALID_OPERATION
# include OpenAL/al.h
# include OpenAL/alc.h
-# include OpenAL/alut.h
#elif defined(OPENALSDK)
# include al.h
# include alc.h
Index: simgear/sound/soundmgr_openal.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/soundmgr_openal.cxx,v
retrieving revision 1.74
diff -u -p -r1.74 soundmgr_openal.cxx
--- simgear/sound/soundmgr_openal.cxx 26 Nov 2009 13:05:44 - 1.74
+++ simgear/sound/soundmgr_openal.cxx 27 Nov 2009 11:04:22 -
@@ -30,7 +30,25 @@
#endif
#if defined( __APPLE__ )
-# include OpenAL/alut.h
+# include OpenAL/al.h
+# include OpenAL/alc.h
+
+// Definitions taken from alut.h (from #if defined (__APPLE__)
+// clauses) with the aim to become independent of alut.h since alut is
+// not available in a standard OpenAL installation on mac (since xcode
+// 2.4). Five alut functions are still included in the OpenAL
+// framework libraries but they are not declared in any header file
+// (at least in OSX 10.6.2): alutExit, alutInit, alutLoadWAVFile,
+// alutLoadWAVMemory, and alutUnloadWAV
+extern C {
+
+#define ALUT_API extern
+#define ALUT_APIENTRY
+#define ALUT_ATTRIBUTE_DEPRECATED __attribute__((deprecated))
+
+ALUT_API ALUT_ATTRIBUTE_DEPRECATED void ALUT_APIENTRY alutLoadWAVFile (ALbyte
*fileName, ALenum *format, void **data, ALsizei *size, ALsizei *frequency);
+}
+
#else
# include AL/alut.h
#endif
Index: simgear/sound/soundmgr_openal.hxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/soundmgr_openal.hxx,v
retrieving revision 1.35
diff -u -p -r1.35 soundmgr_openal.hxx
--- simgear/sound/soundmgr_openal.hxx 23 Nov 2009 10:32:28 - 1.35
+++ simgear/sound/soundmgr_openal.hxx 27 Nov 2009 11:04:22 -
@@ -48,7 +48,6 @@
# define AL_ILLEGAL_COMMAND AL_INVALID_OPERATION
# include OpenAL/al.h
# include OpenAL/alc.h
-# include OpenAL/alut.h
#elif defined(OPENALSDK)
# include al.h
# include alc.h
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Flightgear
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
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 official CVS/git/... It all seems good to me but I need to work a bit more on OpenAL and svn lib thingies. Mac OS X, by default, has OpenAL.framework with ALUT implementation. Only the problem is that it lacks alut.h in its Headers folder. So what we need to check is the existance of alut.h in SimGear's configure FlightGear's configure doesn't need to check the existance of alut.h since it doens't include the header. 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: _alutInitWithoutContext, referenced from: SGSoundMgr::SGSoundMgr()in libsgsound.a(soundmgr_openal.o) and more. Listing alut-related functions in the OpenAL framwork only gives a short list of alut related functions: # nm openAL | grep alut 00013133 T _alutExit 00013168 T _alutInit 00013a2e T _alutLoadWAVFile 000136f8 T _alutLoadWAVMemory 0001311e T _alutUnloadWAV I have freealut installed to resolve the above linker problem Browsing through simgear/soundmgr_openal.cxx it looks like the calls to non-supported alut functions can be avoided. I look into that. 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 the non-required alut.h? The workaround now is to simply add a zero length file (OpenAL/alut.h) somewhere in the pre-processors include search path. svn library checks look good to me, but we probably should let the users specify the location of the libs. This is mainly because svn libs on 10.5.x is older and users usually install the newer ones to /usr/local or some other folder. LDFLAGS=-L/some/path/to/svn-libs configure works in such case, but configure --with-svn-libs=/some/path/to/svnlibs could be better. I agree, --with-svn-libs is the preferred route. The changes suggested by me was the minimalistic changes to configure.ac that would actually compile the svn API dependent code. There should also be a --with-apr option. Cheers, Jari -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
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 the non-required alut.h? The workaround now is to simply add a zero length file (OpenAL/alut.h) somewhere in the pre-processors include search path. Of course, simgear needs alut.h so the above statemens are plain wrong. Maybe the simgear package can provide declarations for the alut functionality it uses (at least for macusers)? Still on OSX10.6, currently the simplest workaround is to install freealut from http://connect.creativelabs.com/openal/Downloads/Forms/AllItems.aspx Jari -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] atlas global tarball
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 scenery data first. On Sun, Nov 22, 2009 at 3:53 AM, Victhor Foster victhor.fos...@gmail.com wrote: Is your computer too slow to generate them? There's an option in Map that speeds up the process, I think it's --headless-mode. Does someone happen to have a tarball with all the atlas generated map images handy? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] boost library version
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 and Fedora as my linux flavour so cannot give details on upgrading boost on Ubuntu. The Net is your friend. Jari Diego Fernando Rodríguez Varón wrote: Hello everyone. I was experiencing the segmentation fault reported by Nicolas before so I just tried updating and compiling. But I get the following error: checking for boostlib = 1.37.0... configure: error: We could not detect the boost libraries (version 1.37 or higher). If you have a staged boost library (still not installed) please specify $BOOST_ROOT in your environment and do not give a PATH to --with-boost option. If you are sure you have boost installed, then check your version number looking in boost/version.hpp. See http://randspringer.de/boost for more documentation. I'm using Ubuntu 8.04 and the boostlib supported is 1.34. So I had change the configure.ac file AX_BOOST_BASE([1.34.0] Is flightgear stopping support for Hardy Heron? :( Hopefully not. Do I really need 1.37? Thanks for your help. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] heads up -- effects for models
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. Animations, particularly material animations, may very likely be messed up; please report any breakage. This requires updating flightgear, simgear, and data. Also, version 1.37 of Boost is now required. Sounds good to me. I'll start to do battle with MSVC9 today. But why Boost 1.37 when 1.40 is available? Isn't the requirement really boost = 1.37, i.e., it will work with boost version 1.x where x is larger or equal to 37. I assume that the boost team does not break boost API going from 37 to 38 and so on. So, the requirement 1.37 is better than 1.40 since users using boost 1.37-1.39 can skip the boost upgrade for now. Cheers, Jari - using boost 1.40 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] flightgear dependency on PLIB pw API
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 Carbon is not available as a 64-bit library, and PLIB only supports Carbon for Mac OS X. I am using the 64-bit enabled Cocoa which, luckily for me, is supported by OSG. I suggest that layout_test is rewritten and the PLIB pw dependency is removed, and thus making the statement regarding PLIB in http://wiki.flightgear.org/index.php/Plib correct. Another option is to change the wiki page. Also, I think that test programs should in general be created by issuing 'make check'. I have attached a trivial patch that moves compilation of layout_test as a part of 'make check' instead of a simple 'make'. It does not resolve the issue with PLIB pw dependence but allows mac 64-bit users to compile the essential components of the flightgear source. Can someone please commit the patch to the CVS? Cheers, Jari Index: src/GUI/Makefile.am === RCS file: /var/cvs/FlightGear-0.9/source/src/GUI/Makefile.am,v retrieving revision 1.23 diff -u -p -r1.23 Makefile.am --- src/GUI/Makefile.am 16 Sep 2009 17:07:59 - 1.23 +++ src/GUI/Makefile.am 31 Oct 2009 19:00:48 - @@ -1,5 +1,5 @@ noinst_LIBRARIES = libGUI.a -noinst_PROGRAMS = layout-test +check_PROGRAMS = layout-test if HAVE_FRAMEWORK_PLIB layout_test_PLIB_FW = $(plib_FRAMEWORK) -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
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 for that openal framework can be located in the default
framework path. Test for non-standard path is not implemented.
3) Added check if alut is a part of the OpenAL framework, if not the a
AC_SEARCH_LIBS os performed to search for freealut. Snow Leopard
does not provide alut as a part of the OpenAL framework.
4) I added --with-cocoa-framework option. This enables the user to
switch from the default Carbon framework to Cocoa.
Comments:
Change 1) is an error in configure.ac and should be fixed even if the
rest of my changes are rejected.
Change 2) and 3) may break things for other mac users since there was
no checks before, configure simply set some variables without testing.
Change 4) is needed to compile 64-bit binaries on mac but the change
will not affect Carbon users. Carbon is 32-bit only whereas Cocoa
comes also in 64-bit flavour. (OSG works with Cocoa but OSG quicktime
support must be dropped and the ImageIO plug-in must probably be used
in OSG).
Can some other mac users try my changes and report back? If the
changes work on other machines than mine then can convince someone to
commit the changes to CVS.
Cheers,
Jari
Index: configure.ac
===
RCS file: /var/cvs/FlightGear-0.9/source/configure.ac,v
retrieving revision 1.154
diff -u -p -r1.154 configure.ac
--- configure.ac17 Sep 2009 07:39:04 - 1.154
+++ configure.ac31 Oct 2009 21:55:35 -
@@ -85,16 +85,27 @@ case ${host} in
])
# Mac OS X specific configure options
-AC_ARG_WITH(osg_framework, [ --with-osg-framework=PREFIX Specify
the prefix path to osg frameworks [default=standard framework paths]])
-if test x$with_plib_framework != x ; then
-echo plib prefix is $with_plib_framework
+# OpenAL framework is used by default, no openal_framework implemented.
+
+AC_ARG_WITH(cocoa_framework, [ --with-cocoa-framework Use the Cocoa
rather than Carbon]])
+if test x$with_cocoa_framework != x ; then
+macAPI=Cocoa
+AC_MSG_NOTICE([Using Cocoa framework])
+else
+macAPI=Carbon
+AC_MSG_NOTICE([Using Carbon framework])
fi
-AC_ARG_WITH(plib_framework, [ --with-plib-framework=PREFIX Specify
the prefix path to PLIB framework [default=standard framework paths]])
+AC_ARG_WITH(osg_framework, [ --with-osg-framework=PREFIX Specify
the prefix path to osg frameworks [default=standard framework paths]])
if test x$with_osg_framework != x ; then
echo osg prefix is $with_osg_framework
fi
+
+AC_ARG_WITH(plib_framework, [ --with-plib-framework=PREFIX Specify
the prefix path to PLIB framework [default=standard framework paths]])
+if test x$with_plib_framework != x ; then
+echo plib prefix is $with_plib_framework
+fi
;;
esac
@@ -335,7 +346,7 @@ case ${host} in
*-apple-darwin*)
dnl Mac OS X
-LIBS=$LIBS -framework GLUT -framework OpenGL -framework AGL -framework
Carbon -lobjc
+LIBS=$LIBS -framework GLUT -framework OpenGL -framework AGL -framework
$macAPI -lobjc
joystick_LIBS=$joystick_LIBS -framework IOKit -framework CoreFoundation
;;
@@ -399,11 +410,27 @@ case ${host} in
*-apple-darwin*)
dnl Mac OS X
-LIBS=$LIBS -framework IOKit -framework OpenAL
-openal_LIBS=$LIBS
-# not sure how to test if OpenAL exists on MacOS (does it come by default?)
-OPENAL_OK=yes
-ALUT_OK=yes
+if test x$with_openal_lib != x; then
+# Check for openal libs with AC_CHECK_LIB() missing here!
+openal_LIBS=
+else
+# Check that OpenAL framework can be found
+AC_CHECK_FRAMEWORK(OpenAL,[#include OpenAL/al.h])
+if test x$ac_cv_framework_OpenAL = xyes ; then
+openal_LIBS=$FRAMEWORKS
+OPENAL_OK=yes
+# Looking for alut.h, if found assume that it is a part of
+# the OpenAL package.
+AC_CHECK_HEADERS([OpenAL/alut.h],[ALUT_OK=yes])
+fi
+fi
+
+# Check if alut was considered to be a part of the OpenAL
+# framework above, if not try to locate a alut library.
+if test x$ALUT_OK = xno ; then
+AC_SEARCH_LIBS(alutInit, alut,
+ [ ALUT_OK=yes openal_LIBS=$openal_LIBS -lalut ])
+fi
;;
*)
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12,
[Flightgear-devel] PATCH: terrasync/subversion checks fixed
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: configure.ac === RCS file: /var/cvs/FlightGear-0.9/source/configure.ac,v retrieving revision 1.154 diff -u -p -r1.154 configure.ac --- configure.ac17 Sep 2009 07:39:04 - 1.154 +++ configure.ac31 Oct 2009 23:00:56 - @@ -707,10 +707,10 @@ fi dnl Check for Subversion library support save_LIBS=$LIBS save_CPPFLAGS=$CPPFLAGS -LIBS= +LIBS=`apr-1-config --link-ld` CPPFLAGS=-I/usr/include/subversion-1 `apr-1-config --includes` AC_CHECK_LIB(svn_client-1, svn_client_checkout3) -AC_CHECK_HEADERS([svn_client.h glut.h]) +AC_CHECK_HEADERS([svn_client.h]) if test x$ac_cv_header_svn_client_h != xyes; then echo TerraSync will shell out for command line subversion svn_LIBS= @@ -718,6 +718,11 @@ if test x$ac_cv_header_svn_client_h != else echo TerraSync will use integrated subversion library AC_SEARCH_LIBS(svn_client_checkout, svn_client-1) + AC_SEARCH_LIBS(svn_delta_version, svn_delta-1) + AC_SEARCH_LIBS(svn_diff_version, svn_diff-1) + AC_SEARCH_LIBS(svn_ra_initialize, svn_ra-1) + AC_SEARCH_LIBS(svn_pool_create_ex, svn_subr-1) + AC_SEARCH_LIBS(svn_wc_version, svn_wc-1) svn_LIBS=$LIBS svn_CPPFLAGS=$CPPFLAGS AC_SUBST(svn_LIBS) -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
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 === RCS file: /var/cvs/SimGear-0.3/source/simgear/sound/Makefile.am,v retrieving revision 1.12 diff -u -p -r1.12 Makefile.am --- simgear/sound/Makefile.am 29 Oct 2009 12:53:20 - 1.12 +++ simgear/sound/Makefile.am 30 Oct 2009 21:22:35 - @@ -22,7 +22,7 @@ check_PROGRAMS = openal_test1 openal_tes openal_test1_SOURCES = openal_test1.cxx openal_test2_SOURCES = openal_test2.cxx -openal_test3SOURCES = openal_test3.cxx +openal_test3_SOURCES = openal_test3.cxx openal_test1_LDADD = \ $(top_builddir)/simgear/debug/libsgdebug.a \ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] PATCH to make simgear CVS compile on Mac OS X 10.6.1 Snow Leopard
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
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/compiler.h,v
retrieving revision 1.31
diff -u -p -r1.31 compiler.h
--- simgear/compiler.h 26 Oct 2009 09:05:19 - 1.31
+++ simgear/compiler.h 30 Oct 2009 22:34:57 -
@@ -138,8 +138,8 @@ inline int (isnan)(double r) { return !(
// any C++ header file undefines isinf and isnan
// so this should be included before iostream
// the functions are STILL in libm (libSystem on mac os x)
-extern C int isnan (double);
-extern C int isinf (double);
+extern C int (isnan)(double);
+extern C int (isinf)(double);
#endif
# else
inline int (isnan)(double r) { return !(r = 0 || r = 0); }
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Question regarding pre-processor code in SIMGEAR/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++ header file undefines isinf and isnan
139// so this should be included before iostream
140// the functions are STILL in libm (libSystem on mac os x)
141 extern C int (isnan)(double);
142 extern C int (isinf)(double);
143 #endif
144 # else
145 inline int (isnan)(double r) { return !(r = 0 || r = 0); }
146 # endif
147 #endif
I am not sure what line 135 is supposed to catch. When I compile with
g++ version 4.2 the statement is false but if I compile with g++ version
4.3 the statement is true. Is the code supposed to catch g++ versions
3.3 and later? If yes, the line 135 should be
#if ( (__GNUC__ = 4 || ( __GNUC__ = 3 ) ( __GNUC_MINOR__ = 3 ) )
If no, then it should be
#if ( __GNUC__ == 3 ) ( __GNUC_MINOR__ = 3 )
Can someone of the simgear developer team review this and commit the
appropriate change to CVS?
Cheers,
Jari
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reversible ILS
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 through 36 inclusive). We choose this end because most users live in the temperate zones where the prevailing westerlies prevail most of the time. (I retract my earlier suggestion about initializing them randomly.) 2) There shall be a menu item, which appears when commanded by the user -- *not spontaneously* -- and can be used to reverse the nearby reversible ILS(s). Perhaps an array of buttons listing the nearest 10 airports with reversible ILSs or some such. And maybe a textbox to allow reversing an arbitrary airport or an arbitrary frequency. This should suffice for single-player FGFS. This would most likely only be used by instrument-rated pilots, or instrument students, so we can assume they have enough sophistication and dedication to deal with such a popup. We need some kind of switching, because the ILS is most needed when the weather is very bad, and that usually means the wind is *not* from the prevailing fair-weather direction. 3) Multiplayer is quite a bit trickier, as previously discussed. This is related to MP ATIS, MP lights, pilot-controlled lights, navaid IDENT, et cetera. This will have to be discussed quite a bit more before anybody starts coding it. For case 2 the appropriate navaids/rwy directions could be set simply by requiring the pilot to call his approach (which, in real life, you have to request if you do not (cannot) accept whatever is suggested from the controller)? I haven't done any instrument approaches in FG but there could be a menu item where one selects an approach from a selectable list of approaches. Of course, this requires that approach related information is available in FG. For multiplayer, could the mp servers simply decide the settings from real weather and all MP players has to accept the settings and make the appropriate approaches? What is the level of realism to expect in multiplayer mode? Is it naive to expect that most users will land/start in the proper direction in multiplayer mode? Cheers, Jari -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] (no subject)
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 and frames and other hardwoods for hull and deck planking. Teak was especially favoured for deck planking once trade had opened up the tropics. A relatively little known fact is that Balsa is actually a hardwood :-) The oak supply was at least enough to supply the Swedish Navy for hundereds of years (though Swedish Pomerainia was also an important source during 1648 - 1815). AFAIK all oaks by law belonged to the crown and could, if not needed for the Navy, be exported to generate cash for the state (something often in short supply). Cheers, Anders Thanks for the intersting info. I guess Sweden's Oaks mainly came from the extreme south? It wouldn't surprise me if Sweden imported quite a bit of Oak. It also doesn't surprise me that all Oaks belonged to the crown. It was almost essential for ship building once the 'big' multi-decked vessels were developed (although some of the 'traditional' long-boats were pretty big too) and a nation's navy was it's primary security force around then; permanent standing national armies didn't come in until quite a lot later. LeeE To add some trivia on Swedish oak; In the 17th century the navy realized that the available oak woods were too small to meet demand. So, one of the kings back then, I forget which one, ordered planting of oak in Skåne (far south in Sweden 56 degrees N). The problem is of course that it takes a few hundred years before the trees get large enough and now the ship building technology has moved on. The upside is that we now have a few nice oak woods in Skåne. Cheers, Jari -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac crashes / corruption with CVS
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 is in macflightgear's svn trunk and 1.9.1 branch. in trunk, it was fixed on rev 213. Looking at the svn diffs I notice that the changes in the 1.9.1 is already in the trunk. Sorry for the misconception earlier. You can get svn/head of macflightgear from: http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk.tar.gz?view=tar The head is for sources as of June 13th. I updated my working copy. Thanks. Jari -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
