From roy.van.rijn at gmail.com  Mon Nov  2 10:01:02 2015
From: roy.van.rijn at gmail.com (Roy van Rijn)
Date: Mon, 2 Nov 2015 02:01:02 -0800
Subject: Evaluation of String problem
Message-ID: <CAMJwwmvTXhJM-LXcdGdzGXaX-Ef+RZ=-_=ifbbt9gsZxz8_RPg@mail.gmail.com>

Dear kulla-devs,

Trying the latest code from the kulla branch, and I've done the following:
1) Install JDK 9
2) Get latest sources: get_sources.sh
3) Modified script/compile.sh for OS/X (/bin instead of /usr/bin)
4) Modified script/compile.sh removed path
../src/jdk.jshell/share/classes/*/*/*/*/*/*.java (there doesnt seem to
be a java file matching six stars)
5) Compile (no messages, works fine)
6) Modified script/run.sh for OS/X (/bin instead of /usr/bin)
7) Started jshell (although the version is: Version (version info not
available))

Next there seems to be a problem evaluating strings with the +
operator, for example:

-> String a = "a";
|  Added variable a of type String with initial value "a"
-> String b = "b";
|  Added variable b of type String with initial value "b"
-> String c = a + b;
|  Added variable c of type String
-> String d = "test " + " another test";
|  Added variable d of type String
-> System.out.println(a);
a
-> System.out.println(b);
b
-> System.out.println(c);
null
-> System.out.println(d);
null

Any idea what could be causing this? This breaks the most trivial of
examples, for example:
-> double tau = Math.PI * 2;
|  Added variable tau of type double with initial value 6.283185307179586

-> System.out.println("Tau is: " + tau);
An exception has occurred in the compiler (1.9.0-ea). Please file a
bug against the Java compiler via the Java bug reporting page
(http://bugreport.java.com) after checking the Bug Database
(http://bugs.java.com) for duplicates. Include your program and the
following diagnostic in your report. Thank you.
java.lang.AssertionError
at com.sun.tools.javac.util.Assert.error(Assert.java:155)
at com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
at com.sun.tools.javac.util.ListBuffer.append(ListBuffer.java:127)
at com.sun.tools.javac.parser.JavacParser.arguments(JavacParser.java:1799)
at com.sun.tools.javac.parser.JavacParser.arguments(JavacParser.java:1814)
at com.sun.tools.javac.parser.JavacParser.term3(JavacParser.java:1276)
at com.sun.tools.javac.parser.JavacParser.term2(JavacParser.java:902)
at com.sun.tools.javac.parser.JavacParser.term1(JavacParser.java:873)
at com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:829)
at com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:809)
at jdk.jshell.ReplParser.replUnit(ReplParser.java:225)
at jdk.jshell.ReplParser.parseCompilationUnit(ReplParser.java:132)
at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:601)
at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:638)
at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:930)
at com.sun.tools.javac.api.JavacTaskImpl.parseInternal(JavacTaskImpl.java:233)
at com.sun.tools.javac.api.JavacTaskImpl.access$400(JavacTaskImpl.java:69)
at com.sun.tools.javac.api.JavacTaskImpl$2.call(JavacTaskImpl.java:225)
at com.sun.tools.javac.api.JavacTaskImpl$2.call(JavacTaskImpl.java:222)
at com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:128)
at com.sun.tools.javac.api.JavacTaskImpl.parse(JavacTaskImpl.java:222)
at jdk.jshell.TaskFactory$ParseTask.parse(TaskFactory.java:221)
at jdk.jshell.TaskFactory$ParseTask.<init>(TaskFactory.java:207)
at jdk.jshell.CompletenessAnalyzer$Parser.disambiguateDeclarationVsExpression(CompletenessAnalyzer.java:671)
at jdk.jshell.CompletenessAnalyzer$Parser.parseUnit(CompletenessAnalyzer.java:615)
at jdk.jshell.CompletenessAnalyzer.scan(CompletenessAnalyzer.java:87)
at jdk.jshell.SourceCodeAnalysisImpl.analyzeCompletion(SourceCodeAnalysisImpl.java:133)
at jdk.internal.jshell.tool.ConsoleIOContext$1.analyzeCompletion(ConsoleIOContext.java:77)
at jdk.internal.jshell.tool.EditingHistory.add(EditingHistory.java:127)
at jdk.internal.jline.console.ConsoleReader.finishBuffer(ConsoleReader.java:655)
at jdk.internal.jline.console.ConsoleReader.accept(ConsoleReader.java:2027)
at jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2695)
at jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2277)
at jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:153)
at jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:447)
at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:266)
at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:245)
at jdk.internal.jshell.tool.JShellTool.main(JShellTool.java:235)

Is there something wrong with the way I've compiled/used the latest
code? Or is the jshell actually broken at this point?

Roy

From roy.van.rijn at gmail.com  Mon Nov  2 11:10:21 2015
From: roy.van.rijn at gmail.com (Roy van Rijn)
Date: Mon, 2 Nov 2015 03:10:21 -0800
Subject: Evaluation of String problem
In-Reply-To: <CAMJwwmvTXhJM-LXcdGdzGXaX-Ef+RZ=-_=ifbbt9gsZxz8_RPg@mail.gmail.com>
References: <CAMJwwmvTXhJM-LXcdGdzGXaX-Ef+RZ=-_=ifbbt9gsZxz8_RPg@mail.gmail.com>
Message-ID: <CAMJwwmt9bU8=Gv2YUmfVykmFvNds37SgAh6kxmuLpjciJ7CfYw@mail.gmail.com>

Some more questions:

When I get the latest JDK9 (not Kulla branch) and build the entire
image the resulting jshell does work and doesn't show this
behaviour... what is the current latest source for the jshell? When
demoing/showcasing/testing, which is version preferred?

On Mon, Nov 2, 2015 at 2:01 AM, Roy van Rijn <roy.van.rijn at gmail.com> wrote:
> Dear kulla-devs,
>
> Trying the latest code from the kulla branch, and I've done the following:
> 1) Install JDK 9
> 2) Get latest sources: get_sources.sh
> 3) Modified script/compile.sh for OS/X (/bin instead of /usr/bin)
> 4) Modified script/compile.sh removed path
> ../src/jdk.jshell/share/classes/*/*/*/*/*/*.java (there doesnt seem to
> be a java file matching six stars)
> 5) Compile (no messages, works fine)
> 6) Modified script/run.sh for OS/X (/bin instead of /usr/bin)
> 7) Started jshell (although the version is: Version (version info not
> available))
>
> Next there seems to be a problem evaluating strings with the +
> operator, for example:
>
> -> String a = "a";
> |  Added variable a of type String with initial value "a"
> -> String b = "b";
> |  Added variable b of type String with initial value "b"
> -> String c = a + b;
> |  Added variable c of type String
> -> String d = "test " + " another test";
> |  Added variable d of type String
> -> System.out.println(a);
> a
> -> System.out.println(b);
> b
> -> System.out.println(c);
> null
> -> System.out.println(d);
> null
>
> Any idea what could be causing this? This breaks the most trivial of
> examples, for example:
> -> double tau = Math.PI * 2;
> |  Added variable tau of type double with initial value 6.283185307179586
>
> -> System.out.println("Tau is: " + tau);
> An exception has occurred in the compiler (1.9.0-ea). Please file a
> bug against the Java compiler via the Java bug reporting page
> (http://bugreport.java.com) after checking the Bug Database
> (http://bugs.java.com) for duplicates. Include your program and the
> following diagnostic in your report. Thank you.
> java.lang.AssertionError
> at com.sun.tools.javac.util.Assert.error(Assert.java:155)
> at com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
> at com.sun.tools.javac.util.ListBuffer.append(ListBuffer.java:127)
> at com.sun.tools.javac.parser.JavacParser.arguments(JavacParser.java:1799)
> at com.sun.tools.javac.parser.JavacParser.arguments(JavacParser.java:1814)
> at com.sun.tools.javac.parser.JavacParser.term3(JavacParser.java:1276)
> at com.sun.tools.javac.parser.JavacParser.term2(JavacParser.java:902)
> at com.sun.tools.javac.parser.JavacParser.term1(JavacParser.java:873)
> at com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:829)
> at com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:809)
> at jdk.jshell.ReplParser.replUnit(ReplParser.java:225)
> at jdk.jshell.ReplParser.parseCompilationUnit(ReplParser.java:132)
> at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:601)
> at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:638)
> at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:930)
> at com.sun.tools.javac.api.JavacTaskImpl.parseInternal(JavacTaskImpl.java:233)
> at com.sun.tools.javac.api.JavacTaskImpl.access$400(JavacTaskImpl.java:69)
> at com.sun.tools.javac.api.JavacTaskImpl$2.call(JavacTaskImpl.java:225)
> at com.sun.tools.javac.api.JavacTaskImpl$2.call(JavacTaskImpl.java:222)
> at com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:128)
> at com.sun.tools.javac.api.JavacTaskImpl.parse(JavacTaskImpl.java:222)
> at jdk.jshell.TaskFactory$ParseTask.parse(TaskFactory.java:221)
> at jdk.jshell.TaskFactory$ParseTask.<init>(TaskFactory.java:207)
> at jdk.jshell.CompletenessAnalyzer$Parser.disambiguateDeclarationVsExpression(CompletenessAnalyzer.java:671)
> at jdk.jshell.CompletenessAnalyzer$Parser.parseUnit(CompletenessAnalyzer.java:615)
> at jdk.jshell.CompletenessAnalyzer.scan(CompletenessAnalyzer.java:87)
> at jdk.jshell.SourceCodeAnalysisImpl.analyzeCompletion(SourceCodeAnalysisImpl.java:133)
> at jdk.internal.jshell.tool.ConsoleIOContext$1.analyzeCompletion(ConsoleIOContext.java:77)
> at jdk.internal.jshell.tool.EditingHistory.add(EditingHistory.java:127)
> at jdk.internal.jline.console.ConsoleReader.finishBuffer(ConsoleReader.java:655)
> at jdk.internal.jline.console.ConsoleReader.accept(ConsoleReader.java:2027)
> at jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2695)
> at jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2277)
> at jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:153)
> at jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:447)
> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:266)
> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:245)
> at jdk.internal.jshell.tool.JShellTool.main(JShellTool.java:235)
>
> Is there something wrong with the way I've compiled/used the latest
> code? Or is the jshell actually broken at this point?
>
> Roy

From jan.lahoda at oracle.com  Mon Nov  2 11:59:36 2015
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 02 Nov 2015 12:59:36 +0100
Subject: Evaluation of String problem
In-Reply-To: <CAMJwwmvTXhJM-LXcdGdzGXaX-Ef+RZ=-_=ifbbt9gsZxz8_RPg@mail.gmail.com>
References: <CAMJwwmvTXhJM-LXcdGdzGXaX-Ef+RZ=-_=ifbbt9gsZxz8_RPg@mail.gmail.com>
Message-ID: <56375028.1050501@oracle.com>

Hello Roy,

This sounds like a problem in jdk9 javac (JDK-8139751) should be 
currently fixed in jdk9/dev:
http://hg.openjdk.java.net/jdk9/dev/langtools/rev/777c5a760a84

Please also note jshell is now integrated in jdk9/dev.

Thanks,
     Jan

On 2.11.2015 11:01, Roy van Rijn wrote:
> Dear kulla-devs,
>
> Trying the latest code from the kulla branch, and I've done the following:
> 1) Install JDK 9
> 2) Get latest sources: get_sources.sh
> 3) Modified script/compile.sh for OS/X (/bin instead of /usr/bin)
> 4) Modified script/compile.sh removed path
> ../src/jdk.jshell/share/classes/*/*/*/*/*/*.java (there doesnt seem to
> be a java file matching six stars)
> 5) Compile (no messages, works fine)
> 6) Modified script/run.sh for OS/X (/bin instead of /usr/bin)
> 7) Started jshell (although the version is: Version (version info not
> available))
>
> Next there seems to be a problem evaluating strings with the +
> operator, for example:
>
> -> String a = "a";
> |  Added variable a of type String with initial value "a"
> -> String b = "b";
> |  Added variable b of type String with initial value "b"
> -> String c = a + b;
> |  Added variable c of type String
> -> String d = "test " + " another test";
> |  Added variable d of type String
> -> System.out.println(a);
> a
> -> System.out.println(b);
> b
> -> System.out.println(c);
> null
> -> System.out.println(d);
> null
>
> Any idea what could be causing this? This breaks the most trivial of
> examples, for example:
> -> double tau = Math.PI * 2;
> |  Added variable tau of type double with initial value 6.283185307179586
>
> -> System.out.println("Tau is: " + tau);
> An exception has occurred in the compiler (1.9.0-ea). Please file a
> bug against the Java compiler via the Java bug reporting page
> (http://bugreport.java.com) after checking the Bug Database
> (http://bugs.java.com) for duplicates. Include your program and the
> following diagnostic in your report. Thank you.
> java.lang.AssertionError
> at com.sun.tools.javac.util.Assert.error(Assert.java:155)
> at com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
> at com.sun.tools.javac.util.ListBuffer.append(ListBuffer.java:127)
> at com.sun.tools.javac.parser.JavacParser.arguments(JavacParser.java:1799)
> at com.sun.tools.javac.parser.JavacParser.arguments(JavacParser.java:1814)
> at com.sun.tools.javac.parser.JavacParser.term3(JavacParser.java:1276)
> at com.sun.tools.javac.parser.JavacParser.term2(JavacParser.java:902)
> at com.sun.tools.javac.parser.JavacParser.term1(JavacParser.java:873)
> at com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:829)
> at com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:809)
> at jdk.jshell.ReplParser.replUnit(ReplParser.java:225)
> at jdk.jshell.ReplParser.parseCompilationUnit(ReplParser.java:132)
> at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:601)
> at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:638)
> at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:930)
> at com.sun.tools.javac.api.JavacTaskImpl.parseInternal(JavacTaskImpl.java:233)
> at com.sun.tools.javac.api.JavacTaskImpl.access$400(JavacTaskImpl.java:69)
> at com.sun.tools.javac.api.JavacTaskImpl$2.call(JavacTaskImpl.java:225)
> at com.sun.tools.javac.api.JavacTaskImpl$2.call(JavacTaskImpl.java:222)
> at com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:128)
> at com.sun.tools.javac.api.JavacTaskImpl.parse(JavacTaskImpl.java:222)
> at jdk.jshell.TaskFactory$ParseTask.parse(TaskFactory.java:221)
> at jdk.jshell.TaskFactory$ParseTask.<init>(TaskFactory.java:207)
> at jdk.jshell.CompletenessAnalyzer$Parser.disambiguateDeclarationVsExpression(CompletenessAnalyzer.java:671)
> at jdk.jshell.CompletenessAnalyzer$Parser.parseUnit(CompletenessAnalyzer.java:615)
> at jdk.jshell.CompletenessAnalyzer.scan(CompletenessAnalyzer.java:87)
> at jdk.jshell.SourceCodeAnalysisImpl.analyzeCompletion(SourceCodeAnalysisImpl.java:133)
> at jdk.internal.jshell.tool.ConsoleIOContext$1.analyzeCompletion(ConsoleIOContext.java:77)
> at jdk.internal.jshell.tool.EditingHistory.add(EditingHistory.java:127)
> at jdk.internal.jline.console.ConsoleReader.finishBuffer(ConsoleReader.java:655)
> at jdk.internal.jline.console.ConsoleReader.accept(ConsoleReader.java:2027)
> at jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2695)
> at jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2277)
> at jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:153)
> at jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:447)
> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:266)
> at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:245)
> at jdk.internal.jshell.tool.JShellTool.main(JShellTool.java:235)
>
> Is there something wrong with the way I've compiled/used the latest
> code? Or is the jshell actually broken at this point?
>
> Roy
>

From ville at misaki.fi  Mon Nov  2 12:55:43 2015
From: ville at misaki.fi (Ville Misaki)
Date: Mon, 2 Nov 2015 21:55:43 +0900
Subject: Named result variables
Message-ID: <CAMP1M+mrAuDn0jYK3jbozu_4s_GhBDpyn_NN_15yUtychdTqiQ@mail.gmail.com>

How about making the variable declaration optional? Or rather, the
interpreter auto-generating the declaration with type inference the first
time a previously-undeclared variable is assigned to.

E.g. from the earlier example:

   set1 = setOf(1, 2, 3);

the variable set1 would have the implied type of Set<Integer>.

Cheers,

Ville



> Keep in mind I'm open to any solution.
>
> Let me frame my idea as a strawman so it is easier to shoot arrows at :-)
>
> Think: source code transformations that IDEs sometimes do.
> So, in this case say, ...
> You type in a complex expression expr. Then you press ctrl-V. The tool
> generates the type typedecl and an equals sign and sticks the cursor
> between them so you can type the variable name:
>
>        typedecl. |   = expr:
>
> Where | represents the cursor position.
>
> Jan can tell me if this is even something jline can do.
>
> The idea is, like tab, you type characters which don't correspond to
valid
> Java, but what you see is valid.
>
> Of course what character is typed to initiate this is arbitrary.
>
> Ideas...
>
> -Robert
>
>
>
>On October 29, 2015 11:17:24 PM Robert Field <robert.field at oracle.com>
wrote:
>
>> Thanks Cay  putting this out for discussion, would love to come up with
>> some nice solution for this.  I would like to avoid something that
>> straddles the snippet and command worlds which are now distinct.
>>
>> I don't think I expressed my idea very clearly -- mostly because it
isn't
>> at all clear to me ;-)
>> What I was thinking was something vaguely tab completion like, in that
you
>> wind up looking at a well formed snippet not all of which you explicitly
>> typed. But not literally a tab nor completion.
>>
>> Thanks,
>> Robert
>>
>>
>> On October 29, 2015 6:50:46 PM Cay Horstmann <cay at horstmann.com>
wrote:
>>
>>> When I teach, I like to use jshell for quick demos. I might predefine
>>>
>>> <T> Set<T> setOf(T... values) { return new
>>> TreeSet<>(Arrays.asList(values)); }
>>>
>>> and then construct two sets:
>>>
>>> Set<Integer> set1 = setOf(1, 2, 3);
>>> Set<Integer> set2 = setOf(2, 3, 5);
>>> set1.removeAll(set2)
>>>
>>> Except, that's a lot of typing, so I don't do that. I do
>>>
>>> setOf(1, 2, 3);
>>> setOf(2, 3, 5);
>>> $1.removeAll($2)
>>>
>>> Note the absence of types. The $n are automatically typed.
>>>
>>> But I lose track of those $n prettty soon. It would be nice if i could
>>> name them.
>>>
>>> I brought this up at the Java One presentation and suggested
>>>
>>> /var set1 $1
>>>
>>> or
>>>
>>> /var set2
>>>
>>> to name the last $n.
>>>
>>> Robert thought that was a bit too much like inventing a new langauge
>>> feature and suggested that one might be able to solve this with tab
>>> completion instead.
>>>
>>> I thought about this a bit and couldn't come up with a compelling way.
>>> Right now, when one hits Tab on a blank line, one is offered a
>>> collection of well over 400 possible completions (types, packages,
>>> classes, $ variables). Using that to get to something like Set<Integer>
>>> or TreeMap<String, TreeSet<Integer>> isn't satisfactory.
>>>
>>> Does anyone else think that an easy way of naming results is worthwhile?
>>> Any ideas on what the user interface should be?
>>>
>>> Cheers,
>>>
>>> Cay
>>>
>>>
>>> --
>>>
>>> Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com

From ville at misaki.fi  Mon Nov  2 12:57:49 2015
From: ville at misaki.fi (Ville Misaki)
Date: Mon, 2 Nov 2015 21:57:49 +0900
Subject: Named result variables
In-Reply-To: <CAMP1M+mrAuDn0jYK3jbozu_4s_GhBDpyn_NN_15yUtychdTqiQ@mail.gmail.com>
References: <CAMP1M+mrAuDn0jYK3jbozu_4s_GhBDpyn_NN_15yUtychdTqiQ@mail.gmail.com>
Message-ID: <CAMP1M+k0_L71s3=dssU5VT9wkBHJBjdej_kLEZtW9_aza1R-_g@mail.gmail.com>

How about making the variable declaration optional? Or rather, the
interpreter auto-generating the declaration with type inference the first
time a previously-undeclared variable is assigned to.

E.g. the earlier example would be:

set1 = setOf(1, 2, 3);

With the set1 having the implied type Set<Integer>.

Cheers,

Ville



> Keep in mind I'm open to any solution.
>
> Let me frame my idea as a strawman so it is easier to shoot arrows at :-)
>
> Think: source code transformations that IDEs sometimes do.
> So, in this case say, ...
> You type in a complex expression expr. Then you press ctrl-V. The tool
> generates the type typedecl and an equals sign and sticks the cursor
> between them so you can type the variable name:
>
>        typedecl. |   = expr:
>
> Where | represents the cursor position.
>
> Jan can tell me if this is even something jline can do.
>
> The idea is, like tab, you type characters which don't correspond to
valid
> Java, but what you see is valid.
>
> Of course what character is typed to initiate this is arbitrary.
>
> Ideas...
>
> -Robert
>
>
>
>On October 29, 2015 11:17:24 PM Robert Field <robert.field at oracle.com>
wrote:
>
>> Thanks Cay  putting this out for discussion, would love to come up with
>> some nice solution for this.  I would like to avoid something that
>> straddles the snippet and command worlds which are now distinct.
>>
>> I don't think I expressed my idea very clearly -- mostly because it
isn't
>> at all clear to me ;-)
>> What I was thinking was something vaguely tab completion like, in that
you
>> wind up looking at a well formed snippet not all of which you explicitly
>> typed. But not literally a tab nor completion.
>>
>> Thanks,
>> Robert
>>
>>
>> On October 29, 2015 6:50:46 PM Cay Horstmann <cay at horstmann.com>
wrote:
>>
>>> When I teach, I like to use jshell for quick demos. I might predefine
>>>
>>> <T> Set<T> setOf(T... values) { return new
>>> TreeSet<>(Arrays.asList(values)); }
>>>
>>> and then construct two sets:
>>>
>>> Set<Integer> set1 = setOf(1, 2, 3);
>>> Set<Integer> set2 = setOf(2, 3, 5);
>>> set1.removeAll(set2)
>>>
>>> Except, that's a lot of typing, so I don't do that. I do
>>>
>>> setOf(1, 2, 3);
>>> setOf(2, 3, 5);
>>> $1.removeAll($2)
>>>
>>> Note the absence of types. The $n are automatically typed.
>>>
>>> But I lose track of those $n prettty soon. It would be nice if i could
>>> name them.
>>>
>>> I brought this up at the Java One presentation and suggested
>>>
>>> /var set1 $1
>>>
>>> or
>>>
>>> /var set2
>>>
>>> to name the last $n.
>>>
>>> Robert thought that was a bit too much like inventing a new langauge
>>> feature and suggested that one might be able to solve this with tab
>>> completion instead.
>>>
>>> I thought about this a bit and couldn't come up with a compelling way.
>>> Right now, when one hits Tab on a blank line, one is offered a
>>> collection of well over 400 possible completions (types, packages,
>>> classes, $ variables). Using that to get to something like Set<Integer>
>>> or TreeMap<String, TreeSet<Integer>> isn't satisfactory.
>>>
>>> Does anyone else think that an easy way of naming results is worthwhile?
>>> Any ideas on what the user interface should be?
>>>
>>> Cheers,
>>>
>>> Cay
>>>
>>>
>>> --
>>>
>>> Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com

From jan.lahoda at oracle.com  Mon Nov  2 15:07:35 2015
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 02 Nov 2015 16:07:35 +0100
Subject: Named result variables
In-Reply-To: <150b78193f0.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
References: <5632B8C0.7050300@horstmann.com>	<150b764b938.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<150b78193f0.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
Message-ID: <56377C37.7020002@oracle.com>

Hi Robert,

Attached is a crude prototype implementing the proposal - the shortcut 
to active the function is Alt-Enter.

(Many things, like using simple names whenever possible, could be 
improved in the prototype, but hopefully good enough for experimenting.)

Jan

On 30.10.2015 07:48, Robert Field wrote:
> Keep in mind I'm open to any solution.
>
> Let me frame my idea as a strawman so it is easier to shoot arrows at :-)
>
> Think: source code transformations that IDEs sometimes do.
> So, in this case say, ...
> You type in a complex expression expr. Then you press ctrl-V. The tool
> generates the type typedecl and an equals sign and sticks the cursor
> between them so you can type the variable name:
>
>        typedecl. |   = expr:
>
> Where | represents the cursor position.
>
> Jan can tell me if this is even something jline can do.
>
> The idea is, like tab, you type characters which don't correspond to
> valid Java, but what you see is valid.
>
> Of course what character is typed to initiate this is arbitrary.
>
> Ideas...
>
> -Robert
>
>
>
> On October 29, 2015 11:17:24 PM Robert Field <robert.field at oracle.com>
> wrote:
>
>> Thanks Cay  putting this out for discussion, would love to come up
>> with some nice solution for this.  I would like to avoid something
>> that straddles the snippet and command worlds which are now distinct.
>>
>> I don't think I expressed my idea very clearly -- mostly because it
>> isn't at all clear to me ;-)
>> What I was thinking was something vaguely tab completion like, in that
>> you wind up looking at a well formed snippet not all of which you
>> explicitly typed. But not literally a tab nor completion.
>>
>> Thanks,
>> Robert
>>
>>
>> On October 29, 2015 6:50:46 PM Cay Horstmann <cay at horstmann.com> wrote:
>>
>>> When I teach, I like to use jshell for quick demos. I might predefine
>>>
>>> <T> Set<T> setOf(T... values) { return new
>>> TreeSet<>(Arrays.asList(values)); }
>>>
>>> and then construct two sets:
>>>
>>> Set<Integer> set1 = setOf(1, 2, 3);
>>> Set<Integer> set2 = setOf(2, 3, 5);
>>> set1.removeAll(set2)
>>>
>>> Except, that's a lot of typing, so I don't do that. I do
>>>
>>> setOf(1, 2, 3);
>>> setOf(2, 3, 5);
>>> $1.removeAll($2)
>>>
>>> Note the absence of types. The $n are automatically typed.
>>>
>>> But I lose track of those $n prettty soon. It would be nice if i could
>>> name them.
>>>
>>> I brought this up at the Java One presentation and suggested
>>>
>>> /var set1 $1
>>>
>>> or
>>>
>>> /var set2
>>>
>>> to name the last $n.
>>>
>>> Robert thought that was a bit too much like inventing a new langauge
>>> feature and suggested that one might be able to solve this with tab
>>> completion instead.
>>>
>>> I thought about this a bit and couldn't come up with a compelling way.
>>> Right now, when one hits Tab on a blank line, one is offered a
>>> collection of well over 400 possible completions (types, packages,
>>> classes, $ variables). Using that to get to something like Set<Integer>
>>> or TreeMap<String, TreeSet<Integer>> isn't satisfactory.
>>>
>>> Does anyone else think that an easy way of naming results is worthwhile?
>>> Any ideas on what the user interface should be?
>>>
>>> Cheers,
>>>
>>> Cay
>>>
>>>
>>> --
>>>
>>> Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com
-------------- next part --------------
# HG changeset patch
# Parent  986a7f7a5601514afbe9c500f3391cc8f8b6029b

diff -r 986a7f7a5601 -r 45237629888e src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java
--- a/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java	Mon Nov 02 15:04:30 2015 +0100
+++ b/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java	Mon Nov 02 15:57:52 2015 +0100
@@ -144,6 +144,7 @@
         bind(DOCUMENTATION_SHORTCUT, (ActionListener) evt -> documentation(repl));
         bind(CTRL_UP, (ActionListener) evt -> moveHistoryToSnippet(((EditingHistory) in.getHistory())::previousSnippet));
         bind(CTRL_DOWN, (ActionListener) evt -> moveHistoryToSnippet(((EditingHistory) in.getHistory())::nextSnippet));
+        bind(ALT_ENTER, (ActionListener) evt -> computeType());
     }
 
     @Override
@@ -216,6 +217,7 @@
     private static final String DOCUMENTATION_SHORTCUT = "\033\133\132"; //Shift-TAB
     private static final String CTRL_UP = "\033\133\061\073\065\101"; //Ctrl-UP
     private static final String CTRL_DOWN = "\033\133\061\073\065\102"; //Ctrl-DOWN
+    private static final String ALT_ENTER = "\033\015"; //Alt-ENTER
 
     private void documentation(JShellTool repl) {
         String buffer = in.getCursorBuffer().buffer.toString();
@@ -290,6 +292,17 @@
         history.fullHistoryReplace(source);
     }
 
+    private void computeType() {
+        try {
+            String type = this.repl.analysis.analyzeType(prefix + in.getCursorBuffer().upToCursor());
+            in.setCursorPosition(0);
+            in.putString(type + "  = ");
+            in.setCursorPosition(in.getCursorBuffer().cursor - 3);
+        } catch (IOException ex) {
+            ex.printStackTrace();
+        }
+    }
+
     private static final class JShellUnixTerminal extends NoInterruptUnixTerminal {
 
         private final StopDetectingInputStream input;
diff -r 986a7f7a5601 -r 45237629888e src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java
--- a/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java	Mon Nov 02 15:04:30 2015 +0100
+++ b/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java	Mon Nov 02 15:57:52 2015 +0100
@@ -74,6 +74,8 @@
      */
     SourceCodeAnalysis() {}
 
+    public abstract String analyzeType(String string);
+
     /**
      * The result of <code>analyzeCompletion(String input)</code>.
      * Describes the completeness and position of the first snippet in the given input.
diff -r 986a7f7a5601 -r 45237629888e src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java
--- a/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java	Mon Nov 02 15:04:30 2015 +0100
+++ b/src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java	Mon Nov 02 15:57:52 2015 +0100
@@ -1184,4 +1184,31 @@
         }
         return arrayType;
     }
+
+    @Override
+    public String analyzeType(String code) {
+        //?:
+        if (code.trim().isEmpty()) { //TODO: comment handling
+            code += ";";
+        }
+        OuterWrap codeWrap;
+        switch (guessKind(code)) {
+            case IMPORT:
+                codeWrap = OuterWrap.wrapImport(null, Wrap.importWrap(code + "any.any"));
+                break;
+            case METHOD:
+                codeWrap = wrapInClass(Wrap.classMemberWrap(code));
+                break;
+            default:
+                codeWrap = wrapInClass(Wrap.methodWrap(code));
+                break;
+        }
+        AnalyzeTask at = proc.taskFactory.new AnalyzeTask(codeWrap);
+        SourcePositions sp = at.trees().getSourcePositions();
+        CompilationUnitTree topLevel = at.cuTree();
+        TreePath tp = pathFor(topLevel, sp, codeWrap.snippetIndexToWrapIndex(code.length()));
+
+        return at.trees().getTypeMirror(tp).toString();
+    }
+
 }

From robert.field at oracle.com  Mon Nov  2 19:28:21 2015
From: robert.field at oracle.com (Robert Field)
Date: Mon, 2 Nov 2015 11:28:21 -0800
Subject: Named result variables
In-Reply-To: <56377C37.7020002@oracle.com>
References: <5632B8C0.7050300@horstmann.com>
	<150b764b938.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<150b78193f0.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<56377C37.7020002@oracle.com>
Message-ID: <89529C25-8403-4CBD-913F-1B0F8B3DD1E8@oracle.com>

That was fast!  :-)

I can?t get it to work on mac. Tried 3+4 then option-enter, command-enter, shift-option-enter, ctrl-option-enter, or ctrl-command-option-enter, and a few others.

Will try on Linux?

On merge I get this:

$ patch -p1 < ~/work/complete-variable-prototype.diff 
patching file src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java
patching file src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java
patching file src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java
Hunk #1 succeeded at 997 (offset -187 lines).

Could that be my problem?

-Robert

> On Nov 2, 2015, at 7:07 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
> 
> Hi Robert,
> 
> Attached is a crude prototype implementing the proposal - the shortcut to active the function is Alt-Enter.
> 
> (Many things, like using simple names whenever possible, could be improved in the prototype, but hopefully good enough for experimenting.)
> 
> Jan
> 
> On 30.10.2015 07:48, Robert Field wrote:
>> Keep in mind I'm open to any solution.
>> 
>> Let me frame my idea as a strawman so it is easier to shoot arrows at :-)
>> 
>> Think: source code transformations that IDEs sometimes do.
>> So, in this case say, ...
>> You type in a complex expression expr. Then you press ctrl-V. The tool
>> generates the type typedecl and an equals sign and sticks the cursor
>> between them so you can type the variable name:
>> 
>>       typedecl. |   = expr:
>> 
>> Where | represents the cursor position.
>> 
>> Jan can tell me if this is even something jline can do.
>> 
>> The idea is, like tab, you type characters which don't correspond to
>> valid Java, but what you see is valid.
>> 
>> Of course what character is typed to initiate this is arbitrary.
>> 
>> Ideas...
>> 
>> -Robert
>> 
>> 
>> 
>> On October 29, 2015 11:17:24 PM Robert Field <robert.field at oracle.com>
>> wrote:
>> 
>>> Thanks Cay  putting this out for discussion, would love to come up
>>> with some nice solution for this.  I would like to avoid something
>>> that straddles the snippet and command worlds which are now distinct.
>>> 
>>> I don't think I expressed my idea very clearly -- mostly because it
>>> isn't at all clear to me ;-)
>>> What I was thinking was something vaguely tab completion like, in that
>>> you wind up looking at a well formed snippet not all of which you
>>> explicitly typed. But not literally a tab nor completion.
>>> 
>>> Thanks,
>>> Robert
>>> 
>>> 
>>> On October 29, 2015 6:50:46 PM Cay Horstmann <cay at horstmann.com> wrote:
>>> 
>>>> When I teach, I like to use jshell for quick demos. I might predefine
>>>> 
>>>> <T> Set<T> setOf(T... values) { return new
>>>> TreeSet<>(Arrays.asList(values)); }
>>>> 
>>>> and then construct two sets:
>>>> 
>>>> Set<Integer> set1 = setOf(1, 2, 3);
>>>> Set<Integer> set2 = setOf(2, 3, 5);
>>>> set1.removeAll(set2)
>>>> 
>>>> Except, that's a lot of typing, so I don't do that. I do
>>>> 
>>>> setOf(1, 2, 3);
>>>> setOf(2, 3, 5);
>>>> $1.removeAll($2)
>>>> 
>>>> Note the absence of types. The $n are automatically typed.
>>>> 
>>>> But I lose track of those $n prettty soon. It would be nice if i could
>>>> name them.
>>>> 
>>>> I brought this up at the Java One presentation and suggested
>>>> 
>>>> /var set1 $1
>>>> 
>>>> or
>>>> 
>>>> /var set2
>>>> 
>>>> to name the last $n.
>>>> 
>>>> Robert thought that was a bit too much like inventing a new langauge
>>>> feature and suggested that one might be able to solve this with tab
>>>> completion instead.
>>>> 
>>>> I thought about this a bit and couldn't come up with a compelling way.
>>>> Right now, when one hits Tab on a blank line, one is offered a
>>>> collection of well over 400 possible completions (types, packages,
>>>> classes, $ variables). Using that to get to something like Set<Integer>
>>>> or TreeMap<String, TreeSet<Integer>> isn't satisfactory.
>>>> 
>>>> Does anyone else think that an easy way of naming results is worthwhile?
>>>> Any ideas on what the user interface should be?
>>>> 
>>>> Cheers,
>>>> 
>>>> Cay
>>>> 
>>>> 
>>>> --
>>>> 
>>>> Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com
> <complete-variable-prototype.txt>


From ville at misaki.fi  Mon Nov  2 23:57:41 2015
From: ville at misaki.fi (Ville Misaki)
Date: Tue, 3 Nov 2015 08:57:41 +0900
Subject: Named result variables
In-Reply-To: <89529C25-8403-4CBD-913F-1B0F8B3DD1E8@oracle.com>
References: <5632B8C0.7050300@horstmann.com>
	<150b764b938.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<150b78193f0.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<56377C37.7020002@oracle.com>
	<89529C25-8403-4CBD-913F-1B0F8B3DD1E8@oracle.com>
Message-ID: <CAMP1M+m-o_dYAj3_JOO3X2J1YKK0dAMv7FTokc1ZQmK_1w8W2Q@mail.gmail.com>

Seems to work great on mac also, just have to press ESC and enter.

It doesn't seem to take the context that much into account, e.g. if I
already have a variable declaration on the row, it still adds the type and
equal sign (without variable name) in the beginning -- and will crash if
accidentally doing twice in a row.

E.g.

  -> "text"
  // alt-enter
  -> java.lang.String  = "text"
  // fill in variable manually
  -> java.lang.String var = "text"
  // alt-enter
  -> java.lang.String  = java.lang.String var = "text"
  // alt-enter
  -> java.lang.String [ERROR] Exception while running registered action
  java.lang.reflect.InvocationTargetException
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
          at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
          at java.lang.reflect.Method.invoke(Method.java:520)
          at
jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2490)
          at
jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2277)
          at
jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:154)
          at jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:447)
          at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:266)
          at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:245)
          at jdk.internal.jshell.tool.JShellTool.main(JShellTool.java:235)
  Caused by: java.lang.NullPointerException
          at
jdk.jshell.SourceCodeAnalysisImpl.analyzeType(SourceCodeAnalysisImpl.java:1024)
          at
jdk.internal.jshell.tool.ConsoleIOContext.computeType(ConsoleIOContext.java:297)
          at
jdk.internal.jshell.tool.ConsoleIOContext.lambda$new$5(ConsoleIOContext.java:147)
          ... 11 more


Cheers,

Ville




On Tue, Nov 3, 2015 at 4:28 AM, Robert Field <robert.field at oracle.com>
wrote:

> That was fast!  :-)
>
> I can?t get it to work on mac. Tried 3+4 then option-enter, command-enter,
> shift-option-enter, ctrl-option-enter, or ctrl-command-option-enter, and a
> few others.
>
> Will try on Linux?
>
> On merge I get this:
>
> $ patch -p1 < ~/work/complete-variable-prototype.diff
> patching file
> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java
> patching file
> src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java
> patching file
> src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java
> Hunk #1 succeeded at 997 (offset -187 lines).
>
> Could that be my problem?
>
> -Robert
>
> > On Nov 2, 2015, at 7:07 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
> >
> > Hi Robert,
> >
> > Attached is a crude prototype implementing the proposal - the shortcut
> to active the function is Alt-Enter.
> >
> > (Many things, like using simple names whenever possible, could be
> improved in the prototype, but hopefully good enough for experimenting.)
> >
> > Jan
> >
> > On 30.10.2015 07:48, Robert Field wrote:
> >> Keep in mind I'm open to any solution.
> >>
> >> Let me frame my idea as a strawman so it is easier to shoot arrows at
> :-)
> >>
> >> Think: source code transformations that IDEs sometimes do.
> >> So, in this case say, ...
> >> You type in a complex expression expr. Then you press ctrl-V. The tool
> >> generates the type typedecl and an equals sign and sticks the cursor
> >> between them so you can type the variable name:
> >>
> >>       typedecl. |   = expr:
> >>
> >> Where | represents the cursor position.
> >>
> >> Jan can tell me if this is even something jline can do.
> >>
> >> The idea is, like tab, you type characters which don't correspond to
> >> valid Java, but what you see is valid.
> >>
> >> Of course what character is typed to initiate this is arbitrary.
> >>
> >> Ideas...
> >>
> >> -Robert
> >>
> >>
> >>
> >> On October 29, 2015 11:17:24 PM Robert Field <robert.field at oracle.com>
> >> wrote:
> >>
> >>> Thanks Cay  putting this out for discussion, would love to come up
> >>> with some nice solution for this.  I would like to avoid something
> >>> that straddles the snippet and command worlds which are now distinct.
> >>>
> >>> I don't think I expressed my idea very clearly -- mostly because it
> >>> isn't at all clear to me ;-)
> >>> What I was thinking was something vaguely tab completion like, in that
> >>> you wind up looking at a well formed snippet not all of which you
> >>> explicitly typed. But not literally a tab nor completion.
> >>>
> >>> Thanks,
> >>> Robert
> >>>
> >>>
> >>> On October 29, 2015 6:50:46 PM Cay Horstmann <cay at horstmann.com>
> wrote:
> >>>
> >>>> When I teach, I like to use jshell for quick demos. I might predefine
> >>>>
> >>>> <T> Set<T> setOf(T... values) { return new
> >>>> TreeSet<>(Arrays.asList(values)); }
> >>>>
> >>>> and then construct two sets:
> >>>>
> >>>> Set<Integer> set1 = setOf(1, 2, 3);
> >>>> Set<Integer> set2 = setOf(2, 3, 5);
> >>>> set1.removeAll(set2)
> >>>>
> >>>> Except, that's a lot of typing, so I don't do that. I do
> >>>>
> >>>> setOf(1, 2, 3);
> >>>> setOf(2, 3, 5);
> >>>> $1.removeAll($2)
> >>>>
> >>>> Note the absence of types. The $n are automatically typed.
> >>>>
> >>>> But I lose track of those $n prettty soon. It would be nice if i could
> >>>> name them.
> >>>>
> >>>> I brought this up at the Java One presentation and suggested
> >>>>
> >>>> /var set1 $1
> >>>>
> >>>> or
> >>>>
> >>>> /var set2
> >>>>
> >>>> to name the last $n.
> >>>>
> >>>> Robert thought that was a bit too much like inventing a new langauge
> >>>> feature and suggested that one might be able to solve this with tab
> >>>> completion instead.
> >>>>
> >>>> I thought about this a bit and couldn't come up with a compelling way.
> >>>> Right now, when one hits Tab on a blank line, one is offered a
> >>>> collection of well over 400 possible completions (types, packages,
> >>>> classes, $ variables). Using that to get to something like
> Set<Integer>
> >>>> or TreeMap<String, TreeSet<Integer>> isn't satisfactory.
> >>>>
> >>>> Does anyone else think that an easy way of naming results is
> worthwhile?
> >>>> Any ideas on what the user interface should be?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Cay
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com
> > <complete-variable-prototype.txt>
>
>

From robert.field at oracle.com  Tue Nov  3 07:04:29 2015
From: robert.field at oracle.com (Robert Field)
Date: Mon, 2 Nov 2015 23:04:29 -0800
Subject: Named result variables
In-Reply-To: <CAMP1M+m-o_dYAj3_JOO3X2J1YKK0dAMv7FTokc1ZQmK_1w8W2Q@mail.gmail.com>
References: <5632B8C0.7050300@horstmann.com>
	<150b764b938.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<150b78193f0.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
	<56377C37.7020002@oracle.com>
	<89529C25-8403-4CBD-913F-1B0F8B3DD1E8@oracle.com>
	<CAMP1M+m-o_dYAj3_JOO3X2J1YKK0dAMv7FTokc1ZQmK_1w8W2Q@mail.gmail.com>
Message-ID: <FE48207F-41F0-4240-97BA-AD6356C0AF0C@oracle.com>

Ville, thanks for the ESC then Enter suggestion, it works!

Jan, this is great!

A sign of cool new stuff ? lots of suggestions ?

Seems it tries to work with any input, including complete garbage.  I?d suggest it only work with valid expressions.  Perhaps beep/flash if it isn?t.

Nit: There is is code for type names to trim out package names that are imported: SnippetMaps.fullClassNameAndPackageToClass(), which is used by Eval.typeOfExpression() which might be exactly what you need for the previous paragraph (returns null if not a valid expression).  

Currently 

new ArrayList<String>()
//alt-enter

becomes:

java.util.ArrayList<java.lang.String> s = new ArrayList<String>()

where it would become:

ArrayList<String> s = new ArrayList<String>()

-Robert





> On Nov 2, 2015, at 3:57 PM, Ville Misaki <ville at misaki.fi> wrote:
> 
> Seems to work great on mac also, just have to press ESC and enter.
> 
> It doesn't seem to take the context that much into account, e.g. if I already have a variable declaration on the row, it still adds the type and equal sign (without variable name) in the beginning -- and will crash if accidentally doing twice in a row.
> 
> E.g.
> 
>   -> "text"
>   // alt-enter
>   -> java.lang.String  = "text"
>   // fill in variable manually
>   -> java.lang.String var = "text"
>   // alt-enter
>   -> java.lang.String  = java.lang.String var = "text"
>   // alt-enter
>   -> java.lang.String [ERROR] Exception while running registered action
>   java.lang.reflect.InvocationTargetException
>           at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>           at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>           at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>           at java.lang.reflect.Method.invoke(Method.java:520)
>           at jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2490)
>           at jdk.internal.jline.console.ConsoleReader.readLine(ConsoleReader.java:2277)
>           at jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:154)
>           at jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:447)
>           at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:266)
>           at jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:245)
>           at jdk.internal.jshell.tool.JShellTool.main(JShellTool.java:235)
>   Caused by: java.lang.NullPointerException
>           at jdk.jshell.SourceCodeAnalysisImpl.analyzeType(SourceCodeAnalysisImpl.java:1024)
>           at jdk.internal.jshell.tool.ConsoleIOContext.computeType(ConsoleIOContext.java:297)
>           at jdk.internal.jshell.tool.ConsoleIOContext.lambda$new$5(ConsoleIOContext.java:147)
>           ... 11 more
> 
> 
> Cheers,
> 
> Ville
> 
> 
> 
> 
> On Tue, Nov 3, 2015 at 4:28 AM, Robert Field <robert.field at oracle.com <mailto:robert.field at oracle.com>> wrote:
> That was fast!  :-)
> 
> I can?t get it to work on mac. Tried 3+4 then option-enter, command-enter, shift-option-enter, ctrl-option-enter, or ctrl-command-option-enter, and a few others.
> 
> Will try on Linux?
> 
> On merge I get this:
> 
> $ patch -p1 < ~/work/complete-variable-prototype.diff
> patching file src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java
> patching file src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java
> patching file src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java
> Hunk #1 succeeded at 997 (offset -187 lines).
> 
> Could that be my problem?
> 
> -Robert
> 
> > On Nov 2, 2015, at 7:07 AM, Jan Lahoda <jan.lahoda at oracle.com <mailto:jan.lahoda at oracle.com>> wrote:
> >
> > Hi Robert,
> >
> > Attached is a crude prototype implementing the proposal - the shortcut to active the function is Alt-Enter.
> >
> > (Many things, like using simple names whenever possible, could be improved in the prototype, but hopefully good enough for experimenting.)
> >
> > Jan
> >
> > On 30.10.2015 07:48, Robert Field wrote:
> >> Keep in mind I'm open to any solution.
> >>
> >> Let me frame my idea as a strawman so it is easier to shoot arrows at :-)
> >>
> >> Think: source code transformations that IDEs sometimes do.
> >> So, in this case say, ...
> >> You type in a complex expression expr. Then you press ctrl-V. The tool
> >> generates the type typedecl and an equals sign and sticks the cursor
> >> between them so you can type the variable name:
> >>
> >>       typedecl. |   = expr:
> >>
> >> Where | represents the cursor position.
> >>
> >> Jan can tell me if this is even something jline can do.
> >>
> >> The idea is, like tab, you type characters which don't correspond to
> >> valid Java, but what you see is valid.
> >>
> >> Of course what character is typed to initiate this is arbitrary.
> >>
> >> Ideas...
> >>
> >> -Robert
> >>
> >>
> >>
> >> On October 29, 2015 11:17:24 PM Robert Field <robert.field at oracle.com <mailto:robert.field at oracle.com>>
> >> wrote:
> >>
> >>> Thanks Cay  putting this out for discussion, would love to come up
> >>> with some nice solution for this.  I would like to avoid something
> >>> that straddles the snippet and command worlds which are now distinct.
> >>>
> >>> I don't think I expressed my idea very clearly -- mostly because it
> >>> isn't at all clear to me ;-)
> >>> What I was thinking was something vaguely tab completion like, in that
> >>> you wind up looking at a well formed snippet not all of which you
> >>> explicitly typed. But not literally a tab nor completion.
> >>>
> >>> Thanks,
> >>> Robert
> >>>
> >>>
> >>> On October 29, 2015 6:50:46 PM Cay Horstmann <cay at horstmann.com <mailto:cay at horstmann.com>> wrote:
> >>>
> >>>> When I teach, I like to use jshell for quick demos. I might predefine
> >>>>
> >>>> <T> Set<T> setOf(T... values) { return new
> >>>> TreeSet<>(Arrays.asList(values)); }
> >>>>
> >>>> and then construct two sets:
> >>>>
> >>>> Set<Integer> set1 = setOf(1, 2, 3);
> >>>> Set<Integer> set2 = setOf(2, 3, 5);
> >>>> set1.removeAll(set2)
> >>>>
> >>>> Except, that's a lot of typing, so I don't do that. I do
> >>>>
> >>>> setOf(1, 2, 3);
> >>>> setOf(2, 3, 5);
> >>>> $1.removeAll($2)
> >>>>
> >>>> Note the absence of types. The $n are automatically typed.
> >>>>
> >>>> But I lose track of those $n prettty soon. It would be nice if i could
> >>>> name them.
> >>>>
> >>>> I brought this up at the Java One presentation and suggested
> >>>>
> >>>> /var set1 $1
> >>>>
> >>>> or
> >>>>
> >>>> /var set2
> >>>>
> >>>> to name the last $n.
> >>>>
> >>>> Robert thought that was a bit too much like inventing a new langauge
> >>>> feature and suggested that one might be able to solve this with tab
> >>>> completion instead.
> >>>>
> >>>> I thought about this a bit and couldn't come up with a compelling way.
> >>>> Right now, when one hits Tab on a blank line, one is offered a
> >>>> collection of well over 400 possible completions (types, packages,
> >>>> classes, $ variables). Using that to get to something like Set<Integer>
> >>>> or TreeMap<String, TreeSet<Integer>> isn't satisfactory.
> >>>>
> >>>> Does anyone else think that an easy way of naming results is worthwhile?
> >>>> Any ideas on what the user interface should be?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Cay
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Cay S. Horstmann | http://horstmann.com <http://horstmann.com/> | mailto:cay at horstmann.com <mailto:cay at horstmann.com>
> > <complete-variable-prototype.txt>
> 
> 


From roy.van.rijn at gmail.com  Tue Nov  3 14:58:37 2015
From: roy.van.rijn at gmail.com (Roy van Rijn)
Date: Tue, 3 Nov 2015 06:58:37 -0800
Subject: Non-interactive flag?
Message-ID: <CAMJwwmuT+rMF-aMXhfNs+FKgCjTL5Q_eX2u123UfaodCnqh0SQ@mail.gmail.com>

I've started using JShell now, not just as a REPL, but as method for
easy scripting. Using the 'new' Files API it is very easy to write
scripts that manipulate files for example in the Java language we all
know and love.

The only 'problem' I've encountered is the following, I'd like to call
JShell with an input file and don't want it end up in the REPL with a
prompt. The only way to prevent this is to end the 'script' with
'/exit'.

IMHO it would be nice to have a command line option to just run a
script and don't go into REPL/prompt mode afterwards?


p.s. Congratulations to everyone, JShell is now available to everyone
in the latest JDK 9 build (b90)

From john.r.rose at oracle.com  Tue Nov  3 18:57:00 2015
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 3 Nov 2015 10:57:00 -0800
Subject: Non-interactive flag?
In-Reply-To: <CAMJwwmuT+rMF-aMXhfNs+FKgCjTL5Q_eX2u123UfaodCnqh0SQ@mail.gmail.com>
References: <CAMJwwmuT+rMF-aMXhfNs+FKgCjTL5Q_eX2u123UfaodCnqh0SQ@mail.gmail.com>
Message-ID: <34700C07-6635-4728-B3F4-54F5C4B8DD07@oracle.com>

On Nov 3, 2015, at 6:58 AM, Roy van Rijn <roy.van.rijn at gmail.com <mailto:roy.van.rijn at gmail.com>> wrote:
> 
> IMHO it would be nice to have a command line option to just run a
> script and don't go into REPL/prompt mode afterwards?

+1; good for testing also

It's a gigantic slippery slope to put in Unix-y shell features, but still the basic CLI options make sense here too (sh -c -i -v -x ...).

> p.s. Congratulations to everyone, JShell is now available to everyone
> in the latest JDK 9 build (b90)

+1000

From bitterfoxc at gmail.com  Wed Nov  4 01:02:58 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Wed, 4 Nov 2015 10:02:58 +0900
Subject: RFR 8141366: JShell API / tool: Couldn't determine import info
	exactly with some spaces in the qualifier
Message-ID: <CAHjBcHMXjxrOZdH2F8QxfwOOWk0430aWYVmH1LMi8qRDe=NtDg@mail.gmail.com>

Hi Robert,
Could you review this and commit to jdk9?

webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8141366/webrev.00/
bugs: https://bugs.openjdk.java.net/browse/JDK-8141366

Regards,
shinyafox(Shinya Yoshida)

From robert.field at oracle.com  Wed Nov  4 07:38:29 2015
From: robert.field at oracle.com (Robert Field)
Date: Tue, 03 Nov 2015 23:38:29 -0800
Subject: RFR 8141366: JShell API / tool: Couldn't determine import info
	exactly with some spaces in the qualifier
In-Reply-To: <CAHjBcHMXjxrOZdH2F8QxfwOOWk0430aWYVmH1LMi8qRDe=NtDg@mail.gmail.com>
References: <CAHjBcHMXjxrOZdH2F8QxfwOOWk0430aWYVmH1LMi8qRDe=NtDg@mail.gmail.com>
Message-ID: <150d16ec120.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Thanks for catching this problem.

Could it be fixed, with much less code, by simply removing whitespace?

Thanks,
Robert



On November 3, 2015 5:03:33 PM ShinyaYoshida <bitterfoxc at gmail.com> wrote:

> Hi Robert,
> Could you review this and commit to jdk9?
>
> webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8141366/webrev.00/
> bugs: https://bugs.openjdk.java.net/browse/JDK-8141366
>
> Regards,
> shinyafox(Shinya Yoshida)



From bitterfoxc at gmail.com  Wed Nov  4 11:02:15 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Wed, 4 Nov 2015 20:02:15 +0900
Subject: RFR 8141366: JShell API / tool: Couldn't determine import info
	exactly with some spaces in the qualifier
In-Reply-To: <150d16ec120.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
References: <CAHjBcHMXjxrOZdH2F8QxfwOOWk0430aWYVmH1LMi8qRDe=NtDg@mail.gmail.com>
	<150d16ec120.2784.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
Message-ID: <CAHjBcHMD3tLSDe1EsgZXWfyd_bAsrsZdMAderGvOyxRPFVd7ow@mail.gmail.com>

Hi,
When I create the patch, I think that we have to treat some other ignored
elements such as comment-out.
But actually comment-out is already replaced with whitespaces
in compileSource.
So removing whitespaces is most simple and enough to fix this problem.

I've updated my patch, changing the fix and adding somo more test.
webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8141366/webrev.01/

Regards,
shinyafox(Shinya Yoshida)



2015-11-04 16:38 GMT+09:00 Robert Field <robert.field at oracle.com>:

> Thanks for catching this problem.
>
> Could it be fixed, with much less code, by simply removing whitespace?
>
> Thanks,
> Robert
>
>
>
>
> On November 3, 2015 5:03:33 PM ShinyaYoshida <bitterfoxc at gmail.com> wrote:
>
> Hi Robert,
>> Could you review this and commit to jdk9?
>>
>> webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8141366/webrev.00/
>> bugs: https://bugs.openjdk.java.net/browse/JDK-8141366
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>
>
>

From bitterfoxc at gmail.com  Wed Nov  4 11:54:37 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Wed, 4 Nov 2015 20:54:37 +0900
Subject: RFR 8141415: JShell API: wrap erroneous with one-liner comment-outed
	imports
Message-ID: <CAHjBcHNxhewUaG5LO2h9YzCe2r58S0Y5CrHQv6NGxTrAjc7Jjw@mail.gmail.com>

Hi Robert,
Please review this:

Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8141415/webrev.00/
Bugs: https://bugs.openjdk.java.net/browse/JDK-8141415

Regards,
shinyafox(Shinya Yoshida)

From ville at misaki.fi  Mon Nov  9 13:49:44 2015
From: ville at misaki.fi (Ville Misaki)
Date: Mon, 9 Nov 2015 22:49:44 +0900
Subject: Display timing/duration of evaluation
Message-ID: <CAMP1M+mjXcigsf1BpO0u_n4Rr3J=Xnh6B_evKoWEPerCVzewcQ@mail.gmail.com>

This came up during the session in JavaOne, and I thought to give it a
shot: display how long each evaluation took.

While this might not be a killer-feature (and my prototype implementation
is as naive as they get, no attempts at digging CPU time or similar), at
least I'm totally addicted to the timing feature of DB clients, always
keeping it on for quick prototyping and evaluation of query performance. I
would imagine it would have similar use when prototyping with Java.

Attached is a patch for my prototype. The timing display is off by default,
and can be toggled by /timing. There are different outputs for concise and
fluff, and the output is omitted for non-interactive outputs.

Comments?

- Ville
-------------- next part --------------
# HG changeset patch
# Parent  ab33a84365a033fa30f1301eb85d80a2b6407ca7

diff -r ab33a84365a0 -r a776bc351e64 src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
--- a/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java	Thu Nov 05 08:15:46 2015 -0800
+++ b/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java	Mon Nov 09 22:23:01 2015 +0900
@@ -42,6 +42,8 @@
 import java.nio.file.NoSuchFileException;
 import java.nio.file.Path;
 import java.nio.file.Paths;
+import java.time.Duration;
+import java.time.Instant;
 import java.util.ArrayList;
 import java.util.Arrays;
 import java.util.Collections;
@@ -141,6 +143,7 @@

     private boolean debug = false;
     private boolean displayPrompt = true;
+    private boolean displayTiming = false;
     public boolean testPrompt = false;
     private Feedback feedback = Feedback.Default;
     private String cmdlineClasspath = null;
@@ -462,12 +465,20 @@
                 if (!trimmed.isEmpty()) {
                     String line = incomplete + trimmed;

+                    Instant start = Instant.now();
+
                     // No commands in the middle of unprocessed source
                     if (incomplete.isEmpty() && line.startsWith("/") && !line.startsWith("//") && !line.startsWith("/*")) {
                         processCommand(line.trim());
                     } else {
                         incomplete = processSourceCatchingReset(line);
                     }
+
+                    if (in.interactiveOutput() && displayTiming) {
+                        double duration = Duration.between(start, Instant.now()).toMillis() / 1000;
+                        fluff("Time elapsed: %.2fs\n", duration);
+                        concise("%.2fs\n", duration);
+                    }
                 }
             }
         } catch (IOException ex) {
@@ -687,6 +698,9 @@
         registerCommand(new Command("/prompt", "/p", null, "toggle display of a prompt",
                                     arg -> cmdPrompt(),
                                     EMPTY_COMPLETION_PROVIDER));
+        registerCommand(new Command("/timing", null, null, "toggle display of timing",
+                                    arg -> cmdTiming(),
+                                    EMPTY_COMPLETION_PROVIDER));
         registerCommand(new Command("/classpath", "/cp", "<path>", "add a path to the classpath",
                                     arg -> cmdClasspath(arg),
                                     classPathCompletion()));
@@ -1132,6 +1146,12 @@
         concise("Prompt: %s", displayPrompt ? "on" : "off");
     }

+    private void cmdTiming() {
+        displayTiming = !displayTiming;
+        fluff("Timing will %sdisplay. Use /timing to toggle.", displayTiming ? "" : "NOT ");
+        concise("Timing: %s", displayTiming ? "on" : "off");
+    }
+
     private void cmdReset() {
         live = false;
         fluff("Resetting state.");

From john.r.rose at oracle.com  Mon Nov  9 21:03:15 2015
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 9 Nov 2015 13:03:15 -0800
Subject: Display timing/duration of evaluation
In-Reply-To: <CAMP1M+mjXcigsf1BpO0u_n4Rr3J=Xnh6B_evKoWEPerCVzewcQ@mail.gmail.com>
References: <CAMP1M+mjXcigsf1BpO0u_n4Rr3J=Xnh6B_evKoWEPerCVzewcQ@mail.gmail.com>
Message-ID: <51981CFE-1A99-417A-9515-0D279403191F@oracle.com>

On Nov 9, 2015, at 5:49 AM, Ville Misaki <ville at misaki.fi> wrote:
> 
> display how long each evaluation took

+1

I'd prefer a threshold time:  If the execution takes less than the threshold, nothing is printed.

Personally, I'd set the threshold to 5 seconds in my profile (if I had one), and this would make sense as a global default too.

I used to do something like this in my Unix shell profile.

Sometimes you don't know how long a command will take, but you don't want a timing report for every piddling command.

Having threshold reporting logic gives you the right mix of information and concision.

? John

From ville at misaki.fi  Mon Nov  9 22:01:26 2015
From: ville at misaki.fi (Ville Misaki)
Date: Tue, 10 Nov 2015 07:01:26 +0900
Subject: Display timing/duration of evaluation
In-Reply-To: <51981CFE-1A99-417A-9515-0D279403191F@oracle.com>
References: <CAMP1M+mjXcigsf1BpO0u_n4Rr3J=Xnh6B_evKoWEPerCVzewcQ@mail.gmail.com>
	<51981CFE-1A99-417A-9515-0D279403191F@oracle.com>
Message-ID: <CAMP1M+m5Arq6y+5_Dtk7HxVqKTq78z3ecXyEDv=NsAn6F38mDQ@mail.gmail.com>

On Tue, Nov 10, 2015 at 6:03 AM, John Rose <john.r.rose at oracle.com> wrote:

> I'd prefer a threshold time:  If the execution takes less than the
> threshold, nothing is printed.
>

Great idea, and makes a lot of sense. I've updated my implementation to
include it (a new patch of the whole implementation attached).

The /timing now takes an optional parameter, using which you can set the
threshold to any non-negative value.

- Ville
-------------- next part --------------
# HG changeset patch
# Parent  ab33a84365a033fa30f1301eb85d80a2b6407ca7

diff -r ab33a84365a0 -r 89bbda0fdcfb src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
--- a/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java	Thu Nov 05 08:15:46 2015 -0800
+++ b/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java	Mon Nov 09 22:23:01 2015 +0900
@@ -42,6 +42,8 @@
 import java.nio.file.NoSuchFileException;
 import java.nio.file.Path;
 import java.nio.file.Paths;
+import java.time.Duration;
+import java.time.Instant;
 import java.util.ArrayList;
 import java.util.Arrays;
 import java.util.Collections;
@@ -141,6 +143,8 @@
 
     private boolean debug = false;
     private boolean displayPrompt = true;
+    private boolean displayTiming = false;
+    private double displayTimingThreshold = 5.0;
     public boolean testPrompt = false;
     private Feedback feedback = Feedback.Default;
     private String cmdlineClasspath = null;
@@ -462,12 +466,22 @@
                 if (!trimmed.isEmpty()) {
                     String line = incomplete + trimmed;
 
+                    Instant start = Instant.now();
+
                     // No commands in the middle of unprocessed source
                     if (incomplete.isEmpty() && line.startsWith("/") && !line.startsWith("//") && !line.startsWith("/*")) {
                         processCommand(line.trim());
                     } else {
                         incomplete = processSourceCatchingReset(line);
                     }
+
+                    if (in.interactiveOutput() && displayTiming) {
+                        double duration = 1.0 * Duration.between(start, Instant.now()).toMillis() / 1000;
+                        if (duration >= displayTimingThreshold) {
+                            fluff("Time elapsed: %.2fs\n", duration);
+                            concise("%.2fs\n", duration);
+                        }
+                    }
                 }
             }
         } catch (IOException ex) {
@@ -687,6 +701,9 @@
         registerCommand(new Command("/prompt", "/p", null, "toggle display of a prompt",
                                     arg -> cmdPrompt(),
                                     EMPTY_COMPLETION_PROVIDER));
+        registerCommand(new Command("/timing", null, "[threshold]", "toggle display of timing or set the threshold",
+                                    arg -> cmdTiming(arg),
+                                    EMPTY_COMPLETION_PROVIDER));
         registerCommand(new Command("/classpath", "/cp", "<path>", "add a path to the classpath",
                                     arg -> cmdClasspath(arg),
                                     classPathCompletion()));
@@ -1132,6 +1149,26 @@
         concise("Prompt: %s", displayPrompt ? "on" : "off");
     }
 
+    private void cmdTiming(String arg) {
+        if (arg == null || arg.isEmpty()) {
+            displayTiming = !displayTiming;
+        } else {
+            try {
+                double threshold = Double.parseDouble(arg);
+                if (threshold >= 0) {
+                    displayTiming = true;
+                    displayTimingThreshold = threshold;
+                } else {
+                    hard("Threshold value must be non-negative.");
+                }
+            } catch (NumberFormatException e) {
+                hard("Invalid threshold value: %s", arg);
+            }
+        }
+        fluff("Timing will %sdisplay. Threshold is %.2fs. Use /timing to toggle.", displayTiming ? "" : "NOT ", displayTimingThreshold);
+        concise("Timing: %s, %.2f", displayTiming ? "on" : "off", displayTimingThreshold);
+    }
+
     private void cmdReset() {
         live = false;
         fluff("Resetting state.");

From robert.field at oracle.com  Tue Nov 10 06:11:19 2015
From: robert.field at oracle.com (Robert Field)
Date: Tue, 10 Nov 2015 08:11:19 +0200
Subject: Display timing/duration of evaluation
In-Reply-To: <CAMP1M+m5Arq6y+5_Dtk7HxVqKTq78z3ecXyEDv=NsAn6F38mDQ@mail.gmail.com>
References: <CAMP1M+mjXcigsf1BpO0u_n4Rr3J=Xnh6B_evKoWEPerCVzewcQ@mail.gmail.com>
	<51981CFE-1A99-417A-9515-0D279403191F@oracle.com>
	<CAMP1M+m5Arq6y+5_Dtk7HxVqKTq78z3ecXyEDv=NsAn6F38mDQ@mail.gmail.com>
Message-ID: <150f0051f58.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

OK, that's three votes for. I'm always worried about slippery slopes, in 
this case towards profiling -- but useful features are useful features.

Others, do you want this feature?

-Robert



On November 10, 2015 1:27:29 AM Ville Misaki <ville at misaki.fi> wrote:

> On Tue, Nov 10, 2015 at 6:03 AM, John Rose <john.r.rose at oracle.com> wrote:
>
>> I'd prefer a threshold time:  If the execution takes less than the
>> threshold, nothing is printed.
>>
>
> Great idea, and makes a lot of sense. I've updated my implementation to
> include it (a new patch of the whole implementation attached).
>
> The /timing now takes an optional parameter, using which you can set the
> threshold to any non-negative value.
>
> - Ville



From bitterfoxc at gmail.com  Tue Nov 10 10:04:07 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Tue, 10 Nov 2015 19:04:07 +0900
Subject: RFR 8142384: New command: /imports, /i which show the list of
	imported packages or classes, etc...
Message-ID: <CAHjBcHNbvOKccDV1bHz_xWwRaxdq0JOZWdSn8g7mwa6Eu0j60w@mail.gmail.com>

Hi Robert.

Some of users will want to know what is already imported.
However, there is no way to know that directly(We can see imported items by
/list, but it shows all of the items which are already typed and there are
no imported items which are imported by start-up).

I propose the new command, /imports and /i, to list imported packages or
classes, etc...

Please review my patch.

Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8142384/webrev.00/
Bugs: https://bugs.openjdk.java.net/browse/JDK-8142384

Regards,
shinyafox(Shinya Yoshida)

From bitterfoxc at gmail.com  Wed Nov 11 03:31:52 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Wed, 11 Nov 2015 12:31:52 +0900
Subject: RFR 8142447: Command change: re-run n-th command should be re-run by
	id
Message-ID: <CAHjBcHOydjAqxhtZADzsNSDOJs6VRM1xmk3igdExT5rtrK4ugQ@mail.gmail.com>

Hi Robert,
I propose changing /<n> to /<id>.

There is no one-to-one correspondence between n-th snippet and snippet id
because we have the name space for main, startup and error.
(Note: When the re-run command is implemented, we have just only one name
space for any snippet)

It makes re-run difficult.
When we re-run main snippet, we have to add the number of startup snippets
and the number of erroneous snippets which appear prior to the snippet what
we want to re-run.
It is very confusing for users.

You can see the example at bugs:
https://bugs.openjdk.java.net/browse/JDK-8142447

Here is the patch.
Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8142447/webrev.00/

Could you consider and review this?

Regards,
shinyafox(Shinya Yoshida)

From robert.field at oracle.com  Wed Nov 11 08:25:55 2015
From: robert.field at oracle.com (Robert Field)
Date: Wed, 11 Nov 2015 09:25:55 +0100
Subject: RFR 8142447: Command change: re-run n-th command should be re-run
	by id
In-Reply-To: <CAHjBcHOydjAqxhtZADzsNSDOJs6VRM1xmk3igdExT5rtrK4ugQ@mail.gmail.com>
References: <CAHjBcHOydjAqxhtZADzsNSDOJs6VRM1xmk3igdExT5rtrK4ugQ@mail.gmail.com>
Message-ID: <7817CD85-883F-42B5-A90F-7246F9B675F0@oracle.com>

I think that makes a lot of sense to consistently do numeric references as being ids.

Sorry I?m not as responsive as usual. Traveling in Europe, just came from JavaDay Kiev.  Speaking today at Devoxx Antwerp.

-Robert

> On Nov 11, 2015, at 4:31 AM, ShinyaYoshida <bitterfoxc at gmail.com> wrote:
> 
> Hi Robert,
> I propose changing /<n> to /<id>.
> 
> There is no one-to-one correspondence between n-th snippet and snippet id because we have the name space for main, startup and error.
> (Note: When the re-run command is implemented, we have just only one name space for any snippet)
> 
> It makes re-run difficult.
> When we re-run main snippet, we have to add the number of startup snippets and the number of erroneous snippets which appear prior to the snippet what we want to re-run.
> It is very confusing for users.
> 
> You can see the example at bugs: https://bugs.openjdk.java.net/browse/JDK-8142447 <https://bugs.openjdk.java.net/browse/JDK-8142447>
> 
> Here is the patch.
> Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8142447/webrev.00/ <http://cr.openjdk.java.net/~shinyafox/kulla/8142447/webrev.00/>
> 
> Could you consider and review this?
> 
> Regards,
> shinyafox(Shinya Yoshida)


From robert.field at oracle.com  Wed Nov 11 08:31:17 2015
From: robert.field at oracle.com (Robert Field)
Date: Wed, 11 Nov 2015 09:31:17 +0100
Subject: RFR 8142384: New command: /imports,
	/i which show the list of imported packages or classes, etc...
In-Reply-To: <CAHjBcHNbvOKccDV1bHz_xWwRaxdq0JOZWdSn8g7mwa6Eu0j60w@mail.gmail.com>
References: <CAHjBcHNbvOKccDV1bHz_xWwRaxdq0JOZWdSn8g7mwa6Eu0j60w@mail.gmail.com>
Message-ID: <4EF92E7D-8B0F-4098-B3EB-F9CBFEEA6DB2@oracle.com>

Thumbs up.

Not easily set up to do a push right now, if someone else can...

-Robert

> On Nov 10, 2015, at 11:04 AM, ShinyaYoshida <bitterfoxc at gmail.com> wrote:
> 
> Hi Robert.
> 
> Some of users will want to know what is already imported.
> However, there is no way to know that directly(We can see imported items by /list, but it shows all of the items which are already typed and there are no imported items which are imported by start-up).
> 
> I propose the new command, /imports and /i, to list imported packages or classes, etc...
> 
> Please review my patch.
> 
> Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8142384/webrev.00/ <http://cr.openjdk.java.net/~shinyafox/kulla/8142384/webrev.00/>
> Bugs: https://bugs.openjdk.java.net/browse/JDK-8142384 <https://bugs.openjdk.java.net/browse/JDK-8142384>
> 
> Regards,
> shinyafox(Shinya Yoshida)
> 


From bitterfoxc at gmail.com  Wed Nov 11 08:42:40 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Wed, 11 Nov 2015 17:42:40 +0900
Subject: RFR 8142447: Command change: re-run n-th command should be re-run
	by id
In-Reply-To: <7817CD85-883F-42B5-A90F-7246F9B675F0@oracle.com>
References: <CAHjBcHOydjAqxhtZADzsNSDOJs6VRM1xmk3igdExT5rtrK4ugQ@mail.gmail.com>
	<7817CD85-883F-42B5-A90F-7246F9B675F0@oracle.com>
Message-ID: <CAHjBcHPRRD-bnSmJ6KyB2B=VGNfDWj01zPLxK75JwqkpTrBswA@mail.gmail.com>

Hi Robert,
Thank you for your comment.

Don't worry, and Enjoy Europe and your presentation ;)!!

Regards,
shinyafox(Shinya Yoshida)

2015-11-11 17:25 GMT+09:00 Robert Field <robert.field at oracle.com>:

> I think that makes a lot of sense to consistently do numeric references as
> being ids.
>
> Sorry I?m not as responsive as usual. Traveling in Europe, just came from
> JavaDay Kiev.  Speaking today at Devoxx Antwerp.
>
> -Robert
>
> On Nov 11, 2015, at 4:31 AM, ShinyaYoshida <bitterfoxc at gmail.com> wrote:
>
> Hi Robert,
> I propose changing /<n> to /<id>.
>
> There is no one-to-one correspondence between n-th snippet and snippet id
> because we have the name space for main, startup and error.
> (Note: When the re-run command is implemented, we have just only one name
> space for any snippet)
>
> It makes re-run difficult.
> When we re-run main snippet, we have to add the number of startup snippets
> and the number of erroneous snippets which appear prior to the snippet what
> we want to re-run.
> It is very confusing for users.
>
> You can see the example at bugs:
> https://bugs.openjdk.java.net/browse/JDK-8142447
>
> Here is the patch.
> Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8142447/webrev.00/
>
> Could you consider and review this?
>
> Regards,
> shinyafox(Shinya Yoshida)
>
>
>

From bitterfoxc at gmail.com  Sat Nov 14 08:05:20 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Sat, 14 Nov 2015 17:05:20 +0900
Subject: RFR 8143006: JShell tool: EditPad doesn't process each line as same
	as inputs for jshell
Message-ID: <CAHjBcHMw3v5XP3xTeqwNZFGa2F1xiDGWuCMp30veN_5vg73t6g@mail.gmail.com>

Hi,
I'd like to change the behavior of SaveHandler.

When I put following into EditPad, it makes an error:

System.out.println("Hello")
System.out.println("World")
--
|  Error:
|  ';'??????
|  System.out.println("hello")
|                             ^

It is very confusing and useless.
Because when I open EditPad after running "System.out.println("Hello")" on
jshell, the text in EditPad contains "System.out.println("Hello")" and it
could be cause of error after several editing.
(it is only happen when the invoked method returns void because
JShell#cmdEdit don't put ";" to the end of statements.)

And, above all, the user will be surprised at the input for EditPad because
it is not processed like the input for jshell.

Could you review this?
http://cr.openjdk.java.net/~shinyafox/kulla/8143006/webrev.00/

Bugs is here:
https://bugs.openjdk.java.net/browse/JDK-8143006

Regards,
shinyafox(Shinya Yoshida)

From robert.field at oracle.com  Sat Nov 14 17:43:26 2015
From: robert.field at oracle.com (Robert Field)
Date: Sat, 14 Nov 2015 18:43:26 +0100
Subject: RFR 8143006: JShell tool: EditPad doesn't process each line as
	same as inputs for jshell
In-Reply-To: <CAHjBcHMw3v5XP3xTeqwNZFGa2F1xiDGWuCMp30veN_5vg73t6g@mail.gmail.com>
References: <CAHjBcHMw3v5XP3xTeqwNZFGa2F1xiDGWuCMp30veN_5vg73t6g@mail.gmail.com>
Message-ID: <2D152B9F-9C8B-4707-BDE3-BCFC5E302FB8@oracle.com>

Thanks for catching this.

You make a good point that it is not processed like other input.  Can we factor out and share code so that it is processed with the same code?

List adds missing semicolons, can we share mechanism there.

The pre-existing approach where cmdEdit builds up the snippet list and the src, then the further processing is in SaveHandler seems worrisome ? not to mention it forces you to interrupt the pretty stream sequencing you built.

Thanks,
Robert

> On Nov 14, 2015, at 9:05 AM, ShinyaYoshida <bitterfoxc at gmail.com> wrote:
> 
> Hi,
> I'd like to change the behavior of SaveHandler.
> 
> When I put following into EditPad, it makes an error:
> 
> System.out.println("Hello")
> System.out.println("World")
> --
> |  Error:
> |  ';'??????
> |  System.out.println("hello")
> |                             ^
> 
> It is very confusing and useless.
> Because when I open EditPad after running "System.out.println("Hello")" on
> jshell, the text in EditPad contains "System.out.println("Hello")" and it
> could be cause of error after several editing.
> (it is only happen when the invoked method returns void because
> JShell#cmdEdit don't put ";" to the end of statements.)
> 
> And, above all, the user will be surprised at the input for EditPad because
> it is not processed like the input for jshell.
> 
> Could you review this?
> http://cr.openjdk.java.net/~shinyafox/kulla/8143006/webrev.00/
> 
> Bugs is here:
> https://bugs.openjdk.java.net/browse/JDK-8143006
> 
> Regards,
> shinyafox(Shinya Yoshida)


From bitterfoxc at gmail.com  Mon Nov 16 02:32:32 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Mon, 16 Nov 2015 11:32:32 +0900
Subject: RFR 8143006: JShell tool: EditPad doesn't process each line as
	same as inputs for jshell
In-Reply-To: <2D152B9F-9C8B-4707-BDE3-BCFC5E302FB8@oracle.com>
References: <CAHjBcHMw3v5XP3xTeqwNZFGa2F1xiDGWuCMp30veN_5vg73t6g@mail.gmail.com>
	<2D152B9F-9C8B-4707-BDE3-BCFC5E302FB8@oracle.com>
Message-ID: <CAHjBcHMF-7m_10yStLkZp26STF=4WrX66x1G_KDS_f+QP7Wm=g@mail.gmail.com>

Hi,
I have another fix, please review this.
I think this is better than before.

http://cr.openjdk.java.net/~shinyafox/kulla/8143006/webrev.01/

In this patch, SaveHandler calls JShellTool#run.
So it commits itself to deal with the code like /open or normal jshell
input.

Regards,
shinyafox(Shinya Yoshida)

2015-11-15 2:43 GMT+09:00 Robert Field <robert.field at oracle.com>:

> Thanks for catching this.
>
> You make a good point that it is not processed like other input.  Can we
> factor out and share code so that it is processed with the same code?
>
> List adds missing semicolons, can we share mechanism there.
>
> The pre-existing approach where cmdEdit builds up the snippet list and the
> src, then the further processing is in SaveHandler seems worrisome ? not to
> mention it forces you to interrupt the pretty stream sequencing you built.
>
> Thanks,
> Robert
>
> > On Nov 14, 2015, at 9:05 AM, ShinyaYoshida <bitterfoxc at gmail.com> wrote:
> >
> > Hi,
> > I'd like to change the behavior of SaveHandler.
> >
> > When I put following into EditPad, it makes an error:
> >
> > System.out.println("Hello")
> > System.out.println("World")
> > --
> > |  Error:
> > |  ';'??????
> > |  System.out.println("hello")
> > |                             ^
> >
> > It is very confusing and useless.
> > Because when I open EditPad after running "System.out.println("Hello")"
> on
> > jshell, the text in EditPad contains "System.out.println("Hello")" and it
> > could be cause of error after several editing.
> > (it is only happen when the invoked method returns void because
> > JShell#cmdEdit don't put ";" to the end of statements.)
> >
> > And, above all, the user will be surprised at the input for EditPad
> because
> > it is not processed like the input for jshell.
> >
> > Could you review this?
> > http://cr.openjdk.java.net/~shinyafox/kulla/8143006/webrev.00/
> >
> > Bugs is here:
> > https://bugs.openjdk.java.net/browse/JDK-8143006
> >
> > Regards,
> > shinyafox(Shinya Yoshida)
>
>

From bitterfoxc at gmail.com  Mon Nov 16 06:13:10 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Mon, 16 Nov 2015 15:13:10 +0900
Subject: Quation about the spec of SourceCodeAnalysis#analyzeCompletion WAS:
	RFR 8143006: JShell tool: EditPad doesn't process each line as same as
	inputs for jshell
Message-ID: <CAHjBcHMUF11uE9ZbbA60AbFD7_585xRj4yqUsNQ_wLzS2UaSEA@mail.gmail.com>

Hi,
I'd like ask about the spec of SourceCodeAnalysis#analyzeCompletion.

When I call SourceCodeAnalysis#analyzeCompletion with "f()\nf()", what
result should be returned?

Currently, it returns:
CompletionInfo {
    completeness = COMPLETE
    unitEndPos = 7
    source = "f()\nf()"
    remaining = ""
}

Is this correct?

I think it is not suitable for JShell API
Another possibility which is suitable for JShell API is here:
CompletionInfo {
    completeness = COMPLETE
    unitEndPos = 4
    source = "f()"
    remaining = "\nf()"
}

Which should be do?

If this is a bug, can I work for this?

Regards,
shinyafox(Shinya Yoshida)

From robert.field at oracle.com  Mon Nov 16 07:33:15 2015
From: robert.field at oracle.com (Robert Field)
Date: Mon, 16 Nov 2015 08:33:15 +0100
Subject: Quation about the spec of SourceCodeAnalysis#analyzeCompletion
	WAS: RFR 8143006: JShell tool: EditPad doesn't process each
	line as same as inputs for jshell
In-Reply-To: <CAHjBcHMUF11uE9ZbbA60AbFD7_585xRj4yqUsNQ_wLzS2UaSEA@mail.gmail.com>
References: <CAHjBcHMUF11uE9ZbbA60AbFD7_585xRj4yqUsNQ_wLzS2UaSEA@mail.gmail.com>
Message-ID: <1510f364a78.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Completion only defects missing semicolons at the end of input. It detects 
ends of snippets with semicolons and end braces.

It is scanning technology not parsing.  It could be argued that it should 
do full parsing ...

-Robert



On November 16, 2015 7:13:13 AM ShinyaYoshida <bitterfoxc at gmail.com> wrote:

> Hi,
> I'd like ask about the spec of SourceCodeAnalysis#analyzeCompletion.
>
> When I call SourceCodeAnalysis#analyzeCompletion with "f()\nf()", what
> result should be returned?
>
> Currently, it returns:
> CompletionInfo {
>     completeness = COMPLETE
>     unitEndPos = 7
>     source = "f()\nf()"
>     remaining = ""
> }
>
> Is this correct?
>
> I think it is not suitable for JShell API
> Another possibility which is suitable for JShell API is here:
> CompletionInfo {
>     completeness = COMPLETE
>     unitEndPos = 4
>     source = "f()"
>     remaining = "\nf()"
> }
>
> Which should be do?
>
> If this is a bug, can I work for this?
>
> Regards,
> shinyafox(Shinya Yoshida)

From robert.field at oracle.com  Mon Nov 16 08:03:30 2015
From: robert.field at oracle.com (Robert Field)
Date: Mon, 16 Nov 2015 09:03:30 +0100
Subject: RFR 8143006: JShell tool: EditPad doesn't process each line as
	same as inputs for jshell
In-Reply-To: <CAHjBcHMF-7m_10yStLkZp26STF=4WrX66x1G_KDS_f+QP7Wm=g@mail.gmail.com>
References: <CAHjBcHMw3v5XP3xTeqwNZFGa2F1xiDGWuCMp30veN_5vg73t6g@mail.gmail.com>
	<2D152B9F-9C8B-4707-BDE3-BCFC5E302FB8@oracle.com>
	<CAHjBcHMF-7m_10yStLkZp26STF=4WrX66x1G_KDS_f+QP7Wm=g@mail.gmail.com>
Message-ID: <1510f51fc50.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

I like that this has shifted the usage pattern to a more consistent 
mechanism.  I'm concerned that this intertwines input processing with 
IOContext in a way that it did not before, this breaking encapsulation.

It is good that this patch disallows command entry from Edit Pad / external 
editors.

One of the characteristics of editor result processing is that only 
snippets which have been changed are reprocessed, I don't see that in this 
code, but that may be the little screens in using.

I'm taking a little for day vacation before returning to the U.S. I'll be 
able to look at this in more depth on my return.

-Robert




On November 16, 2015 3:32:35 AM ShinyaYoshida <bitterfoxc at gmail.com> wrote:

> Hi,
> I have another fix, please review this.
> I think this is better than before.
>
> http://cr.openjdk.java.net/~shinyafox/kulla/8143006/webrev.01/
>
> In this patch, SaveHandler calls JShellTool#run.
> So it commits itself to deal with the code like /open or normal jshell
> input.
>
> Regards,
> shinyafox(Shinya Yoshida)
>
> 2015-11-15 2:43 GMT+09:00 Robert Field <robert.field at oracle.com>:
>
>> Thanks for catching this.
>>
>> You make a good point that it is not processed like other input.  Can we
>> factor out and share code so that it is processed with the same code?
>>
>> List adds missing semicolons, can we share mechanism there.
>>
>> The pre-existing approach where cmdEdit builds up the snippet list and the
>> src, then the further processing is in SaveHandler seems worrisome ? not to
>> mention it forces you to interrupt the pretty stream sequencing you built.
>>
>> Thanks,
>> Robert
>>
>> > On Nov 14, 2015, at 9:05 AM, ShinyaYoshida <bitterfoxc at gmail.com> wrote:
>> >
>> > Hi,
>> > I'd like to change the behavior of SaveHandler.
>> >
>> > When I put following into EditPad, it makes an error:
>> >
>> > System.out.println("Hello")
>> > System.out.println("World")
>> > --
>> > |  Error:
>> > |  ';'??????
>> > |  System.out.println("hello")
>> > |                             ^
>> >
>> > It is very confusing and useless.
>> > Because when I open EditPad after running "System.out.println("Hello")"
>> on
>> > jshell, the text in EditPad contains "System.out.println("Hello")" and it
>> > could be cause of error after several editing.
>> > (it is only happen when the invoked method returns void because
>> > JShell#cmdEdit don't put ";" to the end of statements.)
>> >
>> > And, above all, the user will be surprised at the input for EditPad
>> because
>> > it is not processed like the input for jshell.
>> >
>> > Could you review this?
>> > http://cr.openjdk.java.net/~shinyafox/kulla/8143006/webrev.00/
>> >
>> > Bugs is here:
>> > https://bugs.openjdk.java.net/browse/JDK-8143006
>> >
>> > Regards,
>> > shinyafox(Shinya Yoshida)
>>
>>

From bitterfoxc at gmail.com  Mon Nov 16 09:40:47 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Mon, 16 Nov 2015 18:40:47 +0900
Subject: RFR 8143006: JShell tool: EditPad doesn't process each line as
	same as inputs for jshell
In-Reply-To: <1510f51fc50.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
References: <CAHjBcHMw3v5XP3xTeqwNZFGa2F1xiDGWuCMp30veN_5vg73t6g@mail.gmail.com>
	<2D152B9F-9C8B-4707-BDE3-BCFC5E302FB8@oracle.com>
	<CAHjBcHMF-7m_10yStLkZp26STF=4WrX66x1G_KDS_f+QP7Wm=g@mail.gmail.com>
	<1510f51fc50.2767.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>
Message-ID: <CAHjBcHNm+KNGQy-ZJfhiY_OeRV1O=McpKyqrxMcXqZyCubb7KA@mail.gmail.com>

Thank you for your review.

Yes, interwining input processing is not appeared by /edit.
But, it is already appeared by /open on jshell.
I think it will not be a problem because JShellTool#run and the callee are
already well-considered to implement /open.

In my patch, the command is disallowed from only /e.
It will be possible fix to disallow the command from /open.

In the shouldBeProcessed(), I check that the input which will be processed
is changed.
If it is not changed, then it will not be processed:

In shouldBeProcessed
+                        @Override
+                        public boolean shouldBeProcessed(CompletionInfo
ci) {
+                            return !failed &&
!currSrcs.contains(trimNewlines(ci.source));
                         }

In processSource
+            if (input.shouldBeProcessed(an)) {
+                boolean failed = processCompleteSource(an.source);
+                if (failed) {

That's very good! Enjoy and Have a good vacation!

Regards,
shinyafox(Shinya Yoshida)

2015-11-16 17:03 GMT+09:00 Robert Field <robert.field at oracle.com>:

> I like that this has shifted the usage pattern to a more consistent
> mechanism.  I'm concerned that this intertwines input processing with
> IOContext in a way that it did not before, this breaking encapsulation.
>
> It is good that this patch disallows command entry from Edit Pad /
> external editors.
>
> One of the characteristics of editor result processing is that only
> snippets which have been changed are reprocessed, I don't see that in this
> code, but that may be the little screens in using.
>
> I'm taking a little for day vacation before returning to the U.S. I'll be
> able to look at this in more depth on my return.
>
> -Robert
>
> On November 16, 2015 3:32:35 AM ShinyaYoshida <bitterfoxc at gmail.com>
> wrote:
>
>> Hi,
>> I have another fix, please review this.
>> I think this is better than before.
>>
>> http://cr.openjdk.java.net/~shinyafox/kulla/8143006/webrev.01/
>>
>> In this patch, SaveHandler calls JShellTool#run.
>> So it commits itself to deal with the code like /open or normal jshell
>> input.
>>
>> Regards,
>> shinyafox(Shinya Yoshida)
>>
>> 2015-11-15 2:43 GMT+09:00 Robert Field <robert.field at oracle.com>:
>>
>>> Thanks for catching this.
>>>
>>> You make a good point that it is not processed like other input.  Can we
>>> factor out and share code so that it is processed with the same code?
>>>
>>> List adds missing semicolons, can we share mechanism there.
>>>
>>> The pre-existing approach where cmdEdit builds up the snippet list and
>>> the src, then the further processing is in SaveHandler seems worrisome ?
>>> not to mention it forces you to interrupt the pretty stream sequencing you
>>> built.
>>>
>>> Thanks,
>>> Robert
>>>
>>> > On Nov 14, 2015, at 9:05 AM, ShinyaYoshida <bitterfoxc at gmail.com>
>>> wrote:
>>> >
>>> > Hi,
>>> > I'd like to change the behavior of SaveHandler.
>>> >
>>> > When I put following into EditPad, it makes an error:
>>> >
>>> > System.out.println("Hello")
>>> > System.out.println("World")
>>> > --
>>> > |  Error:
>>> > |  ';'??????
>>> > |  System.out.println("hello")
>>> > |                             ^
>>> >
>>> > It is very confusing and useless.
>>> > Because when I open EditPad after running
>>> "System.out.println("Hello")" on
>>> > jshell, the text in EditPad contains "System.out.println("Hello")" and
>>> it
>>> > could be cause of error after several editing.
>>> > (it is only happen when the invoked method returns void because
>>> > JShell#cmdEdit don't put ";" to the end of statements.)
>>> >
>>> > And, above all, the user will be surprised at the input for EditPad
>>> because
>>> > it is not processed like the input for jshell.
>>> >
>>> > Could you review this?
>>> > http://cr.openjdk.java.net/~shinyafox/kulla/8143006/webrev.00/
>>> >
>>> > Bugs is here:
>>> > https://bugs.openjdk.java.net/browse/JDK-8143006
>>> >
>>> > Regards,
>>> > shinyafox(Shinya Yoshida)
>>>
>>>
>>

From roy.van.rijn at gmail.com  Mon Nov 16 16:36:50 2015
From: roy.van.rijn at gmail.com (Roy van Rijn)
Date: Mon, 16 Nov 2015 17:36:50 +0100
Subject: Using JShell API on OS/X
Message-ID: <CAMJwwmtU7OVugZpfh1y+sr0jbbdweqJj0u51ygS1sxhs8X2u7g@mail.gmail.com>

Dear JShell devs,

During Devoxx I had the chance to see Robert Field talk about JShell.
This talk is available here:
https://www.youtube.com/watch?v=jziVaht480w

At the end of the talk he showed us you can program against the JShell
just by doing things like:
JShell shell = JShell.create();
shell.eval(things);

I decided to try this and see if it is possible to create a simple
plugin for various tools. But when I downloaded the latest JDK9 EA
snapshot (b91) and do the simplest Hello World I quickly run into a
problem.

In my case, using IntelliJ IDEA the classpath in "java.class.path" has
the following entry added ":/Applications/IntelliJ IDEA
14.app/Contents/lib/idea_rt.jar". This causes a problem:

java -classpath
/Library/Java/JavaVirtualMachines/jdk1.9.0.jdk/Contents/Home...<snip>...l:/Applications/IntelliJ
IDEA 14.app/Contents/lib/idea_rt.jar
-Xbootclasspath:/Library/Java/JavaVirtualMachines/jdk1.9.0.jdk/Contents/Home/lib/modules/bootmodules.jimage
-Xdebug -Xrunjdwp:transport=dt_socket,address=roy.local:62661,suspend=y
jdk.internal.jshell.remote.RemoteAgent 62660

The error: Could not find or load main class IDEA

Apparently IntelliJ IDEA on OS/X will always cause the
"java.class.path" to have a space in it. Because of the space in the
path and they way ExecutionControl.jdiGo(int) uses that property.

A solution (on my side) might be to instruct IDEA to set the classpath
differently, enclosing it with double qoutes, but I think a lot of
people will run into this problem eventually? Does this need fixing in
JShell perhaps?

Roy

From iris.clark at oracle.com  Wed Nov 18 22:53:59 2015
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 18 Nov 2015 14:53:59 -0800 (PST)
Subject: RFR (xxs): jdk.jshell.TaskFactory code for java.specification.version
	= 1.9 should be adjusted for Verona
Message-ID: <5b0b286a-b8a1-4c67-8c81-60fc35f399f7@default>

Hi, Robert and Kumar.

Please review this two character diff to address the following bug:

    8141104: jdk.jshell.TaskFactory code for java.specification.version = 1.9
        should be adjusted for Verona
    https://bugs.openjdk.java.net/browse/JDK-8141104

JEP 223 New Version-String Specification [0] (aka Verona) changes the return
Value for various system properties including java.specification.version. The
code in jdk.jshell.TaskFactory should be altered to detect the new version ("9"
instead of "1.9") as follows:

$ hg diff
diff -r ac125016e012 src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java
--- a/src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java  Mon Nov 16 17:10:23 2015 -0800
+++ b/src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java  Wed Nov 18 12:11:08 2015 -0800
@@ -80,7 +80,7 @@
         if (compiler == null) {
             throw new UnsupportedOperationException("Compiler not available, must be run with full JDK 9.");
         }
-        if (!System.getProperty("java.specification.version").equals("1.9"))  {
+        if (!System.getProperty("java.specification.version").equals("9"))  {
             throw new UnsupportedOperationException("Wrong compiler, must be run with full JDK 9.");
         }
         this.fileManager = new MemoryFileManager(

This bug was detected by jdk/jshell/AnalysisTest.java which fails on all
platforms.  I have confirmed that it passes when this changeset is applied.

After review, the changeset will be pushed to verona/stage [1].  The changeset
will go to jdk9/jdk9 when Verona is pushed to that release.

Thanks,
Iris

[0] http://openjdk.java.net/jeps/223
[1] http://hg.openjdk.java.net/verona/stage

From kumar.x.srinivasan at oracle.com  Thu Nov 19 17:36:10 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 19 Nov 2015 09:36:10 -0800
Subject: RFR (xxs): jdk.jshell.TaskFactory code for
	java.specification.version = 1.9 should be adjusted for Verona
In-Reply-To: <5b0b286a-b8a1-4c67-8c81-60fc35f399f7@default>
References: <5b0b286a-b8a1-4c67-8c81-60fc35f399f7@default>
Message-ID: <564E088A.60805@oracle.com>


Hi Iris,

Looks good to me.

Thanks
Kumar

> Hi, Robert and Kumar.
>
> Please review this two character diff to address the following bug:
>
>      8141104: jdk.jshell.TaskFactory code for java.specification.version = 1.9
>          should be adjusted for Verona
>      https://bugs.openjdk.java.net/browse/JDK-8141104
>
> JEP 223 New Version-String Specification [0] (aka Verona) changes the return
> Value for various system properties including java.specification.version. The
> code in jdk.jshell.TaskFactory should be altered to detect the new version ("9"
> instead of "1.9") as follows:
>
> $ hg diff
> diff -r ac125016e012 src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java
> --- a/src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java  Mon Nov 16 17:10:23 2015 -0800
> +++ b/src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java  Wed Nov 18 12:11:08 2015 -0800
> @@ -80,7 +80,7 @@
>           if (compiler == null) {
>               throw new UnsupportedOperationException("Compiler not available, must be run with full JDK 9.");
>           }
> -        if (!System.getProperty("java.specification.version").equals("1.9"))  {
> +        if (!System.getProperty("java.specification.version").equals("9"))  {
>               throw new UnsupportedOperationException("Wrong compiler, must be run with full JDK 9.");
>           }
>           this.fileManager = new MemoryFileManager(
>
> This bug was detected by jdk/jshell/AnalysisTest.java which fails on all
> platforms.  I have confirmed that it passes when this changeset is applied.
>
> After review, the changeset will be pushed to verona/stage [1].  The changeset
> will go to jdk9/jdk9 when Verona is pushed to that release.
>
> Thanks,
> Iris
>
> [0] http://openjdk.java.net/jeps/223
> [1] http://hg.openjdk.java.net/verona/stage


From iris.clark at oracle.com  Thu Nov 19 18:53:21 2015
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 19 Nov 2015 10:53:21 -0800 (PST)
Subject: RFR (xxs): jdk.jshell.TaskFactory code for
	java.specification.version = 1.9 should be adjusted for Verona
In-Reply-To: <564E088A.60805@oracle.com>
References: <5b0b286a-b8a1-4c67-8c81-60fc35f399f7@default>
	<564E088A.60805@oracle.com>
Message-ID: <33b94892-b3a4-4956-814b-d60db6aa61af@default>

Hi, Kumar.

Thanks for the review!

iris

-----Original Message-----
From: Kumar Srinivasan 
Sent: Thursday, November 19, 2015 9:36 AM
To: Iris Clark
Cc: Robert Field; verona-dev at openjdk.java.net; kulla-dev at openjdk.java.net
Subject: Re: RFR (xxs): jdk.jshell.TaskFactory code for java.specification.version = 1.9 should be adjusted for Verona


Hi Iris,

Looks good to me.

Thanks
Kumar

> Hi, Robert and Kumar.
>
> Please review this two character diff to address the following bug:
>
>      8141104: jdk.jshell.TaskFactory code for java.specification.version = 1.9
>          should be adjusted for Verona
>      https://bugs.openjdk.java.net/browse/JDK-8141104
>
> JEP 223 New Version-String Specification [0] (aka Verona) changes the 
> return Value for various system properties including 
> java.specification.version. The code in jdk.jshell.TaskFactory should be altered to detect the new version ("9"
> instead of "1.9") as follows:
>
> $ hg diff
> diff -r ac125016e012 
> src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java
> --- a/src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java  Mon 
> Nov 16 17:10:23 2015 -0800
> +++ b/src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java  Wed 
> +++ Nov 18 12:11:08 2015 -0800
> @@ -80,7 +80,7 @@
>           if (compiler == null) {
>               throw new UnsupportedOperationException("Compiler not available, must be run with full JDK 9.");
>           }
> -        if (!System.getProperty("java.specification.version").equals("1.9"))  {
> +        if 
> + (!System.getProperty("java.specification.version").equals("9"))  {
>               throw new UnsupportedOperationException("Wrong compiler, must be run with full JDK 9.");
>           }
>           this.fileManager = new MemoryFileManager(
>
> This bug was detected by jdk/jshell/AnalysisTest.java which fails on 
> all platforms.  I have confirmed that it passes when this changeset is applied.
>
> After review, the changeset will be pushed to verona/stage [1].  The 
> changeset will go to jdk9/jdk9 when Verona is pushed to that release.
>
> Thanks,
> Iris
>
> [0] http://openjdk.java.net/jeps/223
> [1] http://hg.openjdk.java.net/verona/stage


From jan.lahoda at oracle.com  Thu Nov 19 20:12:30 2015
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 19 Nov 2015 21:12:30 +0100
Subject: RFR (xxs): jdk.jshell.TaskFactory code for
	java.specification.version = 1.9 should be adjusted for Verona
In-Reply-To: <5b0b286a-b8a1-4c67-8c81-60fc35f399f7@default>
References: <5b0b286a-b8a1-4c67-8c81-60fc35f399f7@default>
Message-ID: <564E2D2E.4090607@oracle.com>

Looks OK to me.

Jan

On 18.11.2015 23:53, Iris Clark wrote:
> Hi, Robert and Kumar.
>
> Please review this two character diff to address the following bug:
>
>      8141104: jdk.jshell.TaskFactory code for java.specification.version = 1.9
>          should be adjusted for Verona
>      https://bugs.openjdk.java.net/browse/JDK-8141104
>
> JEP 223 New Version-String Specification [0] (aka Verona) changes the return
> Value for various system properties including java.specification.version. The
> code in jdk.jshell.TaskFactory should be altered to detect the new version ("9"
> instead of "1.9") as follows:
>
> $ hg diff
> diff -r ac125016e012 src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java
> --- a/src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java  Mon Nov 16 17:10:23 2015 -0800
> +++ b/src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java  Wed Nov 18 12:11:08 2015 -0800
> @@ -80,7 +80,7 @@
>           if (compiler == null) {
>               throw new UnsupportedOperationException("Compiler not available, must be run with full JDK 9.");
>           }
> -        if (!System.getProperty("java.specification.version").equals("1.9"))  {
> +        if (!System.getProperty("java.specification.version").equals("9"))  {
>               throw new UnsupportedOperationException("Wrong compiler, must be run with full JDK 9.");
>           }
>           this.fileManager = new MemoryFileManager(
>
> This bug was detected by jdk/jshell/AnalysisTest.java which fails on all
> platforms.  I have confirmed that it passes when this changeset is applied.
>
> After review, the changeset will be pushed to verona/stage [1].  The changeset
> will go to jdk9/jdk9 when Verona is pushed to that release.
>
> Thanks,
> Iris
>
> [0] http://openjdk.java.net/jeps/223
> [1] http://hg.openjdk.java.net/verona/stage
>

From iris.clark at oracle.com  Thu Nov 19 21:18:01 2015
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 19 Nov 2015 13:18:01 -0800 (PST)
Subject: RFR (xxs): jdk.jshell.TaskFactory code for
	java.specification.version = 1.9 should be adjusted for Verona
In-Reply-To: <564E2D2E.4090607@oracle.com>
References: <5b0b286a-b8a1-4c67-8c81-60fc35f399f7@default>
	<564E2D2E.4090607@oracle.com>
Message-ID: <15b96fcb-b65d-4039-bb64-1a609d9c9f10@default>

Hi, Jan.

Thanks for the review.

Regards,
iris

-----Original Message-----
From: Jan Lahoda 
Sent: Thursday, November 19, 2015 12:13 PM
To: Iris Clark; Robert Field; Kumar Srinivasan
Cc: kulla-dev at openjdk.java.net; verona-dev at openjdk.java.net
Subject: Re: RFR (xxs): jdk.jshell.TaskFactory code for java.specification.version = 1.9 should be adjusted for Verona

Looks OK to me.

Jan

On 18.11.2015 23:53, Iris Clark wrote:
> Hi, Robert and Kumar.
>
> Please review this two character diff to address the following bug:
>
>      8141104: jdk.jshell.TaskFactory code for java.specification.version = 1.9
>          should be adjusted for Verona
>      https://bugs.openjdk.java.net/browse/JDK-8141104
>
> JEP 223 New Version-String Specification [0] (aka Verona) changes the 
> return Value for various system properties including 
> java.specification.version. The code in jdk.jshell.TaskFactory should be altered to detect the new version ("9"
> instead of "1.9") as follows:
>
> $ hg diff
> diff -r ac125016e012 
> src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java
> --- a/src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java  Mon 
> Nov 16 17:10:23 2015 -0800
> +++ b/src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java  Wed 
> +++ Nov 18 12:11:08 2015 -0800
> @@ -80,7 +80,7 @@
>           if (compiler == null) {
>               throw new UnsupportedOperationException("Compiler not available, must be run with full JDK 9.");
>           }
> -        if (!System.getProperty("java.specification.version").equals("1.9"))  {
> +        if 
> + (!System.getProperty("java.specification.version").equals("9"))  {
>               throw new UnsupportedOperationException("Wrong compiler, must be run with full JDK 9.");
>           }
>           this.fileManager = new MemoryFileManager(
>
> This bug was detected by jdk/jshell/AnalysisTest.java which fails on 
> all platforms.  I have confirmed that it passes when this changeset is applied.
>
> After review, the changeset will be pushed to verona/stage [1].  The 
> changeset will go to jdk9/jdk9 when Verona is pushed to that release.
>
> Thanks,
> Iris
>
> [0] http://openjdk.java.net/jeps/223
> [1] http://hg.openjdk.java.net/verona/stage
>

From bitterfoxc at gmail.com  Fri Nov 27 18:27:22 2015
From: bitterfoxc at gmail.com (ShinyaYoshida)
Date: Sat, 28 Nov 2015 03:27:22 +0900
Subject: RFR 8142447: Command change: re-run n-th command should be re-run
	by id
In-Reply-To: <5656533D.3020601@oracle.com>
References: <CAHjBcHOydjAqxhtZADzsNSDOJs6VRM1xmk3igdExT5rtrK4ugQ@mail.gmail.com>
	<5656533D.3020601@oracle.com>
Message-ID: <CAHjBcHO0W+79RVTPRhKd-NDNxfc_YZS2OecG2-=sTt+vf4NuBg@mail.gmail.com>

Thank you for your review!

New one is here:
http://cr.openjdk.java.net/~shinyafox/kulla/8142447/webrev.01/

2015-11-26 9:33 GMT+09:00 Robert Field <robert.field at oracle.com>:

> The code looks good to me.
> Just a couple small review comments:
>
>     The method names cmd*() are reserved for the correspondingly named
> commands called via command registration. Similar, but I'd change the name
> of cmdUseHistoryEntryById(String id).
>
I've changed the name.
So should we also change the name of cmdUseHistoryEntry like this?


>
>     There are no associated tests.
>
Certainly. I've add the test.


>
> Then some questions for general discussion that this raises (they do not
> have to be resolved for this fix to proceed) --
>
>     Does it still make sense to have the /-n form which may be useful at
> times but is a different addressing mechanism?
>

One option is that we make the command "/re <id>|-<n>|!" which covers /<id>
and /-<n>, /!.


>     I don't think it is critical to be able to rerun commands (as opposed
> to snippets), but it would be nice.  One approach would be to give them
> synthetic ids: c1, c2, ... .  Thoughts?
>
I like this feature ;)

Regards,
shinyafox(Shinya Yoshida)


> -Robert
>
>
>
> On 11/10/15 19:31, ShinyaYoshida wrote:
>
> Hi Robert,
> I propose changing /<n> to /<id>.
>
> There is no one-to-one correspondence between n-th snippet and snippet id
> because we have the name space for main, startup and error.
> (Note: When the re-run command is implemented, we have just only one name
> space for any snippet)
>
> It makes re-run difficult.
> When we re-run main snippet, we have to add the number of startup snippets
> and the number of erroneous snippets which appear prior to the snippet what
> we want to re-run.
> It is very confusing for users.
>
> You can see the example at bugs:
> https://bugs.openjdk.java.net/browse/JDK-8142447
>
> Here is the patch.
> Webrev: http://cr.openjdk.java.net/~shinyafox/kulla/8142447/webrev.00/
>
> Could you consider and review this?
>
> Regards,
> shinyafox(Shinya Yoshida)
>
>
>