These are chat archives for ensime/ensime-atom

2nd
Dec 2015
Matthew de Detrich
@mdedetrich
Dec 02 2015 01:57
@hedefalk What are your thoughts in using Scala.js instead of Coffeescript for the ensime-atom plugin?
Viktor Hedefalk
@hedefalk
Dec 02 2015 06:44

@mdedetrich My thoughts are: "would be cool". I started out a bit but struck some problems with integrating in a node.js env. Might be solved or a non-issue, dunno: http://stackoverflow.com/questions/31116258/how-to-provide-and-consume-require-js-modules-in-scala-js-and-extending-classes. I think I started some skeletons on doing the types for say atom API: https://github.com/hedefalk/scala-js-atom.

However, I currently don't feel this is something I rationalize spending time on. At least not right now. There are so many features I'd rather implement. The language is not really a big part of the problem right now. It's all about understanding Atom and churning out UI. I'm in no way a coffeescript fan boy, this is the first coffescript I've written. But coffescript is the way of Atom and all examples and API is done in coffescript. Sure It'd be cool to do scala.js or even purescript (haskell-like) instead, but basically feels like a lot of project "setup" and not that much paypack right now.

Viktor Hedefalk
@hedefalk
Dec 02 2015 06:52
One issue is that of apm packages being node.js packages. All major languages (coffescript, typescript or even purescript) can be compiled with other node plugins) This means you typically compile the source lang from within your package.json project definition by using devDependencies and simple scripts. scala.js is built with sbt. I don't know a nice way to do this in a package module, I mean we don't want compiled js in our github repo but then we need to build scala.js during installation of ensime-atom. Maybe this is just a google away, was on top of my head as one of the "issues".
Matthew de Detrich
@mdedetrich
Dec 02 2015 08:42
Ok, fair enough, but yeah your right in that its too much work for little gain
Jeff Wilde
@jeffwilde
Dec 02 2015 15:27
thanks for the pointers, @hedefalk. I’ll see if I can figure what’s going on when atom executes that temproary sbt project. (regarding path separators: github gists don’t allow real path separators in the file names. The backwards slashes I used representationally, so I could show where all the files were coming from including the home directory sbt config, etc. I’m actually on a normal OS X system with regular ol’ slashes: "/")
Jeff Wilde
@jeffwilde
Dec 02 2015 18:25
I’ve figured out what caused everything to blow up. For the curious, it appears that atom was picking up the latest version of java that I have installed, which happens to be a 1.9 early access release, which doesn’t work as expected with sbt. In my normal shell env, this version is ignored. I was able to fix by setting up an sbt wrapper script with some env vars pointing to the correct version of java. This explains why ensime works fine in emacs, which is already running in a shell with all my env vars setup properly.
Not sure if there’s an easy workaround within ensime-atom to ensure it never gets a "bad" version of java by default, but this could be considered not to be ensime-atom’s responsibility, although I am sure some other users will run into this as it becomes more popular...
Jeff Wilde
@jeffwilde
Dec 02 2015 18:34
hmm, I see the .ensime file contains a java-home entry (that is correctly set). I’m wondering if ensime-atom should be using this value while launching sbt?
actually, scratch that, I imagine that value is meant for launching the project itself, not the user’s system-level config.
Viktor Hedefalk
@hedefalk
Dec 02 2015 21:28
@jeffwilde Yeah, I did the same rationale. However, you’re at least the second having that issue. I’m thinking, you probably have a working java-home in .ensime since you probably ran gen-ensime with it. I think it will be more rare with someone wanting to use another java for running sbt than for the project itself than having a weird system default?
So maybe I should use the one from .ensime and have a setting for overriding…
Jeff Wilde
@jeffwilde
Dec 02 2015 21:49
Might be worth a setting for JAVA in the plugin that defaults or autofills from
Jeff Wilde
@jeffwilde
Dec 02 2015 22:51
^^ hit post by mistake there.
I was agreeing, it might be worth a separate setting for JAVA_HOME in the plugin that defaults or autofills with the .ensime file value.