Clojurians
#lumo
<
2018-03-15
>

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

richiardiandrea03:03:20

My 2c @yogthos. I so so like the npm approach actually and using it with profit :) I basically pull all my deps from it except for expound and humane-test-output. Cljs deps are way less frequently updated and maintained... Something shadow-cljs is doing is to use deps.edn directly for building the classpath, shelling out to clojure. Either that or tools.deps will need to be somehow ported to self host...it probably won't happen any time soon. I am building the classpath with clojure -Spath now in a script but would love to see it automatically happen in lumo.

yogthos03:03:29

I wonder if it might make sense to start publishing cljs libs on npm as well as clojars

richiardiandrea04:03:44

I am pushing for that as well, I am at the moment consuming macrovich from npm and I see big value in that because a lot a lot more people are working (ok to be fair also breaking) the tooling around it :smile: Actually I also published https://www.npmjs.com/package/@arichiardi/humane-test-output

richiardiandrea04:03:56

But it is a fork

hlolli10:03:54

how would you handle the classpath resolution for cljs libs on npm?

yogthos15:03:31

things would end up in npm_modules, so it should be predictable

yogthos15:03:11

npm would take care of dependency resolution, and then populate the libraries in standard locations, so lumo should be able to look for them there automatically

hlolli15:03:59

I had a discussion with thheller about this, and he had good arguments against putting .cljs files into npm modules. Forgot what he had in mind, but if you have a npm module with cljs files, even tough you could add that location into the classpath, there are going to be many problems packageing something that depends on this, and for that module to depend on other dependencies, be it node or other cljs lib.

richiardiandrea16:03:21

Uhm i don't think I see why, doesn't a package always get its own node_modules folder? As long as you dig recursively you should find "transitive deps". At the moment the key is to specify a field in package Json but I agree a better solution would be ideal. Like a lumo.edn.

yogthos18:03:41

yeah I can't really think of what the issue would be either, the nice thing with using package.json is that it's already built into npm and you're going to need to use one anyways when distributing things

richiardiandrea18:03:54

yes so the only question there was whether we needed a lumo section or not. It was choosen not too and directories has been repurposed. Actually not repurposed. This is still open for discussion of course: https://github.com/anmonteiro/lumo/issues/130

yogthos18:03:11

so sounds like the issue with npm_modules is that other libraries could potentially mess with that, but that seems like a low risk problem to me, and having something like lumo or cljs reserved for the classpath would address majority of cases

yogthos18:03:53

it might also make sense to default to using npm_modules as the default, and allow using lumo.edn optionally

richiardiandrea18:03:08

totally agree with you

yogthos18:03:11

so if you wanted to have more control over where dependencies are placed, you could opt into that

richiardiandrea18:03:36

in any case at the moment we are not planning to release for broader JS consumption

richiardiandrea18:03:48

packages there are just wrappers of cljs

yogthos18:03:27

right, the packages would just contain cljs files for lumo to use

yogthos18:03:16

yeah that seems quite reasonable

mfikes11:03:04

First class eval for self-hosted landed in ClojureScript master :slightly_smiling_face:

hlolli12:03:47

wtf, my slack client is weird

hlolli12:03:20

my question is, does that mean macros can be compiled and called directly, without $macros namespace?

mfikes12:03:13

It is just an implementation of clojure.core/eval but for self-hosted ClojureScript, or regular ClojureScript that somehow defines cljs.core/*eval*.

hlolli12:03:44

ok, I thought that the limitation of macros in clojurescript was due to the lack of "real" eval, therefore compilation stage before clojurescript start was needed to make them run, but as you pointed out in an old blog article on macros, is that they can indeed be called on runtime, if one uses $macros namespace to call them (otherwise the return just macroexpand).

mfikes13:03:19

@hlolli It is probably feasible to revise the ClojureScript compiler so that self-hosted would allow intermixed macros and functions in the same namespace, just like Clojure. This has always been the case with self-hosted ClojureScript.

hlolli15:03:15

this is not a self-hosted issue, it's not possible to intermix macros and functions in one .cljs namespace? In a piggyback based node-repl started via jvm I get the same macroexpand in runtime from macros.

hlolli15:03:59

it's my habit of putting them in .cljc files or .clj files so I'm not sure if my memory is right :slightly_smiling_face:

mfikes14:03:01

Support for cljs.core/eval has now landed on Planck master; Lumo can likely easily do the same.