Re: Ruby game server woes

	Subject: Re: Ruby game server woes
	Date: Mon 24 Dec 12 11:01:11PM +0900

Quoting Na Na ([e-mail]):

> 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_<whatever your library is called>(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 <whatever your library is called>

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 - [e-mail]             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)