What other standards are there? Well, there’s POSIX time_t which is either an integer or a floating-point type (but actual practice seems to favour integer), and stores the number of seconds since the Unix Epoch, 1970-01-01T00:00:00Z. Not counting leap seconds. Not counting leap seconds is convenient for some calculations, but means there are (recent) times that cannot be represented (namely, any moment during a leap second). That’s not a good representation of time.

There’s another time format in use which is confusingly similar to POSIX’s time_t: it counts time using the number of seconds since the Unix Epoch. Including leap seconds. The opportunities for mistakes in conversion are endless. A problem with this time format is that times in the future (more than a couple of years into the future XX) are ambiguous. Since we don’t yet know if there are going to be leap seconds between now and 2020 we don’t know whether 2020-01-01T00:00:00Z is 1577836800 or a few seconds more or less than that.

An example confusion: “man 2 time” on my Linux box claims that time_t is the number of seconds since Epoch, but “date –date=2013-01-01 +%s” ends in “00″ so clearly leap seconds aren’t being accounted for.

That’s twice now that I’ve used ISO 8601: 2013-04-09T06:06:06Z is roughly when I’m writing this paragraph. As a format for representing this times this has obvious benefits and equally obvious drawbacks. The benefit is that it’s pretty clear, and almost human readable (by humans like me). A drawback is that it takes a lot of space: 20 characters as I’ve given it. If you were storing this in a file you could reasonably use the “compact” form: 20130409060606Z, which is 15 characters, or 14 without the ‘Z’. Space misers could encode this in BCD and fit it in 8 bytes, which is no more than a 64-bit time_t.

Another drawback with ISO 8601 is that calculations with times can be a bit trickier. But on the other hand, you’re more likely to get correct answers, and be able to represent all (recent and future) times.

I’ve been working with sea-level and tide data recently and Hilary’s floating point number of days is certainly pretty convenient for that. The calculations are concerned with the average rotation of the earth, and it nicely represents that. Practitioners of the art also seem to like a slightly different time scale which is Julian centuries. Basically the same but scaled by 36525. It’s not unusual for the 0-point to be something like 1900-01-01T00:00:00, or even a midday like 1899-12-31T12:00:00.

What about representing times with sub-second accuracy? When Unix time_t type is an integer type then you’re stuck. ISO 8601 times can be extended with a decimal point and have as many decimal places as you like. So that’s a good representation. Hilary’s floating point number of days is also pretty good, as long as you’re using double precision. If you’re using double precision then even counting Julian centuries is okay, you still get sub-nanosecond precision. JavaScript’s representation is basically a floating point number that is the Unix time_t but in milliseconds not seconds. That too is pretty good.

I think Hilary’s format is actually pretty reasonable. Some calculations (involving counting whole numbers of days between times) are easier, some are tricky (but no trickier than any other format really). All times are representable. There’s some ambiguity about times in the future (that 1200 appointment you make in the year 2020 might actually turn up in your calendar at 12:00:00.5 if there is a leap second, but at least your midnight appointments won’t be on the wrong day). Yes, it’s a litle bit funky that on days with leap seconds the step between consecutive seconds will be different (it will in 1/86359 or 1/86401 instead of 1/86400), but I’m sure you’ll cope.

After a while, you just get used to seeing a new file format, another new date representation. According to the xlrd documentation Excel uses a floating point number of days since 1899-12-30T00:00:00, but since they thought 1900 was a leap year, this is only reliable after 1900-03-01. Unless the Excel file was made on a Mac, in which case the Epoch is 1904-01-01. The TOPEX/Jason data for global mean sea level represents dates as a decimal fraction of years.

The bottom line is: There are all sorts of crazy date formats. Get over it.

I recommend:

1) using a good library.
2) for storage, use ISO 8601
3) for runtime/manipulation use double.

All the tedious stuff about how you get started and how you install things is surprisingly difficult to get from the internets.

So to install on Ubunutu:

sudo apt-get install r-base

Then you run the command R:

$ R

Once you’re in R you can find things out by using Google. Once you’ve found a function you want to use, say sj.test, if it doesn’t seem to be installed, you can install it by noting the library name which is in curly brackets at the top of the man page. {lawstat} in this case. So you then go:

> install.packages("lawstat") # to install it
> library(lawstat) # to use it

(the package installer has a hilariously craptastic interface written in Tcl/Tk)

That’s it. Everything I need to know to learn R. Everything else is just bog standard programming language stuff (though it helps a bit that I learnt a bit of J).

Here’s the histogram:

And the R code is behind this link. The way the function png() implicitly makes hist() write into the PNG file is particularly bletcherous. It has all the elegance of writing JCL for IBM mainframes.

The curious thing was that the Duplo had SELF ASSEMBLED. It went in all in separated bricks. But when it comes out, some of it has stuck together. I found this pretty amazing. Surely if Lego can self assemble in the washing machine then it is a simple step from there to the beginning of life itself.

The variety of forms is interesting. Simple diatoms… in mixed colours:

…and also monochrome:

Simple towers, reminiscent of the things my little nephew makes, when he can be bothered:

Then there comes the forms that are not so easy to characterise. I like to call them monsters:

I’m particularly impressed with Bosch’s creative instincts here. The one at the front is a battleship with effective use of colour. The back left reminds me a bit of a tree. Perhaps some sort of highly coloured baobab tree. And is that a red boot kicking a yellow football on a field of green?

Francis speculates (whimsically) that maybe my washing machine has passed the singularity and is in fact an Artifical Intelligence trying to communicate with me. Obviously it is constrained by only being able to communicate by rearranging whatever I put into the washing machine. And the fact that it is a 4-bit microcontroller attached only to a valve, a heater, and a motor (maybe a temperature sensor too, but I wouldn’t be surprised if there wasn’t one). It’s an intriguing possibility. Perhaps the form on the right of monsters represents a not quite complete utterance, the Duplo bricks not quite bonded properly.

The AI hypothesis raises several questions: How can we test it? Can we distinguish between merely aleatoric arrangements, and intentional ones? What is Bosch trying to say? Is there something I can put in the washing machine that would make it easier for Bosch to communicate? Is Bosch happy?

Control-C is the Copy command in Windows.  It copies the highlighted text (or other graphic objects) to the clipboard.

What do you do when you’re using a terminal emulation program on Windows to connect to a Unix computer?  Does pressing Control-C send a Control-C character to the Unix system, or does it copy the highlighted text to the clipboard?  I have no idea (it’s been a long while since I used a terminal emulator on Windows), but one thing is clear: It’s not clear what the right answer is.

On a Mac Copy is an example of a command to a GUI application.  Keyboard shortcuts are accessed using the Command key.

Command Key from wikimedia

This is a stroke of genius.

Now, when using a terminal emulation program on a Mac, it’s completely obvious what happens. Control-C sends a Control-C character to the Unix system, which will interpret it as intr. Command-C copies the highlight text to the clipboard.

Was this luck? Hard to tell, but I think not. The Mac was conceived as an entire product. It therefore seems completely reasonable to design a keyboard just for that product, and completely reasonable to create a new key for doing Mac things. Windows was conceived as an operating system. It had to run on existing hardware.

Why didn’t Apple just stick a Control key on the keyboard and use that? Well, that would have been silly, and difficult to explain. Control had an existing use (on a terminal to send control characters that generally affected either the connection or the movement of the print head) which had nothing to do with GUI commands. Better to name the key that is used for keyboard shortcuts for GUI commands, Command.

Why didn’t Windows do this? Microsoft weren’t in a position where they could dictate what keys appeared on the keyboard. They had to make do with whatever was there. Why Control-C for Copy instead of Alt-C, say? I have no idea. It seems particularly mysterious since, at the time Windows was layered on top of DOS and so was used by people familiar with DOS and in DOS, at least at the command prompt, Control-C meant interrupt, like it does in Unix.

The lucky bit seems to be that Apple ever put a Control key on the keyboard at all; early keyboards didn’t have one, but I guess as soon as you have a modem you can connect to some other computer and that will require a Control key for some things. But basically the Control key on a Mac hung around for 2 decades doing nothing much until OS X comes out and then it’s used in all the traditional Unix ways.

What did Unix do when it got a window system? Well, on X Windows in the mid nineties I don’t remember using a keyboard shortcut for Copy. In fact, I don’t remember using Copy at all. The middle mouse button (most Unix workstations and X servers of the time had mice with 3 or more buttons) would paste the highlighted text into whichever window the mouse was pointing at (note: the highlighted text could be in a different window from the one which receives the pasted text). No separate Copy command, just highlight text in one window, and click middle button to paste it into another window. Cute.

Windows has a Windows button now (and, much to my surprise has had it since Windows 95). Obviously there was no way that Copy could be moved from Control-C to Windows-C because Control-C was already welded into the minds of all Windows users. So the Windows button generally does useless things in Windows.

What about Ubuntu? They could’ve decided that it was reasonable to assume that all keyboards would have the Windows key. They could’ve decided that all GUI shortcut commands would use the Windows key. Freeing up Control-C to mean intr. You would’ve though that for a GUI running on Unix this would be an important consideration. But no, Ubuntu thoughtlessly copies windows and Control-C means Copy. Unless you’re in the terminal emulator, Terminal, in which case it sends a Control-C character and you have to remember to use Shift-Control-C for Copy. And just like Windows, the Windows key is useless in Ubuntu.

It all just seems like a lost opportunity to me.

exception change;
fun change 0 cs = nul
  | change m nil = raise change
  | change m (ccs as c::cs) = if m >= c
      then c::change (m-c) ccs
      else change m cs;

It’s pretty neat. The recursion proceeds by either reducing the magnitude of the first argument (the amount we are giving change for), or reducing the size of the list that is the second argument (the denominations of the coins we can use); so we can tell that the recursion must terminate. Yay.

It’s not right though. Well, it gives correct change, but it doesn’t necessarily find the solution with fewest number of coins. Actually, it depends on the denominations of coins in our currency; probably for real currencies the “biggest coin first” algorithm does in fact give the fewest number of coins, but consider the currency used on the island of san side-effect, the lambda. lambdas come in coins of Λ1, Λ10, and Λ25 (that’s not a wedge, it’s a capital lambda. It’s definitely not a fake A).

How do we give change of Λ30? { Λ10, Λ10, Λ10 } (3 tens); what does Wikström’s algorithm give? 1 twenty-five and 5 ones. Oops.

I didn’t work out a witty solution to the fewest number of coins change, but I did create, in shell, a function that lists all the possible ways of making change. Apart from trivial syntactic changes, it’s not so different from the ML:

_change () {
    # $1 is the amount to be changed;
    # $2 is the largest coin;
    # $3 is a comma separated list of the remaining coins

    if [ "$1" -eq 0 ] ; then
        echo ; return
    fi
    if [ -z "$2" ] ; then
        return
    fi
    _change $1 ${3%%,*} ${3#*,}
    if [ "$1" -lt "$2" ] ; then
        return
    fi
    _change $(($1-$2)) $2 $3 |
        while read a ; do
            echo $2 $a
        done
}

change () {
    _change $1 ${2%%,*} ${2#*,},
}

Each solution is output as a single line with the coins used in a space separated list. change is a wrapper around _change which does the actual work. The two base cases are basically identical: «”$1″ -eq 0» is when we have zero change to give, and we output an empty line (just a bare echo) which is our representation for the empty list; «-z “$2″» is when the second argument (the first element of the list of coins) is empty, and, instead of raising an exception, we simply return without output any list at all.

The algorithm to generate all possible combinations of change is only very slightly different from Wikström’s: if we can use the largest coin, then we generate change both without using the largest coin (first recursive call to _change, on line 12) and using the largest coin (second recursive call to _change, on line 16). See how we use a while loop to prepend (cons, if you will) the largest coin value to each list returned by the second recursive call. Of course, when the largest coin is too large then we proceed without it, and we only have the first recursive call.

The list of coins is managed as two function arguments. $2 is the largest coin, $3 is a comma separated list of the remaining coins (including a trailing comma, added by the wrapping change function). See how, in the first recursive call to _change $3 is decomposed into a head and tail with ${3%%,*} and ${3#*,}. As hinted at in the previous article, «%%» is a greedy match and removes the largest suffix that matches the pattern «,*» which is everything from the first comma to the end of the string, and so it leaves the first number in the comma separated list. «#» is a non-greedy match and removes the smallest prefix that matches the pattern «*,», so it removes the first number and its comma from the list. Note how I am assuming that all the arguments do not contain spaces, so I am being very cavalier with double quotes around my $1 and $2 and so on.

It even works:

$ change 30 25,10,1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
10 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
10 10 1 1 1 1 1 1 1 1 1 1
10 10 10
25 1 1 1 1 1

        # given an input number which might be a decimal, convert it to
        # a rational number; set n and d to its numerator and
        # denominator.  For example, 3.3 becomes n=33 and d=10;
        # 17 becomes n=17 and d=1.
        to_rational() {
          # Crapulent bash can't handle decimal numbers, so we will convert
          # the input number to a rational
          if [[ $1 =~ (.*)\.(.*) ]] ; then
              i_part=${BASH_REMATCH[1]}
              f_part=${BASH_REMATCH[2]}
              n="$i_part$f_part";
              d=$(( 10 ** ${#f_part} ))
          else
              n=$1
              d=1
          fi
        }

Since I’m on a Korn overdrive, what would this look like without the bashisms? Dominus uses BASH_REMATCH to split a decimal fraction at the decimal point, thus splitting ‘fff.iii’ into ‘fff’ and ‘iii’. That can be done using portable shell syntax (that is, blessed by the Single Unix Specification) using the ‘%’ and ‘#’ features of parameter expansion. Example:

$ f=3.142
$ echo ${f%.*}
3
$ echo ${f#*.}
142

In shell, «${f}» is the value of the variable (parameter) f; you probably knew that. «${f%pattern}» removes any final part of f that matches pattern (which is a shell pattern, not a regular expression). «${f#pattern}» removes any initial part of f that matches pattern (full technical details: they remove the shortest match; use %% and ## for greedy versions).

Thus, between them «${f%.*}» and «${f#*.}» are the integer part and fractional part (respectively) of the decimal fraction. The only problem is when the number has no decimal point. Well, Dominus special cased that too. Of course the “=~” operator is a bashism (did perl inspire bash, or the other way around?), so portable shell programmers have to use ‘case’ (which traditionally was always preferred even when ‘[' could be used because 'case' didn't fork another process). At least this version features a secret owl hidden away (on line 3):

to_rational () {
  case $1 in
    (*.*) i_part=${1%.*} f_part=${1#*.}
      n="$i_part$f_part"
      d=$(( 10 ** ${#f_part} )) ;;
    (*) n=$1 d=1 ;;
  esac
}

The '**' in the arithmetic expression raised a doubt in my mind and, *sigh*, it turns out that it's not portable either (it does work in 'ksh', but it's not in the Single Unix Specification). Purists have to use a while loop to add a '0' digit for every digit removed from f_part:

to_rational () {
  case $1 in
    (*.*) i_part=${1%.*} f_part=${1#*.}
      n="$i_part$f_part"
      d=1;
      while [ -n "${f_part}" ] ; do
          d=${d}0
          f_part=${f_part%?}
      done ;;
    (*) n=$1 d=1 ;;
  esac
}

Traditional shell didn't support this «${f%.*}» stuff, but it's been in Single Unix Specification for ages. It's been difficult to find a Unix with a shell that didn't support this syntax since about the year 2000. It's time to start to be okay about using it.

demo$ echo pwd | ksh
/home/drj/hackdexy/content
demo$ echo pwd | bash
/home/drj/hackdexy/content
demo$ echo pwd | ksh -i
$ /home/drj/hackdexy/content
$ 
demo$ echo pwd | bash -i
drj$ pwd
/home/drj/hackdexy/content
drj$ exit
demo$ echo pwd | bash --norc -i
bash-4.2$ pwd
/home/drj/hackdexy/content
bash-4.2$ exit
demo$ echo pwd | sh -i
$ /home/drj/hackdexy/content
$ 
sh: Cannot set tty process group (No such process)
demo$ . ../bin/activate
(hackdexy)demo$ echo pwd | ksh -i
(hackdexy)demo$ /home/drj/hackdexy/content
(hackdexy)demo$ 
(hackdexy)demo$ deactivate

What have we learnt? (when stdin is not a terminal) shells do not issue prompts unless the “-i” option is used. That’s basically what “-i” does. bash, but not ksh, will echo the command. That has the effect of making bash’s output seem more like an interactive terminal session.

Both ‘bash’ and ‘ksh’ changed the prompt. ‘bash’ changed the prompt because it sources my ‘.bashrc’ and that sets PS1; ‘ksh’ changed my prompt, apparently because PS1 is not an exported shell variable, and so ‘ksh’ does not inherit PS1 from its parent process, and so sets it to the default of “$ “. If we stop ‘bash’ from sourcing ‘.bashrc’ by using the ‘–norc’ option (‘–posix’ will do as well) then it too will use its default prompt: the narcissistic “bash-4.2$ “.

‘sh’ (dash on my Ubuntu laptop, apparently), is like ‘ksh’ in that it does not echo the commands. But it does output a narked warning message.

The last command, after using ‘activate’ from virtualenv, demonstrates that ‘activate’ must export PS1. I think that is a bug, but I would welcome comment on this matter.

I guess most people use ‘bash’ and mostly set PS1 their ‘.bashrc’, so wouldn’t notice any of this subtlety (for example, they will not notice that ‘activate’ exports PS1 because the ‘.bashrc’ will set it to something different).

I note that the example login and ENV scripts given in The KornShell Command and Programming Language (p241 1989 edition) set PS1 is the login script only, and do not export it. Meaning that subshells will have the default prompt. I quite like that (it also means that subshells from an ‘activate’d shell will have the ‘activate’ prompt). Why doesn’t anyone do it like that any more?

It’s 1993 and as a graduate student in the Computer Lab I get an account on the shared Unix server. A DEC Alpha, running OSF/1. The Alpha was a true 64-bit chip, no 32-bit heritage in its history, no 32-bit mode, and basically no 32-bit arithmetic instructions. Everything was 64-bit, no hostages. As a C programmer this is quite funny. int was still 32-bit (with the usual compiler flags). It was clear that the Alpha with its elegant, very RISC, instruction set was an example a new breed of processor architecture.

In 1994 I started my first job and in the next few years I use and program a variety of 64-bit architectures. The Alpha, UltraSPARC, 64-bit MIPS; I read up on various others (HP PA-RISC 2.0, POWER/PowerPC), because it was clear that the future was one where everyone had a 64-bit RISC workstation on their desk. Unix was clearly the only operating system with a chance of running on 64-bit architectures; sure, I saw, and used briefly, Windows NT running on Alpha, but it was a sorry effort. A 32-bit port of NT onto a 64-bit architecture. Microsoft/Intel were barely making it on 32-bit architectures, never mind 64-bit.

When Intel’s IA-64 architecture came out, I read the manuals. It was clear that: a) Intel hadn’t been paying attention; and, b) no-one would be able to write a decent C compiler for this architecture.

What happens next? I really don’t know. Sun got sucked into Java and took their eye off the ball, every other manufacturer canned their 64-bit line or sold to someone who didn’t care, Intel’s efforts to actually implement their IA-64 architecture (Itanium) were indeed a massive failure, and Intel had to piss away the R&D for 2 or 3 entire generations of CPU design. The amazing thing is that even though Intel basically failed to innovate for like a decade (between Pentium Pro and Core) everyone worshipped them and gave Intel enough time (aka money) to steal their new 64-bit strategy from their competitor AMD. They had the DEC designers, and the fabs, and they eventually produced Core, which was actually pretty good from a hardware perspective. But still based on the awful Intel software architecture.

Which is where we are now.

Does anyone have any idea why all the very sensible and nice 64-bit architectures (SPARC, Alpa, MIPS, PowerPC, not PA-RISC) all failed basically together?

Here’s a few I’ve recently picked up or passed on:

cd -

It changes directory to the last directory that you changed from. It’s /bin/bash not /bin/sh (so I personally would avoid writing it in scripts). I think someone alleged that this was undocumented, but in fact I recently checked and it is in fact documented in the builtins section of the /bin/bash man page, which is huge.

It’s useful when you want to cd to some directory to run a command, but then cd back.

Line 25 of the runlocal script in ScraperWiki used to do just that in order to start a service from within a different current directory:

cd ../services/scriptmgr
node ./scriptmgr.js &
cd -

Because I don’t like writing bash-specific scripts, I changed this to use a subshell, with round brackets:

(
    cd ../services/scriptmgr
    node ./scriptmgr.js &
)

A subshell is used to run the code between the round brackets, and it is just a forked copy of the shell. It has exactly the same environment (environment variables, open files, and so on), but is in another process. Since the Current Working Directory is specific to the process, changing it in the subshell has no effect on the outer shell, which carries on unaffected after the subshell has returned. So that’s something I’ve passed on recently.

cp foo.cnf{-inhg,}

This is the same as cp foo.cnf-inhg foo.cnf. It copies a file by removing the -inhg extension from its name. ScraperWiki stores some config files in Mercurial (the -inhg versions), and they are copied so they can be edited locally (the versions without the -inhg suffix). I’m sure this has all sorts of evil uses.

sudo !!

Of the things I’ve picked up recently, this is my favourite. I like how some of these tips are a combination of things that I already knew individually but hadn’t thought to combine. Of course I know that sudo thing runs thing as root, and I did once know that !! is the /bin/csh mechanism (stolen by /bin/bash) for executing the previously typed command. In combination, sudo !! runs the previously typed command as root. Which is perfect for when you typed pip install thinginator instead of sudo pip install thinginator.

Ctrl-R

The favourite thing I seem to have spread seems to be Ctrl-R. (in /bin/bash) you press Ctrl-R, start typing, and bash will search for what you type in your command history; press Return to execute the command or Ctrl-R to find the next older match. Press Ctrl-C if you didn’t really want to do that.

Credits

One of the @pysheff crowd for sudo !!; can’t remember whether it was @davbo or @dchetwynd.

Ross Jones for cd -;

Bitbucket user mammadori “{-ext,}”.

If you enjoyed this post, you may also like Mark Dominus’ semi-rant on the craptastic way to do calculation in shell scripts. Huh, now I feel compelled to that Mark gets it wrong about GNU Shell; arithmetic expansion is not a GNU innovation, it comes from POSIX, having been slightly mutated from an earlier Korn Shell feature. And if he had comments I would’ve said that on his “blag”.

Two of us were working at the client’s site on the software for what was essentially a compact static robot that was responsible for moving small items from a hopper to a delivery point. There was approximately one instance of the hardware that we were writing software for, and it sat on a bench between our two workstations. Most of the mechanical bits were in a more or less finished state. I was particularly impressed with the piston that generated partial vacuum so that items could be picked with a moving arm with suction cups on. Just one or two gears were made of prototyping plastic; and because of a gearing problem the belt didn’t move at the speed that it said it should in the spec. But you know, typical prototype hardware. The electronics were a mixture of off-the-shelf dev kits for 8-bit embedded micros, mini custom circuit boards for novel sensors, and lovingly hand soldered discrete parts. Add to that the fact that as a software guy I didn’t really understand the importance of grounding, and La Machine wasn’t always completely reliable (my colleague had just lent me Tracy Kidder’s Soul of a New Machine).

Various optical/IR sensors kept track of the items as they moved inside the internals of the machine, various other sensors kept track of motor positions and/or speeds. There was a slightly hairy state machine (documented using OmniGraffle) to keep track of it all. The target pick rate was 5 items per second, and as it took more than 200ms for an item to go from the hopper to the point where it left the machine, there could be several items “in-flight” at any one time (and of course, picking an item was never completely reliable, so the sensors were used to track the items, and determine if a retry was required).

This day it seemed to be working fine, except for some reason the software was reporting that items were failing to be delivered, when in fact I could plainly see that items were popping out of the top of the machine. This was causing the machine to prematurely stop, as it would, sensibly, stop picking items if it thought that a picked item was stuck inside the machine somewhere. Up to this point it had basically been working fine; it had been working the same morning. I was sat thinking about this and investigating somewhat. I’d even checked the last thing I’d changed. So I called my colleague over (just at the next desk) and he came over to look while I demonstrated the problem. It worked. There was no problem. Flakies (there’s a memorable part of Kidder’s book where one of the engineers in helping a more junior engineer sort out a problem with a wire-wrap memory board, grabs the whole frame and shakes it, claiming that it’s probably just flakies; of course it works after that).

So that’s okay then. But when I try it again, it’s not working. Colleague comes over. Works. I work at it on my own. Doesn’t work.

It turned out that it was quite a sunny day. The sun reached the window in the afternoon. Sunlight was falling on machine near the optical sensor and presumably bouncing around enough to prevent the sensor from registering the occlusion as the item went past. When my colleague came over, he was standing over the machine and his shadow blocked the sunlight. This wouldn’t be a problem in the production hardware, as it was all in a box (and hence, dark inside).

I constructed an optical shield and installed it on La Machine (a post-it note stuck to the side).

This was not a problem that could be fixed using print. We did have print via the serial port, but printing more than one character was hazardous because it meant that time taken to transmit characters on the serial line would interfere with the realtime operation of the rest of the software (when items are being picked every 200ms, every millisecond counts).