This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-26
Channels
- # aleph (2)
- # beginners (119)
- # boot (18)
- # cider (19)
- # cljs-dev (46)
- # cljsjs (1)
- # cljsrn (30)
- # clojure (101)
- # clojure-dusseldorf (12)
- # clojure-finland (1)
- # clojure-greece (7)
- # clojure-india (2)
- # clojure-italy (6)
- # clojure-poland (4)
- # clojure-russia (120)
- # clojure-sg (3)
- # clojure-spec (147)
- # clojure-uk (75)
- # clojurescript (86)
- # cursive (4)
- # datomic (50)
- # docker (1)
- # emacs (4)
- # juxt (51)
- # leiningen (16)
- # liberator (1)
- # luminus (1)
- # lumo (116)
- # mount (2)
- # off-topic (2)
- # onyx (38)
- # pedestal (4)
- # protorepl (2)
- # re-frame (44)
- # reagent (8)
- # ring-swagger (16)
- # schema (5)
- # specter (16)
- # test-check (226)
I notice that lumo is tested with crisptrutski.boot-cljs-test
, looks very sweet, I wonder how one could script similar test-suite with lumo on lumo. If the build tools (cljs-boot/calvin) can already do something similar... 馃槙
@hlolli you do have all cljs.test
in Lumo
yes, but how to run all tests and get report. I've been tryign to develop some tests with cljs.test
but they seem bit useless if I need to run them each manually.
;; foo/test.cljs
(ns foo.test
(:require [cljs.test :refer [deftest is]]))
(deftest foo-test
(is (= 1 2)))
;; test_runner.cljs
(require 'foo.test)
(require '[cljs.test :refer [run-tests]])
(run-tests 'foo.test)
$ lumo -c src test_runner.cljs
Testing foo.test
FAIL in (foo-test) (at evalmachine.<anonymous>:507:85)
expected: (= 1 2)
actual: (not (= 1 2))
Ran 1 tests containing 1 assertions.
1 failures, 0 errors.
easy. Just thought of use-fixtures as you wrote this. But compileing a main test file that triggers the other test is fine.
@hlolli you may wanna set the report for :end-run-tests
too like in https://github.com/bensu/doo/blob/master/library/src/doo/runner.cljs#L53-L54
so that lumo exits with the appropriate exit code
on 1.4.1 I'm getting: WARNING: Wrong number of args (5) passed to lumo.repl/execute at line 137 WARNING: Wrong number of args (5) passed to lumo.repl/execute at line 407
are you calling lumo.repl/execute
directly?
in Mach?
NODE_PATH="${MACH_HOME}/node_modules" ${MACH_HOME}/node_modules/.bin/lumo -c ${MACH_HOME}/src:${MACH_CLASSPATH} mach/core.cljs $ARGS
https://github.com/juxt/mach/blob/7de9778ef52e0af1d4b4a518f050219388138d4b/src/mach/core.cljs#L137
certainly seems like you are
in fact, just doing this from the command line: lumo -c ~/dev/juxt/mach/src mach/core.cljs foo
it takes 1 more arg..
just pass 0
as the last arg
Great @anmonteiro that fixes it!
just opened that issue so that you don鈥檛 rely on internal APIs
Another issue, trying to get caching working, but not able from the cmd line, i.e. lumo -k .cache -c ~/dev/juxt/mach/src mach/core.cljs foo
..?
certainly sounds odd
don鈥檛 you see a .cache
folder?
lumo -k .cache ~/dev/juxt/mach/src mach/core.cljs foo
will create the cache folder but then errors '#error {:message Could not load file /home/jon/dev/juxt/mach/src, :data {}}
'
now you鈥檙e missing -c
lumo -k .cache -c ~/dev/juxt/mach/src mach/core.cljs foo
fails with 'Could not resolve target: /home/jon/dev/juxt/mach/src
', but the cache folder is populated
I think its a compatibility issue with mach, just made a dummy namespace with just a println in, called it using the same command line style and it worked
@jonpither I don鈥檛 have any immediate ideas
can you try to come up with a minimal failing case?
thanks!
@anmonteiro it's another issue with Mach, the extra params confuse Mach. Apologies! Will fix
good to know, thanks
@jonpither so now you can distribute cached artifacts along with the NPM package and always start Lumo with -c
and in 1.4+ that鈥檚 not really a problem because Lumo knows how to invalidate the cache: https://github.com/anmonteiro/lumo/commit/ed60f0587688ba686e233a3b89b062a6435497d9
@anmonteiro #!/usr/bin/lumo -k .cache
I have this shebang, the .cache folder has a space in front of it, I have to do -k.cache
, I'm not sure if this is normal behaviour for shebangs or not.
@dominicm not related, but I think you should be using #!/usr/bin/env lumo
more portable
my UNIX fu is not very good otherwise so I can鈥檛 really help there
I remember @mhuebert had a similar problem with Planck some time ago
@anmonteiro Oh I know I should, I was reducing error.
http://stackoverflow.com/questions/4303128/how-to-use-multiple-arguments-with-a-shebang-i-e
I find this particularly frustrating as: a) It means I can't switch mach back to using a shebang b) my portable /usr/bin/env cannot be used due to the non-portable shebang.
with a colleague here we were wondering what it would take in order to have a node
modules-centric output from the cljs compiler
dropping the goog.provide
and goog.require
and make everything scoped (only shareable through export
)
would it be faster on node? don't know until I try 馃槃
@richiardiandrea ClojureScript has been tied to Google Closure since the beginning, that鈥檚 not gonna change
I think what you鈥檙e talking about is so infeasible it shouldn鈥檛 even be considered
yeah that is what I am trying to understand, if it is feasible and if not why
and if doable what advantages will it have
very early stage here 馃槃
for sure there is probably some speed gain in removing all the chaining in cljs.core.bla.bla.call
...but how to evaluate that and quantify that? Is it worth even thinking about it? Don't know yet
there are no .call
calls if you compile with :static-fns
right thanks
I鈥檓 quite sure the property accesses are equivalent in performance (if not faster) than allocating closures, which is what happens if you go the exports route
you may wanna re-evaluate the trade-offs
I am getting instaparse to work with lumo, it is mostly working with the source files
sorry if I am newbie-ing a bit, but couldn't you do in node:
export const cljs_core = require("cljs-core");
for namespaces for instance (premise: I am probably missing smth)yeah who knows which one is faster without profiling...
but the build uses cljsee which outputs a .clj alongside the cljc, lumo picks the clj (with java specifics) over the cljc
@gmercer hrm. do you mean for a macros file?
just plain code - cljsee allows the engelberts to write in clojure 1.7 and using cljsee makes the jar compatible back to 1.5
@gmercer I still don鈥檛 understand the problem. if you are require
ing Instaparse, it should pick .cljs
and .cljc
files
it鈥檒l only search for .clj
files when it鈥檚 looking to load macros
hence my question
I will dig deeper, it's just that the cljc works via -c src but when given the packaged jar it loads the clj - it should have all macros available from the cljc
@gmercer I see the problem
I don鈥檛 think this is a Lumo problem
instaparse.core
requires instaparse.gll
instaparse.gll
requires its own macros, see https://github.com/Engelberg/instaparse/blob/master/src/instaparse/gll.cljc#L31
if there is a gll.cljc
and a gll.clj
file, we think the macros are in the .clj
file
so we load that
`jar tf ~/.m2/repository/instaparse/instaparse/1.4.6-SNAPSHOT/instaparse-1.4.6-SNAPSHOT.jar
''' jar tf ~/.m2/repository/instaparse/instaparse/1.4.6-SNAPSHOT/instaparse-1.4.6-SNAPSHOT.jar ... instaparse/gll.clj ... instaparse/gll.cljc'''
this is correct, and it鈥檚 something that needs to be changed in Instaparse. that鈥檚 how the ClojureScript compiler reasons about what are macros vs non-macros files
https://github.com/anmonteiro/lumo/blob/master/src/cljs/snapshot/lumo/repl.cljs#L72
^ is this what you鈥檙e asking about?
because it is possible you have cljc
for CLJS code and clj
for macros code
I think it would work fine with a single .cljc
file
the implications are it wouldn鈥檛 respect ClojureScript鈥檚 load order semantics anymore
Yeah I don鈥檛 see any immediate solutions
The implementation of the Instaparse engine is different for CLJ and CLJS, and one of the macros (`defparser`) runs the Instaparse engine at macro-time.
I think this is part of what makes cross-compatible macros so difficult.
@gmercer You could try removing the cljsee
plugin from Instaparse and then lein install
ing to see if that fixes the issue
lumo trending in github(in the clojure language) https://github.com/trending/clojure