Best Scripting Language for Embedded Work?

[Christian Gollwitzer]

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