Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #50289 > unrolled thread

Best Scripting Language for Embedded Work?

Back to article view | Back to comp.lang.python

Contents

  Best Scripting Language for Embedded Work? David T. Ashley <dashley@gmail.com> - 2013-07-09 21:29 -0400
    Re: Best Scripting Language for Embedded Work? Dave Angel <davea@davea.name> - 2013-07-09 21:44 -0400
      Re: Best Scripting Language for Embedded Work? David T. Ashley <dashley@gmail.com> - 2013-07-11 21:14 -0400
    Re: Best Scripting Language for Embedded Work? Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2013-07-10 08:41 +0200
    Re: Best Scripting Language for Embedded Work? Christian Gollwitzer <auriocus@gmx.de> - 2013-07-10 09:03 +0200
      Re: Best Scripting Language for Embedded Work? Stefan Behnel <stefan_ml@behnel.de> - 2013-07-10 09:15 +0200
      Re: Best Scripting Language for Embedded Work? Christian Gollwitzer <auriocus@gmx.de> - 2013-07-12 08:52 +0200
    Re: Best Scripting Language for Embedded Work? Grant Edwards <invalid@invalid.invalid> - 2013-07-10 14:15 +0000
    Re: Best Scripting Language for Embedded Work? Johann Hibschman <jhibschman@gmail.com> - 2013-07-10 14:38 -0500
      Re: Best Scripting Language for Embedded Work? David T. Ashley <dashley@gmail.com> - 2013-07-11 21:19 -0400
        Re: Best Scripting Language for Embedded Work? Stefan Behnel <stefan_ml@behnel.de> - 2013-07-12 06:17 +0200

#50289 — Best Scripting Language for Embedded Work?

We develop embedded software for 32-bit micros using Windows as the
development platform.

We are seeking a general purpose scripting language to automate
certain tasks, like cleaning out certain directories of certain types
of files in preparation for ZIP'ing, generating certain source files
automatically, etc.

Selection criteria:

a)Should be able to compile the script interpreter as a monolithic
executable (no .DLL dependencies, etc.) for easy versioning and
distribution of the script interpreter.  (Note that I'm not asking
that the script be a single executable, just the interpreter.  To run
a script you'd need both the script and the interpreter.  The script
would be a text file, and the interpreter would be a single .EXE.)

b)Should be extensible, in that one could add commands or library
functions to the script interpreter in C (for efficiency), and the
whole script interpreter could again consist of a single executable
with no other dependencies.  (Note that I'm not asking that the script
be a single executable, just the interpreter.  To run a script you'd
need both the script and the interpreter.  The script would be a text
file, and the interpreter would be a single .EXE.)

c)Should be able to spawn compilers and capture the output, do file
I/O, and all the other minor expected stuff.

d)Graphical capability would be nice.

I know that Tcl/Tk would do all of the above, but what about Python?
Any other alternatives?

Thanks, Dave Ashley

[toc] | [next] | [standalone]

#50290

On 07/09/2013 09:29 PM, David T. Ashley wrote:
> We develop embedded software for 32-bit micros using Windows as the
> development platform.
>
> We are seeking a general purpose scripting language to automate
> certain tasks, like cleaning out certain directories of certain types
> of files in preparation for ZIP'ing, generating certain source files
> automatically, etc.
>
> Selection criteria:
>
> a)Should be able to compile the script interpreter as a monolithic
> executable (no .DLL dependencies, etc.) for easy versioning and
> distribution of the script interpreter.

Oh, I thought you were going to run this on Windows.  You're just 
developing it on Windows, and you want to cross-compile to target some 
other platform?  Which?


>  (Note that I'm not asking
> that the script be a single executable, just the interpreter.  To run
> a script you'd need both the script and the interpreter.  The script
> would be a text file, and the interpreter would be a single .EXE.)

If you're also constraining your "program" to a single text file, you 
don't want Python.  It uses modules, imported from your script to do 
much of the work.

>
> b)Should be extensible, in that one could add commands or library
> functions to the script interpreter in C (for efficiency), and the
> whole script interpreter could again consist of a single executable
> with no other dependencies.  (Note that I'm not asking that the script
> be a single executable, just the interpreter.  To run a script you'd
> need both the script and the interpreter.  The script would be a text
> file, and the interpreter would be a single .EXE.)

And that's supposed to HELP efficiency??

>
> c)Should be able to spawn compilers and capture the output, do file
> I/O, and all the other minor expected stuff.
>
> d)Graphical capability would be nice.
>
> I know that Tcl/Tk would do all of the above,

I doubt it.

> but what about Python?
> Any other alternatives?



-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#50480

On Tue, 09 Jul 2013 21:44:48 -0400, Dave Angel <davea@davea.name>
wrote:

>On 07/09/2013 09:29 PM, David T. Ashley wrote:
>> We develop embedded software for 32-bit micros using Windows as the
>> development platform.
>>
>> We are seeking a general purpose scripting language to automate
>> certain tasks, like cleaning out certain directories of certain types
>> of files in preparation for ZIP'ing, generating certain source files
>> automatically, etc.
>>
>> Selection criteria:
>>
>> a)Should be able to compile the script interpreter as a monolithic
>> executable (no .DLL dependencies, etc.) for easy versioning and
>> distribution of the script interpreter.
>
>Oh, I thought you were going to run this on Windows.  You're just 
>developing it on Windows, and you want to cross-compile to target some 
>other platform?  Which?

Sorry, I wasn't very complete.

The scripts would run on Windows 7 only, but because they may generate
part of the source code for the embedded system, we have to be careful
about versioning the interpreter, and a monolithic executable makes
that simpler.

>>  (Note that I'm not asking
>> that the script be a single executable, just the interpreter.  To run
>> a script you'd need both the script and the interpreter.  The script
>> would be a text file, and the interpreter would be a single .EXE.)
>
>If you're also constraining your "program" to a single text file, you 
>don't want Python.  It uses modules, imported from your script to do 
>much of the work.
>
>>
>> b)Should be extensible, in that one could add commands or library
>> functions to the script interpreter in C (for efficiency), and the
>> whole script interpreter could again consist of a single executable
>> with no other dependencies.  (Note that I'm not asking that the script
>> be a single executable, just the interpreter.  To run a script you'd
>> need both the script and the interpreter.  The script would be a text
>> file, and the interpreter would be a single .EXE.)
>
>And that's supposed to HELP efficiency??

Did I ever claim I wanted efficiency?

>> c)Should be able to spawn compilers and capture the output, do file
>> I/O, and all the other minor expected stuff.
>>
>> d)Graphical capability would be nice.
>>
>> I know that Tcl/Tk would do all of the above,

I was able to do this with Tcl/Tk years ago.

>I doubt it.
>
>> but what about Python?
>> Any other alternatives?

[toc] | [prev] | [next] | [standalone]

#50300

David T. Ashley <dashley@gmail.com> writes:

> We develop embedded software for 32-bit micros using Windows as the
> development platform.

I'll mostly ignore the "Windows" qualifier. If you're stuck with Windows
CE or similar, then ask them what they suggest. If you're developing on
Windows and deploy on something else (typically, some form of linux),
then, well, think again.

> We are seeking a general purpose scripting language to automate
> certain tasks, like cleaning out certain directories of certain types
> of files in preparation for ZIP'ing, generating certain source files
> automatically, etc.

That's exactly what "shells" are for. They are basically command
interpreters providing a nice interface to various system utilities.
Busybox is a variant where utilities are actually compiled in, and where
you can compile your own stuff in as well. See
http://en.wikipedia.org/wiki/Busybox

> a)Should be able to compile the script interpreter as a monolithic
> executable (no .DLL dependencies, etc.) for easy versioning and
> distribution of the script interpreter.

A fairly common requirement for shells.

> b)Should be extensible, in that one could add commands or library
> functions to the script interpreter in C (for efficiency), and the
> whole script interpreter could again consist of a single executable
> with no other dependencies.

It looks like busybox is able to do this (the faq is fairly precise in
implementation details---I've never done this but it looks kind of
trivial).

> c)Should be able to spawn compilers and capture the output, do file
> I/O, and all the other minor expected stuff.

Trivial for any shell, and probably for any scripting language.

> d)Graphical capability would be nice.

That's a large can of worms. I don't know any small, self-contained
interpreter that includes a full-featured GUI framework. These things
usually end up in shared libs, which you explicitely want to avoid...

> I know that Tcl/Tk would do all of the above, but what about Python?
> Any other alternatives?

Most scripting languages have evolved way beyond "scripting" tasks, and
usually rely on a fairly extensive set of libraries (either shared
libraries or collection of modules). I haven't looked at tcl/tk since I
know python, but they can probable be classified in the same category.
Of course, expect python supporters to... support python (which, btw,
interfaces with tk).

Another contender is lua, which has a good reputation regarding
embeddability.

The answer really depends on your use case. I think you will be better
off if you keep the GUI aspect separated from the rest. Here is
stackoverflow entry discussing the use guis for (unix) shell scripts:

http://stackoverflow.com/questions/928019/how-to-make-a-gui-for-bash-scripts

(via google "linux shell script gui").

-- Alain.

[toc] | [prev] | [next] | [standalone]

#50302

Hi David,

you have multi-posted this to comp.lang.tcl. Please don't do that - use 
crossposting and a proper follow-up (as I did now)

Am 10.07.13 03:29, schrieb David T. Ashley:
> We develop embedded software for 32-bit micros using Windows as the
> development platform.

Robert's answer made me hesitate - what exactly is your platform? Are 
you writing the scripts for the embedded platform, or for Windows, or 
does the embedded controller run Windows RT or something like this?

> We are seeking a general purpose scripting language to automate
> certain tasks, like cleaning out certain directories of certain types
> of files in preparation for ZIP'ing, generating certain source files
> automatically, etc.
>
> Selection criteria:
>
> a)Should be able to compile the script interpreter as a monolithic
> executable (no .DLL dependencies, etc.) for easy versioning and
> distribution of the script interpreter.  (Note that I'm not asking
> that the script be a single executable, just the interpreter.  To run
> a script you'd need both the script and the interpreter.  The script
> would be a text file, and the interpreter would be a single .EXE.)

You are referring to tclkits. Yes, it's indeed possible to compile Tcl 
into a statically linked binary, and C extension packages can be 
statically linked, too. But tclkits are cheating: There are some files 
like the standard library (i.e. init.tcl, the clock command etc., 
unicode encondings...) which are packed into a database and attached to 
the tclkit. The tclkit then opens itself via the file system to read 
these files. I don't know if this is possible in a typical embedded 
system. If you are really talking about Windows, no issue.

Python has similar capabilities, look for pyinstaller or py2exe.

> b)Should be extensible, in that one could add commands or library
> functions to the script interpreter in C (for efficiency), and the
> whole script interpreter could again consist of a single executable
> with no other dependencies.  (Note that I'm not asking that the script
> be a single executable, just the interpreter.  To run a script you'd
> need both the script and the interpreter.  The script would be a text
> file, and the interpreter would be a single .EXE.)

That is possible in Tcl using static packages. In Python I don't know, 
but I think it should be possible.

> c)Should be able to spawn compilers and capture the output, do file
> I/O, and all the other minor expected stuff.

no real issue
> d)Graphical capability would be nice.

For GUI Python relies on either Tcl/Tk, wxwidgets, QT, GTK... I think it 
is possible to assemble these into a packaged binary, too. However it 
will be a rather large thing in the end.

> I know that Tcl/Tk would do all of the above, but what about Python?
> Any other alternatives?

I think Tcl/Tk is a really good match, especially if you are trying to 
do GUI, which is very easy there. Also most scripting stuff is available 
out of the box. Another option might be Lua

http://www.lua.org/

Very compact (a static binary is about ~200K), clean synatx, relatively 
fast. OTOH, the standard library is of course not so extensive as for 
Tcl or Python.

Bash is also an option, because it is some kind of standard for 
scripting. But on Windows it seems alien and you'd need something like 
MobaXTerm to get it into a single file.

	Christian

[toc] | [prev] | [next] | [standalone]

#50303

Christian Gollwitzer, 10.07.2013 09:03:
> http://www.lua.org/
> 
> Very compact (a static binary is about ~200K), clean synatx, relatively
> fast. OTOH, the standard library is of course not so extensive as for Tcl
> or Python.

"not so extensive" is a rather bold understatement. ISTM that most projects
that use Lua build their own eco-system around it, or integrate Lua into
their existing eco-system, with the obvious drawbacks for code reuse across
different projects and user bases.

Stefan

[toc] | [prev] | [next] | [standalone]

#50498

Hi David,

Am 12.07.13 03:18, schrieb David T. Ashley:
> On Wed, 10 Jul 2013 09:03:54 +0200, Christian Gollwitzer
> <auriocus@gmx.de> wrote:
 >
>> Robert's answer made me hesitate - what exactly is your platform? Are
>> you writing the scripts for the embedded platform, or for Windows, or
>> does the embedded controller run Windows RT or something like this?
>
> Writing the scripts to run on Windows 7, but the scripts assist in
> building the software for an embedded system.  Because the embedded
> system may be safety-related, it makes sense to be careful about how
> the script interpreter is versioned, and a single monolithic
> executable makes this easier.

I see. In your situation, I'd also keep the sources to the interpreter 
in your backup. Who knows if you might need them to get it running on 
some future Windows system.

>>
>> Python has similar capabilities, look for pyinstaller or py2exe.
>
> Sorry, I miscommunicated.  I don't need to embed the script in the
> .EXE.  I just want the interpreter to be a single .EXE, so it is
> easier to ensure that every software developer has the same version of
> the interpreter or that we are using the correct earlier version if an
> older product needs to rebuilt in the future.

I understand. But nothing prevents you to wrap a simple script loader 
main script; something like

	execfile(argv[1])

would do it in Python. pyinstaller has a single-file wrapping mode, 
where you get the analogue of a starpack in Tcl.

But I still think Tcl/Tk is a much better fit. For one thing, 
pyinstaller makes huge executables. I did this on Linux to wrap a 
program with matplotlib and Tkinter; I ended up with ~100MB in size. 
That's because pyinstaller pulled in a lot of system libraries, among 
them QT, wxWidgets etc. Without them, the program did not run despite it 
used only Tkinter. In contrast, a starpack wish with just Tcl&Tk is 
around 2MB in size.

Second, Tcl/Tk is much nicer to use interactively. Consider an 
interactive environment, which woud not include the "ls" command. In 
Tcl, you can define

	proc ls {args} {
		if {[length $args] == 0} { set args * }
		puts [join [glob -nocomplain {*}$args] \n]
	}

and then, the following commands all work as expected

	ls
	ls *.jpg
	ls *.txt *.jpg

The analogue in Python would look like this

	import glob
	def ls(*args):
		for pat in args if len(args)>0 else ('*'):
			print '\n'.join(glob.glob(pat))

but using it is ugly and inconvenient compared to the shellish way in Tcl:

	ls()
	ls('*.txt')
	ls('*.jpg', '*.txt')

Of course this is a contrived example, because all interactive 
environments already provide ls. But I usually extend my Tcl with 
similar commands and then just use tkcon to enter them on-the-fly.

I also think that for your use case, you will not need to write C 
extensions. A standard starpack gives you many things out of the box, 
like looking into ZIP files. Even creating them is just two pages of 
code. I would suggest that you put together a couple of packages, put 
them in a lib/ folder, have your main.tcl something like

lappend auto_path [file join [file dirname [info script]] lib]
package require tkcon
tkcon show

and bake that together using sdx into a starpack. Then you have a single 
interpreter, with an interactive console, and you can extend this by Tcl 
modules and still have a single executable.

For example, you can get some inspiration from kbs.tcl, which contains a 
rather complete make system. It usually builds tclkits, but you can rip 
the build system off and write your own dependencies with it. Make a 
package out of it, and then your scripts would just package require 
make, to get things done which are best describe by a dependency graph.


	Christian

[toc] | [prev] | [next] | [standalone]

#50359

On 2013-07-10, David T  Ashley <dashley@gmail.com> wrote:

> We develop embedded software for 32-bit micros using Windows as the
> development platform.
>
> We are seeking a general purpose scripting language to automate
> certain tasks, like cleaning out certain directories of certain types
> of files in preparation for ZIP'ing, generating certain source files
> automatically, etc.

That's what a command shell is for.  Since windows doesn't come with a
real one, I'd recommend installing Cygwin and then using bash, make,
etc.

Better yet.  Abandon windows and switch to an OS environment intended 
for software development rather than generating time-wasting
power-point presentations.

-- 
Grant Edwards               grant.b.edwards        Yow! Look!  A ladder!
                                  at               Maybe it leads to heaven,
                              gmail.com            or a sandwich!

[toc] | [prev] | [next] | [standalone]

#50391

David T. Ashley <dashley@gmail.com> writes:

> We develop embedded software for 32-bit micros using Windows as the
> development platform.
...
> I know that Tcl/Tk would do all of the above, but what about Python?
> Any other alternatives?

Given that list, I'd say just use Tcl and be done.  You could force the
square peg of python into that round hole, but I doubt it'd be worth the
effort.

Cheers,
Johann

[toc] | [prev] | [next] | [standalone]

#50481

On Wed, 10 Jul 2013 14:38:51 -0500, Johann Hibschman
<jhibschman@gmail.com> wrote:

>David T. Ashley <dashley@gmail.com> writes:
>
>> We develop embedded software for 32-bit micros using Windows as the
>> development platform.
>...
>> I know that Tcl/Tk would do all of the above, but what about Python?
>> Any other alternatives?
>
>Given that list, I'd say just use Tcl and be done.  You could force the
>square peg of python into that round hole, but I doubt it'd be worth the
>effort.

I tend to agree with you.  I'm not sure how go monolithic with Python.

DTA

[toc] | [prev] | [next] | [standalone]

#50490

David T. Ashley, 12.07.2013 03:19:
> On Wed, 10 Jul 2013 14:38:51 -0500, Johann Hibschman wrote:
> 
>> David T. Ashley writes:
>>
>>> We develop embedded software for 32-bit micros using Windows as the
>>> development platform.
>> ...
>>> I know that Tcl/Tk would do all of the above, but what about Python?
>>> Any other alternatives?
>>
>> Given that list, I'd say just use Tcl and be done.  You could force the
>> square peg of python into that round hole, but I doubt it'd be worth the
>> effort.
> 
> I tend to agree with you.  I'm not sure how go monolithic with Python.

PyRun? py2exe? Just to name two.

Stefan

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web