From robert.field at oracle.com  Fri Mar  4 08:04:45 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 04 Mar 2016 00:04:45 -0800
Subject: RFR 8148316: jshell tool: Configurable output format, et. al. - v9
Message-ID: <56D9419D.1040607@oracle.com>

Update:
   Per Brian's review have added setting prompt -- /set prompt
   Per Jan's review have nice consistent verbose /help support and error 
messages, which meant rolling in the /set unification,
   have moved feedback support to its own class, added much more 
extensive testing including invalid input, and addressed the other 
smaller issues.
   Detailed help is available, for example:  /help set format
   To achieve clean errors, made new feedback mode creation explicit -- 
/set newmode

Bugs (the second (unrelated) bug was discovered and fixed in the process 
of testing, the third bug was added to address output consistency)
     https://bugs.openjdk.java.net/browse/JDK-8148316
     https://bugs.openjdk.java.net/browse/JDK-8149524
     https://bugs.openjdk.java.net/browse/JDK-8148317

Webrev:
     http://cr.openjdk.java.net/~rfield/8148316v9.webrev/

The example output configuration has been updated accordingly (Open with 
/open):
     http://cr.openjdk.java.net/~rfield/formats/arrowResultNlMeta.jsh

Thanks,
Robert

From andrei.i.eremeev at mail.ru  Sat Mar  5 13:29:25 2016
From: andrei.i.eremeev at mail.ru (Andrei Eremeev)
Date: Sat, 5 Mar 2016 16:29:25 +0300
Subject: Pluggable commands in the JShell tool
Message-ID: <56DADF35.5020809@mail.ru>

Hi REPL team,

What do you think about pluggable commands in JShell? It will allow 
users implementing their custom commands. For example, JShell can be 
used in scripting, and it is useful to run a process within it. So, a 
user can implement a command, like /run-process, and register it as a 
service.
The commands can be loaded by ServiceLoader, and they should implement 
an interface, like:

public interface Command {
     boolean run(JShellWrapper jShell, String arg);	// JShellWrapper is a class/interface which encapsulates JShellTool/JShellState
     String command();					// command name
     boolean matches(String input);			// a method to understand whether the input typed by a user is the current command
     String/List<String> parameters();			// information to be printed in the help command
     String description();				// information to be printed in the help command
     String help();					// information to be printed in the help command
     CompletionProvider completionProvider();		// a provider to suggest completions for arguments of the command
}

What do you think?

Andrei

From brian.goetz at oracle.com  Sun Mar  6 20:56:09 2016
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 6 Mar 2016 15:56:09 -0500
Subject: Pluggable commands in the JShell tool
In-Reply-To: <56DADF35.5020809@mail.ru>
References: <56DADF35.5020809@mail.ru>
Message-ID: <7F9672E9-BB50-4DD5-80EE-0AC1F1EE9631@oracle.com>

It?s a reasonable idea.  (It would also be good if at least some of the commands supported by the shell tool could then use such a mechanism.)  But I think its a bit much to think about for 9. 

> On Mar 5, 2016, at 8:29 AM, Andrei Eremeev <andrei.i.eremeev at mail.ru> wrote:
> 
> Hi REPL team,
> 
> What do you think about pluggable commands in JShell? It will allow users implementing their custom commands. For example, JShell can be used in scripting, and it is useful to run a process within it. So, a user can implement a command, like /run-process, and register it as a service.
> The commands can be loaded by ServiceLoader, and they should implement an interface, like:
> 
> public interface Command {
>    boolean run(JShellWrapper jShell, String arg);	// JShellWrapper is a class/interface which encapsulates JShellTool/JShellState
>    String command();					// command name
>    boolean matches(String input);			// a method to understand whether the input typed by a user is the current command
>    String/List<String> parameters();			// information to be printed in the help command
>    String description();				// information to be printed in the help command
>    String help();					// information to be printed in the help command
>    CompletionProvider completionProvider();		// a provider to suggest completions for arguments of the command
> }
> 
> What do you think?
> 
> Andrei


From sundararajan.athijegannathan at oracle.com  Mon Mar  7 03:41:12 2016
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 7 Mar 2016 09:11:12 +0530
Subject: Pluggable commands in the JShell tool
In-Reply-To: <7F9672E9-BB50-4DD5-80EE-0AC1F1EE9631@oracle.com>
References: <56DADF35.5020809@mail.ru>
	<7F9672E9-BB50-4DD5-80EE-0AC1F1EE9631@oracle.com>
Message-ID: <56DCF858.5000803@oracle.com>

If that level of customization is needed, I think jjs tool can be used.
JShell Java API can be accessed from JavaScript and jjs provides
interactive shell with tab-completion, history etc.  "commands" can be
just JS functions implemented in scripts loaded in the prompt or on
start-up.

-Sundar

On 3/7/2016 2:26 AM, Brian Goetz wrote:
> It?s a reasonable idea.  (It would also be good if at least some of the commands supported by the shell tool could then use such a mechanism.)  But I think its a bit much to think about for 9. 
>
>> On Mar 5, 2016, at 8:29 AM, Andrei Eremeev <andrei.i.eremeev at mail.ru> wrote:
>>
>> Hi REPL team,
>>
>> What do you think about pluggable commands in JShell? It will allow users implementing their custom commands. For example, JShell can be used in scripting, and it is useful to run a process within it. So, a user can implement a command, like /run-process, and register it as a service.
>> The commands can be loaded by ServiceLoader, and they should implement an interface, like:
>>
>> public interface Command {
>>    boolean run(JShellWrapper jShell, String arg);	// JShellWrapper is a class/interface which encapsulates JShellTool/JShellState
>>    String command();					// command name
>>    boolean matches(String input);			// a method to understand whether the input typed by a user is the current command
>>    String/List<String> parameters();			// information to be printed in the help command
>>    String description();				// information to be printed in the help command
>>    String help();					// information to be printed in the help command
>>    CompletionProvider completionProvider();		// a provider to suggest completions for arguments of the command
>> }
>>
>> What do you think?
>>
>> Andrei


From robert.field at oracle.com  Tue Mar  8 04:04:11 2016
From: robert.field at oracle.com (Robert Field)
Date: Mon, 07 Mar 2016 20:04:11 -0800
Subject: RFR 8080069: JShell: Support for corralled classes
Message-ID: <56DE4F3B.3070304@oracle.com>

The ability to corral classes has been a long desires feature, now it 
was required to to fix a bug in dependent overloaded methods.

Please review at your earliest convenience to unblock the other work.

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

Webrev:
     http://cr.openjdk.java.net/~rfield/8080069v0/

Thanks,
Robert


From jan.lahoda at oracle.com  Tue Mar  8 14:55:25 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 08 Mar 2016 15:55:25 +0100
Subject: RFR 8148316: jshell tool: Configurable output format, et. al. - v9
In-Reply-To: <56D9419D.1040607@oracle.com>
References: <56D9419D.1040607@oracle.com>
Message-ID: <56DEE7DD.4010305@oracle.com>

Overall, seems OK to me. Some minor comments:

-should initializeFeedbackModes be moved to Feedback, or to a separate 
file (that would be automatically loaded on startup)? But maybe it does 
not consume too much space in JShellTool

-Nit in JShellTool.java:
@@ -183,45 +253,106 @@
      // Tool id (tid) mapping: the current name spaces
      NameSpace currentNameSpace;

      Map<Snippet,SnippetInfo> mapSnippet;

+    /**
+     * I the input/output currently interactive

Typo: "I" -> "Is"

+     * @return true if console
+     */
+    boolean interactive() {
+         return input != null && input.interactiveOutput();
+    }
+

-in the /help /set, currently it looks like this:
|  The contents of the specified <file> become the default start-up 
snippets and commands.
|  /set start <file>

should it be in the opposite order, i.e.:
|  /set start <file>
|  The contents of the specified <file> become the default start-up 
snippets and commands.

?

Jan

On 4.3.2016 09:04, Robert Field wrote:
> Update:
>    Per Brian's review have added setting prompt -- /set prompt
>    Per Jan's review have nice consistent verbose /help support and error
> messages, which meant rolling in the /set unification,
>    have moved feedback support to its own class, added much more
> extensive testing including invalid input, and addressed the other
> smaller issues.
>    Detailed help is available, for example:  /help set format
>    To achieve clean errors, made new feedback mode creation explicit --
> /set newmode
>
> Bugs (the second (unrelated) bug was discovered and fixed in the process
> of testing, the third bug was added to address output consistency)
>      https://bugs.openjdk.java.net/browse/JDK-8148316
>      https://bugs.openjdk.java.net/browse/JDK-8149524
>      https://bugs.openjdk.java.net/browse/JDK-8148317
>
> Webrev:
>      http://cr.openjdk.java.net/~rfield/8148316v9.webrev/
>
> The example output configuration has been updated accordingly (Open with
> /open):
>      http://cr.openjdk.java.net/~rfield/formats/arrowResultNlMeta.jsh
>
> Thanks,
> Robert

From robert.field at oracle.com  Tue Mar  8 18:44:29 2016
From: robert.field at oracle.com (Robert Field)
Date: Tue, 08 Mar 2016 10:44:29 -0800
Subject: RFR 8148316: jshell tool: Configurable output format, et. al. - v9
In-Reply-To: <56DEE7DD.4010305@oracle.com>
References: <56D9419D.1040607@oracle.com> <56DEE7DD.4010305@oracle.com>
Message-ID: <56DF1D8D.4050006@oracle.com>


On 03/08/16 06:55, Jan Lahoda wrote:
> Overall, seems OK to me. Some minor comments:
>
> -should initializeFeedbackModes be moved to Feedback, or to a separate 
> file (that would be automatically loaded on startup)? But maybe it 
> does not consume too much space in JShellTool

I initially did this but it required writing a version of the /set 
command to live in Feedback.  Finally I decided that Feedback is the 
engine and the init was the configuration (which we know will change) so 
it was fine to have them separate.

>
> -Nit in JShellTool.java:
> @@ -183,45 +253,106 @@
>      // Tool id (tid) mapping: the current name spaces
>      NameSpace currentNameSpace;
>
>      Map<Snippet,SnippetInfo> mapSnippet;
>
> +    /**
> +     * I the input/output currently interactive
>
> Typo: "I" -> "Is"

Fixed.

>
> +     * @return true if console
> +     */
> +    boolean interactive() {
> +         return input != null && input.interactiveOutput();
> +    }
> +
>
> -in the /help /set, currently it looks like this:
> |  The contents of the specified <file> become the default start-up 
> snippets and commands.
> |  /set start <file>
>
> should it be in the opposite order, i.e.:
> |  /set start <file>
> |  The contents of the specified <file> become the default start-up 
> snippets and commands.
>
> ?

Everywhere else is command first.  Will reverse.

Fixed.  Also switched to the indent style used in help for other commands --

-> /help /set
|
|  /set
|
|  Set jshell configuration information, including:
|  the external editor to use, the start-up definitions to use, a new 
feedback mode,
|  the command prompt, the feedback mode to use, or the format of output.
|
|  /set editor <command> <optional-arg>...
|    -- Specify the command to launch for the /edit command.
|       The <command> is an operating system dependent string.
|
|  /set start <file>
|    -- The contents of the specified <file> become the default start-up 
snippets and commands.
|
|  /set feedback <mode>
|    -- Set the feedback mode describing displayed feedback for entered 
snippets and commands.
|
|  /set newmode <new-mode> [command|quiet [<old-mode>]]
|    -- Create a user-defined feedback mode, optionally copying from an 
existing mode.
|
|  /set prompt <mode> "<prompt>" "<continuation-prompt>"
|    -- Set the displayed prompts for a given feedback mode.
|
|  /set format <mode> "<format>" <selector>...
|    -- Configure a feedback mode by setting the format to use in a 
specified set of cases.
|
|  /set field 
name|type|result|when|action|resolve|pre|post|errorpre|errorpost 
"<format>"  <format-case>...
|    -- Set the format of a field within the <format-string> of a "/set 
format" command
|
|  To get more information about one of these forms, use /help with the 
form specified.
|  For example:   /help /set format
|


Thanks Jan!

-Robert


>
> Jan
>
> On 4.3.2016 09:04, Robert Field wrote:
>> Update:
>>    Per Brian's review have added setting prompt -- /set prompt
>>    Per Jan's review have nice consistent verbose /help support and error
>> messages, which meant rolling in the /set unification,
>>    have moved feedback support to its own class, added much more
>> extensive testing including invalid input, and addressed the other
>> smaller issues.
>>    Detailed help is available, for example:  /help set format
>>    To achieve clean errors, made new feedback mode creation explicit --
>> /set newmode
>>
>> Bugs (the second (unrelated) bug was discovered and fixed in the process
>> of testing, the third bug was added to address output consistency)
>>      https://bugs.openjdk.java.net/browse/JDK-8148316
>>      https://bugs.openjdk.java.net/browse/JDK-8149524
>>      https://bugs.openjdk.java.net/browse/JDK-8148317
>>
>> Webrev:
>>      http://cr.openjdk.java.net/~rfield/8148316v9.webrev/
>>
>> The example output configuration has been updated accordingly (Open with
>> /open):
>> http://cr.openjdk.java.net/~rfield/formats/arrowResultNlMeta.jsh
>>
>> Thanks,
>> Robert


From volker.simonis at gmail.com  Wed Mar  9 09:26:34 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 9 Mar 2016 10:26:34 +0100
Subject: RFR(XS): 8150632: jdk.jshell.TaskFactory should use jdk.Version
	to check for java.specification.version
In-Reply-To: <CA+3eh121mnmz1Ygox6-YQaPWDAA0oK=WjkRHt0UKHx3tBnW_mQ@mail.gmail.com>
References: <CA+3eh10khHLEwSink150YOvX=6b16F24oqFrJ8-1_kPd7nWD6w@mail.gmail.com>
	<CA+3eh121mnmz1Ygox6-YQaPWDAA0oK=WjkRHt0UKHx3tBnW_mQ@mail.gmail.com>
Message-ID: <CA+3eh111sw_uUfF-39j+KAMupoduazndp+2-PLfBZa8AcL=_0Q@mail.gmail.com>

PING!

Can I please have a review for this trivial change?

Thank you and best regards,
Volker


On Mon, Feb 29, 2016 at 10:20 AM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Also forwarding to kulla-dev which may be more appropriate than compiler-dev.
>
>
> ---------- Forwarded message ----------
> From: Volker Simonis <volker.simonis at gmail.com>
> Date: Thu, Feb 25, 2016 at 1:11 PM
> Subject: RFR(XS): 8150632: jdk.jshell.TaskFactory should use
> jdk.Version to check for java.specification.version
> To: compiler-dev at openjdk.java.net
>
>
> Hi,
>
> can I please have a review for the following small patch which fixes a
> problem with the jshell java.specification.version check:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2016/8150632/
> https://bugs.openjdk.java.net/browse/JDK-8150632
>
> Currently, jdk.jshell.TaskFactory does a hard check against
> java.specification.version being "9". Until JDK-8149519 [1] will be
> resolved, this check will fail for any newer Java release (i.e.
> 9.0.0.1).
>
> But even if JDK-8149519 will be resolved, I think the compare should
> actually check that java.specification.version is greater or equal to
> "9". This can be easily done with the new jdk.Version API.
>
> Thank you and best regards,
> Volker
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8149519

From robert.field at oracle.com  Wed Mar  9 16:59:29 2016
From: robert.field at oracle.com (Robert Field)
Date: Wed, 09 Mar 2016 08:59:29 -0800
Subject: RFR(XS): 8150632: jdk.jshell.TaskFactory should use jdk.Version
	to check for java.specification.version
In-Reply-To: <CA+3eh111sw_uUfF-39j+KAMupoduazndp+2-PLfBZa8AcL=_0Q@mail.gmail.com>
References: <CA+3eh10khHLEwSink150YOvX=6b16F24oqFrJ8-1_kPd7nWD6w@mail.gmail.com>
	<CA+3eh121mnmz1Ygox6-YQaPWDAA0oK=WjkRHt0UKHx3tBnW_mQ@mail.gmail.com>
	<CA+3eh111sw_uUfF-39j+KAMupoduazndp+2-PLfBZa8AcL=_0Q@mail.gmail.com>
Message-ID: <1535c51a968.2765.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Thumbs up!

Thanks,
Robert



On March 9, 2016 1:26:56 AM Volker Simonis <volker.simonis at gmail.com> wrote:

> PING!
>
> Can I please have a review for this trivial change?
>
> Thank you and best regards,
> Volker
>
>
> On Mon, Feb 29, 2016 at 10:20 AM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> Also forwarding to kulla-dev which may be more appropriate than compiler-dev.
>>
>>
>> ---------- Forwarded message ----------
>> From: Volker Simonis <volker.simonis at gmail.com>
>> Date: Thu, Feb 25, 2016 at 1:11 PM
>> Subject: RFR(XS): 8150632: jdk.jshell.TaskFactory should use
>> jdk.Version to check for java.specification.version
>> To: compiler-dev at openjdk.java.net
>>
>>
>> Hi,
>>
>> can I please have a review for the following small patch which fixes a
>> problem with the jshell java.specification.version check:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8150632/
>> https://bugs.openjdk.java.net/browse/JDK-8150632
>>
>> Currently, jdk.jshell.TaskFactory does a hard check against
>> java.specification.version being "9". Until JDK-8149519 [1] will be
>> resolved, this check will fail for any newer Java release (i.e.
>> 9.0.0.1).
>>
>> But even if JDK-8149519 will be resolved, I think the compare should
>> actually check that java.specification.version is greater or equal to
>> "9". This can be easily done with the new jdk.Version API.
>>
>> Thank you and best regards,
>> Volker
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8149519



From jonathan.gibbons at oracle.com  Wed Mar  9 21:40:35 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 09 Mar 2016 13:40:35 -0800
Subject: jshell tests affect command shell windows
Message-ID: <56E09853.3060204@oracle.com>

Kulla team,

Using the latest jdk9/dev bits, if I run the langtools/test/jdk/jshell 
tests, my terminal window becomes corrupted, such that no printable 
characters are echoed, and "return" just displays the prompt echaracters 
repeatedly on the same line.

A reset command clears the condition, but this is still a pretty serious 
problem.

-- Jon

From robert.field at oracle.com  Wed Mar  9 22:16:09 2016
From: robert.field at oracle.com (Robert Field)
Date: Wed, 09 Mar 2016 14:16:09 -0800
Subject: jshell tests affect command shell windows
In-Reply-To: <56E09853.3060204@oracle.com>
References: <56E09853.3060204@oracle.com>
Message-ID: <56E0A0A9.7050201@oracle.com>

That's not so good (understatement).

What platform are you on?

-Robert

On 03/09/16 13:40, Jonathan Gibbons wrote:
> Kulla team,
>
> Using the latest jdk9/dev bits, if I run the langtools/test/jdk/jshell 
> tests, my terminal window becomes corrupted, such that no printable 
> characters are echoed, and "return" just displays the prompt 
> echaracters repeatedly on the same line.
>
> A reset command clears the condition, but this is still a pretty 
> serious problem.
>
> -- Jon


From jonathan.gibbons at oracle.com  Thu Mar 10 00:14:51 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 09 Mar 2016 16:14:51 -0800
Subject: jshell tests affect command shell windows
In-Reply-To: <56E0A0A9.7050201@oracle.com>
References: <56E09853.3060204@oracle.com> <56E0A0A9.7050201@oracle.com>
Message-ID: <56E0BC7B.4080508@oracle.com>

Linux, Ununtu 14.04.

Vicente reported it on a server, same environment.

-- Jon

On 03/09/2016 02:16 PM, Robert Field wrote:
> That's not so good (understatement).
>
> What platform are you on?
>
> -Robert
>
> On 03/09/16 13:40, Jonathan Gibbons wrote:
>> Kulla team,
>>
>> Using the latest jdk9/dev bits, if I run the 
>> langtools/test/jdk/jshell tests, my terminal window becomes 
>> corrupted, such that no printable characters are echoed, and "return" 
>> just displays the prompt echaracters repeatedly on the same line.
>>
>> A reset command clears the condition, but this is still a pretty 
>> serious problem.
>>
>> -- Jon
>


From jan.lahoda at oracle.com  Thu Mar 10 18:29:56 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 10 Mar 2016 19:29:56 +0100
Subject: jshell tests affect command shell windows
In-Reply-To: <56E0BC7B.4080508@oracle.com>
References: <56E09853.3060204@oracle.com> <56E0A0A9.7050201@oracle.com>
	<56E0BC7B.4080508@oracle.com>
Message-ID: <56E1BD24.4020503@oracle.com>

I guess (a part of) the problem may be tests tweaking the console 
settings and running concurrently (one test changing the console 
settings/changing console to raw; another one running concurrently 
storing these settings, and then the first one ending, followed by the 
second one ending, and actually reseting the console settings to the 
wrong values). So, I guess, the best would be if we avoided setting the 
console to the raw mode during tests (as I don't think we need that anyway):
http://cr.openjdk.java.net/~jlahoda/jshell-test-terminal-change/webrev/

What do you think?

Thanks,
    Jan

On 10.3.2016 01:14, Jonathan Gibbons wrote:
> Linux, Ununtu 14.04.
>
> Vicente reported it on a server, same environment.
>
> -- Jon
>
> On 03/09/2016 02:16 PM, Robert Field wrote:
>> That's not so good (understatement).
>>
>> What platform are you on?
>>
>> -Robert
>>
>> On 03/09/16 13:40, Jonathan Gibbons wrote:
>>> Kulla team,
>>>
>>> Using the latest jdk9/dev bits, if I run the
>>> langtools/test/jdk/jshell tests, my terminal window becomes
>>> corrupted, such that no printable characters are echoed, and "return"
>>> just displays the prompt echaracters repeatedly on the same line.
>>>
>>> A reset command clears the condition, but this is still a pretty
>>> serious problem.
>>>
>>> -- Jon
>>
>

From robert.field at oracle.com  Thu Mar 10 18:56:43 2016
From: robert.field at oracle.com (Robert Field)
Date: Thu, 10 Mar 2016 10:56:43 -0800
Subject: jshell tests affect command shell windows
In-Reply-To: <56E1BD24.4020503@oracle.com>
References: <56E09853.3060204@oracle.com> <56E0A0A9.7050201@oracle.com>
	<56E0BC7B.4080508@oracle.com> <56E1BD24.4020503@oracle.com>
Message-ID: <15361e359f8.2765.4011f3a8741ca2aabce58b8b81f42d24@oracle.com>

Seems a reasonable approach since the tests cannot test that the console 
does the right thing anyhow.

Thumbs up.

Thanks,
Robert



On March 10, 2016 10:30:00 AM Jan Lahoda <jan.lahoda at oracle.com> wrote:

> I guess (a part of) the problem may be tests tweaking the console
> settings and running concurrently (one test changing the console
> settings/changing console to raw; another one running concurrently
> storing these settings, and then the first one ending, followed by the
> second one ending, and actually reseting the console settings to the
> wrong values). So, I guess, the best would be if we avoided setting the
> console to the raw mode during tests (as I don't think we need that anyway):
> http://cr.openjdk.java.net/~jlahoda/jshell-test-terminal-change/webrev/
>
> What do you think?
>
> Thanks,
>     Jan
>
> On 10.3.2016 01:14, Jonathan Gibbons wrote:
>> Linux, Ununtu 14.04.
>>
>> Vicente reported it on a server, same environment.
>>
>> -- Jon
>>
>> On 03/09/2016 02:16 PM, Robert Field wrote:
>>> That's not so good (understatement).
>>>
>>> What platform are you on?
>>>
>>> -Robert
>>>
>>> On 03/09/16 13:40, Jonathan Gibbons wrote:
>>>> Kulla team,
>>>>
>>>> Using the latest jdk9/dev bits, if I run the
>>>> langtools/test/jdk/jshell tests, my terminal window becomes
>>>> corrupted, such that no printable characters are echoed, and "return"
>>>> just displays the prompt echaracters repeatedly on the same line.
>>>>
>>>> A reset command clears the condition, but this is still a pretty
>>>> serious problem.
>>>>
>>>> -- Jon
>>>
>>



From jan.lahoda at oracle.com  Thu Mar 10 19:03:10 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 10 Mar 2016 20:03:10 +0100
Subject: RFR 8080069: JShell: Support for corralled classes
In-Reply-To: <56DE4F3B.3070304@oracle.com>
References: <56DE4F3B.3070304@oracle.com>
Message-ID: <56E1C4EE.5070508@oracle.com>

Seems OK to me.

Jan

On 8.3.2016 05:04, Robert Field wrote:
> The ability to corral classes has been a long desires feature, now it
> was required to to fix a bug in dependent overloaded methods.
>
> Please review at your earliest convenience to unblock the other work.
>
> Bug:
>      8080069:   https://bugs.openjdk.java.net/browse/JDK-8080069
>
> Webrev:
>      http://cr.openjdk.java.net/~rfield/8080069v0/
>
> Thanks,
> Robert
>

From g.ptashko at bgoperator.com  Fri Mar 11 16:45:54 2016
From: g.ptashko at bgoperator.com (Grigory Ptashko)
Date: Fri, 11 Mar 2016 19:45:54 +0300
Subject: jshell on ios without process exec?
Message-ID: <78866F4F-65AF-47B5-987B-712C13E31ADE@bgoperator.com>

Hello.

Long story short. I?ve just tried to use jshell on ios (both arm64 and simulator).

I try this:

JShell jshell = JShell.create();
List<SnippetEvent> events = jshell.eval("2+2");
System.out.println(events.get(0).value());

And get the exception:

Exception in thread "Thread-0" java.lang.Error: iOS is not a supported OS platform.
	at java.lang.ProcessImpl$Platform.get(ProcessImpl.java:171)
	at java.lang.ProcessImpl.<clinit>(ProcessImpl.java:175)
	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1111)
	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1075)
	at java.lang.Runtime.exec(Runtime.java:624)
	at java.lang.Runtime.exec(Runtime.java:483)
	at com.sun.tools.jdi.AbstractLauncher$Helper.launchAndAccept(AbstractLauncher.java:180)
	at com.sun.tools.jdi.AbstractLauncher.launch(AbstractLauncher.java:132)
	at com.sun.tools.jdi.SunCommandLineLauncher.launch(SunCommandLineLauncher.java:223)
	at jdk.jshell.JDIConnection.launchTarget(JDIConnection.java:303)
	at jdk.jshell.JDIConnection.open(JDIConnection.java:121)
	at jdk.jshell.JDIEnv.init(JDIEnv.java:49)
	at jdk.jshell.ExecutionControl.jdiGo(ExecutionControl.java:269)
	at jdk.jshell.ExecutionControl.launch(ExecutionControl.java:71)
	at jdk.jshell.JShell.executionControl(JShell.java:613)
	at jdk.jshell.ClassTracker$ClassInfo.getReferenceTypeOrNull(ClassTracker.java:81)
	at jdk.jshell.Unit.lambda$classesToLoad$3(Unit.java:266)
	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1422)
	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:591)
	at jdk.jshell.Unit.classesToLoad(Unit.java:264)
	at jdk.jshell.Eval.lambda$compileAndLoad$13(Eval.java:559)
	at java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:269)
	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1422)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:511)
	at jdk.jshell.Eval.compileAndLoad(Eval.java:560)
	at jdk.jshell.Eval.declare(Eval.java:462)
	at jdk.jshell.Eval.declare(Eval.java:448)
	at jdk.jshell.Eval.processExpression(Eval.java:291)
	at jdk.jshell.Eval.eval(Eval.java:118)
	at jdk.jshell.JShell.eval(JShell.java:350)
	at EvalJava.main(EvalJava.java:14)

Is it possible to use jshell without exec?ing a process? Within the same process?

Thank you.

--
Best regards,
Grigory Ptashko
Software developer at Biblio-Globus Touroperator
g.ptashko at bgoperator.com
Phone: +7 495 5042500 ext 1557
Mobile: +7 916 1489766


From robert.field at oracle.com  Fri Mar 11 19:19:21 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 11 Mar 2016 11:19:21 -0800
Subject: jshell on ios without process exec?
In-Reply-To: <78866F4F-65AF-47B5-987B-712C13E31ADE@bgoperator.com>
References: <78866F4F-65AF-47B5-987B-712C13E31ADE@bgoperator.com>
Message-ID: <56E31A39.1050603@oracle.com>

Hi Grigory,

It is theoretically possible to implement a (reduced functionality) 
in-process version of JShell, in fact the original prototypes were 
in-process.

At this point however, JDI (which is out of process) is well ensconced 
in the design.

I have intentionally left some support framework for in-process in the 
code to facilitate a possible future in-process option.  The code is 
open-source, so if you are inclined I'd be happy to give you pointers to 
re-implement in-process.

-Robert

On 03/11/16 08:45, Grigory Ptashko wrote:
> Hello.
>
> Long story short. I?ve just tried to use jshell on ios (both arm64 and simulator).
>
> I try this:
>
> JShell jshell = JShell.create();
> List<SnippetEvent> events = jshell.eval("2+2");
> System.out.println(events.get(0).value());
>
> And get the exception:
>
> Exception in thread "Thread-0" java.lang.Error: iOS is not a supported OS platform.
> 	at java.lang.ProcessImpl$Platform.get(ProcessImpl.java:171)
> 	at java.lang.ProcessImpl.<clinit>(ProcessImpl.java:175)
> 	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1111)
> 	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1075)
> 	at java.lang.Runtime.exec(Runtime.java:624)
> 	at java.lang.Runtime.exec(Runtime.java:483)
> 	at com.sun.tools.jdi.AbstractLauncher$Helper.launchAndAccept(AbstractLauncher.java:180)
> 	at com.sun.tools.jdi.AbstractLauncher.launch(AbstractLauncher.java:132)
> 	at com.sun.tools.jdi.SunCommandLineLauncher.launch(SunCommandLineLauncher.java:223)
> 	at jdk.jshell.JDIConnection.launchTarget(JDIConnection.java:303)
> 	at jdk.jshell.JDIConnection.open(JDIConnection.java:121)
> 	at jdk.jshell.JDIEnv.init(JDIEnv.java:49)
> 	at jdk.jshell.ExecutionControl.jdiGo(ExecutionControl.java:269)
> 	at jdk.jshell.ExecutionControl.launch(ExecutionControl.java:71)
> 	at jdk.jshell.JShell.executionControl(JShell.java:613)
> 	at jdk.jshell.ClassTracker$ClassInfo.getReferenceTypeOrNull(ClassTracker.java:81)
> 	at jdk.jshell.Unit.lambda$classesToLoad$3(Unit.java:266)
> 	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1422)
> 	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:591)
> 	at jdk.jshell.Unit.classesToLoad(Unit.java:264)
> 	at jdk.jshell.Eval.lambda$compileAndLoad$13(Eval.java:559)
> 	at java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:269)
> 	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1422)
> 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> 	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
> 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:511)
> 	at jdk.jshell.Eval.compileAndLoad(Eval.java:560)
> 	at jdk.jshell.Eval.declare(Eval.java:462)
> 	at jdk.jshell.Eval.declare(Eval.java:448)
> 	at jdk.jshell.Eval.processExpression(Eval.java:291)
> 	at jdk.jshell.Eval.eval(Eval.java:118)
> 	at jdk.jshell.JShell.eval(JShell.java:350)
> 	at EvalJava.main(EvalJava.java:14)
>
> Is it possible to use jshell without exec?ing a process? Within the same process?
>
> Thank you.
>
> --
> Best regards,
> Grigory Ptashko
> Software developer at Biblio-Globus Touroperator
> g.ptashko at bgoperator.com
> Phone: +7 495 5042500 ext 1557
> Mobile: +7 916 1489766
>


From grigory.ptashko at gmail.com  Fri Mar 11 20:00:09 2016
From: grigory.ptashko at gmail.com (Grigory Ptashko)
Date: Fri, 11 Mar 2016 23:00:09 +0300
Subject: jshell on ios without process exec?
In-Reply-To: <56E31A39.1050603@oracle.com>
References: <78866F4F-65AF-47B5-987B-712C13E31ADE@bgoperator.com>
	<56E31A39.1050603@oracle.com>
Message-ID: <9334D3EF-05D8-41DC-BE0C-A43394662528@gmail.com>

Hello Robert!

These are good news! My hope is not lost!

Please, give me the pointers I will definitely try to re-implement this.

Thank you.

> On 11 ????? 2016 ?., at 22:19, Robert Field <robert.field at oracle.com> wrote:
> 
> Hi Grigory,
> 
> It is theoretically possible to implement a (reduced functionality) in-process version of JShell, in fact the original prototypes were in-process.
> 
> At this point however, JDI (which is out of process) is well ensconced in the design.
> 
> I have intentionally left some support framework for in-process in the code to facilitate a possible future in-process option.  The code is open-source, so if you are inclined I'd be happy to give you pointers to re-implement in-process.
> 
> -Robert
> 
> On 03/11/16 08:45, Grigory Ptashko wrote:
>> Hello.
>> 
>> Long story short. I?ve just tried to use jshell on ios (both arm64 and simulator).
>> 
>> I try this:
>> 
>> JShell jshell = JShell.create();
>> List<SnippetEvent> events = jshell.eval("2+2");
>> System.out.println(events.get(0).value());
>> 
>> And get the exception:
>> 
>> Exception in thread "Thread-0" java.lang.Error: iOS is not a supported OS platform.
>> 	at java.lang.ProcessImpl$Platform.get(ProcessImpl.java:171)
>> 	at java.lang.ProcessImpl.<clinit>(ProcessImpl.java:175)
>> 	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1111)
>> 	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1075)
>> 	at java.lang.Runtime.exec(Runtime.java:624)
>> 	at java.lang.Runtime.exec(Runtime.java:483)
>> 	at com.sun.tools.jdi.AbstractLauncher$Helper.launchAndAccept(AbstractLauncher.java:180)
>> 	at com.sun.tools.jdi.AbstractLauncher.launch(AbstractLauncher.java:132)
>> 	at com.sun.tools.jdi.SunCommandLineLauncher.launch(SunCommandLineLauncher.java:223)
>> 	at jdk.jshell.JDIConnection.launchTarget(JDIConnection.java:303)
>> 	at jdk.jshell.JDIConnection.open(JDIConnection.java:121)
>> 	at jdk.jshell.JDIEnv.init(JDIEnv.java:49)
>> 	at jdk.jshell.ExecutionControl.jdiGo(ExecutionControl.java:269)
>> 	at jdk.jshell.ExecutionControl.launch(ExecutionControl.java:71)
>> 	at jdk.jshell.JShell.executionControl(JShell.java:613)
>> 	at jdk.jshell.ClassTracker$ClassInfo.getReferenceTypeOrNull(ClassTracker.java:81)
>> 	at jdk.jshell.Unit.lambda$classesToLoad$3(Unit.java:266)
>> 	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1422)
>> 	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:591)
>> 	at jdk.jshell.Unit.classesToLoad(Unit.java:264)
>> 	at jdk.jshell.Eval.lambda$compileAndLoad$13(Eval.java:559)
>> 	at java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:269)
>> 	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1422)
>> 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
>> 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
>> 	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
>> 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>> 	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:511)
>> 	at jdk.jshell.Eval.compileAndLoad(Eval.java:560)
>> 	at jdk.jshell.Eval.declare(Eval.java:462)
>> 	at jdk.jshell.Eval.declare(Eval.java:448)
>> 	at jdk.jshell.Eval.processExpression(Eval.java:291)
>> 	at jdk.jshell.Eval.eval(Eval.java:118)
>> 	at jdk.jshell.JShell.eval(JShell.java:350)
>> 	at EvalJava.main(EvalJava.java:14)
>> 
>> Is it possible to use jshell without exec?ing a process? Within the same process?
>> 
>> Thank you.
>> 
>> --
>> Best regards,
>> Grigory Ptashko
>> Software developer at Biblio-Globus Touroperator
>> g.ptashko at bgoperator.com
>> Phone: +7 495 5042500 ext 1557
>> Mobile: +7 916 1489766
>> 
> 


--
Best regards,
Grigory Ptashko

+7 (916) 1489766
grigory.ptashko at gmail.com
facebook.com/GrigoryPtashko


From robert.field at oracle.com  Fri Mar 11 20:46:53 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 11 Mar 2016 12:46:53 -0800
Subject: jshell on ios without process exec?
In-Reply-To: <9334D3EF-05D8-41DC-BE0C-A43394662528@gmail.com>
References: <78866F4F-65AF-47B5-987B-712C13E31ADE@bgoperator.com>
	<56E31A39.1050603@oracle.com>
	<9334D3EF-05D8-41DC-BE0C-A43394662528@gmail.com>
Message-ID: <56E32EBD.7060207@oracle.com>


On 03/11/16 12:00, Grigory Ptashko wrote:
> Hello Robert!
>
> These are good news! My hope is not lost!
>
> Please, give me the pointers I will definitely try to re-implement this.

Basically you would need to implement a new version of ExecutionControl 
-- so the non-private methods could define an interface with two 
implementations: a JDI version (current code) and a new in-process version.

For some of the functionality  look in MemoryFileManager you will find a 
some methods/classes labelled: // For restoring process-local execution 
support.

Without some special magic, you will not be able to implement some 
methods, notably commandRedefine(), just return false.

I thought this might be interesting to others, but most further 
communications should probably be off-list.

Enjoy,
Robert



>
> Thank you.
>
>> On 11 ????? 2016 ?., at 22:19, Robert Field <robert.field at oracle.com> wrote:
>>
>> Hi Grigory,
>>
>> It is theoretically possible to implement a (reduced functionality) in-process version of JShell, in fact the original prototypes were in-process.
>>
>> At this point however, JDI (which is out of process) is well ensconced in the design.
>>
>> I have intentionally left some support framework for in-process in the code to facilitate a possible future in-process option.  The code is open-source, so if you are inclined I'd be happy to give you pointers to re-implement in-process.
>>
>> -Robert
>>
>> On 03/11/16 08:45, Grigory Ptashko wrote:
>>> Hello.
>>>
>>> Long story short. I?ve just tried to use jshell on ios (both arm64 and simulator).
>>>
>>> I try this:
>>>
>>> JShell jshell = JShell.create();
>>> List<SnippetEvent> events = jshell.eval("2+2");
>>> System.out.println(events.get(0).value());
>>>
>>> And get the exception:
>>>
>>> Exception in thread "Thread-0" java.lang.Error: iOS is not a supported OS platform.
>>> 	at java.lang.ProcessImpl$Platform.get(ProcessImpl.java:171)
>>> 	at java.lang.ProcessImpl.<clinit>(ProcessImpl.java:175)
>>> 	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1111)
>>> 	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1075)
>>> 	at java.lang.Runtime.exec(Runtime.java:624)
>>> 	at java.lang.Runtime.exec(Runtime.java:483)
>>> 	at com.sun.tools.jdi.AbstractLauncher$Helper.launchAndAccept(AbstractLauncher.java:180)
>>> 	at com.sun.tools.jdi.AbstractLauncher.launch(AbstractLauncher.java:132)
>>> 	at com.sun.tools.jdi.SunCommandLineLauncher.launch(SunCommandLineLauncher.java:223)
>>> 	at jdk.jshell.JDIConnection.launchTarget(JDIConnection.java:303)
>>> 	at jdk.jshell.JDIConnection.open(JDIConnection.java:121)
>>> 	at jdk.jshell.JDIEnv.init(JDIEnv.java:49)
>>> 	at jdk.jshell.ExecutionControl.jdiGo(ExecutionControl.java:269)
>>> 	at jdk.jshell.ExecutionControl.launch(ExecutionControl.java:71)
>>> 	at jdk.jshell.JShell.executionControl(JShell.java:613)
>>> 	at jdk.jshell.ClassTracker$ClassInfo.getReferenceTypeOrNull(ClassTracker.java:81)
>>> 	at jdk.jshell.Unit.lambda$classesToLoad$3(Unit.java:266)
>>> 	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1422)
>>> 	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:591)
>>> 	at jdk.jshell.Unit.classesToLoad(Unit.java:264)
>>> 	at jdk.jshell.Eval.lambda$compileAndLoad$13(Eval.java:559)
>>> 	at java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:269)
>>> 	at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1422)
>>> 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
>>> 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
>>> 	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
>>> 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>>> 	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:511)
>>> 	at jdk.jshell.Eval.compileAndLoad(Eval.java:560)
>>> 	at jdk.jshell.Eval.declare(Eval.java:462)
>>> 	at jdk.jshell.Eval.declare(Eval.java:448)
>>> 	at jdk.jshell.Eval.processExpression(Eval.java:291)
>>> 	at jdk.jshell.Eval.eval(Eval.java:118)
>>> 	at jdk.jshell.JShell.eval(JShell.java:350)
>>> 	at EvalJava.main(EvalJava.java:14)
>>>
>>> Is it possible to use jshell without exec?ing a process? Within the same process?
>>>
>>> Thank you.
>>>
>>> --
>>> Best regards,
>>> Grigory Ptashko
>>> Software developer at Biblio-Globus Touroperator
>>> g.ptashko at bgoperator.com
>>> Phone: +7 495 5042500 ext 1557
>>> Mobile: +7 916 1489766
>>>
>
> --
> Best regards,
> Grigory Ptashko
>
> +7 (916) 1489766
> grigory.ptashko at gmail.com
> facebook.com/GrigoryPtashko
>


From robert.field at oracle.com  Fri Mar 11 22:37:03 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 11 Mar 2016 14:37:03 -0800
Subject: JShell tool feedback modes -- predefined and default
Message-ID: <56E3488F.3040505@oracle.com>

/set newmode verbose0 command

/set prompt verbose0 '\njshell> ' '   ...> '

/set field verbose0 pre '|  '
/set field verbose0 post '%n'
/set field verbose0 errorpre '|  Error: '
/set field verbose0 errorpost '%n'
/set field verbose0 action 'created' added-primary
/set field verbose0 action 'modified' modified-primary
/set field verbose0 action 'replaced' replaced-primary
/set field verbose0 action 'overwrote' overwrote-primary
/set field verbose0 action 'dropped' dropped-primary
/set field verbose0 action 'rejected' rejected-primary
/set field verbose0 action '  update added' added-update
/set field verbose0 action '  update modified' modified-update
/set field verbose0 action '  update replaced' replaced-update
/set field verbose0 action '  update overwrote' overwrote-update
/set field verbose0 action '  update dropped' dropped-update
/set field verbose0 action '  update rejected' rejected-update
/set field verbose0 resolve '' ok-*
/set field verbose0 resolve ', however, it cannot be invoked until%s is declared' defined-primary
/set field verbose0 resolve ', however, it cannot be referenced until%s is declared' notdefined-primary
/set field verbose0 resolve ' which cannot be invoked until%s is declared' defined-update
/set field verbose0 resolve ' which cannot be referenced until%s is declared' notdefined-update
/set field verbose0 name '%s'
/set field verbose0 type '%s'
/set field verbose0 result ' ==> %s%n'
        

/set format verbose0 '' *-*-*

/set format verbose0 '{pre}{action} class {name}{resolve}{post}' class-*-*
/set format verbose0 '{pre}{action} interface {name}{resolve}{post}' interface-*-*
/set format verbose0 '{pre}{action} enum {name}{resolve}{post}' enum-*-*
/set format verbose0 '{pre}{action} annotation interface {name}{resolve}{post}' annotation-*-*
        
/set format verbose0 '{pre}{action} method {name}({type}){resolve}{post}' method-*-*
        
/set format verbose0 '{pre}{action} variable {name}, reset to null{post}' varreset--update
        
/set format verbose0 '{pre}{action} variable {name} : {type}{resolve}{post}' varinit-*-* vardecl-*-* vardeclrecoverable-*-*
/set format verbose0 '{name}{result}{pre}{action} variable {name} : {type}{resolve}{post}' varinit vardecl vardeclrecoverable

/set format verbose0 '{name}{result}{pre}created scratch variable {name} : {type}{post}' expression
/set format verbose0 '{name}{result}{pre}value of {name} : {type}{post}' varvalue 
/set format verbose0 '{name}{result}{pre}assigned to {name} : {type}{post}' assignment

/set newmode default0 command verbose0

/set format default0 '' *-*-update

/set format default0 '{pre}{action} variable {name}, reset to null{post}' varreset--update
        
/set format default0 '{name}{result}' expression varvalue assignment varinit vardecl

/set newmode concise0 command default0

/set prompt concise0 'jshell> ' '   ...> '

/set format concise0 '' class-* interface-* enum-* method-*

/set feedback default0

From robert.field at oracle.com  Sat Mar 12 00:09:55 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 11 Mar 2016 16:09:55 -0800
Subject: JShell tool feedback modes -- predefined and default
In-Reply-To: <56E3488F.3040505@oracle.com>
References: <56E3488F.3040505@oracle.com>
Message-ID: <56E35E53.6080307@oracle.com>

[hmmm...,  For some reason kulla-dev seems to have removed all the text 
from my message.  Trying again using a link rather than an attachment...]

I recently added an output configuration mechanism to the jshell tool, 
allowing users to specify how they would like feedback from the tool to 
look.  And, importantly, allowing us to experiment with what we want the 
default mode to look like.

Using this, Brian and I have been discussing what we want.  Some of the 
conclusions are:

     * Some of the output is essential and should be highlighted and 
always displayed:  results and errors  (and possible temp var name)
     * Some of the output is informative but can be garnered in other 
ways: type
     * Some of the output is confirmation, which is reassuring to new 
users and annoying to frequent users
     * We decided that it would help making design choices (and give 
easy options to users) if there were three predefined levels of output: 
verbose, concise, and default
     * If we can come up with a consistent layout for concise and 
verbose, the more challenging choice of layout for default would be a 
matter of picking between the two.
     * result is essential and needs a special form.
     * Other information is optional and would not show in more concise 
modes
     * temp variables are generated for expressions to allow access to 
these values, without displaying what the temp variable name it is of 
little use, thus this name cannot be displayed only in the optional 
information
     * so, rather than create an asymmetry, the variable name should be 
displayed in the result
     * the length of the regular and continuation prompts must be the 
same, else indenting is confusing
     * there needs to be easy ways to set the mode (say by an instructor 
or and experienced user) so a command-line option is needed
     * /help should (in default mode) offer the /set feedback verbose

Based on these discussions and some of our earlier prototypes, I have 
created the (version 0) feedback modes: verbose0, default0, and concise0 
as progressive filters on the corresponding more verbose mode.

Download:
     http://cr.openjdk.java.net/~rfield/proto.modes

Starting with a current build of jdk9/dev,  start jshell and type:
     /open proto.modes

It sets to default0, you can change this with:
    /set feedback verbose0
which you can abbreviate to:
    /se fe v

What do you think?
What would you change?
New mode definitions welcome.

Thanks,
Robert


From brian.goetz at oracle.com  Sat Mar 12 00:45:01 2016
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 11 Mar 2016 19:45:01 -0500
Subject: JShell tool feedback modes -- predefined and default
In-Reply-To: <56E35E53.6080307@oracle.com>
References: <56E3488F.3040505@oracle.com> <56E35E53.6080307@oracle.com>
Message-ID: <56E3668D.8060209@oracle.com>

For declaration with initialization:

jshell> int a =3
a ==> 3

and for assignment:

jshell> a = 3
a ==> 3

I would drop the {result} feedback for this form (in default and 
concise).  A declaration with initialization, or assignment, should be 
like any other statement (if, for, while) and these do not produce 
output.  If the user does

jshell> a = 3

and wants to see the value of a, s/he can always ask by evaluating 'a'.


On 3/11/2016 7:09 PM, Robert Field wrote:
> [hmmm..., For some reason kulla-dev seems to have removed all the text 
> from my message.  Trying again using a link rather than an attachment...]
>
> I recently added an output configuration mechanism to the jshell tool, 
> allowing users to specify how they would like feedback from the tool 
> to look.  And, importantly, allowing us to experiment with what we 
> want the default mode to look like.
>
> Using this, Brian and I have been discussing what we want.  Some of 
> the conclusions are:
>
>     * Some of the output is essential and should be highlighted and 
> always displayed:  results and errors  (and possible temp var name)
>     * Some of the output is informative but can be garnered in other 
> ways: type
>     * Some of the output is confirmation, which is reassuring to new 
> users and annoying to frequent users
>     * We decided that it would help making design choices (and give 
> easy options to users) if there were three predefined levels of 
> output: verbose, concise, and default
>     * If we can come up with a consistent layout for concise and 
> verbose, the more challenging choice of layout for default would be a 
> matter of picking between the two.
>     * result is essential and needs a special form.
>     * Other information is optional and would not show in more concise 
> modes
>     * temp variables are generated for expressions to allow access to 
> these values, without displaying what the temp variable name it is of 
> little use, thus this name cannot be displayed only in the optional 
> information
>     * so, rather than create an asymmetry, the variable name should be 
> displayed in the result
>     * the length of the regular and continuation prompts must be the 
> same, else indenting is confusing
>     * there needs to be easy ways to set the mode (say by an 
> instructor or and experienced user) so a command-line option is needed
>     * /help should (in default mode) offer the /set feedback verbose
>
> Based on these discussions and some of our earlier prototypes, I have 
> created the (version 0) feedback modes: verbose0, default0, and 
> concise0 as progressive filters on the corresponding more verbose mode.
>
> Download:
>     http://cr.openjdk.java.net/~rfield/proto.modes
>
> Starting with a current build of jdk9/dev,  start jshell and type:
>     /open proto.modes
>
> It sets to default0, you can change this with:
>    /set feedback verbose0
> which you can abbreviate to:
>    /se fe v
>
> What do you think?
> What would you change?
> New mode definitions welcome.
>
> Thanks,
> Robert
>


From robert.field at oracle.com  Sat Mar 12 02:31:38 2016
From: robert.field at oracle.com (Robert Field)
Date: Fri, 11 Mar 2016 18:31:38 -0800
Subject: JShell tool feedback modes -- predefined and default
In-Reply-To: <56E3668D.8060209@oracle.com>
References: <56E3488F.3040505@oracle.com> <56E35E53.6080307@oracle.com>
	<56E3668D.8060209@oracle.com>
Message-ID: <56E37F8A.3050308@oracle.com>

That is exactly the kind of information I'd love to get from real-world 
use.  Is knowing the value of assignments and initializations frequently 
useful or usually noise?
I encourage all to use one of these as your default mode.

Thanks,
Robert

On 03/11/16 16:45, Brian Goetz wrote:
> For declaration with initialization:
>
> jshell> int a =3
> a ==> 3
>
> and for assignment:
>
> jshell> a = 3
> a ==> 3
>
> I would drop the {result} feedback for this form (in default and 
> concise).  A declaration with initialization, or assignment, should be 
> like any other statement (if, for, while) and these do not produce 
> output.  If the user does
>
> jshell> a = 3
>
> and wants to see the value of a, s/he can always ask by evaluating 'a'.
>
>
> On 3/11/2016 7:09 PM, Robert Field wrote:
>> [hmmm..., For some reason kulla-dev seems to have removed all the 
>> text from my message.  Trying again using a link rather than an 
>> attachment...]
>>
>> I recently added an output configuration mechanism to the jshell 
>> tool, allowing users to specify how they would like feedback from the 
>> tool to look.  And, importantly, allowing us to experiment with what 
>> we want the default mode to look like.
>>
>> Using this, Brian and I have been discussing what we want.  Some of 
>> the conclusions are:
>>
>>     * Some of the output is essential and should be highlighted and 
>> always displayed:  results and errors  (and possible temp var name)
>>     * Some of the output is informative but can be garnered in other 
>> ways: type
>>     * Some of the output is confirmation, which is reassuring to new 
>> users and annoying to frequent users
>>     * We decided that it would help making design choices (and give 
>> easy options to users) if there were three predefined levels of 
>> output: verbose, concise, and default
>>     * If we can come up with a consistent layout for concise and 
>> verbose, the more challenging choice of layout for default would be a 
>> matter of picking between the two.
>>     * result is essential and needs a special form.
>>     * Other information is optional and would not show in more 
>> concise modes
>>     * temp variables are generated for expressions to allow access to 
>> these values, without displaying what the temp variable name it is of 
>> little use, thus this name cannot be displayed only in the optional 
>> information
>>     * so, rather than create an asymmetry, the variable name should 
>> be displayed in the result
>>     * the length of the regular and continuation prompts must be the 
>> same, else indenting is confusing
>>     * there needs to be easy ways to set the mode (say by an 
>> instructor or and experienced user) so a command-line option is needed
>>     * /help should (in default mode) offer the /set feedback verbose
>>
>> Based on these discussions and some of our earlier prototypes, I have 
>> created the (version 0) feedback modes: verbose0, default0, and 
>> concise0 as progressive filters on the corresponding more verbose mode.
>>
>> Download:
>>     http://cr.openjdk.java.net/~rfield/proto.modes
>>
>> Starting with a current build of jdk9/dev,  start jshell and type:
>>     /open proto.modes
>>
>> It sets to default0, you can change this with:
>>    /set feedback verbose0
>> which you can abbreviate to:
>>    /se fe v
>>
>> What do you think?
>> What would you change?
>> New mode definitions welcome.
>>
>> Thanks,
>> Robert
>>
>


From robert.field at oracle.com  Mon Mar 21 03:34:04 2016
From: robert.field at oracle.com (Robert Field)
Date: Sun, 20 Mar 2016 20:34:04 -0700
Subject: RFR 8151755: JShell: Generalization of output configuration
Message-ID: <56EF6BAC.6060503@oracle.com>

To cover the full prototypes of default configuration and any futures, 
the output configuration mechanism is moved to a more general and 
conceptually simpler design (despite a more sophisticated/complex 
implementation).
All formatting is now done by defining fields conditionally on selectors 
which are universal and not order dependent.
The /set format and /set field commands have been merged.
The new '/help /set *' docs and the feedback set-up are now in a 
resource file as the first step towards internationalization.
The /drop command and the message which is generated with an attempt to 
execute corralled code is now integrated into the output configuration 
mechanism..
The format of resolution issue messages can now be properly structured 
depending on the number of unresolved/errors.
In the process of developing tests for the new functionality, the 
ability to overflow the maximum size of history (stored in Preferences) 
was discovered and fixed.

Bugs:
     8151755 jshell tool: properly cover resolution issues in output 
configuration
     https://bugs.openjdk.java.net/browse/JDK-8151755

     8152246 jshell tool: history overflow
     https://bugs.openjdk.java.net/browse/JDK-8152246

Webrev:
     http://cr.openjdk.java.net/~rfield/8151755.webrev/

Sample configuration files -- I have updated proto.modes to the new 
format, and normal mode can be seen (resource file formatted) in 
l10n.properties:
     http://cr.openjdk.java.net/~rfield/formats/proto2.modes
http://cr.openjdk.java.net/~rfield/8151755.webrev/raw_files/new/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties

Thanks,
Robert


From jan.lahoda at oracle.com  Mon Mar 21 13:28:39 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 21 Mar 2016 14:28:39 +0100
Subject: RFR 8152296: langtools/test/jdk/jshell/ToolReloadTest.java failing
	if there is no persisted history
Message-ID: <56EFF707.4060703@oracle.com>

Hi,

Recently, I changed ConsoleIOContext to use UnsupportedTerminal while 
running test, to avoid setting the terminal to the raw mode. Seems that 
does not work well - some features, e.g. history, don't work correctly 
with the UnsupportedTerminal. So, I propose to change that to a dummy 
testing terminal.

Also, the tests are currently using the global Preferences, so they are 
dependent on the preexisting state and on each other - I propose to 
change that to memory based Preferences, which would be created from 
scratch for each test.

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

Any comments are welcome.

Thanks,
     Jan

From robert.field at oracle.com  Mon Mar 21 15:55:29 2016
From: robert.field at oracle.com (Robert Field)
Date: Mon, 21 Mar 2016 08:55:29 -0700
Subject: RFR 8152296: langtools/test/jdk/jshell/ToolReloadTest.java failing
	if there is no persisted history
In-Reply-To: <56EFF707.4060703@oracle.com>
References: <56EFF707.4060703@oracle.com>
Message-ID: <56F01971.5000300@oracle.com>

Thumbs up.

-Robert

On 03/21/16 06:28, Jan Lahoda wrote:
> Hi,
>
> Recently, I changed ConsoleIOContext to use UnsupportedTerminal while 
> running test, to avoid setting the terminal to the raw mode. Seems 
> that does not work well - some features, e.g. history, don't work 
> correctly with the UnsupportedTerminal. So, I propose to change that 
> to a dummy testing terminal.
>
> Also, the tests are currently using the global Preferences, so they 
> are dependent on the preexisting state and on each other - I propose 
> to change that to memory based Preferences, which would be created 
> from scratch for each test.
>
> Webrev:
> http://cr.openjdk.java.net/~jlahoda/8152296/webrev.00/
>
> Any comments are welcome.
>
> Thanks,
>     Jan


From jan.lahoda at oracle.com  Thu Mar 24 17:20:42 2016
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 24 Mar 2016 18:20:42 +0100
Subject: RFR 8151755: JShell: Generalization of output configuration
In-Reply-To: <56EF6BAC.6060503@oracle.com>
References: <56EF6BAC.6060503@oracle.com>
Message-ID: <56F421EA.20806@oracle.com>

Seems OK to me.

Jan

On 21.3.2016 04:34, Robert Field wrote:
> To cover the full prototypes of default configuration and any futures,
> the output configuration mechanism is moved to a more general and
> conceptually simpler design (despite a more sophisticated/complex
> implementation).
> All formatting is now done by defining fields conditionally on selectors
> which are universal and not order dependent.
> The /set format and /set field commands have been merged.
> The new '/help /set *' docs and the feedback set-up are now in a
> resource file as the first step towards internationalization.
> The /drop command and the message which is generated with an attempt to
> execute corralled code is now integrated into the output configuration
> mechanism..
> The format of resolution issue messages can now be properly structured
> depending on the number of unresolved/errors.
> In the process of developing tests for the new functionality, the
> ability to overflow the maximum size of history (stored in Preferences)
> was discovered and fixed.
>
> Bugs:
>      8151755 jshell tool: properly cover resolution issues in output
> configuration
>      https://bugs.openjdk.java.net/browse/JDK-8151755
>
>      8152246 jshell tool: history overflow
>      https://bugs.openjdk.java.net/browse/JDK-8152246
>
> Webrev:
>      http://cr.openjdk.java.net/~rfield/8151755.webrev/
>
> Sample configuration files -- I have updated proto.modes to the new
> format, and normal mode can be seen (resource file formatted) in
> l10n.properties:
>      http://cr.openjdk.java.net/~rfield/formats/proto2.modes
> http://cr.openjdk.java.net/~rfield/8151755.webrev/raw_files/new/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties
>
>
> Thanks,
> Robert
>

From robert.field at oracle.com  Tue Mar 29 06:23:37 2016
From: robert.field at oracle.com (Robert Field)
Date: Mon, 28 Mar 2016 23:23:37 -0700
Subject: RFR 8152925: JShell: enable corralling of any type declaration,
	including enum
Message-ID: <56FA1F69.2060005@oracle.com>

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

Webrev:
     http://cr.openjdk.java.net/~rfield/8152925.webrev/

Thanks,
Robert


From robert.field at oracle.com  Tue Mar 29 22:39:45 2016
From: robert.field at oracle.com (Robert Field)
Date: Tue, 29 Mar 2016 15:39:45 -0700
Subject: RFR (S) 8130450, 8139835: JShell: repeated source / Snippet.id() doc
Message-ID: <56FB0431.4040504@oracle.com>

Bugs:
     8130450: JShell: events are not generated for repeated source
     8139835: JShell API: Snippet.id() doc -- specify: no meaning, dynamic

Webrev:
     http://cr.openjdk.java.net/~rfield/8130450.webrev/

Thanks,
Robert


From robert.field at oracle.com  Thu Mar 31 00:33:14 2016
From: robert.field at oracle.com (Robert Field)
Date: Wed, 30 Mar 2016 17:33:14 -0700
Subject: JShell tool: default output format
Message-ID: <56FC704A.20407@oracle.com>

/set newmode verbose command normal

/set prompt verbose '\njshell> '   '   ...> '

/set format verbose pre '|  '
/set format verbose post '%n'
/set format verbose errorpre '|  Error: '
/set format verbose errorpost '%n'
/set format verbose action 'created' added-primary
/set format verbose action 'modified' modified-primary
/set format verbose action 'replaced' replaced-primary
/set format verbose action 'overwrote' overwrote-primary
/set format verbose action 'dropped' dropped-primary
/set format verbose action '  update created' added-update
/set format verbose action '  update modified' modified-update
/set format verbose action '  update replaced' replaced-update
/set format verbose action '  update overwrote' overwrote-update
/set format verbose action '  update dropped' dropped-update

/set format verbose result '{name} ==> {value}{post}'                                        added,modified,replaced

/set format verbose display ''

/set format verbose display '{pre}{action} {typeKind} {name}{resolve}{post}'                 class,interface,enum,annotation
/set format verbose display '{pre}{action} method {name}({type}){resolve}{post}'             method

/set format verbose display '{pre}{action} variable {name} : {type}{resolve}{post}'          vardecl
/set format verbose display '{result}{pre}{action} variable {name} : {type}{resolve}{post}'  varinit
/set format verbose display '{pre}{action} variable {name}, reset to null{post}'             replaced-vardecl,varinit-ok-update
/set format verbose display '{pre}{action} variable {name}{resolve}{post}'                   vardecl,varinit-notdefined
/set format verbose display '{pre}{action} variable {name}{post}'                            dropped-vardecl,varinit

/set format verbose display '{result}{pre}created scratch variable {name} : {type}{post}'    expression
/set format verbose display '{result}{pre}value of {name} : {type}{post}'                    varvalue 
/set format verbose display '{result}{pre}assigned to {name} : {type}{post}'                 assignment

/set format verbose display '{pre}attempted to use {typeKind} {name}{resolve}{post}'         used-class,interface,enum,annotation
/set format verbose display '{pre}attempted to call method {name}({type}){resolve}{post}'    used-method

/set newmode default command verbose

/set format default display ''                                                               added,modified,replaced,overwrote,dropped-update
/set format default display '{pre}{action} variable {name}, reset to null{post}'             replaced-vardecl,varinit-ok-update
/set format default display '{result}'                                                       added,modified,replaced-expression,varvalue,assignment,varinit-ok-primary

/set newmode concise quiet default

/set prompt concise 'jshell> '   '   ...> '

/set format concise display ''                                                               class,interface,enum,annotation,method,assignment,varinit,vardecl-ok

/set feedback default

From robert.field at oracle.com  Thu Mar 31 03:36:26 2016
From: robert.field at oracle.com (Robert Field)
Date: Wed, 30 Mar 2016 20:36:26 -0700
Subject: JShell tool: default output format
In-Reply-To: <56FC704A.20407@oracle.com>
References: <56FC704A.20407@oracle.com>
Message-ID: <56FC9B3A.8070309@oracle.com>

[Resend: with actual text]

The approach we decided for narrowing to a default format was to define 
three formats: a verbose format, a concise format (with only the 
critical information), and choose a default that is between the two.

This shows the feedback from each mode for representative input snippets:

         http://cr.openjdk.java.net/~rfield/FeedbackModes.html

This file can be /open'ed to add the three prototype modes (updated to 
the new general configuration mechanism):

         http://cr.openjdk.java.net/~rfield/formats/proto3.modes

Are there any shifts you would make?  Brian has stated he would have no 
output for B.  Of the differences between default and concise, B is the 
only case with useful information, so if that is the consensus then I 
would just want the default be the concise mode. What do others think???

I would really like some input from other than Brian and I.

Thanks,
Robert