Looks ok to me.
/Erik
On 2018-11-27 05:52, Volker Simonis wrote:
Hi,
can I please have a review for the following trivial change which
handles the absence of Xrandr more generically:
http://cr.openjdk.java.net/~simonis/webrevs/2018/8214343/
https://bugs.openjdk.java.net/browse/JDK-8214343
Hello Phil.
I don't have any concern about this fix.
I'm thinking why initial programmer used FT_LOAD_RENDER instead of
FT_LOAD_DEFAULT.
On my testing, this fix was fine for me.
Ichiroh Takiguchi
On 2018-11-27 03:59, Philip Race wrote:
It seems fine to me. What is your concern when you say
+1
-phil.
On 11/27/18 8:45 AM, Erik Joelsson wrote:
Looks ok to me.
/Erik
On 2018-11-27 05:52, Volker Simonis wrote:
Hi,
can I please have a review for the following trivial change which
handles the absence of Xrandr more generically:
On 11/27/18 9:36 AM, Ichiroh Takiguchi wrote:
Hello Phil.
I don't have any concern about this fix.
I'm thinking why initial programmer used FT_LOAD_RENDER instead of
FT_LOAD_DEFAULT.
Probably that this was what we wanted to do in almost all cases and it has
now turned out to be untrue ..
I agree. Is casting to int actually the right thing ? Definitely not always
Looking here (for example)
1042 int len;
1060 len = (int)(strlen(vendor) + 1 + strlen(renderer) + 1 +
1+strlen(version)+1 + 1);
we use len ONLY as an argument to malloc
1061 pAdapterId = malloc(len);]
So
Hello Phil.
Do you need me to push this ?
Yes, if possible.
Currently, no sponsor is assigned for this issue.
Ichiroh Takiguchi
On 2018-11-28 05:43, Phil Race wrote:
On 11/27/18 9:36 AM, Ichiroh Takiguchi wrote:
Hello Phil.
I don't have any concern about this fix.
I'm thinking why initial
Oh .. there's no regression test. If you can't find one then I think you
can write one relatively easily by selecting the known font - MS Mincho,
making sure we are on Windows (don't try it on Mac even if the font
exists), draw the text to a BufferedImage in plain / regular style.
Repeat to a
Hi Phil,
sorry I didn't wanted to overrule you but after I didn't heard back
from you for almost a week (an out of office mail could have been
helpful) and after I got 5 other reviews I decided to finally fix the
build error on AIX.
On Mon, Nov 26, 2018 at 9:35 PM Phil Race wrote:
>
> Well .. I
Hi Phil,
To reduce the scope, I have created a new webrev, which addresses only warnings
on Linux platform.
Warnings for other platforms will be addressed in separate bugs.
Here is the new webrev: http://cr.openjdk.java.net/~kaddepalli/8074824/webrev02/
For your reference, I'm attaching
Hi Phil,
> I proposed 2 small fixes for jdk12... still to be done, as better
> solutions are not yet ready and I am completely overbusy on testing Java
> Sorting algorithms.
>
> Maybe I will give up fixing the native renderer, for these reasons:
> - stdlib qsort implementation and performance
On 19.11.2018 09:34, Simon DEVINEAU wrote:
We are gonna contact Red Hat in parallel but, as already said, some
tickets seem to show that is not only applicative problem but also jvm.
If you're seeing an issue with a third party OpenJDK build, please
contact the provider of that build for a
I normally do not comment on component source code changes, but I glanced
through this and noticed that a lot of size_t values are casted to int, in
situations where a size_t is expected, like SAFE_ALLOC or so. Perhaps it would
be better to change the argument to those functions, rather than to
Hi Magnus,
Thanks for taking a look. I was wanting to change the SAFE_ALLOC definition,
but since that file is in java.base, I was not sure of changing it.
Krishna
From: Magnus Ihse Bursie
Sent: Tuesday, November 27, 2018 6:52 PM
To: Krishna Addepalli
Cc: Philip Race ;
Hi,
can I please have a review for the following trivial change which
handles the absence of Xrandr more generically:
http://cr.openjdk.java.net/~simonis/webrevs/2018/8214343/
https://bugs.openjdk.java.net/browse/JDK-8214343
Change JDK-8213944 fixed the build on AIX (which has no Xrandr) by
> 27 nov. 2018 kl. 14:32 skrev Krishna Addepalli :
>
> Hi Magnus,
>
> Thanks for taking a look. I was wanting to change the SAFE_ALLOC definition,
> but since that file is in java.base, I was not sure of changing it.
If you do change it, does it trigger compilation warnings/errors elsewhere?
Looks good Volker. I agree, NO_XRANDR is reasonable and better than HAVE_XRANDR.
I have to say, the amount of work this took is insane for the size of
the problem involved.
Cheers, Thomas
On Tue, Nov 27, 2018 at 2:54 PM Volker Simonis wrote:
>
> Hi,
>
> can I please have a review for the
16 matches
Mail list logo
