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]
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?
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
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
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
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
Hi,
I've placed the javascript code on my website at:
http://www.a1.nl/~ehofman/fgfs/download/avascript-20020628.tar.gz
http://www.a1.nl/~ehofman/fgfs/download/fgfs_base_script-20020628.tar.gz
This is very preliminary code, but should give you a hunch.
BTW, this needs the javascript library
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]
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
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/
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
Hi,
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!
There is a small proble though, is there any way to pass an
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
___
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
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
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 --
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],
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
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
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
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)
{
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
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
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
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
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
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
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
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:
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
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/
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
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 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)
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
35 matches
Mail list logo
