[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.
>=20
> This will not fix your problem, nor will -KU fix your problem.  =
They'll only mask your problem.
>=20
> 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.
>=20
> See:
>=20
> =
https://github.com/rdoc/rdoc/commit/ca7651a8b9e6ef32dfa56f4ca618d9cff6ba8b=
74
>=20
> https://github.com/rdoc/rdoc/issues/63
>=20
> 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.
>=20
> Let's get concrete.
>=20
> 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.
>=20
> 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