rlgen-ruby / ruby 1.9 incompatibilities, possiblefixes, and offer to patch

Ana Nelson nelson.... at gmail.com
Thu Jan 3 21:01:40 UTC 2008


I have the Hello World example running in Ruby 1.9. I replaced ":"
with "then" in the generated code as per Dan's suggestion, and I added
the following line in the example's run_machine method which converts
"data" to an array of integers using String#unpack.

data = data.unpack("c*") if data.is_a?(String)

Nothing else needs to change and this is also Ruby 1.8 compatible.
(I'll update my example with this - thanks, Dan)

Code like this could be generated by write init. But that's only if
Ragel wants to accommodate lazy Ruby programmers who want to pass in
strings when the documentation calls for arrays, now that in Ruby 1.9
strings don't happen to behave like arrays of integers by default. ;-)

Another approach would be to .unpack("c") (.ord is Ruby 1.9 only) each
individual character when it is processed but that means testing each
individual item to see whether it's a string or an int, or defining
an .unpack method on Fixnum if we want to be clever. This seems more
invasive in terms of changing rlgen-ruby, but perhaps it would be
better from a memory management point of view. I'm guessing from what
little I know about it, though, that people who are concerned about
memory management won't be passing around giant strings, so probably
the simpler 1-line option is fine. (I'd be happy to be corrected/
educated on that.)

I'm biased towards thinking that Ragel shouldn't try to do too much to
accommodate this change in Ruby's treatment of strings, unless it's
because of a conscious decision to support string inputs.

Regards,
Ana


On Jan 3, 4:50 am, "Bruce Williams" <br... at codefluency.com> wrote:
> Adrian,
>
> In 1.9, use String#ord:
>
> ------------------------------------------------------------- String#ord
>      str.ord   => integer
> ------------------------------------------------------------------------
>      Return the +Integer+ ordinal of a one-character string.
>
>         "a".ord         #=> 97
>
> So, "foo"[1].ord in 1.9 should be equivalent to "foo"[1] in 1.8.
>
> Cheers,
> Bruce
>
> ---
> Bruce Williamshttp://codefluency.com
>
> On 1/2/08, Adrian Thurston <thurs... at cs.queensu.ca> wrote:
>
> > I'll look this up tomorrow. Right now I'm in a train station. In the meantime are there any ruby experts out there that know the proper way to index arrays and strings and pull out numbers?
>
> > Adrian
> > -----Original Message-----
> > From: dcgrigsby <dan-goo... at unpossible.com>
>
> > Date: Wed, 2 Jan 2008 11:56:55
> > To:ragel-users <ragel-users at googlegroups.com>
> > Subject: [ragel-users] rlgen-ruby / ruby 1.9 incompatibilities, possible
> >  fixes, and offer to  patch
>
> > Hello,
>
> > The code generated by rlgen-ruby is incompatible with Ruby 1.9.
>
> > Using the simple DevChix Hello World example (http://www.devchix.com/
> > 2007/12/13/a-hello-world-for-ruby-on-ragel/)., the generated "write
> > exec" ruby contains a handful of errors.
>
> > 1) the "when" clause in the generated case statements uses a
> > deprecated form.  It is in the form "when <value>:" and should be
> > "when <value> then" instead.
>
> > 2) under 1.9, a string element reference (i.e., [] operator) returns a
> > string, not a fixnum as under 1.8.  So the comparisons like this...
>
> >   if data[p] < _hello_trans_keys[_mid]
>
> > ...result in "`<': comparison of String with 104 failed
> > (ArgumentError)" under 1.9.
>
> > I'd be happy to work up a patch, hopefully one that works under both
> > 1.8 and 1.9, but I need some guidance.
>
> > The former should be easy.  I found all the instances that use the
> > colon in when and changed them successfully.
>
> > The later is where I'm uncertain.  Appending ".to_s" to both sides of
> > the comparison (needs to be both sides to retain 1.8 compatibility)
> > everywhere seems wrong.  At this point I'm doing little more than
> > grepping the source; I don't really comprehend what's going on, so a
> > point in the right direction would be welcome.
>
> > Thanks,
>



More information about the ragel-users mailing list