-
Notifications
You must be signed in to change notification settings - Fork 159
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
fix: //SOURCES
now work in .jsh files too
#1221
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1221 +/- ##
============================================
- Coverage 59.00% 58.84% -0.17%
- Complexity 1050 1058 +8
============================================
Files 84 86 +2
Lines 5579 5666 +87
Branches 937 956 +19
============================================
+ Hits 3292 3334 +42
- Misses 1805 1839 +34
- Partials 482 493 +11
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
c85d3aa
to
0fd1f7a
Compare
@@ -194,6 +194,8 @@ String generateCommandLine(Source src, RunContext ctx) throws IOException { | |||
} | |||
} | |||
|
|||
optionalArgs.add("--execution=local"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is that flag trying to achieve?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
like, my jshell has no documentation for that flag afaics but it does not complain about it...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
jshell, by default, starts up a VM in the background to which it connects. But this means you can't read stdin from that VM because it's not connected to the terminal. This option tells jshell to not do that and just use the local process for the VM, which then inherits the stdin from jshell. It even makes jshell a bit faster it seems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm...interesting...what's the downside ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure, the information on this is very limited. I'm assuming it's more efficient when you call jshell a lot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm hesitant to do this specific change but lets merge in and we can revert if some usecase fails
should add a line or two about this behavior in the docs. The semantics is that they are treated as includes or? |
What more do you want to say about it that the current docs aren't already explaining? "The main script file defines all the dependencies and you add more source files into the application using The current explanation is a bit vague perhaps but I think it's best not to go into too much technical detail. The sources just get included into the application, no need to know exactly how. Right? |
Well; for java the ordering does not really matter as the classes just gets added to jar. In jshell ordering matters if they are treated as inclusion and executed in order. Basically if that is the semantics the description needs to be more specific than its vague now. |
Ok, added a bit of explanation |
Fixes #1220