#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/>