OT: Software bloat (Larkin was right)

Wow, there's my post from December commenting on how Tk looks kinda dated... in your XForms application that also looks... kinda dated.

:-)

No offense, though -- functionality is far more important than appearance for most software!

Is that "knob" control a standard part of xforms, or did you create it yourself?

Here's mine:

is kinda interesting looking -- I like the mascot...

---Joel

I have had to used Tek scopes with nice storage media features but where the scope ponders for a whole long time whether it really wants to comply with the user request :-)

Never understood why because my Instel stores the second after I pushed the button.

At a client of mine they instantly dump everything into Excel, where they have a myriad of calculation and display routines to let loose on the data.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

On a sunny day (Wed, 19 May 2010 12:21:35 -0700) it happened "Joel Koltner" wrote in :

Not sure what you mean by 'knob control', I have not made any widgets for xforms uptil now, so whatever it is, it is in the xforms library.

The nice thing about xforms is that it can change any on screen attribute on the fly, so you get moving pie graphs, moving graphs, lights that change color, I usually do it from what hey call 'idle callback', say a thread that runs constantly. Makes it ideal for instrumentation, as you only have to hand it some values, you do not have to worry about threads and handshaking at all. You can also click on the graphs, interactive, ftp://panteltje.com/pub/xforms_interactive_graph.gif and you can have more then one graph dynamically in the same x-y plot.

Nice!

Some of these old "big iron" instruments were rather more complex at the digital level than you might think -- something like an HP 8920B RF test set is really a handful of different processors that talk to each other over the slow GPIB bus, for instance. Normally this doesn't matter since they're just passing, e.g., "set the time scale to 100ns/division" around, but of course when you ask to transfer a large chunk of data the speed (or lack thereof) becomes apparent.

Apparently when these instruments were designed some 20+ years ago they needed that level of modularity so that they could readily break up design work among the numerous people on the team? I don't really know, although I wouldn't be surprised if that Instek scope was entirely developed by no more than, say,

4-6 core guys so they didn't need nearly as many "hard" interfaces between themselves.

---Joel

Um, "Don". Didi is someone else! ;-) (Hi Dimiter! :>)

Yes. I think the sources are on sourceforge. But, you should be able to find links there.

I think if you play with it, you'll be amused at what you can do in such an environment.

Those Tek scopes were newer ones, lunch box style with a handle. That shouldn't have happened.

Even in the old days many engineers got it right. For example, when I press the magic button on my HP3577 is instantly spools its data onto the PC. This thing is from the 80's and unfortunately has only GPIB but it does work efficiently. Ok, back then they called the button "plot" instead of "print".

That's what good management and design reviews are for. At the division I ran we had around 15 engineers and stuff like that would never happen. Ok, we did hang out together outside of work a lot because we shared similar outdoors interests, and there weren't any rank issues (got an interesting story there). But we never talked shop much while doing pool parties etc.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

TDS3000 series or newer? I kinda get the impression that the 3000 series, even though it looks pretty modern, was still designed using the "old school" methods. (It has the "old school" CCD samplers in it -- hence the very slow capture memory depth.)

Although, gee, now that I think about it, the 3000 series came out something like 15 years ago now! Impressive that they're still selling them profitably today.

The DPO2000, DPO3000, and DPO4000 series that came out within the past 5-10 years... that would be pretty disappointing if they weren't quite snappy. (Those all use the VPI interface on the probes -- *I built them* a USB-connected box to read and write the EEPROMs in those probes, and it was something like 25x faster than the old RS232-connected box they had around from the TekProbe days to do the same thing. So I can claim that at least in the tiny part of those systems *I* worked on, it was fast! When I gave my presentation about this to the rest of the group, the first PowerPoint slide had a dinosaur next to a picture of the old system and a roadrunner next to a picture of my new one...)

Good managers are hard to come by...

---Joel

MiniCom does this... I kinda like it; reminds me of the old Procomm Plus for DOS.

For a lean, poor man's "GUI", consider using a manu system atop curses. *Very* fast (even over a serial link!) and has all the "feel" of a GUI without the G.

Yes. There are some "open" toolkits that you can build on (I think Borland's TVISION). But, if you spend any time looking at how curses works, you can see how easy it is to roll your own toolkit. On a 9600baud serial port you can even make an 8 bit processor look as slick as a modern PC running a GUI (for smart screen layouts). Perfect example of trading CPU for communication channel bandwidth.

(the only real bummer is if you enjoy things like shadows as they often cost extra real-estate in a curses based gUI.)

Oops, sorry. :-) Didi, as I recall, wrote his own GUI from scratch -- I bet his code is pretty tiny. (In communist Bulgaria, GUI writes you?)

AFAIR they were not that old although fast writing to memory cards was a well know technology back then. I know, because we did it in ultrasound machines :-)

Tektronix must have been a fun place to be for an engineer back then, lots of interesting challenges.

In the end even that is a team effort. It is important for anyone on the team to speak up when they see something that could hit the fan or cause miffed customers. I am involved in two such designs right now, with me being around 2000 miles away. "What if ...?" ... "Oh yeah, darn, let's make sure we cover that".

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

I only spent 3 months there as a summer intern, and there was a certain "dead" feeling to the place at times (the floor I worked on -- over half of it was empty spaces or empty desks!), but there were certainly some bright spots left as well.

My experience is that it tends to take two or three "yes, we should do that, it's pretty straightforward to implement and a useful feature us and the customer" voices to outweigh one, "oh no, we shouldn't do that, it'll be risky and difficult" when you have managers with non-technical backgrounds.

---Joel

Here's our parts thing, home page. It's all single-letter keystroke commands and prompts. It a blast to drive.

ftp://jjlarkin.lmi.net/MAX.jpg

You can look at all parts, do searches, do where-used, browse parts lists, see datasheets/photos/links/engineering notes. Parts selected in one context are carried over into others... you can prowl a parts list, highlight a part, escape out, and the part is featured on the home page. Then do where-used, or open the part data file, or enter the total parts report at that point.

John

Ho hum! Worth a try though. Sometimes these tools have smart linkers. Although I am not sure about Python - is it a bit like Lisp in that you could read a text file and then interpret that as program (so that the optimiser cannot remove anything because it might be used).

These days 7MB isn't all that big. And at least it does more than print "hello world".

Regards, Martin Brown

All the script-to-exe tools I've come across embed a full interpreter and a zip (or whatever) file of all the libraries it thinks you might need into a single file. The first step in execution often involves uncompressing the zip into a temporary directory somewhere.

Clifford Heath.

Yeah. I suppose the upside of Linux and the Mac OS is that Python comes with the OS, so the end user in a sense never sees all the bloat in the application software.

I suspect that at a bit under 1,000 lines of code, it's 7MB... but that if it were 10,000 lines of code it'd be, oh, say, 7.1MB. :-)

You developed this in-house? Why not use something off-the-shelf? (OTOH, most OTS solutions force you to do business "their way")

I've wondered the same thing, Don (see, there, I got your name correct :-) ) -- but I've now worked at two small companies that spent more than three years trying to get expensive commercial MRP systems fully deployed without success (...company #1 went belly-up, company #2 is still working on it), so I give John a lot of credit for solving the problem himself and just getting on with the core part of his business -- design engineering.

The only small company I've worked for that had their MRP system "under control" was using Greapt Plains (now Microsoft Dynamics). No one really liked it, but it did at least get the job done.

---Joel