headers
avrbasic | 14 Apr 2012 13:17

more script engines

 

Hi

while I am old fashioned Pascal fun, having a C script engine would be very nice I think.
There is a project called "pico c" at code.google.com released under BSD license, what
would be the best way to integrate it to the nuttx?

I have not tried it yet, but the code looks pretty clean and integration should technically
be pretty easy.

they mention license as new BSD not sure if it the same as nuttx main license
so i hope it could be distributed under same license all, maybe would be best
to ask the authors of pico c first.

just peeking feedback on this idea

Antti

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Meier Lorenz | 14 Apr 2012 13:58
Picon

Re: more script engines

If you consider a general scripting language, I think it makes sense to look at "common" interpreter
languages, such as Python. This would in particular allow non-C trained people to write microcontroller
code, while embedded developers can quickly pick up the syntax (I'm not programming a lot in Python, but I
get along with short scripts).

This interpreter looks nice and shouldn't be too hard to include:

http://code.google.com/p/python-on-a-chip/

-L

Am 14.04.2012 um 13:17 schrieb avrbasic:

Hi

while I am old fashioned Pascal fun, having a C script engine would be very nice I think.
There is a project called "pico c" at code.google.com<http://code.google.com> released under BSD
license, what
would be the best way to integrate it to the nuttx?

I have not tried it yet, but the code looks pretty clean and integration should technically
be pretty easy.

they mention license as new BSD not sure if it the same as nuttx main license
so i hope it could be distributed under same license all, maybe would be best
to ask the authors of pico c first.

just peeking feedback on this idea

Antti

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest@... 
    nuttx-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply |
headers
Gregory N | 14 Apr 2012 15:23
Picon
Favicon
Gravatar

Re: more script engines

 

Hi, Antti,

> while I am old fashioned Pascal fun, having a C script engine would be very nice I think.
> There is a project called "pico c" at code.google.com released under BSD license, what
> would be the best way to integrate it to the nuttx?

Ideally, you would not modify the NuttX source tree in order to support Pico C. Rather, you should modify the Pico C source to support NuttX.

Any code that is taken from a maintained repository and moved into the NuttX repository has been orphaned from its maintainer and is destined for bit rot.

I have done that with, for example, THTTPD. But I wouldn't recommend that approach. That THTTPD port will not be supported properly in the long run.

So, my recommendation is, instead, that you contact the Pico C group and suggest to them that you would like to port Pico C to NuttX and perhaps you can get their support.

If you need hooks in NuttX (as as there are now for Ficl and pascal), then it does make sense to put those hooks in apps/interpreter/. If you cannot get support from the Pico C team, then I propose that you create a patch and we put only the patch in the NuttX source tree with instructions for obtaining Pico C.

Greg

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
avrbasic | 14 Apr 2012 16:33

Re: more script engines

 

> So, my recommendation is, instead, that you contact the Pico C group and suggest to them that you would like to port Pico C to NuttX and perhaps you can get their support.
>
> If you need hooks in NuttX (as as there are now for Ficl and pascal), then it does make sense to put those hooks in apps/interpreter/. If you cannot get support from the Pico C team, then I propose that you create a patch and we put only the patch in the NuttX source tree with instructions for obtaining Pico C.
>
> Greg
>

it seems pico c is stable but not much changing any more, it is claimed that its FROZEN no more features added, etc..

yes, /apps/interpreters sure..
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.

same things would be needed for pico c as well

pico c is nice because
1 very small much much smaller than pymite or elua
2 executes SOURCE C code no need to convert source to pseudo like the pymite requires
3 C is more common language than python or lua

Antti

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Gregory N | 14 Apr 2012 19:56
Picon
Favicon
Gravatar

Re: more script engines

 

Hi, Antti,

> it seems pico c is stable but not much changing any more, it is claimed that its FROZEN no more features added, etc..

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, and parameters.

Greg

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Meier Lorenz | 14 Apr 2012 20:04
Picon

Re: Re: more script engines

Hi Antti,

This might be a stupid question, but did you consider to go for a maintained language and interpreter, such
as Python and [1]? 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).

Cheers,
Lorenz

[1] 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
added, etc..

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,
and parameters.

Greg

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest@... 
    nuttx-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply |
headers
Michael Smith | 14 Apr 2012 20:47
Picon

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.

	http://codeplea.com/game-scripting-languages

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.

HTH.

 = Mike

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 [1]? 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).
> 
> Cheers,
> Lorenz
> 
> 
> 
> 
> [1] 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
added, etc..
> 
> 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,
and parameters.
> 
> Greg
> 
> 
> 
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest@... 
    nuttx-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply |
headers
Gregory N | 16 Apr 2012 02:24
Picon
Favicon
Gravatar

Re: more script engines

 

> If you are trying to appeal to casual developers, your two real options are Pymite (Python) and eLua.

I would think that another option to consider would be a tiny JVM. I have heard a couple mentioned recently, but I don't keep track of the stuff well enough to remember the specific names.

Googling and checking souceforge.net shows several (like http://jelatine.sourceforge.net/ -- it claims to be 32Kb). But none of those were the one I was looking for.

Greg

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Michael Smith | 16 Apr 2012 03:18
Picon

Re: more script engines

 


On Apr 15, 2012, at 5:24 PM, Gregory N wrote:

 

> If you are trying to appeal to casual developers, your two real options are Pymite (Python) and eLua.

I would think that another option to consider would be a tiny JVM. I have heard a couple mentioned recently, but I don't keep track of the stuff well enough to remember the specific names.

Googling and checking souceforge.net shows several (like http://jelatine.sourceforge.net/ -- it claims to be 32Kb). But none of those were the one I was looking for.

There are a number of compact VMs available; maybe you were looking for NanoVM?  (There is a huge list here http://en.wikipedia.org/wiki/List_of_Java_virtual_machines if someone decides this is an interesting thing to pursue).

The reason I didn't list these as mainstream contenders is that the toolchain and community support for tiny Java doesn't seem to be all that great and the ecosystem can get hea vy pretty quickly.  TinyCLR/netMF are another contender if you want to go that route.

 = Mike

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |

Gmane