Re: Bleadperl v5.17.9-200-g0e0ab62 breaks MLEHMANN/JSON-XS-2.33.tar.gz #12864
Comments
From @andkgit bisect commit 0e0ab62 Harden hashes against hash seed discovery by randomizing hash iteration sample fail report http://www.cpantesters.org/cpan/report/48924bc0-9027-11e2-869e-dc2c3b384401 The test failing: t/19_incr.t (Wstat: 12288 Tests: 697 Failed: 48) The line it reports in the diagnostics: https://metacpan.org/source/MLEHMANN/JSON-XS-2.33/t/19_incr.t#L22 When the test is running twice, then the reported fails are usually perl -V Summary of my perl5 (revision 5 version 17 subversion 10) configuration: Characteristics of this binary (from libperl): -- |
From @andk(Andreas J. Koenig) (via RT) <perlbug-followup@perl.org> writes:
Other candidates that start failing around the same time and should get JEEN/Acme-CPANAuthors-Korean-0.09.tar.gz I have not had time to verify that they all start failing on the same I have not verified others due to lack of time. -- |
From schmorp@schmorp.deOn Thu, Mar 21, 2013 at 06:41:28AM +0100, Andreas Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
Thanks andreas for pointing this out, hi Yves. I am talking a bit out of my ass here (call it a rant if you wish), and - Unless I am mistaken, this is to avoid a DOS attack. DOS attacks are easy So please reconsider your choice of making perl worse again. On a tangent, the current regime of perl development - making perl worse, I'd much prefer if the current perl5porters would go back to maintaining But hey, for what I know I am probably in the minority and other people So again, please reconsider, and think about either writing a proper Yves, I know you are not to blame, at least not alone, but it's really -- |
From @demerphqOn 21 March 2013 09:28, Marc Lehmann <schmorp@schmorp.de> wrote:
Your opinion is noted. However given you appear to be uninformed as to
You are mistaken.
I am unaware of any such documentation. Please state your sources.
Yes, and this is a very tiny drop in a large bucket. If you think that
This doesn't make grammatical sense, so I don't know what you are trying to say.
I don't think I have made Perl worse, so currently I have nothing to reconsider.
Thanks for your feedback. I am sure the perl5porters who are regular contributors will give your Yves -- |
From @lizmatOn Mar 21, 2013, at 8:33 AM, Andreas Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
So, to get this straight: my @key= keys %hash; With this change, there is no guarantee anymore that $key[N] => $value[N] (in the same process) ? I'm not 100% sure, but FWIW I think I have used this property of keys() and values() in production code in the past. Liz |
|
The RT System itself - Status changed from 'new' to 'open' |
From @demerphqOn 21 March 2013 10:15, Elizabeth Mattijsen <liz@dijkmat.nl> wrote:
Hi Liz! This hasn't changed.
Yep, you sure have, we all have I should think, at some point or another. :-) And the behavior has not changed. Any code that is currently correct What has changed is that in earlier perls you could do something like this: my @keys= keys %hash; and most of the time (but not always) get away with assuming that In 5.18 you are virtually guaranteed that $keys[$n] will NOT So all that has happened is that buggy code is now going to cheers -- |
From @demerphqOn 21 March 2013 10:25, demerphq <demerphq@gmail.com> wrote:
That should have been my @values= values %copy; Sorry. |
From @lizmatOn Mar 21, 2013, at 10:26 AM, demerphq <demerphq@gmail.com> wrote:
No problem, I realised that already. And *phew*. :-) Thanks for the explanation. Liz |
From schmorp@schmorp.deOn Thu, Mar 21, 2013 at 10:04:24AM +0100, demerphq <demerphq@gmail.com> wrote:
Then please state where I was wrong, I am always open to learn the facts.
You are really claiming that this is one of the best methods to prevent Or maybe you meant I am mistaken in something else? Without telling me
The perlfunc 5.16 documentation on "keys". Older versions are even more all them are ambiguous, but I already mentioned that.
I don't think that, and haven't made that claim. I think you can make
I think it's a perfectly fine english sentence. Maybe a bit complicated for
I am trying to say that the solution for bad hash tables is better hash
To me, breaking existing code for questionable or no reason is making it
I am fully aware of them being volunteers, but so am I (and I am a regular The perl5porters are not "better" than me as a major contributor to perl I can't "the people who maintainer perl5" (as opposed to perl5porters) to -- |
From @demerphqOn 21 March 2013 11:02, Marc Lehmann <schmorp@schmorp.de> wrote:
I am sorry, I seem to be missing some context here. What statement did The purpose of hash iterator randomization is make it harder, and Once an attacker can determine the hash seed they can launch
Well, I beg to differ. I think you are conflating "does not say The documentation for keys(), and as far as I know all other Furthermore I cannot find any evidence that the wording for this has In bleadperl it says: aeedbbe (Nicholas Clark 2007-12-21 17:58:03 In Perl 5.14.2 it says this: The keys of a hash are returned in an apparently random In perl 5.8.5 it says this: The keys are returned in an apparently random order. Here is what it said in 1998/99: 19799a2 (Gurusamy Sarathy 1999-05-24 07:24:11 And in 97: aa68939 (Perl 5 Porters 1997-02-22 04:41:00 And in 94 (5.000) a0d0e21 (Larry Wall 1994-10-17 23:00:00 +0000 1578) Returns a perlfunc.pod didnt exist prior to that commit. I see nothing ambiguous in the documentation, nor do I see it becoming
So then why did you bring it up in this thread? If you have issues
I guess you meant "your" when you said "the". If so then I will just say that I find this comment rude and But please, go ahead and prove me wrong. Post some patches.
I find it really hard to take you seriously given how often you make
I have to disagree? What? Did you mean "agree"? Anyway, it doesnt matter. I don't break existing code for no reason.
Perhaps you are, I never advanced an opinion on the subject.
I never made any comments about anyones individuals merits. Nor do I
Well I have responded to the only cogent concern that I have seen you Is there some other matter I should respond to? Oh, I suppose I forgot. Afaik, you don't even have to fix this, just See: https://rt.cpan.org/Public/Bug/Display.html?id=83421 Thanks for your feedback. Yves -- |
From schmorp@schmorp.deOn Thu, Mar 21, 2013 at 12:28:54PM +0100, demerphq <demerphq@gmail.com> wrote: I interpreted it to mean to refer to the last one you quoted. Now, if you didn't quote anything, what would your statement refer to?
That in itself is obviously a no-goal. No, I don't believe that is the real Or something like that. In case you wonder why it is a no-goal, I can discover these hash seeds
I think you are splitting hairs, but you get it wrong. The purpose of your change is to make it harder to apply such DOS attacks. So it seems I was completely right after all. Thank you for spelling it out for me to verify.
I think it strongly implies it. Beat me if you wish, but your
Sorry, but "guaranteed to be the same as either the keys ..." clearly
No problem with that.
It also says the ordering is the same for the same hash. I know how it's meant, but I also know what is said, and assuming that Note that the earlier randomisation patch already broke the semantics, as
Saying it changes in future versions but is the same for the same hash I give you, as I said, that the wording is ambiguous, and that it is
And it clearly changed, if you took notice.
Saying you don'T se something has no value whatsoever. People tend to chose You'd have to make the stronger claim that no other interprettaion is
I said it before, and Is aid it again: I didn't bring up what you put into my I think one can make faster and better hashes which fix this problem without That means the breakage is not necessary.
No, I specifically meant "the", because I didn't want to say "your".
Since your assumption is wrong, your conclusion is irrelevant fprtunately.
And I didn't claim so. On purpose, in fact.
I already did some benchmarks with unordered hashes. I wonder what they
If you want me to respect your opinions on what is fine code, please
I don't know if they are unwarranted, but at least they were documented,
Well, the code in question (which defines my assumptions) works with older
No, I mean "disagree". You seem to be very combative, and I guess this is why you make so many I _really_ mean that you disagree, and I really mean that you have to
Sure. I am saying they are bad reasons, and badly executed, not that it is
Never said anything to the contrary.
Empty claim.
The actual random ordering changes with each make test run, too, but the
It says the ordering is the same for the same hash. Changing the hash function doesn't break the code. Changing the hash At this point I must actually admit that I didn't even check that this is So if the ordering is really the same for the same hash, within the same Is that the case?
Well, I am. I tell you so. What are your reasons do doubt me so much?
I interpreted your comment as irony, as am pretty confident it was meant
Well, it clearly does. It's your interpretation that doesn't support mine,
You don't have to respond at all, but if you do so, I personally expect
But the bug is in the perl core. Nothing I apply can fix that, becasue I Besides, it makes no sense to me to say "you don't have to fix that, just The problem is that I think the code is fine, and even if not (by sheer power All I urge you, again, is to consider doing the "hardening" either better, I don't have any strong hope for that, and think you will opt for the -- |
From @tseeOn 03/21/2013 02:00 PM, schmorp@schmorp.de (via RT) wrote:
Alternative solutions, with implementation to prove their validity,
Umm, who is splitting hair now?
So why imply otherwise in the first part of your sentence? Shove your
So let's rephrase: If you care for JSON::XS to continue working, then
Hair! In tiny fragments! --Steffen |
|
The RT System itself - Status changed from 'new' to 'open' |
From @ribasushiOn Thu, Mar 21, 2013 at 06:00:56AM -0700, schmorp@schmorp.de wrote:
Marc, you actually are misunderstanding here. The purpose of the changes There is no access to the running process itself, no XS, no debugging Chers |
From @LeontOn Thu, Mar 21, 2013 at 2:00 PM, schmorp@schmorp.de
Well, if you can insert an XS module or a debugger you've already got
IMO same hash clearly means same identity, not similarly valued (if
It suggests this changed wasn't planned years ahead of time, nothing
Alternative interpretations are unfortunate and sometimes something to
perl doesn't agree it's fine.
You're assuming that similar hashes always return their content in the 1) The values don't have the same bucket-size Neither case is very likely in most code, but they can both
Well, one of the two has to change, and it is unlikely to be perl. Leon |
From schmorp@schmorp.deOn Thu, Mar 21, 2013 at 06:45:11AM -0700, Steffen Mueller via RT <perlbug-followup@perl.org> wrote:
Honestly, I do so much for perl, and after my previous experiences I don't
Obviously not me - would you do me a favour and just read the whole mail, He made a wrong assumption/accusation, and all I did was point out that
I am not aware of implying anything otherwise. When it comes to it, it
I honestly don't think I am passive aggressive, Steffen. But the fact that you attack me and ignore the actual issue completely tells I'd take somebody like me, who actually argues, any time over somebody Can you do better? Sure you can.
And many others sure do. Apart from trolling and personal attacks, do
That's exactly what I was pointing out. Count yourself a genius for In any case, I won't reply to obvious troll attempts by you anymore. I have no problem with a bit of drama, but please, make it worthwuoe by -- |
From schmorp@schmorp.deOn Thu, Mar 21, 2013 at 06:54:52AM -0700, Peter Rabbitson via RT <perlbug-followup@perl.org> wrote:
No, I don't.
First, that's not what yves said (but sure, he is wrong). Secondly, if your ead my mail, it is painfully obviously thta I know that - I It was yves who disagrees and said it's purpose to to avoid discovering
I am perfectly aware of that, thank you very much. Again, pleae do I even brought up an example of how to exploiut this using a DOS attack
I know. Please read the whole thread before making comments, thank you. -- |
From @demerphqOn 21 March 2013 15:00, Leon Timmermans <fawaka@gmail.com> wrote:
Thats 3. :-)
Ah but those are the rare examples. The common example is this: %copy= %hash; Any items that collide will change order in %copy as compared to hash This demonstration should work on any perl prior to the new hash randomization: $ perl -le'my %hash=(13=>1,19=>1); print join " ", keys %hash; my So in the old days it was not even unlikely that the two "similar" Yves -- |
From @ribasushiOn Thu, Mar 21, 2013 at 03:15:27PM +0100, Marc Lehmann wrote:
I am confused... If you know there is no access to the running Not trolling - honest question. |
From @TuxOn Thu, 21 Mar 2013 15:12:33 +0100, Marc Lehmann <schmorp@schmorp.de>
Name anything that I cannot live without? $ cat $HOME/.cpan/prefs/MLEHMAN.yml comment: "use common sense" Sorry, you never convinced me your contributions should change that
And what makes you think we *do* have the time to argue?
It is currently done properly and done well. By (very) competent people. -- |
From schmorp@schmorp.deOn Thu, Mar 21, 2013 at 07:02:01AM -0700, Leon Timmermans via RT <perlbug-followup@perl.org> wrote:
Again, it was yves who brought this up, not me. I was merely arguing that
Your opinion is irrelevant. I am not claiming it's the only valid Same hahs clearly means "same hash". Ask some people by showing them: my %a = (a => 1, b => 2); Are you sure that "clearly" %a and %b are not the same? Do you really think I don't think so, but you can surprise me. Note that you are conveneitnly ignoring the other arguments I made. Documentation is mostly irrelevant. Even if documentation clearly said it The documentation just explains why relying in this behaviour is not I was pointing out that code that relies on this is not broken, or buggy, Furthermore, I claim this is a useful feature, and breaking it shouldn't be And rantily, I pointed out that the low regard for bakcwards compatibility
The documentation cleaims it's the same for the same hash, but the ordering I think you are talking bullshit semantics here. A normal reader will Which it was.
I never claimed they are authoritative. You (as a group) however claimed that And that isn't true. It's a reasonable interpretation, and a useful It shouldn't be broken lightly.
development versions don't, all released versions do, by documentation and What you mean is that some developer(s) disagree. That is indeed fine, but
But I don't, and haven't said so. I claim the code in question is fine and
All of these are not relevant to this discussion though.
And why would that be? You hold a gun to my face? You take away
I think so, too. -- |
From schmorp@schmorp.deOn Thu, Mar 21, 2013 at 07:18:13AM -0700, yves orton via RT <perlbug-followup@perl.org> wrote:
It is also unrelated to the code in question.
A pity, but not the code (and topic) in question here. -- |
From schmorp@schmorp.deOn Fri, Mar 22, 2013 at 01:20:40AM +1100, Peter Rabbitson <rabbit-p5p@rabbit.us> wrote:
Because I originally said it's about avoiding DOS attacks (and later Now, the DOS attack is only an example of an algorithmic complexity attack So, if the difference between the DOS attack I was talking about, and the There are all sorts of attacks one can launch remotely. It is good that perl It is always a trade-off between usefulness of the language and resistance If such a remote attack would be a significant danger and wouldn't be caught But the evidence is lacking, and this looks more like blind action. I also The problem here is likely the over-reliance on power-of-two hashing I hope I answered your question in detail.
And surely I had no indications otherwise. I can differentiate between It is unfortunate that Steffen feels he has to poison the atmosphere that -- |
From @ribasushiOn Thu, Mar 21, 2013 at 04:03:54PM +0100, Marc Lehmann wrote:
You did, thank you. However I fail to understand how do you find That is if a hash order is stable 99.9% of the time, and then in the Could you elaborate? [1] Just to make sure I understand - from what I gather this: `perl -MData::Dumper -e '$Data::Dumper::Indent = 0; print Dumper {(1..20)}; print "\n"'` producing identical output on all perls between 5.8.2 and 5.16.3 is Cheers |
From schmorp@schmorp.deOn Thu, Mar 21, 2013 at 07:24:19AM -0700, "H. Merijn Brand via RT" <perlbug-followup@perl.org> wrote:
And what is the relevance for this topic and why would I care?
No, I honestly don't care if you use my packages. The reason you stopped using my packages, as you yourself told me, is that I said no, and said it's not unreasonable to ask you to upgrade, because a I have no problem that you don't want to use my module(s) because of Again, everybody is *fine* to not use my software. This is something But I do consider your behaviour wholly unreasonable, and if the And the arrogance of trying to threaten me into doing your work for free So, no, my modules are not for you, and you clearly don't deserve it - (But I of course have no problems with you using it, according to their In any case, folks, ranting is all fine and good, but why don't you at -- |
From schmorp@schmorp.deOn Fri, Mar 22, 2013 at 02:15:53AM +1100, Peter Rabbitson <rabbit-p5p@rabbit.us> wrote:
I don't find that usefil, I find the actual behaviour useful. Old perls New perls do it only when setting an env variable, or within one process -
No, and I made it explicit that I am fine with that (and it's clearly I have a problem (or rather, my module has one) with this code not use feature 'say'; my %a = (a => 1, b => 2); say keys %a; Besides, I didn't know these perls would produce identical output - but
Are you sure anybody would consider it a bug to get the same output for the I would say that's the default expectation, don't you agree? At least not -- |
From @TuxOn Thu, 21 Mar 2013 16:17:20 +0100, Marc Lehmann <schmorp@schmorp.de>
No, I wanted you to conform to C89, which is what the rest of perl
I used HP C-ANSI-C as an *example* to why your code should use ANSI
I think it is not reasonable to ask to upgrade a compiler that conforms
Then how hard would it be to conform to C89 and let the rest of the
When did I ever threaten you?
Hrmph. IIRC my quest came with a (simple) patch. there was NO work for
I'm not suffering at all. Moreover, I think I am quite amused by the
I think I am, but you seem to misunderstand a lot of other people too. -- |
From @demerphqOn 21 March 2013 14:00, Marc Lehmann <schmorp@schmorp.de> wrote:
Ah, right, I didn't consider that "quoting" even tho of course it is.
Peter Rabbitson already replied to this. Here is the dialog that ensued: On 21 March 2013 16:03, Marc Lehmann <schmorp@schmorp.de> wrote:
You know that this is not about XS nor having access to a debugger, So you are trolling.
Your attitude makes me want to split hairs with you. You employ a The patch to make hash iterator traversal random is specifically to
I haven't been in any way dishonest. There is nothing false about my
No, my interpretation is correct and yours is a figment of your
No, no, no. There is no consistency, there never has been, there never
Yes, as in identity. If you find that keys(%hash) returns items in a different order than values(%hash) does then please file a bug.
The docs say "the same hash unmodified", so that implies very strongly
No, it didnt break any semantics. Stop making stuff up.
No it doesn't.
Not in any way relevant to this discussion, if you took notice.
There is nothing here to argue about, you are wrong, and there your
Are you really so stupid as to claim you didnt say something only a Did you not say: "I think you can make faster hashes with better properties without the And was I not replying to you saying it?
So prove it. Patches welcome.
Which just shows you really have no idea at all how Perls hashes work. Which pretty much ends this discussion.
I don't really give a shit about your opinion actually. Especially as
As I said before, there is nothing ambiguous about saying nothing
So sure, I can make it break with a one line change.
You are rude and insulting in your manner, you should not be surprised
You certainly implied it with "breaking existing code for questionable
Ive already demonstrated how your assumptions are broken by a simple hash copy.
And it is. (So long as you dont modify it by inserting new items.)
We don't change the hash function during the process.
Well you are wrong.
@keys1= keys %hash; will always return identical @keys1 and @keys2 assuming %hash is a
Perhaps you are, I never advanced an opinion on the subject. But since you bring it up again I will note I checked the log and you $ git log --grep "Marc Lehmann" --pretty=oneline
I meant every word in that sentence literally.
There is no "clearly does" involved here. The documentation simply
Excuse me? No the bug is in your code, expecting to snapshot a
If you prefer that wording then so be it.
Post some patches or shut up. I dont care what your opinion is on this Yves -- |
From schmorp@schmorp.deOn Thu, Mar 21, 2013 at 08:36:34AM -0700, "H. Merijn Brand via RT" <perlbug-followup@perl.org> wrote:
I don't remember it that way, sorry. It wasn't just minor, and as people here
Right, asking people to write their C++ or Fortran code in C is not But well, you are entitled to your opinion and not using my module, but
The rest of the people happily enjoy it, last I heard from them.
In your mail merijin. And now you execute your threat (probably not the
You don't.
It did not. And making up bullshit like "it was NO work AT ALL" doesn't make it If it was no work at all, why didn't you do it? It's free software after The lack of respect you show for the work others have done for you to use, In reality, you are just whining because I don't support your pet What's next, I need to support perl 5.001? -- |
From schmorp@schmorp.deOn Thu, Mar 21, 2013 at 12:01:13PM -0700, "Deven T. Corzine via RT" <perlbug-followup@perl.org> wrote:
Exactly, the meanings are not synonymous. However, I agree with Andy that this thread is not productive anymore. I gave my arguments, and was mostly ignored without hearing others. If you want a reply from me, you have to write to me privately, so I can This is true for anybody else - keep in mind, I didn't post to the list -- |
From @rurbanOn Thu, Mar 21, 2013 at 8:44 AM, Steffen Mueller <smueller@cpan.org> wrote:
For the public facing cPanel binaries I solved the problem by using Of course a collision-free hash without the fallback to a linked list The typed/const branch is at my github, the 5.8.1 patch for 5.6 is on |
From @bulk88On Thu Mar 21 07:02:00 2013, LeonT wrote:
No need for XS or a debugger, "unpack('P'" and "(\%hash)+0" and you read -- |
From @iabynOn Thu, Mar 21, 2013 at 04:52:49PM +0100, Marc Lehmann wrote:
Marc, I think you have beautifully summed up why so many of the people who -- |
From @ikegamiOn Thu, Mar 21, 2013 at 9:00 AM, schmorp@schmorp.de <
"Same hash" is not used in the documentation. The documentation says "a Note that the earlier randomisation patch already broke the semantics, as
No semantics were changed. It's always been the case that C<keys> could |
From @ikegamiOn Sat, Mar 23, 2013 at 5:00 AM, Eric Brine <ikegami@adaelis.com> wrote:
For example, my %a = map { $_ => 1 } 'a'..'g'; print keys(%a), "\n"; # ecagbdf |
From schmorp@schmorp.deOn Fri, Mar 22, 2013 at 11:34:15AM -0700, Dave Mitchell via RT <perlbug-followup@perl.org> wrote:
Besides, even if it were true - look at whom you cc'ed. Yep, the person who, So, while I respect the work of others, I wouldn't be surprised if that If at all, I should be praised for not going down to that level, but I If you have any grain of integrity in you, then think about that. Maybe Sure that sounds arrogant, but after people telling me my code is shoddy I will continue to provide quality software that is useful for an -- |
From schmorp@schmorp.deOn Fri, Mar 22, 2013 at 11:34:15AM -0700, Dave Mitchell via RT <perlbug-followup@perl.org> wrote: I am sorry that my last reply has gone to perlbug-followup@perl.org - -- |
From @iabynOn Sat, Mar 23, 2013 at 12:07:51PM +0100, Marc Lehmann wrote:
You seem uncertain. I can assure you it is true.
Lets look at https://rt.cpan.org/Public/Bug/Display.html?id=42462 He made a bug report about your code not supporting older compilers what a bunch of bullshit claims, the code is of course fully ANSI-C Straight off the bat, rude and attacking the *person*. But I am more concerned with your initial response to this hash thread.
But you immediately rush to the lowest possible, most combative level, at
Ah, after one post, already questioning my integrity.
I will continue providing a quality perl interpreter for an enormous -- |
From schmorp@schmorp.deOn Sat, Mar 23, 2013 at 01:02:03PM +0000, Dave Mitchell <davem@iabyn.com> wrote: Dave, you took my *private* reply and again posted it to the list. Unlike Since you are dragging this back to the list *again*, I need to answer it No thanks for making this list an even worse place, but I am sure you feel
There was no patch as has been pointed out before. Making up lies like
That's not "straight off the bat", that's a reply to a rude and You might claim I have little tolerance to bullshit, but looking at only It's merely an attempt at character assassination. rt.cpan.org *is* a common place to go to when the maintainer refuses some The problems with, in general, rt.cpan.org are a whole different chapter
It definitely was a rant (as I wrote myself), but while I have no clue The continued breakage in recent years, paired with bad decisions,
I was well informed about the problem as-is (the problem itself is old), What exactly should I have attempted, and what exactly would that have No, I wasn't, so you implying that I would have had to enquire more first
No, you confuse me with yves. I charged in and made arguments on why this Most everybody else (but not vereybody) charged in and accused me of being At least the current perl maintainer agreed with me on my points (that the
Making this up doesn't make it true. Nowhere did I say or imply that, as
And I would answer that you lie in public, not even stopping from
That's not true. I might be dumb enough to only leave traces of that
You haven't shown even a single case (because your conclusion is based on But hey, even two cases makes "every available opportunity". The staggering amount of bullshit that you pull out of your arse is
Another lie, I didn't question your integrity, I told you that if you have Didn't happen, so now I do question your integrity.
Reality check: "providing a perl interpreter". Well, I provide multiple There is no doubt that you worked a lot more on perl than me and most I think you have a hyperinflated ego. But that's fine. Spreading lies like a machine is not. If don't think I -- |
From @TuxOn Sat, 23 Mar 2013 15:32:07 +0100, Marc Lehmann <schmorp@schmorp.de>
Somehow you cannot bring up the decency and respect to write my name as Furthermore, I have never ever had the intention to be rude. The -- |
From schmorp@schmorp.deOn Sat, Mar 23, 2013 at 07:41:48AM -0700, "H. Merijn Brand via RT" <perlbug-followup@perl.org> wrote:
I honestly apologize for that - it definitely wasn't on purpose, and had You could accuse me of not being diligent enough, and that is true, I consider mistyping a name on purpose as childish, and would not do so, Merijn, Merijn, Merijn. Indeed, hard to type for me, and I guess I'll have
Neither me then.
Same here then. I always try to reply in form.
Wholeheartedly accepted. You might be pleased to know that I did invest -- |
From @iabynOn Sat, Mar 23, 2013 at 03:32:07PM +0100, Marc Lehmann wrote:
Completely untrue. I took your public email: Message-ID: <20130323110751.GB2845@schmorp.de> and made a public reply to it, to <perlbug-followup@perl.org>. You sent a second email to me privately, which I replied to privately: Message-ID: <20130323131406.GE2409@iabyn.com> At no point did I change any of the To/CC fields manually.
You imply that I have made private threads public at least twice. I have
No, I try very hard to be polite and accommodating on public lists, I have never *once* made a deliberately trolling post in my 30 years online.
It was clearly and unambiguously a patch. It wasn't in diff format, but it HE *hes [count]; I have no opinion as to whether it was a good or complete patch, but it
A classic Marc-ism. Take a slight argument over semantics and immediately
I am just going on the evidence that was presented to me: a bug report
No, its just an accurate comment: it was your initial reply to the ticket,
By that, I meant nearly everything in your initial email contained broad,
The hash issue has seen extensive discussions recently, both in the So you weren't entering into a constructive dialogue, you were just bashing.
You didn't appear to be aware the technical details of the motivation And there you immediately leap in with another ad Homenem. A difference of
He also stated that the change "has been in progress for quite some time,
To quote from your original email: "the current regime of perl development - making perl worse, My one-line summary may have been a touch hyperbolic, but I think it Once again you accuse me of being a liar. Doing a personal attack appears
And as I already pointed out, I did not reply in public to a private Oh, and please stop calling me a liar. It is unjustified and deeply
Your lack of self-awareness is astonishing. At the first sign of
There you go again.
Oh look, there you go again.
There you go again.
There you go again
So the 5.14.3 tarball just spontaneously self-assembled?
You are an intelligent person. I don't for one *second* believe you you
Oh look, there you go again. Just for the record, since attacking your opponent seem De Rigour in
Once again I will point out that I have not lied a single time. This is my final communication with you. -- |
From vadim.konovalov@alcatel-lucent.com
1) it appears that HE is larger than HE* and allocating more memory, hence 2) when that chunk of memory freed? TIA :) |
From @demerphqOn 21 March 2013 06:42, Andreas J. Koenig via RT
A patch to fix this can be found in: https://rt.cpan.org/Public/Bug/Display.html?id=84151 Which is the equivalent of: Inline Patchdiff --git a/t/19_incr.t b/t/19_incr.t
index 119a80a..2ff7ce0 100644
--- a/t/19_incr.t
+++ b/t/19_incr.t
@@ -24,8 +24,8 @@ sub splitter {
}
}
-splitter +JSON::XS->new , '
|
From schmorp@schmorp.deOn Sat, Mar 23, 2013 at 09:34:17AM -0700, Dave Mitchell via RT <perlbug-followup@perl.org> wrote:
I stand corrected, and apologise for that.
He quoted a compiler error message, gave some lines of C code, and some
He wrote no such thing, neither clearly not implied nor even hinting at You just made this up by actually editing what he wrote and putting it How low can you go, Dave? While in hindsight he might have intended his mail to be a patch, he
A patch is, at the very least, is a description of changes to apply. Quoting a compiler error, writing some random lines of C and then claiming
If you don't want to be accused of lieing you just have to stop doing it. The above example of falsifying the e-mail you talk about is a good
Yeah, because you didn't even try to look at the whole story. You see part of You might be forgiven to come to the wrong conclusion, but the conclusion
I disagree, but the way you misrepresent mails to suit your needs doesn't
Since you skirted answwering the questions, I assume I wasn't wrong after
Given that these methods are well known, trivial, and explained by me later However, I gave far more explanations than Yves in his reply, or any later All that the responsible person was capable of saying was "you are wrong", My initial mail was, _in comparison_, an encyclopedia of mitigation
As my interaction with reasonable members of the list has shown, I did enter It's hard to enter in a constructive dialog if the majority of p5p, and
I don't think I gave you any reason to think that, and the person who Note also that leaking the details of the hash seed is not the primary
Except this is not about a difference in opinion, but about you making an Misrepresenting what you actually said as an opinion, of course, fits into
[snip]
Also simply wrong, so it seems you admit that you made it up.
Maybe, but that's not what you said. What you said was just made up, which
It seems to be factual, since you are well aware that the many things you
It's not a personal attack if it's true, and it was clearly not my first
Sure, you were just bending the truth unti it broke or so. We might disagree
If you find it offensive then stop doing it, Dave. If you would refrain
Another lie.
Yeah, it gets old quickly. As yves put it... "you made me say that". If you wouldn't make up all this bullshit, I wouldn't have to call it Seriously, you don't pull anything out of your arse, but you still make it
I assume your refusal to back up your claim means that you admit you made
Great argument to back up your claims.
I don't think so.
And I didn't say so, Dave, so take your strawmen ad burn it somewhere else. What I do believe, and what should have been clear from what I stated so
Let me point out then that I never in my life wrote a single ad hominem,
If your assortment of deliberate misinformation could even be called -- |
From @TuxOn Sun, 24 Mar 2013 04:05:20 +0100, Marc Lehmann <schmorp@schmorp.de> snipping all but what I want to comment upon …
The first post in that thread was what I - as an XS module author -
Come on Marc. You care for your software, so you are able to combine an
guilty as charged
And a test case, which in view of what Vadim noted would have shown Already seems to be much more portable for that part. Where do I claim that to be a patch?
Fully agree
In how (other) people interpret written text, and reflecting their -- |
From schmorp@schmorp.deOn Sun, Mar 24, 2013 at 03:19:42AM -0700, "H. Merijn Brand via RT" <perlbug-followup@perl.org> wrote:
The simple fact is, I was not able to, for whatever reason. In isolation And I had to wade through a lot of bullshit, such as things being So no, your intentions weren't at all clear to me. It still sounds as if Maybe you wanted to rant, because you were obviously pissed off by somebody I don't mind when somebody acts like that (that would be rather
I have no such requireemnts for patches. Neither do patches have to have
I fully agree, but things are a bit different here. People can be confused about meanings, and can misinterpret things as much as But when you tell them it isn't true, and give reasons, and they ignore Just look at this sad thread. I don't know how many times it was pointed Yet I still receive private mails where people tell me that all I need to Fair enough you might say, and to some extent, that's true. But when they And there also has to be a limit. When somebody replies to this thread, Also, make no mistake. This list has been used before to spread lies about
Let's not get hung up over an apparently politically-incorrect word. Dave made untrue statements while well knowing that they are likely The words aren't important, it's whats being done that is. Or rather, that's wrong. Seems for some people the words are more -- |
From @bulk88Konovalov, Vadim (Vadim)** CTR ** wrote:
alloca, it can never leak. A non-const length auto C array calls alloca |
From @ikegamiOn Sun, Mar 24, 2013 at 4:00 PM, bulk88 <bulk88@hotmail.com> wrote:
I think he's asking about the newly introduced Perl_malloc |
From @TuxOn Mon, 25 Mar 2013 20:47:39 -0400, Eric Brine <ikegami@adaelis.com>
I tested this yesterday with this code: my $td = 0; my $te = 0; printf "%s: encode %10.6f s/run\n", $f, $te / $n; on two relative big json files test1.json is unformatted (no newlines -rw-rw-rw- 1 merijn users 716642 Mar 25 18:40 test1.json Testing test1.json Then changed the code to (note the (HE *) and the dropped _ for #if defined(__BORLANDC__) || defined(_MSC_VER) || defined(__STDC__) and got Testing test1.json Then with Perl_malloc #if defined(__BORLANDC__) || defined(_MSC_VER) || defined(__STDC__) which resulted in Testing test1.json which is still faster than the original code. gcc (SUSE Linux) 4.7.2 20130108 [gcc-4_7-branch revision 195012] -- |
From @demerphqOn 26 March 2013 08:32, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
IMO the differences there are in the noise. Yves -- |
From schmorp@schmorp.deOn Tue, Mar 26, 2013 at 02:21:20AM -0700, "H. Merijn Brand via RT" <perlbug-followup@perl.org> wrote:
Your test wouldn't even execute the code, so any difference you measure
Since the code you benchmark should be effectively identical this just Just for fun, and to waste more time that I could have used to actually do http://ue.tst.eu/c511fb5d9e4ebc2cd389d7716c706242.txt I measured the runtime of the full program, not just the encodes. With STACK_HES defined to 64 (the default), I get: real 0m0.808s With STACK_HES defined to 0 (basically disabling using the stack and always real 0m0.938s That's a 16% increase in runtime. That probably doesn't mean much to p5pers who don't mind slowing down perl Things get worse when you don't use method calls to call encode, and then All in all, my mini benchmark strongly favours malloc. I never benchmarked this before, of course, but assuming that the The very fact that your test is apparently slightly faster with a much I just hope when designing patches for perl and talking about differences -- |
From @demerphqOn 26 March 2013 13:14, Marc Lehmann <schmorp@schmorp.de> wrote:
If you are referring to the timing results that Merijn posted then I As for /your/ "benchmark", well, it doesn't seem to be very useful http://blogs.perl.org/users/steffen_mueller/2010/09/your-benchmarks-suck.html which could almost be tailor written for this exact case. Try running under dumbbench for a while and see what it says. THAT Lastly I would just like to say that comments like this: "That probably doesn't mean much to p5pers who don't mind slowing down perl are unhelpful and just plain rude. We care a lot about slowing down You are clearly an intelligent person. Anyone reading your code knows Yves -- |
From schmorp@schmorp.deOn Tue, Mar 26, 2013 at 01:35:52PM +0100, demerphq <demerphq@gmail.com> wrote:
The obvious conclusion is that result is suspicious and needs better
Of course it does, don't get silly. It might not be a very exact benchmark, but unless you can point out an
None of that applies to this case.
Do it yourself, prove that my benchmark is wrong, and you have a
It tells you that at least under some conditions, the code is 16% slower, Cache colouring can have an effect this large, but the naive blog posting Massaging your data set to throw out values you don't like without Recompiling and repeating the test, as I did, does take all this into
The example in my "rude" statement is neither about correctness or about
Well, the evidence supports both. If you find reality unpleasant, then I am the wrong person to complain to.
I am quite sure there are bug gains to be gotten. I have a few ideas But frankly, either show your goods or shut up, because from what I see
I think I am just pointing out the obvious.
I never had reason to believe that I miss out on support of other clever -- |
From @cpansproutJSON::XS 2.34 works with 5.18. -- Father Chrysostomos |
|
@cpansprout - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#117239 (status was 'resolved')
Searchable as RT117239$
The text was updated successfully, but these errors were encountered: