Objology

A couple different blogs have commented on this post regarding some asserted Squeak leadership changes.

I actually first heard of this as I once again did my semi-daily delurk in the mailing list and skimmed the last couple days of email. Must have missed the first couple of posts, but picked up on some interesting replies to the original "manifesto" of sorts. I don't have much right to comment much on this. I haven't used Squeak in a while, the last time was to generate spiral and line and then embed the contents of a CD's readme file in the spiral so we could print it and "put the readme file on the CD". At one time, I was really excited about Squeak. I don't know why the fascination didn't hold. I still follow the list, but I don't hold it for it being the revolution that I hoped once upon a time (yes, I know, projects like Squeak need more people that actually contribute code, and less people like me that wish it solved all of their problems). I think the always almost-done-and-starting-over-again VM efforts wore me down.

I don't know what to make of Goran's "declaration." I guess Squeak wasn't going anywhere in a hurry lately, so it can't be worse. In general, I distrust group assertions like this. Having observed a number of open source projects for a number of years now, it seems that these sort of "public leadership gyrations" often don't bode well for project health. They often seem endemic of fascination more with "administrivia" than "producing code." But then there's the exceptions too. It'll be interesting to see how this unfolds. Hopefully for the better.

OK, I whine alot. Or punditize. Or whatever you want to call it. Often about VisualWorks directions/shortcomings/frustrations. Too much likely. And then I read a post like this one by Vassili. And I think, all is well. Our ship's in good hands. Of particular comfort is his statement: "...it reminded me how less approachable this system has become. We will have to do address that in future..." He makes a good post with some introductory examples into use of the Store.Registry package APIs to do the kinds of things we used to do with the SystemOrganizer and Smalltalk.

As much as I have trash talked Store from time to time, this is one aspect that I actually like. Yes, the code scares me. It seems very brute force-ish and is a cornucopea of formatting styles. But I can actually figure out relatively quickly usually how to get the info I want out of it. I've been able to write a good deal of both public and in house "extensions" or "add ons" because I could figure out how to drive it pretty quickly. Interestingly, Envy which I consider a more elegantly implemented system, often seemed more difficult to do these kinds of things with.

As I was browsing a couple of packages a couple of days ago, I noticed something funny. Nearly all of the classes seemed to begin with the letter S. Me, a real fan of using namespaces to create little "microverses" where you're free to express class names without worrying about semantic clash, and nearly all of my classes start with the same letter. This of course, degenerates searching for a class in an "alphabetical" list to a linear method. So I wrote a little script.

This is blogged in the same vein as Vassili's Just Browsing entry: interesting ways to programatically access your program space.

I used a workspace and concocted the following block (why a block? see here. I've been accused of too freely extending base classes, but I draw the line at printMostPopularLetterWithPercentageToTheTranscript):

showMostPopular := 
		[:pkg | | classes grouped mostPopular | 
		classes := pkg definedClasses.
		grouped := classes groupedBy: [:eachClass | eachClass name first].
		mostPopular := (grouped associations 
					asSortedCollection: [:a :b | a value size < b value size]) last.
		Transcript
			show: ('<1p> <2p>% <3s>' 
						expandMacrosWith: pkg
						with: mostPopular value size / classes size * 100.0
						with: (String with: mostPopular key));
			cr].

Then you can use something like:

showMostPopular value: (Store.Registry packageNamed: 'YourPackageOfInterest'

Or

(Store.Registry allPackages asSortedCollection: [:a :b | a name < b name]) 
	do: [:eachPkg | eachPkg  definedClasses size > 10 ifTrue: [showMostPopular value: eachPkg]]

This second one is fun, because it shows the results for all comparable sized packages in the system. I was kind of amused. There's some obvious ones like WinLooks which of course is going to have 100% W.

Extending your development environment is a process. First you have an idea. And then you implement it. And then either it sticks or it doesn't. Often tools that we thought would be handy aren't. And vice versa. Sometimes it takes time to get used to leveraging it.

The latter is the case with the alt-character shortcuts that ExtraRBForSUnitToo. I'm to the point now, where I really like the alt-r for running tests. Ctrl-o (format), ctrl-s (save/accept), alt-r (run tests) has gotten quite popular with me. And I'm finding the alt-t (toggle to/from test case) is growing on me. I'm so used to doing it the slow way, that I forget often, but when I get in the groove, this is just really handy. One thing I found though, was that I was leaving a trail of test case buffers four lanes wide behind me. I just published a "tweak" which attempts to solve that problem. When alt-t attempts to toggle to a test case, it will first search for and reuse buffers which are already test cases, but don't have an accompanying tested class buffer. It works pretty handy. Time will tell.

I picked up a link to this thing off of Vasilli's Retire your Dock.

In the past, I've steered clear of these types of things. From a distance, their goal seemed to be somehow bolting something like the Microsoft Startup menu back into OSX. With the extra wide monitor, the dock on the side, and in particular corner activated eXpose', I didn't think I'd appreciate something like this. But I thought I'd take the plunge and try this QuickSilver launcher/finder/whatever.

First reactions are positive. I'm not sure I'm really leveraging all of what it can do yet. And it is a different path to getting at applications/data, so we'll see if I can retrain myself to use it and do so regularly. Thanks for the post, and even more so to "water" for the comment.

The MessageCatalog "framework" is begging to be "extended." We've never been fond of the "weightiness" of the VisualWorks localizable text resource files, so we set out to do something a little different. ExtraCatalogs has just been replicated up to the Open Repository.

A while back Georg Heeg had made public some efforts to build VisualWorks translation tools (called L10N I think). ExtraCatalogs effort is complementary to that effort. ExtraCatalogs is simply an alternative way of maintaining message catalogs and resolving user messages to them. The tool(s) Georg posted concentrate on how to actually do translations.

ExtraCatalogs has the following features:

• Translations are stored in memory -- this means no thrashing between files. Just one initial load and everything runs along quite nice.
• Works with Existing User Messages -- These bolt right into MessageCatalog framework which searches all subclasses for matches. So nothing changes there.
• XLIFF export/import option -- This is an open standard, and it uses XML to keep buzzword bunnies happy. Which means that it also has standards for character coding issues. And is one file (as opposed to having to "compile" an idx file from a lbl file).
• Support for thread specific locales -- Some had indicated a desire to do something for server style applications, where the system may actually need to render mutiple concurrent localizations of a given user message. To facilitate this, catalogs can be "registred" under a specific locale (if none specified, they go to the current one). As well, a locale can be attached to a given process via Process>>useLocale:. The resolution engine will use this locale when specified, or the current when none is specified (no, this package does not add an instance variable to Process, it uses the process's 'environment' dictionary to store it--I wish PDP did this too).
• Unit Tests are included.

The code is free to use by anyone. It has some rough spots in the design still. Hopefully some time and usage will ferret these issues out, so any feedback/contributions is most welcome.

We played long and hard with the TMX file format (this had been mentioned by a couple different people). But TMX is a tool for translators to use, to move translation data between different translation programs. We attempted to use the TMX file to "short circuit" much of what is the normal process a translator goes through to translate a resource. While this would have been really snazzy, none of the translation tools are geared to deal with this kind of scenario. They use TMX files to translate your resources. After working with translators from a company or two, some vendors, and a mailing list or two, we deduced that the XLIFF file format was a better "open and standard" fit for what we were trying to do.

The latest upgrades for BottomFeeder on the dev stream, appear to render BottomFeeder unstartable, at least under MacOSX. Of the two parcels upgraded, the offender seems to be the WSBundle.pcl. By removing that .pcl in the app directory, it is willing to startup. One thing that's unclear to me is... when you remove one of BottomFeeders "upgrade" parcels, what does it revert to? The original downloaded version? Or the last known good download?

I downloaded and played with Ambrai Smalltalk this evening. I missed their talk the year they presented in Toronto and wasn't really aware that they were still charging on. I was mistaken.

I followed their demo. A beginner might be a bit puzzled as to what he was supposed to do with the downloaded .st file or how to evaluate code, but it was otherwise pretty straightforward. A basic demonstration of "look we made a difference amongst your other pretty windows."

That didn't take long, so I wandered around the system some. The browser's navigability is pretty primitive, if you're coming from a power tool like VisualWorks, it can feel a little cumbersome. But it's a second beta, so it's pretty impressive. I'd suspect some strong VSE/Dolphin influence or at least similarities. Smalltalks with tight OS integration seem to have a similar feel. Browsing around, I noticed that it seems to be pretty well flushed. But economically spartan at the same time.

Classical <primitive #####> 's are used for the normal Smalltalk primitives (i.e. adding numbers, at:put, etc). But for things like the OS interface (file streams for example), it's written in something more like DLLCC. This I like. I wish more of VisualWorks was implemented in transparent Smalltalk-to-native-library objects, rather than wondering just what the primitive that does a directoryContents really does.

There are no Processes, instead there are Tasks. It would be interesting to learn just what these can do. The number hierarchy is light; it uses double dispatching right off the bat (doesn't even bother to fail the primitive first). IndexedCollection didn't understand at:ifAbsent:, but that was readily fixed, and it worked fine. Even better, getting Symbol to understand value: so that #(1 2 3 4 5 6 7 8) collect: #odd works fine was a snap. Growsing around, it seems that it is not the case that a bunch of behavior is hidden behind the scenes (such as the parser/compiler). The debugger is functional enough. It's all there in Smalltalk as it should be.

Just one more thing. One thing I'm pretty fanatical about is code formatting. It's not that I have a style I care about, it's that I'm lazy. I just want to type code and then hit the format button and have it clean it all up for me. I like the uniformity. Whether to terminate or separate with periods is academic past that. So I thought I'd see how hard it would be to add a formatter in. It took about 15 minutes wall time. Which is pretty impressive, considering I'm a stranger in a strange land here. The first mod was to add a line like:

addCommandItem: #onFormat text: 'Format' shortcut: 'Command F';

to the BrowserWindow's editMenu method. When I saw this method, I felt very much like I was back in WBPro again. It's a style I'm only beginerishly familiar with. Anway, restarting the browser, my menu item was there. After that, I added the onFormat method to the same class and begin putting braver and braver Transcript show: methods to. I was lucky to discover that there was already SmalltalkColorPrinter, which is a ParseNodeVisitor... you know the pattern. Even luckier after considering copying this to make a Formatter, to see that there was a SmalltalkPrettyPrinter class already. I just needed a convenience method to work off a string and then my onFormat method could be written as:

self textPane text: (SmalltalkColorPrinter printMethodSource: (SmalltalkPrettyPrinter printMethodSource: self textPane text))

And then of course, I promptly tested in on itself. And it worked. Pretty nifty. It doesn't preserve comments, and it needs to be smart enough to do the right thing when a class is selected, but it was cinche. I'd gamble those two items would be less than another 30 minutes yet.

Tonite, I played some more with Ambrai Smalltalk. More coolness. Some more observations as I growsed around the system, and then again, something fun.

• Fonts - To render a string with in color, or bold, or italic or a specific font, 3 classes get involved from the programmer's perspective: Text, TextStyle, and Font. That's it. Pretty tactile and straightforward. Ever since rewriting ExtraEmphases, I've been looking for good examples of simple and approachable string rendering APIs. This one is a good one.
• Contexts - That I know of, there are two Smalltalk's that can model contexts in a reflective enough fashion to do what SeaSide does. So I'm interested to see if Ambrai will have what it takes. I don't know yet. It does have an ExecutionContext which you can chain through, ask for the selector or method or reciever, look at it's arguments. It's accessed not via 'thisContext' but via ObjectMachine current currentExecutionContext. I don't just how reifable they are, whether you can copy them, restart them, etc. This is an area many "simple" Smalltalk's definitely skimp on, the amount apparently there is impressive.
• Platforms - This is an OSX tuned platform, right? So what are those methods in ObjectMachine 'testing-processor' and 'testing-operating system' for? isPalmOS? And the method comment for applicationHandle? Maybe it's just a long heritage's accumulation over the years. Maybe there's more there.
• Encoders - It's just the various UTF schemes!! How refreshing. And, external streams are basically binary with an encoder around them. As it should be.

Warning: Past this point there be "weird characters", browsers may not render correctly

My first Smalltalk book was the Blue Book. I was totally mystified by the syntax. It was mysterious and alluring:

foo
	↑foo

What was that about? The same word separated by a symbol I couldn't even type and it was supposed to mean something basic. It seemed so transcendental. I truly did feel as I stood on the island watching an etheral balloon floating away's up there. Ever since I figured it out though, I've always wanted to return to that transcendental plane. I want to code with the left and up arrows. I want to look at my code and think "that's so other worldly".

How hard was it to make Ambrai do this? Not hard at all. Ambrai being a small/new project, it hasn't accumulated years of Scanner hacks and attempts and renditions. There's just one, and it's pretty clean. I modified two methods (scanReturn and scanToken) and added a third (scanLeftArrowAssignment). isAssign was added to Character. And Character's isReturn was modified as well. I had to fire up the OSX Character Palette to actually input the characters (does anyone know some way to "map" these characters so I don't have to use the palette). But that's it. So I rewrote one of my favorite methods:

Symbol>>value: anObject
	↑anObject perform: self

Not much different, but that's an up arrow. To test assignment, I wrote another one of my favorite base extensions:

ReadStream>>nextUntil: aTestBlock
nextUntil: aTestBlock 
	| output |
	output ← self contentsSpecies new writeStream.
	[self atEnd or: [aTestBlock value: self peek]] whileFalse: [output nextPut: self next].
	↑output contents

The only thing left after that, was to fix my formatter from last night. I modified the SmalltalkPrettyPrinter to emit the left and up arrow and all was well again. I can now input code in either format. When I "format" it, will be transcended.

BTW: This blog means that my Upgraders Beware blog issues have been resolved. I reinstalled clean.