On Sat, Apr 17, 2010 at 11:10 PM, Czarek <cezary.bagin...@gmail.com> wrote: > On Sat, Apr 10, 2010 at 09:15:54PM +0200, Mislav Marohnić wrote: >> > >> > - since no one seriously considers ruby 1.9 ready for production, >> > nobody is going to spend time merging patches for 1.9 encoding >> > support, so sending patches is a waste of time >> >> >> All the "points" you listed basically just repeat what you stated here in >> your last observation. >> >> Sending (quality) patches is never a waste of time. Patience is a virtue. > > I completely agree with both statements. > > And I also think that expecting people to prepare wonderful patches for > rails 2.3.5 (released almost 5 months ago AFAIR) without some > encouragement or directions would be a little too much. The reasons: > > 1. Debugging which source file or line of code (part of rails or > not) emits a ASCII-8BIT string is very time consuming (since the > point of failure is very far from the cause). Without this, it is > difficult to determine if it already has a LH ticket or not. > > 2. There are already many 1.9 tickets present in 2.3.5 with no > applicable 'solutions'- to list just some I have been bitten by > already, or stumbled upon when searching for existing > patches/duplicates: > > > https://rails.lighthouseapp.com/projects/8994/tickets/1988-make-utf8-partial-rendering-from-within-a-content_for-work-in-ruby19 > > https://rails.lighthouseapp.com/projects/8994/tickets/2188-i18n-fails-with-multibyte-strings-in-ruby-19-similar-to-2038 > > https://rails.lighthouseapp.com/projects/8994/tickets/2476-ascii-8bit-encoding-of-query-results-in-rails-232-and-ruby-191 > > https://rails.lighthouseapp.com/projects/8994/tickets/3331-patch-block-invalid-chars-to-come-in-rails-app > > https://rails.lighthouseapp.com/projects/8994/tickets/3392-rackinput-requires-ascii-8bit-encoded-stringio > https://rails.lighthouseapp.com/projects/8994/tickets/3941 > > https://rails.lighthouseapp.com/projects/8994/tickets/4336-ruby19-submitted-string-form-parameters-with-non-ascii-characters-cause-encoding-errors > > 3. 1.8.7 is recommended for Rails. That is ok. But although the > 2.3.5 release notes mention 1.9, they don't state anything about > potential UTF-8 problems with Ruby 1.9 (except for people's > comments), nor do they suggest what to do with such problems (e.g. > 'wait until X', 'we are waiting for patches', 'send test cases', > 'use 1.8.7', 'try -KU option', 'you are on your own unless you only > use en_us'). And there is also no mention of how to report issues > effectively or which commit to use to avoid reporting something > already on LH. > > 4. When using a combination of software (cucumber, webrat, rspec) it > may be *very* time consuming to even determine which gem is the > cause of the problem and which ones just send the problem further > down the call stack. > > 5. It is unreasonable to expect people to not try Rails with Ruby > 1.9(even if by accident) and the worst thing is that is *seems* to > work, until UTF8 characters are used somewhere (template, db, etc). > No warning is given if Ruby 1.9 is used. So the natural thing to > assume when something is that one's setup is wrong. Which is true - > it's using Ruby 1.9 in the first place. > > 6. Although I don't want absolute morons to use Rails, having no > 'fail-safe' or warning will just scare good developers from Rails > just wanting to try out the framework, even if the issues are not > Rails bugs. There is no 'recommended' set of patches to apply and > test before reporting bugs with Ruby 1.9. > > 7. Most of the solutions you find for encoding problems with ROR and > Ruby 1.9 do not suggest the following: stick with 1.8, because > 1.9 with Rails is a can of worms in this regard. > > I was wondering if this isn't really something more suitable for > ruby-core: it would be nice to know where the string causing the error > was created and why a given encoding was selected. This could at least > provide bug reports with better details regarding the root cause. > > I am really not the brightest developer out there and I apologize for > not being able to propose something more useful than just stating > obvious problems. > > My question is: how can I help in a meaningful way that isn't a > complete waste of my time and that isn't a duplication of other > people's efforts? > > Since patches are never a waste of time, I propose the following? > > My first patch would be a warning about using Ruby 1.9 with Rails. To > save people grief when they install Ruby 1.9 as their default. > > My second patch is to rescue an exception in concat (output_safety), > work around it with force_encoding if it is sane and issue a warning. > Just to try help solve other issues that just *seem* related. > > Then I would put my efforts into discussing the issue on ruby-core > if it would be possible to add location info (and reason for selected > encoding: env, locale, magic, param, etc) for string creation on a > test version of Rails - this may save many tens of thousands of man > hours that would be wasted on debugging and help in the adoption of > not only Ruby 1.9, but in good practices regarding supporting non-US > languages in other gems. > > Then I would build a special version of Ruby that warns whenever a > string is not created as UTF-8 and isn't explicitly created as ASCII, > fork Rails and start adding test cases. > > Would this really be the best approach?
Czarek, thanks for raising this. Working with 1.9 string encodings is too unforgiving. Most of the patches so far amount to forcing UTF-8 or 8-bit ASCII everywhere. Not acceptable or even desirable. I love the idea of trying to force the encoding on concat and giving a warning. It'd be wonderful is Ruby itself offered an encoding sniffer so we could attempt to transcode as well. Then your app works plus you get the information you need to encourage the library author to add 1.9 support. This would make for an excellent Ruby Summer of Code project. jeremy -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
