REPL in maven via scala:console

On Friday July 24 2009, Kevin Wright wrote:
> I guess it's widely known by now that this simply doesn't work under
> MS windows. ...
>
> I've just run a very reveal trial that now suggests this is a problem
> with the REPL, and not with maven.
>
> ...
>
>
> So I'm now thinking that something in the REPL code itself is causing
> this problem.
>
> As a workaround, I propose that the interpreter be made available as
> an in-process component that has its own classpath and runs inside a
> non-delegating classloader, in the much same fashion as a webapp
> does.

Perhaps it's JLine you should be looking at?

Randall Schulz

You could well be right there, it looks like groovy also had a similar problem with jline:
http://jira.codehaus.org/browse/GROOVY-2584


On Fri, Jul 24, 2009 at 4:35 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Friday July 24 2009, Kevin Wright wrote:
> I guess it's widely known by now that this simply doesn't work under
> MS windows. ...
>
> I've just run a very reveal trial that now suggests this is a problem
> with the REPL, and not with maven.
>
> ...
>
>
> So I'm now thinking that something in the REPL code itself is causing
> this problem.
>
> As a workaround, I propose that the interpreter be made available as
> an in-process component that has its own classpath and runs inside a
> non-delegating classloader, in the much same fashion as a webapp
> does.

Perhaps it's JLine you should be looking at?


Randall Schulz

I'm thinking the embedded idea may work.  The only downside to this is that I believe paulp's REPL completion relies on jline... oh, and System.exit will kill the whole JVM, but I guess that's fine in this case.

I have a little bit of free time to work on this today.  We should come up with a plan for this.  It'd be nice to have the same dev environment in windows as I have in linux.  I'm on #scala right now if you have some time to chat.

Also, please at least CC the maven-and-scala group.   The maven-scala-plugin isn't quite considered a scala-interenal issue.  The deployment of scala into a maven repository is, all other maven-related issues should probably hit the maven-and-scala mailing list first though.

- Josh

On Fri, Jul 24, 2009 at 11:44 AM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

You could well be right there, it looks like groovy also had a similar problem with jline:
http://jira.codehaus.org/browse/GROOVY-2584


On Fri, Jul 24, 2009 at 4:35 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Friday July 24 2009, Kevin Wright wrote:
> I guess it's widely known by now that this simply doesn't work under
> MS windows. ...
>
> I've just run a very reveal trial that now suggests this is a problem
> with the REPL, and not with maven.
>
> ...
>
>
> So I'm now thinking that something in the REPL code itself is causing
> this problem.
>
> As a workaround, I propose that the interpreter be made available as
> an in-process component that has its own classpath and runs inside a
> non-delegating classloader, in the much same fashion as a webapp
> does.

Perhaps it's JLine you should be looking at?


Randall Schulz

I decided to hit the maven-internals list once I'd realized this to be a REPL issue and not a maven issue.  But you're right that the only sufferers seem to be maven users...
(unless anyone else has had problems with this in a different context?)

The surest way to get everything working, including completion, does look to be launching the interpreter in-process.

As a very quick alternative workaround, is to disable jline support when spawning the REPL.  Catch then is that we lose completion, but it still resolves the worst of the pain.

What we'll need then is way of re-introducing completion.  Somewhere on one of these forums I was having a discussion about breaking the Interpreter into a client/server architecture.  The client aspect could then be run in-process, interact with jline, and could communicate with the running interpreter via pipes or sockets or whatever other method is most appropriate.


On Fri, Jul 24, 2009 at 5:05 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

I'm thinking the embedded idea may work.  The only downside to this is that I believe paulp's REPL completion relies on jline... oh, and System.exit will kill the whole JVM, but I guess that's fine in this case.

I have a little bit of free time to work on this today.  We should come up with a plan for this.  It'd be nice to have the same dev environment in windows as I have in linux.  I'm on #scala right now if you have some time to chat.

Also, please at least CC the maven-and-scala group.   The maven-scala-plugin isn't quite considered a scala-interenal issue.  The deployment of scala into a maven repository is, all other maven-related issues should probably hit the maven-and-scala mailing list first though.

- Josh

On Fri, Jul 24, 2009 at 11:44 AM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

You could well be right there, it looks like groovy also had a similar problem with jline:
http://jira.codehaus.org/browse/GROOVY-2584


On Fri, Jul 24, 2009 at 4:35 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Friday July 24 2009, Kevin Wright wrote:
> I guess it's widely known by now that this simply doesn't work under
> MS windows. ...
>
> I've just run a very reveal trial that now suggests this is a problem
> with the REPL, and not with maven.
>
> ...
>
>
> So I'm now thinking that something in the REPL code itself is causing
> this problem.
>
> As a workaround, I propose that the interpreter be made available as
> an in-process component that has its own classpath and runs inside a
> non-delegating classloader, in the much same fashion as a webapp
> does.

Perhaps it's JLine you should be looking at?


Randall Schulz

I have forking working beautifully (with jline) on my Windows XP machine.  I've just commited to master.   Once I fix the nightly builds on scala-tools.org, you should be able to use the latest.

The real question here is what are we losing by being in the same VM?  In this case if you call "exit" we don't care as we want the maven process to die.  Things seem pretty snappy to me so far.   I also used a URLClassloader with no delegate, so we should be separated for class space.

- Josh

On Fri, Jul 24, 2009 at 12:41 PM, David Bernard <david.bernard.31@gmail.com> wrote:

Some Thought

* jline is require for 2.8 completion
* jline + scala:console works work linux user

=>
* we could enable/diseable jline by option, diseable by default for windows until there is a fix
* we could try to provide a run of REPL in the same jvm (use of classworld as classloader manager)
* when commons-exec-1.0.1 will releaded use it for forked process.


On Fri, Jul 24, 2009 at 18:19, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

I decided to hit the maven-internals list once I'd realized this to be a REPL issue and not a maven issue.  But you're right that the only sufferers seem to be maven users...
(unless anyone else has had problems with this in a different context?)

The surest way to get everything working, including completion, does look to be launching the interpreter in-process.

As a very quick alternative workaround, is to disable jline support when spawning the REPL.  Catch then is that we lose completion, but it still resolves the worst of the pain.

What we'll need then is way of re-introducing completion.  Somewhere on one of these forums I was having a discussion about breaking the Interpreter into a client/server architecture.  The client aspect could then be run in-process, interact with jline, and could communicate with the running interpreter via pipes or sockets or whatever other method is most appropriate.


On Fri, Jul 24, 2009 at 5:05 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

I'm thinking the embedded idea may work.  The only downside to this is that I believe paulp's REPL completion relies on jline... oh, and System.exit will kill the whole JVM, but I guess that's fine in this case.

I have a little bit of free time to work on this today.  We should come up with a plan for this.  It'd be nice to have the same dev environment in windows as I have in linux.  I'm on #scala right now if you have some time to chat.

Also, please at least CC the maven-and-scala group.   The maven-scala-plugin isn't quite considered a scala-interenal issue.  The deployment of scala into a maven repository is, all other maven-related issues should probably hit the maven-and-scala mailing list first though.

- Josh

On Fri, Jul 24, 2009 at 11:44 AM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

You could well be right there, it looks like groovy also had a similar problem with jline:
http://jira.codehaus.org/browse/GROOVY-2584


On Fri, Jul 24, 2009 at 4:35 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Friday July 24 2009, Kevin Wright wrote:
> I guess it's widely known by now that this simply doesn't work under
> MS windows. ...
>
> I've just run a very reveal trial that now suggests this is a problem
> with the REPL, and not with maven.
>
> ...
>
>
> So I'm now thinking that something in the REPL code itself is causing
> this problem.
>
> As a workaround, I propose that the interpreter be made available as
> an in-process component that has its own classpath and runs inside a
> non-delegating classloader, in the much same fashion as a webapp
> does.

Perhaps it's JLine you should be looking at?


Randall Schulz

Forking within the same process or spawning a separate process?If spawning, then do please tell us what the solution was!


As regards being in the same VM, I think that this denies us the opportunity to set a different java heap size.  This isn't too big an issue when it can be set via MAVEN_OPTS, but I can imagine more awkward scenarios.

On Fri, Jul 24, 2009 at 7:49 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

I have forking working beautifully (with jline) on my Windows XP machine.  I've just commited to master.   Once I fix the nightly builds on scala-tools.org, you should be able to use the latest.

The real question here is what are we losing by being in the same VM?  In this case if you call "exit" we don't care as we want the maven process to die.  Things seem pretty snappy to me so far.   I also used a URLClassloader with no delegate, so we should be separated for class space.

- Josh

On Fri, Jul 24, 2009 at 12:41 PM, David Bernard <david.bernard.31@gmail.com> wrote:

Some Thought

* jline is require for 2.8 completion
* jline + scala:console works work linux user

=>
* we could enable/diseable jline by option, diseable by default for windows until there is a fix
* we could try to provide a run of REPL in the same jvm (use of classworld as classloader manager)
* when commons-exec-1.0.1 will releaded use it for forked process.


On Fri, Jul 24, 2009 at 18:19, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

I decided to hit the maven-internals list once I'd realized this to be a REPL issue and not a maven issue.  But you're right that the only sufferers seem to be maven users...
(unless anyone else has had problems with this in a different context?)

The surest way to get everything working, including completion, does look to be launching the interpreter in-process.

As a very quick alternative workaround, is to disable jline support when spawning the REPL.  Catch then is that we lose completion, but it still resolves the worst of the pain.

What we'll need then is way of re-introducing completion.  Somewhere on one of these forums I was having a discussion about breaking the Interpreter into a client/server architecture.  The client aspect could then be run in-process, interact with jline, and could communicate with the running interpreter via pipes or sockets or whatever other method is most appropriate.


On Fri, Jul 24, 2009 at 5:05 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

I'm thinking the embedded idea may work.  The only downside to this is that I believe paulp's REPL completion relies on jline... oh, and System.exit will kill the whole JVM, but I guess that's fine in this case.

I have a little bit of free time to work on this today.  We should come up with a plan for this.  It'd be nice to have the same dev environment in windows as I have in linux.  I'm on #scala right now if you have some time to chat.

Also, please at least CC the maven-and-scala group.   The maven-scala-plugin isn't quite considered a scala-interenal issue.  The deployment of scala into a maven repository is, all other maven-related issues should probably hit the maven-and-scala mailing list first though.

- Josh

On Fri, Jul 24, 2009 at 11:44 AM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

You could well be right there, it looks like groovy also had a similar problem with jline:
http://jira.codehaus.org/browse/GROOVY-2584


On Fri, Jul 24, 2009 at 4:35 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Friday July 24 2009, Kevin Wright wrote:
> I guess it's widely known by now that this simply doesn't work under
> MS windows. ...
>
> I've just run a very reveal trial that now suggests this is a problem
> with the REPL, and not with maven.
>
> ...
>
>
> So I'm now thinking that something in the REPL code itself is causing
> this problem.
>
> As a workaround, I propose that the interpreter be made available as
> an in-process component that has its own classpath and runs inside a
> non-delegating classloader, in the much same fashion as a webapp
> does.

Perhaps it's JLine you should be looking at?


Randall Schulz

Sorry, the non-forking version (i.e. reflection).

On Fri, Jul 24, 2009 at 3:38 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

Forking within the same process or spawning a separate process?If spawning, then do please tell us what the solution was!


As regards being in the same VM, I think that this denies us the opportunity to set a different java heap size.  This isn't too big an issue when it can be set via MAVEN_OPTS, but I can imagine more awkward scenarios.

On Fri, Jul 24, 2009 at 7:49 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

I have forking working beautifully (with jline) on my Windows XP machine.  I've just commited to master.   Once I fix the nightly builds on scala-tools.org, you should be able to use the latest.

The real question here is what are we losing by being in the same VM?  In this case if you call "exit" we don't care as we want the maven process to die.  Things seem pretty snappy to me so far.   I also used a URLClassloader with no delegate, so we should be separated for class space.

- Josh

On Fri, Jul 24, 2009 at 12:41 PM, David Bernard <david.bernard.31@gmail.com> wrote:

Some Thought

* jline is require for 2.8 completion
* jline + scala:console works work linux user

=>
* we could enable/diseable jline by option, diseable by default for windows until there is a fix
* we could try to provide a run of REPL in the same jvm (use of classworld as classloader manager)
* when commons-exec-1.0.1 will releaded use it for forked process.


On Fri, Jul 24, 2009 at 18:19, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

I decided to hit the maven-internals list once I'd realized this to be a REPL issue and not a maven issue.  But you're right that the only sufferers seem to be maven users...
(unless anyone else has had problems with this in a different context?)

The surest way to get everything working, including completion, does look to be launching the interpreter in-process.

As a very quick alternative workaround, is to disable jline support when spawning the REPL.  Catch then is that we lose completion, but it still resolves the worst of the pain.

What we'll need then is way of re-introducing completion.  Somewhere on one of these forums I was having a discussion about breaking the Interpreter into a client/server architecture.  The client aspect could then be run in-process, interact with jline, and could communicate with the running interpreter via pipes or sockets or whatever other method is most appropriate.


On Fri, Jul 24, 2009 at 5:05 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

I'm thinking the embedded idea may work.  The only downside to this is that I believe paulp's REPL completion relies on jline... oh, and System.exit will kill the whole JVM, but I guess that's fine in this case.

I have a little bit of free time to work on this today.  We should come up with a plan for this.  It'd be nice to have the same dev environment in windows as I have in linux.  I'm on #scala right now if you have some time to chat.

Also, please at least CC the maven-and-scala group.   The maven-scala-plugin isn't quite considered a scala-interenal issue.  The deployment of scala into a maven repository is, all other maven-related issues should probably hit the maven-and-scala mailing list first though.

- Josh

On Fri, Jul 24, 2009 at 11:44 AM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

You could well be right there, it looks like groovy also had a similar problem with jline:
http://jira.codehaus.org/browse/GROOVY-2584


On Fri, Jul 24, 2009 at 4:35 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Friday July 24 2009, Kevin Wright wrote:
> I guess it's widely known by now that this simply doesn't work under
> MS windows. ...
>
> I've just run a very reveal trial that now suggests this is a problem
> with the REPL, and not with maven.
>
> ...
>
>
> So I'm now thinking that something in the REPL code itself is causing
> this problem.
>
> As a workaround, I propose that the interpreter be made available as
> an in-process component that has its own classpath and runs inside a
> non-delegating classloader, in the much same fashion as a webapp
> does.

Perhaps it's JLine you should be looking at?


Randall Schulz

Hey, you got it to work!Nothing to apologize for :)

On Fri, Jul 24, 2009 at 8:47 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Sorry, the non-forking version (i.e. reflection).

On Fri, Jul 24, 2009 at 3:38 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

Forking within the same process or spawning a separate process?If spawning, then do please tell us what the solution was!


As regards being in the same VM, I think that this denies us the opportunity to set a different java heap size.  This isn't too big an issue when it can be set via MAVEN_OPTS, but I can imagine more awkward scenarios.

On Fri, Jul 24, 2009 at 7:49 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

I have forking working beautifully (with jline) on my Windows XP machine.  I've just commited to master.   Once I fix the nightly builds on scala-tools.org, you should be able to use the latest.

The real question here is what are we losing by being in the same VM?  In this case if you call "exit" we don't care as we want the maven process to die.  Things seem pretty snappy to me so far.   I also used a URLClassloader with no delegate, so we should be separated for class space.

- Josh

On Fri, Jul 24, 2009 at 12:41 PM, David Bernard <david.bernard.31@gmail.com> wrote:

Some Thought

* jline is require for 2.8 completion
* jline + scala:console works work linux user

=>
* we could enable/diseable jline by option, diseable by default for windows until there is a fix
* we could try to provide a run of REPL in the same jvm (use of classworld as classloader manager)
* when commons-exec-1.0.1 will releaded use it for forked process.


On Fri, Jul 24, 2009 at 18:19, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

I decided to hit the maven-internals list once I'd realized this to be a REPL issue and not a maven issue.  But you're right that the only sufferers seem to be maven users...
(unless anyone else has had problems with this in a different context?)

The surest way to get everything working, including completion, does look to be launching the interpreter in-process.

As a very quick alternative workaround, is to disable jline support when spawning the REPL.  Catch then is that we lose completion, but it still resolves the worst of the pain.

What we'll need then is way of re-introducing completion.  Somewhere on one of these forums I was having a discussion about breaking the Interpreter into a client/server architecture.  The client aspect could then be run in-process, interact with jline, and could communicate with the running interpreter via pipes or sockets or whatever other method is most appropriate.


On Fri, Jul 24, 2009 at 5:05 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

I'm thinking the embedded idea may work.  The only downside to this is that I believe paulp's REPL completion relies on jline... oh, and System.exit will kill the whole JVM, but I guess that's fine in this case.

I have a little bit of free time to work on this today.  We should come up with a plan for this.  It'd be nice to have the same dev environment in windows as I have in linux.  I'm on #scala right now if you have some time to chat.

Also, please at least CC the maven-and-scala group.   The maven-scala-plugin isn't quite considered a scala-interenal issue.  The deployment of scala into a maven repository is, all other maven-related issues should probably hit the maven-and-scala mailing list first though.

- Josh

On Fri, Jul 24, 2009 at 11:44 AM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

You could well be right there, it looks like groovy also had a similar problem with jline:
http://jira.codehaus.org/browse/GROOVY-2584


On Fri, Jul 24, 2009 at 4:35 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Friday July 24 2009, Kevin Wright wrote:
> I guess it's widely known by now that this simply doesn't work under
> MS windows. ...
>
> I've just run a very reveal trial that now suggests this is a problem
> with the REPL, and not with maven.
>
> ...
>
>
> So I'm now thinking that something in the REPL code itself is causing
> this problem.
>
> As a workaround, I propose that the interpreter be made available as
> an in-process component that has its own classpath and runs inside a
> non-delegating classloader, in the much same fashion as a webapp
> does.

Perhaps it's JLine you should be looking at?


Randall Schulz