Gui application for embedded system

On 01/07/14 03:21, Allan Herriman wrote:
> I have similar experiences, and have similar feelings for TCL.  Yet if I
> were to create a tool that needed an embeddable scripting language, I
> would consider TCL, simply because all other other tools (of the sort I
> believe you're thinking of (e.g. logic simulation and synthesis)) already
> use TCL and the users already programs in TCL and will want to reuse
> those scripts.

I note that the new Xilinx FPGA tool is based around TCL.
I haven't, yet, experimented with it sufficiently to see
whether I "approve" of the TCL!

Grant Edwards wrote:
> On 2014-06-30, Rob Gaddi <rgaddi@technologyhighland.invalid> wrote:
>> On Fri, 27 Jun 2014 14:38:04 -0400
>> Spam@ControlQ.com wrote:
>>
>>>
>>> I would suggest tcl/tk for a very rapid solution, with GUI and a flexible
>>> serial interface.  While not the latest and greatest scripting language,
>>> (sic Python/Kivy), the learning curve is simple, the widgets are built in,
>>> and it runs on Windows, Linux, Unix and various.
>>>
>>> HTH,
>>> Cheers,
>>> Rob.
>>
>> Tk's not a terrible graphics toolkit, but what manner of sadist are you
>> that you would suggest Tcl as the language of choice for anyone without
>> a gun to their head?  I've written assembly for a half dozen
>> processors, C, C++, C#, Python, Perl, VHDL, Verilog, three flavors of
>> BASIC, Java, Javascript, and Awk, and in all that have NEVER
>> encountered a language so unlikely to give you the results you want
>> without extensive debugging as when my EDA tools force me to write Tcl.

My comment below is predicated on having learned the handful of ... 
unexpected things about Tcl that generally confuse people long ago
in a galaxy far away...

I also don't see LISP on your list ( ha! ) So that's probably why Tcl
seems so odd. It was also that or (shudder) Perl at the time, back in 
the 20th Century...

If this comes up again, please consider buying and working through the 
Brent Welch book. I think it'll raise your pain level.

>
> Seconded. If you want to use Tk, use Python, or Scheme, or sticks and
> rocks.  _Anything_ but TCL.
>


Phfbbt! Slander! :)

Writing Tcl from scratch is , I would think, different from having to 
back Tcl into an EDA kit. I also have to wonder if EDA kits froze to 
ancient versions of Tcl that miss critical features { namespaces for one }.

I dunno, really - never had to do that with an EDA kit.

I don't even think you can do actual asynchronous I/O in Python without 
a "framework" (Twisted) . It's five lines of Tcl plus the read handler,
built-into the main language.

There's a few Python examples in which they actually *spawn threads* to 
do socket service. Lordy.

Granted, you have to learn three or four patterns before you get Tcl 
singing, but it's worth it. Figure a couple or four weeks of evenings to 
go through the Brent Welch book.


Every time I try to do something in  Python, I  end up giving up because 
it's missing something.


Just sayin... I write full-featured testers for embedded stuff I've 
written in Tcl in two hours or less. But I've been using Tcl for 20 
years. IMO, it makes for better programming habits in other
languages once you get the rhythm of it.

The Welch book is absolutely critical here...

--
Les Cargill

Tom Gardner wrote:
> On 01/07/14 03:21, Allan Herriman wrote:
>> I have similar experiences, and have similar feelings for TCL.  Yet if I
>> were to create a tool that needed an embeddable scripting language, I
>> would consider TCL, simply because all other other tools (of the sort I
>> believe you're thinking of (e.g. logic simulation and synthesis)) already
>> use TCL and the users already programs in TCL and will want to reuse
>> those scripts.
>
> I note that the new Xilinx FPGA tool is based around TCL.
> I haven't, yet, experimented with it sufficiently to see
> whether I "approve" of the TCL!


If you find Tcl painful, and will have to suffer with it again, please 
consider buying the Brent Welch book and skipping around in it enough to 
be able to defend yourself.

It's available for very cheap on Abebooks.

-- 
Les Cargill

Les Cargill <lcargill99@comcast.com> writes:
> [...]
> There's a few Python examples in which they actually *spawn threads*
> to do socket service. Lordy.

Les,

Let's say you're waiting for a byte to come across a socket. As far as I
know there are two alternatives to using a thread: 1) block until it's
received, or 2) provide a callback. Blocking is usually not acceptable.
Using a callback that executes from another thread can be a bad idea.

So we're left with spawning a thread. That actually seems like the
*best* solution to me. Why do you (apparently) disagree? 

(Note that this really has nothing to do with Tcl specifically.)
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

On Mon, 07 Jul 2014 22:42:44 -0400, Randy Yates
<yates@digitalsignallabs.com> wrote:

>Les Cargill <lcargill99@comcast.com> writes:
>> [...]
>> There's a few Python examples in which they actually *spawn threads*
>> to do socket service. Lordy.
>
>Les,
>
>Let's say you're waiting for a byte to come across a socket. As far as I
>know there are two alternatives to using a thread: 1) block until it's
>received, or 2) provide a callback. Blocking is usually not acceptable.
>Using a callback that executes from another thread can be a bad idea.
>
>So we're left with spawning a thread. That actually seems like the
>*best* solution to me. Why do you (apparently) disagree? 
>
>(Note that this really has nothing to do with Tcl specifically.)


Well, you can also poll for the event (or block on it if the OS will
post a semaphore for you), or use a queue that the OS can post the
event to, and that you can poll or block on.  Even in environments
where a callback is what the OS most conveniently provides, doing
nothing in the callback but posting the event to a work queue is often
the best approach.

The approach with a queue also easily allows multiple service threads,
without having to create a thread for each socket or whatnot.

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Mon, 07 Jul 2014 22:42:44 -0400, Randy Yates
> <yates@digitalsignallabs.com> wrote:
>
>>Les Cargill <lcargill99@comcast.com> writes:
>>> [...]
>>> There's a few Python examples in which they actually *spawn threads*
>>> to do socket service. Lordy.
>>
>>Les,
>>
>>Let's say you're waiting for a byte to come across a socket. As far as I
>>know there are two alternatives to using a thread: 1) block until it's
>>received, or 2) provide a callback. Blocking is usually not acceptable.
>>Using a callback that executes from another thread can be a bad idea.
>>
>>So we're left with spawning a thread. That actually seems like the
>>*best* solution to me. Why do you (apparently) disagree? 
>>
>>(Note that this really has nothing to do with Tcl specifically.)
>
>
> Well, you can also poll for the event (or block on it if the OS will
> post a semaphore for you), or use a queue that the OS can post the
> event to, and that you can poll or block on.  Even in environments
> where a callback is what the OS most conveniently provides, doing
> nothing in the callback but posting the event to a work queue is often
> the best approach.
>
> The approach with a queue also easily allows multiple service threads,
> without having to create a thread for each socket or whatnot.

Agreed. Queues are a smart way to work.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

Randy Yates wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> [...]
>> There's a few Python examples in which they actually *spawn threads*
>> to do socket service. Lordy.
>
> Les,
>
> Let's say you're waiting for a byte to come across a socket. As far as I
> know there are two alternatives to using a thread: 1) block until it's
> received, or 2) provide a callback.

This is done in Tcl essentially using a callback.  But it's all 
first-class furniture in the language itself, not a bolt-on.

> Blocking is usually not acceptable.
> Using a callback that executes from another thread can be a bad idea.
>

Very much so. But Tcl is specifically designed to be callback-friendly.
It's *all* callbacks; there is just an invisible,  default callback in 
the text it  runs in the (implicit) "main" block.

> So we're left with spawning a thread. That actually seems like the
> *best* solution to me. Why do you (apparently) disagree?
>


It's not better because it's one more part that's not necessary. Not
having to have a thread also means you never have to (sempahore) lock
things.

The magic to Tcl is - it is completely and irrevocably event driven.

I am a raving advocate for event driven. YMMV.

There's a built-in event loop that defaults to a "do nothing" when
there are no events and you have blocked. I'll leave "blocked' for now
- it's easy to do.

It's nearly trivial to use event-driven I/O.

So we can have three lines of code:
  set s [socket $IP $PORT ]
  fconfigure $s -blocking 0 -buffering none -translation binary
  fileevent $s readable ::aProc

  and then once you fill out ::aProc ( :: is just the top namespace
  for Tcl ; we're being VERY EXPLICIT about the name ) you're done.

proc aProc { } {
     variable s
     if {[eof $s]} { exit } # or something...
     set ib [ read $s ]
     doSomethingWith $ib
}

That's an entire TCP client.

This does not run in a spawned thread and it's completely serialized for 
you.

"blocked" is easy :

vwait ::forever

Want a timered background loop?

proc BGloop { } {
     after 500 ::BGloop // 500 msec ; more namsepacery
     ...
}

after 10 BGloop # the after 10 is unnecessary
vwait ::forever

> (Note that this really has nothing to do with Tcl specifically.)
>


It rather does, really. To my eye, it's congruent with using
(p)select() in a non-blocking fashion in 'C' on nonblocking channels
(yes, you have to be careful of both ) rather than spawning a thread to
block or poll on sockets/file handles pipes/what have you.

-- 
Les Cargill

Robert Wessel wrote:
> On Mon, 07 Jul 2014 22:42:44 -0400, Randy Yates
> <yates@digitalsignallabs.com> wrote:
>
>> Les Cargill <lcargill99@comcast.com> writes:
>>> [...]
>>> There's a few Python examples in which they actually *spawn threads*
>>> to do socket service. Lordy.
>>
>> Les,
>>
>> Let's say you're waiting for a byte to come across a socket. As far as I
>> know there are two alternatives to using a thread: 1) block until it's
>> received, or 2) provide a callback. Blocking is usually not acceptable.
>> Using a callback that executes from another thread can be a bad idea.
>>
>> So we're left with spawning a thread. That actually seems like the
>> *best* solution to me. Why do you (apparently) disagree?
>>
>> (Note that this really has nothing to do with Tcl specifically.)
>
>
> Well, you can also poll for the event (or block on it if the OS will
> post a semaphore for you), or use a queue that the OS can post the
> event to, and that you can poll or block on.  Even in environments
> where a callback is what the OS most conveniently provides, doing
> nothing in the callback but posting the event to a work queue is often
> the best approach.
>
> The approach with a queue also easily allows multiple service threads,
> without having to create a thread for each socket or whatnot.
>


Please "man select" when you get a chance. You can certainly spawn a
thread for a (p)select() loop in 'C' but you have to attend to locking
that way - fortunately, pthreads.h has semaphores.

-- 
Les Cargill

Les Cargill <lcargill99@comcast.com> writes:

> I don't even think you can do actual asynchronous I/O in Python
> without a "framework" (Twisted) . It's five lines of Tcl plus the read
> handler,
> built-into the main language.

I think the new asyncio module might do that. There's a little client
server example at
https://code.google.com/p/tulip/source/browse/examples/tcp_echo.py

But I don't really know TCL or Python or networking well enough to make
the comparison.

In article <vg37g3mn4l6.fsf@coffee.modeemi.fi>, as@sci.fi says...
> 
> Les Cargill <lcargill99@comcast.com> writes:
> 
> > I don't even think you can do actual asynchronous I/O in Python
> > without a "framework" (Twisted) . It's five lines of Tcl plus the read
> > handler,
> > built-into the main language.
> 
> I think the new asyncio module might do that. There's a little client
> server example at
> https://code.google.com/p/tulip/source/browse/examples/tcp_echo.py
> 
> But I don't really know TCL or Python or networking well enough to make
> the comparison.

Or even the old pyserial documentation pyserial.sourceforge.net

In as standard module that can be included in most distributions.

There are hundreds of modules for adding functionality to Python

There are many ways to crack the same nut generally I would prefer
Python over Tcl, and anything over Basic or Perl or Lisp....

Most languages have lots of libraries/modules, all depends on
a lot of requirements even what core skill set in a place is
as to what is best. Some though I would not consider.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/pi/>  Raspberry Pi Add-ons
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.badweb.org.uk/> For those web sites you hate