When I learned APL, it was on VAX/VMS using Lear Sieglar ADM3 ASCII terminals. Not only didn't they the APL character set, most of them didn't even have lower case. With the proper character set, I thought APL was pretty readable (with a little practice).
-- Grant
From my experience, I decided that if I ever had to implement a project using only *one* language -- application code, user interface, scripting, anything else -- the language would be Forth. For a while after I got an Atari 512, Forth was the only good language on the machine so I got kind of familiar. Still glad that I've never hit a requirement for using only one language. (Used Tcl/Tk in one application specifically to provide a GUI to an embedded system. It was -- OK. Quite lightweight, which was the point.)
Use Lazarus (or fpgui). You might not have heard about it yet :).
Lazarus is a cross platform open source Object Pascal RAD-IDE modeled after Delphi. It is the simplest and by far the easiest method I know to generate good looking stable Guis mainly by simple drag and drop and afterwards setting the properties of the gui elements with the property editor. This generates the basic pascal framework in which you later fill in the specific details of the application.
Afterwards you can compile for all mayor operating systems from the same source with only minimally changed specific settings. RS232 communication is certainly available, it may even be in the main distribution right away. It should not present any mayor problems. I have used a FTDI-USB chip about 10 years ago, for which a Delphi driver was/is available from FTDI, which hopefully should work with Lazarus too. This is most likely the easiest way to get USB running with minimal effort.
Lazarus uses the same graphical elements of the operating system for which it is compiled, so you get a native system look and feel. After over 10 years of very active development it is now finally in a very stable and usable state.
Fully installed on Windows with all source and examples Lazarus takes about 700Mb.
-- A very good similar lightweight alternative to Lazarus especially for guis for embedded systems is fpgui. It uses the same pascal compiler as Lazarus (FPC), but the gui is almost completely programmed in pascal sitting directly on the api, using fpgui native elements. With this you get a very fast lightweight gui with consistent look and feel on the different operating systems. For technical stuff I think this is an advantage, even if it looks slightly different than the native applications (fpgui look). http://fpgui.sourceforge.net/ http://en.wikipedia.org/wiki/Fpgui Simple installation (recommended): http://www.turbocontrol.com/easyfpgui.htm All in all the above are by far the simplest and fastest ways for making good looking stable and professional GUI interfaces on any common operating system for embedded systems. Pascal is pretty close to C, so getting familiar should be quite easy for a C programmer. Pascal is well suited even for safety critical applications; I have seen some very heavy and dangerous mining equipment controlled with Pascal interfaces (Delphi), of cause bypassed with emergency shutdowns. Regards, Gerhard
Python is embeddable. I'd really love to have EDA tools with Python scripting instead of TCL! But as you say, it's doubtful TCL's reign is in any way threatened. It's there and it works. I can't see a business case in it and I doubt many customers have interest.
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
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
This is done in Tcl essentially using a callback. But it's all first-class furniture in the language itself, not a bolt-on.
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.
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
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
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
I think the new asyncio module might do that. There's a little client server example at
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
PC Services
Raspberry Pi Add-ons
Timing Diagram Font
For those web sites you hate
You can also use "select" to wait on a whole bunch of sockets at the same time. This is the usual way to handle lots of sockets without needing the overhead of a thread (or process) for each socket (regardless of the programming language).
However, when you are programming in Python you are often concerned with ease of programming, rather than maximal speed - and spawning a thread for each socket is often a very easy way to handle connections. Python makes multi-threading easy, as many of the key structures are already thread-safe due to the GIL, and things like locks and queues are convenient in the library. It's less good for multi-threading as a way of speeding up calculations, as only one thread does Python work at a time.
Alternatively, you can use the traditional Python approach of letting someone else do the hard work, and use a library - if you want a sophisticated networking application, use twisted to do the work and then you don't have to care how it is implemented.
I have used Pyhton with Tkinter GUI on Win 7 with no problems. Pyserial is compatible with python v2.7.6 so make sure your version is comparible with that. Version 3.0 onwards did not work with pyserial for me.
--------------------------------------- Posted through
Well, Les seemed to be hung up on what's included so I brought up asyncio since it's included now.
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.
I used to use 'C' for this, then AWK, then Perl, then Tcl and SFAIK all progress ended there.
SFAIK, outside of shell scripts, the original* "scripting" thing was logic for things like establishing a SLIP/PPP connection.
*far enough back, but not that far. And yes you betcha on Winders...There's an entire other rant :) about the politics of Tcl which includes people like Stallman. But the principal value I find in Tcl is the underlying ... philosophy of it as a language. It's just had a very highly qualified team steering it all these years.
-- Les Cargill
Python isn't a "scripting language". It's a general-purpose programming language like Java, Pascal, etc.
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.
--
Grant Edwards grant.b.edwards Yow! HAIR TONICS, please!!
at
gmail.com
The current favorite for this type of thing (embedded scripting where you want something smaller than Python) is probably Lua,
I don't think Stallman had any political objections to Tcl (i.e. in terms of free software ideology). His complaint was on technical grounds:
Basically Tcl is what some of the language-design crowd calls "stringly typed" (a pun on "strongly typed"): all values are represented as character strings, which seems very flexible at first, but it's difficult to manage complex programs where stuff is kept like that. Javascript and Lua also suffer from this problem to some extent. Python keeps numbers, strings, etc. strictly segregated. There's no compile-time type checking, but any type mismatch causes a runtime exception, so if you code in a type-aware style, then any mistakes get caught pretty fast during development.
It's been subsequently shown that Stallman a) didn't understand Tcl and b) thought Scheme was a competitor.
"Politics" is a poor word, but it's best I could do.
I fundamentally disagree.
Yep.
-- Les Cargill
Interpreted language, then - 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.
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.
-- Les Cargill
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. 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.
You're right, the current native-code implementations of Python are still incomplete. Due to the dynamic typing, generating purely native code is difficult.
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"?
--
Grant Edwards grant.b.edwards Yow! Sign my PETITION.
at
gmail.com
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.