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

--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to