Clojurians
#cljs-dev
<
2018-02-15
>

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

dnolen00:02:09

so fun java -cp cljs.jar:src cljs.main -e "(def x 1)" -re browser -r

dnolen00:02:29

@bhauman @mfikes all that work from like 4 years ago paying off :slightly_smiling_face:

dnolen00:02:53

oh maybe it was only 3 :slightly_smiling_face:

bhauman00:02:05

good stuff

dnolen00:02:31

@bhauman well I’m going to see New Orleans now, keep me posted if this is working for you or if you have some other ideas

bhauman00:02:47

you got it, have fun!

richiardiandrea01:02:46

@dnolen for when you have time I would to ask you one thing. I see here https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/js.cljs#L176 that the code that assoc-in uses name. For an generic statement/expression though, name is usually not really significant and while we could make document that says that name has to be munged because it will end up in :source-maps, I see that you are already doing it the same in https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/js.cljs#L161 I was then wondering whether the code should use that smn for the key in :source-maps. Ready for patching if necessary.

richiardiandrea01:02:58

the fact that name is used for source maps needs to be documented nonetheless

richiardiandrea02:02:44

Uhm I wonder if I actually need to disable source maps when evaluating expressions at the REPL and if js.cljs is taking care of updating the right thing only when it "sees" an ns form

bhauman22:02:02

I was missing that piece

bhauman22:02:15

I was trying to do it all in one command

bhauman22:02:37

compile and start the repl

bhauman22:02:19

that of course would be a nice to have, as you could run the watcher and share the env/compiler with the repl ala figwheel

dnolen22:02:30

right, but -c and -r are both main dispatches, so terminal

dnolen22:02:23

kind of difficult to reconcile that without changing clojure.main semantics - and -c doesn’t make much sense as a init option

dnolen22:02:54

maybe +r or something like that for an init?

dnolen22:02:24

this is also why I did the groups, so you can group logical flags together

dnolen22:02:49

we could do more argument normalization, i.e. convert -r to +r if -c is the main

bhauman23:02:39

but it seems to me you could have multiple compiles and it makes sense?

bhauman23:02:53

its even desirable

bhauman23:02:24

unless -c also implies a :main cljs build option

bhauman23:02:52

hmm what about allowing multiple main options (i.e -c and -r) in this case as it is a very sensible case

bhauman23:02:41

you could rewrite it into the +r form before processing

bhauman23:02:18

it just feels like it should work, ya know?

bhauman23:02:37

especially in cljs

dnolen23:02:33

Adding a new option is easy, and rewriting would also be easy

dnolen23:02:17

@bhauman actually allowing -r to be non-terminal really is a problem, since that would prevent a user from doing something intentional

dnolen23:02:43

clj -r -c 1 -a 2 which is pass everything after -r to the REPL

dnolen23:02:09

so transforming is a no go

dnolen23:02:25

explicit can do, I don’t really like +r

bhauman23:02:59

well I'd like it to be after the -c option. explicit?

bhauman23:02:21

explicit is +r

bhauman23:02:28

but needs a better name

dnolen23:02:31

oh we could check it in the -c case I guess?

bhauman23:02:43

yeah that's what I think would work

dnolen23:02:07

yes this is fine as long as -c ns is a requirement

bhauman23:02:09

yes, just bc its such a strong win to have a watched compile and repl share the compliler env

bhauman23:02:41

that would be fantastic

dnolen23:02:43

I guess I can’t see a case where we should allow anything but -r right after a -c?

dnolen23:02:57

and anything after -r will be passed as extra args

bhauman23:02:02

no this is just a special case

dnolen23:02:14

k this is easy

bhauman23:02:28

I can't wait to try it :slightly_smiling_face: