The secret is out!

For all the millions of people reading my blog, I have a secret to share: the much-anticipated changes in Hobo, that were promised for the end of the month, are now mostly available in Hobo version 0.7.3.

Okay, okay, they didn’t really promise it, but publicly set that as a goal.

And okay, okay, it’s not really a secret—they posted it on their web site, but only in the forums, so only the dedicated few would find it.

And while you’re pinning me down with technicalities, there might not be quite a million…

RubyCocoa on iPhone

I’m currently downloading (‘as we speak’–it’s 2.1 GIG) the iPhone SDK, after recently playing around with developing toy apps last night in RubyCocoa.

The idea is irresistable (if not slightly implausible) that it just might be possible to build iPhone apps with RubyCocoa. A quick Google search suggests that others are asking the same question, but no one seems to have an answer. But something on Apple’s site suggests that this might be possible:

The applications you create with Ruby and Python are packaged exactly like native Mac OS X applications. Your end-users will not be able to tell the difference. What’s more, Apple is committed to binary compatibility between releases of Mac OS X. This means you will no longer need to embed the runtime and language interpreter in your application.

So they’re saying that (for non-iPhone RubyCocoa development, at least) you don’t *need* to embed the (RubyCocoa) runtime and language interpreter in your application. This implies that it is possible to embed the runtime for RubyCocoa, and if it’s possible to do on a Mac, why not on an iPhone?

Does anyone know any reason that this would or would not be possible?

Plugging Ruby into Your Brain, revisited…

Jesse Newland has an interesting post about how to use Ruby one-liners from QuickSilver, but it wasn’t working reliably for me. Also, I wanted it to show the result in large type, rather than replacing the text of the QuickSilver command prompt. So I tried my hand, even though it relies on passing the Ruby code through AppleScript, and I’m definitely not an AppleScript programmer.

Here’s my version:

using terms from application "Quicksilver"
  on process text ruby
    do shell script "ruby -00 -e '" & ruby & "'" returning result
    show large type result
  end process text
end using terms from

I don’t have any basis for this but an irrational hunch, but I’m hoping that changing the way it returns the result will also help with the reliability. The example one-liner he gave on his page didn’t work for me with his version… let’s see if it works with mine…

(imagine progress bar here)

Whoohoo! It works. It’s possible that I mistyped it when I tried his version, so let me do it again, now that I have a proven snippet in my clipboard.

(imagine another progress bar here)

Whoops! It worked. OK, it must have been a typo on my part… So mine doesn’t really solve anything, it just changes the way the result is displayed.

Come to think of it, although its less flashy, his version has the advantage of making it easy for you to copy the result to your clipboard. Oh well, now we have two versions to choose from. I saved his as “Execute Ruby” and mine as “Execute Ruby–Large Type”.