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 ?
* 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 ?
* 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 ?
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 ?
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 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
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 ?
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
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 ?
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 ?
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
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: ... (code goes here )... So I suppose a 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: ... (code goes here )... or: ... (code goes here )... or even overload the current nasal tag to allow other languages: ... (code goes here )... 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
[Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ?
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. 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 :) 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. 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
