"49" is also mentioned in the paper as possible solution. I've run test
from webrev with array length 2147483644 (Integer.MAX_VALUE-4) and
TimSort passed.
Lev
On 02/11/2015 10:57 PM, David Holmes wrote:
On 12/02/2015 5:14 AM, Lev Priima wrote:
Just briefly looked at it, w/o evaluating formal
The EG discussed these during Lambda and just couldn’t get excited about them.
On Feb 11, 2015, at 5:02 AM, Andrey Nazarov wrote:
> Hi everyone,
>
> I there any reason why java.util.List doesn't have lambda versions of indexOf
> and lastIndexOf methods like list.indexOf(Predicate<>) ?
>
> -
On 2/11/15 12:45 PM, Paul Sandoz wrote:
On Feb 11, 2015, at 8:23 PM, Stuart Marks wrote:
That "matches" my original thinking on the matter and is reflected in the patch. It's
very simple to support. If the method was named "findAll" then it would be misleading and
imply a reset was needed.
O
Roger et al,
Whichever way we go doesn't matter much.
But I continue to think that IOE is a better choice than UOE and I have
trouble seeing the motivation for the change to use UOE.
If you wanted to provide a way to tell if subprocess support was available
at all, then it would be better to add a
This is a request for comment only, at this point. There is no associated
formal test but there is one in the issue description.
Issue: https://bugs.openjdk.java.net/browse/JDK-8068373
Patch: http://cr.openjdk.java.net/~bpb/8068373/webrev.02/
I mostly want to know how out to lunch this approac
Hi Joe,
All right; will do.
Thanks,
Brian
On Feb 11, 2015, at 5:08 PM, Joseph D. Darcy wrote:
> Hi Brian,
>
> Looks fine; just adjust the copyright dates before pushing.
>
> Thanks,
>
> -Joe
Hi Brian,
Looks fine; just adjust the copyright dates before pushing.
Thanks,
-Joe
On 2/6/2015 12:29 PM, Brian Burkhalter wrote:
On Feb 6, 2015, at 7:46 AM, Brian Burkhalter
wrote:
On Feb 6, 2015, at 12:51 AM, Paul Sandoz wrote:
+1, but you should remove the "@throws IAE" on divRemNega
On 2/11/15 1:54 AM, Paul Sandoz wrote:
On Feb 11, 2015, at 12:02 AM, Stuart Marks wrote:
Hi Paul,
On 2/3/15 5:48 AM, Paul Sandoz wrote:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/
This patch adds a new flat mapping collector to Collectors. This can
Am 11.02.2015 um 23:57 schrieb David Holmes:
So where did the new magic number 49 come from? And how do we know this is now "big
enough"?
Thanks,
David
+1
Ulf
On 12/02/2015 5:14 AM, Lev Priima wrote:
Just briefly looked at it, w/o evaluating formal proof. But original
Python implementation(written on C) works on stack size even more
simple, AFAIU it:
/* The maximum number of entries in a MergeState's pending-runs stack.
* This is enough to sort arra
On Feb 11, 2015, at 8:23 PM, Stuart Marks wrote:
> On 2/11/15 2:25 AM, Paul Sandoz wrote:
>> Hi Stuart,
>>
>> Thanks for the detailed review.
>>
>> Here is a possible way forward:
>>
>> 1) Add the methods to Matcher, as proposed in the initial webrev.
>
> Yes, I think this is the way to go,
Hi Martin,
I'm still looking for additional support for using IOException instead of
UnsupportedOperationException; the prevailing view is that UOE is
appropriate.
The usual definition of UnsupportedOperationException seem to fit this
case well.
The behavior of the methods is not supported b
On 2/11/15 2:25 AM, Paul Sandoz wrote:
Hi Stuart,
Thanks for the detailed review.
Here is a possible way forward:
1) Add the methods to Matcher, as proposed in the initial webrev.
Yes, I think this is the way to go, and it seems that Sherman concurs.
1.1) Change the specification of Matche
Just briefly looked at it, w/o evaluating formal proof. But original
Python implementation(written on C) works on stack size even more
simple, AFAIU it:
/* The maximum number of entries in a MergeState's pending-runs stack.
* This is enough to sort arrays of size up to about
* 32 * phi **
Hi David,
Thanks for the suggestion:
"Forcible process destruction is defined as the immediate termination of
a process, whereas regular destruction allows a process to shut down
cleanly."
It is very OS and application specific as to how and if an application
does cleanly exit
but adding q
Thanks for the suggestions and confirmation that Duration is not a misuse
of that type for this purpose.
Roger
On 2/10/2015 2:38 AM, Stephen Colebourne wrote:
On 9 February 2015 at 23:44, David M. Lloyd wrote:
ProcessHandle.Info provides a startTime and totalTime. But it seems odd and
incon
Hi Lev,
The fix looks fine.
Did you consider the improvements suggested in the paper to reestablish
the invariant?
Roger
On 2/11/2015 11:29 AM, Lev Priima wrote:
Hi,
Stack length increased previously by JDK-8011944 was insufficient for
some cases.
Please review and push:
webrev: http://c
On 11/02/2015 16:20, Aleksej Efimov wrote:
Hi Alan, Miran,
If I understood correctly we can fix ">" in the next bulk update
(in early March). If it's so, can I have an approval for this fix?
Thank you,
Aleksej
Yes, fixing at the next sync up is fine (I didn't realize my mail was
holding this
Hi,
Stack length increased previously by JDK-8011944 was insufficient for
some cases.
Please review and push:
webrev: http://cr.openjdk.java.net/~lpriima/8072909/webrev.00/
issue: https://bugs.openjdk.java.net/browse/JDK-8072909
--
Lev
Hi Alan, Miran,
If I understood correctly we can fix ">" in the next bulk update (in
early March). If it's so, can I have an approval for this fix?
Thank you,
Aleksej
On 02/02/2015 01:46 PM, Miroslav Kos wrote:
On 29/01/15 16:06, Alan Bateman wrote:
On 29/01/2015 14:51, Aleksej Efimov wrote:
Hi
It might be more consistent with the existing design to add those
methods into Matcher. I agree the
better name for the "stream return" method is "findAll".
-sherman
On 2/11/15 2:25 AM, Paul Sandoz wrote:
Hi Stuart,
Thanks for the detailed review.
Here is a possible way forward:
1) Ad
Thanks, Roger.
On Feb 11, 2015, at 7:03 AM, Roger Riggs wrote:
> Hi Brian,
>
> Looks good.
>
> Thanks, Roger
>
> On 2/10/2015 7:06 PM, Brian Burkhalter wrote:
>> Please review at your convenience.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8064562
>> Patch: http://cr.o
Thanks, Lance,
Indeed, I was merely the amanuensis, or more precisely, the scribe. ;-)
Cheers,
Brian
On Feb 11, 2015, at 7:08 AM, Lance Andersen wrote:
> looks fine brian, the bug did a good job of explaining the issues.
looks fine brian, the bug did a good job of explaining the issues.
Best
Lance
On Feb 10, 2015, at 7:06 PM, Brian Burkhalter
wrote:
> Please review at your convenience.
>
> Issue:https://bugs.openjdk.java.net/browse/JDK-8064562
> Patch:http://cr.openjdk.java.net/~bpb/8064562/web
Hi Brian,
Looks good.
Thanks, Roger
On 2/10/2015 7:06 PM, Brian Burkhalter wrote:
Please review at your convenience.
Issue: https://bugs.openjdk.java.net/browse/JDK-8064562
Patch: http://cr.openjdk.java.net/~bpb/8064562/webrev.00/
Thanks,
Brian
Thank you Volker :)
On Wed, Feb 11, 2015 at 2:36 PM, Volker Simonis
wrote:
> Hi Thomas,
>
> I've just notices that your test has no copyright info and is indented
> with an indent width of 2 spaces instead of 4.
> If you don't mind I'll fix this before pushing so there's no need for
> a new webr
Hi Thomas,
I've just notices that your test has no copyright info and is indented
with an indent width of 2 spaces instead of 4.
If you don't mind I'll fix this before pushing so there's no need for
a new webrev.
Regards,
Volker
On Tue, Feb 10, 2015 at 10:58 AM, Thomas Stüfe wrote:
>
> Hi Roge
> On 11 feb 2015, at 12:15, David Holmes wrote:
>
> On 11/02/2015 8:36 PM, Staffan Larsen wrote:
>>
>>> On 11 feb 2015, at 09:39, David Holmes wrote:
>>>
>>> On 11/02/2015 6:34 PM, Staffan Larsen wrote:
> On 11 feb 2015, at 09:27, Magnus Ihse Bursie
> mailto:magnus.ihse.bur...@o
On 02/10/2015 08:46 PM, David Holmes wrote:
This time really adding Doug Lea :)
I don't have very strong opinions about this. Placing
park/unpark in Thread was our initial (circa 2000)
proposal, so in that sense it's ideal, and in principle
easily done by relaying LockSupport.{park/unpark} to T
On 11/02/2015 8:36 PM, Staffan Larsen wrote:
On 11 feb 2015, at 09:39, David Holmes wrote:
On 11/02/2015 6:34 PM, Staffan Larsen wrote:
On 11 feb 2015, at 09:27, Magnus Ihse Bursie
mailto:magnus.ihse.bur...@oracle.com>>
wrote:
On 2015-02-11 09:23, David Holmes wrote:
On 11/02/2015 6:09 P
On Feb 11, 2015, at 11:04 AM, David Holmes wrote:
> Paul,
>
> I appreciate the issue with discontinuing use of Unsafe but this churn to the
> public APIs seems unwarranted. Would we have done it differently from day
> one? Sure. Does that mean we should change it all now? Not without a very
> On 11 feb 2015, at 09:39, David Holmes wrote:
>
> On 11/02/2015 6:34 PM, Staffan Larsen wrote:
>>
>>> On 11 feb 2015, at 09:27, Magnus Ihse Bursie
>>> mailto:magnus.ihse.bur...@oracle.com>>
>>> wrote:
>>>
>>> On 2015-02-11 09:23, David Holmes wrote:
On 11/02/2015 6:09 PM, Magnus Ihse Bu
Hi Stuart,
Thanks for the detailed review.
Here is a possible way forward:
1) Add the methods to Matcher, as proposed in the initial webrev.
1.1) Change the specification of Matcher.results to reset the stream before
matching, making it consistent with the replace* methods.
2) Add convenience
Paul,
I appreciate the issue with discontinuing use of Unsafe but this churn
to the public APIs seems unwarranted. Would we have done it differently
from day one? Sure. Does that mean we should change it all now? Not
without a very good reason. And I'm on the fence there.
The fact that LockS
Hi everyone,
I there any reason why java.util.List doesn't have lambda versions of
indexOf and lastIndexOf methods like list.indexOf(Predicate<>) ?
--Thanks, Andrey
On Feb 11, 2015, at 12:02 AM, Stuart Marks wrote:
> Hi Paul,
>
> On 2/3/15 5:48 AM, Paul Sandoz wrote:
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/
>>
>> This patch adds a new flat mapping collector to Collectors. This can be
>> useful if one needs to
On Feb 11, 2015, at 12:15 AM, Martin Buchholz wrote:
> The addition of array comparison intrinsics makes sense - I've missed them
> myself on occasion.
>
Thanks.
> I was surprised that System.arraycopy hasn't been specialized for every array
> type.
> I guess the JIT is good at specializing
On Feb 11, 2015, at 12:26 AM, John Rose wrote:
> On Feb 10, 2015, at 3:15 PM, Martin Buchholz wrote:
>>
>> I was surprised that System.arraycopy hasn't been specialized for every
>> array type.
>> I guess the JIT is good at specializing all callers.
>
> Yes. Usually the arguments have specific
On Feb 11, 2015, at 2:43 AM, David Holmes wrote:
> Adding Doug Lea.
>
> On 11/02/2015 12:51 AM, Paul Sandoz wrote:
>> On Feb 10, 2015, at 3:39 PM, Chris Hegarty wrote:
Adding native methods to 166 classes will introduce another form of
dependency on the platform that i would p
On 11/02/2015 6:34 PM, Staffan Larsen wrote:
On 11 feb 2015, at 09:27, Magnus Ihse Bursie
mailto:magnus.ihse.bur...@oracle.com>>
wrote:
On 2015-02-11 09:23, David Holmes wrote:
On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote:
On 2015-02-11 02:35, David Holmes wrote:
Hi Magnus,
On 11/02/201
> On 11 feb 2015, at 09:27, Magnus Ihse Bursie
> wrote:
>
> On 2015-02-11 09:23, David Holmes wrote:
>> On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote:
>>> On 2015-02-11 02:35, David Holmes wrote:
Hi Magnus,
On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote:
> Here is an add
On 2015-02-11 09:23, David Holmes wrote:
On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote:
On 2015-02-11 02:35, David Holmes wrote:
Hi Magnus,
On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote:
Here is an addition to the build system, that will compile native
libraries and executables and make
On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote:
On 2015-02-11 02:35, David Holmes wrote:
Hi Magnus,
On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote:
Here is an addition to the build system, that will compile native
libraries and executables and make them available for JTReg tests
written in
On 2015-02-11 02:35, David Holmes wrote:
Hi Magnus,
On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote:
Here is an addition to the build system, that will compile native
libraries and executables and make them available for JTReg tests
written in Java.
Sorry I'm missing the basics here: when do
44 matches
Mail list logo
