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

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

dnolen00:02:51

Bunch of fun things to try with master. All the command line stuff and the Nashorn target. I just confirmed that core.async can be tested via nashorn

mfikes01:02:05

Nice! Better than having to open the browser and check the console

bhauman03:02:51

oh sweet the main and cli stuff is awesome!

juhoteperi06:02:48

I think the require :default for ES6 modules is desired, but I'm not sure if the implementation in my patch makes sense

juhoteperi06:02:30

For requires with /, maybe it just makes sense to force everyone to use strings, like now, and just skip the change

kommen09:02:09

I’d appreciate an opinion if my patch https://dev.clojure.org/jira/browse/CLJS-2501 is reasonable

juhoteperi09:02:08

@kommen Looks good to me

dnolen11:02:26

@kommen applied

dnolen12:02:13

@juhoteperi 2346 still doesn’t seem all that desirable to me

dnolen12:02:54

@juhoteperi I don’t really like the approach suggested by 2376, I left a comment

dnolen12:02:46

@r0man your problem seems a bit strange, if you had something minimal to look at that would be easier to sort out

juhoteperi12:02:53

(:require ["material-ui/RaisedButton" :refer [RaisedButton]]) what if the module exports both default and RaisedButton property?

juhoteperi12:02:48

:refer [default] already works, or :as alias and alias/default

juhoteperi12:02:30

I don't see how we could decide that :refer [Something] should refer to default property

dnolen12:02:25

another big change from yesterday’s Nashorn work is that we just try to establish printing automatically now for environments with console and for the Nashorn target.

dnolen12:02:47

I don’t think this should affect REPLs or whatever since those things override after cljs.core loads

dnolen12:02:18

If some thing exports default and a RaisedButton property how do you distinguish that in JavaScript?

dnolen12:02:50

@juhoteperi determining that :refer should be default doesn’t seem difficult to me.

dnolen12:02:44

ah ok, I’m still fuzzy on the semantics of default exports vs normal exports

dnolen12:02:59

in import syntax it’s {foo} vs foo

dnolen12:02:57

but actually I really don’t think we should care about the differentiating thing anyway

dnolen12:02:22

that is :refer [some-default] should always choose the default if available

dnolen12:02:49

if you need to get at the other thing (which is less likely) then you can do it normally via the namespace

dnolen12:02:21

the only thing we need to know to make this work are the exported names

dnolen12:02:41

but we can get that by parsing the modules - I thought we did something like this elsewhere already?

juhoteperi12:02:32

If we have module that does something like foo.js:

function a () {};
export { a as default, a, a as foobar };
in this case these imports would refer to same function:
import a from 'foo'; // default export
import bar from 'foo'; // default export, name here doesn't matter
import {a} from 'foo'; // a property
import {a as bar} from 'foo'; // a property renamed
import {foobar} from 'foo'; // foobar property

dnolen12:02:10

@mfikes let me know if you can’t get the command line stuff to work, I tried your specific example and it seem to work

dnolen12:02:27

for the record the issues was that I’d elided some steps, I had built first

dnolen12:02:41

so the fix was to always compile the ns with -main

juhoteperi12:02:42

If I understand your :refer [RaisedButton] example, in that case, the module-name would be used to refer to default export?

mfikes12:02:45

Yes. The only remaining aspcct that didn't work was using cljs.core instead of clojure.core (the latter worked for me)

dnolen12:02:03

you mean cljs.main ?

mfikes12:02:40

Yeah, right. clojure.main worked for me, but not cljs.main. But, on second thought, perhaps I typed cljs.core.

dnolen12:02:54

I tried this in a couple ways

mfikes12:02:02

I may give it a spin today to try to find any corner cases. One would be that -e that produces nil shouldn't print, etc.

dnolen12:02:10

1) uberjar 2) build, and lein run -m cljs.main

dnolen12:02:42

after pulling the latest dep into some other project for 2, of course

dnolen12:02:19

@mfikes feel free to open tickets for any of those things you find

dnolen12:02:30

-e, -i should be interleavable, all the options should work

dnolen12:02:38

(i.e.) loading from standard in etc.

dnolen12:02:03

source files do not have to have namespaces

mfikes12:02:05

Yeah, will do. Also, I suspect a better example for the news post would be nice, but that can come later

mfikes12:02:54

@dnolen What I'll do is manually run all of the Planck tests surrounding -e, etc, on ClojureScript proper

dnolen12:02:55

for nashorn target stuff all I’m doing is building then running jjs out/output-to.js

dnolen12:02:03

@mfikes nice thanks!

dnolen12:02:10

Jim Laskey (Nashorn lead) on Project Detroit https://www.youtube.com/watch?v=-JLhwsbMvjQ

dnolen12:02:26

would mean V8 is embedded in JVM, and we could switch to that

mfikes12:02:37

Are you still thinking global caching might be in the works for the next release?

dnolen12:02:42

@mfikes yes

dnolen12:02:47

I’ll working on that this week

dnolen12:02:13

@mfikes I can’t remember some of the details of what we talked about, but if you do feel free to add that to the ticket

mfikes12:02:35

One thing that occurred since then: We now have the possibility of immutable git deps that might also be amenable to global caching. Dunno.

dnolen12:02:40

I think my plan now might be to organize cache by compiler version and artifact id + version, would be easier to debug

dnolen13:02:04

@mfikes yes another thing to think about

dnolen13:02:39

.cache/compiler-version/artifact-id/artifact-version/build-opts-sha/

dnolen13:02:54

but could change that to

dnolen13:02:05

.cache/compiler-version/dep-type/artifact-id/artifact-version/build-opts-sha/

dnolen13:02:13

dep-type could be maven, git

mfikes13:02:46

I wonder how you would even detect a git dep, if all you end up seeing is the classpath. Perhaps you look for the sha in the path.

dnolen13:02:16

we would just read deps.edn no?

dnolen13:02:53

can just match source input on path

thheller13:02:47

why not just include everything when building the sha? (sha {:url source-url :compiler-verison ... :build-opts ...}) and then write cache to .cache/cljs/core.cljs.cache.<sha>?

thheller13:02:18

heck even include the entire source in the sha gen

dnolen13:02:08

could do that, but slightly harder to debug if some reason need to go poke around in there, which I suspect there will be

thheller13:02:07

depends on what you actually write to the cache file

dominicm13:02:27

@dnolen reading the deps.edn file wouldn't inform you about transitive git dependencies, if that matters.

thheller13:02:30

the cache file itself can be {:source source-string :js generated-js :ana analyzer-data :build-opts etc}

thheller13:02:52

as transit or whatever

dnolen13:02:57

@dominicm reading deps.edn would imply using the tools to figure all that out

dnolen13:02:35

@thheller yes but you would have to do a lot of hunting around to find anything

dominicm13:02:59

Ah, okay. Currently there's not an API which lets you know the dependency type, fwiw. Although I was thinking of proposing that the manifest type gets added to lib-map this morning anyway, and this would be a good use-case for it.

dnolen13:02:44

@dominicm ok, I hadn’t looked at the API that closely - in anycase this is some future step :slightly_smiling_face:

thheller13:02:49

don't know why I'd never need to hunt for anything. the compiler tells me the sha it used for caching and I look at it. there is no guessing involved in which files where used.

thheller13:02:34

only problem I see really is garbage collection

thheller13:02:44

ie. deleting old cache files

dnolen13:02:59

@thheller well this isn’t that important of a decision, the benefit is a small one, a user (not me) can go look in the cache easily when sorting out some issue

dnolen13:02:13

I do this all the time w/ .m2, so I don’t see a reason to make that harder

bhauman13:02:46

been thinking about the awesomeness of cljs.main

bhauman13:02:23

it made me think that this could be possible

bhauman13:02:10

but it would need access to something like a cljs.repl/*repl-env* in clojure space

bhauman13:02:24

there is a lot of beauty in this approach

r0man14:02:22

@dnolen yes, I'll try to come up with a minimal test case for this. do you know if at the point cljs-base is marked as loaded all the files in it should have been evaluated, or could they be loaded later on demand?

r0man14:02:19

oh, and it works fine in advanced mode, just not in :none.

dnolen14:02:45

@r0man then just a bug, it should work under :none definitely did a lot of testing around that

dnolen14:02:13

there’s no real issue disambiguating namespace usage vs. var usage

mfikes14:02:25

@dnolen Not a big deal, but I bet that the fact that -v takes a Boolean argument will trip up a lot of users that expect it to take no arguments.

dnolen14:02:43

@mfikes we’d have to make the command line parsing a bit fancier, I don’t really want to take on a dep for that - the approach was copied over from clojure.main and duplicates its requirements/limitations

dnolen14:02:05

we could have a sugar pass that injects a value

mfikes14:02:06

Ahh, suspected it was driven by the need for an argument

juhoteperi15:02:37

But if RaisedButton module exports both default and RaisedButton property (and different values), it wouldn't work: export {f1 as default, f2 as RaisedButton};

juhoteperi15:02:04

Only one of those could be accessible using :refer [RaisedButton]

juhoteperi15:02:54

And I agree, as you said on the issue, this is only about convenience

dnolen15:02:04

@mfikes feel free to add an enhancement ticket for fixing up -v --verbose as a special case, that’s easy enough to do

dnolen15:02:39

thanks for all testing! :slightly_smiling_face:

mfikes21:02:47

@dnolen I never wrote a ticket because I failed to figure out what was wrong, but I was unable to get .cljsc_opts to actually have an effect. (I think I'll dig more into later to see what was going on.)

dnolen22:02:46

@mfikes these cljs.main bug reports are really great :slightly_smiling_face: surprising number of cases to check for

dnolen22:02:02

also nice that we really have enough there in prior work to make this all pretty straightforward

dnolen22:02:41

@anmonteiro was pretty excited the generating cljs.user.XXXX namespaces for empty scripts just works, also ns* stuff

mfikes22:02:54

Yes, the cljs.main stuff is very solid, quality-wise :slightly_smiling_face: