Sunday, April 20, 2014

Personal UV Sensor reboot

Back in 2011 one of my CFT projects was to develop a personal UV sensor for those who are a high risk for skin cancer.  Due to the limited availability of tuned UV sensors (i.e. a reliable source for UV Index rating values), I had to abandon the project. I produced one prototype, as outlined here: but had to put further prototypes on hold due to  sensor procurement issues.

Well, apparently there is a rumor that the forthcoming Apple iWatch will include a UV sensor (  This is great if you have an iPhone, lots of money and want a new watch, but this isn't my target.

But, the new UV chip they are using, fits my budget:

I want something small (and cheap) enough that you could clip it to a hat, a UV windbreaker, shirt or blouse. Oh, and it should be water resistant (wear it on the beach or by the side of the pool) or even water proof (go swimming with it on).  It should also allow you to set a timer (in hour increments) to remind you (via beeping) to apply more suntan lotion.

The only UI would be a capacitive touch sensor. Press to see (or hear through beeps) the current UV index. Press to set timer.  LEDs (matching UV Index official colors) and/or small buzzer would be the feedback mechanism.  It should cost under $20 and the battery should last a few years (at least 5) under moderate UI usage.

Why do this?  Well, why is every (new to market) useful sensor device required to work with RF and/or interface with your phone?  Why can't tech just "be there" when you need it, rather than be "gadgets" that work with other "gadgets".

Heck, give me a 10 year battery life and I'd say you just sew the thing into clothing.

Okay, I've said way too much.  Let's just say that I am working on it.... stay tuned.

Tuesday, April 01, 2014

Teaching Forth Programming to kids... is really dangerous...

Teaching Forth Programming to kids is irresponsible and may hinder their progression into the professional programming industry.

So, let's do it.
One rather curious thing I've noticed about aesthetic satisfaction is that our pleasure is significantly enhanced when we accomplish something with limited tools.   - Donald Knuth, Computer Programming as an Art 

Forth doesn't have a lot of modern facilities, but that forces you to figure them out yourself.  Better yet, Forth encourages that you solve the problem at hand (rather than build elaborate frameworks).

I've been called out, in this blog somewhere, for promoting archaic old principles that don't apply to modern development.  But, I don't actually want to force people to learn this stuff. Find your tool and if it helps you do amazing things, stick with it.  

I've been programming in Forth since 1984.  I've learned a dozen languages since.  Forth is still the one that focuses my attention on problem solving better than any other.

Why am I writing this now?  I'm a bit late, but I just discovered this: Gforth for Google Chrome.

It's a toy right now (apparently no persistent file I/O), but I want it to be real.  I want to fire this up in a classroom full of kids and get them hacking.  I want them to build their own abstractions. I want them to see what middleware really is (a bunch of layered restrictions with the goal of making things more structured and easy, while in reality making you conform to things they want to keep hidden -- okay a rant for another day).

Sure, underneath Gforth for Google Chrome there are layers upon layers.  But there is a lesson there too: Its all about simulation.  It's Turing machines all the way down.

Tuesday, March 18, 2014

Statically Typed Languages like C++ and Haskell are good for lazy programmers (like me)

I've seen my errors in production code. I'm doing a forensic analysis of some "embedded" software I shipped to a customer.  By embedded I mean there is no UI and it is supposed to run unsupervised 24x7.

Server (Cloud) software often meet this criteria, but sometimes we cheat and log in (to see how things are going) or restart the OS when things aren't quite right.

But, that's not quite embedded. By embedded I mean "It has to run without me or the user intervening." and "There is no such thing as rebooting to fix a problem."

Now, I love developing code in Lua, so this isn't a Lua criticism, but when I review my daemon logs and see that the process died because I was trying to add a number to a "nil" value, I cringe.

On this same system I have a Haskell process also running.  The only time I saw it had died was when I didn't handlebeing fed bad data from a corrupt database.  Not exactly the same class of bug...

The Lua code problem could have been caught with unit tests or code review (maybe), but I am sort of a lazy programmer.  I can fall back on lazy habits such as "this is so obvious it can't be wrong".

Haskell doesn't let me do this.  It won't let me go on tossing untyped variables here and there . It won't let me assume that I never pass a string as a number (or vice versa).  It forces me to be precise.

Compiling modern C++ (C++11) with warnings on (in clang++ or g++) is similar.

I hate to say this, but after continually abandoning C++ (in cycles: 1992, 1997, 2002, etc), I am back again and I like what I see in C++11.

I'm writing deliverable code at work using C++11 and I just tried my hand at using it, *instead* of a scripting language, to do some configuration file handling.  C++11 for scripting?  Yes. And it seems to work.  Not a pointer in sight. (Actually that would be the only sane way to do this in C++: rely on RAII.)

All that being said, and especially to any potential employer who may be reading this: I am not really a lazy programmer.

Monday, January 20, 2014

The IDE called Forth, or.. Forth I wish I knew how to quit you.

I've been playing with OpenFirmware. Yep, booting it off of a thumb drive (via Grub2). It takes less than a second to boot on a "fast" laptop up to the Forth "ok" prompt.  At that point, I can start playing around with low level hardware.  Open Firmware went so far as to provide a "GNU readline" like capability where I can use Emacs-like command line editing and completion of words.

But, wait, there is no command manual!  What does this word do?  Enter "see" and the word you are interested in and view disassembled source code.

People (still) underestimate the innovations built into a "classic" Forth.   Gforth still has some classic capability built in.

Here is what I had with Forth during the 1980s (on Commodore 64 and then Atari ST):
  1. Full screen block editor.
  2. "See" or equivalent for looking at source.
  3. The ability to ask the block editor to locate the "real" source and let me edit it (i.e. Tags).
  4. The ability to play around with graphics and other hardware facilities.
  5. Very fast start up (or restart for when I crash the machine).
This was the basic Forth IDE.

I'm a long time Emacs user (25+ years)  and I still not at that same IDE productivity level I was with Forth back in the day.

Smalltalk (in particular Squeak) has been the only other things that has come as close (for me).

I know that machines are bigger and software is a lot more complex these days, but why can't I have that same feeling of "being one" with the machine?

Here is what I want:  I want to load up an interesting library (e.g. libpcap, OpenCV, etc) into a Forth (e.g. Gforth) and explore.  I want to play.  Lua, Perl and Python can get me half way there (i.e. bindings), but I still have to grapple with a REPL that doesn't seamlessly integrate with the editor.  

Yes, yes I know you can bend Vim or Emacs to do these things, but the resulting IDE isn't as natural (IMHO). You are still piecing together a generic editor, a command line (linux shell) and a programming language. (For example, how do you list a directory in the chosen language? Oh, you use the shell or editor? Are the results first class elements for the language?). 

Some would say that Visual Studio is a great example of a seamless IDE, but it is still working with a language that isn't naturally "interactive".

This is why I still hang onto Forth. It isn't about Forth building better apps. I don't care what an app is built in.   It isn't about the destination, its all about the journey.

Thursday, January 02, 2014

Todd's 1 question test for all new "advanced" dynamic scripting/programming languages.

Whenever a new language comes out I have a simple test to see if it is worth looking at.  I came up with this test back in the 1990s after being frustrated by the state of "advanced programming languages".

In the 1980s, as a lowly FORTH programmer, twiddling 8-bit bytes, I was blown away with my first experience with Lisp. It was on a DEC2060 (running TOPS-20) and was called "Standard Lisp".

As a student, back in 1984, I coded up a small lisp function to compute the factorial of 120.

The terminal presented me with:


My mind was sufficiently blown.

Of course, the largest factorial computed by a programming language where the number/integer type is matched to the machine word size is much smaller.  I had already programmed in Pascal, FORTH, a bit of C and BASIC.  But, this was the first language implementation I had seen that wasn't bound by that machine word limitation.

(I quickly followed that exercise by coding for the factorial of increasing numbers until, by the time I was in the hundreds of thousands, the terminal responded with a message saying that it was taking too many resources and that the process was being "spooled" -- whatever that meant.  I went home and the next morning I was greeted with an email from the sysadmin requesting that I come get a "print job" from the ops center.  I rang the ops center door buzzer, the admin came to the door and asked what I wanted. I told him him who I was and he then frowned, told me to wait and closed the door. A few minutes later he showed up with a hand truck loaded with a big box of green bar printer paper.  Apparently, "spooled" meant the result was being submitted as a print job).

A couple of years later and I discovered that Smalltalk too had this "big num" (or arbitrary precision) feature.  Why wouldn't every language have that? (Yeah, I know... performance...but, still...)

Now, when I am presented with a programming language that is supposed to be the "next step",  I look to see if it supports bignum.  Now, when I say support, I don't mean surrounding the number by quotes and submitting it to a bignum library. That's cheating. I want to say something like:

X=6689502913449127057588118054090372586752746333138029810295671352301633557244962989366874165271984981308157637893214090552534408589408121859898481114389650005964960521256960000000000000000000000000000  / 19;

I don't want to type it as a string. That's saying that there is something "special" or "hard" about large numbers.  Why, in 2014, should I be concerned about whether a number fits into 32 or 64 bits (or in the case of Lua and Javascript: a 52 bit mantissa)?  I want tnative/natural support.

So, what other programming languages pass this bignum test?

  • Erlang does. 
  • Haskell does... sort of... got to choose the right type.
  • Perl does (and has for a while.. just type "use bigum;"  and all following numbers are not bound by machine word size.

Now, don't get me going about native/natural support for rational types.


Thursday, December 19, 2013

Perl is 26 years old?

I just read on Hacker's News that Perl turns 26 years old today.  My oldest piece of open source software is written in Perl. AFT.  AFT was coded in Perl 5 back in 1996 (which makes it over 17 years old).

I originally wrote AFT in awk (sometime during the early/mid 1990s) . I ported it to Perl by using the awk to perl translator (a2p) as a starting point.

Every once in a while I revisit AFT to see if there are any new tricks to add or just to clean up the code and make it a bit more Modern Perl.  AFT is still in the Ubuntu software repository, so you can install it under Ubuntu by simply doing   sudo apt-get install aft.

I'm still using Perl. I am doing some funky stuff with the AWS cloud (EC2 instances) and find Lincoln D. Stein's VM::EC2 package fits my needs.  Perl is still great for replacing nasty bash/sh scripts (although some would say I am replacing the nastiness of  bash with nastiness of Perl).

I'm not much of a CPAN user, but those who know me understand that I am very selective of libraries and frameworks. I prefer to avoid layering and loading lots of dependencies. What I find attractive about Perl is how much the basic distribution can get accomplished  (e.g. I don't have to resort to libraries so quickly as when I program in Lua).

I'm particularly interested in investigating Mojolicious for use in my elderly monitoring project.  I use LuaJIT primarily on the base station (with a bit of Erlang).  The cloud side is currently a fair amount of Perl.  But aren't there better languages to do cloud/web development?  Isn't Perl old hat?

For those folk who think that Perl is old hat and doesn't have a place in the modern Web, do you use DuckDuckGo?  It was developed primarily in Perl....

Tuesday, October 01, 2013

Power Considerations for an HVAC Thermostat (10 years off a couple of AA batteries?)

Hear a tick coming from your thermostat every time it turns on the heat or AC? Well, assuming you have an electronic/digital thermostat, you are hearing a latching relay.

Latching relays are wonderful power miserly switches. Unlike a solid state relay, which requires control current (anywhere typically between .25mA and 20mA depending on what you choose), a latching (mechanical) relay will latch (hence it's name) when pulsed.  A short burst of 100mA or so and you are done.  If your thermostat is switching the HVAC once an hour per day (which is pretty excessive), then you are still using a lot less power than a solid state relay.  Another potential problem with solid state relays is heat. They generate heat. They can overheat and if you don't choose and place your components wisely, they can affect the temperature sensor.

With latching relays,  your modern latching thermostat is not consuming that much energy.

Interestingly, I believe that the NEST uses solid state relays.

A quick google shows that some NEST customers are having battery issues. Here is an interesting one:

This is the kind of issue I want to avoid.  The two household gadgets that I don't want to think about (battery) power problems are my smoke detectors and my thermostat. I'll check once a year, but beyond that...

Here is a target: Ignore UI and wireless for a moment. Once a temperature schedule has been set, can you design a thermostat that will run for 10 years off of a couple of Lithium AA batteries?  That is my starting point.

So, as boring as "Thermostat design" sounds, it poses an interesting power problem.  Add sophisticated 'internet-of-things' functionality and now you have two problems.