Best Scripting Language for Embedded Work?
Christian Gollwitzer
auriocus at gmx.de
Fri Jul 12 02:52:27 EDT 2013
Hi David,
Am 12.07.13 03:18, schrieb David T. Ashley:
> On Wed, 10 Jul 2013 09:03:54 +0200, Christian Gollwitzer
> <auriocus at 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
More information about the Python-list
mailing list