The Changelog: Software Development, Open Source - Ruby Motion and MacRuby (Interview)

Episode Date: June 26, 2012

Wynn and Sam caught up with Laurent Sansonetti to talk about MacRuby, RubyMotion, and more.

Welcome to the ChangeLog episode 0.8.2. I'm Adam Stachowiak. And I'm Winn Netherland. This is the ChangeLog we cover what's fresh and new in open source. If you found us on iTunes, we're also up on the web at thechangelog.com. We're also up on GitHub. Head to github.com slash explore. You'll find some Trinity reposts, some feature reposts from our blog, as well as the audio podcast. And if you're on Twitter, follow the ChangeLog and me, Adam Stack. And I'm Penguin, P-E-N-G-W-I-N-N.

Speaking of up on GitHub, I've moved on up to GitHub as about a month ago. Yeah, you're a Githubber now. I'm a Githubber. This is the first show we've put together since I made that move, so I'm not trying to keep any secrets or anything, but it's the first time that we've had the opportunity to announce that, so I'm excited to be over at GitHub. We don't keep secrets around here. No.

Speaking of new faces, Sam Sophus has joined us. This is his first episode to join us on air. He's been blogging over at thechangelog.com for a couple of months on iOS and Coco. Sam's a really talented iOS developer. He's also got a new app that we want to plug coming out. It's called Cheddar. It's at cheddarapp.com. It's got a web app and an iOS iPhone app as well,

and it syncs via Pusher, who's been supporters of the show recently. And your to-do list just gets updated in real time directly from the web to your phone. I love the fact that he actually used Pusher, too. It's nice to not so much get a great sponsor, but also to see how it could be used in such an awesome way. We've both been using Cheddar, been really impressed with it. It's got some open source byproducts as well. He's got a pusher library called Bully. It's pretty cool.

Check that out. This week we talked to Laurent Sansonetti from MacRuby and RubyMotion. Sam grilled him on some of the finer points of memory management. I'd say he actually did quite a good job with this first time out on the podcast, too. Just having the background of Coco as well as Ruby was a really good fit.

Sam was playing the part of the expert, and I was just the fanboy as usual. Teeing him up. Exactly. Fun episode. Should we get to it? Let's do it. We're chatting today with Laurent Sansanetti, the developer of RubyMotion and MacRuby before that.

So why don't you expand on that, Laurent, and give yourself an introduction for our listeners. Hi. Well, thanks for inviting me. Yeah, so my name is Laurent Sansanetti, and I was the creator, and I'm still the main developer and maintainer of MacRuby. MacRuby is a Ruby implementation on top of core OS X technologies. And I worked on MacRuby when I was working at Apple.

So I worked at Apple for about seven years on various things, from OS X to iLife to a lot of scripting technologies. And MacRuby was one of my projects there. And recently I left Apple to do a startup. And so I created a startup a few months ago. And the first product is called RubyMotion. And RubyMotion is a port of MacRuby and for iOS so it allows you to do

iOS applications using Ruby and that's all about me I guess so I'm a long time Ruby enthusiast and so that's why I really want I'm currently working on pushing Ruby on iOS

where it has never been yet and iOS is probably the best place for Ruby to exist right now. We definitely want to jump into RubyMotion, but just to keep this, I guess, chronological, let's talk about MacRuby first and how that project came about. So MacRuby was... So that's a good question we can take a history course

and if we go back to Lopert so it was 10.6 if I'm not mistaken no sorry 10.5 and for 10.5 I was responsible for the integration of Ruby in OS 10 so

we pushed a new Ruby implementation, which was 1.a.6, which was at that time the latest version. We pushed Ruby gems, and we also pushed Rails on the system, and we pushed Ruby Cocoa. And Ruby Cocoa was a bridge. Well, it's still a bridge between the Objective-C runtime

and the C-Ruby runtime, which are two different programming languages. And the goal of RubyCoco was to be a framework that lets you write Mac applications using Ruby. But it's a bridge. So the problem of RubyCoco is that it has a lot of performance issues and a lot of stability problems because as a bridge it has to make sure that it has to keep track of two separate object models at the same time. So for instance, using RubyCocoa you have two different set of classes that exist at the same time in your application. When you want to use an Objective-C class from Ruby, the bridge has to create a fake class and forward all the messages. So it has a lot of problems. And I was chatting with our vice president at the time.

His name is Bertrand Serlet. And he had this idea of, why don't you just re-host Ruby on top of the Objective-C runtime? This way, you don't need to breach classes and objects anymore. You would have a fully native implementation of Ruby, but on top of the same runtime, and you would eliminate all the problems. And that was, I think, in November 2008,

2004, sorry, or 2005. I don't even remember. And during the Christmas break, I started hacking on it. And it turns out that it was working. So I went back to him and I say, well, it's working. So should we keep this project? And he says, yes, sure, let's go ahead. And we picked the name MacRuby and then MacRuby was born.

So that's the story of MacRuby. And MacRuby was maintained at Apple for four years, I think. So it was one of my side projects at Apple. And the last year and a half, it was my main project at Apple because MacRuby was used by Apple on a few products. And on Lion, actually, some functionality of Lion is written in Mac Ruby. So we really had to make sure that it was working fine. So what point did you, I guess, envision in the next phase of that

in porting it to iOS and what later became RubyMotion? Well, so when Lion was about to ship, it was clear that Apple was not interested in maintaining MacRuby anymore, so they asked me to work on different projects. Then I was a bit

sad because MacRuby was really growing and it has a wonderful community around the project, so I really didn't want to leave the project. So I thought about it and then I realized that in order to keep working on MacRuby, one thing I could do is push it on iOS because this wasn't something Apple was interested to sponsor. So I decided to leave the company and do the startup.

And right now it works because it allows me to keep working on the MacRuby code base while I'm making a living out of it. So it seems to be working. So how much of RubyMotion came from MacRuby? I know it uses MacRuby, but obviously there's a lot of stuff to make RubyMotion possible. So I'd be interested to hear about that relationship.

So the runtime is shared across RubyMotion and MacRuby. Other than that, everything has been rewritten. For instance, RubyMotion comes with its own compiler. So it provides static computation from Ruby code into optimized machine code, while MacRuby uses a just-in-time compiler. And I had to write a static compiler for RubyMotion because there is no way you can do just-in-time compilation iOS. There is no way to actually create memory pages and mark them as executable on iOS devices. It's forbidden for security reasons. So I had to work around that. And also some bits of the runtime have been optimized for iOS constraints.

And also the memory model is different on RubyMotion because we cannot use the Objective-C garbage collector because it doesn't exist on iOS. So I had to write my own model around the same principle as Arc, the latest memory model of Objective-C. So besides these differences, the code base is about the same. I'd like to draw a contrast, I guess, to some of the other tools in the space. And I know that architecturally they're quite different,

but just to give folks kind of a feel for where RubyMotion fits in. So RubyMotion, I guess in some ways could be compared to Titanium from AppCelerator and possibly MonoTouch. Would you care to kind of break down its differences architecturally? So I don't think it's comparable to Titanium or AppCelerator in the sense that Remotion lets you call directly into the IS SDK APIs. And also it gives you a binary at the end,

which is pretty much the same as an Objective-C binary when you look at the binary differences. So it uses the same runtime as Objective-C apps. It uses the same runtime as Objective-C apps. It uses the same APIs as Objective-C apps. So it's more close to Monotouch. Monotouch is doing the same thing that RubyMotion does, but for C Sharp. And on the same side, I think that,

I'm not very familiar, but I think that Titanium is actually using JavaScript to bridge into the... That's right. And so it's not the same thing because it's using a different runtime. It's actually bridging objects and classes, and it's creating APIs for all the SDK APIs so that you can use them in JavaScript. While in RubyMotion, for instance,

you can create a class that iterates from UIView, and the class you create in Ruby is going to be an Objective-C class directly that iterates from UIView, so there are no bridging things that are being made up under the contains. So it's really a native solution. So I was reading in the RubyMotion docs

that you can create a Ruby method that's callable from Objective-C which is really awesome can you talk a little bit about the language additions and such you've added in RubyMotion so these language additions have been

introduced in MacRuby so they are not new in RubyMotion. The thing is that if we go back to Blueprint and to RubyCoco, in RubyCoco, the only way to define an Objective-C selector

in Ruby was to replace the semicolons with underscore characters. So, for instance, you would do def insert object underscore at index underscore, then open parentheses and your arguments. So that wasn't very natural. And I thought about that a lot when I started MacRuby, and I came up with this syntax.

Then I had a couple discussions with Matt the author of Ruby and we came up that it was probably the best it was probably the best solution the best syntax that we could probably

so we we used that. We introduce, so this syntax was introduced in MacRuby, and it was picked up with RubyMotion after. So that's not a new extension. But basically, we extend the Ruby language so that you can define Objective-C selectors in Ruby, and that you can also call Objective-C selectors

using the same syntax. We should mention that RubyMotion is not open source, although this week you've open sourced part of the tool chain, the command line tool chain. Let's talk a bit about maybe as far as feature parity of developing Cocoa apps in Xcode versus the experience in RubyMotion? Yeah.

So, yeah, so we, so, yeah, last week we open sourced the build system of RubyMotion. So the community is growing so fast and is actually trying to extend the platform so quickly that it was inevitable to open source this part. And right now I think there are over five pull requests on GitHub already about extending the build system, so it was definitely a good idea. But if we compare RubyMotion with Objective-C and Xcode,

I guess that was the question, it's definitely a different experience. In RubyMotion, you do everything in the terminal using a command line. So you keep using your favorite text editor, Vim or TextMate or Sublim Text or even Redcar, which is actually great. You keep using your favorite text editor and you use the terminal for everything else. Creating projects, building projects, reading your projects in the simulator, sending your projects to your iOS device, iPhone or iPad,

or even creating IP archives so that you can send them to the App Store. Everything is done from the command line. It's always one command that you type. So it's very different from this Xcode environment where you do everything inside the same window and you type your code inside the same window, you get debugging. So it's a bit different.

I think the biggest difference so far is that in RubyMotion, when you type Rake, by default, it starts the simulator with your project. And there is an interactive console that shows up by default. It's called the REPL. And you can type expressions there that are actually interpreted in real time inside your application running on the simulator. So this is really something that is very different from Xcode because Xcode doesn't have this kind of interactive way of communicating with your application yet.

So in RubyMotion, you can, for instance, select elements from the simulator using your mouse and maintaining the command key. Then it creates a new context, a new shell context inside Ripple. And from there, you can type expressions like you can change the frame, you can change the background view, you can create new views. So it's actually very interesting to first to introspect all the APIs of iOS because you can try APIs using the console. It's really nice. And also, it's actually very cool to debug your application.

So when there is something going wrong, you can know. You can, for instance, connect to a specific view, and then you can type expressions there, and you can try to fix the bug in real time. And then once you're happy, you can copy-paste the code back to your editor. It was interesting seeing the, I guess, mixed reactions to RubyMotion from Objective-C developers.

So, Sam, you are an Objective-C developer. What has been your impression of the REPL? It's, like, mind-blowingly fantastic. Coming from Objective-C, like, only working with Xcode and such, like, I was trying to add some custom fonts to a RubyMotion application. And normally I would just, like, because the font names are like kind of arbitrary depending on which font you're using so I was like I usually go in app delegate and like log all the fonts and like find which one it is and I was like oh wait I have a console and I went in like UI font like family names and like there they are and I was like this is fantastic um like

I don't think like Objective objective C developers really know what they're missing out on. Um, cause the only console we're really used to is like setting a break point and then like GDB or LODB, like, cause it only worked that well. And, um, yeah, it's like, um, people should like be really excited to, to play with it. Um, another thing that's like super amazing, um, that I was like really happy about, um, I put the fonts in my resources directory and like the build system automatically added the info P list stuff for me. Um, which is really awesome. So good work. Yeah, we, we, we tried to, uh, the big system is system was really designed so that it picks everything by default. You don't need to specify information.

It tries to be smart. And sometimes it tries to be too smart. So we need to, there are a few things that we should probably fix. But yeah, that's the main idea behind the build system. Yeah, that's actually my favorite part of RubyMotion is how easy that is versus dealing with all these dialogues and Xcode and build configurations. Yeah, it's really fantastic.

Laurent, would you consider yourself just a tools developer or are you an end-user developer as well? Are you scratching your own itch when you're building these features or are you listening to feedback from others in the community? Well, that's a good question. Well, personally, I'm a programming language enthusiast, so my favorite thing to do is designing programming languages.

So I really like learning new programming languages and trying. I've been designing my own language since a couple of years, but this is really what excites me the most. Now in RubyMotion, what I like is that I can keep working on the project I created at Apple. And this is a codebase I'm very familiar with. But I'm not super interested in

working on applications. I prefer to work on runtimes, compilers, garbage collectors, this kind of thing. And working on Ruby Motion lets me work on compilers, garbage collectors, this kind of thing. Working on RubyMotion lets me work on compilers. This is really the area I'm very excited about.

But I'm not super excited about using RubyMotion to write applications. You mentioned community growth is one reason why you open sourced the toolchain. This is a unique project in that you've got a couple of different dimensions in which the community grows. You've got not only the Ruby gems for the Ruby community, but also CocoaPods, which we've had on the show previously for CocoaFramework. So do you see explosive growth on both of those angles? Probably, yeah. So I think there are over 100 open source projects related to RubyMotion and GitHub, and most of them are sample code. But there are quite a few libraries that are growing,

libraries around UIKit, CoreData, OpenGL, and various third-party libraries like Cocoa 2D, Cocoa 2D, sorry, or the Parse SDK, Facebook SDK. So we are starting to see an ecosystem that's growing around libraries for RubyMotion. And so far, people are making gems for these libraries. And CocoaPods right now is being used to bridge, actually to vendor third-party Objective-C libraries inside your project. But I've been talking to the CocoaPods author, which is actually a friend of mine,

and he's my personal hero. So if Eloy is listening to that podcast, he will know that. But we've been chatting about that, and there is probably a way that we can use CocoaPods to also include pure Ruby extensions for RubyMotion. So we don't know yet where the community will go, but I think that if we can use the same package system for everything, that's pretty going to be the best solution

and the simplest solution, at least, for Ruby Motion. So Sam, you're both an Objective-C developer and a Rubyist. How do you see Ruby Motion changing the way that you tackle applications? It's interesting because as an Objective-C developer, there's all these tools like Titanium and such. And looking at those, it's like, well, this is just a silly bridge that doesn't work that well or generates all this code that runs in a web view or whatever.

And I've been opposed to all these sort of tools that do anything except Objective-C. But that's why RubyMotion is so interesting is because it actually makes a good binary, and it's not just writing Objective-C or web views. I don't know. It's interesting. It's something that I didn't want to like at first, but I really like it a lot.

So, Laurent, do you consider this a gateway drug to Coco for folks that may not know Objective-C? Do you see it as an intermediate step or is this something that you hope folks will camp out in for a while and just build robust applications in RubyMotion? Yeah, that's a good question. I think that RubyMotion is definitely a gateway to iOS for people who are not familiar with C. And the problem with Objective-C is really that it's a C-based language, and most programmers these days don't know about C. So when they pick Objective-C, they have all sorts of problems

trying to figure out what the pointer is, or all the C background that comes with when you use Objective-C, they really have an issue to actually be comfortable with that. But RubyMotion is very different. So they just need to learn how to read Objective's interface, which is like 1% of the language. And then they are set. They can use all the APIs and they can build stuff. so i think that ruby motion is definitely a good way to get new programmers

inside the ios community and i'm currently in discussions with a few uh uh teaching groups around the globe that are teaching ios and they are very interested in using ruby motion in that way so that they can get new programmers on the platform more quickly instead of actually teaching them C and Objective-C. But at the same time, I think that right now, RubyMotion is very young, and I think it's only a month old. But in the future, there will probably be mature DSLs, domain-specific languages, around RubyMotion that will let you write applications in a very short amount of Ruby code.

Right now, when you look at the RubyMotion app, you can see calls to the iOS SDK. And people say, well, it looks like Objective-C, and that's true. We use the same APIs. And the power of iOS are in the APIs, not the language, of course. But I think that in the future, we will see mature libraries around UIKit and CoreData and everything.

And I think you will definitely be able to write a full-fledged application just by using these libraries. And from there, if you can, for instance, write a real app in less than 100 lines of Ruby I don't think that Ruby motion

would be a get read drag anymore because people really stick to Ruby motion for everything when you can write an application in 100 lines would you I don't know rewrite it in Objective C? Probably not because the less lines you write,

the less bugs you introduce, the code is more maintainable, it's easier to write, easier to read, easier to maintain. So that will probably be the killer feature of RubyMotion. Right now, RubyMotion is very young, but the community is growing so fast, and I think it's probably a matter of months

until we see mature libraries. Yeah. You know, I try to get out of the echo chamber of the Ruby community in which I live, but the Ruby angle aside, it's kind of hard to downplay the importance of a command line, tool chain, and a REPL. Those are two things that Xcode just really doesn't have today. Oh, yeah. And we have much more features in the pipeline

for RubyMotion and the REPL. So right now it's very simple, but in the next few weeks we'll start introducing new features, and I think it's probably going to excite more people. So let's check Twitter for some questions. Sam, what do we got? So Ryan Farnall, I'm probably saying his name wrong. He asks, any chance a good debugger is coming to complement the REPL for debugging?

And definitely coming from Objective-C, this is something that I'm just used to thinking and like breakpoints and such. So yeah, this is pretty interesting. Yeah, so yeah, the debugger is definitely coming. So it will be first integrated into simulator, and then we will try to integrate it on the device. So right, it will first come for the simulator. Are you thinking it will work similar to the Rails debugger, just adding the debugger call call or if you can say?

No, it will be more like GDB. So you start the repo, then you can break on, there will be a break method on kernel that lets you break on a specific method or a file line. It will definitely, it will feel like GDB or LODB or

any debugger that you get used to. So would you be able to debug on the device? Not the first iteration of the debugger. But we will make sure that the REPL works on the device also in the future. Very cool. Andrew Nesbitt wants to know, will improvements in RubyMotion like the REPL be backported to MacRuby?

So, well, there is already a REPL in MacRuby. It's called MacIRB, and you can type expressions there. There is no way yet to, well, you don't have the view selector thing. I mean, to select a view using your mouse, it doesn't work in Mac IRB but besides that

everything else is there so there is no really, I'm not sure if you would really be needing that especially since in Mac Ruby you use Xcode for everything Mac Ruby doesn't have the command line interface that RubyMotion has so to create a Mac Ruby project you use Xcode for everything. MacRuby doesn't have the command line interface

that RubyMotion has, so to create a MacRuby project, you use Xcode and you use IB to do your user interface, so you probably don't need the REPL that much, but you also have Mac IRB, and if you look at GitHub, you will see that there are various REPL for MacRuby

some of them are actually Cocoa apps which is good since it's actually using the run loop of Cocoa so that you can actually connect the REPL to your MacRuby app and type expressions there and you don't actually

block the main thread of the REPL when you type expressions. But besides that, I don't think that the REPL should be ported. Can you talk a little bit about how your version of memory management is different from the Objective-C ones we're used to versus retainer? Obviously, it's very different from manual memory management. But how it differs from Arc or the Cocoa Garbage Collection on the Mac? Yeah, so the memory method of Remotion is very simple.

So it's almost the same as Arc, except that it's done at runtime. So the runtime automatically inserts retainer release and auto-release calls for you when your application starts. So that's exactly how RubyMotion works. And right now it's extremely simple, but I'm working on a new version, which will ship in a few

months, that will be more deterministic and that will also be able to detect cycles. So when, for instance, you have an object that has reference to another one, and right now both objects are going to leak because they use the reference kind of one, both of them, so both objects will leak.

But in the near future, my goal is to introduce a system that lets you F-cycles and that doesn't force you to think about them. So I don't want to introduce weak references in RubyMotion because I think that it actually breaks the whole idea of automatic memory management system. You shouldn't need to think about weak references.

You should just use Ruby and don't think about that. So I really want the memory system to be able to deal with cycles and automatically clear objects that have cycle references. Especially if you could

have, like, if you call a block on an object and then reference that object in the block, like, breaking those would have, like, if you call a block on an object and then reference that object in the block, like, breaking those would solve, like, save a ton of typing, at least in Objective-C land. So, like, that would be fantastic in Ruby as well. Yeah, yeah, yeah. That was a great question by Owen, I guess, O, from the Twitter.

Up next, Anil wants to know, personally, Laurent, what tools do you use when you develop? Oh, so I use GDB and VI. So I actually, I'm a weird person, but I actually live in GDB. So GDB is my terminal, and I type expressions there. I use GDB as a repo for C and I start programs in GDB and I

build everything using GDB. So I'm a weird person. I do everything inside the same terminal and then I use MacVim for the code edition. I'm a big fan of Vim. I've been using VI for more than 10 years.

So my brain is, um, completely, um, I don't know, fucked up. Sorry about that. So I can't use anything else than VI.

I'm sorry. So it's all a VI and GDB. Do you have any plans for, um, like support with instruments or, or building your own profiling tools for Ruby motion? Yeah. Yeah, definitely. So we'll be coming with something soon.

To be honest, I don't know yet what the plan will be, but we definitely need to have a profiling story around Ruby Motion. I know that Forks has been able to use instruments to profile Ruby Motion Apps. And right now, there is no way to see your... I think there is no way to see the Ruby traces when you actually hold... When you request... When you hold a reference to an object and you see the backtrace of the allocation,

I don't think it shows the Ruby trace yet. But I think there is a way to do that. So we'll try to support instruments because it's probably the best profiler that exists on the Mac yet. At the same time, I would really want to have a profiler on the command line, something that you could just run your application using Rake,

and then it would automatically do a memory profiling and CPU profiling for you, and then you would get some results back into the terminal. I would really want a terminal version also. It would be really neat if there was something like, in Rails 3.2, they added the slow Cori profiler, so if anything takes a long time in development, it automatically logs and warns you that something's slow. That might be a neat addition. So, Laurent, I just want to applaud you on, I guess, the business model. I think we get

spoiled in the open source world to expect everything just to be handed over, the source included. I appreciate the way that you've open sourced what you could, but I was one of the first customers on the first day, even before I knew how, I guess, how much utility I would get out of RubyMotion. I've been a fan of the work you've done on MacRuby and just wanted to support that effort. How have you been received, I guess, in that business model in the community? Well, first, I would like to thank you

for purchasing RubyMotion. It's really nice and it's greatly appreciated. But so far, the community is great. I was also a bit worried about that because I'm a free software activist so it's really tough for me to do

a proprietary development right now. But so far the community is actually accepting your project very well. And the thing is that I've been thinking about this a lot and I don't think other way than charging customers

for using RubyMotion I could do the project open source but I would need to find a company to sponsor the work and the problem with that is that you always need to find a sponsor and sponsors tend to stop sponsoring you at some point. It's really a problem, and I had the same experience in the past.

Also, if you look at popular open-source projects right now, the contributors are actually being sponsored by companies. Sometimes they stop sponsoring them, and they need to find a new company, and they actually jump ships from one company to another one and right now the economy is actually very bad for other companies I think so

it's really tough for me I really want Ruby Machine to exist in the next five years I want it to be a real project something that people can actually trust in writing their apps. And so I want to keep working on Macro before at least five years and maintain it.

And I don't see any other way than actually charging the users so that they can actually get maintenance and software updates and so forth. So I really want to open source as many things as possible because I'm a huge free software activist but until I find another solution I'm afraid that parts of RubyMotion will be

proprietary, will be closed source Now in both of those models, both the corporate sponsorship model, I mean you've got politics in play with corporate interests, but in this model, you're kind of the you've got politics in play with corporate interests, but in this model, you're kind of the, you know, you've got to do everything in the vertical. You've got to have a nice design website. You've got to sell the thing. How much support have you

gotten on that aspect of it? And have you had to pay for all of those services up front? Yeah, so you're exactly right that doing a startup is very tough. I'm actually doing three jobs at the moment. It's very funny. So I do marketing, I do support, and then I do engineering. I mean, working on RubyMotion. But I'm currently, we generated enough revenue so that I can actually hire people. So I will have app very soon on the platform and on the support and the marketing side. And besides that, I'm actually doing okay. So it's not that much of work.

So I think I'm doing fine right now. What are your thoughts on bringing some of the build system and such to MacRuby on the Mac and kind of the other pieces of RubyMotion that aren't iOS specific? So the first thing I want to backport to MacRuby is the memory model. Because the Objective-C garbage collector that MacRuby is using is model because the Objective-C garbage collector that MacRuby is using is being deprecated in Mountain Lion. So it means that in Mountain Lion plus one, which will

probably be released in two years, it will disappear from OS X. So we need to replace the memory model of MacRuby with something else. So I'm currently trying to find out if I can backport the RubyMotion memory model to MacRuby. So it's not that easy.

It's not as easy because MacRuby is used more widely than RubyMotion. MacRuby is not only about Cocoa apps. People use it outside Cocoa, so outside the run loop, the Cocoa run loop. So I really need to find a solution that works in all the scenarios where MacRuby is being used.

So I'm still thinking about that with the rest of the MacRuby developer team. But this will probably be the first thing that we backport from RubyMotion to MacRuby. The

command line interface is pretty nice to have, but right now the priority is actually replacing the garbage collector. That makes sense. Well, I have a couple feature requests. I'll just fire them off.

It would be really fantastic if you could write static libraries or frameworks in RubyMotion, especially if I'm transitioning a large project to RubyMotion. It would be great if I could write pieces instead of just replacing all of the Objective-C all at once because that would be a ton of work for a larger project to RubyMotion, it'd be great if I could write pieces instead of just replacing all of the Objective-C all at once, because that'd be a ton of work for a larger project. So I'm sure that's lower on your priority list, but that would be really awesome. People have been asking if we can add support for RubyMotion code inside existing Xcode Objective-C projects.

And I think that's probably what you want, right? Right, right. And yeah, so we probably do something in this area. But it's not high on the to-do list right now because we want to focus on using RubyMotion to do everything. I mean, using RubyMotion to do everything. I mean, using RubyMotion to start an application. But we'll probably find a way so that you can use RubyMotion inside existing projects.

Can you chat about testing for a minute? That was one of the things that made me really excited about RubyMotion because as Objective-C developers, people rarely test, or if anything, it's just unit tests and never anything beyond that. Can you talk about the testing support in RubyMotion? So the testing support is actually very naive right now. So RubyMotion comes with Bacon, which is, I think, an RSpec clone.

So I'm not familiar with testing. So I'm afraid I'm not a big user of testing in Ruby. But bacon is a clone of RSpec. It's a simplistic clone of RSpec. So the code base is only one file. And RubyMotion ships with bacon. And by default, when you create an application, you get a spec directory and from there, you can write

Bacon specs. I think that by default, there is only one spec. It checks that there is a UI window inside your UI application. And I think by default, if you type break spec, it runs the spec and you get an error because we don't create

a UI window by default when you create a project. So that's the first spec that we have and it fails by default. So I think that it conforms to the test-driven development. You need to create the window and then run the spec again and then it will pass. And then

it's up to you and you can write any spec you want and so far i'm i i've not seen a lot of um projects that have been using the specs yet but uh one thing i saw is that some there is a there is a gem a gem that you can install that will actually colorize the output of Rake spec. So you get, for instance, green stuff for the spec that pass and red stuff when there is a problem.

I suspect that in that gem, there are samples of various Ruby Motion apps that actually have more detailed specs. It'd be interesting to see support for the instruments like UI automation stuff

in Ruby instead of JavaScript, because that's what instruments requires you to write. Surely that's a ton of work, but... Actually, we have... Someone is working on that right now. Amazing. He's working on that, and so he's having issues

connecting to instruments, so I'm trying to help him. But I think there will be some sort of announcement around that in probably the next few days. So for folks that might not be privy to this ecosystem, I guess it would be kind of a

fit for, say, Cucumber for RubyMotion, to use a bad analogy. It's it'd be similar to like Capybara or something. Cause it simulates, um, touches and like entering text in text fields and such. Um, and then you can see the result or like query the UI and see the state of things. So yeah Yeah. A lot of exciting stuff happening with Ruby motion. Thank you for your time. We're all, and we look forward to those announcements that are forthcoming.

Wow. Thank you very much for having invited me.