Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Perl: porters

merging in the origin/legacy-pragma git branch

 

 

Perl porters RSS feed   Index | Next | Previous | View Threaded


public at khwilliamson

Oct 29, 2009, 9:47 PM

Post #1 of 7 (386 views)
Permalink
merging in the origin/legacy-pragma git branch

I would like to start submitting patches to fix the "Unicode bug"
wherein the semantics differs depending on the internal utf8-or-not
representation of a scalar.

I submitted the first steps for that quite a while back, and Rafael made
a separate branch for that. I'm not sure how to proceed. I need that
to go forward. Do I do something, or what? It is a tiny patch.

At the time Rafael expressed some concern that I was using up a bit from
PL_hints, and suggested using the newer hash instead. I would prefer to
keep using PL_hints for several reasons:
1) The closely related bits for locale and "use bytes" are located here,
and it seems to make sense to keep them all in the same structure. And
there are several bits available even after this one is used up.
2) It's easier for me to just copy the existing paradigm for these than
to figure out how to do the other
3) I'm leery of the other scheme given all the problems there are with
charnames in regcomp.c. I'm pretty ignorant on this, and ignorance
leads to paranoia, not bliss. But I'm not sure we've gotten to the
bottom of the cause, and I'd just as soon not get involved with
depending on something that may be flaky. Now perhaps this is used with
full success elsewhere, and my concerns are just paranoia. But then I
go back to reasons 1 and 2.


zefram at fysh

Oct 30, 2009, 4:35 AM

Post #2 of 7 (381 views)
Permalink
Re: merging in the origin/legacy-pragma git branch [In reply to]

karl williamson wrote:
>At the time Rafael expressed some concern that I was using up a bit from
>PL_hints,

What do you want the bit for? Bug fixes don't need to be optional.

-zefram


public at khwilliamson

Oct 30, 2009, 8:21 AM

Post #3 of 7 (387 views)
Permalink
Re: merging in the origin/legacy-pragma git branch [In reply to]

Zefram wrote:
> karl williamson wrote:
>> At the time Rafael expressed some concern that I was using up a bit from
>> PL_hints,
>
> What do you want the bit for? Bug fixes don't need to be optional.
>
> -zefram
>
Recently someone pointed out on this list that it took a long time for
people to agree that it is a bug; and I suppose some still don't. I was
using the term "Unicode bug" because that's what it has been called
before on this list, whether one thinks it is one or not. But it may
very well be that programs have come to rely on the existing behavior,
so the design agreed upon last year was that there would be a 'use
legacy' pragma for people to select older semantics, of which this would
be the first, and perhaps only example; at the time there was hope of
getting it into 5.10 Update 1 :-), with the default turned off but it
didn't happen, and so now I would like to get it into 5.12 with the
default turned on.


zefram at fysh

Oct 30, 2009, 8:27 AM

Post #4 of 7 (368 views)
Permalink
Re: merging in the origin/legacy-pragma git branch [In reply to]

karl williamson wrote:
>so the design agreed upon last year was that there would be a 'use
>legacy' pragma for people to select older semantics,

If you want such a pragma to apply broken semantics for regexps, it
should not be part of the core. It should be a CPAN module, mediated
through an entry in %^H.

-zefram


demerphq at gmail

Oct 30, 2009, 9:06 AM

Post #5 of 7 (377 views)
Permalink
Re: merging in the origin/legacy-pragma git branch [In reply to]

2009/10/30 Zefram <zefram [at] fysh>:
> karl williamson wrote:
>>so the design agreed upon last year was that there would be a 'use
>>legacy' pragma for people to select older semantics,
>
> If you want such a pragma to apply broken semantics for regexps, it
> should not be part of the core.  It should be a CPAN module, mediated
> through an entry in %^H.

I am strongly inclined to think that you are confused as to what Karl
wants to do.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"


public at khwilliamson

Oct 30, 2009, 10:42 AM

Post #6 of 7 (380 views)
Permalink
Re: merging in the origin/legacy-pragma git branch [In reply to]

demerphq wrote:
> 2009/10/30 Zefram <zefram [at] fysh>:
>> karl williamson wrote:
>>> so the design agreed upon last year was that there would be a 'use
>>> legacy' pragma for people to select older semantics,
>> If you want such a pragma to apply broken semantics for regexps, it
>> should not be part of the core. It should be a CPAN module, mediated
>> through an entry in %^H.
>
> I am strongly inclined to think that you are confused as to what Karl
> wants to do.
>
> Yves
>

I'm working on fixing
http://rt.perl.org/rt3/Public/Bug/Display.html?id=58182

I believe there are other bug reports about the same thing. Yes,
regexps are involved, but so are uc() and its kin. The original patch
commit message is here:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2009-01/msg00695.html


rgarciasuarez at gmail

Nov 6, 2009, 3:21 PM

Post #7 of 7 (342 views)
Permalink
Re: merging in the origin/legacy-pragma git branch [In reply to]

2009/10/30 karl williamson <public [at] khwilliamson>:
> I would like to start submitting patches to fix the "Unicode bug" wherein
> the semantics differs depending on the internal utf8-or-not representation
> of a scalar.
>
> I submitted the first steps for that quite a while back, and Rafael made a
> separate branch for that.  I'm not sure how to proceed.  I need that to go
> forward.  Do I do something, or what?  It is a tiny patch.
>
> At the time Rafael expressed some concern that I was using up a bit from
> PL_hints, and suggested using the newer hash instead.  I would prefer to
> keep using PL_hints for several reasons:
> 1) The closely related bits for locale and "use bytes" are located here, and
> it seems to make sense to keep them all in the same structure.  And there
> are several bits available even after this one is used up.
> 2) It's easier for me to just copy the existing paradigm for these than to
> figure out how to do the other
> 3) I'm leery of the other scheme given all the problems there are with
> charnames in regcomp.c.  I'm pretty ignorant on this, and ignorance leads to
> paranoia, not bliss.  But I'm not sure we've gotten to the bottom of the
> cause, and I'd just as soon not get involved with depending on something
> that may be flaky.  Now perhaps this is used with  full success elsewhere,
> and my concerns are just paranoia.  But then I go back to reasons 1 and 2.

I have now merged this branch in blead. Further patches welcome :)

Perl porters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.