These are chat archives for ensime/ensime-atom

5th
Mar 2016
Magnus Andersson
@magnusart
Mar 05 2016 11:25
@hedefalk Been busy last week but I tried the new Atom plugin and cleaned out all caches again and now ensime runs for akka-persistence-cassandra. Thanks for trying it out earlier so I knew it wasn’t something in the project!
Viktor Hedefalk
@hedefalk
Mar 05 2016 11:33
@magnusart Cool, great it works!
Magnus Andersson
@magnusart
Mar 05 2016 11:35
Going away for bit but I'll poke around a bit tonight to see if I understand the atom plugin works.
Richard Dallaway
@d6y
Mar 05 2016 12:16
@hedefalk types! I’m off to learn purescript….
Viktor Hedefalk
@hedefalk
Mar 05 2016 12:37
@d6y Yey! I'm feeling the peer pressure. I'll do a quick rewrite in typescript I think, but then we'll redo in purescript.
Magnus Andersson
@magnusart
Mar 05 2016 13:03
I’m confused about these javascript overlays, it just seems very fragmented to me. In a project they had started using Coffee Script a while back but it just caused confusion when fixing bugs since javascript is a dynamic language. We went back to javascript.
At the time sourcemaps were not quite working yet.
Viktor Hedefalk
@hedefalk
Mar 05 2016 13:06
Well, I'd say it's a matter of setup pain to fix stuff like building and sourcemaps, but today you can very much have zero penalty polyglotism in a node environment.
I personally can't stand writing/reading javascript as little as I want to code in Java.
Coffeescript can definitely lure you into feeling safe when you shouldn't, but I still think it's a hell lot better than Javascript. But I think I'm gonna rewrite the ensime-node-client lib now in Typescript so I can use it better from ensime-vscode. It's always good to learn new languages too.
Magnus Andersson
@magnusart
Mar 05 2016 13:10
Yes I do agree it is painful. But not as painful as it was when translating from javascript to coffeescript in your head.
Viktor Hedefalk
@hedefalk
Mar 05 2016 13:12
s/node envorinment/js environment since you should do your web with webpack or browserify too which have loaders/plugins for most stuff.
Why was that hard? Just remove function and return and semicolons :)
Jari Pennanen
@Ciantic
Mar 05 2016 14:40
@hedefalk I'm now on this point: https://gist.github.com/Ciantic/e61f95a01cc918827d09 - I just got the gen-ensime working from node
from tests file you can see which parts are working
next I'll do some tests for ensime server API
my intention is to be able to call gen ensime from VS Code directly, without installing it
(of course this thing installs it but anyway)
I was considering writing this in Scala JS though, there isn't that many Node calls so it wouldn't be too difficult, but interacting with Visual Studio API it's better to use TypeScript
Jari Pennanen
@Ciantic
Mar 05 2016 15:04
ugly part of TS is that it doesn't have granular targeting (or node targetting) so right now I use async await, but if I use default parameter values it won't work with Node
Magnus Andersson
@magnusart
Mar 05 2016 17:38
@hedefalk well maybe my memory have muddled things. We had backbone as well and how the systen was implemented with that contributed considerably. Still, not having the same source in your editor as in your browser when you get an exception on line 1005 causes a mental stumbling block. But with source maps things might be brighter.
Magnus Andersson
@magnusart
Mar 05 2016 18:59
With the new debugger rewrite by @chipsenkbeil in ensime-server should the expectation be that the Jerky protocol will change? Trying to grasp at something to start hacking.
Chip Senkbeil
@chipsenkbeil
Mar 05 2016 20:01
I don't intend to alter the protocol, just replace the implementation. Haven't seen anything that would result otherwise. If something does change, it will be small and well documented. New features will add to the protocol when they happen, of course.
Rory Graves
@rorygraves
Mar 05 2016 20:08
Yep, sounds like a good plan. @magnusart I would say however, if you find something querky in the protocol we should try and address it (and improve it for the long term).
Magnus Andersson
@magnusart
Mar 05 2016 21:06
I do have some ground to cover first. Just want to see if I can hack something together.
I just noticed something, the ensime server does not exit when atom exits. Is this by design?
Rory Graves
@rorygraves
Mar 05 2016 21:11
No that doesn't sounds right - check out -Dexplode-on-disconnect - not sure if atom uses it.
Viktor Hedefalk
@hedefalk
Mar 05 2016 21:12
@magnusart Nah, not really. I think it did before, but maybe I unfixed it. Should be a one-liner in deactivate() though. I typically have my server running between reloads.
Ah, yeah -Dexplode-on-disconnect would be better then so it works even if Atom dies badly. But it should be under option since you might want to reload Atom without restarting ensime-server.
Magnus Andersson
@magnusart
Mar 05 2016 21:13
There is a setting to run the server detached, but I don’t have it enabled.
In the plugin settings
Rory Graves
@rorygraves
Mar 05 2016 21:15
Restart does not take long after first load, because the cache has been built
Viktor Hedefalk
@hedefalk
Mar 05 2016 21:19
@Ciantic Awesome! I did some readup on Typescript yesterday and I think I'm gonna rewrite ensime-node in Typescript for easier use in vscode. Best way forward - I'll do that just 1-1 as quickly as I can, and then we can work together? I think I need to take small steps since I want ensime-atom to use it too so need to work with ensime-node, ensime-atom and ensime-vscode in unison.
@rorygraves Seconds lost are seconds lost :)
Rory Graves
@rorygraves
Mar 05 2016 21:22
I don't spend my entire time bouncing ;)
YMMV
Viktor Hedefalk
@hedefalk
Mar 05 2016 21:29

@magnusart Yeah, the setting for running detached was used for this before but I think I removed it. Basically there are a few different things:

1) Run as detached process - https://nodejs.org/api/child_process.html#child_process_options_detached. Seems it probably keeps running on *nix anyways, but probably dies on Win when Atom dies.
2) Should we kill ensime-server on unload of Atom - I did before with that same setting I think.
3) Something else, I forgot.

Anyways, I think there's probably some thinking this through to do. Feel free to contribute.

Magnus Andersson
@magnusart
Mar 05 2016 21:36
As a user expected ensime to shut down when Atom is closed since I started it from Atom. I expect the ensime-server lifecycle to be managed. Leaving processes running without my knowledge is not obvious. At the very least it should be documented clearly otherwise that the user is expected to shutdown the ensime server themselves.
Other than that I think the approach with a setting that spawns ensime server with or without -Dexplode-on-disconnect would be fine.
Looking at it now… It seems the process should be killed actually. At least from deactivate(). Maybe deactivate isn't called when quitting…
Magnus Andersson
@magnusart
Mar 05 2016 22:11
I’m digging around as well (but I’m unfamiliar with the code).
Magnus Andersson
@magnusart
Mar 05 2016 22:14
Right. Let’s see what the debugger says
I guess something got lost on the way somehow.
Cool! Please let me know if you find the bug and please PR. I'm a bit busy tonight so can't dig myself…
But clicking merge PR I can do. hint, hint, hint
Magnus Andersson
@magnusart
Mar 05 2016 22:18
TypeError: _.foreach is not a function at InstanceManager.module.exports.InstanceManager.destroyAll
Magnus Andersson
@magnusart
Mar 05 2016 22:23
Perhaps it should be _.forEach with a capital E instead?
Magnus Andersson
@magnusart
Mar 05 2016 22:31
@hedefalk that was it. Hacked the installed package and with the typo fixed it now works.
I’ll fork the ensime-node project and do a PR. It will be the smallest PR in the project history. ;)
Viktor Hedefalk
@hedefalk
Mar 05 2016 22:32
Nice!
Awesome find!
Small changes that fix a lot are the best!
Magnus Andersson
@magnusart
Mar 05 2016 22:33
Was easy to find with the debugger. I’m still clueless of the code base.
:D
Viktor Hedefalk
@hedefalk
Mar 05 2016 22:33
I really need to rewrite in a typed language or be more serious with test coverage…
Magnus Andersson
@magnusart
Mar 05 2016 22:34
But it looked like that had been there for a while. Kinda tricky to see the errors when it happens during shutown
Viktor Hedefalk
@hedefalk
Mar 05 2016 22:34
It's a bit of a mess. Quick and dirty. I'm really going to try to tidy up now before doing much in feature land.
Magnus Andersson
@magnusart
Mar 05 2016 22:39
ensime-node was that repo only under your user?
Here is the PR: hedefalk/ensime-node#1
Some whitespace snuck in there. Not sure why, I suppose Atom did something.
Viktor Hedefalk
@hedefalk
Mar 05 2016 22:45
Actually, if you can PR against https://github.com/ensime/ensime-node that would be better.
Man, is that crap. I don't know how to set a new upstream repo in github. So I was gonna kill hedefalk/ensime-node and fork ensime/ensime-node again to have that upstream thing.
Magnus Andersson
@magnusart
Mar 05 2016 22:46
ok
Viktor Hedefalk
@hedefalk
Mar 05 2016 22:46
I just transferred from hedefalk to ensime but then there's no apparant simple way to get the relationship correct.
Magnus Andersson
@magnusart
Mar 05 2016 22:47
I looked at yours and saw that it didn’t have an upstream so I figured it was the only one. I’ll nuke my ensile-node and do a fork off the proper repo.
Or if you want you can just do the commit yourself. It’s a capital E. I don’t need any credit for that. :)
Viktor Hedefalk
@hedefalk
Mar 05 2016 22:53
You SHOULD have the credit!
But I understand if you don't wanna go through cloning again. I might be able to fix it with some git trickery. Tomorrow!
Magnus Andersson
@magnusart
Mar 05 2016 22:54
OK ensime/ensime-node#1
@hedefalk done. Didn’t take much time in the end.
Viktor Hedefalk
@hedefalk
Mar 05 2016 22:54
Awesome! Merged!
Magnus Andersson
@magnusart
Mar 05 2016 22:55
Nice.
Matthew de Detrich
@mdedetrich
Mar 05 2016 23:06
@hedefalk Regarding my issue, I am trying to see if its an issue with SBT startup options
Do you have any idea where they are located?
Viktor Hedefalk
@hedefalk
Mar 05 2016 23:13
@mdedetrich Don't know what you mean?
I actually removed SBT entirely from ensime-atom just the other day… Or do you mean options from build definition that goes into .ensime?
Matthew de Detrich
@mdedetrich
Mar 05 2016 23:14
@hedefalk Does ensime or ensime-server use the sbt launcher in any way?
Viktor Hedefalk
@hedefalk
Mar 05 2016 23:14
No.
Matthew de Detrich
@mdedetrich
Mar 05 2016 23:15
Because there are global launch options for SBT which may effect it
Viktor Hedefalk
@hedefalk
Mar 05 2016 23:15
ensime-emacs has some sbt integration.
Matthew de Detrich
@mdedetrich
Mar 05 2016 23:15
Hmmm
Viktor Hedefalk
@hedefalk
Mar 05 2016 23:15
Stuff from your sbt build will go into .ensime of you do sbt gen-ensime though. But ensime-server is started with java -cp from ensime-atom.
Matthew de Detrich
@mdedetrich
Mar 05 2016 23:16
@hedefalk So you are sure that shouldn’t be effecting it?
Viktor Hedefalk
@hedefalk
Mar 05 2016 23:16
I'm not entirely sure what you are even asking so I'm not sure about anything :)
Global launch options?
As long as it doesn't stick in .ensime it can't affect ensime-atom.
Matthew de Detrich
@mdedetrich
Mar 05 2016 23:19
What I thought could cause a problem is having sbt launch options (such as -XMX).SBT used to allow you to give it launch options, I stll have a config lying around somewhere however I have no idea where it is
@hedefalk Is there anything outside of ensime that could effect my issue?
Viktor Hedefalk
@hedefalk
Mar 05 2016 23:21
Wait, your issue was before when you actually DID use sbt to generate ensime-server classpath, right? It went away now? Or are we talking about the same thing?
You had reds everywhere because compiler crash?
This one ensime/ensime-atom#177
It was a compiler crash right?
Matthew de Detrich
@mdedetrich
Mar 05 2016 23:23
@hedefalk I have always had this issue, it always happens when I save a source file. @rorygraves said it was probably a compiler crash (or that that ensime-server wasn’t handling a certain compiler output and was crashing because of it, because it didn’t cause an actual crash)
Yeah
I was thinking whether it is a memory issue
Viktor Hedefalk
@hedefalk
Mar 05 2016 23:24
Ah, you still have it and only in ensime-atom, not ensime-emacs?
Matthew de Detrich
@mdedetrich
Mar 05 2016 23:25
Actually @rorygraves , you said you would have a look at it, did you have any time do so
It was ensime-sublime that worked fine, I don’t have ensime emacs
Viktor Hedefalk
@hedefalk
Mar 05 2016 23:25
Ok.
Actually, it's obviously an upstream bug, but I'll leave it in ensime-atom just because I think it can be useful to know what provokes it. You can reliably recreate the issue, right?
Matthew de Detrich
@mdedetrich
Mar 05 2016 23:26
100% reliably, like I have been checking with every ensime-atom/ensime-server release
and fresh clean projects
Viktor Hedefalk
@hedefalk
Mar 05 2016 23:27
Could you then try to minimize the behaviour needed and paste the entire client server communication logs? Then we can crash ensime-server without using atom in a test file.
Matthew de Detrich
@mdedetrich
Mar 05 2016 23:27
So it has nothing to do with the actual project (it happens on any Scala project as far as I can see)
Viktor Hedefalk
@hedefalk
Mar 05 2016 23:27
Sorry, I really gotta hit the sack though.
Matthew de Detrich
@mdedetrich
Mar 05 2016 23:27
@hedefalk All good, I will do it on a trivial main output project
And post the entire communication log