[MacRuby-devel] [MacRuby] #159: "%d" with large integer argument gives conversion error

MacRuby ruby-noreply at macosforge.org
Tue Jan 5 17:45:02 PST 2010

#159: "%d" with large integer argument gives conversion error
 Reporter:  jamis@…              |       Owner:  lsansonetti@…        
     Type:  defect               |      Status:  new                  
 Priority:  major                |   Milestone:                       
Component:  MacRuby              |    Keywords:                       

Comment(by lsansonetti@…):

 Looking at the changes, I have the following comments:

 * The "strict" code paths should be enabled by default, because we must be
 compatible with the upstream implementation of Ruby. At the very least,
 "nan".to_f should (unfortunately) return 0.0, like Ruby 1.9. I believe the
 %a and %A string formatters can be callable by default, since these are
 additions and do not break existing behavior.

 * In RoxorCompiler::compile_conversion_to_ruby(), the optimization that
 was inlining the code to convert a C float into a Ruby float disappeared.
 It is now compiling a call to rb_vm_float_to_rval() every time. This isn't
 good performance-wise, we must bring the inline optimization back.

 * On some simple benchmarks (such as a "i=0.0; while i<100000000.0; i+=1;
 end" loop), the new code is about 3 times slower. It's because the
 compiler generate C calls when creating floats, according to Shark, such
 as rb_vm_float_value(), rb_float_new_retained(), and
 rb_vm_effective_immediate_bits() (which should be inlined). Also, probably
 because of rb_float_new_retained(), boxed floats are apparently never
 released, which leads to memory leaks (a simple loop demonstrated that).

 I am attaching a patch of your changes against MacRuby trunk (as of r3193)
 so that others can try them. But at this point I'm not confident to merge
 all of it.

Ticket URL: <http://www.macruby.org/trac/ticket/159#comment:12>
MacRuby <http://macruby.org/>

More information about the MacRuby-devel mailing list