Close #3933 Improvements to the IntelliJ IDEA getting started guide #3954
Conversation
|
Please hold off on this for a few hours. I realized the explanation at the end has a small error, although the steps are right. sbt and dotc run in separate JVMs, but I wrote as if they are in the same one. |
expz
force-pushed
the
expz-contributing
branch
from
65bf8ae to
66af1eb
Compare
|
I updated the pull request 5 days ago, but it still has not run the checks. Do I need to do something to initiate them? |
|
Something went wrong with the CI, no idea what that is... But since your diff is only on a markdown file I guess this could be review / merged without running the test suite. |
|
The CLA is signed. I don't know what's up with Drone either. |
| @@ -20,40 +20,51 @@ its installed on your local machine). Otherwise, specify it by pressing *New*. | |||
|
|
|||
|  | |||
|
|
|||
| On the final window we must select which modules we can import. Here, we are presented with the full list of SBT projects | |||
| In some versions of IDEA, we must select which modules we can import. Here, we are presented with the full list of SBT projects | |||
There was a problem hiding this comment.
If you have that handy can you give a "v > XX.XX" format example of which versions?
There was a problem hiding this comment.
Good question, but is there any reason why we should currently support multiple IDEA versions? Supporting only one (in the docs) seems a reasonable tradeoff.
Maybe people who don't want to upgrade can install a new version next to the other.
Gotta setup IDEA (already run into bad bugs from ScalaIDE), so I can take a look at this PR.
There was a problem hiding this comment.
After some testing, I found that the change happened in version 2017.2 released in November 2017.
@Blaisorblade You have a good point in general, but I can think of two reasons to support multiple versions. First, the change was made a few months ago, so many people will need the first directions. Second, this page is unique in that its main purpose is to make on-boarding as frictionless as possible. That seems to call for setting aside the general principle of supporting only the newest version that applies elsewhere.
For an example where we do not keep the old directions, see below about invoking dotc in debug mode.
| To run the compiler you can do it either as an sbt command or via debugging the compiler. | ||
| For the first option you can fire up sbt from the `Terminal` window of IDEA or you can do it externally. | ||
| To run the compiler you can do it either as an sbt command or a shell script. | ||
| For the first option you can fire up sbt from the `Terminal` window of IDEA or you from an external terminal. |
There was a problem hiding this comment.
Although error messages are linkable and nice from my personal experience it's better to run it on an external terminal so personally I would give only one option here.
| If you are interested in debugging the compiler you can enable the necessary agent on the JVM. | ||
| This is done in two steps. For the first step you need to pass the | ||
| necessary flag to the running VM. For convenience, this is already in comments on the `Build.scala` file under the | ||
| If you are interested in debugging the compiler, you can use a remote debugging configuration. |
There was a problem hiding this comment.
Actually this step is automated now. We run dist/pack from sbt and then we pass the -debug flag when compiling with dotc. I think this is a great opportunity to write this small improvement down.
There was a problem hiding this comment.
Thanks, that way is more convenient.
I noticed it does not work from within sbt, although that is not important. It fails with a bad option '-debug' was ignored error. Also, perhaps it is by design, but neither the sbt dotc nor the script dotc list -debug in the options under the -help command.
There was a problem hiding this comment.
I just found that the dist/pack command was not necessary for debug to work. Do you have a guess as to what I am doing differently? I am using the most recent commit of the master branch.
There was a problem hiding this comment.
I noticed it does not work from within sbt
Indeed, debug does not work within sbt. It might be tricky to make it work though
I just found that the dist/pack command was not necessary for debug to work.
Yeh, dist/pack is not necessary. If you run bin/dotc, the script will run dist/pack for you if needed.
Also, perhaps it is by design, but neither the sbt dotc nor the script dotc list -debug in the options under the -help command.
I don't think we should list the debug option with the help command. This an internal option meant to debug the compiler.
expz
force-pushed
the
expz-contributing
branch
from
66af1eb to
e84683b
Compare
|
Hi @expz thanks! I'm new here and also setting up IDEA, so I'm also going through the guide! Do you mind if I also help? |
|
I'm watching Dmitry's intro to Dotty internals, and he suggests modifying That's not in our instructions. But memory usage hasn't decreased, especially if one adds more projects. @expz Your PR already improves docs, so I'm happy to move other changes in separate PRs (and ping you if you want), rather than iterate here. Any preference? |
|
Merging this as-is. Further improvements can go in later PRs. |
|
Sorry I did not see your questions in time! |
|
@expz Don't worry, better to have this in I guess — we can do further PRs, and I didn't want to hold this up too much. I'll tag you for the next PR. |
This pull request makes improvements to the IntelliJ IDEA getting started guide. The types of improvements are listed in the associated issue #3933.