I was having lunch with JL awhile ago, and we were talking about some recent Verilab email threads.

Participation in email threads is fairly high at Verilab: If you ask a question, you’re pretty likely to get an answer. Or three.

But even though participation is the norm, there is no guarantee that you’ll get an answer. There’s no guarantee that the person with the most useful knowledge will chime in. Well, these aren’t novel concerns, and there are tools to address them: Bug trackers. I’m rather a fan of bug trackers, and I think they could be used far more widely than is typical. And foolishly, I promised JL I’d write a blog on the subject.

So I started to organize my thoughts: My central themes would be the interface and the data model. I would argue that the bug tracker data model is far superior, but the interface is often far too cumbersome.

A bug tracker keeps state (and state history) and responsibility metadata. A bug tracker manages a to-do list, and if it weren’t a useful data model, then to-do lists would have gone extinct; and that ain’t happening.

Any communication that desires a response is actually an addition to someone’s to-do list: “Please respond”. And the vast majority of communications do desire responses: “Please book me on a flight to Aruba”; “What’s the Emacs keystroke for …?”; “I’m going to see the new movie on Friday at 8, wanna come?”.

Why not use a bug tracker for all of them?

(more…)

At the end of August, I picked up a copy of “Beautiful Code” (O’Reilly, edited by Andy Oram and Greg Wilson) that was lying around the Verilab office.  I’d just finished the last Harry Potter book, and I was in the mood for some lighter fare.  I’m about 90% through it, although I skipped a couple of chapters entirely.

I had every intention of really studying and understanding the code excerpts, and I stuck to it for exactly one chapter. After that, I just couldn’t force myself. I’m sure that must say something about me, not sure I want to know what.

However, I enjoyed several chapters. My favorite by far is “A Spoonful of Sewage” by Brian Cantrill. It’s the story of hunting and fixing a lock order bug in the Solaris 8 kernel. I think a big reason for its appeal is it really is written as a story. And along the way, I learned about priority inheritance as a solution to a common resource starvation issue. To me, priority inheritance is definitely a beautiful idea.

online pharmacycialislevitrasomaviagra (more…)

In a company like Verilab, full of consultants smarter than a brain pie, it’s not often the CEO gets to teach anyone anything technical. So forgive me for taking advantage of a rare opportunity.

This morning (well, morning to me in the US, afternoon to him in one of our European offices) one of the team asked an emacs question on our lively, internal, intercontinental, questions-answered-almost-before-they-are-asked forum. Specifically, he wanted to know how to change this:

 a0_af0_high = a0_af0_high.get_write_data();
    a0_af0_low = a0_af0_low.get_write_data();
    a1_af0_high = a1_af0_high.get_write_data();
    a1_af0_low = a1_af0_low.get_write_data();
    a0_af1_high = a0_af1_high.get_write_data();
    a0_af1_low = a0_af1_low.get_write_data();

into this:

a0_af0_high   = a0_af0_high.get_write_data();
a0_af0_low    = a0_af0_low.get_write_data();
a1_af0_high   = a1_af0_high.get_write_data();
a1_af0_low    = a1_af0_low.get_write_data();
a0_af1_high   = a0_af1_high.get_write_data();
a0_af1_low    = a0_af1_low.get_write_data();

Such a simple problem, so many interesting comments and answers.

(more…)

Here’s a new English term I’ve just coined: reuseless code. It refers to code that was written in such a reusable way that it can’t be used in any way. Writing reusable code is a noble cause, but before you start it is better to clarify where, why and how you think your code will ever be reused, if at all. Skip this step and you can be sure that, despite your good intentions, someone else will have to rewrite the whole thing later on. You can also be sure that your code will be unnecessarily and overwhelmingly complex.

In a testbench different parts are likely to be reused in different ways. Standard interfaces are the number one candidates for reuse in the pure sense of the term; it is quite probable that they will be plugged in as is into an altogether different project later on. Data generators (i.e. an Ethernet packet generator), base class libraries and generic packages (register package) follow close. In fact, if you’re lucky enough, you will probably be reusing someone else’s code yourself.
(more…)

This note began as a review of the tech report “The Landscape of Parallel Computing Research: A View from Berkeley“, with David Patterson among the many authors. It turned into a trip down memory lane. By the end, I agreed with them that Something Big is in play.
As ever, I urge you to read the paper. It has received quite a bit of attention, so there is also much surrounding material - the group’s blog is one good jumping-off point.

(more…)