OT an electronic circuit

Thanks, George, that is encouraging. I shall try Python then. Even though I don't like snakes and killed the last one I saw because it took an aggressive stance towards me and a dog. In hindsight it probably wasn't a rattler.

That's the kind of stuff I'll probably also run into. I grew up with DOS but have largely forgotten all the command line stuff. Hopefully Python can be set into a mode where it accepts any path or at least any in a given sub-directory set. Migrating to Linux has helped me re-learn some command line.

That would be right up my alley as a SW-beginner. An older one to boot.

That is the stuff I always hand off to experts and why there are SW guys and coders in my network. I develop the idea and the code architecture, like what has to be calculated when, and then it's off to the code writer.

Check out virtual environments.

Cheers

Phil Hobbs

What gets me is not the coding itself. It's the perpetual changes of versions, library and include files and their locations, compile options and whatnot. After being forced to re-write an application for the n-th time because the dependencies and tools changed beyond recognition, one tires of the game.

Sigh. Time to think about retirement, I guess.

Jeroen Belleman

Python actually compiles your source to a pseudocode form at the instant you run it. It's not a full-blast interpreter. DEC's BASIC-PLUS looked a lot like Python, and also compiled to pseudocode at run time. Pseudocode is object code for an imaginary, usually stack-oriented, computer. It's faster than an interpreter but slower than a proper machine code compiler.

That is what irks me with Linux. Some software needs dependencies "fixed" and after allowing their updates some other software or hardware (such as audio) no longer works. Soon I'll have to learn about containerizing packages, or "snap" in Linux-speak.

Luckily I am well into that phase, so many things aren't that urgent anymore. I never want to stop 100% though, just 85-90%. The 10-15% remaining base load is mainly there to keep my brain exercized. I told all my clients to only leave the tough stuff for me.

It was common even in the 90s on large game and multimedia projects to provide a "sandbox language" interface to the engine that allowed the story and art-people limited access to engine mechanics but the fundamental system "engine" and physics stuff was privileged. Makes division of labor on large projects easier.

In those times it was often some stack-machine scripting language like Forth or a dialect of C that was compiled for a bespoke VM, that ran alongside the compiled C++ code. Python and Lua play that role now, it's not hard to provide bindings to make sandboxed dll/system calls into compiled C++ code.

If you know a little C/C++ OpenFrameworks is a good just-get-things-done API, it provides some cross-platform abstractions for working with menu interfaces, sound, graphics, threading, etc. that's much easier than working with say the Windows API directly.

For doing quick-n-dirty cross-platform GUIs OpenFrameworks provides a nice API that's simpler than working with something like Qt or the Windows API directly I think.

Speaking of Forth, did you know it was created by an astronomer to control a telescope?

I didn't but seems plausible-on-its-face to me!

It's a language that I've made attempts to get into every so often but don't seem to get very far.

My introduction to computer science was at an arts college in the 90s, they were very big into Lisp as a teaching tool at that time but it didn't seem to "take" with 19-year-old me very well. It seemed very elegant and very inscrutable, back then. That the (small) faculty of the department were the type of people who were reaaaaaallly big into Lisp probably didn't help matters.

When I learned some Python a number of years later it struck me: "Ah, this is the right combination of elegance and get-r-done that would have sold me on STEM in the first place instead of dicking around in the music buisness for a decade."

Not that there's anything wrong with that but "The music business is a cruel and shallow money trench...."

The reason it is called Forth is that the inventor (Charles H. Moore) early on considered it as a fourth-generation computer language on the IBM 1130. Unfortunately, the 1130 permitted only five-character identifiers. So Fourth became Forth.

I did not realize that it was available online but, here it is:

Here's a GUI written with the OpenFrameworks API (C++)

Essentially all the code for the example applet in the window there is on-screen in the background. Simple enough?

Programming is something I have very little experience with and I also don't like it. In Windows we had Azeatech DAQFactory which is an easy "click-and-drop" SCADA that has Labjack connectivity. Excel plus VBA worked nicely as well. The Linux world also offers SCADA software but none has Labjack connectivity. I just don't want to let a simple task mutate into a major science project.

I was hoping that Labjack offered examples with GUI in Python or in another popular language but they don't. So I am looking for the path of entry with the least amount of boulders in front of it. Maybe that's Python, maybe not.

For a programming rookie that looks complicated. The main issue is connectivity to the devices (Labjack U3). LabjackPython has that. OpenFrameWorks will likely require a lot of massaging of library code, compilation and whatnot.

The Labjack device only seems to give limited support for Mac/Linux but there's a C++ API for something or other it seems. Don't know a lot about Windows-coding but at least there's something. Say that's a cool piece of kit.

At some point if you're going with Python (it would be the same in C++) read up on using threads for multiple tasks, Python does make this pretty easy to launch multiple processes running on their own threads, like when you've got a communications port open for asynchronous communication and are doing GUI-stuff simultaneously.

Running the GUI/main program in one execution thread and the comms task in another keeps them both responsive. Usually some mechanism is provided for thread-safe passing of data between them like a locking queue.

I don't know if Python offers true multi-processor support at this time, I know at one time it didn't. Multiple threads of execution on the same processor have been supported for a long time tho.

Currently this sort of stuff is way above my level of software skills. However, having recently transitioned to Linux which is, ahem, a bit retro when it comes to user interaction, I am slowly learning the ropes.

This doesn't have to be realtime or even close. Even streaming is usually limited to 50ksamples/sec. Most of my cases will be slow monitoring of a temperature or a pressure and then reacting to that. There won't be a mushroom cloud if the response is issued 20msec late :-)

Hopefully any sluggishness is that unobjectionable in practice on a modern machine, however when an interpreted language like Python has to dive down through a number of layers of abstraction and privileged system calls to check hardware port status and pull any available data back up into the interpreter for use it is often not la dolce vita.