These are chat archives for ensime/ensime-atom

3rd
Mar 2016
Matthew de Detrich
@mdedetrich
Mar 03 2016 06:45
@hedefalk I will have to upload my reproduction of my issue a bit later, I am currently getting bogged down in scala-json-ast
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 06:46
@mdedetrich give up with that :-P come fix atom instead, it'll be far more rewarding :-)
Matthew de Detrich
@mdedetrich
Mar 03 2016 06:47
Eh its almost there, I am also in the middle of moving so I don’t have a lot of time
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 06:48
Meh. The JSON wars are a philosophical problem requiring much debate, you'll spend the next year fighting that battle.
Matthew de Detrich
@mdedetrich
Mar 03 2016 06:50
I think I am gradually going to end up forcing it, don’t really like it, but it at least makes people act more rationally
Its actually finally getting somewhere
@fommil People have a tendency to complain, but when you ask for a good solution they start to realise that something thats a standard can’t solve everything
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 07:22
Isn't that the primary objection that many people have? Anyway, if your heart is set on it. Id be happier if you worked on ensime :grinning:
Matthew de Detrich
@mdedetrich
Mar 03 2016 07:24
Well currently the lack of JSON has actually cause a lot of issues (personally and in the community) so its one I want to solve, and the sooner the better
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 07:26
It's unlikely that we'll swap from spray-json-shapeless in ENSIME.
Matthew de Detrich
@mdedetrich
Mar 03 2016 07:29
The current implementation is basically almost the same as spray-json (thats kinda the idea)
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 07:33
Well that's a shame
Viktor Hedefalk
@hedefalk
Mar 03 2016 07:33
@fommil How does spray-json compare with argonaut or cerci? I've used argonaut successfully before, but will probably use cerci in my next thing if I don't get any new stimuli. I've only used lift-json before and compared to that, argonaut has been a charm. I'm not really into runtime exceptions. Unless it's coffeescript :)
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 07:33
spray-json has some flaws. The AST is ok though.
I use spray-json until i need crice. Its heavy.
Viktor Hedefalk
@hedefalk
Mar 03 2016 07:35
Sorry, circe, not cerci. I've been watching to much game of thrones? It's heavy?
Matthew de Detrich
@mdedetrich
Mar 03 2016 07:46
Well the idea of scala-json is its only the AST, so you are free to implement your own parser/serializer for your use case
@fommil Also since you can verify that the JSON is correct (I believe ensime automatically derives the JSON), you can probably get away with unsafe.JValue
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 07:59
Still don't see why we should swap over. It adds another jar into an already bloated dependency tree which is tricky when you're an IDE expected to keep up with Scala releases.
If anything, I'd rather look at removing dependencies (akka in particular)
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:00
Well the AST itself is going to really small, and stable. However if you are using Spray as your webserver, odds are that sometime down the track you would be using it anyways
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:00
We're not using spray
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:01
The idea of the AST is its minimal and clean with zero dependencies, so if implement your own web server or communication system, you don’t have to pull everything in to work with it
You also won’t have lifecycle issues
@fommil The intention of JSON AST is to be ultra small (it doesn’t handle querying or parsing), and that ideally, it will only be updated when a new Scala major comes out
So in that sense, if you are using JSON, that actually better aligns with your needs than spray-json
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:06
I don't care how small it is. It's another jar with another maintainer and another release schedule and will slow us down when we want to support the latest Scala or dotty binary formats.
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:06
@fommil scala json ast will support newer versions of Scala faster than anything else out there, even dotty
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:06
I'd frankly rather just copy pastem these dependencies into our source tree
How? Are you going to sit over Martin's shoulders when he cuts the M1 release?
Then we have to wait for spray-json to release their parser and formatter
Then i can cut spray-json-shapeless
Then we can use it
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:08
@fommil snapshots can definitely be made, almost instantly, when they are released. There isn’t any real breaking of code for scala json ast
I am just saying, that spray-json will be a hell of a lot slower than scala json ast for releases (same deal with any framework really)
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:09
We'll have to see. i don't see how adding another link in the chain helps anything
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:09
scala json ast, is literally just 2 AST implementations packaged as a jar, with a build.sbt to set up for platforms (it also targets Scala.js). Publishing a version by just adding it to crossVersions, or bumping a version number, is really easy
Especially since we don’t have to care about breaking anythin
The problems you have is actually one of the main reasons this is being done
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:10
My argument was always put it in the stdlib or just promote existing solutions. I don't see any value in blessed modules
But you're not solving any problem that we have, so i refute your statement
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:10
Martin (and others) is pushing to cull stdlib really hard, for it to be a minimal core. So blessed modules will be a stdlib
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:10
It's just complicating the release scheduling
Exactly, which is why I'm in favour of it not existing. Stdlib or bust.
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:11
If you use spray-json, you tie yourself to their release schedule. So your alternatives are to do it yourself, or to pick a blessed module which will have a same release schedule as Scala itself
The latter is what scala-json-ast will be
Its treated the same way as scala-xml in that regard
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:11
Yes, but now you'll tie us to two. How is that better?
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:12
I don’t think I said that you should use both (do you mean trying you to both Spray and scala-json-ast?)
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:12
My experience with scala modules is that their release schedule is horrendous. Did you ever use scala swing?
Of course we have to use both. It's only an ast. It's practically useless
I need a parser and serialisation library
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:13
Yes, scala-swing was deprecated because no one was using it
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:13
Nobody was using it because they didn't keep up
I was using it
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:14

I need a parser and serialisation library

Well the change for scala json ast is not going to effect you then. These parsers will use a AST behind the scenes so you wont notice

Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:14
There s nothing special about a Scala module. It's exactly like any other oss package .
Aaaaagh!! You're not listening.
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:14
it appeared that you were arguing that you wanted to make your own AST/parser/serializer
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:15
You're giving me one more jar in my release schedule. That's causing me pain. I'd rather just copy paste all of spray-json into our codetree to avoid all this nonsense.
And not use this new ast at all. That brings us to zero jars, not two. That's the right direction as far as my sanity is concerned. This AST is not helping. Even Martin thought it was a full JSON library.
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:19
What you are saying doesn’t really make any sense. If you are going to use a parser that isn’t internal, you are going to tie yourself into its release schedule, regardless if that parser uses spray-json behind the scenes or scala-json-ast behind the scenes. Spray-json/play will probably move to scala-json-ast, but to you this should be completely irrelevant, because spray-json or play-json (or w/e) are their own discrete dependencies either
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:19
Or maybe we'll just move to cerce and piggyback off typelevel's pipeline
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:19
You seem to be arguing to copy everything into your own tree internally, which is fine, but you were implying that scala-json-ast would be worse than spray-json which isn’t correct
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:20
The reason it doesn't make sense to you is because you're not appreciating the complexities of being on the front line of new scala releases.
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:20
Its not that its not making sense, its that its not correct. I know the release cycles of the libraries you talk about, they are slower than what you are arguing for
spray has a really slow release cycle, so does play, so does circe
They all have dependencies/other breakages that they have to deal with and solve before they can release
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:21
Nobody can edit their dotty code until the ide supports it, which includes the author's of the libs were using. It's chicken or egg. Hence, we need to remove deps, not addto them. We're expected to be first wave. You're going to be first wave now which pushes spray-json into second wave and ensime inho 3rd wave.
Honestly, this AST is not helping.
I will copy/paste instead.
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:22
The solution you are talking about seems to be the exact opposite of what you wan’t to do solve the issues you are talking about. Making the code internal is your best solution. The second best solution is to pick a library that has a really good release cycle (or a chance of having a really good release cycle). None of the libraries you mentioned have that
It seems you have more of an issue with it being “typesafe” rather than what is likely to happen in reality.
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:23
spray-json does have a good release schedule. It's as simple as me emailing mathias and asking him to release.
It's not spray.
he'd probably give me the keys if i asked nicely.
But a new AST means major changes
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:24
Sure, and scala-json-ast won’t be any different in that regard. Its already being set up to handle this stuff very well, and there will be multiple maintainers (we have been over this before)
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:24
Breaking changes. Probably released as spray-json2
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:25
mathias is, btw, going to be on the commity for the AST since he helped design it
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:26
We'll see how it goes, but at the first sign of trouble I'm forking.
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:28
Sure, all I wanted to say is that the release will be managed by the OSS community (the current one has around 6 people in it iirc). I will be on there myself, and if all you are going to ask for is “bump to M4 and release a snapshot”, thats not hard at all, it takes me 5 minutes
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:31
And spray-json is transitioning to this ast without breaking changes?
And it'll be backported to 2.10?
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:31
It already supports 2.10, and Scala.js
I am also planning to add 2.12.x support, but I am focusing more on getting the design finalised now
Its intended to support every Scala version since 2.10, this is another reason the design is intentionally kept to be small, its much easier to deal with back porting and unstable releases
Benchmarking is also being set up, so we can deal with performance regressions as well
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 08:44
Fine, well if it's transparent and doesn't cause me to do any more work then it should be ok.
My objections then become philosophical in that i don't see any reason for scala modules. They are exactly like any other ivy dependency.
Matthew de Detrich
@mdedetrich
Mar 03 2016 08:47

There is a technical reason why they are being made into modules (smaller stdlib makes it easier for compiler programmers to work on the compiler), however the “blessing” of modules is also needed to help transition people into the language.

Thats however another debate

Fine, well if it's transparent and doesn't cause me to do any more work then it should be ok.

It is meant to be transparent. Frameworks/json libraries will use this scala json ast either directly, or add it as module support. If its the former, you will just download a scala-json-ast instead of a spray-json. If its the latter, its optional, so it just wont be downloaded.

The main point I am making is that scala-json-ast is deliberately designed to be stable, easy to backport and easy to release. Its not like scala-swing which is such a massive undertaking that I don’t see how it even could be maintained by someone like Typesafe

Viktor Hedefalk
@hedefalk
Mar 03 2016 14:42
Just published ensime-atom@v0.37.0. Coursier by default, removed SBT entirely. And also support for using assembly jars https://github.com/ensime/ensime.github.io/pull/68/files.
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 15:05
:clap:
Not jealous, honest
Viktor Hedefalk
@hedefalk
Mar 03 2016 15:05
:)
By the way, when did slow claps become sarcastic by default? Back in the day we used them honestly, but the script kidz I work with these days…
Yoel Garcia Diaz
@yoeluk
Mar 03 2016 15:14
Hi, does anyone know how to enable auto-import? I think that it used to be under settings but I can't find it anymore
Viktor Hedefalk
@hedefalk
Mar 03 2016 15:18
auto-import?
Do you mean auto-import on auto-complete?
Yoel Garcia Diaz
@yoeluk
Mar 03 2016 15:20
yeah I was thinking that it could add import to the file when using a case class / object not in scope ?
maybe I am mistaken that this was included in the settings before
Viktor Hedefalk
@hedefalk
Mar 03 2016 15:28
Yeah, it never was. There's a shady "import the first of import suggestions on cursor" implemented without any ui. There's an issue. Please +1 and consider PR :) :) :) ensime/ensime-atom#181
Viktor Hedefalk
@hedefalk
Mar 03 2016 15:54
Sorry guys, published v0.37.2 which fixed two really stupid issues.
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 16:37
@hedefalk you need to import the right implicit
import fommil.mood.ClapIsSarcastic
I don't provide any others, you'll have to write your own
Oh no, wait, it's implementing a sealed trait. Poo poo for you.
Richard Dallaway
@d6y
Mar 03 2016 16:41
@hedefalk 0.37.2 working well for me. Wow, that ensime start up time is so much faster now.
Should the ensime-client source be here -> https://github.com/ensime/ensime-node ? I don’t see anything there yet.
Viktor Hedefalk
@hedefalk
Mar 03 2016 16:46
@d6y Yup, should move it there.
Richard Dallaway
@d6y
Mar 03 2016 16:47
Cool - ok, I’m going to go catch up with all the work and slap together release notes, and do a new screet shot for the documentation site.
Viktor Hedefalk
@hedefalk
Mar 03 2016 16:49
Anyone know how to add upstream repo to an existing. I mean https://github.com/hedefalk/ensime-node to be like a fork of https://github.com/ensime/ensime-node?
So I can web-PR.
Now it's there at least…
Richard Dallaway
@d6y
Mar 03 2016 16:52
Hmm git superpowers. I’d probably be tempted to try merging your code into the ensime version, deleting your repo, and recreating it as a fork :-)
Rory Graves
@rorygraves
Mar 03 2016 16:52
@fommil might know. He moved a bunch around when we got started.
Viktor Hedefalk
@hedefalk
Mar 03 2016 16:53
Yeah, I used some importer thing now so ensime/ensime-node got it all. But there's not github connection between them. This is not really git but github.
Richard Dallaway
@d6y
Mar 03 2016 17:00
The winner for my favourite commit of 2016…is…. the comment “seems to be working” and a delete of 1776 lines of code. That is fantastic :-) Deleting code is the best feeling.
Rory Graves
@rorygraves
Mar 03 2016 17:01
Lol. Awesome. My favourite kind of commit.
Richard Dallaway
@d6y
Mar 03 2016 17:24
@hedefalk feel free to add in things I missed….
@/all release notes for 0.37.2 (@hedefalk has been busy!) https://github.com/ensime/ensime-atom/releases/tag/v0.37.2
Denis Mikhaylov
@notxcain
Mar 03 2016 17:50
Do I need to install coursier to make 0.37.2 work?
Richard Dallaway
@d6y
Mar 03 2016 17:51
@notxcain I don’t think so… but I realise I’m saying that and I do happen to have it installed
Denis Mikhaylov
@notxcain
Mar 03 2016 17:53
I updated to 0.37.2, hit Ensime: Start and then Ensime connected appeared. However almost every command results in The error was thrown from the ensime package. ensime is out of date: undefined installed; 0.37.2 latest. Upgrading to the latest version may fix this issue.
For example
/Users/notxcain/.atom/packages/ensime/lib/features/public-symbol-search.coffee:31
Hide Stack Trace
TypeError: Cannot read property 'post' of undefined
    at VueComponent.<anonymous> (/Users/notxcain/.atom/packages/ensime/lib/features/public-symbol-search.coffee:31:11)
    at Watcher.run (/Users/notxcain/.atom/packages/Ensime/node_modules/vue/src/watcher.js:268:17)
    at runBatcherQueue (/Users/notxcain/.atom/packages/Ensime/node_modules/vue/src/batcher.js:60:13)
    at Array.flushBatcherQueue (/Users/notxcain/.atom/packages/Ensime/node_modules/vue/src/batcher.js:34:3)
    at MutationObserver.nextTickHandler (/Users/notxcain/.atom/packages/Ensime/node_modules/vue/src/util/env.js:58:16)
Richard Dallaway
@d6y
Mar 03 2016 17:56
I’m in the habit of deleting my .ensime_cache folder in a project after an update, and restarting Atom
Denis Mikhaylov
@notxcain
Mar 03 2016 18:00
@d6y nice! It worked, thanks. It worth adding try removing your .enisime_cache to troubleshooting guide
Richard Dallaway
@d6y
Mar 03 2016 18:00
Ok - thanks for letting me know. I will do
Richard Dallaway
@d6y
Mar 03 2016 18:06
Atom screen shot updated, and troubleshooting guide updated in ensime/ensime.github.io#69 … I’m going to go off and have an evening.
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 18:23
@d6y you don't need to delete the cache
Only time you ever need to delete it is if you want the reclaim some disk space or you have a huge project and are on windows and just recompiled everything
(then is faster to start from scratch)
@hedefalk just take your commits and push upstream, then delete/move your repo and clone from upstream
Srepfler Srdan
@schrepfler
Mar 03 2016 21:21
ok, how precise is ensime output supposed to be let’s say under atom?
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 21:22
how precise is your input?
Srepfler Srdan
@schrepfler
Mar 03 2016 21:22
scala file seems to pass ok via intellij
ensime file has been regenerated so imports should be fine
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 21:23
honestly, I don't know what you're asking
Srepfler Srdan
@schrepfler
Mar 03 2016 21:23
for example
Ghost
@ghost~540393fe163965c9bc2018ce
Mar 03 2016 21:24
have you tried following the "Getting Help" section of http://ensime.org ?
Srepfler Srdan
@schrepfler
Mar 03 2016 21:25
let me try the procedures and see if ensime still complains