On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato wrote:
> Hi,
>
> Please review the changes for upgrading the CLDR data to version 38. The vast
> majority of the changes are simply the changes in CLDR upstream, and others
> are mainly test changes due to the locale data change.
Looks like the gen
On Tue, 17 Nov 2020 22:21:18 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> Jim Laskey has up
On Tue, 17 Nov 2020 23:00:26 GMT, Jonathan Gibbons wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix whitespace issues
>
> There seems to be much more here than there needs to be.
>
> If the issue is just
Hi,
Please review the changes for upgrading the CLDR data to version 38. The vast
majority of the changes are simply the changes in CLDR upstream, and others are
mainly test changes due to the locale data change.
-
Commit messages:
- Updated the version in `cldr.md` files
- Merge
An honest question,
why do we need so many interfaces for the different categories of
RandomGenerator ?
My fear is that we are encoding the state of our knowledge of the different
kinds of random generators now so it will not be pretty in the future when new
categories of random generator are d
On Mon, 16 Nov 2020 12:44:08 GMT, Magnus Ihse Bursie wrote:
>> Currently, to use the javac server, a horrendously long command line option
>> is created, looking like this: `--server:portfile=> portfile>:sjavac=`, where the sjavac command has
>> had all spaces replaced by %20. Since Project Jig
On Tue, 17 Nov 2020 22:12:19 GMT, Jim Laskey wrote:
>> @kevinrushforth What is the recommended approach to remove the doc
>> edit/commit?
>
> javadoc can be found at
> http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
Presuming your master branch
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
Jim Laskey has updated the pull request with a new target base due to a merge
On Tue, 17 Nov 2020 21:59:04 GMT, Jim Laskey wrote:
>>> my local branch seems to have the right sources for doc
>>
>> Maybe, but your branch on GitHub does not.
>
> @kevinrushforth What is the recommended approach to remove the doc
> edit/commit?
javadoc can be found at
http://cr.openjdk.java
On Tue, 17 Nov 2020 21:10:48 GMT, Kevin Rushforth wrote:
>> @erikj79 my local branch seems to have the right sources for doc
>
>> my local branch seems to have the right sources for doc
>
> Maybe, but your branch on GitHub does not.
@kevinrushforth What is the recommended approach to remove the
On 2020-11-17 19:08, Philip Race wrote:
So maybe the actual *usage* of C++11 features slows it down.
I found this :-
https://stackoverflow.com/questions/34179434/is-compiling-with-c11-way-slower-than-with-c98
I really did not even think to measure the build time and I don't
think there's
On Tue, 17 Nov 2020 21:33:13 GMT, Magnus Ihse Bursie wrote:
>>> my local branch seems to have the right sources for doc
>>
>> Maybe, but your branch on GitHub does not.
>
> This PR looks seriously messed up:
>
> JimLaskey added 30 commits on Oct 9
> @JimLaskey
> 8248862: Implement Enhanced Pseu
On Tue, 17 Nov 2020 21:10:48 GMT, Kevin Rushforth wrote:
>> @erikj79 my local branch seems to have the right sources for doc
>
>> my local branch seems to have the right sources for doc
>
> Maybe, but your branch on GitHub does not.
This PR looks seriously messed up:
JimLaskey added 30 commits
On Tue, 17 Nov 2020 21:04:08 GMT, Erik Joelsson wrote:
> In Xcode 12.2, the framework JavaVM was removed in the sysroot and all
> (relevant) frameworks inside were just moved one step up so we still find
> things like JavaNativeFoundation and JavaRuntimeSupport. There is however one
> test tha
On Tue, 17 Nov 2020 20:56:52 GMT, Jim Laskey wrote:
> my local branch seems to have the right sources for doc
Maybe, but your branch on GitHub does not.
-
PR: https://git.openjdk.java.net/jdk/pull/1273
On Tue, 17 Nov 2020 21:04:08 GMT, Erik Joelsson wrote:
> In Xcode 12.2, the framework JavaVM was removed in the sysroot and all
> (relevant) frameworks inside were just moved one step up so we still find
> things like JavaNativeFoundation and JavaRuntimeSupport. There is however one
> test tha
In Xcode 12.2, the framework JavaVM was removed in the sysroot and all
(relevant) frameworks inside were just moved one step up so we still find
things like JavaNativeFoundation and JavaRuntimeSupport. There is however one
test that currently links explicitly to JavaVM, which fails the build. Th
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
Jim Laskey has updated the pull request incrementally with one additional
co
On Tue, 17 Nov 2020 20:15:34 GMT, Erik Joelsson wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> It looks like
On Tue, 17 Nov 2020 20:15:34 GMT, Erik Joelsson wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> It looks like
On Tue, 17 Nov 2020 19:58:47 GMT, Jim Laskey wrote:
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
It looks like you have
On Tue, 17 Nov 2020 00:31:24 GMT, Igor Ignatyev wrote:
> Hi all,
>
>
> [8256414](https://bugs.openjdk.java.net/browse/JDK-8256414) / #1233 added
> similar profile to submit workflow, this patch defines `linux-x64-optimized`
> profile in jib-profile so it can be used by mach5 and added to tie
This PR is to introduce a new random number API for the JDK. The primary API is
found in RandomGenerator and RandomGeneratorFactory. Further description can be
found in the JEP https://openjdk.java.net/jeps/356 .
-
Commit messages:
- 8248862: Implement Enhanced Pseudo-Random Number
On Tue, 17 Nov 2020 19:52:49 GMT, Erik Joelsson wrote:
>> Igor Ignatyev has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> build only hotspot for optimized
>
> Marked as reviewed by erikj (Reviewer).
folks, thanks for your reviews.
--
On Tue, 17 Nov 2020 19:31:16 GMT, Igor Ignatyev wrote:
>> Hi all,
>>
>>
>> [8256414](https://bugs.openjdk.java.net/browse/JDK-8256414) / #1233 added
>> similar profile to submit workflow, this patch defines `linux-x64-optimized`
>> profile in jib-profile so it can be used by mach5 and added
> Hi all,
>
>
> [8256414](https://bugs.openjdk.java.net/browse/JDK-8256414) / #1233 added
> similar profile to submit workflow, this patch defines `linux-x64-optimized`
> profile in jib-profile so it can be used by mach5 and added to tier1?
>
> Thanks
> -- Igor
>
> cc-ing @dcubed-ojdk
Igor
On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth wrote:
>> Change looks ok from a build point of view, but I can't comment on the
>> validity and implications of using this key.
>
> I ran a 3D lighting test that is designed to be a GPU stress test. It's a
> worst case, to be sure, but it take
On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth wrote:
>> Change looks ok from a build point of view, but I can't comment on the
>> validity and implications of using this key.
>
> I ran a 3D lighting test that is designed to be a GPU stress test. It's a
> worst case, to be sure, but it take
On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth wrote:
>> Change looks ok from a build point of view, but I can't comment on the
>> validity and implications of using this key.
>
> I ran a 3D lighting test that is designed to be a GPU stress test. It's a
> worst case, to be sure, but it take
So maybe the actual *usage* of C++11 features slows it down.
I found this :-
https://stackoverflow.com/questions/34179434/is-compiling-with-c11-way-slower-than-with-c98
I really did not even think to measure the build time and I don't
think there's any JDK build parallelism in building a specifi
* Philip Race:
> There is more code in the newer version but not 4 times as much !
> Harfbuzz now requires c++11 features (-std=c++11)
> Possibly the C++ compiler you are using (you don't mention platform) is
> slower in this mode.
It's GCC 8 on Debian buster, which defaults to C++14. And it's
There is more code in the newer version but not 4 times as much !
Harfbuzz now requires c++11 features (-std=c++11)
Possibly the C++ compiler you are using (you don't mention platform) is
slower in this mode.
-phil.
On 11/17/20, 9:01 AM, Florian Weimer wrote:
* Phil Race:
This upgrades JDK
* Phil Race:
> This upgrades JDK to import the current 2.7.2 version of harfbuzz -
> an OpenType text shaping library
>
> https://bugs.openjdk.java.net/browse/JDK-8247872
>
> This has passed building and headless and headful automated tests on
> all platforms.
Is it just me, or does the new Harfb
On Wed, 11 Nov 2020 20:13:55 GMT, Magnus Ihse Bursie wrote:
> The time has come to actually turn on the support for reproducible builds by
> default in the jib profiles.
This pull request has now been integrated.
Changeset: c255b18c
Author:Magnus Ihse Bursie
URL: https://git.openjdk
On Tue, 17 Nov 2020 14:37:22 GMT, Magnus Ihse Bursie wrote:
>> The time has come to actually turn on the support for reproducible builds by
>> default in the jib profiles.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one
> additional commit since the last revision:
>
> The time has come to actually turn on the support for reproducible builds by
> default in the jib profiles.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Change formatting as requested
-
Changes:
- all: http
On Wed, 11 Nov 2020 20:13:55 GMT, Magnus Ihse Bursie wrote:
> The time has come to actually turn on the support for reproducible builds by
> default in the jib profiles.
Due to feedback from Erik in a private discussion, I have now changed the
implementation so that reproducible builds are onl
> The time has come to actually turn on the support for reproducible builds by
> default in the jib profiles.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase.
There is a long-standing bug with the intent to remove optimized builds
(https://bugs.openjdk.java.net/browse/JDK-8183287). Given that it does
not seem that popular, I wonder if it really is necessary to burden the
submit workflow (and tier1 testing, as requested in
https://bugs.openjdk.java
On Tue, 17 Nov 2020 00:31:24 GMT, Igor Ignatyev wrote:
> Hi all,
>
>
> [8256414](https://bugs.openjdk.java.net/browse/JDK-8256414) / #1233 added
> similar profile to submit workflow, this patch defines `linux-x64-optimized`
> profile in jib-profile so it can be used by mach5 and added to tie
I see now that this PR was already integrated.
I think that any change to the submit workflow (if they add additional
testing, and not just fix bugs) is a non-trivial change which needs
careful consideration.
We have already had a huge influx of additional build platforms in a
very short tim
Hi Igor,
There is a long-standing bug with the intent to remove optimized builds
(https://bugs.openjdk.java.net/browse/JDK-8183287). Given that it does
not seem that popular, I wonder if it really is necessary to burden the
submit workflow (and tier1 testing, as requested in
https://bugs.open
On Mon, 16 Nov 2020 13:51:29 GMT, Erik Joelsson wrote:
>> We should be more explicit about OS and compiler versions used in the GitHub
>> Actions builds, to avoid problems caused by unexpected changes to the
>> defaults. This patch changes the OS and GCC versions used from ubuntu-latest
>> (cu
43 matches
Mail list logo
