Archive for category macruby
My name is Matt Aimonetti, and in my free time I work on Apple’s open source Ruby implementation named MacRuby. I’m also the author of O’Reilly’s MacRuby book. As you can imagine, I’m very thankful that Apple initiated the MacRuby project a few years ago and have been an avid supporter. MacRuby is awesome to develop OS X native applications using the Ruby language and even allows you to compile down your apps to machine code. It’s a great alternative to Objective-C.
MacRuby is so awesome that Apple is even using it in its upcoming OS. The only problem is that Apple apparently decided to not share MacRuby with other OS X developers and put MacRuby in the OS private frameworks. While this doesn’t affect the project itself, it does affect OS X developers like myself who can’t link to Lion‘s private MacRuby framework and are forced to embed MacRuby with their applications.
That’s why I have opened a ticket on Apple radar system to ask that MacRuby be made a public framework.
If you also want Apple to make this change, please take a minute and let them know.
Today I was helping someone write an Objective-C framework around cocos2d.
C/Objective-C code can be called directly from MacRuby. However the Obj-C code you would like to use might be using some ANSI C symbols that are non-object-oriented items such as constants, enumerations, structures, and functions. To make these items available to our MacRuby code, you need to generate a BridgeSupport file as explained in this section of my book.
In our case, we were working on the framework and I didn’t feel like manually having to regenerate the BridgeSupport file every single time I would compile our code. So instead I added a new build phase in our target.
And I added the following script to run at the end of the build:
# This step generated the bridgesupport file for the framework
mkdir -p $TARGET_BUILD_DIR/$PROJECT_NAME.framework/Resources/BridgeSupport/
gen_bridge_metadata --64-bit -f $TARGET_BUILD_DIR/$PROJECT_NAME.framework/ -o $TARGET_BUILD_DIR/$PROJECT_NAME.framework/Resources/BridgeSupport/$PROJECT_NAME.bridgesupport
e script just executes the steps required to add the BridgeSupport file to your framework. I can now rebuild my framework without having to worry about BridgeSupport.
I just pushed a major update to my MacRuby book.
If you already purchased an electronic copy (thank you!), go to your product page and download an update. Note that if you are on an iPhone or iPad and you click on the .epub link, the file will automatically load in iBooks, same thing if you have the kindle app installed and you are clicking on the .mobi file.
If you haven’t purchased an electronic version yet, you can still read the book in HTML format here. If you choose to do so, please still think about leaving a review on the O’Reilly site to show your support to myself and to my publisher.
What’s new in this update?
- I refactored the introduction to the book, you know have a new Chapter 2 which introduces you to GUI app development and lets you build a full app right away to give you an idea of what is available.
- Chapter 3 covers more advanced concepts and was updated to reflect changes made on trunk.
- The chapter on Core Data is now almost done, I will soon push an update with the end of the chapter, but between the chapter content and the example app, you should be good to go today.
- GitHub repo with the code used in the book. (work in progress, I need to move more code there)
- The book is now divided in two parts, one more theoretical and more practical. Even if part 2 isn’t written yet, the table of contents shows some of the examples I will cover. I hope to have some of these chapters written in a few weeks.
- Lots of small fixes and updates thanks to the readers comments and to my editor.
Finally if you are interested in pre-ordering the book, Amazon runs a great deal on the book:
Thank you for your support!
The JS bridge only works when using WebKit so we need to create a tiny browser to test our code. What we are going to do is to make an object available via JS and also trigger some JS to test the bridge both ways. Here is the full code:
On the object we want to make available via JS (instance of Cat), we have to make the methods available by defining def self.isSelectorExcludedFromWebScript(sel); false end
To trigger JS from Ruby, we use #evaluateWebScript on windowScriptObject. In our example we are using JQuery since it’s already loaded in the DOM. We also go full loop by printing out the result of JS calling a method on our Ruby object.
Here is the thing, MacRuby doesn’t have the age method compiled/registered yet so JS can’t call it. To fix this problem we force the registration of the method by doing: @kitty.respondsToSelector(“age”). Note that if #age was taking arguments, we would have to use @kitty.respondsToSelector(“age:”) and then evaluate the JS like that: @js_engine.evaluateWebScript(‘animal.age_(12)’)
Hopefully by the time you need to do something like that, MacRuby 0.8 will be released and you won’t have to worry about that
I started thinking about working on “MacRuby: The Definitive Guide” last year when I realized that the project had a great future but there was a serious lack of documentation. With the support of the MacRuby team, I worked on a table of contents and a pitch. The next step was to decide what we wanted to do with the book.
I know a lot of technical book authors and most of them will tell you the same thing: if you think that you are going to make money writing a book, you are wrong. Even if your book sells well, because of the time invested in writing the book, you are probably better off doing consulting work and charging by the hour.
So since day one, I knew that this project would not make me rich. The goal was to share knowledge not to reimburse my mortgage or save California from bankruptcy. While publishing a web book is great, distribution is quite limited, especially if you try to reach people outside of your network. That’s why I decided to start talking to a few publishers. Most publishers I talked to were interested in working on the book, however they were not really keen on publishing a Creative Commons Attribution-Noncommercial-No Derivative licensed book.
Let me explain why I think releasing technical books under a CC license is important. As you might know (or have figured out by now), I am not a native English speaker. I actually learned my first English words thanks to the computer my dad had at home. The problem when you don’t live in an English speaking country and you want to learn about the cutting edge technology is that you have to understand English. Thanks to the Internet, learning and practicing English is now much easier that it used to be. However, if you want to have access to books, most of the time you have to wait until someone translates the book and publishes it in your country or you have to manage to get an English version delivered to your country. This is often a pain because of national credit card limitations, international delivery restrictions etc… If you manage to find a way to get a copy, the book ends up costing a lot of money.
What does that mean in practice? Most of the technical books are first available in the English speaking western world, then slowly translated and/or distributed around the world. By the time you get a legal copy in Bolivia, Algeria or Vietnam, a new edition is probably out in the US probably because the technology evolved. Maybe that explains some of the book piracy worldwide?
Think about it for a minute: knowledge is power and time is money. And what do we do? We delay knowledge distribution. This is why I am a big fan of the Khan Academy and its awesome free online courses.
Turns out O’Reilly shares my vision and has already published a lot of books under various open licenses: http://oreilly.com/openbook/ I was also interested in publishing the content of my book ASAP so people could access it right away even though there would be lots of typos and missing content. This is also something O’Reilly has already done with the CouchDB and the Scala books.
Talking with Jan Lehnardt about his experience working with O’Reilly on the ‘CouchDB: The definitive guide’ book, I realized that we seem to have some shared interests. I contacted Jan’s editor and we decided to start working on the MacRuby book. The book will be available later on in all the usual commercial formats and I hope people will show their support so O’Reilly will be encouraged in their choice to continue publishing CC licensed book. At the end of the day, purchasing a CC licensed book helps supporting the authors, the publishers but also all the people who can’t have access to the latest technical books.
Finally, working on a book is not an easy thing, especially when you have to write it in a language that’s not yours. But I have to say that the community support has been amazing. Even John Gruber sent a fireball my way. And since the announcement was made, I have received a lot of comments, tweets, emails etc… It is very encouraging and it gives me the motivation needed to work on the book after a long work day.
As I’m working on my upcoming O’Reilly MacRuby book, I’m writing quite a lot of example code. I have spent the last few weeks digging through most of the Foundation framework classes to hopefully make Cocoa more accessible to Ruby developers.
In some instances things might look quite weird to someone new to Cocoa in some cases, things seem almost too easy. Here is an example implementing a undo/redo functionality using Foundations’ NSUndoManager.
framework 'Foundation' class Player attr_accessor :x, :y def initialize @x = @y = 0 end def undo_manager @manager ||= NSUndoManager.alloc.init end def left undo_manager.prepareWithInvocationTarget(self).right @x -= 1 end def right undo_manager.prepareWithInvocationTarget(self).left @x += 1 end end
Which you can use as such:
>> lara = Player.new => <Player:0x200267c80 @y=0 @x=0> >> lara.undo_manager.canUndo => false # normal since we did not do anything yet >> lara.left => -1 >> lara.x # -1 => -1 >> lara.undo_manager.canUndo => true # now we can undo, so let's try >> lara.undo_manager.undo # undo back to initial position => #<NSUndoManager:0x200257560> >> lara.x => 0 >> lara.undo_manager.canUndo => false # we can't anymore which makes sense >> lara.undo_manager.canRedo => true # however we can redo what we just undone >> lara.undo_manager.redo # redo to before we called undo => #<NSUndoManager:0x200257560> >> lara.x => -1
The above example was tested in macirb but as you can see, actions can be undone and redone very very easily. This is just a quick preview of what you can do using Ruby + Cocoa and hopefully it will give you some cool ideas to implement.
After going through two betas, MacRuby 0.5 final is now released and can be downloaded by clicking on the icon below:
Don’t worry about having MacRuby and Ruby 1.8.x or 1.9 installed, MacRuby is namespaced and won’t affect your current Ruby installations, just download and launch the installer. (Note: The build was compiled for SnowLeopard only)
You can read all the details of the release on the MacRuby website.
So what changed since 0.4? Too many things for me to list them here but basically 0.5 uses LLVM to compile code and make MacRuby faster and integrate better with the Obj-c runtime. However since the last beta, here is what changed:
- HotCocoa is now a separate gem
- improved AOT compilation
- Grand Central Dispatch support – use all your cores without the pain of threads. Read this post for more info.
0.5 is a solid release which I consider production ready, I personally wrote a few of small Cocoa apps in MacRuby and everything has been working very well. Of course, I’m also excited about the new stuff in 0.6 trunk like the debugger previewed a few weeks ago: http://merbist.com/2010/01/18/how-to-detect-cylons-with-macruby/ but also some drastic changes in the primitive classes that I might cover later on.
Finally, people are asking if the iPad will be able to run apps running in MacRuby. Unfortunately, the current answer is: no. The two issues with the IPhone/iP*d OS are the lack of Garbage Collector and support for BridgeSupport (needed to define CocoaTouch constants available from MacRuby). However, this matter is being discussed on the mailing list and progress is made by contributors (the core team primarily focusing on the desktop).
That is going to be an exciting Ruby week as MacRuby 0.5 is now out and Rails 3 beta/RC0 is expected really soon.