c.cc

Mailing list and archives fixed

For a long time, there weren’t many “new” people working with our tools. Therefore, our lists lived behind an https:// address with a self-signed certificate. This caused problems for many people. If nothing else, it threw big scary warnings claiming Bad Things were about to happen.

I’ve moved things around. Our lists are now completely open.

• Our list for users of process-oriented programming (things like Plumbing, or JCSP, etc.) is users@concurrency.cc.

• Our list for developers working on these kinds of tools (contributing to Plumbing, etc.) is developers@concurrency.cc.

You can join either list from our mailing lists page. Please join in the fun. I’ll try and get another post up over break about things that are going on with the team. (Also, we’ll know whether we’re a GSoC participant!)

Google Summer of Code

Yesterday we submitted an application for the 2010 Google Summer of Code. You can find our application and ideas right on this site. We won’t know if we have been accepted as an institution until the 18th of March, but if you are interested in doing a Google Summer of Code project with us it is probably worth contacting us about it now. Even if we don’t get accepted as a mentoring institution, we would of course still be more than happy for anyone to come and join the project and do cool stuff!

If you want to get in touch with us about Google Summer of Code and projects, join the developers list and drop us a note.

Around the WWW

This is the first of a series of posts where we point to things we’ve found on the WWW, and do our best to address some questions/share some thoughts about our tools.

To answer the question that we’ve received several times and seen in a number of places, Windows is coming.

The St. Louis Area Robotics Group

A few weeks back, a thread was started on the St. Louis Area Robotics Group forums regarding our libraries and the Arduino/robotics.

The original poster (gifted) pointed out that while the native Arduino programming environment provides threading via protothreads, it doesn’t necessarily make it easier to handle multiple events taking place simultaneously. This past week, I had students working on a challenge involving three LEDs fading in and out on three PWM channels; as each finished its fade cycle, it would “ask” for a new reading from an ADC channel. I encourage students working with dataflow languages like occam to first draw a picture of their program:

We call this a “dataflow” language because the entire basis for programming in occam is one where we are communicating data from one parallel process to another. Hence, it is useful to think of values “flowing” from one process to the next. I’ll break things down fully here:

Step 1

The fader process gets done bringing it’s specific LED (in this case, the LED on pin 11) to full brightness and back. At this point, it wants a new reading from the ADC to determine how fast or slow it should fade. So, fader signals the switch process that a new reading is desired. (So you know, the fader process does not know who is listening—it just knows that it wants a new reading, so it sends out a SIGNAL.)

Step 2

The switch process grabs the SIGNAL and then signals the adc process that a new reading is desired. From the point of view of adc, it has been sitting quietly doing nothing, simply waiting for someone to ask for some data.

Step 3

The adc takes a reading from pin 0.

Step 4

The adc process communicates its reading down the adcResp channel, and proceeds to begin waiting again.

Step 5

The switch process takes the value it received from adc (it was waiting), and sends that on to the fader process (who is also waiting).

There is a 1:1 correspondence between this diagram and the code we write. If you want to see an implementation of this tri-LED fader, you can see it in our repository. I’ll eventually write this up as a sequence of short chapters in the book, but I simply haven’t had time yet. (And, actually, that code needs some comments. I use replicated syntaxes to keep it short, but those should probably be explained.)

Plumbing is for concurrency

So, yes… we think this is good for robotics, because a lot of robotic control is about reading from and reacting to sensors. We <3 the Arduino because it is a low-cost microcontroller that lots of people use for exactly these kinds of applications—but we think it’s too difficult to manage this kind of complexity in C, especially for programmers just starting point.

And, for tmaiden on the St. Louis robotics forums: we use the word parallelism to denote when things happen “at the same time,” and use the word “concurrency” to mean “the appearance of simultaneity.” I don’t know if others make this distinction, but we do… because when we use our tools on multicore devices, we get parallelism. When the Arduino goes multicore, our domain will be technically incorrect, and we’ll have to go get parallelism.cc.

And those .cc domains are expensive.

Did I write that?

Meredeth Patterson (maradydd)¹ commented on the preface to “Plumbing for the Arduino”:

This is how you write an introduction that makes people care about what your project does. This is how you take a specialty solution, heretofore useful to and understandable by only people who already understood process algebra and the pi-calculus, and present it as another tool for people’s toolboxes right alongside hammers and screwdrivers. If you want to drive a nail, get a hammer; if you want to do parallel tasks in real-time, get occam-π.

The hard thing about giving your work away is not knowing whether it has value. I know there are bugs in the book (Zoro Feigl already found one…), and I know it can be improved. That’s the nice thing about getting it out there for people to use—they can push back, and we can improve our software and our text.

And that really makes me feel good.

There’s a few other people who found our project in the past week or so and started exploring it. I’ll point to those over the next couple of days. The early adopters—people exploring something new—really are exciting to work with. You can see learning taking place as well as more work piling up, because you now know you’ve got more things to improve and more documentation to write. (I happen to think that’s a good thing.)

Mailing lists and updates

Tap tap

I have no idea if this blog is read by anyone, but hopefully you put our RSS feed in your reader if you were interested in news and updates.

Twitter

We created a dedicated Twitter feed for the site. You can follow concurrencycc for updates. For example, when the book updates, or the blog, we’ll write a short note. All signal, no noise. I hope. I’m not a Twitter expert.

Mailing Lists

We have two new mailing lists: * users@concurrency.cc * developers@concurrency.cc

You can join either or both of these lists using the details on our mailing lists page. (Or, if you want, drop matt at concurrency dot cc an email.)

These are not strictly limited to people exploring occam on the Arduino. Our long-term goal is that people exploring process-oriented programming find a home for their projects under this domain. If you start exploring Plumbing and have questions, that is a great place to ask. Everyone involved in the creation of Plumbing (and, for that matter, everyone working on occam-π) can be found there.

If you’re interested in contributing to the Plumbing libraries (or, the virtual machine underneath it), or you want to help bring occam to another hardware platform, join developers@concurrency.cc. That is the space where we discuss the tools that make things like Plumbing possible. Again, we’re all there.

Book Updated

Two (three?) new chapters appeared last weekend. Also, Zoro (who seems to do some very cool art) dropped an important note to bookbugs.

Every program you write for the Arduino that uses Plumbing needs to start with this line:

#INCLUDE "plumbing.module"	

This line of code brings in all of the support you need to program the Arduino in occam. Our intention is that the tools you use for programming the Arduino will ultimately insert that line automatically. (Or, perhaps we’ll change our minds about that.) Either way, I’ve updated the first chapter so that it is included there. I am not going to update all of the code examples in the book at this time, simply because that will 1. take longer and 2. upset my pagination. Also, the group needs to discuss (on developers) whether we’re going to make that line go away or not.

Summary

We have a new Twitter feed, new mailing lists, and updates to the book (now on revision 2010-02-12). Enjoy!