Skip Menu |
 

This queue is for tickets about the Net-DNS CPAN distribution.

Report information
The Basics
Id: 121680
Status: resolved
Priority: 0/
Queue: Net-DNS

People
Owner: Nobody in particular
Requestors: RURBAN [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: [PATCH] Improve map hash handling
Download (untitled) / with headers
text/plain 527b
Starting with cperl 5.27 I disabled unpaired map processing to hashes under use strict. See https://github.com/perl11/cperl/issues/281 Therefore I rewrote the relevant dirty parts in the RR modules, and added a generic mapper Net::DNS::RR::_map_name() to unify the keys. It's also a bit faster. In Net::DNS::RR::TSIG I added code to protect from calling empty digest functions. See https://github.com/rurban/distroprefs/blob/master/sources/authors/id/R/RU/RURBAN/patches/Net-DNS-1.10-527c.patch for the patch -- Reini Urban
From: rwfranks [...] acm.org
Download (untitled) / with headers
text/plain 1.5k
On Sun May 14 13:10:40 2017, RURBAN wrote: Show quoted text
> Starting with cperl 5.27 I disabled unpaired map processing to hashes > under use strict. > See https://github.com/perl11/cperl/issues/281 > > Therefore I rewrote the relevant dirty parts in the RR modules, and > added a generic mapper Net::DNS::RR::_map_name() to unify the keys. > It's also a bit faster.
If 'use strict;' means anything at all, it means strict adherence to the language rules as laid down in the scriptures. map BLOCK LIST map EXPR,LIST Evaluates the BLOCK or EXPR for each element of LIST (locally setting $_ to each element) and returns the list value composed of the results of each such evaluation. In scalar context, returns the total number of elements so generated. Evaluates BLOCK or EXPR in list context, so each element of LIST may produce zero, one, or more elements in the returned value. and Map always returns a list, which can be assigned to a hash such that the elements become key/value pairs. See perldata for more details. my %hash = map { get_a_key_for($_) => $_ } @array; Sure, these code fragments can be cleaned up, and will be, but using 'map' in this way is perfectly legitimate. Show quoted text
> In Net::DNS::RR::TSIG I added code to protect from calling empty > digest functions.
If there is an entry for $key in the key table, an undefined digest function is logically impossible. If there is not, then this bit of code is unreachable.
Subject: Re: [rt.cpan.org #121680] [PATCH] Improve map hash handling
Date: Wed, 17 May 2017 16:59:17 +0200
To: bug-Net-DNS [...] rt.cpan.org
From: Reini Urban <rurban [...] cpan.org>
Download (untitled) / with headers
text/plain 2.1k
Show quoted text
> On May 17, 2017, at 2:42 PM, Dick Franks via RT <bug-Net-DNS@rt.cpan.org> wrote: > > <URL: https://rt.cpan.org/Ticket/Display.html?id=121680 > > > On Sun May 14 13:10:40 2017, RURBAN wrote:
>> Starting with cperl 5.27 I disabled unpaired map processing to hashes >> under use strict. >> See https://github.com/perl11/cperl/issues/281 >> >> Therefore I rewrote the relevant dirty parts in the RR modules, and >> added a generic mapper Net::DNS::RR::_map_name() to unify the keys. >> It's also a bit faster.
> > If 'use strict;' means anything at all, it means strict adherence to the language rules as laid down in the scriptures. > > map BLOCK LIST > map EXPR,LIST > Evaluates the BLOCK or EXPR for each element of LIST (locally > setting $_ to each element) and returns the list value composed of > the results of each such evaluation. In scalar context, returns > the total number of elements so generated. Evaluates BLOCK or EXPR > in list context, so each element of LIST may produce zero, one, or > more elements in the returned value. > > and > > Map always returns a list, which can be assigned to a hash such > that the elements become key/value pairs. See perldata for more > details. > > my %hash = map { get_a_key_for($_) => $_ } @array; > > > Sure, these code fragments can be cleaned up, and will be, but using 'map' in this way is perfectly legitimate.
Legitimate in perl5, but not in cperl since 5.27 with use strict. See also http://perl11.org/blog/strict-hashpairs.html map only acts on lists and arrays. hashes only act on list or array pairs. mapping a map list to a hash only makes sense with pairs. multiple pairs or odd lists are too dangerous, hence my new strict mode forbids it. you can decide to close out cperl from your users or add my patches. Show quoted text
>> In Net::DNS::RR::TSIG I added code to protect from calling empty >> digest functions.
> > If there is an entry for $key in the key table, an undefined digest function is logically impossible. > > If there is not, then this bit of code is unreachable.
I fall into this error, so I had to add it.
From: rwfranks [...] acm.org
Download (untitled) / with headers
text/plain 1.8k
On Wed May 17 10:59:39 2017, RURBAN wrote: Show quoted text
> using 'map' in this way is perfectly legitimate. > > Legitimate in perl5, but not in cperl since 5.27 with use strict. > See also http://perl11.org/blog/strict-hashpairs.html > > map only acts on lists and arrays. > hashes only act on list or array pairs. > mapping a map list to a hash only makes sense with pairs. > multiple pairs or odd lists are too dangerous, hence my new strict > mode forbids it.
But there's more than one way to do it. I fully agree with you about the danger. Following Perl6 and making odd hash assignments fatal would make almost everyone happy. Perl6 is where we are all headed eventually. If that is not strict, I do not know what is. However, the stricture that the fully assembled list have an even length in no way implies that each sublist map evaluation must contribute an even number of elements to the complete list. Show quoted text
> you can decide to close out cperl from your users or add my patches.
It is you pulling the rug from under the users by making cperl not understand Perl5 any more. I see no reason to get involved. The code fragment that offends you produces mappings with one or three list elements in (strictly) equal numbers, which guarantees that the complete list has an even number of elements. My job is to make sure that happens, the compiler's job to complain if I foul up, otherwise to get on with what I (in polite Perl) asked it to do. Is that too much to ask? Show quoted text
> >> In Net::DNS::RR::TSIG I added code to protect from calling empty > >> digest functions.
> > > > If there is an entry for $key in the key table, an undefined digest > > function is logically impossible. > > > > If there is not, then this bit of code is unreachable.
> > I fall into this error, so I had to add it.
If you know how to break it, I would be interested to see a concise example.
Subject: Re: [rt.cpan.org #121680] [PATCH] Improve map hash handling
Date: Thu, 18 May 2017 07:28:28 +0200
To: bug-Net-DNS [...] rt.cpan.org
From: Reini Urban <rurban [...] cpan.org>
Download (untitled) / with headers
text/plain 2.4k
Show quoted text
> On May 17, 2017, at 8:09 PM, Dick Franks via RT <bug-Net-DNS@rt.cpan.org> wrote: > > <URL: https://rt.cpan.org/Ticket/Display.html?id=121680 > > > On Wed May 17 10:59:39 2017, RURBAN wrote:
>> using 'map' in this way is perfectly legitimate. >> >> Legitimate in perl5, but not in cperl since 5.27 with use strict. >> See also http://perl11.org/blog/strict-hashpairs.html >> >> map only acts on lists and arrays. >> hashes only act on list or array pairs. >> mapping a map list to a hash only makes sense with pairs. >> multiple pairs or odd lists are too dangerous, hence my new strict >> mode forbids it.
> > But there's more than one way to do it. > > I fully agree with you about the danger. Following Perl6 and making odd hash assignments fatal would make almost everyone happy. Perl6 is where we are all headed eventually. If that is not strict, I do not know what is. > > However, the stricture that the fully assembled list have an even length in no way implies that each sublist map evaluation must contribute an even number of elements to the complete list. >
Well, that’s where we disagree :) Show quoted text
>> you can decide to close out cperl from your users or add my patches.
> > It is you pulling the rug from under the users by making cperl not understand Perl5 any more. I see no reason to get involved.
Well, from CPAN there are only 6 modules involved. That’s easy to maintain patches for. But in the long run people should use proper practices, i.e. produce a pair in map for hashes. Show quoted text
> The code fragment that offends you produces mappings with one or three list elements in (strictly) equal numbers, which guarantees that the complete list has an even number of elements. My job is to make sure that happens, the compiler's job to complain if I foul up, otherwise to get on with what I (in polite Perl) asked it to do. Is that too much to ask?
Well, I decided to allow only a pair, not multiple in strict mode. In non-strict mode it is still valid code. Show quoted text
>
>>>> In Net::DNS::RR::TSIG I added code to protect from calling empty >>>> digest functions.
>>> >>> If there is an entry for $key in the key table, an undefined digest >>> function is logically impossible. >>> >>> If there is not, then this bit of code is unreachable.
>> >> I fall into this error, so I had to add it.
> > If you know how to break it, I would be interested to see a concise example.
Well, I moved on some days ago, but when I find it again I will tell you. It probably had to do with rejected strict ‘hashpairs’ map.
From: rwfranks [...] acm.org
Download (untitled) / with headers
text/plain 864b
On Thu May 18 01:28:47 2017, RURBAN wrote: Show quoted text
> > The code fragment that offends you produces mappings with one or > > three list elements in (strictly) equal numbers, which guarantees > > that the complete list has an even number of elements. My job is to > > make sure that happens, the compiler's job to complain if I foul up, > > otherwise to get on with what I (in polite Perl) asked it to do. Is > > that too much to ask?
> > Well, I decided to allow only a pair, not multiple in strict mode. In > non-strict mode it is still valid code.
So you unilaterally decide to change the language, and suddenly its all my fault for using a well defined Perl5 feature. Splitting the construct into two lines does not alter what is taking place, does not change the risk profile, but merely prevents your over-constrained compiler from interfering with the process.
Subject: Re: [rt.cpan.org #121680] [PATCH] Improve map hash handling
Date: Wed, 31 May 2017 15:45:45 +0200
To: bug-Net-DNS [...] rt.cpan.org
From: Reini Urban <rurban [...] cpan.org>
Download (untitled) / with headers
text/plain 4.8k
Reini Urban rurban@cpan.org Show quoted text
> On May 31, 2017, at 12:49 AM, Dick Franks via RT <bug-Net-DNS@rt.cpan.org> wrote: > > <URL: https://rt.cpan.org/Ticket/Display.html?id=121680 > > > On Thu May 18 01:28:47 2017, RURBAN wrote: >
>>> The code fragment that offends you produces mappings with one or >>> three list elements in (strictly) equal numbers, which guarantees >>> that the complete list has an even number of elements. My job is to >>> make sure that happens, the compiler's job to complain if I foul up, >>> otherwise to get on with what I (in polite Perl) asked it to do. Is >>> that too much to ask?
>> >> Well, I decided to allow only a pair, not multiple in strict mode. In >> non-strict mode it is still valid code.
> > So you unilaterally decide to change the language, and suddenly its all my fault for using a well defined Perl5 feature.
That’s your point of view. My point of view is that cperl is besides perl6-lang and p5p one of the three perl language defining committees. perl6-lang has not much influence on CPAN modules (yet), only p5p and cperl has. p5p has a negative track record in designing features (in fact they failed in all attempts for 15 years), whilst cperl has no negative track record, and pushed 10x more fixes and features in 2 years than p5p in 15 years. p5p is actively destroying the language and the community, cperl is fixing and building it. everybody was waiting for 15 years that perl5 is being fixed. cperl is doing that. See http://perl11.org/blog/p5p-incompetence.html or https://www.reddit.com/r/cperl/comments/4gcwvi/what_to_do_with_p5p/ unilaterally: you mixed that with p5p development style. they unilaterally decide what’s being implemented and how, commit it to master without any discussion and there it is. everything sprout did in the last years. or what nicholas clark on the 10 years before. highlights being the double readonly system, the horrible COW system, and ref instead of bind, despite a good design from perl6, a design for perl5 by chip salzenberg (OP_BIND being reserved for >10 years), which was not pursued because it would slow down every single SV access at run-time. sprout didn’t care and implemented just that, slowing down every single SV access at run-time, and on top of that with an ill-designed \$ref syntax, not the better bind := perl6 syntax. in p5p technical criticism is disallowed and censored via their new religious code of conduct in which all violations by p5p members are tolerated (calling all germans or critics “assholes" being the typical way of engagement with the community), and technical criticism from outside is a violation for their new “lack of faith” argument. in cperl a feature is first publicly designed and presented as issue, then smoked in a branch, then smoked on cpan, and only then merged to master and released. like in perl6 and unlike in perl5. additionally to github cperl allows uncensored discussion in /r/cperl on reddit. /r/perl, blogs perl and p5p is censored by p5p shills and trolls with hilarious arguments. everybody who rather engages in p5p discussions about perl5 features is helpless, as these discussions are censored, meaningless, and actually harmful. they are actively leading to the destruction of perl5. you should rather engage yourself in perl6 and cperl feature discussions if you want to influence future changes. well defined: if it was well defined it wouldn’t lead to trouble. in fact it is ill defined, so I fixed it. this is one of the few features not taken from perl6. Show quoted text
> suddenly its all my fault for using a well defined Perl5 feature.
I never said that. I gave you a fix for cperl. It would be your fault not to apply it and leave out cperl support. it would raise the bar for cperl users. In order to fix dangerous habits such fixes are necessary. perl5 is not going anywhere, is badly maintained, is losing all it’s users, and is a security risk to use on public services. it’s still in the top 10 with lots of legacy code, cperl is recommended to be used there. p5p doesn’t take any cperl fixes, dozens of high risk fixes are live, and it get’s worse and worse every year. I’ve publicly warned from using perl5 since 5.16, and personally fixed all the known issues. and cperl broke only one feature (-d with sigs), whilst perl5 broke many more (binary names, cow, lexical $_, use encoding, types, the bytecode compiler). Show quoted text
> Splitting the construct into two lines does not alter what is taking place, does not change the risk profile, but merely prevents your over-constrained compiler from interfering with the process.
no, as explained it makes it clear that a list is spliced into a hash. splicing a map into a hash demands pairs. the strict hashpairs name is it clear enough. 'use strict; my %hash = @{[map {$_} (0..1)]}' is a valid single line alternative, but cperl does not recommend such code golfing. hence i left it unmentioned.
From: rwfranks [...] acm.org
Download (untitled) / with headers
text/plain 572b
On Wed May 31 09:46:14 2017, RURBAN wrote: Whatever your opinion, or the manifest shortcomings of p5p, the facts remain: (1) I still have a need to generate (pairs of) odd-length mappings. (2) For odd integers n,m : (n + m) mod 2 = 0 I am satisfied that the method is sound, know what I am doing, why I am doing it, and intend to continue. The only concession I will make is to separate the mapping step from the hash assignment to hide my logic from your compiler. The original code was legitimate Perl5, so it would be disingenuous to characterise this as a bug.
Subject: Re: [rt.cpan.org #121680] [PATCH] Improve map hash handling
Date: Thu, 1 Jun 2017 14:48:53 +0200
To: bug-Net-DNS [...] rt.cpan.org
From: Reini Urban <reini.urban [...] gmail.com>
Download (untitled) / with headers
text/plain 860b
I know, I believe I labeled it as feature for cperl 5.26 support. My latest GitHub contains the latest proper patch. Am 31.05.2017 22:53 schrieb "Dick Franks via RT" <bug-Net-DNS@rt.cpan.org>: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=121680 > > > On Wed May 31 09:46:14 2017, RURBAN wrote: > > Whatever your opinion, or the manifest shortcomings of p5p, the facts > remain: > > (1) I still have a need to generate (pairs of) odd-length mappings. > > (2) For odd integers n,m : (n + m) mod 2 = 0 > > I am satisfied that the method is sound, know what I am doing, why I am > doing it, and intend to continue. > > The only concession I will make is to separate the mapping step from the > hash assignment to hide my logic from your compiler. > > The original code was legitimate Perl5, so it would be disingenuous to > characterise this as a bug. >
The workaround is in the 1.11 release
Subject: Re: [rt.cpan.org #121680] [PATCH] Improve map hash handling
Date: Tue, 27 Jun 2017 11:08:58 +0200
To: bug-Net-DNS [...] rt.cpan.org
From: Reini Urban <reini.urban [...] gmail.com>
Download (untitled) / with headers
text/plain 189b
Thanks! Am 27.06.2017 11:04 schrieb "NLnet Labs via RT" <bug-Net-DNS@rt.cpan.org>: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=121680 > > > The workaround is in the 1.11 release >


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.