Clojurians
#lumo
<
2017-04-17
>

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

plexus15:04:28

is there any support for loading .cljs namespaces from node_modules? sorry for my ignorant questions, just trying to gauge the possibilities... could npm packages be used to distribute libs for lumo as an alterantive to clojars?

plexus15:04:05

@futuro thanks for the links BTW, that's exactly the kind of stuff I was looking for earlier!

anmonteiro15:04:03

@plexus there are no ignorant questions if there’s no docs to enlighten you

anmonteiro15:04:09

:slightly_smiling_face:

plexus15:04:06

:slightly_smiling_face:

anmonteiro15:04:24

so that doesn’t work right off the bat, but you can make it work with lumo --classpath node_modules/your-module/the-modules-src-dir

anmonteiro16:04:15

I wonder if we could support CLJS require by indexing node_modules folders implicitly

plexus16:04:01

ok, that's what I thought. Would be a really cool feature :slightly_smiling_face: Right now it seems using an npm package for JS stuff is significantly more straightforward than using a package from Clojars.

plexus16:04:15

is it possible to modify the classpath at runtime?

anmonteiro16:04:41

@plexus technically there’s nothing stopping us from doing that

anmonteiro16:04:48

there’s work in progress to make it work

anmonteiro16:04:07

probably won’t be in the next version (1.4), but definitely in 1.5

anmonteiro16:04:51

or I could just push the 1.4 release to next week and finish that work this week :slightly_smiling_face:

plexus16:04:56

is this referring to modifying the classpath, or to loading from node_modules? ("probably won’t be in the next version (1.4), but definitely in 1.5")

plexus16:04:18

ok, makes sense

plexus16:04:46

do I have it right that 1.4 will make it possible to require js files like namespaces?

anmonteiro16:04:01

what do you mean?

anmonteiro16:04:07

you can already require JS files

plexus16:04:23

isn't that what shipped in 1.9.518?

anmonteiro16:04:28

(js/require "my-module") or (js/require "./path/to/module")

anmonteiro16:04:38

oh that’s a different thing

anmonteiro16:04:01

the Node module support that shipped with 1.9.518 is about converting CommonJS modules to Goog modules

anmonteiro16:04:26

that’s about compiling ClojureScript projects

anmonteiro16:04:39

Lumo supports require out of the box because it’s based on Node

anmonteiro16:04:14

that said, Lumo also supports compiling CLJS projects (with optimizations), and we also want to implement that support in future versions. But that’s not going to be in 1.4

plexus16:04:49

yeah, so I've been using js/require in my scripts, but I thought with 1.9.518 I would be able to use CLJS (require ...) instead to do the same thing. I might be missing some bits here :slightly_smiling_face:

anmonteiro16:04:11

yep, this stuff is confusing

anmonteiro16:04:04

to give more context on the classpath thing, my objective is to roughly have the same API as clojure.java.classpath

plexus16:04:59

cool, good stuff

dominicm19:04:38

There is potential risk (I assume) that this will lead to collisions, as things will resolve… differently to that of Aether. Especially as dependencies nest in node, where they are flat in jvm.

plexus20:04:09

definitely true. I'm thinking this would be mostly for things that exclusively target lumo and hence are only on npm. But perhaps it makes more sense to improve the experience with clojars, perhaps moving some stuff from calvin into lumo, or making calvin more a first class "blessed" package manager. (just thinking out loud here)

plexus20:04:27

I first had a hard time getting calvin running, but think I had an outdated version in node_modules somewhere that caused trouble. Now that it works it's pretty sweet. I just submitted a patch so that it passes extra arguments on to lumo, this way you can do calvin repl -m my-app.core and have calvin take care of the classpath for you.

dominicm21:04:28

I feel like eventually someone will solve the classpath problem in a very happy way, & we'll end up with a new lein/boot/make/etc. that can handle it all for you.

dominicm21:04:20

Currently mach shells out to boot to calculate the classpath (and does some caching so it doesn't kill lumo unless you change the dep). I imagine shelling out to mvn would be faster though, but many don't have maven itself installed.

dominicm21:04:25

Another option is for this build tool to wrap up aether into a tiny java cli of some kind that you "lug" around, and it calls java -jar aether-wrapper.jar cp -d "juxt/bidi:0.2.0" -d "juxt/yada:1.5.0" or something

dominicm21:04:55

This will be more effective with java 9 once you can strip down that jar really small.

dominicm21:04:11

Or maybe even taking advantage of the "compile to native" feature too.

dominicm21:04:52

I think this probably will go away given the pieces of the jigsaw (eh, eh :wink:) fall into place

anmonteiro21:04:49

:slightly_smiling_face:

anmonteiro21:04:20

or we make the entire JS community need to depend on Maven

anmonteiro21:04:27

and someone will write a Maven resolver in JS

dominicm21:04:30

That could also work. I hear maven is really complex in it's rules about arithmetic. So I fear a js based one would ultimately not work.

anmonteiro21:04:39

ah interesting

dominicm21:04:17

Well, it would work, it wouldn't be correct. I live in constant fear of things not being correct. I may be overly paranoid though ¯\(ツ)

plexus21:04:54

define "correct" :slightly_smiling_face: I find Java's dependency resolution entirely unintuitive and arbitrary at times. I've looked hard to find a description of the algorithm, but such documentation does not seem to exist.

plexus21:04:34

so yes, if anyone ever decides to reimplement this in JS or CLJS it will probably behave slightly different. I can live with that.

dominicm21:04:54

Well, I think it's maven's classpath arithmetic that can be confusing at times, no?

anmonteiro21:04:53

so this just happened:

[email protected]:/# time ./lumo -e :foo
:foo

real	0m0.113s
user	0m0.100s
sys	0m0.010s

dominicm21:04:56

java just takes a flat path, and searches sequentially. Think like $PATH

anmonteiro21:04:08

that’s 113ms

dominicm21:04:30

:horse_racing: zoom

plexus21:04:34

yes, I mean Maven, Aether. "Java in practice" :wink:

anmonteiro21:04:35

I don’t know how it’s faster in my Ubuntu Docker image than it is on my mac

plexus21:04:43

awesome @anmonteiro !

dominicm21:04:52

because linux is just betterer

anmonteiro21:04:14

:slightly_smiling_face:

richiardiandrea21:04:18

There was an idea here to use GWT java to js converted in aether, nobody has done it yet, but it is possible :grinning:

anmonteiro21:04:35

yeah it’s consistently around 160ms on my mac, but 110-115 on Ubuntu

plexus21:04:56

^^ just noticed that version needed a bump

plexus21:04:34

it's the least I can do :stuck_out_tongue:

anmonteiro21:04:35

I like to call it “environment” now :slightly_smiling_face:

anmonteiro21:04:57

it’s not just a REPL anymore

plexus21:04:58

environment sounds good. it's a word with ambition :wink:

plexus22:04:52

Are there any Calvin users here that could take a non-trivial patch for a test run?

plexus22:04:06

now :bed: :clock1:

stbgz23:04:05

@plexus got it!!

stbgz23:04:44

I’ll look at it tonight it should get merged by tomorrow, thanks for the pr