 In fact, I was just tweeting earlier that I feel a little bit bad about giving just an old boring technical talk, but a friend said, yeah, you've been picked for diversity. I like that. So you have to listen to one token-boring white male talk today. Anyway, so calling native code from Ruby, why would you even want to do that? So if you want to use some native library or system functionality, you might have to call into C code. But we don't really want to use a C extension for this, because nobody got time to deal with users' compiler problems. So one thing we have as part of the CocoaPods project is a gem called Xcode Proch, which deals with Xcode, which is the IDE for developing iOS and Mac apps. And we need to deal with this to integrate dependencies, which is what CocoaPods does. And it used to include a C extension for quite some time. And there were so many issues with that. For example, in some versions of OS X, building C extension was actually completely broken and added weird compiler arguments. Here is the problem of it is not very transparent if a C extension fails to build. You sometimes just see fail to build gem native extension, and then you have to look at some log file or something. And many users, of course, are not really familiar with, especially for our users, they're not sometimes not even familiar with Ruby, and even less with C extension, so it's really hard for them to even know what happens. And you can also have things like this, so you don't really know what happens. And it's not only us that have problems with C extensions. If you look at a really popular gem, and you look at their issues and search for compile, you see that there are over 200 issues relating to compiling. It's C extension, and it's not because they are doing a sloppy job, just that it's really hard to get stuff to compile on random users' computers, basically. But there's a solution, which is called Fiddle. Fiddle exists in Ruby since 1.9x, but really you want 2x, because there are some little details which don't work well on 1.9x, but that shouldn't be a problem so much. It's a problem for us in the beginning, because OS 10 shipped with 1.87 actually for a long time, but now we don't have that problem anymore. And it's a foreign function interface for calling C from Ruby. It uses deal open and deal sim, which are C APIs for dealing with dynamic shared libraries. And it can also be used to call Objective C, which I will be showing later. This is how it looks like in a very simple way. So you require the Fiddle gem, and you can deal open a shared library that is existing on the system, or that you just install via some other way. And then you have a function object. And when you instantiate it, you give it the symbol you want to load, which is the function, the C function you want to have exposed. You give it the parameter types, which is an array of constants, basically. I will show them on the next slide. And the return type. And what you get back is a function object, and that you can simply call. You give it the parameters, the function needs, and you get a result. So Fiddle has a couple of constants for all the different types in C, for void, for integer, char for all the floating point types, stuff like this, also for pointers, which is the type void p, void pointer. And it's also possible if you want to use something from the standard C library, which is exposed via the Ruby standard library, you can also just create a basically an empty handle with Fiddle handle new, and you can reference your own binary, which includes, of course, the C library. And let's look a bit at how we actually used it inside the Xcode approach, Jan. The first part, so basically we had two steps in our process of integrating it. The first thing we wanted to do is use core foundation, which is basically on macOS 10, it's the lowest level of functionality that is macOS specific, you could see. Under that is a C library, which is usually a positive thing, so it's portable, but the core foundation provides mac specific stuff. Among them reading and writing p lists, that is what we needed, so property lists, they're used for many tools that Apple writes, among them Xcode, and so we needed to call into core foundation to deal with p lists. And as we saw earlier, you need like four lines of code or so to call one function. And also you have this function object, which is a little different from a regular function. So what we wanted to do is to have a way to expose all the functions we needed as Ruby functions without writing too much code. So for that we created this little function here. And the first thing we do is, oh. So we have a cache basically of functions, which includes the symbol name, and that allows us to basically save the function object instances. So not every time we call a function, we have to create all the things. And the next thing, which is down here, is we define actually dynamically a method, which creates this function object with the symbol we need, with parameter types and the return type, as we saw earlier. And we also save that function as an instant variable, which is basically our cache. And then finally, we call that function and return this. So this is our dynamic function. Basically, this part is the dynamic function we create, and it returns, of course, the result of the function call. And we have one final nitty-gritty detail of core foundation, which is you have to do manual memory management. And there is, though, a way to do kind of automatic management, which is called auto-release. And the convention is if a function is called create something. So that's why we look for the create in the name of the function. If it's in the function, we have to call this auto-release. That allows us to, if we have created an object, it gets released automatically. So using that function, we created, so what we needed is also the path to the library that's up here. Here we do the DLO pin of it. And then we basically have another convenience function, which just takes this and calls the external image function we just saw. And what that allows us to do is we can just very simply call, create these functions with just one call to this external method, the name of the function, the parameter types, and the return type. And then we can just call this here like a normal Ruby function. So we don't have to care anymore if it is a function that comes from C or not. And that allows us to really keep the usage of FIDL contained in one module and the rest of the code base doesn't care. And with that, we can, for example, do this, which is converting a string, a CF string to a Ruby string. So that's something you have to do a lot. When you call into C libraries, you have to convert Ruby types to the C types because, for example, a Ruby array is not a C array. A Ruby string is not the CF string. So you really have to actually deal with these details of how to convert types. And especially for us, it was especially true because we needed to deal with this core foundation library. So the details of the function don't matter that much. It just shows that we can just call things like the CF data, get byte pointer as like a regular Ruby function. We don't have to care anymore. That is a C function, actually. So the next step we needed to take or we wanted to take. So it used to be that we just wrote this P list using core foundation. Unfortunately, this is not actually 100% the format that Xcode writes. So our next step was actually calling into functionality, like private functionality of Xcode to write it exactly as we wanted. And for this, we actually had to call Objective C. And we can also do this with Fiddle because Objective C is still having C calling conventions. And that means it is in the end calling C functions. And most importantly, there is one C function, which is called Objective C message send, which basically happens every time you make a method call in Objective C. So we again wanted to wrap this a bit. So we created this Objective C message send function, which takes, again, arguments and return type. And basically the only difference between the calling just a regular function and a method and Objective C method is it needs two additional parameters, two pointers. The first pointer is the object. And the second pointer is called a selector, which is more or less just the name of the method we want to call. So by creating this Objective C message send function, we could actually create Ruby classes, which are wrappers around an Objective C class. They take in their initializer, they get the object, which we obtain from somewhere else. And then we can call methods on them. For example, we have this P list description UTF-8 data function. Method, rather, we have this selector, which as you see is basically just a string. We can call a function called response to selector, which tells us if this selector is implemented on the object. It's just a safety measure to make sure... So we can, in through the initializer, we can pass anything. So we have to make sure that it actually implements this method. Otherwise, we get runtime crashes, which is another nice property, of course, of calling into C. You can get crashes. Then we call this Objective C message send, which gives us back a function object and that we can just regularly call by giving it the object. And via this, we get from the string the selector object, which is just another kind of string. And this allowed us to call Objective C from Ruby without having a C extension, which was our goal. And to recap, so C extensions have a real bad UX. As you saw, many projects struggle with it. We struggle with it even though we only support one platform. So Cocoa Pots only runs on OS X, so it was even more... It was even easier for us. It's much more difficult if you actually have a project that runs on multiple platforms. And Fiddle provides a way to use native code dynamically, which limits all the compilation hassle. And as you saw, it's not that difficult. I mean, if you have wanted to write C instead, it's not that much different. And we can even call Objective C if we want. Thanks. Why do you think it's used so little or why it is so unknown, the Fiddle? Oh, why is it so used a little? Sorry, I didn't get it acoustically. Well, the thing is, as you saw, if you don't... It creates some boilerplate. But really, I don't know. I guess it's used so little because people don't know about it so much. We sure didn't know about it before we used it. And yeah, that's part of the reason why I gave this talk, so people know about it. And I think the other problem is sometimes C extensions are used for performance reasons. So you implement something in C so it's faster. And with that, Fiddle can't help, right? The goal of the users of Fiddle is really if you need to call an existing library. Because if you just implement your stuff in Ruby, it's probably even more slower because as you saw, you have to do this type conversions even more than when you would just write a C extension and then you have just the type conversion once with using Fiddle, it can happen even more. So if you have a C extension for performance reasons, it's not a good idea to use Fiddle, then you still need to C extension. Another question, no more? Then one more round of applause.