Objology

So, they've talked lots about this wave a blogger goes through. He gets into it. He does it more and more. He finds it consumes his life. He burns out. He fades away.

I did that.

But I thought I'd explore the niche of those that might take it up and try again, maybe wiser in their perspective the second time.

Here goes.

So, I'm willing to give this blog thing a try again. What are the good RSS feeds to hook Bottom Feeder up to? I'm (at this point) interested only in the Smalltalk community (and related communities) type of stuff. I don't want to spend all day reading blogs. Let's have 'em.

A while back, we built an "experimental fork" here at Key of the venerable SUnit. I blogged about it quite a bit. I wasn't out to "take over" the SUnit effort. In fact, I'd be quite pleased if all/any/some of the "improvements" we made in SUnitToo and the associated IDE extension (ExtraRBForSUnitToo) made it back into the core. Just wanted that on record.

That said, we did recently find a bug with the tool and the way it interoperated with PDP's ability to "define method" when you get a MessageNotUnderstood. Much thanks to Terry Raymond for helping see the problem and finding a fix for it. It's been replicated to the Open Repository.

It was time I did another Extra package. And I got an opportunity to.

Any real network programming requires that you deal with the network IO timeout problem. In C code, this basically means that you preface any read()/write()/send()/recv() with a poll()/select() call that has a non-zero timeout, and take appropriate action when your timeout expires.

In VisualWorks Smalltalk, this is not immediately obvious though, because we bury our IOAccessor objects (the equivalent of a C file descriptor) behind ExternalStreams, and Constructor (eww) thingies, and IOPositionableBuffers. For the most part this is a good thing. You get to use the same powerful streaming features on a socket that you would for a file, or an internal string, or whatever. But the timeout thing, it makes it tricky.

Our first attempt at this was to use a sort of a "transactional" timeout. Specify the time you expect to send your command, have it processed, and read the ack back. Many eons ago, I blogged about Finished Yet?, an extension to BlockClosure, so you could time them out. It was actually built originally for just this problem, though I've found it generally useful for other things too.

That worked fine for us for a while. It worked because it was run from a UI, and UIs don't normally do much. Other than interact asynchronously in short bursts. But then I added some monitoring processes which did long running computations, at a priority higher than some of the networking polling threads. Suddenly I started having timeout problems. Not because I was having legitimate network IO problems, but because I was starving the transactions from ever getting any work done. I tried a variant of the transaction timeout, that attempted to let the process run if it could as long as it wasn't idle after the timeout. This didn't really fix it.

SocketAccessor has the ability to do a select()/poll(), it's just not wired into the normal methods that streams and such use. Time for a new approach. Make timeout a first class part of SocketAccessor, rather than layering it on with other techniques.

ExtraSockets does this by adding a readTimeout and writeTimeout. By default, they are nil, and any methods which might use them, do the original thing. But if they're not nil, the two subclass overridden methods (readInto:startingAt:for: and writeFrom:startingAt:for:), first do the equivalent of the select(). And if they fail, raise a SocketIOTimeout (maybe we should have reused one of the existing signals, if you have suggestions let me know).

Results so far? Great. It works better than the old framework. With or without the longrunnning computations. And it made putting the timeout parameters much easier. Basically, the socket is given a read/write timeout that is indicative of what worst case network latencies are. The query proceeds. A transaction specific readWait is entered to allow the end processing time to vary per transaction. And then normal read timeouts apply for actually reading back the response.

I'm pretty convinced that network io timeouts are not something that should be "layered" on top of sockets. They should be first class integral parts of them. I'd love to see this code/approach integrated into VisualWorks in one way or another. Until then, feel free to grab ExtraSockets and see if it doesn't make your network IO timeout code easier and more robust.

One thing I'd like to know before I publish, is what the test status of a given package is. I've just published a version of ExtraRBForSUnitToo that is a start of that. Here's the simplest thing that probably won't work:

This was actually quick and easy to throw together. But it begs a couple of interesting questions:

1. Different size icons make the vertical alignment sketchy. Though maybe this is a good way to see packages that are tested vs those that aren't. Putting them side by side was quick and easy. Morphing them together in an overlay or something like that is just not going to work. Putting them at the end, would be a little more difficult, but probably not impossible.
2. You have to reselect the item to get the icon to change. This is the same behavior as when you publish a package, it's icon does not update until you reselect the item. In both cases, it's not right.
3. The performance isn't the greatest, especially on Bundles. The problem is that CodeComponent has no compiledMethodsDo:, just an accessor. So you have to gather them all. And then enumerate them. For bundles, its even worse. That said, it makes it a little sluggish, it's not a killer.
4. I'd like to entertain retooling the test case icons. They're OK, but they don't differentiate the different states very well.
5. This begs more than ever the question of "when do you invalidate the visual indicators?" The current behavior (as the test methods themselves change) is worse and worse for this kind of a "global" indicator.

One of the coolest objects in the graphics/view framework for VisualWorks is the VisualBlock.

VisualBlock is a block with a bounds. Many of the views/widgets we put together are just a fancy displayOn: message. It came in really handy, in creating an "icon" that was two OpaqueImages side by side. Given the desire to create an "aggregate" icon by showing two OpaqueImages side by side, you have a couple of choices:

1. Create a special object. A subclass of VisualComponent. Two instance variables. Add the various bounds messages. Your displayOn: message. If this is a very common thing to do in your system, then this is actually probably the right thing to do.
2. Synthesize a new OpaqueImage which is the two put together. Means you have to create a separate Mask and Pixmap, draw the OpaqueImage figures/shapes onto it at the right places. Return a new OpaqueImage after turning them back into Images. Kind of yecky, and it'll work the heck out of your graphics server.
3. Just use a VisualBlock. Something like:

graphic := VisualBlock block: [:gc :box |
  icon1 displayOn: gc at: box origin.
  icon2 displayOn: gc at: (box origin right: icon1 width).
] bounds: (Point zero corner:  icon1 width + icon2 width @ icon1 height).
^graphic

To me, the VisualBlock is very appealing. It was quick and easy to throw together. I can experiment with different layouts. And it doesn't thrash the graphics layer.

VisualBlock exists under the current "wrappers" framework, I have no idea if there's such a thing for Pollock yet. But if there's not, I'll bet its one of the first things I slap together.

In yesterday's post about test feedback for packages, one of the things I listed as issues was that ...Different size icons make the vertical alignment sketchy....

So I sat down and tried to figure out how to make it put the icon at the back. One of the problems is that there's implicit notion that your list is text, with an optional icon on the left side. These means we'd need a new kind of LabelAndEndingIcon or something. And we'd have to get the lists to use a visualBlock, instead of a displayStringSelector. And figure out where to wire that in. It's all in there, but you'd touch stuff everywhere.

Luck is our lady in this case. If you make displayString return a Text object rather than a String for PackageModel, the list will happily go with that. This is cool. You could italicize package names. Or bold them. Or superscript them. And do all kinds of cute formatting. You could make your browser look just like those Christmas letters we used to get from Mac owners in the 80's... you know, the one's where the font changed every 2 or 3 sentences. Just because, well, because it could. It was the trademark of the Mac letter writer, his or her way of saying "Nah nah nah nah, I own a Mac and you don't." But I digress.

Rather than go nuts with fonts, I just chose to use a #trailingInsert emphasis. This allows you to insert arbitrary graphics in the text stream. It's counterpart, #leadingInsert is what is used to put the Stop Sign in for PDP breakpoints. This is possible when you load the package ExtraEmphases. With that in place, we get something that looks like this:

Doing it this way has another interesting side affect. You know how when you flip to the "Heirarchy Mode" for a class, the Packages in the second list over, don't show the icon decoration that they would have otherwise? Not a problem in this case. The test status still shows up. It would be interesting to respin the package/bundle modified/notmodified icons this way, using ExtraEmphases #insertLeading, rather than LabelAndIcon. Then it would just work everywhere.

Oh yeah, I took out the ability for Bundles to show the test status icon. I don't use Bundles; if this disavows someone, let me know, I'll figure out how to put them back in.