These are chat archives for ensime/ensime-atom

26th
Feb 2016
Viktor Hedefalk
@hedefalk
Feb 26 2016 05:38
@booschie Not exactly sure what you're asking for.
  • There'a a command "Window:Run Package Specs" which run all jasmine specs of the Atom plugin you have in your open in your Window.
  • The ensime log - I guess your asking for the ensime-atom log? That is shown if you open up chrome developer tools. "Window: Toggle devtools"
"the settings property seems not to be set, even though the ensime plugin works. Any help?" The sbt is only needed to write out a classpath file for your current scala/ensime-version. This will be put in ~/.atom/packages/Ensime/classpath*. When this exists and is newer than your ensime-atom version (stats package.json), startup doesn't need sbt. It uses this classpath file and runs a java cmd with it to start the server. The server is not run by sbt, only dowloaded by it. If you wipe that file, sbt will be run on each startup do download server.
By the way, there's a commit in master currently that adds an option "User Coursier to bootstrap server" that entirely removes the dependency to SBT. Please try it!
Viktor Hedefalk
@hedefalk
Feb 26 2016 05:44
"The fix would automatically read SBT_HOME environment variable and set sbt exec path accordingly". The problem with this is that it will probsbly only work on GNU/Linux. If you open Atom as an app, you will most certainly not have any SBT_HOME set even though you're used to having in terminal.
Sorry, the Coursier thing is in a PR, not in master.
Viktor Hedefalk
@hedefalk
Feb 26 2016 08:02
Released 0.36.0 with cooler type hovers and some small fixes: https://github.com/ensime/ensime-atom/releases/tag/v0.36.0
Richard Dallaway
@d6y
Feb 26 2016 08:16
woohoo!
Viktor Hedefalk
@hedefalk
Feb 26 2016 08:19
@d6y And look ma! I've learnt from the best and managed to write release notes too!
Richard Dallaway
@d6y
Feb 26 2016 08:19
:-)
Ensime 2016-02-26 08-20-04.png
I’m getting Atom complaining about an outdent in ensime.coffee
Oh wait… maybe my fork is broken
Let me find out what I’m actually running :)
Viktor Hedefalk
@hedefalk
Feb 26 2016 08:39
Oooh, I have it too…
Richard Dallaway
@d6y
Feb 26 2016 08:39
Here you go: ensime/ensime-atom#190
I think… in my comprehensive testing of… yup, it starts now… ship it.
and https://github.com/ensime/ensime-atom/pull/190/files?w=0 with ?w=0 shows you the diff without my stupid auto whitespace fixes
Viktor Hedefalk
@hedefalk
Feb 26 2016 08:41
Oh, snap, this is embarrassing… Parens error.
Richard Dallaway
@d6y
Feb 26 2016 08:41
(which I’m disabling as a plugin right now)
We are doomed to make them forever. My turn next. Until we use our copious free time to re-write to purescript scalajs or elm or whatever!
Viktor Hedefalk
@hedefalk
Feb 26 2016 08:45
I found one more error. ensime/ensime-atom@f7b5dc9

Made the edit directly in github :)

This is truly embarrassing. What's most embarrassing is that no tests found this.

Richard Dallaway
@d6y
Feb 26 2016 08:45
eeeeeeee
:-)
Viktor Hedefalk
@hedefalk
Feb 26 2016 08:46
v0.36.1 published! @all don't use 0.36.0. It was booorked.
I just added appveyor for win build and we have travis too. I'm thinking I should add some smoke integration tests.
Richard Dallaway
@d6y
Feb 26 2016 08:47
I didn’t know you could make coursier use .ivy2 cache folder. That’s v. nice. ( I’ve been using it as an SBT plugin, and building up a whole new ~/.coursier/cache folder)
code 2016-02-26 08-48-23.png
Nice ^^ thank you
Viktor Hedefalk
@hedefalk
Feb 26 2016 08:49
I just copied from @fommil. I think we use ~/.coursier/cache?
Richard Dallaway
@d6y
Feb 26 2016 08:49
No no - I have a lot of disk space invested in ~/.ivy … it makes sense
Richard Dallaway
@d6y
Feb 26 2016 08:49
I don’t need two copies of the internet ;-)
Viktor Hedefalk
@hedefalk
Feb 26 2016 08:50
Ah, you say we can, but we're not, right? PR please!
Richard Dallaway
@d6y
Feb 26 2016 08:50
Oh right… well, it all seems to work for me, using coursier
I’ll have a look at those flags. But suspect they are just fine!
Viktor Hedefalk
@hedefalk
Feb 26 2016 08:51
Wait, ensime-atom is not using .ivy2. But if you see that in log, that must have been because you already had classpath*-file made from sbt.
Stop server, kill your classpath* files and retry with Coursier and you will see classpath from ~/.coursier.
But if it is possible to reuse .ivy, that'd be cool.
Ghost
@ghost~540393fe163965c9bc2018ce
Feb 26 2016 08:54
I didn't know it reused the cache either, i thought it copied. Actually, good point there, we need to delete the ivy and coursier caches before running the incremental updater.
Viktor Hedefalk
@hedefalk
Feb 26 2016 08:56
I'm not entirely following here, but that's not the first time so don't mind… :)
I kindof know for a fact that the Coursier thing is broken on Win (becuase cli curl) and therefore I left it as not default. I'm gonna try to provoke the error with a integration test on appveyor and then fix it. When stuff is working, I'm gonna remove sbt entirely from ensime-atom. yey.
Richard Dallaway
@d6y
Feb 26 2016 08:57
I’m not sure anymore. I’ve been using coursier as an SBT plugin only. But there’s this...
Both command belows can be given repositories with the -r or --repository option, like

-r central
-r https://oss.sonatype.org/content/repositories/snapshots
-r "ivy:https://repo.typesafe.com/typesafe/ivy-releases/[organisation]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]"

central and ivy2local correspond to Maven Central and ~/.ivy2/local. These are used by default unless the --no-default option is specified.
…which I took to mean it could read existing ivy cached files. But I’m no longer sure.
Viktor Hedefalk
@hedefalk
Feb 26 2016 08:59
I guess it uses it's own cache anyways? But disk is just disk. If we can add our own ./ivy as an upstream repo just like .m2, that'd be great, right?
Ah, now I read the above.
Well, I certainly have no idea :)
Richard Dallaway
@d6y
Feb 26 2016 09:06
So I think that makes both of us. It feels pretty fast at the moment. I suggest we leave it alone until we get a better idea for how coursier works, and how we might tweek it.
@hedefalk I’m going to copy and paste your release notes into 0.36.1...
Viktor Hedefalk
@hedefalk
Feb 26 2016 09:09

Yup, sounds reasonable! I left the -m update-changingin there, but I'm waiting on this:

alexarchambault/coursier#154

For me, without "-update-changing", I was down to 2 sec which makes me think we could skip the entire classpath file thing and just handle our classpath in-mem.

Currently the classpath file is there as a cache. ensime-atom only runs the sbt/coursier update if the timestamp on the classpath file is older than the package.json of ensime-atom (which is updated per relase).
So I don't know. We could do it another different way. Run coursier always but without update-changing. And if we want to update server we run it with update-changing. But we don't really need the classpath files…
But the question is when a user would like to update server and when not.
Richard Dallaway
@d6y
Feb 26 2016 09:13
…and when we migh recommend doing so because stuff has changed.
To me, what there is (when package.json changes) is sane. Releases aren’t so frequent as to be a pain.
Viktor Hedefalk
@hedefalk
Feb 26 2016 09:15
Yes, hm. We could probably just remove update-changing from startup and remove the classpath file thing and just do it in-mem. And re-add the "update server" command to run a coursier fetch with -m update-changing.
The other idea is to make the client setup a "latest timestamp on ensime server snapshot", which we would only update if we need a later ensime-server for this release. On the other hand, we want everyone to update to latest server once in a while anyways.
I just think the "communicating internally via files" is a pretty bad pattern if we don't need to.
Rather just put a timestamp in a file in that case and have the classpath inmem instead.
@d6y Thanks for updating release notes.
Richard Dallaway
@d6y
Feb 26 2016 09:19
Is there any doc for what -m does?
having problem finding anything...
Richard Dallaway
@d6y
Feb 26 2016 09:24
@hedefalk btw, you thinking of getting to ScalaDays berlin this year?
…or even https://skillsmatter.com/conferences/7432-scala-exchange-2016 (planning ahead a bit there!)
Viktor Hedefalk
@hedefalk
Feb 26 2016 09:25
@d6y Definitely Berlin, already bought tickets.
Richard Dallaway
@d6y
Feb 26 2016 09:25
I’m planning to be at both of those..
…ah excellent, I will go to Berlin too then.
Viktor Hedefalk
@hedefalk
Feb 26 2016 09:26
Scala exchange would be great too. A bit early to decide though.
:thumbsup:
Maybe we can have a hack-session on ensime-atom :)
Richard Dallaway
@d6y
Feb 26 2016 09:27
that’d be good.
Viktor Hedefalk
@hedefalk
Feb 26 2016 09:28
I think I'm gonna spend a few hours today to explore pulling if I can pull out an ensime-client node package without negatively effecting dev turnaround.
A bit curious on vscode…
Richard Dallaway
@d6y
Feb 26 2016 09:29
Yeah, I guess the core stuff isn’t going to change much between Atom and the MS thingy.
Have fun!
Viktor Hedefalk
@hedefalk
Feb 26 2016 09:32
Yeah, I think it can be a good thing to force some architectural cleanup of ensime-atom too.
Viktor Hedefalk
@hedefalk
Feb 26 2016 13:50
If someone on Win would like to try the Coursier bootstrap, I'd be happy. I was trying to provoke an error using curl, but it seemed to work on appveyor: ensime/ensime-atom#189