From robert.field at oracle.com  Mon Jun 12 20:04:02 2017
From: robert.field at oracle.com (Robert Field)
Date: Mon, 12 Jun 2017 13:04:02 -0700
Subject: RFR 8180306, 8179048, 8179046, 8181950: jshell tool: /help fixes
 and required test fixes
Message-ID: <593EF3B2.9000401@oracle.com>

Please review ?

Bugs:

8180306: jshell tool: /help -- confusing identifier in feedback mode 
examples
https://bugs.openjdk.java.net/browse/JDK-8180306

8179048: jshell tool: /help -- references to "/reset or /reload" should 
add /env
https://bugs.openjdk.java.net/browse/JDK-8179048

8179046: jshell tool: /help /edit is missing -all and -start
https://bugs.openjdk.java.net/browse/JDK-8179046

8181950: jshell tests: longer help documentation breaks tests because of 
paging
https://bugs.openjdk.java.net/browse/JDK-8181950

Webrev:

http://cr.openjdk.java.net/~rfield/8180306v1.webrev/

Thanks,
Robert


From robert.field at oracle.com  Mon Jun 12 22:44:48 2017
From: robert.field at oracle.com (Robert Field)
Date: Mon, 12 Jun 2017 15:44:48 -0700
Subject: RFR 8180510: jshell tool: crash on entering pseudo-commands: /<id>
 or /-<n>
Message-ID: <593F1960.6050804@oracle.com>

Please review --

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8180510

Webrev:

     http://cr.openjdk.java.net/~rfield/8180510v0.webrev/

Thanks,
Robert


From jan.lahoda at oracle.com  Tue Jun 13 14:47:14 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 13 Jun 2017 16:47:14 +0200
Subject: RFR 8180306, 8179048, 8179046, 8181950: jshell tool: /help fixes
 and required test fixes
In-Reply-To: <593EF3B2.9000401@oracle.com>
References: <593EF3B2.9000401@oracle.com>
Message-ID: <593FFAF2.5050300@oracle.com>

Seems good to me.

Jan

On 12.6.2017 22:04, Robert Field wrote:
> Please review ?
>
> Bugs:
>
> 8180306: jshell tool: /help -- confusing identifier in feedback mode
> examples
> https://bugs.openjdk.java.net/browse/JDK-8180306
>
> 8179048: jshell tool: /help -- references to "/reset or /reload" should
> add /env
> https://bugs.openjdk.java.net/browse/JDK-8179048
>
> 8179046: jshell tool: /help /edit is missing -all and -start
> https://bugs.openjdk.java.net/browse/JDK-8179046
>
> 8181950: jshell tests: longer help documentation breaks tests because of
> paging
> https://bugs.openjdk.java.net/browse/JDK-8181950
>
> Webrev:
>
> http://cr.openjdk.java.net/~rfield/8180306v1.webrev/
>
> Thanks,
> Robert
>

From robert.field at oracle.com  Fri Jun 16 06:14:01 2017
From: robert.field at oracle.com (Robert Field)
Date: Thu, 15 Jun 2017 23:14:01 -0700
Subject: RFR 8182270: JShell API: snippet information / 8166334: jshell tool:
 shortcut: expression/statement to method
Message-ID: <59437729.6040108@oracle.com>

Please review --

Bugs:

     JShell API: Tools need snippet information without evaluating snippet
     https://bugs.openjdk.java.net/browse/JDK-8182270

     jshell tool: shortcut: expression/statement to method
     https://bugs.openjdk.java.net/browse/JDK-8166334

Webrev:

     http://cr.openjdk.java.net/~rfield/8182270v0.webrev/

Thanks,
Robert


From jan.lahoda at oracle.com  Fri Jun 16 16:53:00 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 16 Jun 2017 18:53:00 +0200
Subject: RFR 8180510: jshell tool: crash on entering pseudo-commands:
 /<id> or /-<n>
In-Reply-To: <593F1960.6050804@oracle.com>
References: <593F1960.6050804@oracle.com>
Message-ID: <59440CEC.5070200@oracle.com>

Seems OK to me.

Jan

On 13.6.2017 00:44, Robert Field wrote:
> Please review --
>
> Bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-8180510
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8180510v0.webrev/
>
> Thanks,
> Robert
>

From robert.field at oracle.com  Wed Jun 21 02:29:56 2017
From: robert.field at oracle.com (Robert Field)
Date: Tue, 20 Jun 2017 19:29:56 -0700
Subject: RFR 8182270: JShell API: snippet information / 8166334: jshell
 tool: shortcut: expression/statement to method
In-Reply-To: <59437729.6040108@oracle.com>
References: <59437729.6040108@oracle.com>
Message-ID: <5949DA24.8000109@oracle.com>

Please review: Adds new shift-tab-m shortcut for converting expressions 
or statements into methods.  And adds to the JShell API, non-evaluative 
Snippet information access, required the new tool functionality, and 
generally useful for analyzing source snippets before evaluation.

Update...

With input from Jan, added direct UI level tests of, not only the new 
shift-tab-m functionality, but, of all shift-tab functionality.

Fixed an obscure issue of temp variable numbering after ctrl-C'ing a 
shift-tab-m.


On 06/15/17 23:14, Robert Field wrote:
> Please review --
>
> Bugs:
>
>     JShell API: Tools need snippet information without evaluating snippet
>     https://bugs.openjdk.java.net/browse/JDK-8182270
>
>     jshell tool: shortcut: expression/statement to method
>     https://bugs.openjdk.java.net/browse/JDK-8166334
>
> Webrev:
>
>     http://cr.openjdk.java.net/~rfield/8182270v0.webrev/
>
> Thanks,
> Robert
>


From jan.lahoda at oracle.com  Fri Jun 23 16:13:35 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 23 Jun 2017 18:13:35 +0200
Subject: RFR 8182270: JShell API: snippet information / 8166334: jshell
 tool: shortcut: expression/statement to method
In-Reply-To: <5949DA24.8000109@oracle.com>
References: <59437729.6040108@oracle.com> <5949DA24.8000109@oracle.com>
Message-ID: <594D3E2F.5090706@oracle.com>

Typo:
ToolShiftTabTest.java:
@summary test shift-tab shortcuts "fixs"
=>
@summary test shift-tab shortcuts "fixes"

Otherwise looks good.

Jan

On 21.6.2017 04:29, Robert Field wrote:
> Please review: Adds new shift-tab-m shortcut for converting expressions
> or statements into methods.  And adds to the JShell API, non-evaluative
> Snippet information access, required the new tool functionality, and
> generally useful for analyzing source snippets before evaluation.
>
> Update...
>
> With input from Jan, added direct UI level tests of, not only the new
> shift-tab-m functionality, but, of all shift-tab functionality.
>
> Fixed an obscure issue of temp variable numbering after ctrl-C'ing a
> shift-tab-m.
>
>
> On 06/15/17 23:14, Robert Field wrote:
>> Please review --
>>
>> Bugs:
>>
>>     JShell API: Tools need snippet information without evaluating snippet
>>     https://bugs.openjdk.java.net/browse/JDK-8182270
>>
>>     jshell tool: shortcut: expression/statement to method
>>     https://bugs.openjdk.java.net/browse/JDK-8166334
>>
>> Webrev:
>>
>>     http://cr.openjdk.java.net/~rfield/8182270v0.webrev/
>>
>> Thanks,
>> Robert
>>
>

From robert.field at oracle.com  Sat Jun 24 06:31:06 2017
From: robert.field at oracle.com (Robert Field)
Date: Fri, 23 Jun 2017 23:31:06 -0700
Subject: RFR 8182489: jshell tool: rerun multiline snippet from history
 corrupts history
Message-ID: <594E072A.7060400@oracle.com>

Please review (for JDK 10) ---

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8182489

Webrev jdk repo (code fix):

     http://cr.openjdk.java.net/~rfield/8182489v0jdk.webrev/

Webrev langtools repo (test):

     http://cr.openjdk.java.net/~rfield/8182489v0langtools.webrev/

Thanks,
Robert




From robert.field at oracle.com  Sat Jun 24 23:57:20 2017
From: robert.field at oracle.com (Robert Field)
Date: Sat, 24 Jun 2017 16:57:20 -0700
Subject: 8176110: JShell: completions with package results should, in most
 cases, be dot terminated
Message-ID: <594EFC60.8060201@oracle.com>

Please review for JDK 10 --

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8176110

Webrev:

     http://cr.openjdk.java.net/~rfield/8176110v0.webrev/

Thanks,
Robert


From robert.field at oracle.com  Sun Jun 25 04:00:21 2017
From: robert.field at oracle.com (Robert Field)
Date: Sat, 24 Jun 2017 21:00:21 -0700
Subject: RFR 8176110: JShell: completions with package results should, in
 most cases, be dot terminated
In-Reply-To: <594EFC60.8060201@oracle.com>
References: <594EFC60.8060201@oracle.com>
Message-ID: <594F3555.6040101@oracle.com>

Please review for JDK 10 --

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8176110

Webrev:

     http://cr.openjdk.java.net/~rfield/8176110v0.webrev/

Thanks,
Robert




From sormuras at gmail.com  Sun Jun 25 14:27:34 2017
From: sormuras at gmail.com (Christian Stein)
Date: Sun, 25 Jun 2017 16:27:34 +0200
Subject: Fwd: JShell /exit with a non-zero error code
In-Reply-To: <CAJi8+g5kVna7KhgXNMQ-7x6Z1xMVSA0Bt1J1gDXQGcF0iEJSmA@mail.gmail.com>
References: <CAJi8+g5kVna7KhgXNMQ-7x6Z1xMVSA0Bt1J1gDXQGcF0iEJSmA@mail.gmail.com>
Message-ID: <CAJi8+g50=0f2JgCZ46chSTQq_M+8KBfk4HweLWbV1abGrBrWhw@mail.gmail.com>

Hi!

Copied from: https://stackoverflow.com/questions/44620232/exit-
jshell-with-error-code

How do I /exit a jshell session with a non-zero error code?

*/exit* yields: Process finished with exit code 0
*/exit 1* yields: Process finished with exit code 0
*throw new Error("1")* yields: java.lang.Error thrown: 1 at (#24:1)` and
Process finished with exit code 0
*System.exit(1)* yields: State engine terminated. Restore definitions with:
/reload -restore ... and the jshell session is not terminated.


A bash command like set -e is not available.



It feels like it is intentionally not supported, am I right?


My current work-around is to communicate via file system.
I create an "error token" file in "build.jsh" and check its presence
afterwards:


/open src/main/java/Bach.java
/open src/main/java/Build.java
Path failed = Paths.get("build.jsh.failed");
Files.deleteIfExists(failed)
try {
  Build.main();
} catch (Throwable t) {
  Files.createFile(failed);
}
/exit



Check in calling (.travis.yml) script:


./build.jsh && test ! -f build.jsh.failed



Cheers,
Christian

From jan.lahoda at oracle.com  Sun Jun 25 18:44:20 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Sun, 25 Jun 2017 20:44:20 +0200
Subject: RFR 8182489: jshell tool: rerun multiline snippet from history
 corrupts history
In-Reply-To: <594E072A.7060400@oracle.com>
References: <594E072A.7060400@oracle.com>
Message-ID: <59500484.7030003@oracle.com>

Seems OK.

Jan

On 24.6.2017 08:31, Robert Field wrote:
> Please review (for JDK 10) ---
>
> Bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-8182489
>
> Webrev jdk repo (code fix):
>
>      http://cr.openjdk.java.net/~rfield/8182489v0jdk.webrev/
>
> Webrev langtools repo (test):
>
>      http://cr.openjdk.java.net/~rfield/8182489v0langtools.webrev/
>
> Thanks,
> Robert
>
>
>

From jan.lahoda at oracle.com  Sun Jun 25 18:48:17 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Sun, 25 Jun 2017 20:48:17 +0200
Subject: RFR 8176110: JShell: completions with package results should, in
 most cases, be dot terminated
In-Reply-To: <594F3555.6040101@oracle.com>
References: <594EFC60.8060201@oracle.com> <594F3555.6040101@oracle.com>
Message-ID: <59500571.1050505@oracle.com>

Overall, looks good. One nit: the "case PACKAGE:" branch should also end 
with a "break;", to avoid possible future errors.

Thanks,
     Jan

On 25.6.2017 06:00, Robert Field wrote:
> Please review for JDK 10 --
>
> Bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-8176110
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8176110v0.webrev/
>
> Thanks,
> Robert
>
>
>

From robert.field at oracle.com  Sun Jun 25 23:02:30 2017
From: robert.field at oracle.com (Robert Field)
Date: Sun, 25 Jun 2017 16:02:30 -0700
Subject: RFR 8177847: jshell tool: retain delete of non-retained mode does
 not locally delete
Message-ID: <59504106.5030504@oracle.com>

Please review for JDK 10 --

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8177847

Webrev:

     http://cr.openjdk.java.net/~rfield/8177847v0.webrev/

Thanks,
Robert


From robert.field at oracle.com  Mon Jun 26 19:54:19 2017
From: robert.field at oracle.com (Robert Field)
Date: Mon, 26 Jun 2017 12:54:19 -0700
Subject: 8182268: JShell: CompletionInfo.source() for CONSIDERED_INCOMPLETE
 missing semicolon
Message-ID: <5951666B.9040605@oracle.com>

Please review --

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8182268

Webrev:

     http://cr.openjdk.java.net/~rfield/8182268v0.webrev/

Thanks,
Robert


From robert.field at oracle.com  Mon Jun 26 19:55:25 2017
From: robert.field at oracle.com (Robert Field)
Date: Mon, 26 Jun 2017 12:55:25 -0700
Subject: RFR 8182268: JShell: CompletionInfo.source() for CONSIDERED_INCOMPLETE
 missing semicolon
In-Reply-To: <5951666B.9040605@oracle.com>
References: <5951666B.9040605@oracle.com>
Message-ID: <595166AD.9030608@oracle.com>


Please review --

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8182268

Webrev:

     http://cr.openjdk.java.net/~rfield/8182268v0.webrev/

Thanks,
Robert




From jan.lahoda at oracle.com  Mon Jun 26 20:28:49 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 26 Jun 2017 22:28:49 +0200
Subject: RFR 8182268: JShell: CompletionInfo.source() for
 CONSIDERED_INCOMPLETE missing semicolon
In-Reply-To: <595166AD.9030608@oracle.com>
References: <5951666B.9040605@oracle.com> <595166AD.9030608@oracle.com>
Message-ID: <59516E81.9070102@oracle.com>

Seems OK.

Jan

On 26.6.2017 21:55, Robert Field wrote:
>
> Please review --
>
> Bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-8182268
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8182268v0.webrev/
>
> Thanks,
> Robert
>
>
>

From jan.lahoda at oracle.com  Mon Jun 26 20:30:31 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 26 Jun 2017 22:30:31 +0200
Subject: RFR 8177847: jshell tool: retain delete of non-retained mode does
 not locally delete
In-Reply-To: <59504106.5030504@oracle.com>
References: <59504106.5030504@oracle.com>
Message-ID: <59516EE7.4040406@oracle.com>

Seems OK.

Jan

On 26.6.2017 01:02, Robert Field wrote:
> Please review for JDK 10 --
>
> Bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-8177847
>
> Webrev:
>
>      http://cr.openjdk.java.net/~rfield/8177847v0.webrev/
>
> Thanks,
> Robert
>

From jan.lahoda at oracle.com  Tue Jun 27 17:49:17 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 27 Jun 2017 19:49:17 +0200
Subject: RFR: 8183021: Fix failing jshell tests on Windows
Message-ID: <59529A9D.1050808@oracle.com>

Hi,

Two JShell tests are failing on Win:
-jdk/jshell/ToolBasicTest.java, seems that 
System.getProperty("user.home") may return forward slashes, but the 
tests expects the canonical backward slash. The proposed solution is to 
normalize the path using Paths.get(...).
-jdk/jshell/ToolMultilineSnippetHistoryTest.java, seems JShellTool 
prints \n, while the test expects \r\n. The proposed solution is to 
change the relevant place in JShellTool to use println to improve 
testability.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8183021

Webrev:
http://cr.openjdk.java.net/~jlahoda/8183021/webrev.00/

Thanks,
     Jan

From jan.lahoda at oracle.com  Tue Jun 27 18:14:20 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 27 Jun 2017 20:14:20 +0200
Subject: RFR: 8182297: jshell tool: pasting multiple lines of code truncated
Message-ID: <5952A07C.2080901@oracle.com>

Hi,

Currently, when pasting multiple lines into JShell, only the first two 
lines are used.

The cause is that when 
jdk.internal.jline.console.ConsoleReader.readLine, we need to read the 
cursor position. This is e.g. to avoid backspacing into the prompt. I 
believe standard JLine is solving this by determining the length of the 
prompt, but that does not work well for JShell, as the prompt is not 
always known (e.g. when using System.in).

So, there's a code to query the cursor position - this is done by 
writing a query to the terminal and reading the answer from the standard 
input.

But if there's something in the standard input before the answer, it 
needs to be read as well. So, this is read and stored in a queue/stack, 
but the problem is that the stack is a local variable in the readLine 
method. So only one line of the input is used and the rest is dropped. 
The reason why two lines are used after paste is that the above happens 
for the second pasted line; the measurements for the first line are 
usually already done for the first line, which is not so affected.

The proposed solution is to store the todo stack in a field.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8182297

Webrev:
jdk repository:
http://cr.openjdk.java.net/~jlahoda/8182297/jdk.00/
langtools repository (test):
http://cr.openjdk.java.net/~jlahoda/8182297/langtools.00/

Thanks,
    Jan

From robert.field at oracle.com  Tue Jun 27 18:29:59 2017
From: robert.field at oracle.com (Robert Field)
Date: Tue, 27 Jun 2017 11:29:59 -0700
Subject: RFR: 8183021: Fix failing jshell tests on Windows
In-Reply-To: <59529A9D.1050808@oracle.com>
References: <59529A9D.1050808@oracle.com>
Message-ID: <5952A427.6010701@oracle.com>

Looks fine.

We seem to have a general issue of not using platform line ending, I've 
created:

     https://bugs.openjdk.java.net/browse/JDK-8183022

-Robert

On 06/27/17 10:49, Jan Lahoda wrote:
> Hi,
>
> Two JShell tests are failing on Win:
> -jdk/jshell/ToolBasicTest.java, seems that 
> System.getProperty("user.home") may return forward slashes, but the 
> tests expects the canonical backward slash. The proposed solution is 
> to normalize the path using Paths.get(...).
> -jdk/jshell/ToolMultilineSnippetHistoryTest.java, seems JShellTool 
> prints \n, while the test expects \r\n. The proposed solution is to 
> change the relevant place in JShellTool to use println to improve 
> testability.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8183021
>
> Webrev:
> http://cr.openjdk.java.net/~jlahoda/8183021/webrev.00/
>
> Thanks,
>     Jan


From robert.field at oracle.com  Tue Jun 27 19:04:53 2017
From: robert.field at oracle.com (Robert Field)
Date: Tue, 27 Jun 2017 12:04:53 -0700
Subject: RFR: 8182297: jshell tool: pasting multiple lines of code
 truncated
In-Reply-To: <5952A07C.2080901@oracle.com>
References: <5952A07C.2080901@oracle.com>
Message-ID: <5952AC55.4090303@oracle.com>

Style nit: in this class all field definitions are at the top of the 
class, which I believe is the coding standard.  This new field is two 
thousand lines down.  I understand that this field is private to 
readLine, but a comment could communicate that.

Style question: adding to pushBackChars in the original is decidedly Old 
School (an old for-loop *gasp*), and the proposed is all streamy, but it 
is twice as long, involves more steps, seems harder to understand, 
involves intermediate collections, and is probably slower.  Is there a 
reason?

Seems OK, address above at your discretion.

-Robert



On 06/27/17 11:14, Jan Lahoda wrote:
> Hi,
>
> Currently, when pasting multiple lines into JShell, only the first two 
> lines are used.
>
> The cause is that when 
> jdk.internal.jline.console.ConsoleReader.readLine, we need to read the 
> cursor position. This is e.g. to avoid backspacing into the prompt. I 
> believe standard JLine is solving this by determining the length of 
> the prompt, but that does not work well for JShell, as the prompt is 
> not always known (e.g. when using System.in).
>
> So, there's a code to query the cursor position - this is done by 
> writing a query to the terminal and reading the answer from the 
> standard input.
>
> But if there's something in the standard input before the answer, it 
> needs to be read as well. So, this is read and stored in a 
> queue/stack, but the problem is that the stack is a local variable in 
> the readLine method. So only one line of the input is used and the 
> rest is dropped. The reason why two lines are used after paste is that 
> the above happens for the second pasted line; the measurements for the 
> first line are usually already done for the first line, which is not 
> so affected.
>
> The proposed solution is to store the todo stack in a field.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8182297
>
> Webrev:
> jdk repository:
> http://cr.openjdk.java.net/~jlahoda/8182297/jdk.00/
> langtools repository (test):
> http://cr.openjdk.java.net/~jlahoda/8182297/langtools.00/
>
> Thanks,
>    Jan


From jan.lahoda at oracle.com  Tue Jun 27 22:05:46 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 28 Jun 2017 00:05:46 +0200
Subject: RFR: 8183021: Fix failing jshell tests on Windows
In-Reply-To: <5952A427.6010701@oracle.com>
References: <59529A9D.1050808@oracle.com> <5952A427.6010701@oracle.com>
Message-ID: <5952D6BA.8040603@oracle.com>

On 27.6.2017 20:29, Robert Field wrote:
> Looks fine.

Sorry, I was too eager and sent this before the tests were finished. 
Turned out even the snippet.source() may contain "\n". Given the use of 
"\n" seems mostly benign (except for these UI tests), and trying to 
change "\n" to "\r\n" for the snippet.source() seems less safe, I tried 
to fix this solely in the test. Using "[\n]" will translate to "[\r\n]" 
inside the test framework on Windows, which will match the sole \n.

Updated webrev:
http://cr.openjdk.java.net/~jlahoda/8183021/webrev.01/

Sorry for trouble.

>
> We seem to have a general issue of not using platform line ending, I've

I've noticed that, but except for these tests seems mostly benign, right?

Jan

> created:
>
>      https://bugs.openjdk.java.net/browse/JDK-8183022
>
> -Robert
>
> On 06/27/17 10:49, Jan Lahoda wrote:
>> Hi,
>>
>> Two JShell tests are failing on Win:
>> -jdk/jshell/ToolBasicTest.java, seems that
>> System.getProperty("user.home") may return forward slashes, but the
>> tests expects the canonical backward slash. The proposed solution is
>> to normalize the path using Paths.get(...).
>> -jdk/jshell/ToolMultilineSnippetHistoryTest.java, seems JShellTool
>> prints \n, while the test expects \r\n. The proposed solution is to
>> change the relevant place in JShellTool to use println to improve
>> testability.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8183021
>>
>> Webrev:
>> http://cr.openjdk.java.net/~jlahoda/8183021/webrev.00/
>>
>> Thanks,
>>     Jan
>

From robert.field at oracle.com  Tue Jun 27 23:12:46 2017
From: robert.field at oracle.com (Robert Field)
Date: Tue, 27 Jun 2017 16:12:46 -0700
Subject: RFR: 8183021: Fix failing jshell tests on Windows
In-Reply-To: <5952D6BA.8040603@oracle.com>
References: <59529A9D.1050808@oracle.com> <5952A427.6010701@oracle.com>
 <5952D6BA.8040603@oracle.com>
Message-ID: <5952E66E.6010206@oracle.com>


On 06/27/17 15:05, Jan Lahoda wrote:
> On 27.6.2017 20:29, Robert Field wrote:
>> Looks fine.
>
> Sorry, I was too eager and sent this before the tests were finished. 
> Turned out even the snippet.source() may contain "\n". Given the use 
> of "\n" seems mostly benign (except for these UI tests), and trying to 
> change "\n" to "\r\n" for the snippet.source() seems less safe, I 
> tried to fix this solely in the test. Using "[\n]" will translate to 
> "[\r\n]" inside the test framework on Windows, which will match the 
> sole \n.

Right, that will work in this case.  However, were it actually a \r\n it 
would fail without being [\n]+ -- but that all seems twisty-turny and 
only addresses this one case.

How about, instead of fixing this one test 
(ToolMultilineSnippetHistoryTest), instead change line 123 of UITesting 
from:

         expected = expected.replaceAll("\n", 
System.getProperty("line.separator"));

To:

         expected = expected.replaceAll("\n", "\\R");

?

Where (from Pattern) --

Linebreak matcher
\R     Any Unicode linebreak sequence, is equivalent to 
\u000D\u000A|[\u000A\u000B\u000C\u000D\u0085\u2028\u2029]

-Robert

>
> Updated webrev:
> http://cr.openjdk.java.net/~jlahoda/8183021/webrev.01/
>
> Sorry for trouble.
>
>>
>> We seem to have a general issue of not using platform line ending, I've
>
> I've noticed that, but except for these tests seems mostly benign, right?
>
> Jan
>
>> created:
>>
>>      https://bugs.openjdk.java.net/browse/JDK-8183022
>>
>> -Robert
>>
>> On 06/27/17 10:49, Jan Lahoda wrote:
>>> Hi,
>>>
>>> Two JShell tests are failing on Win:
>>> -jdk/jshell/ToolBasicTest.java, seems that
>>> System.getProperty("user.home") may return forward slashes, but the
>>> tests expects the canonical backward slash. The proposed solution is
>>> to normalize the path using Paths.get(...).
>>> -jdk/jshell/ToolMultilineSnippetHistoryTest.java, seems JShellTool
>>> prints \n, while the test expects \r\n. The proposed solution is to
>>> change the relevant place in JShellTool to use println to improve
>>> testability.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8183021
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~jlahoda/8183021/webrev.00/
>>>
>>> Thanks,
>>>     Jan
>>


From jan.lahoda at oracle.com  Wed Jun 28 11:38:27 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 28 Jun 2017 13:38:27 +0200
Subject: RFR: 8183021: Fix failing jshell tests on Windows
In-Reply-To: <5952E66E.6010206@oracle.com>
References: <59529A9D.1050808@oracle.com> <5952A427.6010701@oracle.com>
 <5952D6BA.8040603@oracle.com> <5952E66E.6010206@oracle.com>
Message-ID: <59539533.2030604@oracle.com>

On 28.6.2017 01:12, Robert Field wrote:
>
> On 06/27/17 15:05, Jan Lahoda wrote:
>> On 27.6.2017 20:29, Robert Field wrote:
>>> Looks fine.
>>
>> Sorry, I was too eager and sent this before the tests were finished.
>> Turned out even the snippet.source() may contain "\n". Given the use
>> of "\n" seems mostly benign (except for these UI tests), and trying to
>> change "\n" to "\r\n" for the snippet.source() seems less safe, I
>> tried to fix this solely in the test. Using "[\n]" will translate to
>> "[\r\n]" inside the test framework on Windows, which will match the
>> sole \n.
>
> Right, that will work in this case.  However, were it actually a \r\n it
> would fail without being [\n]+ -- but that all seems twisty-turny and
> only addresses this one case.
>
> How about, instead of fixing this one test
> (ToolMultilineSnippetHistoryTest), instead change line 123 of UITesting
> from:
>
>          expected = expected.replaceAll("\n",
> System.getProperty("line.separator"));
>
> To:
>
>          expected = expected.replaceAll("\n", "\\R");
>
> ?
>
> Where (from Pattern) --
>
> Linebreak matcher
> \R     Any Unicode linebreak sequence, is equivalent to
> \u000D\u000A|[\u000A\u000B\u000C\u000D\u0085\u2028\u2029]

I was thinking of generalizing the \n handling, but I think I prefer the 
framework and tests to be more strict - at least until we have more 
tests that want to be more lax. (Not sure if we could use \R, as the 
test framework should allow to check a difference between '\r' and '\n', 
I think, as changing '\n' to '\r' could have visible effects. To be more 
lax, we might be able to use \r?\n, so something alike.)

But a good pointer for \R - maybe this test could be made lax using \R:
http://cr.openjdk.java.net/~jlahoda/8183021/webrev.02/

What do you think?

Thanks,
    Jan

>
> -Robert
>
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~jlahoda/8183021/webrev.01/
>>
>> Sorry for trouble.
>>
>>>
>>> We seem to have a general issue of not using platform line ending, I've
>>
>> I've noticed that, but except for these tests seems mostly benign, right?
>>
>> Jan
>>
>>> created:
>>>
>>>      https://bugs.openjdk.java.net/browse/JDK-8183022
>>>
>>> -Robert
>>>
>>> On 06/27/17 10:49, Jan Lahoda wrote:
>>>> Hi,
>>>>
>>>> Two JShell tests are failing on Win:
>>>> -jdk/jshell/ToolBasicTest.java, seems that
>>>> System.getProperty("user.home") may return forward slashes, but the
>>>> tests expects the canonical backward slash. The proposed solution is
>>>> to normalize the path using Paths.get(...).
>>>> -jdk/jshell/ToolMultilineSnippetHistoryTest.java, seems JShellTool
>>>> prints \n, while the test expects \r\n. The proposed solution is to
>>>> change the relevant place in JShellTool to use println to improve
>>>> testability.
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8183021
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~jlahoda/8183021/webrev.00/
>>>>
>>>> Thanks,
>>>>     Jan
>>>
>

From jonathan.gibbons at oracle.com  Wed Jun 28 15:42:06 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 28 Jun 2017 08:42:06 -0700
Subject: RFR: 8183021: Fix failing jshell tests on Windows
In-Reply-To: <59539533.2030604@oracle.com>
References: <59529A9D.1050808@oracle.com> <5952A427.6010701@oracle.com>
 <5952D6BA.8040603@oracle.com> <5952E66E.6010206@oracle.com>
 <59539533.2030604@oracle.com>
Message-ID: <bdfc2d49-c324-a590-ace5-68543dd93476@oracle.com>



On 6/28/17 4:38 AM, Jan Lahoda wrote:
> On 28.6.2017 01:12, Robert Field wrote:
>>
>> On 06/27/17 15:05, Jan Lahoda wrote:
>>> On 27.6.2017 20:29, Robert Field wrote:
>>>> Looks fine.
>>>
>>> Sorry, I was too eager and sent this before the tests were finished.
>>> Turned out even the snippet.source() may contain "\n". Given the use
>>> of "\n" seems mostly benign (except for these UI tests), and trying to
>>> change "\n" to "\r\n" for the snippet.source() seems less safe, I
>>> tried to fix this solely in the test. Using "[\n]" will translate to
>>> "[\r\n]" inside the test framework on Windows, which will match the
>>> sole \n.
>>
>> Right, that will work in this case.  However, were it actually a \r\n it
>> would fail without being [\n]+ -- but that all seems twisty-turny and
>> only addresses this one case.
>>
>> How about, instead of fixing this one test
>> (ToolMultilineSnippetHistoryTest), instead change line 123 of UITesting
>> from:
>>
>>          expected = expected.replaceAll("\n",
>> System.getProperty("line.separator"));
>>
>> To:
>>
>>          expected = expected.replaceAll("\n", "\\R");
>>
>> ?
>>
>> Where (from Pattern) --
>>
>> Linebreak matcher
>> \R     Any Unicode linebreak sequence, is equivalent to
>> \u000D\u000A|[\u000A\u000B\u000C\u000D\u0085\u2028\u2029]
>
> I was thinking of generalizing the \n handling, but I think I prefer 
> the framework and tests to be more strict - at least until we have 
> more tests that want to be more lax. (Not sure if we could use \R, as 
> the test framework should allow to check a difference between '\r' and 
> '\n', I think, as changing '\n' to '\r' could have visible effects. To 
> be more lax, we might be able to use \r?\n, so something alike.)
>
> But a good pointer for \R - maybe this test could be made lax using \R:
> http://cr.openjdk.java.net/~jlahoda/8183021/webrev.02/
>
> What do you think?
>
> Thanks,
>    Jan

Tests that are designed to test the line-end handling should be strict, 
but tests for other functionality but which incidentally have line 
endings in their output can be more lax. Can the framework be configurable?

Good tip on \R, by the way. I know other places where that could be used.

-- Jon
>
>>
>> -Robert
>>
>>>
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~jlahoda/8183021/webrev.01/
>>>
>>> Sorry for trouble.
>>>
>>>>
>>>> We seem to have a general issue of not using platform line ending, 
>>>> I've
>>>
>>> I've noticed that, but except for these tests seems mostly benign, 
>>> right?
>>>
>>> Jan
>>>
>>>> created:
>>>>
>>>>      https://bugs.openjdk.java.net/browse/JDK-8183022
>>>>
>>>> -Robert
>>>>
>>>> On 06/27/17 10:49, Jan Lahoda wrote:
>>>>> Hi,
>>>>>
>>>>> Two JShell tests are failing on Win:
>>>>> -jdk/jshell/ToolBasicTest.java, seems that
>>>>> System.getProperty("user.home") may return forward slashes, but the
>>>>> tests expects the canonical backward slash. The proposed solution is
>>>>> to normalize the path using Paths.get(...).
>>>>> -jdk/jshell/ToolMultilineSnippetHistoryTest.java, seems JShellTool
>>>>> prints \n, while the test expects \r\n. The proposed solution is to
>>>>> change the relevant place in JShellTool to use println to improve
>>>>> testability.
>>>>>
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8183021
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~jlahoda/8183021/webrev.00/
>>>>>
>>>>> Thanks,
>>>>>     Jan
>>>>
>>


From jan.lahoda at oracle.com  Wed Jun 28 15:46:43 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 28 Jun 2017 17:46:43 +0200
Subject: RFR: 8182297: jshell tool: pasting multiple lines of code
 truncated
In-Reply-To: <5952AC55.4090303@oracle.com>
References: <5952A07C.2080901@oracle.com> <5952AC55.4090303@oracle.com>
Message-ID: <5953CF63.8040808@oracle.com>

On 27.6.2017 21:04, Robert Field wrote:
> Style nit: in this class all field definitions are at the top of the
> class, which I believe is the coding standard.  This new field is two
> thousand lines down.  I understand that this field is private to
> readLine, but a comment could communicate that.

Agreed, moved down to the "//where:" section.

>
> Style question: adding to pushBackChars in the original is decidedly Old
> School (an old for-loop *gasp*), and the proposed is all streamy, but it
> is twice as long, involves more steps, seems harder to understand,
> involves intermediate collections, and is probably slower.  Is there a
> reason?

The reason for the intermediate collection is this: before, 
pushBackChars was always empty, so it was enough to just iterate through 
"prefix" in the reverse order and push the characters onto the stack. 
After this, the first input character was at the top of the stack, the 
last at the bottom, which ensured the correct order.

After making pushBackChars a field, the stack may already contain data 
from previous invocations of readLine. So, the content of "prefix" needs 
to be added in the reverse order at the bottom of the stack.

This could be done using:
for (int i = 0; i < prefix.length(); i++) {
     pushBackChar.add(0, prefix.charAt(i));
}

but each invocation of the add method would need shift all the content 
to make room for the new (single) char, and this could take a while. So, 
using the temporary list should ensure there will be at most one content 
shifting in pushBackChar.

In an updated webrev, I used a for instead of the stream 
manipulation&explicit reverse, might be slightly better.

Updated webrev for the jdk repository:
http://cr.openjdk.java.net/~jlahoda/8182297/jdk.01/

The webrev for the langtools repository remains the same:
http://cr.openjdk.java.net/~jlahoda/8182297/langtools.00/

Thanks,
     Jan

>
> Seems OK, address above at your discretion.
>
> -Robert
>
>
>
> On 06/27/17 11:14, Jan Lahoda wrote:
>> Hi,
>>
>> Currently, when pasting multiple lines into JShell, only the first two
>> lines are used.
>>
>> The cause is that when
>> jdk.internal.jline.console.ConsoleReader.readLine, we need to read the
>> cursor position. This is e.g. to avoid backspacing into the prompt. I
>> believe standard JLine is solving this by determining the length of
>> the prompt, but that does not work well for JShell, as the prompt is
>> not always known (e.g. when using System.in).
>>
>> So, there's a code to query the cursor position - this is done by
>> writing a query to the terminal and reading the answer from the
>> standard input.
>>
>> But if there's something in the standard input before the answer, it
>> needs to be read as well. So, this is read and stored in a
>> queue/stack, but the problem is that the stack is a local variable in
>> the readLine method. So only one line of the input is used and the
>> rest is dropped. The reason why two lines are used after paste is that
>> the above happens for the second pasted line; the measurements for the
>> first line are usually already done for the first line, which is not
>> so affected.
>>
>> The proposed solution is to store the todo stack in a field.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8182297
>>
>> Webrev:
>> jdk repository:
>> http://cr.openjdk.java.net/~jlahoda/8182297/jdk.00/
>> langtools repository (test):
>> http://cr.openjdk.java.net/~jlahoda/8182297/langtools.00/
>>
>> Thanks,
>>    Jan
>

From jan.lahoda at oracle.com  Wed Jun 28 20:58:08 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 28 Jun 2017 22:58:08 +0200
Subject: RFR: 8183021: Fix failing jshell tests on Windows
In-Reply-To: <bdfc2d49-c324-a590-ace5-68543dd93476@oracle.com>
References: <59529A9D.1050808@oracle.com> <5952A427.6010701@oracle.com>
 <5952D6BA.8040603@oracle.com> <5952E66E.6010206@oracle.com>
 <59539533.2030604@oracle.com>
 <bdfc2d49-c324-a590-ace5-68543dd93476@oracle.com>
Message-ID: <59541860.2060503@oracle.com>



On 28.6.2017 17:42, Jonathan Gibbons wrote:
>
>
> On 6/28/17 4:38 AM, Jan Lahoda wrote:
>> On 28.6.2017 01:12, Robert Field wrote:
>>>
>>> On 06/27/17 15:05, Jan Lahoda wrote:
>>>> On 27.6.2017 20:29, Robert Field wrote:
>>>>> Looks fine.
>>>>
>>>> Sorry, I was too eager and sent this before the tests were finished.
>>>> Turned out even the snippet.source() may contain "\n". Given the use
>>>> of "\n" seems mostly benign (except for these UI tests), and trying to
>>>> change "\n" to "\r\n" for the snippet.source() seems less safe, I
>>>> tried to fix this solely in the test. Using "[\n]" will translate to
>>>> "[\r\n]" inside the test framework on Windows, which will match the
>>>> sole \n.
>>>
>>> Right, that will work in this case.  However, were it actually a \r\n it
>>> would fail without being [\n]+ -- but that all seems twisty-turny and
>>> only addresses this one case.
>>>
>>> How about, instead of fixing this one test
>>> (ToolMultilineSnippetHistoryTest), instead change line 123 of UITesting
>>> from:
>>>
>>>          expected = expected.replaceAll("\n",
>>> System.getProperty("line.separator"));
>>>
>>> To:
>>>
>>>          expected = expected.replaceAll("\n", "\\R");
>>>
>>> ?
>>>
>>> Where (from Pattern) --
>>>
>>> Linebreak matcher
>>> \R     Any Unicode linebreak sequence, is equivalent to
>>> \u000D\u000A|[\u000A\u000B\u000C\u000D\u0085\u2028\u2029]
>>
>> I was thinking of generalizing the \n handling, but I think I prefer
>> the framework and tests to be more strict - at least until we have
>> more tests that want to be more lax. (Not sure if we could use \R, as
>> the test framework should allow to check a difference between '\r' and
>> '\n', I think, as changing '\n' to '\r' could have visible effects. To
>> be more lax, we might be able to use \r?\n, so something alike.)
>>
>> But a good pointer for \R - maybe this test could be made lax using \R:
>> http://cr.openjdk.java.net/~jlahoda/8183021/webrev.02/
>>
>> What do you think?
>>
>> Thanks,
>>    Jan
>
> Tests that are designed to test the line-end handling should be strict,
> but tests for other functionality but which incidentally have line
> endings in their output can be more lax. Can the framework be configurable?

A version where the test framework can be configured to accept both \r\n 
and \n as line endings:
http://cr.openjdk.java.net/~jlahoda/8183021/webrev.03/

Jan

>
> Good tip on \R, by the way. I know other places where that could be used.
>
> -- Jon
>>
>>>
>>> -Robert
>>>
>>>>
>>>> Updated webrev:
>>>> http://cr.openjdk.java.net/~jlahoda/8183021/webrev.01/
>>>>
>>>> Sorry for trouble.
>>>>
>>>>>
>>>>> We seem to have a general issue of not using platform line ending,
>>>>> I've
>>>>
>>>> I've noticed that, but except for these tests seems mostly benign,
>>>> right?
>>>>
>>>> Jan
>>>>
>>>>> created:
>>>>>
>>>>>      https://bugs.openjdk.java.net/browse/JDK-8183022
>>>>>
>>>>> -Robert
>>>>>
>>>>> On 06/27/17 10:49, Jan Lahoda wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Two JShell tests are failing on Win:
>>>>>> -jdk/jshell/ToolBasicTest.java, seems that
>>>>>> System.getProperty("user.home") may return forward slashes, but the
>>>>>> tests expects the canonical backward slash. The proposed solution is
>>>>>> to normalize the path using Paths.get(...).
>>>>>> -jdk/jshell/ToolMultilineSnippetHistoryTest.java, seems JShellTool
>>>>>> prints \n, while the test expects \r\n. The proposed solution is to
>>>>>> change the relevant place in JShellTool to use println to improve
>>>>>> testability.
>>>>>>
>>>>>> Bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8183021
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~jlahoda/8183021/webrev.00/
>>>>>>
>>>>>> Thanks,
>>>>>>     Jan
>>>>>
>>>
>