Re: [Flightgear-devel] FSWeekend impressions
Hi Torsten, Want pictures? http://www.t3r.de/flightpics/fsweekend2008/ Sending this from work by webmail: let's hope it works: Here's a quote from the X-plane.org forum: At FSWeekend there was a guy from the open-source flight simulator FlightGear too. He had this large FlightGear banner above his table. I looked like he printed it out himself, but it looked cool anyway. :-) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FSWeekend impressions
Am Montag 03 November 2008 schrieb Martin Spott: Somewhen in the past we've been starting the FlightGear Expo Checklist page on the wiki (you won't find the page without using a seach engine) Sometimes a little link might help... ;) http://wiki.flightgear.org/index.php/FlightGear_Expo_Checklist Good Job in Lelystad!!! Thomas - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: use of boost libraries
On lundi 03 novembre 2008, Tim Moore wrote: I've been working on effects support for FlightGear, as part of the work I've been doing on integrating shadows into the OSG version. Roughly speaking an effect is like a material for an object, but it can support different techniques based on OpenGL features and user choices. Each technique is multipass and of course supports shaders. Anyway, in doing this work I've been using the Boost library from boost.org, and I'd like to introduce it as a new dependency in FlightGear. I've used its rich support for working with STL iterators and binding functions for use with STL algorithms. More generally, I like Boost's implementation of the TR1 libraries that are being introduced in the C++0x standardization process (including a standard hash table implementation). Boost contains a ton of well-tested, useful code. I know that Boost is well supported on Linux and see that it is on Windows as well, though I have no direct experience with that. Are there any objections to or comments about adding Boost as a FlightGear dependency? Tim Are we talking about it ? http://www.boost.org/users/license.html Which is not said being GPL Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: use of boost libraries
Instead, some places in FlightGear itself (at least Nasal and JSBSim, as far as I remember) are the factors that limit portability. We have actually gone to some effort to make sure that JSBSim compiles everywhere. Even on my cell phone. ;-) Jon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FSWeekend impressions
setup. We also didn't do that many multiplayer demos this year. This year's booth setup was actually not really ideal for that; one get's the best impression when one can watch the two participating parties at the same time. With some minor rearrangements this should be possible, and I would like to try and get some more multiplayer demos done again next year. Let me just add, that I tried a aerotow demo on my laptop which did'nt turn out very succesfully from the aviation point of view, but seemed to be very impressive from the software perspective. I started two FlightGear sessions on my dual core laptop with a secondary monitor attached, having each FlightGear session on one display. Both synchronized via the multiplayer server we had. I tried to operate the j3cub and the ask21 simultaneously but my multitasking capabilities where somewhat limited to perform fast enough for that. At least, I was able to take off a couple of feet - but quickly broke the tow. Nevertheless, people were impressed to see two instances of a simulator on a single laptop. Thanks to Durk for the organization of the booth and the other crew members for a fun time. Torsten Want pictures? http://www.t3r.de/flightpics/fsweekend2008/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FSWeekend impressions
Thomas F??rster wrote: Am Montag 03 November 2008 schrieb Martin Spott: Somewhen in the past we've been starting the FlightGear Expo Checklist page on the wiki (you won't find the page without using a seach engine) Sometimes a little link might help... ;) http://wiki.flightgear.org/index.php/FlightGear_Expo_Checklist Thanks for adding the link - I didn't have neither a graphical desktop nor a suitable browser handy when I had been writing the above posting, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: use of boost libraries
Am Montag 03 November 2008 schrieb gerard robin: ..[boost libs introduction]... Are we talking about it ? http://www.boost.org/users/license.html Which is not said being GPL Not knowing any details, from the website it sounds like things are more complicated: Introduction The Boost Software License specifies the terms and conditions of use FOR THOSE Boost libraries THAT IT COVERS. (capitalization by me) Seems not all libs are under a maybe non GPL license and even worse, not all libs are under the same license, making this a case by case decision. Has anyone further investigated into this? Thomas - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: use of boost libraries
Martin Spott wrote: Instead, some places in FlightGear itself (at least Nasal and JSBSim, as far as I remember) are the factors that limit portability. Erik Hofman wrote: I'm pretty sure JSBSim works nicely on IRIX. I'll give it another try soon to make sure. Jon S. Berndt wrote: We have actually gone to some effort to make sure that JSBSim compiles everywhere. Even on my cell phone. ;-) Ah, that's good to know, I'll give it yet a try on the next occasion, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: use of boost libraries
Thomas Förster wrote: Am Montag 03 November 2008 schrieb gerard robin: ..[boost libs introduction]... Are we talking about it ? http://www.boost.org/users/license.html Which is not said being GPL Not knowing any details, from the website it sounds like things are more complicated: Introduction The Boost Software License specifies the terms and conditions of use FOR THOSE Boost libraries THAT IT COVERS. (capitalization by me) Seems not all libs are under a maybe non GPL license and even worse, not all libs are under the same license, making this a case by case decision. Has anyone further investigated into this? I'm not proposing that Boost source code be included in FlightGear/SimGear sources, so I don't see how the Boost license matters. That said, I wouldn't want to depend unnecessarily on proprietary libraries. Right after Thomas' quote above it goes on to say, Currently, some Boost libraries have their own licenses. The hope is that eventually all Boost libraries will be covered by the Boost Software License. In the meantime, all libraries comply with the Boost License requirements. The Boost License requirements are: * Must be simple to read and understand. * Must grant permission without fee to copy, use and modify the software for any use (commercial and non-commercial). * Must require that the license appear with all copies [including redistributions] of the software source code. * Must not require that the license appear with executables or other binary uses of the library. * Must not require that the source code be available for execution or other binary uses of the library. This all sounds nice and Open Source Friendly to me. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: use of boost libraries
As someone who uses Boost for some projects at work, there are two things to consider regarding this. One is that I believe all new libraries must be under the Boost license to be accepted (don't quote me on that) and those qualifiers were put in because before the creation of the Boost Software License individual libraries were under whatever license the author chose. The second thing to consider is that can pull in individual libraries as dependencies (i.e, only the Random, Hash and GIL libraries) rather than requiring _all_ of boost. Then libraries could be reviewed on an individual basis as acceptable dependencies. Jonathan On Mon, 3 Nov 2008 15:02:02 +0100, Thomas Förster [EMAIL PROTECTED] wrote: Am Montag 03 November 2008 schrieb gerard robin: ..[boost libs introduction]... Are we talking about it ? http://www.boost.org/users/license.html Which is not said being GPL Not knowing any details, from the website it sounds like things are more complicated: Introduction The Boost Software License specifies the terms and conditions of use FOR THOSE Boost libraries THAT IT COVERS. (capitalization by me) Seems not all libs are under a maybe non GPL license and even worse, not all libs are under the same license, making this a case by case decision. Has anyone further investigated into this? Thomas - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Jonathan Wagner - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug in glide_slope_tunnel.nas or gui.nas?
Does anybody else see this after startup? (compiled on linux from CVS a few days ago) Nasal runtime error: non-objects have no members at /home/torsten/FlightGear/data/Nasal/gui.nas, line 12 called from: /home/torsten/FlightGear/data/Nasal/glide_slope_tunnel.nas, line 81 called from: /home/torsten/FlightGear/data/Nasal/glide_slope_tunnel.nas, line 98 called from: /home/torsten/FlightGear/data/Nasal/globals.nas, line 76 It seems, that gui.INIT() is called after glide_slope_tunnel.loop(), which calls gui.popupTip() that relies on screenHProp set by gui.INIT(). This only happens, if the glide slope tunnel is enabled on startup. Torsten - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: use of boost libraries
Martin Spott wrote: Instead, some places in FlightGear itself (at least Nasal and JSBSim, as far as I remember) are the factors that limit portability. I'm pretty sure JSBSim works nicely on IRIX. I'll give it another try soon to make sure. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: use of boost libraries
Erik Hofman wrote: I believe (with a big questionmark) that boost works fine with MIPSpro nowadays, but I wouldn't argue against it if it didn't. Well, for approx. two years now (rough guess) FlightGear reportedly - from different places - requires some GCC-isms to compile on Unix- Systems anyway. So it's not a question about wether the _dependencies_ are portable (TM) - OSG for example compiles and works nicely on Solaris, even on IRIX using their 'native' compilers and I've also been successful in compiling 'boost' on Solaris. Instead, some places in FlightGear itself (at least Nasal and JSBSim, as far as I remember) are the factors that limit portability. I'm getting asked regularly about the state of support for FlightGear on OpenSolaris. So, if there's someone looking for a headache, this might be a good place to start ;-)) Best regards, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: use of boost libraries
On 3 Nov 2008, at 00:30, Tim Moore wrote: I know that Boost is well supported on Linux and see that it is on Windows as well, though I have no direct experience with that. Are there any objections to or comments about adding Boost as a FlightGear dependency? My recollection is that parts of Boost (possibly the parser module?) are implemented in a templated way that can cause quite amazing code size increases. This was the reason for not using it in another project I was involved with, a couple of years ago. It may well be that improvements in compiler code-gen for templates have fixed this - or more likely, the issues is in parts of Boost that won't be touched. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FSWeekend impressions
On 2 Nov 2008, at 23:17, Durk Talsma wrote: To summarize, FSWeekend 2008 has been a lot of fun for me, and I hope also for the rest of the crew. I certainly hop to organize another booth next year. I hope to post some photo's later. I will have to reconnect my server again, so I won't do that until tomorrow. Cheers, Durk (your FGFS representative signing off... :-) ) Some points to keep in mind for LinuxTag booth planning, assuming people are going? Your report is bringing back nightmares of trying to get the WorldForge clients and servers all playing together on an assortment of laptops and overheating PCs in unventilated exhibition halls! Sounds like it was a great event, thanks to all involved for their hard work. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FSWeekend impressions
Martin Spott wrote: James Turner wrote: Some points to keep in mind for LinuxTag booth planning, assuming people are going? I'm pretty certain that we're going to keep our schedule and to be present on LinuxTag next year - although we yet have to find a small aircraft to place onto the booth :-) That always works - we got more people than the IBM stand at LUDEx in London in 2001 - mainly thanks to this: http://photos.stockill.org.uk/p4000506.html IBM had paid for the shipping though, and I'm still using up the enormous box of pens they chucked at me as they were packing up They wouldn't let us steal their 10ft wide plasma screen though. Jon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: use of boost libraries
* Jonathan Wagner -- 11/3/2008 3:34 PM: The second thing to consider is that can pull in individual libraries as dependencies (i.e, only the Random, Hash and GIL libraries) rather than requiring _all_ of boost. Sure. I think most people knew this. But I assume it's very unlikely that anyone has only some libs of boost installed. You either have it (all of it), or you don't. So a dependency on only a few libs doesn't really make us less dependent. And *if* we accept the dependency (which seems to be as good as decided), then we can also use more of its libs without making the situation any worse. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
Hi Melchior, why do you take this to the -users list again, where it is obviously off-topic as a development issue and after I had taken the discussion where it belongs: to the -devel list? The proposal as posted in my announcement was designed by a group of developers, not just Martin and me. I just took the task of proposing and defending it. You might want to consider that the proposal was thoroughly pondered before implementing it on the scenery side and publishing it. Our team has experts on the relevant issues, ranging from databases and operating systems to the concerned parts of FlightGear and the scenery process. So as long as you do not _prove_ us wrong, there is no reason to conclude that our proposal is nonsensical. I will show that what you did is far from proving us wrong. I am open to change the structure and even defend the change in the group of developers who have designed it if the change does not contradict the goal of the proposal and there are sufficient arguments for a change weighing up the cost of additional risk and effort. Not only are your arguments not sufficient, the largest share of your change requests even contradicts the goal of our proposal. For the benefit of discussion with _other_ FlightGear developers I will lay out the arguments for this. I might add that in some rare cases I share your sense of beauty w.r.t. technical aspects of FlightGear, but this is not such a case and even if it was, it would not be a sufficient argument. I am full-quoting your mail, so all developers not on the users-list can see what we are talking about. That should be also in your interest, because your and my comments can now be found in additional places, so you and I can occasionally point to it ;-) Melchior FRANZ wrote: I give up. Let's just have the nonsensical directory layout. It's not the only bad design in fgfs, and I'm the only one who cares about it, anyway. But here's a final comparison for your entertainment (and for the archive, so that I can occasionally point to it ;-): Solution 1 -- proposed and defended by Ralf and Martin: --- Airports/L/O/X/LOXA.ils.xml /LOXA.parking.xml /LOXA.rwyuse.xml /LOXA.twr.xml /LOXA.threshold.xml /LOXN.ils.xml /LOXN.parking.xml /LOXN.rwyuse.xml /LOXN.twr.xml /LOXN.threshold.xml /LOXT.ils.xml /LOXT.parking.xml /LOXT.rwyuse.xml /LOXT.twr.xml /LOXT.threshold.xml /LOXZ.ils.xml /LOXZ.parking.xml /LOXZ.rwyuse.xml /LOXZ.twr.xml /LOXZ.threshold.xml Characteristics: - lots of files per level (messy) lots of files per level is the characteristics. lots is not a quantifiable measurement and messy is your very personal interpretation. Incidentally, messy is the only attribute in this point I can see coming near to an argument against our proposal, again in the realm of personal perception of beauty and therefore without any concrete foundation except your personal taste. Your personal taste is not in itself a sufficient argument for a change in this context. I think we should rather be discussing concrete characteristics such as validity, maintainability, performance and correctness. Wouldn't you agree? - natural grouping done by prefixes, rather than directories (the latter of which were invented for that purpose and come at *no* costs) Just because it might not cost anything doesn't mean that it's better. Window paint was invented for the purpose of painting windows and comes at no recurring cost. Still it does not make any sense to me to paint my windows if I want to have an unobstructed outside view. Also the fourth directory level _does_ cost something. See below. - tower abbreviated as twr (not saving *any* space) Saving space might not be the only argument in favour of twr, and even without such an argument, I can see no important point against our proposal here that would warrant a change. Technical argument: - it's too late, we don't want to change it anymore You might want to check your use of quotes, because they usually indicate word-by-word quotations. Neither can I be quoted that way nor did I say anything that implies the meaning of the phrase attributed to me. This is what I wrote: So if there is a strong argument in favour of the changes you proposed, I'm open to such a last-minute change, but otherwise I'd rather leave the structure as it is. (http://sourceforge.net/mailarchive/message.php?msg_name=490CA168.40004%40custom-scenery.org) This was the very first time I mentioned this constraint and did not represent it differently afterwards. Further what you obvioulsy are referring
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
Off topic to Melchior and Ralf's non-technical discussion, but: On Mon, Nov 3, 2008 at 8:29 AM, Ralf Gerlich [EMAIL PROTECTED] wrote: The index concept has some similarity to a B-tree (http://en.wikipedia.org/wiki/B-Tree) in terms of structure, though the balancing aspect and therefore some of the performance estimates do of course not apply. Still, the general intention and the structural aspects are in most points applicable to our index. To truly optimize for load balancing the operating system's directory searches, we should really be reading from the right end of the airport identifier ... which is more uniformly random than the left end. We can drop one level of tree completely, only increase the size of the worst case leaf directory by a factor of two from 58 to 107 files, and reduce the number of organizational directories from 9681 to 1267. The average size of each leaf directory increases from 3 to 21 files which is comparable to the tree directories that now have 36 subdirectories. This naming scheme would cause the example file to become: Airports/A/X/LOXA.ils.xml Having said that, anyone doing non-programmatic access is probably not going to enjoy that hierarchy. So, unless someone wants to assert that Airports/ is going to be under automated maintenance, I continue to think that Ralf (et al) have made a good choice. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: use of boost libraries
On Mon, 3 Nov 2008 11:59:34 + (UTC), Martin wrote in message [EMAIL PROTECTED]: Erik Hofman wrote: I believe (with a big questionmark) that boost works fine with MIPSpro nowadays, but I wouldn't argue against it if it didn't. Well, for approx. two years now (rough guess) FlightGear reportedly - from different places - requires some GCC-isms to compile on Unix- Systems anyway. So it's not a question about wether the _dependencies_ are portable (TM) - OSG for example compiles and works nicely on Solaris, even on IRIX using their 'native' compilers and I've also been successful in compiling 'boost' on Solaris. Instead, some places in FlightGear itself (at least Nasal and JSBSim, as far as I remember) are the factors that limit portability. I'm getting asked regularly about the state of support for FlightGear on OpenSolaris. So, if there's someone looking for a headache, this might be a good place to start ;-)) ..headache, you're viciously wicked! ;o) Last time I heard about OpenSolaris, was on http://groklaw.net/ where the issues were the legal nature of their licensing, not technological, Sun's CDDL is not compatible with the GPL by design, under Sun's own corporate legal policy. Further background: http://www.groklaw.net/article.php?story=20050126023359386 http://www.groklaw.net/article.php?story=20050205022937327 http://www.groklaw.net/article.php?story=20041218044030728 http://www.google.com/search?num=100hl=enq=site%3Agroklaw.net+GPL+CDDLbtnG=Search ..bottom line is do not mix GPL code with CDDL code. Can be extended to find some OpenSolaris guy to do the CDDL coding, as that will allow licensing apartheid, to prevent litigation, you want firm borders around your work. Recent developments: http://www.groklaw.net/article.php?story=20080729154916498 http://www.groklaw.net/article.php?story=20080502163143920 http://www.groklaw.net/article.php?story=20071029143159212 http://www.google.com/search?hl=enq=OpenSolaris+license+site%3Agroklaw.netbtnG=Search http://www.google.com/search?num=100q=OpenSolaris+licenseie=UTF-8oe=UTF-8 -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: use of boost libraries
On Mon, 3 Nov 2008 13:25:58 +0100, gerard wrote in message [EMAIL PROTECTED]: On lundi 03 novembre 2008, Tim Moore wrote: I've been working on effects support for FlightGear, as part of the work I've been doing on integrating shadows into the OSG version. Roughly speaking an effect is like a material for an object, but it can support different techniques based on OpenGL features and user choices. Each technique is multipass and of course supports shaders. Anyway, in doing this work I've been using the Boost library from boost.org, and I'd like to introduce it as a new dependency in FlightGear. I've used its rich support for working with STL iterators and binding functions for use with STL algorithms. More generally, I like Boost's implementation of the TR1 libraries that are being introduced in the C++0x standardization process (including a standard hash table implementation). Boost contains a ton of well-tested, useful code. I know that Boost is well supported on Linux and see that it is on Windows as well, though I have no direct experience with that. Are there any objections to or comments about adding Boost as a FlightGear dependency? Tim Are we talking about it ? http://www.boost.org/users/license.html Which is not said being GPL ..is it compatible with the GPL? http://www.fsf.org/licensing/licenses/gpl.html -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: use of boost libraries
On Tue, 4 Nov 2008 00:52:42 +0100, Arnt wrote in message [EMAIL PROTECTED]: On Mon, 3 Nov 2008 11:59:34 + (UTC), Martin wrote in message [EMAIL PROTECTED]: Erik Hofman wrote: I believe (with a big questionmark) that boost works fine with MIPSpro nowadays, but I wouldn't argue against it if it didn't. Well, for approx. two years now (rough guess) FlightGear reportedly - from different places - requires some GCC-isms to compile on Unix- Systems anyway. So it's not a question about wether the _dependencies_ are portable (TM) - OSG for example compiles and works nicely on Solaris, even on IRIX using their 'native' compilers and I've also been successful in compiling 'boost' on Solaris. Instead, some places in FlightGear itself (at least Nasal and JSBSim, as far as I remember) are the factors that limit portability. I'm getting asked regularly about the state of support for FlightGear on OpenSolaris. So, if there's someone looking for a headache, this might be a good place to start ;-)) ..headache, you're viciously wicked! ;o) Last time I heard about OpenSolaris, was on http://groklaw.net/ where the issues were the legal nature of their licensing, not technological, Sun's CDDL is not compatible with the GPL by design, under Sun's own corporate legal policy. Further background: http://www.groklaw.net/article.php?story=20050126023359386 http://www.groklaw.net/article.php?story=20050205022937327 http://www.groklaw.net/article.php?story=20041218044030728 http://www.google.com/search?num=100hl=enq=site%3Agroklaw.net+GPL+CDDLbtnG=Search ..bottom line is do not mix GPL code with CDDL code. Can be extended to find some OpenSolaris guy to do the CDDL coding, as that will allow licensing apartheid, to prevent litigation, you want firm borders around your work. Recent developments: http://www.groklaw.net/article.php?story=20080729154916498 http://www.groklaw.net/article.php?story=20080502163143920 http://www.groklaw.net/article.php?story=20071029143159212 http://www.google.com/search?hl=enq=OpenSolaris+license+site%3Agroklaw.netbtnG=Search http://www.google.com/search?num=100q=OpenSolaris+licenseie=UTF-8oe=UTF-8 ..the earful || zinger: http://www.groklaw.net/article.php?story=20050121014650517 -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1 (final directory comparison)
* Alex Perry -- 11/3/2008 11:26 PM: Off topic to Melchior and Ralf's non-technical discussion, but: Better non-technical than technical but wrong. ;-) To truly optimize for load balancing the operating system's directory searches, This isn't about load balancing at all. It's just about avoiding to have 2*n files on one directory level, which would be painful for computer and humans. Sorting from the left is actually better than your suggestion, as the likeliness that all of LO?? ends up in the file cache (- read-ahead) would be an advantage, while having all of ??XA in the cache doesn't buy you anything. Apart from that both are equivalent. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
