On Fri, 10 May 2024 01:25:45 GMT, xiaotaonan wrote:
>> Clean up non-standard use of /// comments in `java.base`
>
> @mdinacci @hns @landonf
Hello @xiaotaonan, I see that you have several PRs of similar nature that have
been opened in the past day or two. I would recommend taking a look at the
On Fri, 10 May 2024 04:55:21 GMT, Chen Liang wrote:
>> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's
>> LambdaForm method type parameters. Since they are distinct from those of
>> Linkers, they are now tracked and generated separately. It seems that no
>> proper
On Thu, 9 May 2024 00:49:43 GMT, xiaotaonan wrote:
> …ersion
>
> Release Note: System Property for Java SE Specification Maintenance Version
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/19149
On Wed, 8 May 2024 20:37:28 GMT, Vladimir Yaroslavskiy wrote:
>> Hi Vladimir (@iaroslavski),
>>
>> Please see the data below.
>>
>> Thanks,
>> Vamsi
>>
>> name | builder | size | mode | count | score
>> -- | -- | -- | -- | -- | --
>> b01 | RANDOM | 600 | avg | 325677 | 6.764
>> b01 | RANDOM |
Making sure `restoreEcho` correctly reflects the state in the shutdown thread,
which differs from the application's thread that issues the `readPassword()`
method.
-
Commit messages:
- initial commit
Changes: https://git.openjdk.org/jdk/pull/19184/files
Webrev:
On Tue, 12 Dec 2023 22:21:29 GMT, Joe Darcy wrote:
>> Vicente Romero has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fixing comment
>
> As the core reflection code will encounter record classes compiled before and
> after the javac
On Mon, 29 Apr 2024 20:17:29 GMT, Joe Darcy wrote:
>> Vicente Romero has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> minor refactoring
>
> test/jdk/java/lang/reflect/records/R10.jcod line 1:
>
>> 1: class R10 {
>
> Please add some
> Reflection is not retrieving generic type information for mandated
> parameters. This is a known issue which has been explicitly stated in the API
> of some reflection methods. Fix for
> [JDK-8292275](https://bugs.openjdk.org/browse/JDK-8292275) made the
> parameters of compact constructors
On Fri, 10 May 2024 04:55:21 GMT, Chen Liang wrote:
>> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's
>> LambdaForm method type parameters. Since they are distinct from those of
>> Linkers, they are now tracked and generated separately. It seems that no
>> proper
On Fri, 10 May 2024 16:10:29 GMT, Maurizio Cimadamore
wrote:
>> Consider this layout:
>>
>>
>> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
>> MemoryLayout.sequenceLayout(10, JAVA_INT));
>>
>>
>> And the corresponding offset handle:
>>
>>
>> MethodHandle offsetHandle =
I'm not convinced this helps.
The isAlive() spec says:
"A thread is alive if it has been started and has not yet terminated."
Clearly an object is reachable if it can be accessed by a thread that will
be started in the future. Is that part of a "potential continuing
computation from any live
On Fri, 10 May 2024 07:57:40 GMT, Alan Bateman wrote:
> In preparation for JEP 471 and JEP 472, provide access to the initial value
> of System.err from JavaLangAccess. The initial value of System.in is already
> exposed to code in java.base with this shared secret.
Marked as reviewed by
On Fri, 10 May 2024 10:58:42 GMT, Alan Bateman wrote:
> There aren't any API or implementations changes in third preview but the JEP
> number/title needs to be bumped for the javadoc page.
Marked as reviewed by mcimadamore (Reviewer).
-
PR Review:
On Fri, 10 May 2024 16:16:18 GMT, Daniel Jeliński wrote:
>> Replace the custom unsigned divide / remainder functions with the
>> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>>
>> No new tests. Existing tier1-3 tests continue to pass.
>>
>> I added a new set of divide
On Fri, 10 May 2024 14:54:10 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 61:
>>
>>> 59: @Override
>>> 60: public JdkConsole println(Object obj) {
>>> 61: pw.println(obj);
>>
>> Are these `println(...)` and `print(...)` methods
On Fri, 10 May 2024 07:57:40 GMT, Alan Bateman wrote:
> In preparation for JEP 471 and JEP 472, provide access to the initial value
> of System.err from JavaLangAccess. The initial value of System.in is already
> exposed to code in java.base with this shared secret.
+1
-
Marked
On Tue, 7 May 2024 15:42:23 GMT, Maurizio Cimadamore
wrote:
> This PR fixes an issue that has crept into the FFM API implementation.
>
> From very early stages, the FFM API used to disable the alignment check on
> nested layout elements, in favor of an alignment check against the memory
>
On Fri, 10 May 2024 10:58:42 GMT, Alan Bateman wrote:
> There aren't any API or implementations changes in third preview but the JEP
> number/title needs to be bumped for the javadoc page.
Marked as reviewed by bpb (Reviewer).
-
PR Review:
On Wed, 8 May 2024 16:39:16 GMT, Maurizio Cimadamore
wrote:
>> This PR fixes an issue that has crept into the FFM API implementation.
>>
>> From very early stages, the FFM API used to disable the alignment check on
>> nested layout elements, in favor of an alignment check against the memory
On Wed, 8 May 2024 20:21:50 GMT, Naoto Sato wrote:
> In order to enlighten users to not depend on a particular version of the
> locale data, putting a note into the JDK vs. CLDR version chart would be
> appropriate.
This pull request has now been integrated.
Changeset: 65abf24f
Author:
> Replace the custom unsigned divide / remainder functions with the
> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>
> No new tests. Existing tier1-3 tests continue to pass.
>
> I added a new set of divide benchmarks. Results in thread.
>
> I also removed the BigDecimal.toString
> Consider this layout:
>
>
> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
> MemoryLayout.sequenceLayout(10, JAVA_INT));
>
>
> And the corresponding offset handle:
>
>
> MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(),
>
On Sat, 27 Apr 2024 11:52:18 GMT, Viktor Klang wrote:
>> This is an attempt to be more clear about recommendations on Lock usage.
>
> Viktor Klang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update
>
On Thu, 9 May 2024 02:09:50 GMT, xiaotaonan wrote:
> Clean up non-standard use of /// comments in `java.base`
This PR is premature.
Until JEP 467 is integrated, there is nothing special about `///` comments, and
the compiler does not report on non-standard use.
There is a Draft PR for this
On Fri, 10 May 2024 15:32:07 GMT, Jan Lahoda wrote:
>> When JLine reads a line, there may be a prompt provided. However, JLine will
>> not interpret the prompt literally, it will handle `%` specially. As a
>> consequence, doing:
>>
>> System.console().readLine("%%s");
>>
>>
>> will not
> When JLine reads a line, there may be a prompt provided. However, JLine will
> not interpret the prompt literally, it will handle `%` specially. As a
> consequence, doing:
>
> System.console().readLine("%%s");
>
>
> will not print `%s`, as first `String.format` is used, which will convert
On Fri, 10 May 2024 09:22:39 GMT, serhiysachkov wrote:
>> Calendar.add() tests that describe its behavior.
>
> serhiysachkov has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8331646 fixing typo
A bit late but the descriptions of the
On Fri, 10 May 2024 11:00:55 GMT, Jan Lahoda wrote:
>> When JLine reads a line, there may be a prompt provided. However, JLine will
>> not interpret the prompt literally, it will handle `%` specially. As a
>> consequence, doing:
>>
>> System.console().readLine("%%s");
>>
>>
>> will not
> Consider this layout:
>
>
> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
> MemoryLayout.sequenceLayout(10, JAVA_INT));
>
>
> And the corresponding offset handle:
>
>
> MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(),
>
On Fri, 10 May 2024 04:55:21 GMT, Chen Liang wrote:
>> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's
>> LambdaForm method type parameters. Since they are distinct from those of
>> Linkers, they are now tracked and generated separately. It seems that no
>> proper
On Fri, 3 May 2024 10:31:14 GMT, serhiysachkov wrote:
> Calendar.add() tests that describe its behavior.
This pull request has now been integrated.
Changeset: d11e70ad
Author:Serhiy Sachkov
Committer: Mahendra Chhipa
URL:
On Wed, 1 May 2024 10:03:25 GMT, Pavel Rappo wrote:
>> The grammar rules prefer "that" because it is a restrictive clause, even
>> though "which" might sound better. See for example:
>> https://owl.purdue.edu/owl/general_writing/grammar/that_vs_which.html
>
>> The grammar rules prefer "that"
On Fri, 10 May 2024 07:45:02 GMT, Jaikiran Pai wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix System.console().readln(null) in jshell
>>
>> Without it, jshell hangs on me. Will think of a test.
>
>
Thanks for that reference.
I verified that when the fix in JDK-8303866 is reverted, this bug is
reproducible again.
So I've resolved JDK-8298530 as a duplicate of JDK-8303866.
-Archie
On Thu, May 9, 2024 at 9:51 PM Jaikiran Pai
wrote:
> I think this might have been addressed in mainline
> Consider this layout:
>
>
> MemoryLayout SEQ = MemoryLayout.sequenceLayout(5,
> MemoryLayout.sequenceLayout(10, JAVA_INT));
>
>
> And the corresponding offset handle:
>
>
> MethodHandle offsetHandle = SEQ.offsetHandle(PathElement.sequenceLayout(),
>
On Mon, 29 Apr 2024 11:48:08 GMT, Chen Liang wrote:
>> Primarily offering this PR for discussion, as Throwables throwing exceptions
>> on toString(), getLocalizedMessage(), or getMessage() seems like a rather
>> unreasonable thing to do.
>>
>> Nevertheless, there is some things we can do, as
On Sun, 28 Apr 2024 09:54:34 GMT, Viktor Klang wrote:
> Primarily offering this PR for discussion, as Throwables throwing exceptions
> on toString(), getLocalizedMessage(), or getMessage() seems like a rather
> unreasonable thing to do.
>
> Nevertheless, there is some things we can do, as
On Sun, 28 Apr 2024 09:54:34 GMT, Viktor Klang wrote:
> Primarily offering this PR for discussion, as Throwables throwing exceptions
> on toString(), getLocalizedMessage(), or getMessage() seems like a rather
> unreasonable thing to do.
>
> Nevertheless, there is some things we can do, as
Primarily offering this PR for discussion, as Throwables throwing exceptions on
toString(), getLocalizedMessage(), or getMessage() seems like a rather
unreasonable thing to do.
Nevertheless, there is some things we can do, as witnessed in this PR.
-
Commit messages:
-
On Wed, 1 May 2024 10:03:25 GMT, Pavel Rappo wrote:
>> The grammar rules prefer "that" because it is a restrictive clause, even
>> though "which" might sound better. See for example:
>> https://owl.purdue.edu/owl/general_writing/grammar/that_vs_which.html
>
>> The grammar rules prefer "that"
On Fri, 10 May 2024 07:57:40 GMT, Alan Bateman wrote:
> In preparation for JEP 471 and JEP 472, provide access to the initial value
> of System.err from JavaLangAccess. The initial value of System.in is already
> exposed to code in java.base with this shared secret.
The change looks OK to me.
On Fri, 10 May 2024 10:58:42 GMT, Alan Bateman wrote:
> There aren't any API or implementations changes in third preview but the JEP
> number/title needs to be bumped for the javadoc page.
Marked as reviewed by jpai (Reviewer).
-
PR Review:
Hello Archie,
Archie Cobbs wrote on 09.05.2024 20:09 (GMT +02:00):
FWIW when I run the test case in that bug on the latest JDK 23 (jdk-23+21-110-g0a4eeeaa3c6), it does not report any exception.
So this bug may have gotten fixed by recent changes and just needs to be closed... ?
Interesting
> Replace the custom unsigned divide / remainder functions with the
> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>
> No new tests. Existing tier1-3 tests continue to pass.
>
> I added a new set of divide benchmarks. Results in thread.
>
> I also removed the BigDecimal.toString
On Fri, 10 May 2024 13:39:42 GMT, Daniel Jeliński wrote:
>> Replace the custom unsigned divide / remainder functions with the
>> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>>
>> No new tests. Existing tier1-3 tests continue to pass.
>>
>> I added a new set of divide
On Fri, 10 May 2024 13:39:42 GMT, Daniel Jeliński wrote:
>> Replace the custom unsigned divide / remainder functions with the
>> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>>
>> No new tests. Existing tier1-3 tests continue to pass.
>>
>> I added a new set of divide
On Fri, 10 May 2024 11:44:14 GMT, Doug Lea wrote:
>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1412:
>>
>>> 1410: if (stalled)
>>> 1411: Thread.onSpinWait();
>>> 1412: stalled = true;
>>
In preparation for JEP 471 and JEP 472, provide access to the initial value of
System.err from JavaLangAccess. The initial value of System.in is already
exposed to code in java.base with this shared secret.
-
Commit messages:
- Initial commit
Changes:
There are any API or implementations changes in third preview but the JEP
number/title needs to be bumped for the javadoc page.
-
Commit messages:
- Initial commit
Changes: https://git.openjdk.org/jdk/pull/19175/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=19175=00
On Fri, 10 May 2024 08:45:32 GMT, Daniel Jeliński wrote:
>> Replace the custom unsigned divide / remainder functions with the
>> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>>
>> No new tests. Existing tier1-3 tests continue to pass.
>>
>> I added a new set of divide
On Fri, 10 May 2024 12:09:20 GMT, Doug Lea wrote:
>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2167:
>>
>>> 2165: }
>>> 2166: }
>>> 2167: return stat;
>>
>> @DougLea Since `stat` is a local, and is only written to once per branch it
>>
On Fri, 10 May 2024 07:34:40 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 10 May 2024 08:30:24 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 10 May 2024 08:15:59 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 10 May 2024 08:11:52 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 10 May 2024 08:08:05 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 10 May 2024 08:04:27 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 10 May 2024 08:02:23 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
On Fri, 10 May 2024 07:35:17 GMT, Viktor Klang wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments
> When JLine reads a line, there may be a prompt provided. However, JLine will
> not interpret the prompt literally, it will handle `%` specially. As a
> consequence, doing:
>
> System.console().readLine("%%s");
>
>
> will not print `%s`, as first `String.format` is used, which will convert
On Fri, 10 May 2024 07:23:38 GMT, Per Minborg wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix System.console().readln(null) in jshell
>>
>> Without it, jshell hangs on me. Will think of a test.
>
>
On Mon, 6 May 2024 20:48:05 GMT, Chen Liang wrote:
> A peek into TypeKind during the research for #19105 reveals that TypeKind has
> a few issues:
> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to
> use "newarray code"
> 2. `fromDescriptor` can throw IOOBE if the
> Please review this PR which introduces the `java.io.IO` top-level class and
> three methods to `java.io.Console` for [Implicitly Declared Classes and
> Instance Main Methods (Third Preview)].
>
> This PR has been obtained as `git merge --squash` of a now obsolete [draft
> PR].
>
>
On Thu, 9 May 2024 21:15:31 GMT, Chen Liang wrote:
>> A peek into TypeKind during the research for #19105 reveals that TypeKind
>> has a few issues:
>> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to
>> use "newarray code"
>> 2. `fromDescriptor` can throw IOOBE if
On Fri, 10 May 2024 07:29:42 GMT, Per Minborg wrote:
>> If the sole constructor of a class is private, not only does it preclude the
>> class from being instantiated, but it also precludes the class from being
>> extended. Mind you, even with the sole private constructor, both
>>
> Calendar.add() tests that describe its behavior.
serhiysachkov has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8331646 fixing typo
-
Changes:
- all: https://git.openjdk.org/jdk/pull/19082/files
- new:
On Thu, 9 May 2024 19:48:53 GMT, Sonia Zaldana Calles
wrote:
>> Pre-existing: Man, I cannot grok the complex return code handling, tbh.
>>
>> We have the local `ret` variable holding a return code. We also hand codes
>> to CHECK_EXCEPTION_LEAVE as macro argument. But we don't hand codes to
> This PR suggests refactoring the implementation classes of java.lang.constant
> into a new package jdk.internal.constant to enable sharing some trusted
> static factory methods with users elsewhere in java.base, such as
> java.lang.invoke and java.lang.classfile. The refactoring also adds
> Replace the custom unsigned divide / remainder functions with the
> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>
> No new tests. Existing tier1-3 tests continue to pass.
>
> I added a new set of divide benchmarks. Results in thread.
>
> I also removed the BigDecimal.toString
On Thu, 9 May 2024 19:52:12 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the
On Thu, 9 May 2024 19:48:53 GMT, Sonia Zaldana Calles
wrote:
> > This may be food for another RFE, to keep this patch minimal. But a good
> > solution, to me, would be like this:
> >
> > * have the same logic for return codes (1 = error, 0 = success) to ease
> > understanding
> > * have
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Thu, 9 May 2024 13:34:16 GMT, Claes Redestad wrote:
>> A rather large startup regression was introduced in 23-b13 from
>> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
>> been dealt with as enhancements such as
>>
On Wed, 8 May 2024 14:53:05 GMT, Claes Redestad wrote:
> A rather large startup regression was introduced in 23-b13 from
> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
> been dealt with as enhancements such as
>
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Thu, 9 May 2024 21:15:31 GMT, Chen Liang wrote:
>> A peek into TypeKind during the research for #19105 reveals that TypeKind
>> has a few issues:
>> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to
>> use "newarray code"
>> 2. `fromDescriptor` can throw IOOBE if
On Thu, 9 May 2024 21:15:31 GMT, Chen Liang wrote:
>> A peek into TypeKind during the research for #19105 reveals that TypeKind
>> has a few issues:
>> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to
>> use "newarray code"
>> 2. `fromDescriptor` can throw IOOBE if
On Thu, 9 May 2024 18:27:08 GMT, Pavel Rappo wrote:
>> Please review this PR which introduces the `java.io.IO` top-level class and
>> three methods to `java.io.Console` for [Implicitly Declared Classes and
>> Instance Main Methods (Third Preview)].
>>
>> This PR has been obtained as `git
On Tue, 7 May 2024 22:50:18 GMT, Doug Lea wrote:
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with
On Tue, 7 May 2024 20:23:11 GMT, Pavel Rappo wrote:
>>> Should this be final?
>>
>> With only the private constructor, it doesn't matter too much in practice,
>> but an explicit `final` would be good documentation if that is the intent.
>
> If the sole constructor of a class is private, not
On Wed, 8 May 2024 18:43:41 GMT, Pavel Rappo wrote:
>> Please review this PR which introduces the `java.io.IO` top-level class and
>> three methods to `java.io.Console` for [Implicitly Declared Classes and
>> Instance Main Methods (Third Preview)].
>>
>> This PR has been obtained as `git
On Thu, 9 May 2024 18:27:08 GMT, Pavel Rappo wrote:
>> Please review this PR which introduces the `java.io.IO` top-level class and
>> three methods to `java.io.Console` for [Implicitly Declared Classes and
>> Instance Main Methods (Third Preview)].
>>
>> This PR has been obtained as `git
85 matches
Mail list logo
