Front page | perl.perl5.porters |
Postings from July 2019
On Fri, 07 Jun 2019 02:26:42 -0700, smylers@stripey.com wrote:
> Dave Mitchell writes:
>
> > the bytes in patch 0002 just before the word "make" are
> >
> > ef bf bd ef bf bd ef bf bd
> >
> > which when decoded as utf8, form these characters
> >
> > "\x{fffd}\x{fffd}\x{fffd}"
> >
> > So I think the patches probably need resubmitting.
>
> Ascii-only patches attached.
>
> (That was an opening double-quote mark when I typed it, U+201C. It
> should've had the UTF-8 bytes E2 80 9C.)
>
> Dagfinn Ilmari Mannsåker writes:
>
> > This is 2019, everything should be Unicode-capable by now,
>
> I agree. Especially since some committers have non-Ascii characters in
> their names!
>
> And as you show, there are plenty of commit messages already
> successfully using non-Ascii characters. However, what turned up on the
> mailing list was clearly unusable.
>
> The attachments in my ‘sent’ folder are unmangled if I open them with
> Vim, but possibly insufficiently labelled as to how to interpret them; I
> couldn't see anywhere in Zoho's webmail client to specify attachment
> headers. It may have been that if I'd sent them some other way they
> would have made it through fine.
>
> Or maybe only folk with commit bits are free to use any characters in
> their messages, and those of us submitting via RT need to use a
> restricted subset. I shall try to remember to watch my typing in future.
The (old version of) RT we're using seems to corrupt UTF-8 in attached patches received by email, including in the copy of the email sent to the list.
This:
+L<overload> has been upgraded from version 1.31 to 1.32. It now provides
+C<OverloadedStringify> for determining whether an object has overloaded
+stringification by any means.
+
seems inaccurate - isn't the idea that it's always been provided (for useful versions of always) and we're now documenting and testing it.
Tony
---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=134180