[ruby-core:40289] Re: Counseling

On Oct 21, 2011, at 8:45 PM, Eric Hodel wrote:

> On Oct 21, 2011, at 9:43 AM, Perry Smith wrote:
> On Oct 21, 2011, at 5:52 PM, Perry Smith wrote:
>> Just as good of an alternative would be to change my default to UTF-8 instead of US-ASCII.
> 
> This will not fix your problem, nor will -KU fix your problem.  They'll only mask your problem.
> 
> The correct solution is to add the encoding magic comment to files that matches the expected encoding of the strings they create.  Blindly forcing all strings to UTF-8 will break libraries that depend on their strings being in US-ASCII encoding.
> 
> See:
> 
> https://github.com/rdoc/rdoc/commit/ca7651a8b9e6ef32dfa56f4ca618d9cff6ba8b74
> 
> https://github.com/rdoc/rdoc/issues/63
> 
> You will need to send patches to the library maintainers to mark their required encodings correctly, or file tickets.

I'm willing to admit that you have thought about this more than I have -- although the reverse could just as easily be true.

What I gather from your links is that we might have some fundamental disagreements.  If setting my environment to use UTF-8 breaks a library, the library is broken.  (That is my position).  Your position appears to be that "I broke the library".

I added comments to all my files.  But most gems do not include them.  They are just now catching up (perhaps).  Setting -KU helps much much more than adding comments to my files.

>> My first attempt to solve this was to put a UTF-8 coding into all my ruby files.  This appeared to help but upon reflection, I don't think it really did.  Adding the -KU in scripts like thin's startup script helps more.  In fact, I think it solves 99.99% of my problems.  But when I update thin (for example) I forget to add the -KU to the script and hit errors until I add the -KU back.
> 
> Let's get concrete.
> 
> Show us an error you get when running thin without any modification and I can help you and the maintainer of thin (or whatever other library) find the appropriate changes to make for it to work correctly.
> 
> Through our combined efforts at a concrete task we may even be able to make it easier for authors to avoid such a pitfall.

I will take you up on this offer.  I'm wondering if we should move this off of the list.

Right now, I do not have any useful stacks to show you.  Rails has a "clean backtrace" concept which strips out what we need.  Let me turn that off.  It may be that I won't hit this problem again for several months.  When I do, what do you suggest?  (How should I contact you?)

Thank you,
pedz