-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 10 September 2010, Jeff Johnson <n3...@mac.com> wrote: > todo++. Feel free to make the call about ruby 1.8.x <-> 1.9.x > and minimum necessary version etc as you progress. I haven't > a clue which ruby version is "best" to target.
I'll make 1.9 mandatory. 1.8 has only been around to make the Rails folks happy, and with rails-3.0 out of the door, there's no need for 1.8 compatiblity. And do not worry about any distro yet. It's still not a feature marked as stable, so nobody should expect backwards compatibility IMHO. > Mind if I write up a blueprint for "rpm-embed-ruby" at > http://launchpad.net/rpm to describe some of the details? Its your work, > so I ask first. Yeah, sure, go on. And, to be honest, it's mostly your work right now. I spent the last days mainly with (re-) writing some docs, finding out whether there's a way to make more than one interpreter instance possible, and, above all, finding a way around Ruby's #include quirks. Btw, RPM5 is a nice place to get to know more of the really cool and nifty C stuff. ;-) > You are more than welcome to change/delete/ignore/whatever > the blueprint. I'm going to register with Launchpad then... Ok, waiting for the mail to come in. > For starters, there's global <-> instance that needs worrying about (I'd > suggest targeting/using global initially: multiple interpreters have > all sorts of weird surprises). Since Ruby cannot support multiple interpreters right now, I'm about to change the default to "a new interpreter init for each expanding." I don't like the idea of carrying one interpreter around through the whole runtime. That might bring all sorts of surprises people don't expect. It's a policy decision, basically, that needs to be documented. Whatta you think? > There's also deciding on some mechanism for what modules get > automagically loaded (and from where) as a side effect of calling > rpmrubyNew(). Modules == Ruby Modules? (The term "module" exists for Ruby, too; I'm asking to make sure.) > I likely did the minimimum necessary change to capture stdout in a buffer > to return as the %{ruby OPTS ARGS: BODY} > expansion value, using whatever seemed like a reasonable "Rubyesque" way > to redirect a stream. If I looked, I'd remember why I did whatever I did. Yes, you already did a lot of good stuff. Using StringIO is a neat way to capture stuff for expansion. The other way would be using tempfiles, but I don't think that people will create more output than what's fitting into their RAM... just now. Switching to tempfiles is dirt easy from the Ruby perspective, and doesn't make any difference. > And there's some toy *.spec test cases that should be written to exercise > both macro/scriptlet syntaxes attached to embedded ruby. That's something I wanted to talk about anyways: Do you have objections if I pull in a unit testing framework? (Yeah, dire shot, I know.) > Then there's the whole messiness of exception and signal handling in > embedded ruby as well as threading that need to start to be worked > through. There's some utterly simple things that could/should be done to > display diagnostics while trying to devise a real world framework not > only for ruby, but all the embeddings. With Ruby, it's quite simple, because the C API has mechanisms of taking care of Ruby exceptions and other failures triggered by the Ruby code. I don't know for the rest, though. Gimme some function pointer for that, and I'll wire it up. :-) Gotta fix the xmalloc & co warnings first, without breaking things, though. Uhm, any suggestions? Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkyKjV4ACgkQhS0drJ3goJKw4gCePLApcpuu6P1pEoSnhNQBIDEd 2kAAn1T+6D3Kym9TYAWhk8tC9aNGD5VY =AqeM -----END PGP SIGNATURE----- ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
