Re: Ruby and E.V.E. Paradox

GD ha escrito:

>
> This is an interesting idea but may be overkill for what I'm trying
> to do.
>

Well, I'd suggest you read swig docs and see if you still think is
overkill for your project.  Since you mentioned it is a game engine, I
seriously doubt that it will be overkill.

>
>  >   VALUE result = rb_protect( wrap_callback, VALUE(&data), &error );
>
> You can do this!? Is this safe?

Yes.  Again, read ruby.h.  It checks for this to be true... or ruby
won't compile.

> Is there any authoritative source that
> says: "directly casting a pointer to a VALUE is perfectly fine and
> will continue to be supported".

Besides me, you mean?  I guess we have a trust issue, here :(

Well, that relies on a feature of the C/C++ language.  As long as you
are using C ruby and we are dealing with 32/64-bit machines, it will
hold true.  Again, read ruby.h and config.h.
Besides that, Matz has mentioned this is ok (search the list).  His
goal for VALUE was to have it be like void*, but clearer to users and
keeping type safety.  Unfortunately, C does not quite allow it to
behave like a void* in all contexts, so sometimes you do need to cast
it to void*.
This is more or less a limitation of C/C++.

If that's not enough for you, I'll try to see if I can convince the
Pope to say something along those lines, but it might be tricky :)

> If so, VALUE can be used (effectively) in the same way as a void*,
> so there is no need to convert everything into Ruby objects as
> I had thought.

Err... you weren't exposing each and every single little class in your
code, were you?  Ouch.
That's not the idea, of course.  The stuff you need to convert to Ruby
is only the stuff you need your users to use in Ruby, as it stands to
reason.

>
> I'll probably give it a shot for interest's sake. Looking closer at the
> Python docs that don't seem as strong as first impressions suggest,
> although there are some decent examples.
>

Well... what EXACTLY are you trying to achieve, Garret?   You started
the thread mentioning you WANTED to get away from Lua and use Ruby for
your game engine.
Personally, within the context of game engines, I must tell you, I
think that's not such a good idea, as Lua is multi-thread safe today
which is definitively something you do want in a game engine (and
LuaJIT is probably *THE* fatest VM I have *EVER* seen for a non-static
typed language).
As such, I warned you before-hand that neither Python nor Ruby are
thread safe.
You did mention you liked Ruby's syntax better than anything else and
you did not care about multi-threading, so I kept helping you with
ruby.
You mentioned you had difficulties embedding Ruby, and I gave you
pointers for you to read on.  You did not understand how to use a
couple of functions, and I pointed to you the right stuff you should be
using.
You posted some code that crashed on you, and I gave you similar
working code that works reliably, with compiling instructions to boot.
You questioned whether my code was valid, which means you probably have
not tried running it.
You have also not followed my advice of looking at SWIG and, instead,
now you want to look at Python (!?).  Are you pulling my chain?

If you DO want to use Python for wrapping a library, and you are
familiar with C++ template use, I suggest using boost::python and Py++.
 It is slightly more efficient than SWIG, albeit it can be hard to
debug if you are not familiar with templates.
If you don't like templates (like myself), I would ALSO recommend you
learn and use SWIG for embedding Python.
Is there any reason why you are avoiding SWIG and not even looking at
the documentation I pointed you to?  In case you did not find it, it's
here, btw:
http://www.swig.org/Doc1.3/Ruby.html#Ruby  (read: memory management
section)
http://www.swig.org/Doc1.3/Contents.html#Contents

You will learn quite a lot about embedding stuff from reading it.   My
guess is that the problems you are having with Ruby and perhaps Lua
might be because you are not too familiar with the subtleties that can
arise from exposing classes to scripting languages.  SWIG does a really
good job of explaining that (best thing I've seen yet) and has working
and relatively well tested code in about 20+ languages.

The good thing about SWIG is that you can actually use Lua (which you
mentioned you know well already) and expose one or two classes that way
first.  Then, you should be able to easily port that code to ruby, by
just changing just a couple of swig files (if any).
Also, if you end up dropping Ruby at some point in time, you should be
able to again port your code easily to whatever other language you
fancy.

> (*) - Technically I _did_ in a couple of hours, but it wasn't stable and
> crashed randomly, so I tried to figure out what was going wrong. No luck.

Well, if you've wrapped a class or two and they are crashing, your best
bet is posting the code to them to get help.  Otherwise, it is unlikely
anyone will be able to help you out much.
Also, it will be hard for anyone to write better docs, if nobody knows
what exactly are you having difficulties with.

> That was unwarranted.

True, it did read quite nasty once I read it myself.  What I meant was
more like: "Luckily for you, you are wrong".

>
> I would suggest that a good place for these little tips and tricks that keep coming up
> would be somewhere near the official documentation, so that the next
> person who comes along to play with embedded Ruby can start off
> slightly further ahead than I did.
>

Sure.  Feel free to write them up somewhere.  In case it was not clear,
any code or snippet of code I posted in this thread is public-domain.