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!
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] 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
Re: [Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ?
Adding another language wouldn't be that hard. Actually, we had another one before nasal and beside nasal for a while. It was called PSL (plib scripting language), and we ripped it out because Nasal was/is just better and because offering and maintaining two languages it utterly pointless . And that's why I consider the likeliness of getting lua or any other language support committed approximately zero. I for one would strongly oppose (veto-style :-). Of course, what you do in your private copy or fork is your business. 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 ?
On Fri, Feb 27, 2009 at 4:27 AM, Melchior FRANZ wrote: Adding another language wouldn't be that hard. Actually, we had another one before nasal and beside nasal for a while. It was called PSL (plib scripting language), and we ripped it out because Nasal was/is just better and because offering and maintaining two languages it utterly pointless . And that's why I consider the likeliness of getting lua or any other language support committed approximately zero. I for one would strongly oppose (veto-style :-). Of course, what you do in your private copy or fork is your business. Let me jump in with some pre-coffee comments (so I'm not yet responsible for anything I say) :-) Nasal is *very* well designed, compact, and efficient. It is used heavily throughout many areas of FlightGear. So I can't imagine any scenario where we would switch to some new scripting language unless a lot key developers were convinced that it was every so much better that that benefit would substantially outweigh the cost. And I find that scenario hard to imagine. I agree that if you want to play around with integrating Lua into your own development tree, that's great. You will learn a ton about flightgear and it's internal structures in the process. I tend to side with others that there would need to be some overwhelmingly compelling reason to support lua along side Nasal within FlightGear. If the primary motivation is language preference, that is going to be a really tough sell around here ... and that is because Nasal is *really* slick, brilliantly conceived, well implemented, and it has served us so well. But all that said, FlightGear is intended to be a developers sandbox, so please feel welcome to play and learn and ask questions. Best regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- 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 ?
On Thu, 2009-02-26 at 16:05 -0500, Nicolas Quijano wrote: Hi all, let me start that my goal here is NOT to start a polemic on the reasons for using nasal vs any other scripting language, or the scripting vs native code, or any such argument :) Thanks for remembering that. OK, without getting into a religious discussion about the worth or advisability of adding another scripting into flightgear, it sounds like a lot of work and feature bloat for very, very little return. :) That said, being a long time user and proponent of levering scripting in games/sims, and particularly, using Lua, I have a keen interest in any insights garnered over time by current and past fgfs devs. How coupled are Nasal and the scripting glue in FGFS ? Is there a clean break, or if not, can it be refactored without too much pain into something that would allow end dev users to use whatever scripting language they prefer, or have many modules already writen in, etc. If the coupling is not of the hair pulling type, it might be conceivable to integrate another scripting language alongside Nasal for starters, and in time, completely replace it if one is so inclined :) It may not be inconceivably hard to add another interpreted language to flightgear. The first problem I noticed today is our XML spec didn't have this in mind, we have: nasal script ... (code goes here )... /script /nasal So I suppose a lua tag wouldn't be bad... But if we wanted to go in the direction of adding support for random scripting languages we might want to replace the top level tag with something else: userscript language=nasal script ... (code goes here )... /script /userscript or: userscript language=nasal script ... (code goes here )... /script /userscript or even overload the current nasal tag to allow other languages: nasal language=lua script ... (code goes here )... /script /nasal As far as replacing nasal, that project would be very hard. There are many vital parts of flightgear currently coded in nasal. There are also random bits of nasal code scattered around in joystick configurations, instrument and aircraft models, scenery models... everywhere. It would, in effect, require starting the whole data project over again. For me, this would be Lua, and I'll be working on integrating it in my local fork, but as I'm just getting down to tinker with FGFS source code, I'm interested in hearing your views on the topic. If there is interest in this beyond my own, I'd rather do it in a collaborative/friendly way that's not one sided, or in other words, I'd rather not rip out Nasal savagely to replace it completely with Lua, without thinking about compatibility down the road. My preferred approach would be to start with cohabitation, rather than coupling Lua to a local fork... What I'm interested in hearing is about the collective and individual experience of working with Nasal at the source code level, the API/communication mechanism between its VM/interpreter and native code, and plenty of other documentation details which do not seem to exist or that I haven't been able to find, and can save a lot of time in coming to grasp with code you haven't written. Nasal is actually implemented in the simgear project. Nasal communicates with flightgear through the property tree, so you'll have to create lua methods to read, write and create properties. Nasal calls flightgear commands in Main/fg_commands.cxx Nasal is also purposely limited on disk IO abilities. It is only able to read/write from specified directories. Otherwise it would be possible for a rogue aircraft script to send, say the contents of /etc/passwd to a random player on the multiplayer server... Thanks in advance for sharing your experiences with Nasal integration, Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- 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 wrote: If the coupling is not of the hair pulling type, it might be conceivable to integrate another scripting language alongside Nasal for starters, and in time, completely replace it if one is so inclined :) At the risk of diverting the thread, and not wanting to get into religious argument, but I'm genuinely curious as to why would you even want to do this? Is there something that Lua (or any other language) can do that you can't do in Nasal? If there is, then it would probably be better to fix it in Nasal than it would be to embed a whole new scripting language. As Ron has indicated already, while it would be possible, you are talking an immense undertaking to replace Nasal, and it seems that there really isn't any actual return on that investment (not that this is necessarily a bad thing, plenty of things are done just for the hell of it). -- James Sleeman -- 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
