Reimplement the "Require REPL Utilities" command

[cfehse]

What has Changed?

• Reimplemented the ""Require REPL Utilities" command
  1. Ensure that the namespace of the file exists in the REPL
  2. Evaluate the require form in the editor session
  3. If a REPL window for the editor filetype exists:
     a. Set the REPL window to the namespace of the file
     b. Evaluate the require form in the REPL window session

Fixes #451

My Calva PR Checklist

I have:

• Read How to Contribute.
• Made sure I am directing this pull request at the dev branch. (Or have specific reasons to target some other branch.)
• Made sure I am changed the default PR base branch, so that it is not master. (Sorry for the nagging.)
• Tested the VSIX built from the PR (well, if this is a PR that changes the source code.) You'll find the artifacts by clicking Show all checks in the CI section of the PR page, and then Details on the ci/circleci: build test. (For now you'll need to opt in to the CircleCI New Experience UI to see the Artifacts tab, because bug.)
  • Tested the particular change
  • Figured if the change might have some side effects and tested those as well.
  • Smoke tested the extension as such.
• Referenced the issue I am fixing/addressing in a commit message for the pull request.
  • If I am fixing the issue, I have used GitHub's fixes/closes syntax
  • If I am fixing just part of the issue, I have just referenced it w/o any of the "fixes” keywords.
• Updated the [Unreleased] entry in CHANGELOG.md, linking the issue(s) that the PR is addressing.

The Calva Team PR Checklist:

Before merging we (at least one of us) have:

• Made sure the PR is directed at the dev branch (unless reasons).
• Read the source changes.
• Given feedback and guidance on source changes, if needed. (Please consider noting extra nice stuff as well.)
• Tested the VSIX built from the PR (well, if this is a PR that changes the source code.)
  • Tested the particular change
  • Figured if the change might have some side effects and tested those as well.
  • Smoke tested the extension as such.
• If need be, had a chat within the team about particular changes.

Ping @PEZ, @kstehn, @cfehse

[PEZ]

If a REPL window for the editor filetype exists:
a. Set the REPL window to the namespace of the file
b. Evaluate the require form in the REPL window session

This shouldn't be necessary, right? Whatever is required in the namespace is shared. Or, are there any dynamic vars or something that gets set when loading the utilities?

[bpringe]

Thanks for making this change @cfehse!

If a REPL window for the editor filetype exists:
a. Set the REPL window to the namespace of the file
b. Evaluate the require form in the REPL window session

This shouldn't be necessary, right? Whatever is required in the namespace is shared. Or, are there any dynamic vars or something that gets set when loading the utilities?

Yeah I don't think that should be necessary either, because the editor and REPL window share a REPL session (or at least they should, from my understanding).

[cfehse]

@bpringe @PEZ

This shouldn't be necessary, right? Whatever is required in the namespace is shared. Or, are there any dynamic vars or something that gets set when loading the utilities?

Perhaps it shouldn't - and well sharing the same session: the REPL Window session is a clone of the editor session. Means this "sharing" the same session?

[PEZ]

No, they have different sessions alright. But if you (def foo :foo) in a namespace in your app, then it is ”attached” to that namespace, so any session will see it, because all sessions are for the same app. It would be pretty crazy otherwise, even if also pretty cool if each session had its own app.

What is not shared between sessions are dynamic variable bindings, like *ns*, *1, etcetera (and any dynamic variables you define yourself). At least not shared for Clojure sessions. ClojureScript sessions share everything, if I am correctly informed.

[cfehse]

@bpringe @PEZ

This shouldn't be necessary, right? Whatever is required in the namespace is shared. Or, are there any dynamic vars or something that gets set when loading the utilities?

In fact this is not necessary. I simplified the implementation which works for me in Brandon's test project but in a more real life project there seems to be a timing problem. It sometimes does not work the first time the command is executed.

[cfehse]

@bpringe @PEZ

And for some files, it doesn't work at all. gg

[bpringe]

in a more real life project there seems to be a timing problem

I thought it might be a timing issue as well when I first started looking into it, because the results (when it worked and did not work) seemed to be very random, which could indicate some kind of race condition / timing issue.

[cfehse]

@bpringe @PEZ

Now this works for me in all circumstances:

1. Create the namespace if it does not exist.
2. Evaluate the form (in-ns '<namespace) (we do this in the "normal" evaluation commands as well).
3. Evaluate the form to require the tools.

Please take a look at the changes.