Objology

How saddened I was, as I skimmed through this mornings deluge of Squeak mail, to note one which made me aware that the *nix builds for Squeak now use automake/autoconf. I admit readily to being a Squeak list lurker, so this has been in place for who knows how long.

I've played with automake/autoconf a bit from time to time. Many open source projects use it. You download a tarball and expand it. Inside a crawling directory structure, there might be a directory called src. That's where your source code is. And there'll be a README with the usual license ramblings. And maybe a sparsly or dated filled doc directory. And there's all these other files scattered about that have to do with how you compile/install the thing. After a while, I learned a couple of useful commands with these things, and mostly not to ask more. When I had problems, the responses are usually "try this. that worked for me." or "it works for me, but I'm not trying to do what you are" or "i don't know."

One acute example of this was GNUSmalltalk. It's a cute little smalltalk. And in some ways very novel. Back when we were playing with the Wisp/WeeSpeak stuff, I toyed with using GNUSmalltalk as the basis. The problem was, I couldn't figure out how to distill the build process down so I could really warp it. I asked the then maintainer how I could strip away all of the auto-this-n-that and just play with the source. He admitted to me that he didn't really know how the stuff worked, he had just copied it from somewhereelse and modified as needed. I've found that this is quite common. I suspect that the ratio of people using automake/autoconf to those who actually understand what's going on to be quite high. Not to be deterred, I decided that I would take a look at these black boxes and find enlightenment. The table of contents for automake has no less than 28 sections to it! And when you're done assimilating at least some portion of that, you can move over to the 18 chapter autoconf manual. This is all for cross platform and to simplify the 14 chapters fo the make manual. Somewhere in the shuffle of rules, idioms, and practices, I gave up. Maybe some day I'll have another go at groking this thing again. Like when I have my appendix out and need something to put me to sleep in the hospital after the drugs have warn off.

As an aside, I have actually used one "make system" that seemed simplistic and straightforward to use with a minimal amount of learning curve. It's used by the GNUstep guys. It's simple, example based manual can be found here. My one big complaint at the time, was that you needed to source an environment modifying script in your bash.profile. But I believe they have actually fixed that now.

Chris Petrilli claims that the practice of versioning with 0.X.Y.Z is useless. He calls on said releasee's to release with real version 1.0's. And then 2.0. Etc.

I'll take it a bit further. Why put the .0 there anyway? It's a waste. Just release with version 0. And then 1. And then 2. If and when you branch, use a some sort of suffix to split it free. What is with the .0 though? How often is it really worth while? The supposition seems to be an attempt to communicate "this is the real thing". But everyone knows from experience, that a .0 release rarely lives up to it's author's expectation. It is a later point release that becomes everybody's favorite.

Left with this ambiguity, no ignorant person can look at your personalized/customized value judgements about when to increment what part of the version, and discern whatever it is you had in mind. The only real value is that a) this version is later or earlier than that other version, b) an urban concensus has congealed around known good releases ("ah, it's the 3.14.59 version that you wanted, *that's the good one!!")

My theory on this silliness is that it's what our tools teach us to do. It's all in whatever template your versioning system tends to proffer as the default version. A long time ago, certain case/source code tools liked to default to w.x.y.z value. So out came 1.0.0.0, and then 1.0.0.1, followed by 1.0.0.2. This was patently and obviously preposterous, so that faded quick, and we moved into the realm of just X.Y.Z. The religion of the "major-minor-maintenance". A lot of stuff is still there. But I've noticed more people are in the A.B versions now. In the VW Store system, this is the default. I hope we move beyond this soon too. Automated build systems' inability to deduce what is major and what is minor leave me to hope we'll get there yet.

For years, I watched NT 4.0a boot. I knew the 4.0a thing was a total marketting moniker. What really mattered was that it said "build 1381".

A couple weeks back, Ron Jeffries was playing with VisualWorks and I got him playing with SUnitToo/ExtraRBForSUnitToo. One of the things he talked about was the "two browser" approach, having one browser open for your test case and another for your testee.

At the same time, we were having a discussion about how unique Key Tech is in putting Tests right along side the classes, in the same package. For us, what this means, is that we can switch back and forth between a testee and its test case pretty quick. They're almost always right there together. For various reasons, not everyone else is in a position to do as we have done, and one loss there is the extra navigation to go back and forth between the two.

Some of our guys use RBTabs and will have one buffer open for the test case and the other for the testee. This type of approach would be handy for those who don't put their test cases by the testees.

Then I had a little light bulb experience. What if you could manage that with a shortcut key? Here's the mindset. I'm working on a testee. For reasons sundry, I decide I need to look at the testcase, but I don't want to keep navigating. I'd like to have a new buffer for it. Or if I have a buffer for it already, then just switch to that one. And the converse of course. So, there's no an ALT-T shortcut with the latest version (1) of ExtraRBForSUnitToo (the tool counterpart for SUnitToo). I played with it for just a few minutes and found I really liked it. I don't have to memorize that the test is in buffer 1 and the testee is in buffer 2 so that I can use the alt-number shortcuts. And it creates them as I need them. Let me know what you think. It should work fine even if you are using RBTabs.

BTW, if you read through this thinking "what's a buffer?", I'd like to know. Technically, they're called "Views" in the VW IDE, and I guess I could've used that term.