[ragel-users] Re: rlgen-ruby / ruby 1.9 incompatibilities, possiblefixes, and offer to patch

[Adrian Thurston]

In the absence of one efficient method of extracting ordinals from both
strings and arrays I think we should use arrays. They cover the most
usage scenarios.

I think converting to array form should be done by the programmer if
necessary rather than converted automatically by "write init". Such a
conversion is only useful for people that are unaware of the issue and
is too much code for people that are.

I'll fix the "when" problem and update the tests to convert input to
array form.

-Adrian

Ana Nelson wrote:
> 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,
>>> Dan
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "ragel-users" group.
> To post to this group, send email to ragel-users at googlegroups.com
> To unsubscribe from this group, send email to ragel-users-unsubscribe at googlegroups.com
> For more options, visit this group at http://groups.google.com/group/ragel-users?hl=en
> -~----------~----~----~----~------~----~------~--~---
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://www.colm.net/pipermail/ragel-users/attachments/20080105/8a52c8af/attachment-0001.sig>