develooper Front page | perl.perl5.porters | Postings from March 2013

[perl #117255] Re: Bleadperl v5.17.9-200-g0e0ab62 breaks MLEHMANN/JSON-XS-2.33.tar.gz

From:
schmorp @ schmorp . de
Date:
March 21, 2013 13:27
Subject:
[perl #117255] Re: Bleadperl v5.17.9-200-g0e0ab62 breaks MLEHMANN/JSON-XS-2.33.tar.gz
Message ID:
rt-3.6.HEAD-28177-1363860169-1630.117255-75-0@perl.org
# New Ticket Created by  schmorp@schmorp.de 
# Please include the string:  [perl #117255]
# in the subject line of all future correspondence about this issue. 
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=117255 >


On Thu, Mar 21, 2013 at 10:04:24AM +0100, demerphq <demerphq@gmail.com> wrote:
> Your opinion is noted. However given you appear to be uninformed as to
> the details it is not worth much.

Then please state where I was wrong, I am always open to learn the facts.

> > - Unless I am mistaken, this is to avoid a DOS attack. DOS attacks are easy
> >   to protect against, and this won't protect me against basically any form
> >   of attack, so it's useless. Far better methods exist that prevent every
> >   form of memory resource and/or cpu time starvation.
> 
> You are mistaken.

You are really claiming that this is one of the best methods to prevent
memory resource and/or cpu time starvation? Because that's what the satteemnt
you quoted says.

Or maybe you meant I am mistaken in something else? Without telling me
what it is you are refering to it is hard to tell.

> > - I'd say this simply breaks perl, as perl documented the order is fixed,
> >   at least between runs (I would argue even the earlier fix to randomise
> >   between runs is a bug). Sure, the wording is ambiguous, but that doesn't
> >   make it any better.
> 
> I am unaware of any such documentation. Please state your sources.

The perlfunc 5.16 documentation on "keys". Older versions are even more
explicit.

all them are ambiguous, but I already mentioned that.

> > - Perl hash already are very slow (just write yourself some XS functions to
> >   interface to gcc's unordered_hash and watch the speed - despite the
> >   overhead of XS).
> 
> Yes, and this is a very tiny drop in a large bucket. If you think that
> the changes I made are going to affect hash performance in any kind of
> significant way then please provide evidence.

I don't think that, and haven't made that claim. I think you can make
faster hashes with better properties without the drawbacks.

> > - Taking out the inability to write a proper hash on all the perl developers
> >   out there is just wrong - Perl is the runtime, and should get it right,
> >   if possible.
> 
> This doesn't make grammatical sense,

I think it's a perfectly fine english sentence. Maybe a bit complicated for
you to understand though.

> so I don't know what you are trying to say.

I am trying to say that the solution for bad hash tables is better hash
tables, or a sense of proportion, not breaking perfectly fine existing
code.

> > So please reconsider your choice of making perl worse again.
> 
> I don't think I have made Perl worse, so currently I have nothing to reconsider.

To me, breaking existing code for questionable or no reason is making it
worse. It is obvious that you disagree and think you didn't make it worse,
but at best, you have to disagree with my perfectly valid opinion on this
topic-

> I am sure the perl5porters who are regular contributors will give your
> opinions on how they use their time the full attention and consideration
> that they deserve.

I am fully aware of them being volunteers, but so am I (and I am a regular
contributor as well), please keep that in mind.

The perl5porters are not "better" than me as a major contributor to perl
in any way, and have no higher moral ground. Acting uppity because you are
part of a mailinglist and contribute more often than me is proving nothing
really.

I can't "the people who maintainer perl5" (as opposed to perl5porters) to
do what I want, and neither do I try, but sarcaasm and ignorance on your
part is wrong too. My concerns are valid, and while you have all the right
in the world to ignore them, or even ridicule them, that doesn't make them
invalid.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp@schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About