RE: [Flightgear-devel] JavaScript!
David Megginson writes: (I'd love a programming environment on my Palm V, for example) Hmm.. I sense a potential Python convert lurking in these words :-) http://pippy.sf.net Enjoy Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
Cameron Moore writes: I think it's safe to say that there are two contenders at this point: Scheme and Lua. I'd never heard of Lua until this thread, but I've seen Scheme. I would expect that we would use Guile for a Scheme interpreter. How big is Guile? Has anyone ever used Lua? Run away screaming. There are several (many?) small, tight Scheme interpreters available, but Guile isn't in the list -- by now, it probably makes Python and Perl look compact. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
David Megginson wrote: Andy Ross writes: But the language itself is pretty mild. It's a lot like perl and python -- hashes and vectors are the core data structures, with syntax support for common idioms like regular expressions and function calling. Object naming is represented explicitly as a hash lookup, etc... That's my thinking as well. Personally, I'd be just as happy with Perl or even Python, but there are probably many more people out there who know JavaScript syntax. Once we remove all the browser-specific stuff, as you say, it should be nice and compact. So now I can safely conclude that JavaScript is the direction to go? runs away with his hands over his head and ducks Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
David Megginson wrote: So, Andy, here's your challenge -- you wrote YASim to prove how small and simple an FDM could be; how about showing us how small and simple a JavaScript implementation can be? I'm sure FlightGear isn't the only project that would benefit. Yikes, don't tempt me. You heard Curt -- I'd get it written, it would be small and tight and everyone would love it, and then I'd spend the next 10 years turning it into the huge monster that every other scripting language becomes. In place of the Dark Lord, you would set up a King; beautiful and terrible. All would love it and despair. Or something, anyway. I pass the test. :) Or not -- I'll admit that I've thought about writing a scripting language in the past. But it's not a simple project. Or rather, it can be a simple project if you're willing to do Scheme. If you want to do a parser for a nicer syntax and have built-in support for concepts like modules and OOP, it takes more work. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
David Megginson wrote: Erik Hofman writes: or do you mean: fgfs.set fgfs.setBoolean fgfs.get fgfs.getBoolean Yes, that stuff. It looks reasonable. Reasonable??? It's the same syntax you used for the Java library! :-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
Norman Vine wrote: Have you looked at SWIG ??? No, I dont know the package. The reason I ask is this looks nearly identical to the code SWIG would output for JavaScript from a SWIG interface file for fgSetString(char * , char *) The beauty of using SWIG is that the same interface file would support JavaScript, Perl, Python, TCL-Tk, Mzscheme, guile ... giving a choice of which Interpreter was compiled in. Is this a scripting engine, or a code generator? If it is a scripting engine wouldn't that mean the scripts would actually be one of: javascript, python, etc. That looks like it would make things difficult for script writers. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Javascript source
Erik Hofman wrote: Hi, I've placed the javascript code on my website at: No I haven't. Can find the location of my homepages on my ISP's webserver ... :-( Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
A couple of comments on the scripting issue: JavaScript is a really nice language, but you aren't going to get a very small runtime without losing useful things (like regular expressions). However, the sources are readily available, as has already been noted. My day job is working with Mozilla based products, and more than 1/2 our application logic is written in JS (pretty much all the UI and glue logic) JS is very effective and manageable, orders of magnitude moreso than Perl. Python is equally good as the code size grows, but the syntax puts people off and the common library is huge as Norman (I think?) already pointed out.. JS doesn't have a common library in the same way. Anyway, you can't (easily) leverage the JS runtime that ships with Mozilla, it's been subtly tweaked for Mozilla integration, and is often a not-quite-release version. It is technically possible to use the runtime, but I would strongly recommend not bothering to try, since it will introduce many complications. For one thing, it's sitting in a strange place: the Mozilla non-XPCOM shared object directory, which will be something like /usr/lib/mozilla, /opt/mozilla or possibly /opt/gnome/lib/mozilla (under Ximian). Should the user have a static Mozilla build (I don't know if this is ever going to happen in practice, but it keeps getting talked about) there won't even be a shared object to link to. In terms of embedding a really small interpreter, I know various people who've used Lua with great success (it seems designed to be inlined into a 'host' source tree and modified, not kept distinct), and it's really, really small. Never used it personally, but worth investigation if disk size is the primary consideration. Also, the dependency issues go away (in the projects I know that have added Lua, there has never been a support issue related to it) One final point : everything I've heard about SWIG indicates that it handles OO systems badly: it maps straight C to Perl/Tcl/etc well, but when you want to map classes to Java / Python / JS, it falls down pretty quickly. When I embedded Python in some of my own code, I tried using SWIG briefly, gave up, and was able to use the native Python API far more effectively. Sorry this drifted rather far OT, all just my 2 pence, of course. James
Re: [Flightgear-devel] JavaScript!
Erik Hofman writes: Yes, that stuff. It looks reasonable. Reasonable??? It's the same syntax you used for the Java library! I'm (well) over 18, so from me reasonable is higher praise than cool. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JavaScript!
James Turner writes: A couple of comments on the scripting issue: JS is very effective and manageable, orders of magnitude moreso than Perl. This is good to hear. Python is equally good as the code size grows, but the syntax puts people off a simple matter of taste, for example the other 'P' language syntax makes me cringe, similarly to what Python's 'whitespace'doesforsome:-) the common library is hugeThis is true, however IMHO this is a plus in that thereis alarge body of wellTESTED code that can just be usedas is,FYI it is also quite fine grained and is 'cross-platform'. In terms of embedding a really small interpreter, I know various people who've used Lua with great success Yes, I have heard the same One final point : everything I've heard about SWIG indicates that it handles OO systems badly: it maps straight C to Perl/Tcl/etc well, but when you want to map classes to Java / Python / JS, it falls down pretty quickly. This use to be a problem however the latest version of SWIGis much more OO friendly,it even has a'reasonably' complete C++ parser builtin !! When I embedded Python in some of my own code, I tried using SWIG briefly, gave up, and was able to use the native Python API far more effectively. SWIG does take a 'bit' of work to get used to BUTonce over the hurdle it is MUCH easier to keepin'sync' with the 'C' code base in that it 'usually' just uses the project header files or a subset of them to generate the 'wrappers' from. Plus with a little more thought you can get Multi-Language support too ! Norman
RE: [Flightgear-devel] JavaScript!
Erik Hofman writes: There is a small proble though, is there any way to pass an argument to a PLIB menuBar Callback function? NO use class data members, global variables or functions to get the 'arguments' within the callback() Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JavaScript!
Norman Vine writes: Erik Hofman writes: There is a small proble though, is there any way to pass an argument to a PLIB menuBar Callback function? NO use class data members, global variables or functions to get the 'arguments' within the callback() PLIB questions should really be asked on the PLIB list though :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
Norman Vine wrote: There is a small problem though, is there any way to pass an argument to a PLIB menuBar Callback function? NO use class data members, global variables or functions to get the 'arguments' within the callback() PLIB questions should really be asked on the PLIB list though :-) I know, but most of the time you seem to be right :-) Isn't there any trick with the puObject member either (I just need to know which menu entry is causing the callback)? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
David Megginson wrote: Erik Hofman writes: Good news (if you ask me)! I have an ECMA (Java)Script running in FlightGear, accessable true the menu (actually dynamically controllable trough a scripts.cml file). I now can toggle the sound on and of using JavaScript! Wow -- excellent news. Is the interpreter (1) Open Source or free It's licensed under both MPL and (L)GPL. and (2) small? We can already do scripting, of course, though -rwxr-xr-x1 erik user 826244 Mar 13 14:19 libjs.so external Java or Python processes using the libraries in scripts/, but I wouldn't want to require users to install a large Java or Python distro for core FlightGear functionality. A bundled interpreter is just what we need. I was thinking of it as a learning aid (set the plane 1km out on the flight path, etc.) There is a small proble though, is there any way to pass an argument to a PLIB menuBar Callback function? I searched the PLIB website but couldn't find a clue. I think you need to make the state information available somewhere else that the callback function can find it. Well, I am dynamically generating the menu structure. That means I can't use a per entry callback function. I need just one number/pointer/hint in the callback to get it working. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
Erik Hofman writes: and (2) small? We can already do scripting, of course, though -rwxr-xr-x1 erik user 826244 Mar 13 14:19 libjs.so I'm actually more concerned about the source tree size. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
David Megginson wrote: Erik Hofman writes: and (2) small? We can already do scripting, of course, though -rwxr-xr-x1 erik user 826244 Mar 13 14:19 libjs.so I'm actually more concerned about the source tree size. -rw-r--r--1 erik user 648823 May 12 2001 js-1.4-2.tar.gz -rw-r--r--1 erik user 1046117 Mar 13 19:12 js-1.5-rc4.tar.gz Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
Erik Hofman [EMAIL PROTECTED] said: Well, I am dynamically generating the menu structure. That means I can't use a per entry callback function. I need just one number/pointer/hint in the callback to get it working. Make a child class that has all the necessary data in it. And make your one user data item in puObject a pointer to the child class so you can pull its data in from inside the callback routine. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
Jim Wilson [EMAIL PROTECTED] said: Erik Hofman [EMAIL PROTECTED] said: Well, I am dynamically generating the menu structure. That means I can't use a per entry callback function. I need just one number/pointer/hint in the callback to get it working. Make a child class that has all the necessary data in it. And make your one user data item in puObject a pointer to the child class so you can pull its data in from inside the callback routine. Actually, you can just make a subclass with the info you need included. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JavaScript!
Erik Hofman writes:
Isn't there any trick with the puObject member either (I just need to
know which menu entry is causing the callback)?
why not just use use the puObject pointer
/* print the 'menu text' of calling menu entry on stdout */
void tattle_tale_cb( puObject *me)
{
printf(%s\n,me-getLegend());
/* do something useful now */
}
You could also derive a new class from popUpMenu
differing only by adding a userData argument to the
constructor which you could then use for ANYTHING
But you REALLY SHOULD ask this over on the PLIB list
as Steve probably has a better way of doing this
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
Erik Hofman writes: -rw-r--r--1 erik user 648823 May 12 2001 js-1.4-2.tar.gz -rw-r--r--1 erik user 1046117 Mar 13 19:12 js-1.5-rc4.tar.gz What does everyone else think? Should this be bundled unpacked in the SimGear source tree and built automatically (as with expat, our XML parser), bundled as an archive so that users can build it if they don't already have it installed (as with metakit and zlib), or left as an external, optional extra? I'd like to embed an interpreter in FlightGear, and ECMAScript is an excellent candidate language, but it would be nice if the interpreter were a lot smaller. Erik -- what do your bindings look like? Is anyone going to argue for embedding a small Scheme interpreter instead? Does anyone know of a smaller ECMAScript implementation? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
David Megginson writes: Erik Hofman writes: -rw-r--r--1 erik user 648823 May 12 2001 js-1.4-2.tar.gz -rw-r--r--1 erik user 1046117 Mar 13 19:12 js-1.5-rc4.tar.gz What does everyone else think? Should this be bundled unpacked in the SimGear source tree and built automatically (as with expat, our XML parser), bundled as an archive so that users can build it if they don't already have it installed (as with metakit and zlib), or left as an external, optional extra? I'd like to embed an interpreter in FlightGear, and ECMAScript is an excellent candidate language, but it would be nice if the interpreter were a lot smaller. Erik -- what do your bindings look like? Is anyone going to argue for embedding a small Scheme interpreter instead? Does anyone know of a smaller ECMAScript implementation? I would argue that if we do embed a script interpreter it should be really small, tight, and light weight. 1Mb of compressed source seems excessive ... this is almost exactly the same size as the entire flightgear source, so we'd be roughly doubling the size of our source and the time to compile ... If we include something that we want to maintain ourselves and not closely track some up stream 3rd party source, then it might make sense to unroll it in the source tree, integrate it with our build/install system, and distribute it that way. If it's something that comes standard or optionally with most distributions, then unrolling it and integrating with our own build system is probably going to be more trouble than it's worth, especially if we want to track upstream changes. We end up having to support platform and build issues which is a major PITA. In that case we could include a .tar.gz for the convenience of those that don't already have it installed ... like metakit and zlib. Also we need to consider that each new dependency we add significantly increases the barrier for new developers to get all the pieces in place to build their own executable. In light of this, having an external scripting system that uses a network interface becomes attractive. However, there can be performance issues with that which might be addressed by a built in script engine. I don't necessarily know enough about script interpreters to have a strong opinion as to how we should proceed, but I think these are the items we need to consider. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
David Megginson wrote: What does everyone else think? Should this be bundled unpacked in the SimGear source tree and built automatically (as with expat, our XML parser), bundled as an archive so that users can build it if they don't already have it installed (as with metakit and zlib), or left as an external, optional extra? I'd like to embed an interpreter in FlightGear, and ECMAScript is an excellent candidate language, but it would be nice if the interpreter were a lot smaller. If it would be a lot smaller (e.g. 20-50 kb zipped) I'm for including it. But at that size I'm against it. IMHO we should handle it like we do handle the JPEG writer: if it's aviable on the system compile the hooks into the code and if it isn't don't. So we don't have a new dependancy but offer the increased feature for those that care (or are lucky enough to have it pre installed on their system) Is anyone going to argue for embedding a small Scheme interpreter instead? No! If we add a scripting language it should be one that many people can use. So there are IMHO 4 choices: - JavaScript - Perl - VisualBasic (yuck!) - Python CU, Christian PS: Polls (asking an OpenSource community) showd that the most annoying thing about software are the dependancies. The greatness of an software has to rise exponentially to it dependancies (roughly) -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
David Megginson wrote: Erik Hofman writes: -rw-r--r--1 erik user 648823 May 12 2001 js-1.4-2.tar.gz -rw-r--r--1 erik user 1046117 Mar 13 19:12 js-1.5-rc4.tar.gz What does everyone else think? I dunno. That's awfully big. JavaScript isn't a terribly big language though, so it's possible that this includes a whole bunch of stuff (browser/DOM hooks, test suites, example code) that's not useful to us and could be eliminated. Where can we find it? Is this the Mozilla interpreter? The KDE one? Somebody elses? Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
Norman Vine wrote:
Erik Hofman writes:
Isn't there any trick with the puObject member either (I just need to
know which menu entry is causing the callback)?
why not just use use the puObject pointer
/* print the 'menu text' of calling menu entry on stdout */
void tattle_tale_cb( puObject *me)
{
printf(%s\n,me-getLegend());
/* do something useful now */
}
Ah,that seems a nice start.
Thanks.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
Curtis L. Olson wrote: I would argue that if we do embed a script interpreter it should be really small, tight, and light weight. Amen. :) It's possible that the source for the actual interpreter is much smaller than the full package, though. JavaScript implementations are likely to be aimed at browsers, and the browser environment is a notoriously fat interface. It's a pity that there aren't any good, small, tight scripting languages left. Lots of languages *start* small and tight, but rapidly expand. Python did this -- version 1 was small and tight, version 2 is a monster. Perl is about to do it for the Nth time. I tremble in fear everytime Larry releases another apocalypse. Perl 6 is just out of control at this point. There are (duck) scheme variants like guile that are still small, though. Also, there's Lua. Lua is very small and very tight (only a few tens of kilobytes of code). It's also very odd, with strange syntax for stuff that the rest of the world has standardized on long ago. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
Andy Ross wrote: David Megginson wrote: Erik Hofman writes: -rw-r--r--1 erik user 648823 May 12 2001 js-1.4-2.tar.gz -rw-r--r--1 erik user 1046117 Mar 13 19:12 js-1.5-rc4.tar.gz What does everyone else think? I dunno. That's awfully big. JavaScript isn't a terribly big language though, so it's possible that this includes a whole bunch of stuff (browser/DOM hooks, test suites, example code) that's not useful to us and could be eliminated. Where can we find it? Is this the Mozilla interpreter? The KDE one? Somebody elses? http://www.mozilla.org/js/spidermonkey/ When removing unnessercery code I get: -rw-r--r--1 erik user 660930 Jun 27 19:05 src.tgz Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
David Megginson wrote: Erik Hofman writes: -rw-r--r--1 erik user 648823 May 12 2001 js-1.4-2.tar.gz -rw-r--r--1 erik user 1046117 Mar 13 19:12 js-1.5-rc4.tar.gz Does anyone know of a smaller ECMAScript implementation? We might want to go for js-1.3 then: -rw-rw-r-- 1 22 22481442 Sep 1 1998 js-1.3-1.tar.gz JavaScript 1.3 is fully compatible with ECMA-262, Edition 1. JavaScript 1.3 resolved the inconsistencies that JavaScript 1.2 had with ECMA-262, while keeping all the additional features of JavaScript 1.2 except == and !=, which were changed to conform with ECMA-262. JavaScript 1.4 is fully compatible with ECMA-262, Edition 1. The third version of the ECMA specification was not finalized when JavaScript 1.4 was released. JavaScript 1.5 is fully compatible with ECMA-262, Edition 3. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
Curtis L. Olson writes: I would argue that if we do embed a script interpreter it should be really small, tight, and light weight. 1Mb of compressed source seems excessive ... this is almost exactly the same size as the entire flightgear source, so we'd be roughly doubling the size of our source and the time to compile ... Point well taken. I'd like to see a small interpreter, perhaps 100K-200K source -- I'm sure it could be done, even for ECMAScript. Also we need to consider that each new dependency we add significantly increases the barrier for new developers to get all the pieces in place to build their own executable. I agree strongly, but we do need scripting to take FlightGear to the next level. We've been abusing the XML a little, as Norm has often graciously pointed out -- XML should be used for representing state (data tables, etc.), and scripting languages should be used for representing data. It is just as stupid to use XML for procedural stuff for-loop start-value3/start-value end-value18/end-value increment1/increment action ... /action /for-loop as it is to use a programming language for declarative stuff inst = new Instrument; inst.addLayer(new Layer); inst.getLayer(0).setTexture(...) In light of this, having an external scripting system that uses a network interface becomes attractive. However, there can be performance issues with that which might be addressed by a built in script engine. It's also a dependency problem, again. Once FlightGear starts to depend on scripting, users are going to have to have a Java, Perl, or Python environment set up on their computers (or an accessible computer, anyway), and that raises a barrier for new users, which is even worse than a barrier for new developers. Of the three, Java is the most likely to be already installed on a user's machine, but even then they probably have no idea how to use it. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
Erik Hofman writes: We might want to go for js-1.3 then: -rw-rw-r-- 1 22 22481442 Sep 1 1998 js-1.3-1.tar.gz Could we trim that down by another 75% or so? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
David Megginson wrote:
Erik Hofman writes:
-rw-r--r--1 erik user 648823 May 12 2001 js-1.4-2.tar.gz
-rw-r--r--1 erik user 1046117 Mar 13 19:12 js-1.5-rc4.tar.gz
What does everyone else think? Should this be bundled unpacked in the
SimGear source tree and built automatically (as with expat, our XML
parser), bundled as an archive so that users can build it if they
don't already have it installed (as with metakit and zlib), or left as
an external, optional extra? I'd like to embed an interpreter in
FlightGear, and ECMAScript is an excellent candidate language, but it
would be nice if the interpreter were a lot smaller.
Erik -- what do your bindings look like?
You mean the code to bind a JavaScript function to a C function:
static JSBool
_fgs_set(JSContext *cx, JSObject *obj, uintN argc, jsval *argv, jsval *rval)
{
const char *node, *str;
if (argc != 2)
return JS_FALSE;
if ((node = JS_GetStringBytes(JS_ValueToString(cx, argv[0]))) == NULL)
return JS_FALSE;
if ((str = JS_GetStringBytes(JS_ValueToString(cx, argv[1]))) == NULL)
return JS_FALSE;
_fgs_root_node-setStringValue(node, str);
*rval = BOOLEAN_TO_JSVAL( true );
return JS_TRUE;
}
or do you mean:
fgfs.set
fgfs.setBoolean
fgfs.get
fgfs.getBoolean
etc.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
David Megginson wrote: Erik Hofman writes: We might want to go for js-1.3 then: -rw-rw-r-- 1 22 22481442 Sep 1 1998 js-1.3-1.tar.gz Could we trim that down by another 75% or so? A quck look reveiled: -rw-r--r--1 erik user 338033 Jun 27 21:03 src.tgz Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JavaScript!
Erik Hofman writes:
David Megginson wrote:
Erik -- what do your bindings look like?
You mean the code to bind a JavaScript function to a C function:
static JSBool
_fgs_set(JSContext *cx, JSObject *obj, uintN argc, jsval
*argv, jsval *rval)
{
const char *node, *str;
if (argc != 2)
return JS_FALSE;
if ((node = JS_GetStringBytes(JS_ValueToString(cx,
argv[0]))) == NULL)
return JS_FALSE;
if ((str = JS_GetStringBytes(JS_ValueToString(cx,
argv[1]))) == NULL)
return JS_FALSE;
_fgs_root_node-setStringValue(node, str);
*rval = BOOLEAN_TO_JSVAL( true );
return JS_TRUE;
}
or do you mean:
fgfs.set
fgfs.setBoolean
fgfs.get
fgfs.getBoolean
Eric
Have you looked at SWIG ???
The reason I ask is this looks nearly identical to the code SWIG
would output for JavaScript from a SWIG interface file for
fgSetString(char * , char *)
The beauty of using SWIG is that the same interface file would support
JavaScript, Perl, Python, TCL-Tk, Mzscheme, guile ... giving a choice
of which Interpreter was compiled in.
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
Erik Hofman writes: or do you mean: fgfs.set fgfs.setBoolean fgfs.get fgfs.getBoolean Yes, that stuff. It looks reasonable. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
