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

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

oh sweet the main and cli stuff is awesome!

By the way, these two changes would be easy to finish: https://dev.clojure.org/jira/browse/CLJS-2376 https://dev.clojure.org/jira/browse/CLJS-2346

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

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

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

@kommen Looks good to me

thanks!

@kommen applied

thanks!

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

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

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

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.

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

@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

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

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

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

you mean cljs.main ?

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

I tried this in a couple ways

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.

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

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

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

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

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

source files do not have to have namespaces

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

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

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

@mfikes nice thanks!

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

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

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

@mfikes yes

I’ll working on that this week

@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

OK

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

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

@mfikes yes another thing to think about

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

but could change that to

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

dep-type could be maven, git

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.

we would just read deps.edn no?

can just match source input on path

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

heck even include the entire source in the sha gen

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

depends on what you actually write to the cache file

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

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

as transit or whatever

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

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

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.

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

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.

only problem I see really is garbage collection

ie. deleting old cache files

@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

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

been thinking about the awesomeness of cljs.main

it made me think that this could be possible

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

there is a lot of beauty in this approach

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

@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

we could have a sugar pass that injects a value

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

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

thanks for all testing! 🙂

https://dev.clojure.org/jira/browse/CLJS-2512

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

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

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

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

amazing

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