Clojurians
#lumo
<
2017-03-30
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

cfleming00:03:32

@anmonteiro @mfikes Thanks!

mfikes01:03:54

@cfleming Planck also now supports -V / --version and -D / --dump-sdk if you do brew install --HEAD planck I'll likely further shore up the code and also of course address any behavioral changes we find are necessary, but the first cut appears to be working.

mfikes01:03:04

@cfleming If you end up supporting Lumo and Planck via Cursive's "normal" project.clj infrastructure, both Lumo and Planck accept -c and a regular Java-style classpath. Neither Planck nor Lumo directly support lein but they are both often used by feeding lein-generated or boot-generated classpaths.

mfikes01:03:25

Adjusting Planck --version to behave like Lumo…

mfikes02:03:33

Having Cursive being able to introspect the bundled SDKs is something I've never seen before. I took a sneak peek at what it might look like.

cfleming03:03:22

@mfikes @anmonteiro When people are working on Planck and Lumo projects, do they tend to use lein for dep management? I guess they need to obtain their CLJS deps somehow?

cfleming03:03:04

I’m not sure how to handle that, actually.

hit02304:03:11

What about boot?

hit02304:03:31

@cfleming

cfleming07:03:00

@hit023 Cursive doesn’t support it right now, but my question was more how Lumo/Planck users manage their deps in general

dominicm07:03:32

@cfleming mach uses a #cp reader macro, then mutates the classpath

dominicm07:03:59

I think there's a cp file produced for performance though, uncertain.

cfleming07:03:04

@dominicm mach? What’s that? I’m not familiar with it.

dominicm07:03:47

@cfleming JUXT's build tool on top of lumo

dominicm07:03:16

If it's not much effort, it might be okay to just expect people to have a file like that which contains the cp

cfleming08:03:03

@dominicm Thanks for the suggestion, I’ll check it out. But people still need some kind of dependency resolution and fetch, right?

cfleming08:03:21

They must use lein, boot or some other kind of Maven-like thing

dominicm09:03:05

@cfleming mach does boot -d dep:ver (nothing static).

dominicm09:03:05

I think my point is that nothing exists in this space yet

dominicm09:03:05

But the existence of a cp file inducing the classpath is a fine thing to have at this point in the lifecycle. And I'm assuming it's minimal effort.

cfleming09:03:30

@dominicm Ok, thanks - I think a cp file is a fine idea too. I’ll support that and then add new things as people start using them.

dominicm09:03:00

Just read my wording again. I see the ambiguity in my earlier words. Oops!

cfleming09:03:16

The doc only mentions #cp, but not anything about a cp file.

dominicm09:03:46

I can't remember how we do it exactly. But if we don't do it now, I can add it.

dominicm09:03:29

It may go into .mach or similar, currently afk so uncertain.

cfleming09:03:40

Thanks - I don’t really need it for anything specific, but the comments above made me wonder about it.

cfleming09:03:16

I’ve only used Lumo for one-off scripts, so hadn’t considered deps, or at least CLJS ones - I’d assumed it was all node_modules

dominicm09:03:22

Yeah, I can understand that. It may be a WIP to add it (I believe as a desire for caching)

dominicm09:03:55

It's difficult to consume cljs from a node modules folder due to differing semantics.

cfleming09:03:27

I am totally willing to believe that.

dominicm09:03:51

Mach did look into the node modules folder for a while, and still does a little (unnecessary now 1.2.0 is out). But the jar solution is better. The hard part now is figuring out the classpath arithmetic that maven does for a (cl)js port

cfleming09:03:46

Yeah, it’s a bit weird - you really want something with deps resolution (lein or boot) somewhere in the mix

cfleming09:03:15

Perhaps I could just get people to download their deps to a libs folder and use everything I find in there - I assume boot can do that trivially.

cfleming09:03:46

In general, I think my best option is going to be to just rely on the built-in IntelliJ functionality for now. That supports all sorts of different configs, and will allow pretty much anything. The only thing is it’s manually configured and not in some declarative file.

futuro11:03:38

@cfleming I've been using boot -d dep:ver to download the dependencies I needed, then I use lumo -c <fullpath to jar in .m2 directory>

pesterhazy13:03:04

Is there a way to start a repl in a namespace? lumo -e "(require 'my.core)" -e "(in-ns 'my.core)" -r doesn't seem to work

anmonteiro14:03:00

@pesterhazy can you do that in the raw clojure.jar?

anmonteiro14:03:54

If it's possible we should support it. Otherwise, that has been my rule of thumb

pesterhazy15:03:09

let me check

pesterhazy15:03:35

It works:

java -jar ~/.m2/repository/org/clojure/clojure/1.9.0-alpha14/clojure-1.9.0-alpha14.jar -e "(in-ns 'clojure.set)" -r

mfikes15:03:57

@cfleming Neither Lumo nor Planck do deps management and only accept a -c for the classpath. I suppose they are analogous to if you were to start a bare Clojure REPL, which also does no deps management. There is a section on Lein and Boot here http://planck-repl.org/dependencies.html

mfikes15:03:25

@pesterhazy @anmonteiro That may work in Clojure only because in-ns is a function in Clojure. In ClojureScript it is a REPL special—perhaps that's the root of the -e problem.

mfikes15:03:54

$ planck -e "in-ns"
WARNING: Use of undeclared Var cljs.user/in-ns at line 1
$ lumo -e "in-ns"
WARNING: Use of undeclared Var cljs.user/in-ns at line 1
nil

pesterhazy15:03:08

@mfikes interesting. Maybe an --init-ns arg would be better?

mfikes15:03:16

That might be a good approach :slightly_smiling_face:

pesterhazy15:03:08

For background, I like to have a dev script that opens a lumo repl opened in my user namespace

richiardiandrea18:03:50

@cfleming are you going to handle node.js objects/events code completion?

richiardiandrea18:03:08

That is the feature that I am seeing very powerful in vscode

cfleming19:03:56

@richiardiandrea So yes, to some degree, but I’m not sure quite how yet

richiardiandrea19:03:15

I was looking into ternjs

cfleming19:03:18

Type inference in (CL)JS is hard

richiardiandrea19:03:26

that could be a shared module between editors

cfleming19:03:42

Yeah, I actually use the base definitions from Tern for completion in Cursive

richiardiandrea19:03:57

given that we can kind of compile to JS on the flight, we could get pretty fancy :smile:

cfleming19:03:58

But I’m probably going to switch that to the ones from Closure

cfleming19:03:59

I’m planning to do more sophisticated inference in Cursive, but it’s a hard problem/large project

richiardiandrea19:03:00

yeah true that, it would be great to make it available to other editors and if you do that probably I can help :wink:

cfleming20:03:14

@richiardiandrea Unfortunately whatever I do probably won’t be reusable, since it’ll be intertwined with the IntelliJ infrastructure

richiardiandrea20:03:29

Well Tern runs as separate executable if I read it correctly too it might be straightforward to just call it from inside IntelliJ, but maybe I am totally off here :grinning:

cfleming20:03:43

The problem is that Tern only does JavaScript.

cfleming20:03:12

And running that sort of offline analysis in a separate process and then merging the results back into the data indexed within IntelliJ is… tricky.