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

task created by fullRunInputTask doesn't capture sys.exit #831

Closed
eed3si9n opened this Issue Jul 28, 2013 · 8 comments

Comments

Projects
None yet
3 participants
@eed3si9n
Member

eed3si9n commented Jul 28, 2013

steps

  1. write a program that calls sys.exit when you pass in "--help" to argument. (scopt does this)
  2. in build.sbt, define fullRunInputTask(InputKey[Unit]("custom_run"), Runtime, "Main")
  3. from the shell, call custom_run --help.

problem

the program runs, and upon sys.exit sbt itself shuts down.

expectation

the program shuts down, and returns to sbt shell as run task does.

note

Mark wrote:

[trapExit] will fix the issue. However, the reason it isn't on by default is that it can only handle one run at a time (it is a SecurityManager hack to begin with). This issue will be to try to handle independent executions simultaneously.

@ceilican

This comment has been minimized.

Show comment
Hide comment
@ceilican

ceilican Jul 28, 2013

More generally, SBT seems to treat run tasks created with fullRunInputTask quite differently from the way it treats the default run task.

The issue described above is just one consequence.

Another consequence is this: if an exception is thrown within a program executed via run, SBT shows the full exception message. On the other hand, if the program is executed via a custom-run, SBT hides the exception message and requires the user to type last *:custom-run to see it.

I know nothing about the internals of SBT and the technical difficulties involved. But judging purely from a user perspective, it would be nice if SBT could provide a uniform treatment of default and custom run tasks.

ceilican commented Jul 28, 2013

More generally, SBT seems to treat run tasks created with fullRunInputTask quite differently from the way it treats the default run task.

The issue described above is just one consequence.

Another consequence is this: if an exception is thrown within a program executed via run, SBT shows the full exception message. On the other hand, if the program is executed via a custom-run, SBT hides the exception message and requires the user to type last *:custom-run to see it.

I know nothing about the internals of SBT and the technical difficulties involved. But judging purely from a user perspective, it would be nice if SBT could provide a uniform treatment of default and custom run tasks.

@ceilican

This comment has been minimized.

Show comment
Hide comment
@ceilican

ceilican Jul 28, 2013

Apparently, SBT executes default run tasks in a separate JVM (and thus is not terminated when a default run task calls sys.exit), but custom run tasks in the same JVM (and thus is terminated when the custom run task calls sys.exit).

ceilican commented Jul 28, 2013

Apparently, SBT executes default run tasks in a separate JVM (and thus is not terminated when a default run task calls sys.exit), but custom run tasks in the same JVM (and thus is terminated when the custom run task calls sys.exit).

@harrah

This comment has been minimized.

Show comment
Hide comment
@harrah

harrah Jul 29, 2013

Member

Both the default and custom run tasks are configured by fork, which is false by default. Saying fork in run will configure only the default run. The amount of a trace shown is configured by traceLevel, which is configured for run by default using traceLevel in run := 0. A custom run-like task can be configured similarly. fullRunInputTask does not control that. Rather, it is more like a property of the key.

Member

harrah commented Jul 29, 2013

Both the default and custom run tasks are configured by fork, which is false by default. Saying fork in run will configure only the default run. The amount of a trace shown is configured by traceLevel, which is configured for run by default using traceLevel in run := 0. A custom run-like task can be configured similarly. fullRunInputTask does not control that. Rather, it is more like a property of the key.

@ceilican

This comment has been minimized.

Show comment
Hide comment
@ceilican

ceilican Jul 30, 2013

Thanks for the explanation, Mark!

I thought fullRunInputTask would define a custom_run task that behaves exactly like run (w.r.t. fork, traceLevel, resilience to sys.exit calls, and so on...).

Since it doesn't, could you tell me the simplest way to define (in build.sbt) a custom_run task that behaves exactly like run?

ceilican commented Jul 30, 2013

Thanks for the explanation, Mark!

I thought fullRunInputTask would define a custom_run task that behaves exactly like run (w.r.t. fork, traceLevel, resilience to sys.exit calls, and so on...).

Since it doesn't, could you tell me the simplest way to define (in build.sbt) a custom_run task that behaves exactly like run?

@harrah

This comment has been minimized.

Show comment
Hide comment
@harrah

harrah Jul 31, 2013

Member

Configure the revelant settings in customRun:

trapExit in customRun := true

fork in customRun := true

traceLevel in customRun := 0

@eed3si9n I forgot about trapExit. That will fix the issue. However, the reason it isn't on by default is that it can only handle one run at a time (it is a SecurityManager hack to begin with). This issue will be to try to handle independent executions simultaneously.

Member

harrah commented Jul 31, 2013

Configure the revelant settings in customRun:

trapExit in customRun := true

fork in customRun := true

traceLevel in customRun := 0

@eed3si9n I forgot about trapExit. That will fix the issue. However, the reason it isn't on by default is that it can only handle one run at a time (it is a SecurityManager hack to begin with). This issue will be to try to handle independent executions simultaneously.

@ghost ghost assigned harrah Jul 31, 2013

@ceilican

This comment has been minimized.

Show comment
Hide comment
@ceilican

ceilican Jul 31, 2013

So now I have something like this in my "build.sbt":

fullRunInputTask(InputKey[Unit]("customRun"), Runtime, "Main")

trapExit in customRun := true

fork in customRun := true

traceLevel in customRun := 0

And SBT complains:

/Users/Bruno/Dropbox/Code/Skeptik/build.sbt:111: error: not found: value customRun
trapExit in customRun := true
            ^
/Users/Bruno/Dropbox/Code/Skeptik/build.sbt:111: error: reassignment to val
trapExit in customRun := true
                     ^

I understand why this happens. My question is: is there a way to achieve what I want having only a "build.sbt" file? Or will I need to write a "Build.scala" file, in order to use the full power of the Scala language (even if in this case I just need to know the key object that was created by fullRunInputTask)?

ceilican commented Jul 31, 2013

So now I have something like this in my "build.sbt":

fullRunInputTask(InputKey[Unit]("customRun"), Runtime, "Main")

trapExit in customRun := true

fork in customRun := true

traceLevel in customRun := 0

And SBT complains:

/Users/Bruno/Dropbox/Code/Skeptik/build.sbt:111: error: not found: value customRun
trapExit in customRun := true
            ^
/Users/Bruno/Dropbox/Code/Skeptik/build.sbt:111: error: reassignment to val
trapExit in customRun := true
                     ^

I understand why this happens. My question is: is there a way to achieve what I want having only a "build.sbt" file? Or will I need to write a "Build.scala" file, in order to use the full power of the Scala language (even if in this case I just need to know the key object that was created by fullRunInputTask)?

@harrah

This comment has been minimized.

Show comment
Hide comment
@harrah

harrah Jul 31, 2013

Member

0.13 allows vals in the .sbt file. Before that, you can use a block and return a Seq[Setting[_]] in the expression:

{
  val customRun = InputKey[Unit]("customRun")
  Seq(
    trapExit in customRun := true,
    ...
  )
}

(EDIT: forgot the {} the first time)

Member

harrah commented Jul 31, 2013

0.13 allows vals in the .sbt file. Before that, you can use a block and return a Seq[Setting[_]] in the expression:

{
  val customRun = InputKey[Unit]("customRun")
  Seq(
    trapExit in customRun := true,
    ...
  )
}

(EDIT: forgot the {} the first time)

@ceilican

This comment has been minimized.

Show comment
Hide comment
@ceilican

ceilican commented Aug 1, 2013

Thanks!

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