From: "Carlo E. Prelz" Date: 2012-12-25T01:50:36+09:00 Subject: Re: Ruby game server woes Subject: Re: Ruby game server woes Date: Mon 24 Dec 12 11:01:11PM +0900 Quoting Na Na (lists@ruby-forum.com): > Is this why you write in ruby? Speed of development, and then c > extensions when you need quicker computations? Well, this is what I *obtain* from writing in Ruby+C. The why is a bit more difficult to explain: there is a strange feeling of satisfaction/accomplishment that I get when I see my Ruby code running. It is a bit the opposite of what I experienced with Java. Java somehow cut the cake, but there always was that aftertaste of unrealized promise, of vague awkwardness. C is one with Unix: they were invented together and still nothing better has been found (both Apple and Google had to bow their heads...). IMHO it is only with Ruby that the promises of OO have been delivered. And the delivery comes together with the acceptance that more ease in development and maintenance is paid with a tad less performance. The highway towards better performance is open and available when you need it - once you master the way. (oops - I may have waxed a bit too lyrical ;-) > Are there issues with c extensions in terms of multiple platforms? Or > is it a case that ruby c extensions typically will compile well for mac, > linux, and windows without platform-specific code? Ahha... I use only Linux. But: if you can compile MRI (including the C extensions that are found under the ext subdirectory), your extension too will most probably compile. After all, when you write C extensions to Ruby you write similar code as the one that makes up the interpreter - which is itself written in ANSI C. You interface with the running interpreter in the same way. The Ruby-related stuff is all neatly included in .h files, which happen to be themselves included in MRI. If your Ruby extension is just there for performance reasons (and thus makes no use of exotic libraries), there is no reason why it won't compile. wherever Ruby itself compiles. And if the exotic libraries are already ported to the various architectures, the dirty work is done for you already. Then, with macosx this is certainly more direct (after all, it is still UNIX, and you use GCC there as default). With windows, to my knowledge there are a range of options to give to that unlucky platform an appearance of shape ;-), so there have to be ways. But there, I cannot be of help. > Finally, if you know - is it possible to write a c extension that itself > uses multiple threads to speed up computations if it's a task that can > be done in parallel? Of course! I do it regularly. For example, my audio playback toys always have a background thread that makes sure samples are fed to the DSP in time. (the DSP stuff is of course highly unportable and quirky, thanks to the time-revered ALSA library, but this is another topic ;-) Once you are in C land, you can do anything you do in any other C program or library. And you can bring in any other library, too. There is a function that the Ruby interpreter calls when your library file is loaded, called void Init_(void) (which is the only function that your library *needs* to export), where you create the class objects and their accessible methods. Then you need to write the code for those methods. Among them, you generally have the initialization call (the equivalent of Class::new), which is called every time you create a new instance of your class. If you want a thread to be associated to each instantiated object, you just call pthread_create from within the body of that function. There arev some gotchas you have to be aware of (basically, if you want the thread function to make use of ruby objects, you must make sure the garbage collector does not destroy them in the meantime - but this is advanced stuff). It is all about trying a bit. Create your directory, put into it your extconf.rb (which is just a Ruby script making use of the mkmf package, and may be refreshingly simple) plus one or more .c and/or .h files. Run ruby extconf.rb which will create the makefile, then run make whick will create your shared library. make install will move the library wherever your Ruby installation is supposed to find it. At that point your Ruby scripts can do require and you will be able to instantiate your C-based objects. > Thanks for taking the time to reply. these winter days are sooo dark... ;-) Carlo -- * Se la Strada e la sua Virtu' non fossero state messe da parte, * K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu)