On 3/03/2022 11:02 pm, Julian Waters wrote:
I understand, I'll notify the author about this. I'm not sure if they'll
be alright with discussing on the mailing lists though, since they have
expressed that they prefer discussing it on the PR itself
That's not the way OpenJDK works, and anything
I understand, I'll notify the author about this. I'm not sure if they'll be
alright with discussing on the mailing lists though, since they have
expressed that they prefer discussing it on the PR itself
best regards,
Julian Waters
On Thu, Mar 3, 2022 at 8:57 PM David Holmes wrote:
> On 3/03/202
On 3/03/2022 10:47 pm, Julian Waters wrote:
Hi David,
I did not create the PR, I'm instead asking for others to review it
before I help the author create the issue on the JBS. Should I just go
ahead and create the issue for them?
The best thing would be for the PR creator to discuss the prop
Hi David,
I did not create the PR, I'm instead asking for others to review it before
I help the author create the issue on the JBS. Should I just go ahead and
create the issue for them?
best regards,
Julian
On Thu, Mar 3, 2022 at 8:45 PM David Holmes wrote:
> Hi Julian,
>
> On 3/03/2022 10:33
Hi David,
No worries :)
regards,
Julian
On Thu, Mar 3, 2022 at 8:47 PM David Holmes wrote:
> Sorry Julian, I see now you were the person aiding the person who
> created the PR.
>
> David
>
> On 3/03/2022 10:45 pm, David Holmes wrote:
> > Hi Julian,
> >
> > On 3/03/2022 10:33 pm, Jules W. wrote
Sorry Julian, I see now you were the person aiding the person who
created the PR.
David
On 3/03/2022 10:45 pm, David Holmes wrote:
Hi Julian,
On 3/03/2022 10:33 pm, Jules W. wrote:
Hi all,
A new PR that adds methods to PriorityQueue was created some time ago at
https://github.com/openjdk/jd
Hi Julian,
On 3/03/2022 10:33 pm, Jules W. wrote:
Hi all,
A new PR that adds methods to PriorityQueue was created some time ago at
https://github.com/openjdk/jdk/pull/6938 but has no corresponding issue. As
I'm not too familiar with this part of the JDK I'm querying this mailing
list for anyone
I believe the linked sequence of messages refer to the addition of a
PriorityQueue constructor only taking a Comparator which was does appear in
Java 1.8. Did you have a link to something regarding the a constructor
taking a Collection and a Comparator (2 arguments)?
On Thu, May 14, 2015 at 2:08
On May 15, 2015, at 4:04 PM, Chris Hegarty wrote:
> And/Or should PriorityQueue override addAll and provide a more performant
> implementation for common Collection types ( just like the constructor )?
>
It should be possible to improve this case too: create a new array,
appropriately sized,
>
> I was initially confused by this because it seems to attribute the
> algorithmic difference to Comparable vs Comparator, which doesn't make any
> sense
That's exactly what threw me off as well, but I didn't bother checking
(doh!). Anyway, I think the upside is we're all in agreement now that
Yes, this is very subtle, and Brett mentioned it (albeit somewhat obliquely) in
an email on jdk9-dev: [1]
If someone needs to make a
heap and their data is Comparable, the corresponding constructor gives a
O(n) runtime. If their data uses a Comparator, the corresponding runtime
(using addAll)
Whoops, I believe you're right -- I completely overlooked that as well :(
On Fri, May 15, 2015 at 12:40 PM, Paul Sandoz
wrote:
>
> On May 15, 2015, at 6:15 PM, Louis Wasserman wrote:
>
> > http://lcm.csa.iisc.ernet.in/dsa/node139.html suggests an algorithm for
> > heapifying an unsorted array i
On May 15, 2015, at 6:15 PM, Louis Wasserman wrote:
> http://lcm.csa.iisc.ernet.in/dsa/node139.html suggests an algorithm for
> heapifying an unsorted array in O(n), corroborated elsewhere at
> http://courses.csail.mit.edu/6.006/fall10/handouts/recitation10-8.pdf .
> Any particular reason we can
Constructor has advantage in knowing it's working with a clean slate;
addAll could check for that too, I suppose, and at least skip things like
modCount increments. As a general rule of thumb, I always prefer to have
dedicated methods for batch/bulk operations since you have more context to
potent
And/Or should PriorityQueue override addAll and provide a more
performant implementation for common Collection types ( just like the
constructor )?
-Chris.
On 15/05/15 14:20, Vitaly Davidovich wrote:
Paul,
I don't think you're missing anything obvious (unless I am as well :)).
What you wrote
On May 15, 2015, at 3:20 PM, Vitaly Davidovich wrote:
> Paul,
>
> I don't think you're missing anything obvious (unless I am as well :)). What
> you wrote is basically what I meant by creating static helper method in
> Brett's own code that does exactly what you wrote. The asymptotic comple
Paul,
I don't think you're missing anything obvious (unless I am as well :)).
What you wrote is basically what I meant by creating static helper method
in Brett's own code that does exactly what you wrote. The asymptotic
complexity will be nlogn in both cases, but the constant factor will be
diff
On May 14, 2015, at 8:17 AM, Brett Bernstein wrote:
> I believe the linked sequence of messages refer to the addition of a
> PriorityQueue constructor only taking a Comparator which was does appear in
> Java 1.8. Did you have a link to something regarding the a constructor
> taking a Collection
> You may have trouble finding someone with the same enthusiasm for this
> constructor as yourself.
This probably applies to many data structures that have specific (and
rare) applications. A priority queue that takes a custom comparator
seems like a pretty frequent (algorithmic) use case to me,
On Wed, May 13, 2015 at 11:17 PM, Brett Bernstein wrote:
> I believe the linked sequence of messages refer to the addition of a
> PriorityQueue constructor only taking a Comparator which was does appear in
> Java 1.8. Did you have a link to something regarding the a constructor
> taking a Collec
Software is hard.
We tried and got stuck, although the former effort can be revived.
RFR : 6799426 : (xs) Add constructor PriorityQueue(Comparator)
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019124.html
On Wed, May 13, 2015 at 10:17 PM, Brett Bernstein wrote:
> To whom this
On Fri, May 7, 2010 at 03:47, David Holmes wrote:
> Hi Chris,
>
> Chris Hegarty said the following on 05/07/10 19:55:
>>
>> Hi David, Martin,
>>
>> Thanks for filing the bug David, I'll just add a link to the email thread
>> in the archive for reference.
>
> Thanks.
>
>> Just one minor observation
On 07/05/2010 11:47, David Holmes wrote:
Hi Chris,
Chris Hegarty said the following on 05/07/10 19:55:
Hi David, Martin,
Thanks for filing the bug David, I'll just add a link to the email
thread in the archive for reference.
Thanks.
Just one minor observation while reviewing the changes. I
Hi Chris,
Chris Hegarty said the following on 05/07/10 19:55:
Hi David, Martin,
Thanks for filing the bug David, I'll just add a link to the email
thread in the archive for reference.
Thanks.
Just one minor observation while reviewing the changes. Is it necessary
for initFromPriorityQueue
Hi David, Martin,
Thanks for filing the bug David, I'll just add a link to the email
thread in the archive for reference.
Just one minor observation while reviewing the changes. Is it necessary
for initFromPriorityQueue to call initFromCollection ( in the case where
you're given a PriorityQu
Hi Martin,
CR 6950540 filed. (Chris might want to tidy it up :) )
Changes look okay to me.
Thanks,
David
Martin Buchholz said the following on 05/07/10 12:19:
David,
Of course you're right.
I didn't realize that the hole was one-element nulls.
(Why is software always 10 times harder than yo
David,
Of course you're right.
I didn't realize that the hole was one-element nulls.
(Why is software always 10 times harder than you'd think?)
Updated webrev, with lots more tests for corner cases.
I still need a bug filed in bugtraq.
Martin
On Thu, May 6, 2010 at 16:53, David Holmes wrote:
Hi Martin,
Martin Buchholz said the following on 05/07/10 09:13:
On Thu, May 6, 2010 at 15:58, David Holmes wrote:
Fix:
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/PriorityQueueConstructor/
I'm not sure this is necessarily the right fix. It seems to me that
incidental nulls will be c
On Thu, May 6, 2010 at 15:58, David Holmes wrote:
>> Fix:
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/PriorityQueueConstructor/
>
> I'm not sure this is necessarily the right fix. It seems to me that
> incidental nulls will be caught in many/most cases by the sorting code for
> colle
Martin,
Martin Buchholz said the following on 05/07/10 08:24:
This is a bug report with fix.
(Chris, please file a bug)
Summary: PriorityQueue(collection) should throw NPE if collection
contains a null
Description:
PriorityQueue spec says:
"A priority queue does not permit {...@code null} ele
30 matches
Mail list logo