Hi David,
Am 12.07.13 03:18, schrieb David T. Ashley:
On Wed, 10 Jul 2013 09:03:54 +0200, Christian Gollwitzer
<aurio...@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
--
http://mail.python.org/mailman/listinfo/python-list
