Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #50498

Re: Best Scripting Language for Embedded Work?

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.

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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