Fork me on GitHub
#boot
<
2015-08-11
>
alandipert00:08:53

i can't see why not but i haven't tried it myself

devn01:08:43

Hello friends and uncles.

micha02:08:21

hey @devn!

devn02:08:58

what's upppppp @micha

alandipert03:08:24

how about supporting a URL scheme for bringing up a repl with a certain env

alandipert03:08:41

i suppose sharing a URL to a boot script is basically the same

martinklepsch08:08:37

@juhoteperi: any reason the docs for cljs.edn have been removed from the readme?

juhoteperi08:08:14

there was a reason but it was pretty much reverted

juhoteperi08:08:22

@martinklepsch: Docs restored

onetom08:08:56

@juhoteperi: should we use your boot-less package to replace the hoplon5 *.inc.css combination functionality?

juhoteperi10:08:06

@martinklepsch: That’s why it doesn’t mention it would be special for boot-cljs

martinklepsch10:08:56

@juhoteperi: ah ok. Thought it might be a leftover from when CLJS didn’t handle this

juhoteperi10:08:57

@onetom: Sure you could use that

onetom10:08:10

@juhoteperi: but is it the recommended way? Is there a sass/scss compiler too which is integrated w boot? I know about boot-garden but that seemed something totally different from CSS to me

juhoteperi10:08:16

@onetom: Recommended by who? I can recommend it, sure. Does that matter anything? I don’t know. 😄

onetom10:08:29

@juhoteperi: by the clojure community. since u implemented such a thing u probably know similar tools, which makes you an expert on the topic transitively 😉

juhoteperi10:08:35

It depends on your needs and what you want to use. If you want to use LESS, it’s the best option. If you want to just use CSS and concat files then no.

juhoteperi10:08:23

Because I just use my own tool I haven’t looked into other options too much

juhoteperi10:08:08

I think e.g. boot-sass can’t load imports from classpath.

pandeiro12:08:49

@juhoteperi: boot-less (and lein-less) are imo reason alone to choose less -- they are perfect

pandeiro12:08:37

re-posted from IRC: what might be causing cljs.test/run-tests to return stale results when used with boot-cljs?

juhoteperi12:08:29

@pandeiro: In repl or file?

pandeiro12:08:43

@juhoteperi: in the browser, so: file

pandeiro12:08:03

i've checked that the test ns in question is getting recompiled...

pandeiro12:08:23

my guess is maybe the ns that is calling cljs.test/run-tests is not getting re-compiled...

juhoteperi12:08:23

Is it being reloaded?

pandeiro12:08:32

i am refreshing the browser

pandeiro12:08:55

i think cljs.test/run-tests is a macro...

juhoteperi12:08:57

you can use :compiler-options {:verbose true} to check what ns are being compiled

juhoteperi12:08:01

shouldn’t matter

pandeiro12:08:06

let me do that

pandeiro12:08:16

i also have a minimal repro example

juhoteperi12:08:26

the namespace which does run-tests requires the test namespaces?

pandeiro12:08:46

deraen: it does yes

pandeiro12:08:07

in the case of my app, that ns' src is being generated dynamically from a boot task that takes ns args for which to test

pandeiro12:08:17

but in my minimal repro, i am doing it statically

juhoteperi12:08:42

:recompile-dependants should then take care of recompiling run-tests ns

pandeiro12:08:08

is that a compiler option?

juhoteperi12:08:14

Yeah and it defaults to true

pandeiro12:08:40

@juhoteperi: verbose output shows both run-tests ns and tests ns being re-compiled

pandeiro12:08:53

but the results are the same: stale output from run-tests

pandeiro12:08:15

interestingly, if i touch the run-tests ns, the test output is fresh again...

pandeiro12:08:32

...and subsequent compiles are staying fresh, even without touching the run-tests ns again

bensu12:08:51

@pandeiro: if you are running in a browser, might it be the browser caching?

bensu12:08:11

(btw thanks for the Docker images simple_smile )

pandeiro12:08:37

@bensu: i'll check with a hard refresh

pandeiro13:08:50

yep, still reproducing with hard refresh

micha13:08:51

@pandeiro: maybe it's like with clj test, where the test ns adds meta to other namespaces or something?

micha13:08:09

so when you touch the test ns it applies new meta to the namespaces it's testing

pandeiro13:08:52

@micha: in a couple secs I'll have the simple repro on github

pandeiro13:08:04

I have a boot version and a cljs quick start version

pandeiro13:08:14

with quick start i can't reproduce the issue so far

pandeiro13:08:56

there are instructions in the README for how to reproduce

juhoteperi13:08:53

I’ll check it later

pandeiro13:08:24

@juhoteperi: appreciate it

micha16:08:41

@juhoteperi: is it cool if i push 1.7.48-SNAPSHOT to clojars?

aengelberg18:08:59

What would be the best way to write a boot task that builds my clojurescript test cases AND runs them?

aengelberg18:08:24

i.e. it will need to call node or whatever engine I'm using

martinklepsch18:08:42

@aengelberg: have you seen @crisptrutski’s boot-cljs-test?

aengelberg18:08:58

Thanks, I'll try that

martinklepsch18:08:24

@aengelberg: if you encounter any issues, please file them or ping chris or me here.

pandeiro18:08:50

@martinklepsch: the README has the artifact name wrong just fyi

pandeiro18:08:24

i'm doing something similar with a project, wrapping the test prep and the test execution... i'll have to try this lib to see if it irons out some of the kinks i've hit

aengelberg18:08:15

Using the "node" env doesn't work for me when only using the run-cljs-tests task, because doo is complaining about env attributes it can't see

pandeiro19:08:52

@martinklepsch: @crisptrutski - should the 'simple way' of using boot-cljs-test work in combination with other compilations now that boot-cljs supports multiple cljs tasks?

martinklepsch19:08:20

yes, that’s on the roadmap

crisptrutski19:08:23

yeah, i was waiting on that release

crisptrutski19:08:36

will be in 0.1.0, should be out soon

crisptrutski19:08:47

hmm, or perhaps i should cut before changing this?

pandeiro19:08:58

I'm reading through the source now, curious how you're doing it

crisptrutski19:08:22

very similar to the tasks you and myguidingstar wrote

pandeiro19:08:25

@crisptrutski: you haven't used this for CI tests by any chance, have you?

crisptrutski19:08:31

basically combined your tricks + bensu’s doo

crisptrutski19:08:04

don’t think so, at least not running any cljs projects through ci at the moment

crisptrutski19:08:57

just the return code to worry about right?

pandeiro19:08:31

@crisptrutski: yeah basically... i've hit something really weird when running code like this on circleci

pandeiro19:08:50

where the boot process just hangs during or after cljs compilation

pandeiro19:08:02

it happens only every 2 out of 3 times simple_smile

pandeiro19:08:11

once every three times, it works great!

crisptrutski19:08:31

well, worth adding an example project with a circle config to this repo i guess

pandeiro19:08:57

that's a good idea, i can help if you want

crisptrutski19:08:02

hands welcome simple_smile

pandeiro19:08:34

the even weirder part of my particular case is that i only hit this when using both boot-test and cljs-test

pandeiro19:08:42

using either by itself, the tests run fine

crisptrutski19:08:25

oh, i think i’ve seen that too

crisptrutski19:08:01

i wrote it off to having another boot-cljs task in the chain

crisptrutski19:08:06

but didn’t check

pandeiro19:08:05

@crisptrutski: did it look anything like this - http://sprunge.us/HCVj ?

martinklepsch19:08:45

We will still need two cljs compilers for dev + test simultaneously right?

micha19:08:34

martinklepsch: you should be able to have multiple cljs.edn files with different compiler options in them...in theory

micha19:08:55

each one gets its own pod and cljs compiler instance now

martinklepsch19:08:16

@micha: right. probably the test task should clone one, modify it and then build the cloned as well

micha19:08:33

sounds pretty sweet

martinklepsch19:08:48

but that still requires a separate build. We could not test the very same build that we made for development

micha19:08:49

i like the sound of that, tasks figuring things out and just doing them

martinklepsch19:08:58

(which maybe is also not something we want)

crisptrutski19:08:02

@pandeiro: no, just boot hung after running all suites correctly

crisptrutski19:08:14

also i’m guessing the exit codes don’t “compose"

crisptrutski19:08:39

@martinklepsch: doo needs to be in the build with its current design, so separate to dev makes sense to me

martinklepsch19:08:32

@micha: I’ve added a more minimal repro to that StreamClosed issue: https://github.com/boot-clj/boot/issues/270#issuecomment-129807599

martinklepsch19:08:55

also potentially we don’t want things like reload or repl in the tested build right?

pandeiro19:08:14

@micha: re: the different .cljs.edn files - there was some reason for boot-cljs to switch from that to individual (cljs ...) task invocations, right? do you remember, specifically?

juhoteperi19:08:33

@pandeiro: It was reverted

pandeiro19:08:43

@martinklepsch: ideally you'd want to be able leave out reload and any other namespaces you don't want to load

pandeiro19:08:16

@juhoteperi: the 'one task, many *.cljs.edn' model is still how it is gonna work then?

juhoteperi19:08:33

@pandeiro: Reason was to have isolated environments (output dir and pod) for each build, but alternative implementation was chosen

crisptrutski19:08:35

don’t see the point in compiling code not directly under test into tested js in general

juhoteperi19:08:39

@pandeiro: Yes

martinklepsch19:08:40

@crisptrutski: @pandeiro the test task could probably have some :filter-require & :filter-init-fns option with sane defaults

juhoteperi19:08:11

@pandeiro: I'll still as some kind of filter parameter for boot-cljs before next release

pandeiro19:08:42

no i think you just create the test ns you want, with just the requires you want, and you give that as the param to (test-cljs :namespaces #{...})

crisptrutski19:08:20

so we’re generating the test ns for this plugin, so that the doo wrapping is involved

martinklepsch19:08:23

@juhoteperi: I’m confused now. 😂 What change exactly was reverted?

crisptrutski19:08:39

could look at a less invasive mechanism for doo, or modifying the runner ns though

juhoteperi19:08:42

@martinklepsch: One cljs task per .cljs.edn

martinklepsch19:08:55

that’s no longer the case?

juhoteperi19:08:28

@martinklepsch: It's back to one cljs task taking care of all .cljs.edn files

crisptrutski19:08:47

why can id not be a set?

martinklepsch19:08:26

so how can I set different optimizations per build?

pandeiro19:08:29

what was the need for id, specifically? the filename itself is not unique enough?

crisptrutski19:08:43

@pandeiro: it’s actually useful right here to do focused builds

martinklepsch19:08:46

@pandeiro: id = thing before .cljs.edn

juhoteperi19:08:48

@crisptrutski: Boot-cljs? No, not currently, but it will be, I think

juhoteperi19:08:05

Id is currently used to select only one .cljs.edn file

pandeiro19:08:14

ah so there's no new :id key in *.cljs.edn ?

crisptrutski19:08:19

@juhoteperi: what is behaviour for id that isn’t found? generate a default edn?

pandeiro19:08:31

ah to filter them, ok

juhoteperi19:08:35

@pandeiro: id is the name of .cljs.edn file

juhoteperi19:08:46

foo.cljs.edn -> :id foo

micha19:08:01

ids still work, right?

pandeiro19:08:03

and if you don't include :id, then it builds all of them

juhoteperi19:08:15

@micha: Yes, it's only possible to select one

martinklepsch19:08:35

and that’s intended to stay, yes?

pandeiro19:08:49

i agree w/ @crisptrutski that a #{} also makes sense

martinklepsch19:08:58

I found it quite handy when needing to make multiple builds with different optimization settings

pandeiro19:08:15

@martinklepsch: that stuff goes in :compiler-options of the .cljs.edn file? e.g. :optimizations :none ?

crisptrutski19:08:19

@martinklepsch @pandeiro back to talking about custom runner namespaces, or filtering on namespaces

micha19:08:31

so is the problem that you want to do 2 things: * live version for development, and * test version to run cljs tests on

micha19:08:36

is that correct?

martinklepsch19:08:43

@pandeiro: then I can’t change it easily as part of different builds (prod vs. dev)

crisptrutski19:08:50

i was thinking just filtering on test namespaces as entry points

pandeiro19:08:18

@martinklepsch: dev and prod were always just solved by different deftasks for me...

pandeiro19:08:39

@micha: yeah dev and test1 ... testn builds

pandeiro19:08:09

i'd like to be able to run those on a watch and run them adhoc from the repl

crisptrutski19:08:58

should #137 not also be #{str}?

juhoteperi19:08:54

If some one can think better name for the option, I'll listen 😄

pandeiro19:08:50

@juhoteperi: i thought too id vs ids -- would :ids still be able to take a single string?

juhoteperi19:08:10

pandeiro: Just wrap the string in set

crisptrutski19:08:20

the functional interface is just a function

pandeiro19:08:28

yeah sure, and maybe display that in error if person tries

pandeiro19:08:53

(or maybe boot already shows that if the arg type doesn't match)

juhoteperi19:08:03

Yes, boot already takes care of that

pandeiro19:08:28

and then to get boot-reload out, there would need to be a special :filter param?

pandeiro19:08:46

or could boot-reload itself not specify a build id?

juhoteperi19:08:11

boot-reload snapshot probably has :id option already. It's quite useful to be able filter out e.g. node build there.

pandeiro19:08:29

you probably only want boot-reload on one build usually i imagine

pandeiro19:08:01

that is great, so with that you can still just (cljs ...) compile everything without specifying :ids

juhoteperi19:08:02

No reason to limit it only that case, I'm thinking all cljs tooling should use same option

pandeiro19:08:10

yeah sure, i agree

pandeiro19:08:35

so boot-reload should also maybe take :ids #{} ?

pandeiro19:08:03

starts to feel like a uniform interface simple_smile

juhoteperi19:08:12

Well, infact it already does just that

juhoteperi19:08:47

@martinklepsch was clairvoyant and saw what boot-cljs would do before we implemented it

pandeiro19:08:23

@martinklepsch: look into the future and tell me when @juhoteperi will cut boot-cljs 1.7.48 would you?

juhoteperi19:08:06

I'm thinking it'll happen soon

pandeiro19:08:34

you still want to add the :filter thing?

juhoteperi19:08:50

@pandeiro: It's availbe as :ids option now

pandeiro19:08:14

in boot-reload you mean?

juhoteperi19:08:21

@pandeiro: Yes

pandeiro19:08:35

right, i was just wondering then what else you wanted to include before 1.7.48 then?

juhoteperi19:08:12

I originally wanted to fix output dependency graph stuff but as dnolen is taking 2 week off proper fix will take some time

pandeiro19:08:13

(:filter would be on the boot-cljs side, to remove stuff by regex or something -- not something i'm asking for btw, the boot-reload thing solves the problem)

pandeiro19:08:42

@juhoteperi: any link to that?

pandeiro19:08:01

could that be related to my cljs.test issue at all?

juhoteperi19:08:19

I don't think so. It only affects boot-reload.

pandeiro19:08:49

yeah no doesn't seem like it

juhoteperi19:08:17

And it should work perfectly for cljs namespaces, current implementation just is a bit limited with foreign-deps. And it's implemented in boot-cljs and we should instead use cljs api.

pandeiro19:08:58

@juhoteperi: right, cool. and dnolen is up for it? or you would try to submit a patch to cljs?

pandeiro19:08:18

i'm wondering if i should already create an issue or wait til someone else reproduces this https://github.com/pandeiro/cljs-test-issue ?

juhoteperi19:08:29

@pandeiro: Yes, he agrees it's good feature but wanted an proposal about implementation before patch

pandeiro19:08:21

@juhoteperi: cool, i agree it'd be great to have that dependably (for those cases when you want to debug js libs)

juhoteperi19:08:16

@pandeiro: quick start version works for me, 2 tests ran after the change

juhoteperi19:08:43

Ah right, it's supposed to work but doesn't work with boot

pandeiro19:08:12

@juhoteperi: did the boot one work for you?

pandeiro19:08:10

it is very non-deterministic; it will start to work after certain combinations of file touches, changes, etc

juhoteperi19:08:24

@pandeiro: Nope.

juhoteperi19:08:28

Clearly a bug with boot-cljs

pandeiro19:08:31

but if you follow the directions exactly as written, for me it never works that first time

pandeiro19:08:43

@juhoteperi: alright i'll issue it then? and start trying to dig in

pleasetrythisathome19:08:00

hey has anyone ever had a problem with protocols not being loaded in the repl after it’s first started?

pleasetrythisathome19:08:26

in my component systems, sometimes components error that another component doesn’t satisfy a protocol, which is clearly does.

pleasetrythisathome19:08:43

going to the component file that implements said protocols and saving it solves the issue

juhoteperi19:08:18

@pandeiro: Something to do with our shim namespace, using :init-fns in cljs.edn can be used as workaround

martinklepsch19:08:20

@juhoteperi: did you push a new snapshot?

juhoteperi19:08:20

@martinklepsch: Nope

juhoteperi20:08:11

Now I really have to eat 😄

martinklepsch20:08:59

@juhoteperi: enjoy!

bensu20:08:14

@pleasetrythisathome: extending protocols to records/components in different files often leads to that problem. when you reload, you reload only the file where the record was defined and not where it was extended. then, the refreshed record doesn't know about the extend part until you go there and reload it

pleasetrythisathome20:08:12

@bensu that makes sense. in my case i’m defining protocols in one file. and then defining records that implement protocols in their definitions in another file. does the same problem apply? seems like if the record file is reloaded it should know what protocols it implements

bensu20:08:57

@pleasetrythisathome: I'm not sure. I don't know how redefining a protocol works, but I'll guess that in the end it is the same problem. the record that remains loaded is pointing to the old definition of the protocol, which might not be the same thing as the new one

bensu20:08:44

my only solution to this is to use the reloaded workflow and reload every namespaces in those cases

pleasetrythisathome20:08:36

i do use the reloaded workflow 😞

pleasetrythisathome20:08:50

it looks to me that all the relevant namespaces are being reloaded

pleasetrythisathome20:08:02

i’ve been thinking its a dependency graph problem

pleasetrythisathome20:08:13

that the protocols are somehow loaded after the record files

bensu20:08:19

I don't have much insights... one last thing is that if you have introduced a circular dependency during refactoring, you won't notice in the REPL and might get strange effects like this one. if you haven't done it already, try running the code from clean state.

pleasetrythisathome20:08:35

yea circular dependency is a good thing to check

crisptrutski21:08:28

@martinklepsch: @juhoteperi @pandeiro boot-cljs-test is out with latest boot-cljs

crisptrutski21:08:39

0.2.0-snapshot

crisptrutski21:08:59

feedback and testing really welcome

martinklepsch21:08:04

@juhoteperi: When modifying :asset-path in a .cljs.edn file should I expect this to be picked up in a watch cycle?

juhoteperi21:08:13

@martinklepsch: Chaging compiler options probably doesn't work too well without restarting the process

micha21:08:57

we could easily detect this with fileset-diff and rerun make-compiler when cljs.edn files change

micha21:08:45

that would create a new pod etc

martinklepsch21:08:31

I think it worked before actually — could that be?

crisptrutski21:08:55

@juhoteperi: having trouble passing :main option to new boot-cljs task

juhoteperi21:08:12

@crisptrutski: use :require option in .cljs.edn

crisptrutski21:08:28

@juhoteperi: reason not supporting it via :compiler-options anymore?

crisptrutski21:08:31

my use case is actually wanting the default-main edn, but with a specified main

juhoteperi21:08:06

Probably partially unintended consequence of changing shim ns logic

crisptrutski21:08:34

i’m trying to avoid duplicating default-main in my own code to work around this

juhoteperi21:08:46

If you set :main option manually :require and :init-fns are completely ignored

juhoteperi21:08:58

though if you don't use cljs.edn that doesn't matter

crisptrutski21:08:17

perhaps warning if file exists and option is set?

juhoteperi21:08:04

Not that simple as the cljs.edn exists always when shim ns is being generated, as it's created first if it doesn't exist

crisptrutski21:08:22

i think this is actually a clobbering issue

crisptrutski21:08:42

the merge in wrap/compiler-options

crisptrutski21:08:10

main has {:compiler-options {:main nil}} in my case

juhoteperi21:08:34

We could probably allow setting any options manually with warning if they are set

crisptrutski21:08:06

like that output-to was removed - was actually using that but it’s quite abusive

crisptrutski21:08:14

warning for that would be useful for migration though

crisptrutski21:08:34

context’s {:opts {:main ns}, :main {:compiler-options {:main ..}}} shape is quite confusing

crisptrutski21:08:14

crashes my mainframe 😖

juhoteperi22:08:46

(warn "You are manually overwriting Boot-cljs set option for %s, I hope you know what you are doing!" k)

crisptrutski22:08:16

yeah, i’m trying out something like that

crisptrutski22:08:56

feel that [:main :output-dir :output-to] are in distinctly increasing levels of abuse though simple_smile