Re: [Flightgear-devel] FGRUN link problem in ubuntu
Hi Fred,
Thank you! Yes, 512 links perfectly...
It's strange - I sort of saw the circular reference, and
tried many times to 'fix' the library 'order', but nothing
seemed to work! Each time with different problems...
I did _NOT_ think of putting a library TWICE, or perhaps
more times, in the list!
But I suppose it sort of make sense if the linker does
not look back to what it has already resolved! This
feels like a 'bug' in the linker, and seems like
someone should look at and fix the linker source ;=))
I note from the gcc site - http://gcc.gnu.org - that
they have a later release 4.3.3 2009-01-24, compared
to my 4.2.4 2008-05-19, and maybe this has been fixed
in there.
I see I could install this 4.3.3 through the
Synaptic Package Manager, and might try this if I
get the time...
Anyway, lesson learned, and thanks for the speedy fix.
And also for the 'const' addition to remove the pesky
warning.
Regards,
Geoff.
On Sat, 2009-03-07 at 21:34 +0100, Frederic Bouvier wrote:
I didn't read your message carefully. It was a bit tricky but it should
be fixed now. Order of libraries in the link command is important and
sometimes the same library must be put twice because of circular
dependencies. Update your fgrun workspace ( to 512 ).
-Fred
Frederic Bouvier a écrit :
Hi Geoff,
Mathias introduced a new SimGear Library : libsgbvh if I recall
correctly. Pretty sure it must be added to the link command.
-Fred
Geoff McLane a écrit :
Hi Fred et al,
In ubuntu, updated (cvs/svn) PLIB, SG, OSG, FG, and
FGRUN (svn/trunk) yesterday AND today (2009-03-07)...
FG compiles and runs ok, at least for the default
cessna...
BUT can not get FGRUN to link! ;=((
The big error output is given below.
I thought it might just be missing some new SG things added very
recently, like libsgbvh, so amended src/Makefile.am to include _ALL_
the SG libraries, but still a problem! The error output changed to 2
given below.
I even tried a fresh svn checkout, and presently at revision 510
Any help appreciated...
I am using gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3), and
there is also a repeated 'warning' that has been there for a while :-
make[2]: Entering directory `/home/geoff/fg/fgrun/trunk/fgrun/src'
g++ -DHAVE_CONFIG_H -I. -I/home/geoff/fg/install/simgear
-I/home/geoff/fg/install/plib/include
-I/home/geoff/fg/install/OpenSceneGraph/include
-I/home/geoff/fg/install/simgear/include -DLOCALEDIR=
\/home/geoff/fg/install/fgrun/share/locale\ -g -O2 -MT wizard.o -MD
-MP -MF .deps/wizard.Tpo -c -o wizard.o wizard.cxx
In file included from wizard.cxx:8:
folder_open.xpm:52: warning: deprecated conversion from string constant
to ‘char*’
... repeated many many times ...
But just adding 'const' in front of
char * folder_open_xpm[] = {
gets rid of this warning...
But still the LINK problem... Any others with this problem?
Regards,
Geoff.
Error output 1
g++ -DLOCALEDIR=\/home/geoff/fg/install/fgrun/share/locale\ -g -O2
-L/home/geoff/fg/install/plib/lib
-L/home/geoff/fg/install/OpenSceneGraph/lib
-L/home/geoff/fg/install/simgear/lib -o fgrun wizard.o wizard_funcs.o
advanced.o advanced_funcs.o AirportBrowser.o AirportTable.o Fl_Table.o
Fl_Table_Row.o Fl_OSG.o Fl_Heading_Dial.o main.o io.o fgfsrc.o logwin.o
parkingloader.o settings.o util.o run_posix.o fgrun_pty.o -lsgmodel
-lsgmath -lsgscreen -lsgprops -lsgxml -lsgmisc -lsgdebug -lsgstructure
-lsgutil -lplibsg -lplibul -lplibnet -losgParticle -losgSim -losgViewer
-losgGA -losgText -losgDB -losgUtil -losg -lOpenThreads -lfltk_gl
-lpthread -lfltk -lXft -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11
-lm -lz -lutil -losgFX
/home/geoff/fg/install/simgear/lib/libsgmodel.a(ModelRegistry.o): In
function `simgear::BVHStaticGeometryBuilder::addTriangle(SGVec3float
const, SGVec3float const, SGVec3float const)':
/home/geoff/fg/simgear/source/simgear/scene/model/../../../simgear/scene/bvh/BVHStaticGeometryBuilder.hxx:114:
undefined reference to
`simgear::BVHStaticTriangle::BVHStaticTriangle(unsigned int, unsigned int
const*)'
/home/geoff/fg/install/simgear/lib/libsgmodel.a(ModelRegistry.o): In
function
`simgear::BVHStaticGeometryBuilder::buildTreeRecursive(std::listsimgear::BVHStaticGeometryBuilder::LeafRef,
std::allocatorsimgear::BVHStaticGeometryBuilder::LeafRef )':
/home/geoff/fg/simgear/source/simgear/scene/model/../../../simgear/scene/bvh/BVHStaticGeometryBuilder.hxx:222:
undefined reference to
`simgear::BVHStaticBinary::BVHStaticBinary(unsigned int,
simgear::BVHStaticNode const*, simgear::BVHStaticNode const*, SGBoxfloat
const)'
/home/geoff/fg/install/simgear/lib/libsgmodel.a(ModelRegistry.o): In
function `simgear::BVHStaticGeometryBuilder::buildTree()':
/home/geoff/fg/simgear/source/simgear/scene/model/../../../simgear/scene/bvh/BVHStaticGeometryBuilder.hxx:133:
undefined reference to
[Flightgear-devel] Improved Saitek Cyborg Evo Force support in MacOSX
Hi all, I have Saitek Cyborg Evo Force joystick that does not work with the released MacFG (1.9.1) nor latest CVS flightgear on my Mac (OSX 10.5.6). There are several issues to resolve. I list the issues below and also suggest how to fix them. 1) The latest release of PLIB does not recognize the rudder and throttle axises. I sent a patch to the PLIB developers that resolves the axis issue and the patch was accepted. The developers committed the changes to the PLIB subversion repository, http://plib.svn.sourceforge.net/viewvc/plib?view=revrevision=2155 I suppose that when the PLIB developers release 1.8.6, the new PLIB version will be incorporated in future FG releases, and the improved joystick support will find its way to MacFlighear. 2) The second issue is that the configuration file for the Saitek Evo line of joysticks (.../Saitek/Cyborg-Evo.xml) does not recognize my joystick. The reason for this is that the name tag for the force variant of the joystick is expected to be 'nameSaitek Cyborg Evo Force/name' whereas my joystick requires 'nameCyborg Evo Force/name'. The simple fix is to add this new tag to the configuration file but the rudder and trottle axises are interchanged. Again there is a simple fix to the issue, simply change the axis assignments between the rudder and the throttle. Doing this resolves the issue locally for me. However, on a grander scale I'd like to see the changes get into CVS repository. Adding my rudder/throttle axis change into the repository may break the Saitek Evo joysick configuration for other flightgear users on Mac. I provide 2 solutions for the configuration file problem and would be happy if one of them is pushed into the CVS repository. A) The polished backward compatible way is to add another configuration file. To this end I have attached Cyborg-Evo-Force.xml to this mail. This configuration files is based on the Cyborg-Gold-3d-USB.xml file and will only catch joysticks that presents them as Cyborg Evo Force (new tag not used before). B) The unpolished way is to make the required changes to the Cyborg-Evo.xml file. Since the changes will only affect Mac users, ask MacFG Saitek Evo users to test the new configuration. If there are happy MacFG Cyborg-Evo users they will probably react but if there is no MacFG users with Cyborg-Evo then the suggested changes will not affect anyone. I have added this second suggestion since I have no idea of the number of MacFG Cyborg Evo users, but I note that the Evo line of joysticks is not listed as confidently supported on the MacFG web site (http://macflightgear.sourceforge.net/home/documents/faq/#content_1_3) nor is Saitek themselves pro-Mac. Saitek only market their joysticks as Windows compatible. I have attached a cvs diff with changes to Cyborg-Evo.xml if this second solution is acceptable. I prefer solution B but it may upset users. Solution B is a cleaner fix in my eyes but it is important not to alienate once user base. The question is, how many MacFG users are there with Saitek Evo joysticks? Please note, the button assignment between configuration files in solution A and B differ since I prefer the assignments in A (almost the same as in the Cyborg-Gold-3d-USB.xml file). Can someone with CVS write permissions review my changes and if acceptable commit them to the repository? Cheers, Jari ? Input/Joysticks/Saitek/Cyborg-3d-USB.xml ? Input/Joysticks/Saitek/Cyborg-Evo-Force.xml Index: Input/Joysticks/Saitek/Cyborg-Evo.xml === RCS file: /var/cvs/FlightGear-0.9/data/Input/Joysticks/Saitek/Cyborg-Evo.xml,v retrieving revision 1.10 diff -u -p -r1.10 Cyborg-Evo.xml --- Input/Joysticks/Saitek/Cyborg-Evo.xml 20 Nov 2008 18:14:00 - 1.10 +++ Input/Joysticks/Saitek/Cyborg-Evo.xml 8 Mar 2009 14:29:53 - @@ -45,6 +45,7 @@ axis 5: (hat up-down) look u/d Trim E nameSaitek Cyborg Evo/name nameSaitek Cyborg evo Wireless/name nameSaitek Cyborg Evo Force/name +nameCyborg Evo Force/name !-- Axis Bindings -- @@ -67,12 +68,7 @@ axis 5: (hat up-down) look u/d Trim E /binding /axis -axis - number - mac3/mac - unix2/unix - windows2/windows - /number +axis n=2 descThrottle/desc binding commandnasal/command @@ -80,12 +76,7 @@ axis 5: (hat up-down) look u/d Trim E /binding /axis -axis - number - mac2/mac - unix3/unix - windows3/windows - /number +axis n=3 descRudder/desc binding commandproperty-scale/command !-- $Id$ Joystick binding definitions for Saitek Cyborg Evo Force Joystick. This file borrows heavily from Cyborg-Gold-3d-USB.xml and
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: SimGear/projects/VC8 SimGear.vcproj, 1.14, 1.15
On 7 Mar 2009, at 21:47, Mathias Froehlich wrote: Modified Files: SimGear.vcproj Log Message: Zap SGLocation. Modified Files: projects/VC7.1/SimGear.vcproj projects/VC8/SimGear.vcproj simgear/scene/model/Makefile.am simgear/scene/model/placement.cxx simgear/scene/model/placement.hxx Removed Files: simgear/scene/model/location.cxx simgear/scene/model/location.hxx Woo, nice one Mathias, this one was on my TODO list for the future. James -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: SimGear/projects/VC8 SimGear.vcproj, 1.14, 1.15
Hi James, On Sunday 08 March 2009 17:37:31 James Turner wrote: Woo, nice one Mathias, this one was on my TODO list for the future. Was on my TODO list since almost ever :) Hope that there are no other users appart from flightgear. To be honest, I have not looked into terragear et al to see if this might be a problem ... Tell me if this is in use somewhere else. Greetings Mathias -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ?
FlightGear needed a built-in scripting language, and it has one. A compact, clean, elegant and fast one. In total there are at the moment more than 170.000 lines of Nasal in *.nas files and a few thousands embedded in joystick drivers, dialog description files, model animation files, keyboard.xml, mice.xml and several other files. Extension functions interface perfectly to the property tree, the event manager, the built-in XML parser etc. Nasal is very tightly integrated in fgfs and used all over the place. The Lua language is quite similar to Nasal, even syntax-wise (where there are differences, Nasal is better IMHO). Do we want two similar languages embedded in fgfs side by side, so that people can choose? Hell, no! This is just needless bloat (re-invention of the wheel is an understatement!) and it would be a source of confusion. On which basis would people decide for one or the other? Would we expect them to evaluate both languages and to find out which works better for them? Or just take a random pick? What would be the advantage? That people who don't like Nasal can have something that's quite similar? Doesn't sound smart. So, having both in FlightGear is clearly not desirable. Would we want Lua to replace Nasal? Andy, the author of Nasal, is also FlightGear developer. He has done the integration in fgfs himself, he knows about our needs, he's almost daily in our IRC channel and always willing to answer questions or to improve the language. Lua just can't beat that. And it wouldn't be enough for Lua to be as good as Nasal, or slightly better. It would have to be vastly better to even be considered. It's an uphill battle and it doesn't look good for Lua. What are Lua's advantages? Random picks from Nicolas' email: debugger: Sure, that's nice. We have several debugging utility functions for Nasal, but no debugger. But then again, I wouldn't often have needed one. And to quote a fellow fgfs developer after he had read the Lua wikipedia page: No wonder they need a debugger! (People might be thrilled to learn that Lua's arrays (which are emulated with hashes, because there are no arrays at all) start with index 1 (Shudder!). But that's not all: you *can* write to array[0] and don't get an error message, but Lua will silently throw the value away and return nil if you read it out! Yes, Lua badly needs a debugger! ;-) documentation: True. Nasal could use some more. Nicolas could spend some of the time that integrating Lua would have taken for writing Nasal documentation. :-) These two points were the only clear advantages. What about the rest: faster than nasal (that's an opinion, [...]: Exactly. Just an opinion, with no benchmarks to back it up. And even if it's slightly faster: the Nasal execution time is *not* a bottle-neck in fgfs by any means. C API that allows loading of C/C++ modules through Lua: That's seriously presented as an advantage? It means that we would in no time see fgfs aircraft coming with binary blobs that users are supposed to install, but which they can't explore. That's not only dangerous, it also undermines FlightGear's Open Source character. This misfeature (in our context) alone should be enough to reject Lua! That's a gift for commercial freeloaders, not something that we profit from. If something needs to be fast, then we can code it in C++ right away, and make it available to all aircraft. user community: Nasal and FlightGear have their own user communities, thanks. Nasal isn't FlightGear only. It's used in other projects as well. And the Lua community wouldn't buy us much either. We wouldn't want that aircraft depend on external Lua modules, which users would have to download from www.luarocks.org or wherever and install them just to fly that aircraft. People contribute to fgfs because they want to, not because they are already familiar with its scripting language, which is easy enough to learn. * Nicolas Quijano -- Wednesday 04 March 2009: I really didn't want to get into that kind of argument (language comparisons, etc) How telling! In the game biz, it's never the best solution to roll your own [...] FlightGear is neither a game, nor a biz. And no, nasal is not really crucial, at least not with jsbsim. Why was Nasal chosen in the first place ? Wasn't it to supplement a fledgling FDM module at the time, yasim, that was lagging behind jsbsim and its property system ? Or so I've inferred and been told :) First: the property system was adopted *by* JSBSim. It's not something that JSBSim brought to the project. And second: Nasal has nothing to do with YASim other than it's by the same author. It doesn't have much to do with FDMs at all. It's used all over the place. Who was the source of this nonsense again? it doesn't bother anyone that the overall feeling given by more than a few longstanding community members is that Nasal is NOT well liked, quite the contrary ? More from the uninformed source? Where's the evidence? Names please!
[Flightgear-devel] SimGear licensing
Hi all, While I was in the process of perusing the SimGear code I noticed that some of the newer code was being released under the GPL As part of the original SimGear team I was under the impression that SimGear was specifically LGPL as expressed here http://simgear.org/mission_statement and here http://cvs.flightgear.org/viewvc/SimGear/COPYING?revision=1.1.1.1root=SimGear I have not been an active member of the FGFS community for a while and realize that things 'change' but I am curious The last thing I want todo is start anything even resembling a 'license' flame. but ... I find this unfortunate and a bit confusing ... Norman-- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reproducible crash in mk_viii.cxx
On 7 Mar 2009, at 09:40, James Turner wrote: start FlightGear using fgfs --aircraft=CitationX --airport=CYOW -- runway=25 take off, and make a left turn to heading 98, while maintaining an IAS of approx 250 kts, and an altitude of approx 2500 ft. Maintain this heading for approx 13 minutes and FlightGear will seg fault: Normally, these crashes are not related to the CullVisitor, it just happens to be a noisy part of the code, so it shows up in logs. The crash is almost certainly my fault, will take a look (probably tomorrow, today is my last day of I'm unable to reproduce the crash using these steps - can anyone else? James -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ?
I've been silent in this thread mostly because I'm not very active as a developer these days, but it got me wondering why one would use lua instead of nasal. Searching for 'lua nasal' in google the first hit describes it all to my opinion: http://trainofthoughts.org/blog/2007/09/16/lua-popularity/ If low footprint, then really low footprint, please… Or to stretch the point even further: if low footprint is really the ultimate reason for Lua (which is 13K LoC) and a reason against JavaScript (80K LoC) or even Perl (105K LoC), then I still do not understand why people not even use for instance Arena (14K LoC) or even NASAL (5K LoC). Arena and NASAL both at least are a lot more C/ C++ /Perl/ Java/ JavaScript style in their look and feel and so at least attract the “old-style” coders a lot more. I agree with this statement and therefore don't particularly like the idea to change scripting language just for the sake of it. I do wonder how well lua would handle the property system (and xml files) though. Erik -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reproducible crash in mk_viii.cxx
Yep!
Tried ...
--aircraft=CitationX --airport=CYOW --runway=25 --fg-scenery=
$HOME/Scenery-1.0.1
Take off, wheels up, and turn to 98, flying at about 2500, at about 260
IAS ... about 10 minutes or so and BANG!
As reported had hundreds of ...
CullVisitor::apply(Geode) detected NaN,
depth=nan, center=(0.006986 0.000522999 0.089738),
matrix={
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan
}
For for the next run I added --log-level=debug
==
and got last output of ...
CullVisitor::apply(Geode) detected NaN,
depth=nan, center=(0.006986 0.000522999 0.089738),
matrix={
nan nan nan nan
nan nan nan nan
nan nan nan nan
nan nan nan nan
}
Loading tile 1728984
Trying /home/geoff/Scenery-1.0.1/w080n40/w075n45/1728984
Trying /home/geoff/Scenery-1.0.1/Terrain/w080n40/w075n45/1728984
OBJECT_BASE 1728984.btg
Trying /home/geoff/Scenery-1.0.1/Objects/w080n40/w075n45/1728984
Running MaiOBn LJECT_SHARoop
=== ED M
odels/Communications/Updatradio-mediuing time
Cm.xml lon=urrent Unix calenda-74.7694r time = 123653lat=79345.4060
warp4 e = 0
lev= C-20.47 urrent hdg=GMT = 3/1808/2009
18:45:30
CurrenCreat Unixtin cag alend new buffer ofar tim size =e = 123653
37930 warp = 0
2768 Current GMT = 3/8/2009 18:45:
30
Current Julian Date = 2.4549e+06
COURSE: GMT = 2/8/109 18:45:30
March 21 noon (GMT) = 1237636800
Time since 3/21/109 GMT = -12.7184
days = -12 hours = 18.7583 lon = 0 lst = 5.95833
COURSE: GMT = 2/8/109 18:45:30
March 21 noon (GMT) = 1237636800
Time since 3/21/109 GMT = -12.7184
days = -12 hours = 18.7583 lon = nan lst = Creanantin
Currg aent l neon=0.00w b Siuffderer ealof Tisizme e == 32768
5.86471
gst = C245.8rea65
Currtinentg a LOCA neL Sidew buffer ofreal Ti sime = ze = 32768
nan (nan) (diff = -0.0936229)
Elapsed time interval is = 506127, previous remainder Creatingis a =
6283
new buffer of size = 3-- F276ram8
e rate is = 72
Model iterations needed = 61, new remainder = 4077
Creating a new buffer of size = 32768
Creating a new buffer of size = 32768
Creating a new buffer of size = 32768
Creating a new buffer of size = 32768
Creating a new buffer of size = 32768
Creating a new buffer of size = 32768
Defering boundingvolume tree built for
/home/geoff/Scenery-1.0.1/Terrain/w080n40/w075n45/1728984.btg to
parent.
Got cached model
/home/geoff/fg/fgfs/data/Models/Communications/radio-medium.ac
Defering boundingvolume tree built for
/home/geoff/fg/fgfs/data/Models/Communications/radio-medium.ac to
parent.
Defering boundingvolume tree built for
Models/Communications/radio-medium.xml to parent.
Building boundingvolume tree for 17289findbyF84.sreqtg.
379 size 33
Deleting a sample
In memory sounds sample
Loading tile 1728992
Trying /home/geoff/Scenery-1.0.1/w080n40/w075n45/1728992
Trying /home/geoff/Scenery-1.0.1/Terrain/w080n40/w075n45/1728992
OBJECT_BASE 1728992.btg
Trying /home/geoff/Scenery-1.0.1/Objects/w080n40/w075n45/1728992
OBJECT_SHARED Models/Communications/radio-medium.xml lon=-74.9431
lat=45.5417 elev=-32.36 hdg=180
OBJECT_SHARED Models/Communications/radio-medium.xml lon=-74.9542
lat=45.5769 elev=-17.42 hdg=180
OBJECT_SHARED Models/Communications/radio-medium.xml lon=-74.9419
lat=45.5419 elev=-13.77 hdg=180
OBJECT_SHARED Models/Communications/radio-medium.xml lon=-74.9389
lat=45.5408 elev=-24.74 hdg=180
Creating a new buffer of size = 32768
Creating a new buffer of size = 32768
Creating a new buffer of size = 32768
Creating a new buffer of size = 32768
Creating a new buffer of size = 32768
Creating a new buffer of size = 32768
Creating a new buffer of size = 32768
Creating a new buffer of size = 32768
Creating a new buffer of size = 32768
Creating a new buffer of size = 32768
Defering boundingvolume tree built for
/home/geoff/Scenery-1.0.1/Terrain/w080n40/w075n45/1728992.btg to
parent.
Got cached model
/home/geoff/fg/fgfs/data/Models/Communications/radio-medium.ac
Defering boundingvolume tree built for
/home/geoff/fg/fgfs/data/Models/Communications/radio-medium.ac to
parent.
Defering boundingvolume tree built for
Models/Communications/radio-medium.xml to parent.
Got cached model
/home/geoff/fg/fgfs/data/Models/Communications/radio-medium.ac
Defering boundingvolume tree built for
/home/geoff/fg/fgfs/data/Models/Communications/radio-medium.ac to
parent.
Defering boundingvolume tree built for
Models/Communications/radio-medium.xml to parent.
Got cached model
/home/geoff/fg/fgfs/data/Models/Communications/radio-medium.ac
Defering boundingvolume tree built for
/home/geoff/fg/fgfs/data/Models/Communications/radio-medium.ac to
parent.
Defering boundingvolume tree built for
Models/Communications/radio-medium.xml to parent.
Got cached model
/home/geoff/fg/fgfs/data/Models/Communications/radio-medium.ac
Defering boundingvolume tree built for
Re: [Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ?
Nice try, let me flip it right back at you : how telling of you to mix facts and your extremely biased opinion while accusing me of the same :) Not interested in debating this, never suggested Nasal should be dropped from the main FGFS tree. And even though I'm French, I've lived abroad all my life, so lack the necessary chauvinism to entertain such a thought. (-- that's a joke) I did wonder at why Nasal, etc. but I don't have the presumption to say that FGFS should move to Lua or the world will end ;) Is that clear enough ? It's always been in the context of a fork, whether public or private not being relevant. As for secret sources, they'll name themselves if they feel like it, can you respect that, whatever their reasons ? No smearing at all, btw : FGFS is great as it is, warts and canons of elegances alike. And it can and will be greater, probably in ways that don't suit either of us at times. And that's fine by me. You sure it's okay with you ? Again, thanks, it's been enlightening : makes it the more obvious that there will be public forks off simgear/flight gear in the very near future, thus becoming a matter of organisation and resources. Hopefully, it can all be done under a common benign overlord so at the very least, they can interact together over the wires. I also answer further down, in between quotes. On Sun, Mar 8, 2009 at 1:54 PM, Melchior FRANZ mfr...@aon.at wrote: FlightGear needed a built-in scripting language, and it has one. A compact, clean, elegant and fast one. In total there are at the moment more than 170.000 lines of Nasal in *.nas files and a few thousands embedded in joystick drivers, dialog description files, model animation files, keyboard.xml, mice.xml and several other files. Extension functions interface perfectly to the property tree, the event manager, the built-in XML parser etc. Nasal is very tightly integrated in fgfs and used all over the place. The Lua language is quite similar to Nasal, even syntax-wise (where there are differences, Nasal is better IMHO). Do we want two similar languages embedded in fgfs side by side, so that people can choose? Hell, no! This is just needless bloat (re-invention of the wheel is an understatement!) and it would be a source of confusion. On which basis would people decide for one or the other? Would we expect them to evaluate both languages and to find out which works better for them? Or just take a random pick? What would be the advantage? That people who don't like Nasal can have something that's quite similar? Doesn't sound smart. So, having both in FlightGear is clearly not desirable. Would we want Lua to replace Nasal? Again, never my intent : we're talking about a fork, a specialized version of FGFS. That said, if it's a developer's sandbox, facilitating end user choice of weapons is a good thing : anything that prevents tight coupling of conceptually separate modules is always smart. I think even you'd agree on this :) Andy, the author of Nasal, is also FlightGear developer. He has done the integration in fgfs himself, he knows about our needs, he's almost daily in our IRC channel and always willing to answer questions or to improve the language. Lua just can't beat that. And it wouldn't be enough for Lua to be as good as Nasal, or slightly better. It would have to be vastly better to even be considered. It's an uphill battle and it doesn't look good for Lua. Good to know Andy is around. But not sure Lua (or any established scripting solution) wouldn't beat that. Your rationale is fundamentally flawed, as cohabitation is not about which is better (neither), but rather what do people want, what will they use, and if you build it, will they use it ? Answers to all such question are never black and white, or resounding yes and no in any absolute fashion. Btw, if I come away from my experimenting with Nasal converted, I'll be the first to say it loud and clear :) What are Lua's advantages? Random picks from Nicolas' email: Arumph. Nothing random about your picking, at least be honest about it :) debugger: Sure, that's nice. We have several debugging utility functions for Nasal, but no debugger. But then again, I wouldn't often have needed one. And to quote a fellow fgfs developer after he had read the Lua wikipedia page: No wonder they need a debugger! (People might be thrilled to learn that Lua's arrays (which are emulated with hashes, because there are no arrays at all) start with index 1 (Shudder!). But that's not all: you *can* write to array[0] and don't get an error message, but Lua will silently throw the value away and return nil if you read it out! Yes, Lua badly needs a debugger! ;-) You quote, and sin again with what you reproach of me : sources ;) To boot, it's tendentious information Quote from the horse's mouth, not someone's else reading of wikipedia !!! Or don't moan about the fact that I didn't provide sources :) (or stop holding people
Re: [Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ?
Melchior is exactly right. JSBSim adopted the property system - which is a great piece of work by - was it David Megginson? I, too, have heard of some developers mixing Nasal scripts with all of the various FDMs, with great success. Jon From: Nicolas Quijano [mailto:nquij...@gmail.com] Sent: Sunday, March 08, 2009 4:00 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ? First: the property system was adopted *by* JSBSim. It's not something that JSBSim brought to the project. And second: Nasal has nothing to do with YASim other than it's by the same author. It doesn't have much to do with FDMs at all. It's used all over the place. Who was the source of this nonsense again? Archives other tidbits written all over the vast world of FGFS (mis)information. Maybe you should get off your virtual throne and get down and dirty with documentation... Or is it so beneath you or uninteresting that it's better to keep on harping that the newcomers should do it ? Do you realize how totally crazy this sounds, especially in the context of Nasal (language, internals, APIs from two POVs : dev and user) ? You want people who don't know anything about it to document it ? -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ?
* Nicolas Quijano -- Sunday 08 March 2009: As for secret sources, they'll name themselves if they feel like it, That would be fun! But I won't hold my breath. No smearing at all, The nonsense about Nasal being bandaid for a fledgling FDM and nobody liking it, is just smearing Nasal and YASim based on undisclosed sources, not on reality. It's rare that I have to read so much nonsense here on the list. Again, never my intent : we're talking about a fork, a specialized version of FGFS. That's fine, then. * Melchior FRANZ -- Sunday 08 March 2009: What are Lua's advantages? Random picks from Nicolas' email: Arumph. Nothing random about your picking, at least be honest about it :) I meant random in the sense that when I assembled the list I only glanced over the message again, and tried to pick all relevant arguments, but was also aware that I'd probably miss some. That's where the randomness comes from. Just tell us what I forgot and I'll rip that apart as well. :-P Quote from the horse's mouth, not someone's else reading of wikipedia !!! Huh? What makes you think I haven't immediately read the wikipedia article myself?! We discussed about it on IRC, but wikipedia is the source. Nasal also needs the debugger and better sandboxing : making a parsing error a fatal exception is not a long term solution... You can catch Nasal exceptions. And no, I'm not surprised Melchior : you have time to play language police, but no time to write docs, right ? [...] Maybe you should get off your virtual throne and get down and dirty with documentation... Or is it so beneath you or uninteresting that it's better to keep on harping that the newcomers should do it ? [...] You'll send PMs about language constructs, and how people should code, but you won't do the documentation work ? Another such fun-piece! Guess who wrote half of the existing documentation? http://wiki.flightgear.org/index.php/Nasal_scripting_language Check out the change history! You *really* don't know what you are talking about. As if you had to prove it ... In my empirical experience, it's the number one cause of stuttering and performance slowdowns (cue in wildfire) I said experience, not evidence :) Just because you say it's not a bottleneck, doesn't mean it's not. The wildfire author suspects that particles are the problem with wildfire slowness. allowing current commercial exploitiers of FSX or earlier version of the sim to bring their a/c to FGFS, something Curt himself expressed interest in, Yes, but not by throwing our ideals away and open a can of worms. I would be surprised to learn that Curt wants to encourage commercial entities to enhance fgfs with closed, secret binary parts. Or with aircraft that come only with OSX and MS Windows binary blobs, but without Linux/Solaris/... blobs. Cross-platformness is an important goal of the FlightGear project, and has always been. If the project's creator, and afaik, still manager/benign overlord to this day, [...] but ultimately thanks to Curtis for starting it all a decade ago Somehow I think of David MURR when I read project's creator, but Curt was AFAIK there at the very first hours (along with a few others). A co-founder, indeed. But this was long before my time, so I might be wrong here. Oh, maybe because like my so-called sources you have your own reasons to reply privately ? The reasons are: - self-proclaimed forum police trying to tell others what they can write - some forum admins asking for more censorship without acceptable reasoning - the dropping of ATOM/RSS with the last forum software update m. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ?
* Jon S. Berndt -- Sunday 08 March 2009: Melchior is exactly right. JSBSim adopted the property system - which is a great piece of work by - was it David Megginson? Yes. For those who don't know him: David is/was also JSBSim developer, wrote SAX (Simple API for XML), and several of the core parts of fg/sg. And he also played a role in the famous Torvalds-Tanenbaum thread. :-) m. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ?
* Melchior FRANZ -- Sunday 08 March 2009: [reasons for why I write PM in the forum] - self-proclaimed forum police trying to tell others what they can write - some forum admins asking for more censorship without acceptable reasoning Sorrym, should have been: people asking for more moderators and censorship, after a heated, but completely on-topic dicusssion had taken place (without any contributions by me). This wasn't the existing moderators' wish -- quite on the contrary. But the attitude shown here made the forum less interesting for me. - the dropping of ATOM/RSS with the last forum software update m. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
