seandenigris.com

All of Alan’s speeches are packed with “aha!” moments. This one is no disappointment…

I thought the ending was especially profound:

Every human being is born with the potential to learn to see… with their hearts, bodies, spirits, and minds, and to learn to be… vividly alive and human…

Our great gift is that, though we are the stuff that dreams are made of, we can invest those dreams with the clearer knowledge brought by careful study beyond our simple prejudices.

There is nothing more powerful than imagination coupled with investigation. Imagination allows us to dream and conceive of better futures for us all. Investigation finds the powers and knowledge to make better futures happen.

So I think my advice to our species would be: “We can’t learn to see until we admit we are blind”.

In other words, let us learn how to wake up from the slumbers of our nervous system, culture, and beliefs, [and] try to find out what is going on and what is really needed.

The full transcript is available at forbes.com

If you see an error at the bottom of your blog pages like:

 990

The problem is that the prepare function was recently changed to require at least two parameters.

As my Inove theme doesn’t seem to be supported, I dove it to fix it myself.

I quickly found a simple fix online. N.B. depending on the application, there may be security ramifications; the changeset linked above mentioned that authors may have been incorrectly using prepare to sanitize queries.

That having been said, to eliminate the error, just change /…/wp-content/themes/inove/footer.php: line 22 from:

$post_datetimes = $wpdb->get_row($wpdb->prepare("SELECT YEAR(min(post_date_gmt)) AS firstyear, YEAR(max(post_date_gmt)) AS lastyear FROM $wpdb->posts WHERE post_date_gmt > 1970"));

to:

$post_datetimes = $wpdb->get_row("SELECT YEAR(min(post_date_gmt)) AS firstyear, YEAR(max(post_date_gmt)) AS lastyear FROM $wpdb->posts WHERE post_date_gmt > 1970");

That is, remove the call to prepare.

Hope that helps!

Why

The most frequent use case I have is for pending bug fixes. Imagine this… you find a bug in Pharo that you need fixed to progress on your project, so you fix it. Now, you’ll need the fix to be present anywhere your project is loaded, so what do you do while waiting for the fix to be integrated? You’re obviously not about to manually file in changesets when you have a powerful tool like Metacello! And anyway, you don’t want to have to edit the scripts for your continuous integration server.

How

I’ve found two ways I like to handle this scenario. I’ll show the (slightly) easier one first.

Method #1 – #customProjectAttributes

This is the method to use for Monticello packages

1. Make sure your configuration has #customProjectAttributes

Depending on the version of Metacello that was used to create your ConfigurationOfMyProject, you may have to add this method (which is easy enough).

In ConfigurationOfMyProject>>project, if you see the following two statements:

	"Construct Metacello project"
	constructor := (Smalltalk at: #MetacelloVersionConstructor) on: self.
	project := constructor project.

Change them to the following:

	project := MetacelloMCProject new projectAttributes: self customProjectAttributes. 
	constructor := (Smalltalk at: #MetacelloVersionConstructor) on: self project: project.

2. Define your custom attributes

#customProjectAttributes will return a collection of symbols that will be added to the Metacello platform symbols e.g. #’squeak4.4′ or #’pharo2.0.x’. The following is for the bug fix example we discussed earlier. The general process is a) declare a condition that let’s you know the fix hasn’t been applied in this image (e.g. a class is not present or DNU a message), and if true, add an attribute declaring that (e.g. #’PharoIssue6300′, as below).

customProjectAttributes
 
	| requiresPharoFix6300 requiresPharoFix6382 attributes |
	attributes := OrderedCollection new.
 
	requiresPharoFix6300 := (Morph canUnderstand: #hasKeymapCategoryNamed:) not.
	requiresPharoFix6300 ifTrue: [ attributes add: #'PharoIssue6300' ].
 
	^ attributes.

3. Finally, add fixes to your baseline

With this method, they must be packaged with Monticello. See method #2 below if you have to use changesets or .st files

	spec for: #'PharoIssue6300' do: [
	spec package: 'SLICE-Issue-6300-Detach-keymaping-shortcuts' with: [
		spec repository: 'ss3.gemstone.com/ss/PharoInbox' ].
	spec package: 'VimPharo' with: [ spec requires: #'SLICE-Issue-6300-Detach-keymaping-shortcuts' ] ].

Method #2 – #preLoadDoIt:

This is the method to use for changesets or .st files

1. Add a #preLoadDoIt: to your baseline

For example:

	spec for: #'common' do: [
		spec blessing: #'baseline'.
		spec preLoadDoIt: #preLoad.
		...

2. Define your callback

This method is going to look much like #customProjectAttributes in method #1. The main difference is, since Metacello can not handle file-ins, you will load the code right in this method instead of delegating, as in the following example:

preLoad
 
	| shouldFixIssue7294 |
	shouldFixIssue7294 := (EventHandler canUnderstand: #keyStrokeRecipient) not.
	shouldFixIssue7294 ifTrue: [ '/path/to/issue7294.cs' asFileReference fileIn. ].

When

So when would you want to use method #2? For one, you may already have a changeset handy. But the other reason is time decay. In Pharo, for example, because of the rapid pace of development, the package you fixed may have another fix applied first. Now, loading your version may silently replace those changes (this is what happens in the MC browser, I assume Metcello works the same way). I’m actually still figuring out the tradeoffs here for myself. For now, I default to method #1 unless I have a specific reason for #2.

Summary

So there you have a simple pattern to conditionally load packages or code files in a Metacello configuration

Hope it helps!

Motivation

Many time I wish I could send a non-existent message to an object that’s part of the built-in Smalltalk library.

For example:

String>>surroundedByDoubleQuotes
 
	^ $" asString, self, $" asString.

Packaging

Simple Case: Project-specific Extensions

In Pharo, I can store this method in a package different from the one of the class in question. This is called an “extension method” and the implementation is currently a bit of a hack… You put the method in a protocol that starts with an asterisk followed by the package name. Thus, for the example above, if my project was packaged in MyPackage, I could package the method with it like this…

For methods that are project-specific, this is all we need (although hopefully now that Pharo is working on first-class packages, it would be great if we could have both a protocol and specify an extension). However, the method above really has nothing to do with a particular project. It seems generally useful; and indeed, I find myself using it over and over.

Generally Useful Extensions

In these cases, it doesn’t work to package the method with the project that uses it, because if more than one of these projects are loaded into the same image, one method will override the other, creating a mess in Monticello. So I’ve been experimenting with two approaches.

The naive way would be to package all such methods in one package, e.g. “PharoExtensions”. This is the first thing I tried, but I was a bit uncomfortable with the all-or-nothing idea – that I’d have to load every extension I’ve ever created to use just one.

The most flexible tack is to package each method individually. The method above could be in the “StringSurroundedByDoubleQuotes” package. This way, one could load the method without effecting any other parts of the system. However, a package is a bit heavy-weight for just one method.

A Compromise

The current idea I’ve been playing with is to mirror the existing package structure of Pharo. For the above, String lives in “Collections-Strings”, so I tack on a standard suffix, making it “Collections-StringsSpd”. Now, we can load extensions for only the packages we are using, without having a confusing mess of ClassNameMethodName packages.

I read a great article about buying an apartment “for free” in NYC. It was well-written and thought-out, but missed a crucial financial factor that we all tend to forget about – opportunity cost.

From Wikipedia:

Opportunity cost is the… sacrifice related to the second best choice available to someone

In other words, we give up the benefits we would have gained had we made a different choice.

This was my comment to the author…

Nice analysis! For me, renting is still preferable because of two other factors. 1. Liquidity – if real estate prices in the area go down (everything has a cycle and it’s happened before in a big way in NYC), and I’m renting, I just walk away, leaving the owner to worry about it. You’ve made a bet that prices will go up; which is fine, but not guaranteed. 2. Opportunity cost – the 3.5% increase you’re hoping for will probably not keep pace with inflation (even the gov’t fantasy number, no less real inflation). But worse (if you’re wrong), you will not be investing any of the money tied up in equity in other asset classes. Again, this is another bet on real estate; this time vs. stocks or precious metals or agriculture… So I’m not saying it’s a bad idea, just that nothing comes for free

Recently, calendar events entered on my iPhone stopped syncing to my Mac. Calendar syncing was enabled, and I even tried “Replacing Calendar Information on This iPhone” (next sync only).

Luckily, it ended up being pretty easy to fix:

1. In this Apple article, follow the instructions under “For issues with syncing calendars” (I skipped the steps before that)
2. Restart iTunes (I tried to sync without this step, but got a message like “sync session cannot be started”)
3. In iTunes, go to the “Info” tab for your iPhone, and make sure calendar syncing is enabled

That should do it. Good luck!

From problem to source browser in 2 minutes (it took much longer to write this post about it)!

UPDATE: InspectIt (sorry, first version said “DoIt”):

'/path/to/home/Library/Mail/V2/Mailboxes/Notes.mbox/' asFileReference allChildren
    select: [ :e | e extension = 'emlx' ]
    thenCollect: [ :e | e readStream contents ].

After upgrading to Mountain Lion, the following all seemed to be broken:

• MacPorts… Issuing a selfupdate command produced:

  checking whether the C compiler works... no configure: error: in '/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/base': configure: error: C compiler cannot create executables

• make…

  command not found

• cmake…

  error: There is no SDK with the name or path '/Developer/SDKs/MacOSX10.8.sdk'

The solution to these problems were fairly simple:

• MacPorts – reinstall with the Mountain Lion installer
• make – install Xcode command line tools per this StackOverflow answer
• cmake – upgrade via “sudo port upgrade cmake”

A few minutes later, I was back in business compiling the Pharo Smalltalk VM!

Apple’s “free upgrade to Mountain Lion” for MBP retina purchasers, announced without qualifications at the WWDC, has a 30 expiration from time of purchase.

Sounds reasonable… except that they never put that anywhere in writing when you make your purchase… oh, and that Apple’s recent OSes have been notoriously unstable at their release… oh, and that my $3000+ laptop was freezing (i.e. worse than kernel panic, no feedback whatsoever) several times daily, and I didn’t want to complicate debugging by upgrading the OS while I was diagnosing the problem.

When you add all this up, it lead me to wait until 10.8.1 to upgrade, at which time Apple support told me that they thought the best course of action would be to screw me out of the $19 for Mountain Lion, even though I had just spent more than $3000 and they had made a public promise to give it to me for free.

So they sent me a survey with the following question:

Is there anything that the Advisor could have done better to resolve the issue during the call?

and my answer:

At issue is the standard support response at mega corporations, which is that everyone you speak to doesn’t have the authority to do the right thing, even if both sides agree on what that is. Of course the follow-up is that there is someone who does have that authority, but there’s no way to actually talk to them (in this case there was an email address to which I could send a message). So, probably the only thing “that the Advisor could have done better to resolve the issue” would be to quit their job at Apple and start a small computer company in their garage, from which I could buy computers, and receive reasonable support decisions because responsibility is not diffused among countless executives, directors, and other bureaucrats. Although, that somehow sounds familiar – oh right, that’s what Apple used to be – so until the culture evolves beyond the evil economics of Milton Friedman (i.e. profit at any cost), there’s probably nothing they can do. Also, it’d be hard to do all that “during the call” because I don’t like waiting on hold and had already been transferred four times

Mark Watson wrote a nice blog post about his appreciation for Pharo and its progress.

I was inspired to comment on my own experience of Pharo as we move toward 2.0:

Thanks for the shout, Mark! Given how much you’ve enjoyed Pharo so far, I think you’ll be really impressed after the 2.0 release – I’m sure it will be a game-changer.

Much of the work the past few years has been in improving Pharo under the hood, like the new compiler, class builder, vector graphics, keyboard shortcut framework, and countless cleanups. This has been coupled with great leaps in infrastructure, like the CI server testing many variants of Pharo and its VM on Mac, Window, and Linux with every commit.

Now, all these investments are starting to payoff for Pharo users:

• Continuous integration has given us the confidence to replace the uggggly File library with FileSystem, a beautiful object-oriented library which is a joy to work with.
• Nautilus, the new browser, has long-awaited features like a history and custom groups.
• I’ve been playing around today with Vim bindings for Pharo tools, made easy by Keymapping.
• Fuel is a new fast object serializer
• Fuel might soon allow near-instantaneous bootstrap times for Metacello, the new package-mananagement system, which is getting closer to RubyGems (plus tools) every day
• The Pharo Kernel is driving the system to become more modular

I feel that we are close to a tipping point where the system becomes so easy and fun for developers that we will see a self-perpetuating revolution in the IDE. For me, Vim bindings are something I’ve sorely missed since finding Smalltalk two years ago. It’s only now that I’ve seen in Pharo an opening to make that dream a reality…

Now, if we can just clean Morphic…