Thursday, September 23, 2010

If Eclipse views could talk...

If the various Eclipse views in the default Java perspective could talk, what would they say?

Package explorer: Here are the projects in your workspace!  Look, I can actually present them in a sensible way!  Not like some IDEs I could mention.  Yeah, you can have multiple projects open at the same time.

Java editor: I know what your code means!  I will automate boring tasks like adding getters and setters for you.  I will let you know when you've made a mistake.  You'll probably want to override my ugly default syntax-coloring choices.

JUnit: What am I doing over here in the left-hand pane?  Sure, you'll be able to see whether or not the bar is green, but the stack trace is much too narrow to show you the text of a failed assertion. Hey, why don't you move me down to the bottom pane?  Ahhh...that's much better.  By the way, if assertTrue or assertFalse fails, I'll let you know with the message "Assertion failed: null".

Type hierarchy: Let me tell you why I'm here.  Uh...hold on...I'm pretty sure there's something I can do that's useful...uh...crap, I can't think of why you would actually need to use me.  That sucks. Oh well, at least I'm not taking up any of your valuable screen real estate over here as a hidden tab in the left-hand pane.

Mylyn: Hi!  I'm Mylyn!  Every other view is named in a way that clearly indicates its purpose, but not me!  I'm Mylyn!  If you were an elite developer, you'd know what I'm for.  Apparently you're not an elite developer.  I'm Mylyn!  I need one-sixth of your screen! I'm Mylyn!  Wait, don't close me!  I'm My [click]

Outline: Hey, here's a concise list of your fields and methods! If your class gets really complicated, this will help you navigate around it.  Sure, this right-hand pane that I'm in is taking up about a third of the screen on that netbook you're using, but I'm totally worth it.  Wait...if you use proper object-oriented design, the class won't get complicated?  I don't believe it.  Wait...don't close me!  I [click]

Console: Here's your standard output.  You can type stuff here as standard input, too.  However, I adamantly refuse to position the cursor in any way that would indicate where the next character of output (or echoed input) will be generated.  Nor will I accept ANSI escape codes.  This big red button to kill the process is pretty useful, though.

Thursday, August 19, 2010

ASUS 1005HA netbook - first impressions

My new netbook (Asus 1005HA, Linux version) arrived today. I bought it to replace my Lenovo X61 tablet, not for any technical reason, but because the X61 won't fit in the trunk bag on my bicycle.

Software: The preinstalled Linux (Xandros?) is crap, so I immediately installed the Ubuntu 10.04 netbook remix. I have to say that I am extremely impressed with Ubuntu. There is a nice application launcher (in place of a traditional desktop.) The window manager uses the "one maximized application at a time" model, which I initially thought would be annoying, but is actually really nice. Each running app gets a small icon on the panel, and Alt-Tab switches between apps. Very good use is made of the limited (1024x600) screen real estate. I found it easy to add a new application launcher (for Eclipse!), and to add launchers to the "Favorites" category. Connecting to wireless networks (WPA and WEP) worked flawlessly. Installing software from the package repositories (openjdk, subversion) worked great.

Hardware: Awesome! The screen is bright and sharp. The keyboard is much better than I expected - I can type at close to full speed. The track pad works very well, and dragging on the right edge scrolls up and down. I haven't run any benchmarks, but it seems quite responsive. I installed Eclipse and did a bit of Java programming, and performance was fine. (It's some kind of Atom which supports hyperthreading.) Battery life is predicted (by the Ubuntu battery meter) at about 5.5 hours, which seems reasonable. I am waiting for a 2GB memory module to arrive, but with the pre-installed 1GB it works just fine. And the size - it really is significantly smaller and lighter than any traditional notebook, even ultraportables.

Overall: I really like it a lot so far. I'm looking forward to seeing how well it can handle serious work during the school year.

What I Did This Summer

It's been a busy summer. Things that I did (in absolutely no order):
  1. Full-time parenting. This was by far the most interesting and rewarding activity. Eli is now talking up a storm, and Gus is almost walking. I can now sing the themes to Super Why and Dinosaur Train from memory.
  2. Went to Charlotte to visit the Bridges clan. Lots of fun, but US Airways now on enemies list.
  3. Vacationed in Dewey Beach, DE with Bridges, Hovemeyer, and Swope families. Good times! However, fantasized about formally suggesting "Drunken Frat Boy, DE" as new name for town.
  4. Continued work done by YCP undergrads (hi Ray and Brandon!) to create an RTOS for AVR microcontrollers. The kernel is 100% C (no assembly)! Planning to somehow get a SIGCSE or CCSCE paper out of this.
  5. Successfully programmed a 22V10 GAL, for both combinational and stateful logic. (I need to break down and actually learn about FPGAs sometime.)
  6. Attended Heisler/Williams wedding reception and Hoyt/Spacco wedding. Latter involved travel to Chicago. Reconnected with UMD peeps.
  7. Advised one student doing an internship for credit, and another taking a course by tutorial.
  8. Retooling of Programming Language Design course.
  9. ABET stuff (don't ask.)
  10. Read all 3 books by Stieg Larsson. Highly recommended.
  11. Got netbook. How did I live without one of these? Lenovo X61 notebook now seems hopelessly large and cumbersome.
  12. Rode bike many times. Planning to use as main commuting vehicle during school year when weather cooperates.
  13. Reviewed a book.
  14. Attended CCSCE 2010 organizational meeting.
  15. Lunch at Victory Brewing Company twice with Kate to celebrate aniversaries.
There's probably some other stuff I forgot.

Thursday, May 27, 2010

using git to track marmoset svn repository

I'm doing some work on marmoset this summer. As an experiment, I'm doing my development in a git repository, using git-svn to track changes in the main svn repository. My changes are somewhat experimental, so I didn't want to commit to svn HEAD, and svn branches are so 1990s. We'll see how it goes. I'm also pushing my changes to a publically-visible git repos:

Thursday, April 29, 2010

Greatest Song Ever

Here's a screenshot of Pandora playing the greatest song ever:

Some of the things I was obsessed with in high school haven't stood the test of time, but The Smiths most definitely have.

Monday, April 12, 2010

gdb debugging using simavr

I just got debugging using gdb working with simavr. It's as simple as putting
avr->gdb_port = 1234;
avr->state = cpu_Stopped;
in the code that preceeds the simulation loop. Then, start avr-gdb (using the name of your firmware ELF file as the executable), and issue the command "target remote localhost:1234". Presto, you're debugging your firmware. Sweet.

Saturday, April 10, 2010


One of the headaches of developing code for an embedded system is the difficulty of debugging target code. I suppose you can use an ICE if you have money and expertise, but a nice simple alternative is a software simulator.

I just discovered simavr, which is an open-source software simulator for AVR microcontrollers. It is a library which simulates a variety of AVR cores, and has hooks through which you can emulate hardware (such as devices attached to I/O pins). The idea is you write a C program which defines your hook functions, and then call into the library to run the actual simulation.

I was able to get a "blinking LED" program working in a couple hours by adapting the example code. I used ANSI control sequences to visualize the pins of an output port, but you can use any kind of UI you want. It looks as though simavr supports debugging of the target firmware using gdb, which is totally awesome. I will try that next.

Fare thee well, Firefox?

Is it just me, or has firefox gotten to be intolerably slow to start up? I've timed it, and 10-15 seconds is not unusual on the computers I use.

I'm trying out Google Chrome, and I have to say, it seems a lot more responsive.

It doesn't seem all that long ago that I was trying out Phoenix (remember when it was called that?) and it was the best browser out there. I think Firefox was more or less perfect fairly early in its development. I can distinctly remember thinking, in the 2.0 days, "Why is development continuing? It already does everything it needs to do."

I suppose in 10 years I'll be posting about how bloated Chrome has become.

Wednesday, March 24, 2010

Makefiles 101

Just finished up some lecture notes on building C/C++ programs using a makefile:
I think I've covered the essential concepts and techniques, although I should probably include a complete example (program and makefile). We'll see how it goes in class...

Monday, February 22, 2010

More progress on OO language interpreter

Garbage collection is now (I think?) working in Thud, my object-oriented scripting language:
[dhovemey@nobby]$ cat LongLoop.thud
# With the heap set to 8192 objects,
# this program causes the garbage collector to run.

import System::IO;

var n = 0;
while (n < 9000) {
n = n + 1;

[dhovemey@nobby]$ thud LongLoop.thud
At this point, the compiler and bytecode interpreter are more or less working. What remains is to add all of the standard library classes needed to make it a useful language: I/O, containers, regular expressions, etc.

I began this project with the idea that implementing a language like Python or Ruby would be a fairly easy task. Well, it was harder than I thought it would be, but really not that hard overall. Right now, there are about 15,000 lines of source, including comments and whitespace. This is bloated somewhat by the 2,500 or so lines generated by bison for the parser, and also the fact that I essentially recreated the Java I/O classes (streams, readers/writers, etc.) rather than use iostreams.

[Aside: is it just me, or is iostreams ridiculously complicated?]

Eventually, I'm hoping to use Thud as my main day-to-day scripting language. In the longer term, it would be an interesting project to replace the bytecode-interpreter-based virtual machine with one based on LLVM.

Wednesday, February 3, 2010

Last one

I could post more of these, but I'll stop with this one.

More random art

This random art stuff is really just too cool for words:

Random Art

I'm implementing Christopher Stone's Random Art Nifty Assignment in preparation for assigning it in a data structures course I'm teaching. Since the assignment involves the creation of "random" functions of two variables, it's a good opportunity to discuss the idea of using trees to represent expressions.

Obligatory screenshot of first successful run of the program:

This is an extremely cool assignment.

Friday, January 22, 2010

Hello, world

I have been working on an interpreter for a simple dynamic OO programming language (vaguely like Java, but dynamically typed like Ruby.)

Today I got a hello world program to run:
[dhovemey@nobby]$ ThudC Hello.thud
[dhovemey@nobby]$ ThudDisAsm Main\$.thudc
class Main$ {
method main$() {
0: push_module_ref 2(System::IO)
3: load_field 4(out)
6: push_const 5(Hello, world!)
9: call 7(println) 2
13: pop
14: push_nil
15: return
[dhovemey@nobby]$ thud Hello.thud
Hello, world!
[dhovemey@nobby]$ echo $?
[dhovemey@nobby]$ cat Hello.thud
import System::IO;

IO.out.println("Hello, world!");
Oh yeah.

Note that in the example above, the source file "Hello.thud" produces a compiled class called "Main$" because that is a special class generated for "top-level" statements in a source file. The idea is to make the language useful as a scripting language, where many programs will be a sequence of statements that use the built-in classes.

The language (and its implementation) is currently called "Thud", which is one of the standard metasyntactic variables. It's also the title of one of the recent Discworld novels by Terry Pratchett.

There is still a lot of work to do before the interpreter is actually useful:
  • Currently, there is no garbage collection.
  • The built-in types support very few methods. For example, the built-in Int32 type does not support any arithmetic methods.
  • The IO facility is limited to printing to stdout.
I started this project quite a while ago because I was frustrated with both Perl and Ruby. I know Perl quite well, but find it to be exceedingly ugly to write programs in. I tend to like Ruby in theory, especially because it is a pure OO language (where all values are objects). However, I find that Ruby suffers from cryptic syntax. I gave up trying to learn Ruby on rails because I find that significant chunks of rails code---especially the ones that look like anonymous hashes hanging in space---to be deeply impenetrable.

I freely admit that the world does not need another OO scripting language, but it has been a lot of fun designing and implementing one.

The Thud virtual is based on a bytecode interpreter. There are exactly 17 opcodes. There are no static fields or static methods---instead, the same effect is achieved by having "modules", which are singleton classes. (For example, System::IO is a module.)

I will be posting the source code (free software, of course) in the near future.