Updated XBee library for Processing

For a project in my group, we needed to talk to multiple XBee radios from a computer. I adapted the XBee API library for Processing by Rob Faludi and Daniel Shiffman, adding methods for sending and receiving serial data (Series 1 radios only).

To send data to a specific radio (identified by its 16-bit address), you use the xbee.sendDataString16(int addr, int[] bytes) function. There's a new constant, xbee.SERIES1_RX16PACKET, that's returned by XBeeDataFrame.getApiID() for incoming data from a radio. XBeeDataFrame's with this API ID support the getAddress16() and getBytes() methods.

Download: xbee-api-library-for-processing-1.5.zip

ArduinoBlocks

Wow. Someone went ahead and made a graphical programming language for Arduino. From the blog entry:

Finally I can release an Alpha Version of ArduinoBlocks. Only the Windows Version ist availible for download as you have to compile it for the different OSs and also for the different Mac processors. The idea is to have a visual blocks language for children that is translated into Arduino code.

I managed to get it running on my Mac by copying the .jars into a copy of my Arduino 0007 directory. Here's a program to blink an LED:

This is a lot like the programming interface for the Pico Crickets, but not quite as refined.

Working?

Working?
Originally uploaded by dam.

I've been developing my earlier ideas about understanding code into a design for an interface. Here are some sketches of wireframes for the software. By my next presentation (during the week of the 19th of February), I plan to evolve these sketches into a complete design.

Adding jars to your classpath in Xcode

It's difficult to reference external .jar files in the classpath passed to the Java compiler by Xcode. Or, at least, it took me a long time to figure out how it works. The secret is adding the .jar file to the "Java Classes" search path of the project's target. The tricky part is that the dialog box that appears when you press the "+" sign will only let you select a directory - pick the directory containing the .jar, press "Add", and then double-click the newly added entry. Simply append the name of the .jar file to the directory path. Then it will be added to the classpath passed to the Java compiler. (In the expert view, the JAVA_CLASS_SEARCH_PATHS variable will display a space-separated list of the .jars.)

Note that this won't add the .jar to the runtime classpath. You'll also need to add it to the Classpath list in the "Pure Java Specific" section of the Target properties.

Language Design Insight from Python

The Python Enhancement Proposals seem, at first glance, a suprisingly place to find insight into programming language design. On further reflection, though, it appears inevitable that documents designed to justify, explain, and specify new features in a superbly-thought-out language would be models of clarity, conciseness, and interest. Along, with Paul Graham's essays (e.g. on Arc and Lisp), I recommend them to anyone interested in programming or software design (even if you abhor semantically-significant white-space in source code).

PEP 343: Anonymous Block Redux and Generator Enhancements proposes new syntax and keywords for Python. While fairly technical, this gets at the heart of language design: what abstractions and structures get encoded into the syntax, and how? Guido van Rossum, creator of Python, offers specific reasons for preferring one notation over another and insights into the way in which such designs evolve.

Here's an excerpt to give you an idea of the style (don't worry, it makes sense in context):

The idea was to define the template like this:

        @with_template
        def opening(filename):
            f = open(filename)
            try:
                yield f
            finally:
                f.close()

and used it like this:

        with f = opening(filename):
            ...read data from f...

The problem is that in PEP 310, the result of calling EXPR is assigned directly to VAR, and then VAR's __exit__() method is called upon exit from BLOCK1. But here, VAR clearly needs to receive the opened file, and that would mean that __exit__() would have to be a method on the file.

PEP 318 discusses various proposed syntaxes for function decorators, which ended up looking like this:

        @classmethod
        @synchronized(lock)
        def foo(cls):
            pass

This was only agreed on, however, after months of battle and hundreds of alternatives, and the PEP has links to all the gory details. It's good to see people passionate about the fine details of programming, even if it means spending weeks arguing over the relative merits of ! and @.

Other interesting PEPs include Iterators (#234), Simple Generators (#255) and Generator Expressions (#289).

Developing Symbian 60 Java Apps on Mac OS X

You need:

• Bluetooth for your Mac (built-in or external dongle).
• Java 1.3.1 (should come with Mac OS X Panther).

Instructions:

1. Download X11 for Mac OS X (about 40 mb). To install, open the .dmg file and double-click the .pkg.
2. Download MIDPv103.dmg.gz from the MIDP for Mac OS X page. Create a directory named j2me (all lower-case) in your Applications directory and copy the contents of the MIDP .dmg into it.
3. Download j2me.zip, a sample j2me program from Sun. Unzip it to any directory.
4. The zip file includes an already compiled version of the demo that you can transfer to your phone and try. It's in the bin directory, and called demo.jar. Try transferring it to your phone with Bluetooth. You should now see a program called ManyBalls in your menu. If you run, you should see a ball bouncing around the screen. Use the arrow keys to change the settings.
5. Now, you can try to compile the demo yourself. Launch the Terminal (from Applications:Utilities) and change into the directory where you unzipped j2me.zip. For example: cd ~/Desktop/j2me.
6. Type ./bin/build.sh. You should see a message that a jar file was created. You should now see a balls.jar file in the bin directory.
7. Try uploading balls.jar to your phone (if you already uploaded the pre-compiled demo.jar, delete the ManyBalls program from your phone so you can be sure that the new one works).

Microcontroller Multithreading

While helping people work on their Wiring programs, I noticed that a common difficulty is trying to do multiple independent things at once. Even something as simple as blinking two LEDs at different rates is tricky without multithreading. I can imagine a system similar to Flash, with objects, events (including timers), modes (similar to different key frames), and finally code. So a button press would trigger an event (pin went low), which could run a piece of code that set a flag to tell an LED to start blinking. The LED would be handled in an event that fires every second, say, and if the blink flag is set, turns on or off.

This is also similar to agent-based programming systems like starlogo, swarm, ascape , and repast. Anyone know of anything like this for a microcontroller?

Why You Should Always Use Header Files

I spent an ungodly amount of time today tracking down a bug that was causing some float point values to print (over the serial port from the Atmel atmega128) as garbage. I had a function in a C library that returned a float, and I was linking against the library without a header file. I'm guessing that when linking my main C file, the compiler, not seeing a declaration for my function, assumed that it returned an int and generated a cast to convert it to a float. Then, the floating point value returned by the actual function was getting mangled.

Now, if only I could get avr-libc's printf to output floating point numbers itself. And I could link against the library without hacking the calloc source to repeatedly add instead of multiply, thus avoiding an error to the effect of "undefined reference to __mulhi3".

Computer Science vs. Programming

Joel on Software, in the midst of some good advice for programmers in college, explains why I wanted my IDII bio to include “software development” not “computer science”:

Dynamic Logic is appealing to brilliant theoreticians like Professor Zuck because it holds up the hope that you might be able to formally prove things about computer programs, which could be very useful, if, for example, you could formally prove that the Mars Rover's flash card wouldn't overflow and cause itself to be rebooted again and again all day long when it's supposed to be driving around the red planet looking for Marvin the Martian.

So in the first day of that class, Dr. Zuck filled up two entire whiteboards and quite a lot of the wall next to the whiteboards proving that if you have a light switch, and the light was off, and you flip the switch, the light will then be on.

The proof was insanely complicated, and very error-prone. It was harder to prove that the proof was correct than to convince yourself of the fact that switching a light switch turns on the light. Indeed the multiple whiteboards of proof included many skipped steps, skipped because they were too tedious to go into formally. Many steps were reached using the long-cherished method of Proof by Induction, others by Proof by Reductio ad Absurdum, and still others using Proof by Graduate Student.

For our homework, we had to prove the converse: if the light was off, and it's on now, prove that you flipped it.

I tried, I really did.

I spent hours in the library trying.

After a couple of hours I found a mistake in Dr. Zuck's original proof which I was trying to emulate. Probably I copied it down wrong, but it made me realize something: if it takes three hours of filling up blackboards to prove something trivial, allowing hundreds of opportunities for mistakes to slip in, this mechanism would never be able to prove things that are interesting.

Not that that matters to dynamic logicians: they're not in it for useful, they're in it for tenure.

I dropped the class and vowed never to go to graduate school in Computer Science.

The moral of the story is that computer science is not the same as software development. If you're really really lucky, your school might have a decent software development curriculum, although, they might not, because elite schools think that teaching practical skills is better left to the technical-vocational institutes and the prison rehabilitation programs. You can learn mere programming anywhere. We are Yale University, and we Mold Future World Leaders. You think your $160,000 tuition entititles you to learn about while loops? What do you think this is, some fly-by-night Java seminar at the Airport Marriott? Pshaw.

I've done a lot of software development and math, but, so far, little computer science. Maybe that'll be my next degree.

Inkfall

I was playing around with Processing and came up with this simple simulation of ink falling into a maze. The source code is also available. I'm hoping to work on my design skills this year. If you have any suggestions, let me know.

Branching project and solution files in Visual Studio Team System (should work much better than in SourceSafe)

Writing serious Perl: The absolute minimum you need to know

.NET Socket Bugs & Gotchas

Here are a some bugs and subtleties in the .NET System.Sockets.Net library (or documentation) that have burned me while doing C# development. Network programming isn't easy, but Microsoft's poor implementation and documentation of these classes make it even harder.

TcpClient.Close() doesn't close the socket connection.

This is apparently by design, though you won't find that anywhere in the documentation (until Whidbey and version 2.0 of the .NET Framework). When you call TcpClient.GetStream(), the returned NetworkStream becomes the owner of the underlying socket. To close the socket, call TcpClient.GetStream().Close(). TcpClient.Close() should work if you never called GetStream(), but I wouldn't count on that behavior continuing in Whidbey. In fact, I'm not sure what the .NET 2.0 version of TcpClient.Close() does. Isn't the socket the only resource that needs to be disposed of?

Socket.Available and NetworkStream.DataAvailable don't throw exceptions when the socket connection dies.

The documentation wrongly says that these properties will throw a SocketException if “the remote host shuts down or closes the connection.” In fact, the documentation of the Winsock function ioctlsocket(sock, FIONREAD, &argp) (which these properties wrap) says that an error is returned (and thus an exception thrown) only in a few rare cases (namely WSANOTINITIALISED 10093 if WSAStartup was never called, WSAENETDOWN 10050 if the network is down or the network stack is full, WSAEINPROGRESS 10036 if another blocking operation is in progress, WSAENOTSOCK 10038 if the file descriptor is not a socket, and WSAEFAULT 10014 if argp is an invalid pointer) and not if the socket simply disconnects. Also, you shouldn't rely on the accuracy of the number returned from Socket.Available (see Microsoft Knowledge Base Article #192599 for details).

Socket.Connected doesn't check that the socket is currently connected, only that it was as of the last IO operation.

That is, this propery never tells you anything you didn't already know. If your socket never connected, it's not connected. If your last call to send or receive threw something other than WSAEWOULDBLOCK 10035, the socket isn't connected. Etc. The .NET 2.0 documentation suggests a dance involving messing with the socket's blocking mode and sending zero bytes over it, but that doesn't work either.

The only reliable way to detect a network disconnection is by reading or writing to the Socket (or TcpClient, or whatever). By default, those are blocking operations. You'll need to either use the asynchronous BeginReceive and BeginSend or BeginRead and BeginWrite (but be sure to check for exceptions thrown by the corresponding End function); make your socket non-blocking, call Socket.Poll or Socket.Select before sending or receiving, or do your socket operations on their own thread. Again, network programming is not a trivial task. I hope this had made it a little easier.

If you've had any other problems with these socket libraries, or have any other suggestions for working around them, let me know. For other problems with .NET, check out this helpful list of .NET bugs. If ever a .NET function doesn't do what you expect, look through its source with the .NET Reflector, which I used to help solve these socket problems.

Josh Ledgard ("chief community evangelist" for Visual Studio) talks about the MSDN product feedback center.

Discussion on how C# project references work and improvements for Whidbey.

How should C# Intellisense filter its list of options?

VS 2005's console toolwindow (the new default is to launch console applications inside of a VS window)

jaybaz on refactorings in Whidbey with specifics on signature changes and rename.

The new debugging datatips in Visual Studio 2005 (much nicer than the yellow tooltips, but not quite intuitive).

Discussion on Eric Gunnerson's C# Compendium about possible future C# language features and scenarios.

Cyrus talks about how the C# Intellisense might handle errors and why the VS editor behaves differently for different languages.

Thoughts on C#

I've been programming in C# for the past few weeks at work, and I wanted to record some of my thoughts. It's a well designed language overall, and the .NET Framework has been a useful library. If only the IDE wasn't a constant source of frustration and anger.

Here, then, are some of the main differences between C# and C++ (the language I know best).

• C# is a higher level, interpreted language. In C++, you play tricks with your data structures by reading and writing their memory directly, using pointers. In C#, these are replaced by reflection, a more powerful, but slower, method of instantiating runtime-typed objects or retrieving a listing of an object's methods or fields. My C# code loads a lot of objects from strings in configuration files, making it easier to change my program's behavior without recompiling. It can also help separate infrastructure code from application logic.
• C# has garbage collection but makes it difficult to deterministically despose of objects or resources. This means I don't have to worry (much) about memory leaks, but I could easily avoid them in C++ by using a smart pointer like boost's shared_ptr. The lack of C++ style destructors is a pain, though there's some good reasoning behind it. (Remember, there's nothing in C++ to stop you from returning a pointer to a local variable.) I still haven't found a use for the finalize method, since you can't seem to assume anything about the program's state when it's called, but the Dispose method and using directive are a useful substitute (and an interesting mix of language keywords and specific classes; more on this below).
• C# sometimes conflates the underlying language with your code. Certain keywords act on particular interfaces, as in the example above and foreach with the IEnumerable interface. Also, the compiler automatically generates certain methods, like Begin- and EndInvoke on delegates. This is very convenient but feels improper. C++ does a bit of this with operator overloading, but C# goes far beyond thet.

There are more differences, but I'd rather talk about the problems with C#. Here's a partial list.

• The documentation sucks. It's impossible to find useful information among all the crap about DirectX, COM, and the N other technologies you don't use. When you do find the class or function you care about, it doesn't tell you what you need to know, or else it's wrong. For example, TcpClient.Close() doesn't disconnect your socket, contrary to its description (you have to use TcpClient.GetStream().Close() instead). And Thread.Abort() doesn't kill the thread it's called on (it throws an exception in the thread that called it). And many classes are described only as “internal to the .NET Framework”, including useful things like the IXmlSerializable interface that lets you customize the XML serialization of a class. And you have to follow extra links to find out basic information, like the namespace of a class or the parameters of a function. And the Longhorn documentation crashes Internet Explorer (but then, so does Microsoft Project). And so on. It's inexcusable.
• The lack of flexibility of certain classes. The System.Configuration includes some convenient classes for reading from a configuration file, as long as you don't need to specify the file. In fact, .NET's configuration works badly in general, and doesn't even do the one thing it's supposed to: allow your program to always find its settings. Another restrictive class is RemotingConfiguration. Channels cannot be unloaded, and Configure can only be called once. Apparently, the recommended way to stop listening on a port (with remoting) is to restart your process.
• The string.Format function. It may be less kludgy than C++'s strean operators, but it's also a return to the days of C's unchecked function parameters. In this case, the runtime stops you from mangling you memory, but will happily throw exceptions at very inconvient times. C++'s output routines can generally be verified by the compiler, an important safeguard.

I have a few other minor quibbles with C#, but its flaws pale in comparison to those of Visual Studio. I don't understand how the same company can create such a well-done language and such a poor tool for using it. It's an insult to the designers of C# and those of us trying to use it. But don't worry, as we say at work with each newly-discovered or re-encoutered flaw, it'll all be better in Longhorn.