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?
Thanks in advance.
--
Cezary Baginski
signature.asc
Description: Digital signature
