Archives for Coding
09 November 2009
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.
28 January 2007
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.
26 January 2006
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.
30 December 2005
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.
21 June 2005
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:
f = open(filename)
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:
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).
04 February 2005
- Bluetooth for your Mac (built-in or external dongle).
- Java 1.3.1 (should come with Mac OS X Panther).
Download X11 for Mac OS X (about 40 mb). To install, open the .dmg file and double-click the .pkg.
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.
Download j2me.zip, a sample j2me program from Sun. Unzip it to any directory.
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.
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.
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.
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).
29 January 2005
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
ascape , and
Anyone know of anything like this for a microcontroller?
18 January 2005
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
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".
08 January 2005
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.
19 September 2004
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.
05 August 2004
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.
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?
don't throw exceptions when the socket connection dies.
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
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).
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.
VS 2005's console toolwindow (the new default is to launch console applications inside of a VS window)
The new debugging datatips in Visual Studio 2005 (much nicer than the yellow tooltips, but not quite intuitive).
01 May 2004
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