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

Saturday, I conceded to take part in that podcast that James and David and Michael do. This is not an advertisement. At all. It's a bunch of rambling and talking over each other, where my contribution is to take nothing seriously and mock much of what is said. I'm not sure they'll invite me back anytime soon.

At one point, we had a discussion about why there is no second and third methods. Pros and cons both ways of course. And we looked at some code in the system where at: 2 is used, and surmised what this told us.

Anyway, in flippancy, I suggested that one way of encoding a large range of at: someIndex methods tersely was to simply use roman numeral selectors. The nice thing about roman numerals is that they start at one, so they match Smalltalk code well. I was then challenged to make it do tail based access as well. I had said I would use case for this distinction, but in the end decided to use a trailing underscore to indicate that the selector should go from the back of the collection, rather than the front. Mixed case is supported.

What a pile of manure, huh? But such is the normal kind of fun hack for me. And it turns out that NormalManure is a nice anagram for "Roman Numeral", so I published it in the Open Repository under the name of NormalManure. The other part of the blog title composed of roman numeral characters (my second candidate for a goofy package name).

So, load that. Now instead of having to use verbose method names like first, you can just i. And if you want last, you just use i_. You can evaluate the expression of Object comment D which will return the 500^th element of Object's comment. Enjoy.