James Robertson asks a leading question about Store Bundles in VisualWorks. It's an interesting question, and I hope James will forgive me, but I think it's a bit off the mark. It's like asking me if I use the bathroom in that used house I bought a year or two ago. Duh, of course, I use it. But that doesn't mean that I bought the house for its bathroom, or that I like the bathroom. That given a chance I wouldn't gladly have what my neighbor has a for a commode at his place. There are (in my opinion) more telling questions to ask about the Bundle construct found in VisualWorks. Questions like these:

• Do you use Bundles primarily to get the code browser to group packages logically together?
• Do you use Bundles primarily to give you a mechanism of "versioning a set of packages together."
• Do you use Bundles primarily as a way to make loading a group of associated packages easier?
• Have you used Envy? If so, do you consider a Bundle an adequate replacement for an Envy Config map (open or realeased)?
• Have you used Team/V? If so, do you consider a Bundle an adequate replacement for Clusters?
• Do you take advantage of the fact that Bundles can have the same names as Packages? Do you take advantage of the behavior that the default prerequisite type (#any) will give preference to a bundle over a package, when it encounters two by the same name?
• Do you take advantage of the fact that when you put a Package in a Bundle, it will suppress things like post load actions?
• Do you feel that Bundle "load order lists" (having to get the contents of the packages right, and the packages in the right order) brings a level of organization to your code that you were lacking before?
• As you consider your peers in other technologies (Ruby, Python, Debian, C, .Net, etc.) do you find analogs for a system that uses something like both Bundles and Packages?
• When you teach a college grad, or that friend who's been listening to you tell him about VisualWorks for all these years, do you brag about Bundles to him, and show him all the cool things you can do with them?
• If you use Bundles, but are not enamored with them, how much pain are you willing to go through to get to a better place?
• Do you consider the presence of Bundles something that helps close the deal between a VisualWorks implementation and a competing technology (or another Smalltalk flavor)?

The last is my favorite.

I use Bundles, it's part of the legacy of the VisualWorks system. So I work within those constraints. But asking me whether I use them, doesn't really tell much about them.

Last night, I had a great time collaborating with Michael and Andres as we shared ideas back and forth on how to rewrite the following method:

paddedBinaryPrintString

	"Answer the base two representation of the receiver, with the output

	being split into groups of 8 bits each"



	| binaryDigits paddedSize paddedString binaryStream |

	binaryDigits := self abs printStringRadix: 2.

	paddedSize := binaryDigits size.

	binaryDigits size \\ 8 > 0 ifTrue: [paddedSize := paddedSize + 8 - (binaryDigits size \\ 8)].

	paddedString := String new: paddedSize withAll: $0.

	paddedString replaceFrom: paddedSize - binaryDigits size + 1 to: paddedSize with: binaryDigits.

	binaryStream := String new writeStream.

	self < 0 ifTrue: [binaryStream nextPutAll: '-'].

	(1 to: binaryDigits size by: 8)

		do:

			[:base |

				binaryStream nextPutAll:

					(paddedString copyFrom: base to: base + 7)

			]

		separatedBy: [binaryStream space].

	^binaryStream contents

00001010 11001101 11100010
01001010 00100010 10000011

It was a fun discussion on whether one solution was more mathematical (relying more on integer behaviors to get the right output) versus those that were more stringy (print it up front a

Some were more serious than others; I did one where I actually formed the string backwards, and then reversed the contents on the final return. Two gems that I thought I'd put here. I did a recursive version:

paddedBinaryPrintString

	"Answer the base two representation of the receiver, with the output

	being split into groups of 8 bits each."

	"Use recursion to break the problem down into chunks of 8 nicely."

	

	| ws |

	self < 0 ifTrue: [^'-' , self abs paddedBinaryPrintString].

	ws := (String new: 8) writeStream.

	self \\ 256 printOn: ws paddedWith: $0 to: 8 base: 2.

	^self > 256

		ifTrue: [(self // 256) paddedBinaryPrintString , ' ' , ws contents]

		ifFalse: [ws contents]

This inspired Andres to exploit an API I've rarely really used or been aware of:

paddedBinaryPrintString

	"Answer the base two representation of the receiver, with the output

	being split into groups of 8 bits each.  Each digit is a byte of the receiver"



	| result |

	self < 0 ifTrue: [^'-', self negated paddedBinaryPrintString].

	result := String new writeStream.

	(self digitLength to: 1 by: -1)

		do:

			[:eachDigitIndex |

				(self digitAt: eachDigitIndex)

					printOn: result

					paddedWith: $0

					to: 8

					base: 2

			]

		separatedBy: [result space].

	^result contents

Michael had some nice ones too (I just don't have them sitting here digitally to share, well I would if I wasn't too lazy to dig through Skype Logs). I thought it'd be fun to throw it out there, and see if others had another way to write the method. Go for funny. Go for fast. Go for creative. Go for elegant. Go for readable. Whatever. Put your version in the comments.

I'll try to do one of these a week.

Start your requisitions! Seriously. I've been in Nashville all weekend with the OOPSLA planning committee working out details of what's when. And I'm excited.

There's some neat workshops planned. And neat events. So put it on your plan. Start watching the The OOSPLA Site for changes.

Look forward to seeing you there.

I'm sitting in Nashville, Tennessee this morning, planning how to make sure OOPSLA ends up another great conference this year.

One of those moments of inane absurdity that I seem to gravitate to came in confluence with the discussion of the LISP 50th Year Birthday Party and Dick Gabriel's penchant for poetry, I hit upon the notion of poetry in code.

What if we mapped code expressions to poetry? Can one come up with an analog to meter (e.g. lvalue rvalue rvalue, lvalue rvalue rvalue) and write code along that lines? Or rhyming. What would an analog be?

What I hit upon though, was to look at Haiku in code. Haiku in poetry sets the rule that your poem is 3 lines, of 5, 7, and 5 syllables each. I chose to interpret this in Smalltalk code as 3 statements, with 5, 7, and 5 program nodes per statement in the body of the method.

Rather than be creative myself, I just chose to mine the existing code base. Here's the expression I used to find methods that are written in Haiku:

results := OrderedCollection new.

CompiledMethod allGeneralInstances

	do:

		[:each | 

		source := each getSource.

		([RBParser parseMethod: source]

			on: Error

			do: [nil])

			ifNotNil:

				[:tree | 

				tree body statements size = 3

					ifTrue:

						[wordCounts := tree body statements

							collect: [:statement | (NodeCounter new visitNode: statement) count].

						wordCounts asArray = #(5 7 5) ifTrue: [results add: each]]]]

NodeCounter is not a standard part of the system, here's a fileout of the code for that, it's simple.

So running this, I get a couple hits in a normal development image. Here's an example of Haiku in Smalltalk:

swap: oneIndex with: anotherIndex

		| save |

		save := self basicAt: oneIndex.

		self basicAt: oneIndex put: (self basicAt: anotherIndex).

		self basicAt: anotherIndex put: save

Run this on your code. Do you have any good Smalltalk Haiku methods? Or maybe you'd like to change your perspective and see if you can't write a method that follows these lines.

A while back, Sherry Michael (who I have the privelege of working with at Cincom) did some interesting work to try and reconcile the disparity between SUnitToo(ls) and the semi-large set of tests already written for VisualWorks. What follows is Sherry in "Guest Blogger" mode, writing about this cool work.

I much prefer the SUnitToo UI for running tests. Its semi-persistent test state and the visual feedback it gives are clear advantages in the development process. In fact, they were so important to me that I wheedled Alan into letting me convert the WebTolkit test suite to SUnitToo last year when I was fixing up the WebToolkit configuration model.

I've moved on to more comprehensive refactoring in the Tools/UI arena these days, and I often need to run the correspondingly more comprehensive basic VisualWorks test suites which are written using the original SUnit hierarchy. Still I'm spoiled by the SUnitToo test tools, and I really wanted to use them again. I discovered that if I was careful about running tests that make use of the original SUnit hierarchy rules concerning what is an abstract test and when selectors are inherited, I could use the SUnitToo Class menu item to convert a class to use SUnitToo and run it with those tools. So I started there, but soon found that I needed to occasionally add to or update the set of tests I was running.

About the third time I managed to publish the test suite with the TestCase superclass still in the SUnitToo hierarchy, I started to consider how the two frameworks might be reconciled. My previous discussions with Travis, during my WebToolkit retrofit, about his motivations in developing the SUnitToo framework had convinced me his minimalist approach was correct. I also knew that SUnitToo and its tools make use of VisualWorks Announcements to instrument much of the behavior that I was interested in using. Converging the two code bases was not an option.

I eventually took the approach of building a "bridge" between the two hierarchies. This has worked well enough for me and a few others that I was encouraged recently to put it into the public repository -- SUnit-Bridge2SU2. The mechanism involves replacing TestCase and TestResource in the XProgramming.SUnit namespace with identically named classes that inherit from their counterparts in the SUnit (SUnitToo framework) namespace. We can't just load the package containing the bridge classes because they need to be stripped versions which know just enough to be able to handle the hierarchy rules expected by the original tests, and otherwise use their SUnitToo superclass to run the tests. Overriding the class doesn't delete the undesired original methods. So, with a little magic from the RefactoringBrowser, the original XProgramming.SUnit classes are renamed and bridge classes are inserted in their place when the package is loaded into the image.

If you load the SUnit-Bridge2SU2 package before you load your test suites, only this package and the original SUnit package will contain changes. You probably don't care because you're not likely to be publishing either of these anyway. Your test packages will not be marked dirty unless you have actually made real changes. If you forget to load the bridge first, your tests will be marked dirty (we actually did replace the TestCase and TestResource superclass, after all). But these changes resolve as "no conflict" changes and reconciling your test packages against the repository again will reset the tick marks. Now you can run your existing standard SUnit tests using the SUnitToo tools and enjoy the visual feedback, the semi-persistent state and additional browsers to manage the failed tests.

Pretty cool, huh? Sherry's not much a toot her own horn type of person. So I'll chime in by tooting it for her.

Got tired of the flat 80's green progress bar for LessProgress. Wanted something a little more vibrant. I'll get tired by it in a month or two and tone it down probably, just like SUnitToo(ls).

Great example (in my opinion) why just bolting an an alpha channel into Image is not enough. The drawing uses two 3-point moving gradients, and one 4-point gradient, all involving alpha channels. There was a version that used a non rectangular clip, but I simplified that out, so it just gets to be a show-off of gradients.

Some like 'em, some don't. I kind of do. Those "abstract art" pictures people set as their desktop backgrounds. I think I figured out how they make those today. They use something like Cairo. The throw together a code snippet like this:

window := ApplicationWindow new.

random := Random new.

vb := VisualBlock block:

		[:gc :box | 

		gc newCairoContextWhile:

				[:cr | 

				cr groupWhile:

						[cr scale: window bounds extent.

						10 timesRepeat:

								[| source |

								random next < 0.1 ifTrue:

										[source := LinearGradient from: random next @ random next to: random next @ random next.

										source addStopAt: 0

											red: random next

											green: random next

											blue: random next

											alpha: random next squared * 0.25.

										source addStopAt: 1

											red: random next

											green: random next

											blue: random next

											alpha: random next squared * 0.25.

										source extend: ExtendStyle pad]

									ifFalse:

										[source := RadialGradient from: random next @ random next

											radius: random next / 2

											to: random next @ random next

											radius: random next + random next.

										source addStopAt: 0

											red: random next

											green: random next

											blue: random next

											alpha: (random next squared min: 0.5).

										source addStopAt: 1

											red: random next

											green: random next

											blue: random next

											alpha: (random next squared ).

										source extend: ExtendStyle reflect].

								cr

									source: source;

									paint]].

				cr paint]].

window component: vb.

window openWithExtent: 1400 @ 900