From: gga Date: 2007-01-17T20:20:07+09:00 Subject: 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.