Gui application for embedded system

On 2014-07-11, Mel Wilson <mwilson@the-wire.com> wrote:
> On Fri, 11 Jul 2014 14:13:36 +0000, Grant Edwards wrote:
>> On 2014-07-10, Les Cargill <lcargill99@comcast.com> wrote:
>
>>> Fair enough. The terminology gets a bit fuzzy anyway - what I've seen
>>> of Python in scripting, it's used in pipes under BASH or the like.
>> 
>> I'm sorry, I don't know how a language is "used in pipes under BASH".
>> Almost all of the programs I see connected together with pipes under
>> bash are written in C.
>> 
>> Does that mean C is a "scripting language"?
>
> Nothing much to it.  The pipe works by patching the STDOUT from the first 
> program into the STDIN of the second.  As long as the programs work with 
> the POSIX conventions of STDIN and STDOUT it's not language-centric at 
> all.

Yep, I know what a pipe is.  I've been writing shell scripts for 30+
years.  What I didn't understand was when you described Python as a
programming language that is "used in pipes under BASH".

-- 
Grant Edwards               grant.b.edwards        Yow! I think I am an
                                  at               overnight sensation right
                              gmail.com            now!!

Grant Edwards wrote:
> On 2014-07-11, Mel Wilson <mwilson@the-wire.com> wrote:
>> On Fri, 11 Jul 2014 14:13:36 +0000, Grant Edwards wrote:
>>> On 2014-07-10, Les Cargill <lcargill99@comcast.com> wrote:
>>
>>>> Fair enough. The terminology gets a bit fuzzy anyway - what I've seen
>>>> of Python in scripting, it's used in pipes under BASH or the like.
>>>
>>> I'm sorry, I don't know how a language is "used in pipes under BASH".
>>> Almost all of the programs I see connected together with pipes under
>>> bash are written in C.
>>>
>>> Does that mean C is a "scripting language"?
>>
>> Nothing much to it.  The pipe works by patching the STDOUT from the first
>> program into the STDIN of the second.  As long as the programs work with
>> the POSIX conventions of STDIN and STDOUT it's not language-centric at
>> all.
>
> Yep, I know what a pipe is.  I've been writing shell scripts for 30+
> years.  What I didn't understand was when you described Python as a
> programming language that is "used in pipes under BASH".
>

My meaning was that when Python is apparently used in scripting, it's
not the scripting language; filters are written with it and then a shell 
is used to pipe things together.

-- 
Les Cargill

Grant Edwards wrote:
> On 2014-07-10, Les Cargill <lcargill99@comcast.com> wrote:
>> Grant Edwards wrote:
>>> On 2014-07-10, Les Cargill <lcargill99@comcast.com> wrote:
>>>
>>>> Dunno about 'hung up on', but not including async I/O as a first
>>>> class ... thing ( object? service? doohickey? ) in a scripting
>>>> language rather misses the classical justification for having a
>>>> scripting language in the first place.
>>>>
>>>> Scripting languages are for automating things you'd otherwise have to
>>>> type for. Since we're in an embedded newsgroup, I'm rather shocked
>>>> that this isn't the sort of thing practitioners use daily.
>>>
>>> Python isn't a "scripting language".  It's a general-purpose
>>> programming language like Java, Pascal, etc.
>>>
>>
>> Interpreted language, then -
>
> It's not interpreted either.  It's generally compiled into byte-code
> that is then run on a VM Just like Java is (mostly), and like Pascal
> often was back in the day.

True enough, although I'd still call that an implementation detail of 
"interpreted".

  The most commonly used Python compiler
> generates byte-code for a "native" Python VM, but there also Python
> compilers that generate byte-code for the Java VM and (IIRC) one or
> two others.
>
>> I probably made the error of merging those two out of habit over the
>> last 20 years or so.
>>
>> Pascal and Java can be used to generate native machine code. SFAIK,
>> Python cannot.
>
> You're right, the current native-code implementations of Python are
> still incomplete.  Due to the dynamic typing, generating purely native
> code is difficult.
>

NO doubt, and VM are frequently good enough these days.

>>> Some people use it for scrpting stuff that they would otherwise do at
>>> a shell prompt, but that's not what Python was intended for, nor is it
>>> optimized for that.
>>
>> Fair enough. The terminology gets a bit fuzzy anyway - what I've seen
>> of Python in scripting, it's used in pipes under BASH or the like.
>
> I'm sorry, I don't know how a language is "used in pipes under BASH".

cat file | python myScript.py > zee

> Almost all of the programs I see connected together with pipes under
> bash are written in C.
>

That's because an awful lot of software was written in 'C'.

> Does that mean C is a "scripting language"?
>

No. My point is that it's not the shell, like bash.

-- 
Les Cargill

On 12/07/14 04:24, Les Cargill wrote:
> Grant Edwards wrote:
>> On 2014-07-11, Mel Wilson <mwilson@the-wire.com> wrote:
>>> On Fri, 11 Jul 2014 14:13:36 +0000, Grant Edwards wrote:
>>>> On 2014-07-10, Les Cargill <lcargill99@comcast.com> wrote:
>>>
>>>>> Fair enough. The terminology gets a bit fuzzy anyway - what I've seen
>>>>> of Python in scripting, it's used in pipes under BASH or the like.
>>>>
>>>> I'm sorry, I don't know how a language is "used in pipes under BASH".
>>>> Almost all of the programs I see connected together with pipes under
>>>> bash are written in C.
>>>>
>>>> Does that mean C is a "scripting language"?
>>>
>>> Nothing much to it.  The pipe works by patching the STDOUT from the
>>> first
>>> program into the STDIN of the second.  As long as the programs work with
>>> the POSIX conventions of STDIN and STDOUT it's not language-centric at
>>> all.
>>
>> Yep, I know what a pipe is.  I've been writing shell scripts for 30+
>> years.  What I didn't understand was when you described Python as a
>> programming language that is "used in pipes under BASH".
>>
> 
> My meaning was that when Python is apparently used in scripting, it's
> not the scripting language; filters are written with it and then a shell
> is used to pipe things together.
> 

There is a saying - when you are in a hole, stop digging.

Python is used for an enormous range of tasks.  That includes websites
and web frameworks, general applications, scientific applications,
games, test systems, embedded development tools, systems software,
utilities, scripts, gui programs, cli programs, and pretty much anything
else you can think of except small embedded systems (there are limited
versions of python available for pretty small processors, but these are
mostly experimental projects).

Python is a byte-compiled language, not an interpreted language (though
the byte-compiler is built into the standard virtual machine).  There
are byte-compilers for Python to VM's other than the standard one
(cpython), such as for .net or java VM's.  There are JIT compilers such
as pypy, which can result in speeds comparable to typical C code for
some types of tasks (though usually Python code on a standard VM is
significantly slower than compiled C).

Of the roughly 2500 non-link files in my /usr/bin directory, 200 are
python files.  These are not "filters" - in fact, I don't know of any
that are filters.  They cover a variety of tasks - one of which is the
"yum" package manager for Fedora/Red Hat.

I know (from your many posts over the years) you are experienced and
knowledgeable in many things in the programming world, but Python is
apparently not something you are familiar with.  You would be better off
listening to experienced Python users like Grant than continuing to
demonstrate your lack of experience here.  Even better, you might like
to try to learn Python yourself.

David Brown wrote:
<snip>
>
> I know (from your many posts over the years) you are experienced and
> knowledgeable in many things in the programming world, but Python is
> apparently not something you are familiar with.

Of course - I believe I stipulated that up front.

> You would be better off
> listening to experienced Python users like Grant than continuing to
> demonstrate your lack of experience here.  Even better, you might like
> to try to learn Python yourself.
>

I've tried it. Meh. All I can say is that it is better than Perl. I'm
not trying to give Grant or anyone a rash here; at best I could hope
somebody would provide a nice reason to consider investing more in the
language other than "everybody's using it."

To clarify:
	- Tcl provides an event system by default. Python
	  doesn't. There is a package.
	- Tcl provides event-driven I/O by default. Python doesn't.
	  There is a package.
	- Freewrap/Teapot provide mechanisms for wrapping or packaging
   	  code for distribution without installing Tcl. Python
           doesn't.
	

-- 
Les Cargill

Les Cargill <lcargill99@comcast.com> writes:
> 	- Tcl provides an event system by default. Python
> 	  doesn't. There is a package.
> 	- Tcl provides event-driven I/O by default. Python doesn't.

I'm not sure what you mean by this, but Python (at least on Linux)
supports select and epoll, and there are some event driven i/o modules
like asyncore or the fancier Twisted that have been around for a while.
I haven't tried the new coroutine-based asyncio module but it looks
interesting.  I've always just use threads, whose dangers are overhyped
if you know what you're doing and program conservatively.

> 	- Freewrap/Teapot provide mechanisms for wrapping or packaging
>   	  code for distribution without installing Tcl. Python
>           doesn't.

For Windows there is py2exe.org, and InnoSetup if you want a fancy
InstalShield-like experience.  Most Linux systems have Python already
available so there's less need for something like that, and people just
use standard Linux packaging tools.

Paul Rubin wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> 	- Tcl provides an event system by default. Python
>> 	  doesn't. There is a package.
>> 	- Tcl provides event-driven I/O by default. Python doesn't.
>
> I'm not sure what you mean by this, but Python (at least on Linux)
> supports select and epoll, and there are some event driven i/o modules
> like asyncore or the fancier Twisted that have been around for a while.

Agreed. Since Ptyhon is doubtless built on 'C', I'd
be surprised that select() and epoll() aren't supported for Windows.

> I haven't tried the new coroutine-based asyncio module but it looks
> interesting.  I've always just use threads, whose dangers are overhyped
> if you know what you're doing and program conservatively.
>

Sure. I appear to be having some difficulty in explaining why I prefer
that the interpreter itself be built around event-driven-ness but
that's okay. It's always possible to use the dispatch
pattern but I've gotten used to it being the default state
of things.

I've been repetitive about this because I sometimes get to evangelize
in real  life about testing frameworks for embedded stuff. When the
accusations of failure get to flying :) it's darned handy to
have a test framework that demonstrates that the embedded side works,
or one that exposes the defects that are there.

Threads are absolutely no problem but it's nicer to have options.


>> 	- Freewrap/Teapot provide mechanisms for wrapping or packaging
>>    	  code for distribution without installing Tcl. Python
>>            doesn't.
>
> For Windows there is py2exe.org, and InnoSetup if you want a fancy
> InstalShield-like experience.  Most Linux systems have Python already
> available so there's less need for something like that, and people just
> use standard Linux packaging tools.
>

Yep; Windows is a pain with this issue.

One thing I've clarified with this thread ( thanks, guys ) is that
Python is closer to a replacement for 'C' than other roles I was
trying to hammer it into.

-- 
Les Cargill

Les Cargill <lcargill99@comcast.com> writes:
> Threads are absolutely no problem but it's nicer to have options.

The Python community seems to mostly hate threads and prefer Twisted, so
I'm in a bit of a minority.  I found Twisted confusing and too Java-like
the one time I tried to use it.  It has better performance than threads
so I've figured I'd have to get familiar with it someday, but have
avoided it so far and now I have hopes that the new asyncio library may
make it unnecessary.  There are also alternative languages like Erlang,
Haskell, and Go, that have high-performance concurrency that looks like
threads/processes to the user but are implement as async under the hood.

> I've been repetitive about this because I sometimes get to evangelize
> in real  life about testing frameworks for embedded stuff. 

I'm pretty interested in this and would be happy to hear about any
recommendations you might have.

> One thing I've clarified with this thread ( thanks, guys ) is that
> Python is closer to a replacement for 'C' than other roles I was
> trying to hammer it into.

Yeah, most of my stuff in the past decade or so has been in Python.
When I write anything in C these days, as I've written elsewhere it
feels like a "back to nature" experience.

Paul Rubin wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> Threads are absolutely no problem but it's nicer to have options.
>
> The Python community seems to mostly hate threads and prefer Twisted, so
> I'm in a bit of a minority.  I found Twisted confusing and too Java-like
> the one time I tried to use it.  It has better performance than threads
> so I've figured I'd have to get familiar with it someday, but have
> avoided it so far and now I have hopes that the new asyncio library may
> make it unnecessary.


Huh. Well, I'd expect them to catch up. Thread aren't *bad*; thy're
better when the system is  run-to-completion, which isn't common these
days.

>  There are also alternative languages like Erlang,
> Haskell, and Go, that have high-performance concurrency that looks like
> threads/processes to the user but are implement as async under the hood.
>

Those are on the list too, but it's a real Tower of Babel out there :)

>> I've been repetitive about this because I sometimes get to evangelize
>> in real  life about testing frameworks for embedded stuff.
>
> I'm pretty interested in this and would be happy to hear about any
> recommendations you might have.
>

It's all good, really. The main thing will be what you're comfortable 
with and you won't know that until you try.

I've glommed onto Tcl because you just open a serial port or a socket 
and whale away. If you have, say, a USB device, I'll write 'C' to
operate it and load up a pipe in Tcl to drive it.

This goes back 20 years to a hard-to-find bug on a relatively simple
system where we actually built an exhaustive test jig that got run
continuously for days every release. Put in instrumentation at every
branch point and worked on the jig until we proved we executed every 
path. We generated all the permutations of events and made that into a 
"script" that would run repeatedly.

There are prepared frameworks but they can be tricky and they're 
targeted at bespoke test as a job function, but at developer testing.

This is harder for things that implement, say, layer 1 comms stuff. But
those are often tractable by connecting to both ends and writing pattern 
generators, or setting up and tearing  down cross connects. If you can 
buy COTS testers it's arguably better, but sometimes you can't.

>> One thing I've clarified with this thread ( thanks, guys ) is that
>> Python is closer to a replacement for 'C' than other roles I was
>> trying to hammer it into.
>
> Yeah, most of my stuff in the past decade or so has been in Python.
> When I write anything in C these days, as I've written elsewhere it
> feels like a "back to nature" experience.
>

For anything complicated, I end up writing C++ wrappers for freely
available 'C' libraries, generally. This is domain-dependent, of course. 
This is purely to make the programs shorter; it's
not very "OO". I did this for the leverage, not the methodology.

FFTW and libsndfile both got this treatment.

Since my day job is embedded, I don't use a whole lot of Python. Perhaps
that will change.


-- 
Les Cargill

Les Cargill <lcargill99@comcast.com> writes:
> Since my day job is embedded, I don't use a whole lot of
> Python. Perhaps that will change.

Python is great on the ARM/Linux class of embedded system.  It's not
usable for small MCU's and probably not so great for bare metal even
with larger processors.  I've heard it works ok with around 2 meg of
ram, though I haven't personally run it in anything that small.

I see someone has uploaded Hedgehog Lisp to github:

  https://github.com/sbp/hedgehog

This is an embedded, functional Lisp dialect with offline compilation,
whose runtime is around 20 kbytes and which (given a C compiler) should
be able to run in bare metal and is supposedly ok with around 256K of
ram.  It uses a semispace GC and maybe the footprint could be decreased
further by switching to mark-sweep.  I've spent a while studying it and
playing with it, though I never used it for anything "real".