Re: more script engines
If you are trying to appeal to casual developers, your two real options are Pymite (Python) and eLua. Both of
these are actively maintained, have a solid user community and overall plenty of support. They are also
both on the large and hungry side. PyMite is GPL, eLua uses the MIT license.
If you are looking for a 'scripting' language for a team of more dedicated developers, there are better options.
First, NuttX already includes the excellent Ficl Forth engine. If space is an issue and you know or are
prepared to learn Forth, go no further. The code density you can achieve with Forth is quite acceptable,
and Ficl performs well on small 32-bit systems. The learning curve is, however, very steep. If you're
serious, or if you don't plan to write a whole lot of script code, this is not a bad choice.
If you are looking for something that's an easier bridge from the C languages, then there are a number of
well-developed small scripting languages to choose from. Rather than write a review here, I'm just going
to link to an excellent performance comparison of most of the major contenders.
If I was starting from scratch with a small team, I'd be choosing between Pawn and Squirrel, based on whether
speed or language features were more important.
On Apr 14, 2012, at 11:04 AM, Meier Lorenz wrote:
> Hi Antti,
> This might be a stupid question, but did you consider to go for a maintained language and interpreter, such
as Python and ? The benefit would be that others (like e.g. our project) might feel compelled to support
this in the long term and to provide testing and bugfixes.
> The project seems pretty active and after an evaluation of a number of interpreter languages I found
Python to suit the embedded needs best, while still being close to a major language (Python).
>  http://code.google.com/p/python-on-a-chip/
> Am 14.04.2012 um 19:56 schrieb Gregory N:
> Hi, Antti,
>> it seems pico c is stable but not much changing any more, it is claimed that its FROZEN no more features
> I see from browsing the source that it is not large. If it is an abandoned project, then it might make sense to
move a snapshot into the NuttX source tree.
> Communicating with the project owners to see if they have any preference might be a good thing, however. My
only concern is in bringing more unsupported and unsupportable code into NuttX.
>> yes, /apps/interpreters sure..
> There are a few of options:
> 1. Fork a new copy of Pico C at apps/interpreters/pico-c.
> 2. Put in installation hooks in apps/interpreters/pico-c as was done for apps/interpreters/ficl
> 3. Another is to put a tar'ed, versioned snapshot in misc with patchfiles and installation scripts. As was
done for the Pascal p-code interpreter.
> It really depends upon how much ownership you want to take for the code. I will never use so I won't be
supporting it. If in the future it breaks, I will probably just remove it from NuttX. Do you plan to support
it for all time? If so, why don't you just take over the Pico C project.
> There are a couple of reasons that I broke off the apps/ code from the RTOS in 6.0. One is that the hodge podge
of random applications was creating a messy RTOS source tree (the nuttx source tree is now pretty clean;
the apps tree is messy but at least small). Another is that projects really need their one
application-specific environment and the apps/ directory serves as a model (although people don't use
it that way).
> But I wonder what the long range future of the apps directory is? I am thinking that it is not good because it
still just a collection of random things, some completely unsupported, and that situation can only get worse.
>> I have been thinking how to properly execute pascal per scripts from NSH, I have sue
>> minimal pex command added, but i should add probably option to set stack sizes and
>> what also very important forward command line params to the pascal script, here I am
>> not sure how this would work, i guess its doable.
> You made this as a NSH built-in application, right? Then you can pass anything to the pex command on the
command line. Use argc, argv, and getopt() to parse the command line and define options for stack sizes,
> Yahoo! Groups Links
Yahoo! Groups Links
<*> To visit your group on the web, go to:
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to: