Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #50498
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Newsgroups | comp.lang.tcl, comp.lang.python |
| Subject | Re: Best Scripting Language for Embedded Work? |
| Date | 2013-07-12 08:52 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <kro8ob$q6q$1@dont-email.me> (permalink) |
| References | <h7ept85p7jtc5e7j2ubl66k604d7cln3hs@4ax.com> <krj0lu$us9$1@dont-email.me> <44mut85vjpefr1o1g8l2vr9mmaqnd7q101@4ax.com> |
Cross-posted to 2 groups.
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
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web