transterpreter » Always Where

the open group @ allegheny college

How is a research group at a small, liberal arts college born? I think you get some students working on related things, and declare them a group. That, and have them over for dinner at least once.

Background (not so important)

My current research focuses on the behavior of novice programmers and the development of tools for parallel programming on small embedded systems. Long term, I am interested in the usability of programming languages—which lies at the intersection of my current lines of research inquiry.

One reason I take a long view on my research because I am at the start of my career. Another is that I am committed to involving students at Allegheny College with diverse backgrounds in my research. For these reasons, I paint my research with a broad brush to better support more students with more interests. In doing so, I can productively move my research forward regardless of what interests my students might have in any given year. It also makes it easier to collaborate across disciplinary boundaries when you keep an open mind regarding where your work can be applied.

The Students (very important)

This semester, I am excited to be working with four students. Stephanie Cost and Sara Doan (both Allegheny ’11) have been learning the foundations of image manipulation using Python, with an eye towards image analysis and transformation. Their work is funded by the Collaborative Research Experiences for Undergraduates programme, and is titled Operation: Stick Figure Army. Their project explores the problem of transforming 2D images into 3D models suitable for printing on the Makerbot Cupcake CNC 3D printer (project overview). The goal is to produce an open source set of tools for supporting blind readers—images are the bane of a blind student’s existence, as they translate poorly using existing printing technologies. Our hope is that low-cost, personal fabrication technologies like the Cupcake CNC (along with usable, open software tools) will create new opportunities for blind readers in this space. Both Sara and Stephanie are doing excellent work, and I’m excited to have the entire year (both semesters plus the summer) to work with them on this project.

Although this is our Fall Break, I spent two hours today catching up with Radu Creanga (Allegheny ’11), who is helping our distributed group bring parallel programming to the Arduino platform. Using the occam-pi programming language and executing on the Transterpreter virtual machine, Radu has quickly learned the joys of checking out an open source project, cross-compiling it from source, and doing hardware-level additions to our library for safe, process-based parallel programming called Plumbing. You can follow his work online (project overview, more posts coming soon), and both his software and documentation will be part of our pending release at concurrency.cc.

Last, but not least, Drew Pirrone-Brusse (Allegheny ’10) is working on Verbing Stories. Drew is pursuing a self-designed major at the intersection of Communication Arts and Computer Science, and this semester we are exploring Kodu (and, time permitting, Scratch) as platforms for interactive storyboarding in the context of game design and creation. While Kodu is not an open platform, we hope that our work will provide inspiration for others interested in the use of novice programming environments for interactively exploring the role of story in game development.

In later posts, I’ll point out where some of our infrastructure (repositories, etc.) live. In the meantime, I wanted to introduce the exciting projects that these students are engaged in. If you’re so inclined, you can also follow their work at planet.baseplate.org; for lack of a better name, we’ve named ourselves the Open Group @ Allegheny College, because we’re open to working with students on a wide range of projects, and we strive to make our work open source wherever and whenever possible.

Blogs: Stephanie/Sara (Operation: Stick Figure Army), Radu (Plumbing for the Arduino), Drew (Verbing Stories)

Planet: planet.baseplate.org

first package: lint free

I’ve managed to do an initial packaging for Fedora of the toolchain that we use for programming the Arduino (see post with cool video). This is a big step—it means I’ve learned something about packaging, and it means we’re closer to being able to provide a really cool educational tool to the Fedora community. There’s still plenty of work to be done, but I consider this pretty exciting.

From the IRC:

04:57 < jadudm> 1 packages and 0 specfiles checked; 0 errors, 0 warnings.
04:58 <@mchua> jadudm: yay!
04:58 <@humph> jadudm: !!!
04:58 <@ctyler> jadudm: congrats!
04:58 < jadudm> tyty

This is sweet, sweet awesomeness. This is the first time I’ve seen a packaging process for our tools through this way… while I’m not done, getting to the point that rpmlint gives me zero warnings and zero errors on a compiler toolchain is (for me) a milestone. I now need to clean this up fully, write a script to automate it (eg. checkout from SVN, tarball, upload, generate .spec file, rpmbuild, rpmlint), and then modularize that process for the AVR version. So there’s a bit more work to do, but it’s well within striking distance now. ctylers, ianweller, and others have been a great help in this process.

parallel blinkenlights

Omer Kilic (twitter)is now a PhD student at the University of Kent; I had the pleasure of working with him while I was there doing my degree a few years back. (In fact, Omer’s excitement about embedded systems is part of the reason why I finally got over my own fears about real hardware and started playing with small systems like the Arduino.) Adam Sampson has hooked him up with our nascent Plumbing library for the Arduino, and he has some tasty-tasty blinkenlights going on:

Parallel Blinkenlights! from Omer Kilic on Vimeo.

I’ll try to get a website and some getting started information up on the web in the near future. Plumbing is a library for handling input and output on the Arduino in a parallel-safe way, using the occam-pi programming language. The code for the above example probably looks something like this:

PROC main () PAR blink (13, 500) blink (10, 400) blink (7, 600) blink (4, 300) :

How do you do that?

For a number of years, we’ve been working with a language that is fundamentally parallel in nature. More importantly, the Transterpreter was at the core of Christian Jacobsen‘s doctoral work. The Transterpreter (other than having a really cool name) make it possible to run occam-pi programs on really tiny devices. The Arduino is an example of what I mean by a “tiny” device.

While I don’t know exactly how fast Omer is blinking the lights, I know he is blinking them in parallel. This means that they are blinking at the same time. When programming in occam-pi, you pretend that it is possible to do things simultaneously by writing PAR, and then you let the tools take care of everything else for you. I only say “pretend” because the Arduino only has one processor—but, despite this, we write PARallel code in occam-pi and let the tools take care of things, regardless of whether we have one processor or one thousand.

As a result, blinking four LEDs is one of the easiest things in the world to do. As you can see, Omer is blinking four pins at different rates of speed, all underneath one PAR block.

Open-source is Awesome

Everything we work on is open source (GPL/LGPL), and we have the first few chapters of a book drafted to support people learning with these tools. We’ve aimed the book at artists and (people are assuming are) non-programmers. That doesn’t mean we’re talking down—it just means we’re writing lots of tiny chapters that expose just one thing at a time. I’ll work on getting some minimal website up for the materials, get some mailing lists set up, and see if we can’t get a few people playing with the fun stuff. I wasn’t planning on releasing things this soon, but it looks like we’re starting to see a bit of interest. That must mean… it’s time to release!

You see, right now I’m out in Raleigh, NC taking part in POSSE (Professors’ Open Source Software Experience), which is graciously being hosted by Red Hat through the auspices of gdk. As Dr. Panic points out in his blog post about packaging software, I chose to do something other than “Hello, World” yesterday. I decided I’d try and get all the tools we need for the Arduino packaged up as a Red Hat package, so RH users could download things and dive in. That took a long time, and I’m not done yet… but I’m making good progress! Sadly, I can’t run myself under a PAR block… I’d be able to get so much more done…

We’ll get stuff online, and others can join in the fun. That can be part of tonight’s homework… along with everything else the POSSE organizers have us doing.

documentation and its role in open projects

Mel was musing on documentation in open projects recently.

In our recent code sprint on the Transterpreter project, we realized that for years we have had far too little documentation. Specifically, we’ve been lacking documentation on not just one front, but two.

First, we’ve lacked developer documentation. That didn’t change during our sprint. Someday, but not during this sprint.

Instead, we focused on a new (user-centered) platform and end-user documentation. Given that we are working on a language and a runtime for that language, it becomes difficult to document things for people. “I downloaded it… now what do I do?!” Invariably, we say “write some programs!” That’s… less than ideal. We realized that if we want more people to explore parallel programming for embedded systems, we’re going to have to provide an easy path for engaged beginners to dive in and be successful from the start.

So, we brought our language and runtime to the Arduino. (There’s some cool videos over on the Transterpreter blog; check it out.)

The Arduino is a piece of “open hardware,” meaning the design of the device is free and open. It is powered by the Atmel Atmega328, a 16MHz processor with 32K of flash and 2K of RAM. To many people, those are small numbers, but to us, they’re enough to write interesting parallel programs for controlling embedded microcontroller projects.

We have drafted the first 50 pages of a book that supports programming these affordable ($25 or less), open devices in one of the few parallel programming languages around. Our support library is called Plumbing, and we are excited about completing the first ten chapters and sharing them with a group of “alpha testers” who can help make sure our writing is appropriate for our target audience.

Who is our target audience? We have chosen the Student Artist as our target persona for the book. This is a notional college-age student who is studying art, has no significant programming experience, but wants to add interactivity and computation to their work. They don’t want to learn to program (per se), but instead want to achieve some end: a piece of art, an installation, or similar. The electronics and programming component is fascinating to them (and perhaps a touch daunting), but they’re willing and ready to learn what is necessary to make their art as successful as possible.

This persona, we believe, overlaps a great deal with the MAKE community, and even with many students of engineering and computing. However, we have explicitly forced ourselves to consider a target audience that is not studying programming. This forces us to think about what concepts we introduce when, focus on outcomes and results (as opposed to belaboring theory up-front), and do our best to support the artist/maker in fun and thought-provoking explorations from the start.

If you are interested in being part of the group who gets a look at the book early, please either drop me an email (matt at transterpreter dot org) or leave a note with contact information in the comments (a URL to your contact info, an email address, etc.). We’ll be finishing the drafting and revising that material over the coming weeks, and hope to have an initial release of the software (a simple IDE with Arduino support built-in) soon.

invited talk

In two weeks, I’ll be giving a talk (along with Christian Jacbosen) at USENIX ’09 entitled Towards Designing Usable Languages. We’re excited about the talk, and it should be very, very exciting.

I believe the talk will be on-line when we’re done, so I’ll make sure to point to it. If you’re in the San Diego area, and want to try and get together, drop a note—the schedule will be tight, however. We’re in-and-out like a burger.

patience

Patience is a virtue I do not have.

By this, I don’t mean the run-of-the-mill, “When will this line move?!” kind of patience. I have that. The Bureau of Motor Vehicles does not scare me. I can wait with the best of them in a queue. I mean I have no patience for the big stuff: personal excellence, career advancement, and the like.

About three weeks into graduate school, I was ready to be a full professor. I wasn’t, but that’s how I felt. Or, in hindsight, I now see that I was impatient to get on with things. Now, I’ve learned from my first year as a member of the faculty at Olin that patience can be a good thing—that I have a lot to learn. Nor does it mean that I’ve magically found patience.

Consider:

On August 1st, the moving truck I rented was empty.

On August 2nd, the ceiling in our kitchen looked like this, because of a leak from the shower upstairs. It was fixed that day. (The shower, not the ceiling. The ceiling is still on the “to do” list.)

A week later, we enjoyed two relaxing days on Lake Cayuga with friends we had not seen in too long.

We also enjoyed ice cream.

On our way home, we spent an hour at the Corning Museum of Glass. I hope to go back, because one hour is nowhere near enough for this amazing museum.

We’ve spent time discovering our new hometown. Admittedly, it was a less exciting place in the past. Today, however, we can walk downtown to find locally owned stores, and are particularly excited because we can buy fresh, local milk. In glass bottles. That you return and have refilled.

Christian and I made and bottled our own beer while he was here. Admittedly, someone else took care of a lot of the process, but we’re finding that it gets better with every tasting. It was something I had never done before, and enjoyed the brewing and process a great deal.

With fresh tomatoes in season, I made salsa. I’ve never done this before, and it was marvelous.

I made a lot of salsa. It’s in the freezer now. I want a chest freezer, so in the future I can make more.

Although Christian is our first house guest (and a long-staying one at that), we also hosted friends from Olin on their way from Chicago to Boston. The evening they were here, we went to the county fair, and had ice cream and deep fried Oreos.

Christian and I have ported the Transterpreter to a new processor and robotics platform, and have learned quite a bit about a number of things along the way. A bit intense, but a good learning experience nevertheless. We can see a possible paper and future project directions based on our experiences.

And we have weathered the ongoing attacks of our neighbor’s cats. Apparently, the cats had friends here, because they often come by, crying to be let in. So far, our defenses are holding.

That’s month one. I’ve just finished the first week of classes. Should I be surprised when a day doesn’t go exactly as planned, because a server died in the department? No. Should I be surprised if I don’t have a perfectly smooth semester? No. I have to constantly remind myself that the past three months (and, indeed, the past year) were very intense, and very busy, and now is the time to start taking some deep breaths, settling in, and finding a groove that doesn’t involve 80-hour work weeks. Or, as the case has probably been lately, 90+ hour weeks.

I still want to take over the world. And I want everything I do to be amazing (not perfect—they’re similar, but different—amazing has more of a shazam! factor). And I want everything to be amazing right now. I don’t think this, consciously, of course. I live it. It’s subconscious, and it takes effort to step back and realize that I’m doing a pretty kick-ass job (especially with the salsa and beer), and it’s going to take some time to settle into a new home, a new job, and a new pace of life.

/me watches the clock for a few seconds…

Nope. That didn’t help. I’m still impatient.

das brewing

A friend and colleague from Olin is starting her epic drive from Boston to Seattle soon, and will be stopping here in NE Ohio for a break. Having not lived here for some time, I needed to find a place that we could have some tasty treats before sending her on her way. So, I did a Google search for “restaurants strongsville ohio.”

This turned up a list of restaurants on some page or another; I naturally clicked on The Brew Kettle, simply because I couldn’t believe that there was a brew pub in Strongsville. It just didn’t jive with my view of the place. I mean, Strongsville is overrun by chains and suburban sprawl, not tasty brewpubs, right?

The Brew Kettle’s decor. Clean, and with a clear theme.

Wrong. Christian, Carrie, and I went there on Friday to check it out. (Dr. Jacobsen is visiting for the month while we do some Transterpreter hacking; more on that in a later post.) We drove over, and the outside of the restaurant is nothing special; it’s in a little strip with a bakery outlet and a dentist’s office. Inside, the decor was clean. The beer list on a large chalkboard was reasonably impressive, but we started by requesting a taster of their own brews.

The food was great. Christian and I split the “Backyard Sampler,” which gave us a 1/4 rack of ribs, some BBQ wings, and some pulled pork. Everything showed signs of having been prepared fresh, and prepared well. The pulled pork, for example, was nicely done, with their own seasonings; likewise, the wings were real chicken wings, and the sauce used in all cases was their own. The fries were good, too.

The thing that makes the Brew Kettle special, though, is that they will let you brew your own beer. Currently, they’re booked until March 2009, but we got very lucky. I inquired if they might have any cancellations, and they said “no”. However, a half-hour later, someone stopped by our table and said that they have an opening right now if we’re still interested in brewing. Apparently, they were already 30 minutes into a brewing slot, weren’t able to get anyone off the top of their cancellation list.

So, we said yes!

Christian adding the flavor hops half-way through the brewing process.

The brewing process took around 2.5 hours; we opted to produce an IPA, as we’re reasonably fond of hoppy beers around here. The recipe we were given had us using American Cascade hops for each stage in our brewing process; we were excited to be using whole-leaf hops as opposed to some compressed, pelletized form. (Not that we know the difference, but they were fun to work with.) In the future, we’ll have to do some research and experimentation. My primary goal will likely be to strive to recreate the glory that is a good pint of Incubus. Or Skrimshander. Or, really, anything Tonie brews at Hopdeamon Brewery, but sadly does not export.

The Brew Kettle takes care of fermenting, and in two weeks, we get to come back for bottling and labeling. As it turns out, we get to design our own label! Naturally, it will involve the Transterpreter, somehow.

the open group @ allegheny college

Background (not so important)

The Students (very important)

first package: lint free

parallel blinkenlights

How do you do that?

Open-source is Awesome

documentation and its role in open projects

invited talk

patience

das brewing

Pages

Archives

Admin

the open group @ allegheny college

Background (not so important)

The Students (very important)

first package: lint free

parallel blinkenlights

How do you do that?

Open-source is Awesome

documentation and its role in open projects

invited talk

patience

das brewing

Pages

Tags

Archives

Admin