Fork me on GitHub
#cljs-dev
<
2018-02-14
>
dnolen00:02:22

yeah it was that before, if people have strong opinions about the flags - should speak up sooner rather than later

dnolen00:02:38

this is pretty slick:

dnolen00:02:41

java -cp cljs.jar:src cljs.main -js browser -v -o out/main.js -c foo.core

dnolen00:02:49

java -cp cljs.jar:src cljs.main -js browser -r

dnolen00:02:16

I think that’s it

dnolen00:02:36

we can remove all the scripts from the Quick Start and when Alex Miller gets around to validating the Windows clj tool, I think we can replace the whole Dependencies section of the Quick Start with instructions for deps.edn and drop the Lein & Maven stuff (probably move them elsewhere for reference)

richiardiandrea00:02:48

I like -O just because it reminds me of gcc, but I don't have strong opinions 😄

dnolen00:02:53

@richiardiandrea CLJS-2492, I don’t know about that change

dnolen00:02:01

some sources may have real underscores - we don’t know

dnolen00:02:49

not all sources are CLJS sources, so it’s not safe

dnolen00:02:02

and CLJS sources can have underscores

dnolen00:02:44

was there another issue you wanted me to look at? Or did I already apply that?

dnolen00:02:25

considerably nicer with clj

dnolen00:02:33

clj -m cljs.main -js browser -r

dnolen00:02:40

don’t need to bother with setting src etc.

richiardiandrea00:02:50

@dnolen the thing of CLJS-2492 is that I need a way to sync the two right?

dnolen00:02:10

I just don’t think it’s important

richiardiandrea00:02:19

so either I do it when the source maps are "saved" in :source-maps or before they are consumed

richiardiandrea00:02:45

it seems there is a mismatch in the two when using them from self-host

dnolen00:02:22

I don’t really understand what you are saying

dnolen00:02:28

this is just about reporting right?

dnolen00:02:35

presenting a mapped stacktrace

dnolen00:02:45

if so, it’s a bit lossy but that shouldn’t be a real problem

richiardiandrea00:02:16

yep so what I am saying is that when I get from :source-maps I see the keys of my mapped stuff under something that has _

richiardiandrea00:02:39

so maybe the thing that writes in :source-maps has a problem

richiardiandrea00:02:49

while I was fixing the "reading" side

richiardiandrea00:02:57

needs more investigation

dnolen00:02:58

right I don’t think you want to do that

dnolen00:02:09

just munge if you want to do a lookup

dnolen00:02:23

(munge foo.bar-baz) and you can use that for the lookup

dnolen00:02:45

and leave the source map stuff be

richiardiandrea00:02:51

ok, will try that

richiardiandrea00:02:32

will add comments to CLJS-2492 if I find something else, thanks!

dnolen00:02:40

gotta run, please try out the --compile options if anyone has time

mfikes01:02:18

Cool. The -O matches Planck's similar flag:

-O x, --optimizations x     Closure compiler level applied to source loaded
                                from namespaces: none, whitespace, or simple.

bhauman10:02:09

allowing more than one watch -w path would be nice, but that can be added later without breaking things

bhauman10:02:40

also --init could take namespaces as well and pass them to preloads

mfikes12:02:09

Just thinking out loud (not seriously suggesting this): Given that if you have ClojureScript in deps.edn you can now do things as simply as

clojure -m cljs.main <-m foo.core or other options>
it is tempting to have a cljs variant of clj that does 2 things: 1) Uses a "base" deps.edn that includes a shipping ClojureScript dep (perhaps doing this via automatically supplying an alias?) 2) Instead of specifying clojure.main, specify cljs.main With this, the idea would be that users could still specify a different ClojureScript dep in their own deps.edn if needed, and in the end it would work essentially like clj but be for ClojureScript. All of the above is temptingly close now; that's why pondering it. 🙂

mfikes12:02:57

Then you could of course, do things like cljs -m foo.core

dnolen13:02:40

it’s something to think about yes, but need to stew on it. Overall I think this is a pretty huge step forward for ease of use

dnolen13:02:17

being able to write a one liner to get a CLJS git dep and try something out is really sweet

dnolen13:02:37

@bhauman nice idea about multiple -w, would be trivial to add, we probably want a --preload or -p option. Currently we’re not really overlapping much between --compile and --repl --main options. Probably best to keep it that way.

bhauman13:02:59

makes sense to me 🙂

bhauman13:02:57

@mfikes a cljs tool would need to pass through all the clj args (-Sdeps etc), is that what you are thinking?

bhauman13:02:35

which really just replaces the main arg

mfikes13:02:27

Yes, in other words, replace clojure.main with cljs.main and ensure the ClojureScript dep is available.

mfikes13:02:14

The pattern is about to be:

clj -m cljs.main (whatever you want)
a small step to
cljs (whatever you want)

mfikes13:02:18

We'll get a huge improvement in the Quick Start instructions soon. And if the above were done, they would get one tiny bit simpler.

bhauman13:02:34

can you supply additional deps with the cli tool? this is something I haven't tried

mfikes13:02:08

Yeah, it automatically reads a local deps.edn if present.

mfikes13:02:28

You can also put them right on the command line via -Sdeps

bhauman13:02:59

yeah but it seems hard to inject deps

bhauman13:02:19

unless -Sdeps adds deps to the local supplied edn

mfikes13:02:38

Yes, there is an entire merge-with processing logic it follows

bhauman13:02:08

-Sdeps EDN Deps data to use as the final deps file

mfikes13:02:55

I wonder if "final" there means last in the merge chain

bhauman13:02:17

well I can just try it I guess

bhauman13:02:13

but if it does merge it then that is awesome

mfikes13:02:18

Yeah, confirming in #tools-deps

dnolen13:02:28

@r0man I took at look at your patch, I think you cannot elide orphans like that - otherwise it seems fine, I guess I just missed when I did it originally since all the other support for it is already there.

r0man13:02:32

Hi david, I think you had the same thing in place, but removed it again in this commit: f5cd5f902e96aef3861bb72af483779305e59fd6

r0man13:02:19

Regarding the orphans, why do you think they are needed? With orphans included I got a lot of stuff in my cljs-base that I don't really want. Files on the classpath, like test files. And other thing from a checkouts directory. Really a lot! 🙂

r0man13:02:43

You mentioned yesterday that I reported a problem about orphans some time ago.

dnolen13:02:36

you cannot elide orphans

r0man13:02:39

The problem back then was that the compiler didn't pick up the main entries from the modules. Because I didn't require them. They should of course be added to the build. But anything else not required?

dnolen13:02:54

let’s rewind so we understand why

dnolen13:02:09

if you have orphans you included them in the build somehow

dnolen13:02:24

so go fix that problem, modules just reflects that

dnolen13:02:40

for example you build your project directory (i.e. (build "src" …)) but you have files that are never required by your main ns

dnolen13:02:02

this is fine, they are part of the build

dnolen13:02:22

if you dont use :main these files will appear once you use optimizations

dnolen13:02:23

so my recommendation is to decrease the scope of the patch, and instead fix your build so all these other inputs are not getting sucked in

dnolen13:02:02

we do not randomly load things from classpath as compiler inputs, this is something you have configured

r0man13:02:51

ok, but one more question. yesterday you mentioned that I do need to require files I want to have in my build. so far so good. but do you have an example of an orphan I actually want in my build, even though I don't require it?

dnolen13:02:26

I don’t need an example 🙂

r0man13:02:27

so which are the orphans we are interested in?

dnolen13:02:32

this is how it has worked since the beginning

dnolen13:02:37

and people depend on it

dnolen13:02:09

if you don’t use :main everything under (build source ...) will be in the compiled thing

dnolen13:02:12

requires do not matter

r0man13:02:16

ok, so I remove the orphans patch. any other suggestions for the first one?

thheller13:02:10

FWIW :modules with their :entries are basically a set of :main namespaces so you can definitely remove "orphans" just like :main

dnolen13:02:14

@r0man first patch looks fine - if people complain a lot about the behavior we can go change this later

r0man13:02:00

ok, let me fix my build, and try it out again. I'll report back

bhauman13:02:48

I really like how cljs.main is providing a much clearer understanding of the various configuration values, much, much better than the conflated meaning of :source-paths in cljsbuild which means watch-paths, compile-paths, add-to-classpath

bhauman13:02:41

I'm excited to do a figwheel without figwheel gist

dnolen13:02:30

@bhauman yeah, and for beginners you could probably go a very long way before you ever start writing out compiler options EDN manually

mfikes14:02:32

@r0man I haven't dug into it yet, but there might be a legitimate test failure from the last commit https://travis-ci.org/mfikes/clojurescript/builds/341441134

r0man14:02:22

@mfikes ok, I'll take a look

dnolen15:02:57

@mfikes hrm which one is the test failure?

mfikes15:02:08

I think it is the self-hosted tests

mfikes15:02:25

Specifically script/test-self-parity

dnolen15:02:14

seems strange

dnolen15:02:24

since the last commit didn’t have anything to do w/ self-host

r0man15:02:35

@dnolen I think I forgot a check if modules are used or not

mfikes15:02:46

It seems to be rooted in the fact that

bin/cljsc src/test/self/self_parity "{:optimizations :none :output-to \"builds/out-self-parity/main.js\" :output-dir \"builds/out-self-parity\" :main self-parity.test :target :nodejs}"
terminates quickly without doing anything

r0man15:02:50

I'm working on a fix

dnolen15:02:19

@r0man is it just checking for modules, I can do that here

dnolen15:02:01

oh you’re done 🙂

r0man15:02:02

I also removed the ensure-cljs-base. this is then basically what you had in another commit

dnolen15:02:04

@r0man but don’t we need the ensure-cljs-base?

r0man15:02:00

@dnolen I don't think so. you didn't do this in your original commit. and I think this is already done in ensure-module-opts

dnolen15:02:04

@r0man how will that file get a name?

dnolen15:02:24

that’s what ensure-cljs-base does, set :output-to for base

dnolen15:02:56

@r0man oh right thanks

dnolen15:02:12

yeah we handle it options normalizations

dnolen15:02:16

k cool, thanks!

r0man15:02:19

@dnolen Regarding those orphans again. I was hunting for an orphan called DA39A3E.js (an empty file that breaks my advanced build) the last hour or so. I was looking in all my jar files but couldn't find it. Now that @mfikes pointed out the failing test I was looking into the builds/out-self-parity directory and see files like AEF573C.js and 3FABB9D.js. Do you know what they are doing, and why do they have those funny names?

richiardiandrea15:02:49

@mfikes I will check the tests as the only commit regarding self-host is mine

richiardiandrea15:02:13

Oh ok I am reading the above :)

dnolen15:02:26

@r0man how would an empty file break your build?

r0man15:02:18

@dnolen not sure, investigating. was just wondering where this file comes from

dnolen15:02:32

if we have some compiler input that doesn’t have a name

dnolen15:02:42

if you passed a string, or a form, then we generate a random name for that

dnolen15:02:37

@r0man searching util/content-sha in cljs.closure would give you some leads

richiardiandrea15:02:52

I like the new cli stuff a lot a lot, just one thing that can be made easier for editors would be to add the .edn extension to the option file so that in case you need manual editing you get coloring. Minor I know, but advanced user will manually change the final 😸

richiardiandrea15:02:10

Also I like the idea of having deps.edn + other conf file for the tool you use. I am using serverless-cljs-plugin now and I also have a serverless-lumo.edn in there for lumo compiler options

bhauman15:02:24

I'm going to be testing a figwheel-sidecar.repl/repl-env

bhauman15:02:40

to see how it works

dnolen15:02:17

@bhauman something to think about

dnolen15:02:31

cljs.repl.foo is the pattern

dnolen15:02:39

if cljs.repl.figwheel this will just work

bhauman15:02:41

figwheel.repl.node

bhauman15:02:58

now I gotcha

dnolen15:02:25

ah ok here’s the issue

dnolen15:02:37

we use -js to set the environment but also set the REPL

dnolen15:02:49

but if we sort that out then

dnolen15:02:02

you would just need to have Figwheel on your classpath

dnolen15:02:15

with cljs.repl.figwheel ns existing

dnolen15:02:24

and then people can use all the command line stuff

bhauman15:02:06

perfect, but it's not quite working yet because -js is a tad complected?

dnolen15:02:19

well not really 🙂

dnolen15:02:25

we don’t get target from that anyway

dnolen15:02:31

we get it from the REPL

dnolen15:02:41

but in your case you want that to be separate

dnolen15:02:31

but how does figwheel work here

dnolen15:02:43

I guess you just wrote all your own node & browser support right?

bhauman15:02:56

its one env fits all

bhauman15:02:08

it doesn't have to stay that way

bhauman15:02:32

in other words the target is de-coupled from the env

dnolen15:02:47

yeah just thinking about good option name

dnolen15:02:26

well target is easy

dnolen15:02:02

I guess -r could take the REPL name

dnolen15:02:19

if we can find it it’s a REPL, if we cannot it’s a command line arg

dnolen15:02:06

hrm but that’s a bit weird …

bhauman15:02:10

does that obviate the -js ?

dnolen15:02:15

I don’t want to mess w/ the clojure.main pattern here

bhauman15:02:22

yeah I agree

dnolen15:02:38

yes -js would go away

bhauman15:02:40

what about -repl-env -target

bhauman16:02:23

I'm going to keep saying "this is awesome" a lot

bhauman16:02:40

bc this is awesome

bhauman16:02:33

refreshing and rebuilding

dnolen16:02:50

@bhauman -js is gone, now -re

dnolen16:02:17

@bhauman yeah just for making it easier to try different REPLs this is huge! 🙂

dnolen16:02:33

zero config, just need the dep

bhauman16:02:23

I'm super digging it

bhauman16:02:01

OK is --main required?

bhauman16:02:19

clj -m cljs.main -t nashorn -re figwheel

bhauman16:02:51

looks like its failing on script-opt

bhauman16:02:07

clj -m cljs.main -t nashorn -r

bhauman16:02:06

so cljs.main doesn't default to a repl when it has no main options args?

bhauman16:02:16

oh wait maybe I'n not up to date

bhauman16:02:27

and its interpreting -re as a script

bhauman16:02:02

Yep that was it

bhauman16:02:29

OK it does seem that this is different than clojure.main in that you have to explicitly say you want a repl

bhauman16:02:39

in this case clj -m cljs.main -t nashorn it just bails when my expectation from clojure.main is that it would start a repl

bhauman16:02:03

oops my bad

bhauman16:02:16

clj -m cljs.main -re node creates a repl

bhauman16:02:43

clj -m cljs.main -re node -t node exits without starting a repl

dnolen17:02:05

Well it’s actually like Clojure in a sense

dnolen17:02:12

If no opts then REPL

dnolen17:02:26

If any opts main unless -r

dnolen17:02:36

You can see this if you examine the logic in clojure.main

dnolen17:02:06

A couple thoughts - other REPLs probably want to arg process - need a standard way to print docs for those

dnolen17:02:59

We could continue the pattern of getting those from repl-env instance?

Alex Miller (Clojure team)17:02:11

btw, with the new main opts support in clj, you can create an alias :aliases {:cljs {:main-opts ["-m" "cljs.main"]}} in your ~/.clojure/deps.edn so it’s available on all projects, then use it and append extra opts at the command line clj -A:cljs -t nashorn

dnolen17:02:11

:the_horns:

r0man17:02:59

David, so this was breaking my advanced build: https://dev.clojure.org/jira/browse/CLJS-2522 not the empty file

bhauman17:02:57

@dnolen what are you getting from the repl-env right now?

dnolen17:02:14

:output-dir, :target, :browser-repl - vai -repl-options

bhauman17:02:44

and your suggesting supplying arg modifications? hmmm this could be a function that operates on the final args?

bhauman17:02:55

or a var name

dnolen17:02:15

basically put the current dispatch values into two atoms - one for inits the other for mains

dnolen17:02:09

you can then (add-init-opt! ...) or (add-main-opt! ...) from your REPL source

dnolen17:02:26

this way you can get the info you need, but you can’t really muck with the semantics

bhauman17:02:34

oh that works

dnolen17:02:05

opt should be set of matching keys, dispatch fn, docstring

dnolen17:02:15

then we can print -h generically for all REPLs

bhauman17:02:58

that solves my current build-id problem

bhauman18:02:33

oh my god, I got it to work

bhauman18:02:46

clj -m cljs.main -re figwheel

bhauman18:02:59

it worked and it started a repl connected to figwheel!

bhauman18:02:13

and now for --fw-build? and --fw-config?

bhauman18:02:01

and after that I will look at defaults, and see if I can align with the cljs defaults

dnolen18:02:55

I’m working on something that’s pretty flexible, off to Clojure SYNC but this is a good plane hack :)

bhauman18:02:25

have fun in New Orleans!!

dnolen18:02:39

@bhauman hrm besides arg processing it seems like you also need a way to take over main or compile cases

dnolen18:02:22

That is, replace the bottom behavior

dnolen19:02:43

@r0man your patch probably needs more explanation, I’m curious why this specifically is needed in the modules case

bhauman19:02:10

@dnolen I believe you are correct, am I right in thinking that that is better served by composing over cljs.main with a figwheel.main?

dnolen19:02:37

I don’t see why

dnolen19:02:49

repl-options can return ::main and ::compile

bhauman19:02:04

well that works then

bhauman19:02:09

i need to read all the code

dnolen19:02:58

@bhauman yeah basically you really want to avoid recreating all this behavior

dnolen19:02:13

you just want to inject your own things where it’s important

dnolen19:02:40

@bhauman checkout master, if REPL options contains :cljs.cli/compile or :cljs.cli/main fns those will take over the default

dnolen19:02:53

you can ignore the command line option handling stuff for now that, still underway

r0man19:02:20

@dnolen write-javascript should return something that implements IJavaScript, right? The JavaScriptFile record does this, a plain map not.

r0man19:02:35

And there are cases this function returns a map at the moment.

r0man19:02:32

oh, sorry. a map does implement this indeed.

r0man19:02:44

it's just that javascript-name name is not defined for maps.

r0man19:02:41

so an alternative would be to add a javascript-name method for map maybe?

dnolen19:02:02

I think so, the narrower the scope of the change, the better

r0man19:02:38

@dnolen can you explain in which cases which of those types are used? I think I got a bit confused by this.

dnolen19:02:49

no it’s a mess

r0man19:02:56

I thought JavaScriptFile is always passed around

r0man19:02:06

when there is a file

dnolen19:02:07

the whole deftype thing is unnecesary, we’d rather it was maps everywhere

dnolen19:02:39

so what you’re observing is the slow transition away from JSFile

r0man19:02:01

ok, thanks. so I'll add a multimethod for clojure.lang.IPersistentMap

dnolen19:02:31

that should be ok, leave a comment in the patch about why this was done

r0man19:02:51

@dnolen I think this would also mean I also need to define js-source-file then for maps. that's the next thing I get an exception.

r0man19:02:01

and I think since I can't define a multimethod on clojure.lang.IPersistentMap I need to define them on both PersistentArrayMap and PersistentHashMap, right?

dnolen20:02:51

@r0man I think we need to backtrack

dnolen20:02:09

where in module processing is this actually failing - I thought I handled a similar problem when I did this the first time?

dnolen20:02:09

@r0man how is that not caught by the first line of the function?

dnolen20:02:14

see the map over sources there?

dnolen20:02:54

or rather why can’t you fix the problematic case there?

dnolen20:02:16

I want to push the JSFile goofiness to the end of everything

dnolen20:02:22

so it’s easier to rip it out in the future

r0man20:02:29

well, when I looked at the class of the sources that are passed to build-modules, all of them where JavaScriptFile. just 2 of them not, which were foreign deps I think.

r0man20:02:50

so you think we should convert all maps at the top of the function to javascript files?

dnolen20:02:17

I don’t see why it would be a problem? it won’t work otherwise

dnolen20:02:48

my only desire here is that we don’t go mucking around with the pipeline

dnolen20:02:06

it’s done the way it is for a reason, will get to cleaning it up eventually

r0man20:02:23

I don't mind. I just thought passing javascript file types around is the correct approach, and the 2 cases that broke were actully bugs.

r0man20:02:38

So, I'm changing it in that function ....

dnolen20:02:05

yeah, nope

dnolen20:02:08

JSFile is the wrong way

dnolen20:02:16

plain data is what we want in the compiler

r0man21:02:54

should I add an extra check for instance? JavaScriptFile and don't convert them (since records are also map?s) as well?

bhauman23:02:54

I got it working with figwheel and rebel readline, as rebel readline is a :read repl opt

dnolen23:02:36

@bhauman about to drop a big enhancement - the surface is the same - but you can add options to hearts delight and take over --compile & --main

dnolen23:02:04

most of my flight was just formatting the docstring 😛

bhauman23:02:52

well that will do it

dnolen23:02:01

@bhauman might need further tweaking but it’s pretty extreme on the flexibility side

dnolen23:02:05

you can define your own groups

dnolen23:02:11

you can override flags etc. etc.

dnolen23:02:53

I must say this is really slick 🙂

dnolen23:02:02

way faster to try stuff then mucking around with scripts

dnolen23:02:09

for bug reporting alone this is a revolution!