New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

REPL Ctrl-C behaviour suggestion #6302

Open
scabug opened this Issue Aug 31, 2012 · 8 comments

Comments

Projects
None yet
2 participants
@scabug
Copy link

scabug commented Aug 31, 2012

From my scala-internals post (https://groups.google.com/d/msg/scala-internals/PqK6GkZhJK0/xjZw3wQ4wYEJ), verbatim:

Ideally, the function of Ctrl-C should depend on whether the REPL is waiting for user input, or running something in the foreground.

Waiting at a prompt, my preference would be:

  • If there's no text entered at the prompt, print a message like "(interrupt) type :quit or Ctrl-D to exit"
    • it's handy to trap Ctrl-C here, because people often press it repeatedly without intending to completely exit their current activity--mysql client, I'm looking at you
  • If there is text entered, discard it and bring up a new, empty prompt--this is what bash does.

With a foreground task running, ideally Ctrl-C should kill the task and return control to the REPL. I guess this implies running each command in a separate thread from the REPL itself, so it can be forcibly stopped—but of course, this doesn't necessarily imply starting a new thread for each command—we could just keep one of them around to run user code in—until it dies, only then we start a new one.

As for the mechanics of stopping the task, so long as we're baking pie in the sky...

while (!thread.isDead) {
  thread.youShouldExitNow() // presumably this is a custom thread class
  thread.interrupt()
  Thread.sleep(n) // say 2-5 seconds
  if (!thread.isDead) {
    val yn = prompt "The thread hasn't exited yet. Should we try to forcibly stop it?"
    if (yn == "y") {
      thread.stop()
    } 
  }
}

If anything is running in the background, may FSM have mercy on its soul. Out of scope. :)

If we felt like being clever, we could rewrite any line that has a looping construct at the root of its tree to be breakable. If it's a method call that loops, well, too bad.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Aug 31, 2012

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Aug 31, 2012

@acruise said:
Sigh, markup

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Sep 24, 2012

@gkossakowski said:
Downgrading this to major. We cannot put on hold 2.10.0 release because of this ticket.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Sep 6, 2014

Chip Senkbeil (senkwich) said:
I take it that this was never pursued. With JDK 8 (Oracle) officially disabling Thread.stop, the above would be trimmed down to just attempting an interrupt (hoping the code is interruptible). Cancelling a run doesn't seem to do anything to break out of long-running code.

Like the description says, you could rewrite looping constructs to be interruptible, but that doesn't do anything for external code being referenced inside the REPL.

Just seems like something that would be nice to have, but maybe it's too much to ask for.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Sep 6, 2014

@paulp said:
Nope, Thread.stop is still available. That refers to the "Thread.stop(Throwable)" version, but not the no argument form.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Sep 7, 2014

Chip Senkbeil (senkwich) said:
I thought the no argument form was just a wrapper for Thread.stop(Throwable) with an argument of ThreadDeath?

In JDK 7, this was what I found when browsing JDK 1.7:

public final void stop() {
    stop(new ThreadDeath());
}
@scabug

This comment has been minimized.

Copy link
Author

scabug commented Sep 7, 2014

@paulp said:
I verified Thread.stop works on 1.8.0_20 before I commented.

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Apr 19, 2015

Li Haoyi (lihaoyi) said:
This is fixed in the Ammonite REPL

[info] Running ammonite.repl.Repl
Loading Ammonite Repl...
@ while(true) ()

Interrupted!
@

@SethTisue SethTisue added this to the Backlog milestone Mar 3, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment