Fork me on GitHub
#lumo
<
2017-04-26
>
hlolli00:04:31

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... 馃槙

anmonteiro00:04:04

@hlolli you do have all cljs.test in Lumo

hlolli00:04:24

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.

anmonteiro00:04:30

@hlolli

;; 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.

hlolli00:04:58

easy. Just thought of use-fixtures as you wrote this. But compileing a main test file that triggers the other test is fine.

anmonteiro00:04:58

so that lumo exits with the appropriate exit code

hlolli00:04:12

ah, that would be very useful. Ok, enough material to eat on for next days, thanks.

jonpither16:04:54

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

anmonteiro16:04:13

are you calling lumo.repl/execute directly?

jonpither16:04:54

NODE_PATH="${MACH_HOME}/node_modules" ${MACH_HOME}/node_modules/.bin/lumo -c ${MACH_HOME}/src:${MACH_CLASSPATH} mach/core.cljs $ARGS

anmonteiro16:04:28

certainly seems like you are

jonpither16:04:30

in fact, just doing this from the command line: lumo -c ~/dev/juxt/mach/src mach/core.cljs foo

anmonteiro16:04:01

it takes 1 more arg..

jonpither16:04:07

will confirm

anmonteiro16:04:13

as the last arg

jonpither16:04:59

Great @anmonteiro that fixes it!

anmonteiro16:04:07

just opened that issue so that you don鈥檛 rely on internal APIs

jonpither16:04:03

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 ..?

jonpither16:04:44

tried with --cache and -K, think I'm doing something odd probably

anmonteiro17:04:47

certainly sounds odd

anmonteiro17:04:13

don鈥檛 you see a .cache folder?

jonpither17:04:59

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 {}} '

anmonteiro17:04:20

now you鈥檙e missing -c

jonpither17:04:10

yeah, sorry, wait

jonpither17:04:54

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

jonpither17:04:10

^ without the -k .cache it succeeds

jonpither17:04:24

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

anmonteiro17:04:52

@jonpither I don鈥檛 have any immediate ideas

anmonteiro17:04:00

can you try to come up with a minimal failing case?

jonpither17:04:23

will do - I'll strip down Mach core.cljs

jonpither17:04:58

@anmonteiro it's another issue with Mach, the extra params confuse Mach. Apologies! Will fix

anmonteiro17:04:11

good to know, thanks

jonpither17:04:31

great - caching works, Mach is fast again 馃檪 Thanks.

anmonteiro17:04:09

@jonpither so now you can distribute cached artifacts along with the NPM package and always start Lumo with -c

jonpither17:04:37

gotcha will try that now

anmonteiro17:04:45

and in 1.4+ that鈥檚 not really a problem because Lumo knows how to invalidate the cache: https://github.com/anmonteiro/lumo/commit/ed60f0587688ba686e233a3b89b062a6435497d9

dominicm17:04:45

@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.

anmonteiro17:04:51

@dominicm not related, but I think you should be using #!/usr/bin/env lumo

anmonteiro17:04:55

more portable

anmonteiro17:04:37

my UNIX fu is not very good otherwise so I can鈥檛 really help there

anmonteiro17:04:49

I remember @mhuebert had a similar problem with Planck some time ago

dominicm17:04:47

@anmonteiro Oh I know I should, I was reducing error.

dominicm17:04:49

I've figured it out

dominicm17:04:53

and the results horrify me

dominicm17:04:16

linux shebangs only send one argument.

dominicm17:04:32

No idea what mac behaviour is, but this annoys me. I'm going to *BSD!

dominicm17:04:14

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.

richiardiandrea19:04:18

with a colleague here we were wondering what it would take in order to have a node modules-centric output from the cljs compiler

richiardiandrea19:04:57

dropping the goog.provide and goog.require and make everything scoped (only shareable through export)

richiardiandrea19:04:14

would it be faster on node? don't know until I try 馃槃

anmonteiro21:04:03

@richiardiandrea ClojureScript has been tied to Google Closure since the beginning, that鈥檚 not gonna change

anmonteiro21:04:19

I think what you鈥檙e talking about is so infeasible it shouldn鈥檛 even be considered

richiardiandrea21:04:46

yeah that is what I am trying to understand, if it is feasible and if not why

richiardiandrea21:04:07

and if doable what advantages will it have

richiardiandrea21:04:13

very early stage here 馃槃

richiardiandrea21:04:44

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

anmonteiro21:04:31

there are no .call calls if you compile with :static-fns

anmonteiro21:04:17

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

anmonteiro21:04:35

you may wanna re-evaluate the trade-offs

gmercer21:04:38

I am getting instaparse to work with lumo, it is mostly working with the source files

richiardiandrea21:04:46

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)

richiardiandrea21:04:21

yeah who knows which one is faster without profiling...

gmercer21:04:38

but the build uses cljsee which outputs a .clj alongside the cljc, lumo picks the clj (with java specifics) over the cljc

gmercer21:04:18

is there a flag is change the order, i.e. cljs, cljc, clj ?

anmonteiro21:04:06

@gmercer hrm. do you mean for a macros file?

gmercer21:04:50

just plain code - cljsee allows the engelberts to write in clojure 1.7 and using cljsee makes the jar compatible back to 1.5

gmercer21:04:18

i.e. pre reader macros

anmonteiro21:04:20

@gmercer I still don鈥檛 understand the problem. if you are requireing Instaparse, it should pick .cljs and .cljc files

anmonteiro21:04:41

it鈥檒l only search for .clj files when it鈥檚 looking to load macros

anmonteiro21:04:45

hence my question

gmercer21:04:29

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

anmonteiro21:04:39

@gmercer I see the problem

gmercer21:04:03

sorry for the waffling 馃槂

anmonteiro21:04:19

I don鈥檛 think this is a Lumo problem

gmercer21:04:34

it happens in planck too

anmonteiro21:04:37

instaparse.core requires instaparse.gll

anmonteiro21:04:44

if there is a gll.cljc and a gll.clj file, we think the macros are in the .clj file

anmonteiro21:04:55

so we load that

gmercer21:04:14

`jar tf ~/.m2/repository/instaparse/instaparse/1.4.6-SNAPSHOT/instaparse-1.4.6-SNAPSHOT.jar

gmercer21:04:20

''' jar tf ~/.m2/repository/instaparse/instaparse/1.4.6-SNAPSHOT/instaparse-1.4.6-SNAPSHOT.jar ... instaparse/gll.clj ... instaparse/gll.cljc'''

gmercer21:04:39

where is the decision made ?

anmonteiro21:04:52

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

anmonteiro21:04:32

^ is this what you鈥檙e asking about?

gmercer21:04:31

yes, why does clj win over cljc ?

anmonteiro21:04:51

because it is possible you have cljc for CLJS code and clj for macros code

gmercer21:04:36

so this would hit any users

gmercer21:04:25

but would be fine if it spat out both clj and cljs

gmercer21:04:01

nah, still wouldn't

anmonteiro22:04:21

I think it would work fine with a single .cljc file

gmercer22:04:44

as it does with -c src

gmercer22:04:16

what are the implications if the order was changed ?

anmonteiro22:04:36

the implications are it wouldn鈥檛 respect ClojureScript鈥檚 load order semantics anymore

anmonteiro22:04:49

Yeah I don鈥檛 see any immediate solutions

aengelberg22:04:52

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.

aengelberg22:04:10

I think this is part of what makes cross-compatible macros so difficult.

aengelberg22:04:02

@gmercer You could try removing the cljsee plugin from Instaparse and then lein installing to see if that fixes the issue

stbgz22:04:14

lumo trending in github(in the clojure language) https://github.com/trending/clojure