These are chat archives for ensime/ensime-atom

7th
Dec 2015
Jeff Wilde
@jeffwilde
Dec 07 2015 17:03
@hedefalk, I dropped your feature branch into my atom installation to try it out with my currently working project, but I’m getting an error right off the bat while it’s trying to update the ensime server:
Uncaught ReferenceError: path is not defined
~/.atom/packages/Ensime/lib/ensime-server-update.coffee:52
Hide Stack Trace
ReferenceError: path is not defined
    at updateEnsimeServer (~/.atom/packages/Ensime/lib/ensime-server-update.coffee:52:29)
    at ~/.atom/packages/Ensime/lib/ensime-startup.coffee:96:7
    at withSbt (~/.atom/packages/Ensime/lib/utils.coffee:58:5)
    at startEnsimeServer (~/.atom/packages/Ensime/lib/ensime-startup.coffee:95:5)
    ...
my lack of experience with atom’s coffeescript env is definitely showing here, but I’m not seeing where that path var would even be defined for use on this line:
 tempdir =  packageDir() + path.sep + “ensime_update_”
Viktor Hedefalk
@hedefalk
Dec 07 2015 17:06
Have you run "npm install” in the folder?
Jeff Wilde
@jeffwilde
Dec 07 2015 17:08
yep. I believe it was successful at getting all the deps.
Viktor Hedefalk
@hedefalk
Dec 07 2015 17:08
Oh!
Should be a path = require ’path’ in the top there. Thanks!
fs = require('fs’) too :)
I guess I extracted that AFTER I regression-tested server update.
I just pushed an update.
Jeff Wilde
@jeffwilde
Dec 07 2015 17:12
k, I’ll check that out.
Viktor Hedefalk
@hedefalk
Dec 07 2015 17:12
I had missed those two imports.
Let me know if there are more issues!
I’m really lacking unit tests for this :’(
Jeff Wilde
@jeffwilde
Dec 07 2015 17:13
haha
okay, updating is working now!
Viktor Hedefalk
@hedefalk
Dec 07 2015 17:14
Cool!
This is why I want a statically typed language like Scala :)
Jeff Wilde
@jeffwilde
Dec 07 2015 17:15
that’s the whole point of static typing! :)
I’ll let you know how it drives…
Viktor Hedefalk
@hedefalk
Dec 07 2015 17:15
Just gotta fixup my editor in a dynamic language first so I can write in Scala later
Mother of all yakk shaving?
Or maybe TeX was the mother of all yakk shaving…
Jeff Wilde
@jeffwilde
Dec 07 2015 17:22
I think I'd call that bootstrapping!
Rory Graves
@rorygraves
Dec 07 2015 17:35
Clearly the answer is to update Scala-is to Scala-coffee and write it all in Scala!
Jeff Wilde
@jeffwilde
Dec 07 2015 18:11
@hedefalk, I’ve got a bit of strange behaviour i’m seeing: it doesn’t seem the ensime server update process actually finished, the tab is still open and the “Ensime server update:” text is still in the bottom bar, even though the acual sbt job is done and was cleasrly successful:
[info] Done updating.
[success] Total time: 70 s, completed Dec 7, 2015 12:14:46 PM
[success] Total time: 0 s, completed Dec 7, 2015 12:14:46 PM
I can separately invoke the Ensime: Start command, though, and it appears successful, “Ensime: Full type check finished!” in the bottom bar… but there’s no output shown from the ensime server and no code navigation or underlining is working.
quitting atom and restarting allows the Ensime: Start command to actaully give useful output.
Viktor Hedefalk
@hedefalk
Dec 07 2015 18:18
@jeffwilde ok, cool. I’ll debug this as soon as I get a minute. But you can use now after restart, no?
Jeff Wilde
@jeffwilde
Dec 07 2015 18:19
yeah, it’s work like it was with the release version now (except with the UI addition of the .ensime file selector).
I haven’t tried starting two ensime servers in the same project yet.
Viktor Hedefalk
@hedefalk
Dec 07 2015 18:20
"Ensime server update:” is just the name of the pane. Maybe a bit confusing. When it’s done it’s done. I just don’t kill the pane after sigterm, maybe I should? Or maybe later we’ll just have it in a separate tab in the Ensime bottom pane?
Cool! But then I know there are some issues when doing cold start. I need to try all the scenarios with no cache and and kill off ivy and all of that I guess.
Jeff Wilde
@jeffwilde
Dec 07 2015 18:21
ah, ok.
Viktor Hedefalk
@hedefalk
Dec 07 2015 18:22
I want to .ensime file selector to show status. Like a green ball for started client and a red ball for server or something like that.
And then have the same for stopping
And updating server and all that.
Jeff Wilde
@jeffwilde
Dec 07 2015 18:23
another thing i’ve noticed, it doesn’t appear to work when I try to Ensime: Stop. The server stops (no more highlighting or code nav) but the Ensime pane sticks around and trying to start the server again has no effect.
Mind you, I don’t think I ever actually tried that with the production release.
Viktor Hedefalk
@hedefalk
Dec 07 2015 18:23
Ok.
Jeff Wilde
@jeffwilde
Dec 07 2015 18:24
I like that idea; keeping track of already-launched servers.
Viktor Hedefalk
@hedefalk
Dec 07 2015 18:24
There are some issues here with regards to what to show. Before there was ”stopped state commands” which basically was ”start/update server” and ”started state commands” which was all the rest. That is all broken now when there is not a global stopped or started state.
I have an idea on how to fix this ”a little bit"
But basically there will be corner cases where the commande will be there but just show an error message when no client is attached to the current working file or so…
Jeff Wilde
@jeffwilde
Dec 07 2015 18:30
Hmm. The full credit answer would appear to be an "all stopped" state and an "at least one started" state for what commands to show, but I'm not sure how that plays out internally for atom..
Does that mean that almost all commands will require a "choose which server to send to " step?
(similar to choosing which .ensime file to start)
Oh never mind, I missed your reference to "current working file"
Viktor Hedefalk
@hedefalk
Dec 07 2015 19:31
Yeah, problem with commands is that they are registered in a way that they might need to be there always and then we have to resolve which instance it is for on the fly. But I have ONE idea that it might be possible to add a custom html attribute on panes and then use a selector on this when attaching the commands.