@ghopper your issue is fixed on master - it was a bad handling of multiple provides

It’s a good time to take master for a spin again - I’m thinking we should go for a Monday release

Master LGTM for all my non-trivial projects.

@dnolen Awesome, thanks for your patience. :)

Canary is good with current master.

I think transit-cljs needs to be updated to handle MapEntry

it never handled RedNode or BlackNode by the looks of things either but i guess tree maps are less used

Yeah, there are tickets for those in the repo

ah cool

Yeah i think some of those new reducible types that @mfikes added recently probably need to be added like Repeat

at least the ones that aren't infinite maybe..?

@tmulvaney Are you saying that transit-cljs can't encode the sequence produced by (repeat 5 :hi) with master?

@mfikes correct

I wonder if this is because ClojureScript is doing something wrong, or if transit-cljs is violating things a bit, relying on implementation details

yeah transit-cljs dispatches on the type

That would seem to imply that every time ClojureScript adds a new deftype along these lines, code like that in the wild might break.

https://github.com/cognitect/transit-cljs/blob/master/src/cognitect/transit.cljs#L202

Yep, so MapEntry, Repeat. I wonder about a finite Eduction...

(eduction (take 3) (range))

I guess there are predicates in core that could replace the keys in that map, seq? vector? map? that would handle most cases...

Right. Perhaps you could argue that transit-cljs is an example of code that, while correct, is fragile in the face of new types being added. I don't see a good way to not break (correct) code like that.

Here is an example of @tmulvaney’s suggested approach https://github.com/brandonbloom/fipp/blob/master/src/fipp/visit.cljc#L35

@dnolen Sorry, I didn’t have much time yesterday. Would it help if I submitted a 1-2 liner to mention the flag in the changes file?

JIRA is maybe too much overhead; could do it as a PR or just a sentence posted here. Up to you 😉

@mfikes exactly. although looking at fipp i'm not sure if there is a predicate in that cond which supports Eduction either. It's not a seq?. There is an argument for doing based on type I suppose: it's more explicit.

FWIW, I've written https://github.com/cognitect/transit-cljs/issues/44 https://github.com/cognitect/transit-cljs/issues/45

@tmulvaney Right, fipp "works", but not as desired:

cljs.user=> (fipp (eduction (take 3) (range)))

#
object
[
cljs.core/Eduction
]

@jannis sure

@dnolen https://github.com/clojure/clojurescript/pull/71

Let me know if that’s too long 🙂

@mfikes we can’t hook on protocols so there’s really no better way for transit-cljs

in Clojure you can cover expanding concrete types via an interface

@jannis https://github.com/clojure/clojurescript-site/blob/master/content/reference/compiler-options.adoc the option should be mentioned here also

cutting another release

@juhoteperi Yep, good point! I’ll get a PR ready

@mfikes https://dev.clojure.org/jira/browse/CLJS-2677, there’s really not an obvious way to make this work

if it’s going to work Node.js has to work, and Node.js expects relative paths

Yeah, I figure. If there is a way to throw an uninformed user a bone by detecting and throwing an exception saying so, perhaps that would improve things.

Perhaps that ticket should be low priority anyway

By the way, shouldn't 1.10.217 be in maven central by now?

given this necessitates generating a local node_modules folder anyway, not a big deal

also there’s no way to detect this

you can use node_modules w/o specifying :npm-deps

Cool. Well, if anyone else sees the same JavaScript console stuff, they may find the JIRA and educate themselves 🙂

being able to run a REPL w/o :output-dir is neat, but it’s probably going to have limitations

anybody try Socket REPL w/ shared Node.js env yet? It’s pretty cool 🙂

@mfikes does it seem available yet?

Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.clojure:clojurescript:jar:1.10.217 in central ()

{:deps {org.clojure/clojurescript {:mvn/version "1.10.217"}}}

@juhoteperi Done: https://github.com/clojure/clojurescript-site/pull/199

^ Added to 1.10.x doc list https://gist.github.com/mfikes/bdbe214f03abac88ae384adb1ac26490

1.10.217 has appeared now

Github milestones and labels would be useful to manage site PR's

Maybe it would make sense to add some collaborators to the site repository? Master branch could be protected to disallow direct pushes and require PR with approved reviews etc.

@mfikes https://github.com/clojure/clojurescript-site/pull/159 this is also related to 1.10

Thanks @juhoteperi added to the bottom and will clean it up later when free

@dnolen I've been playing with the socket repl, trying to wrap my head around the cljs.server.* namespaces. What kind of common dev use cases will this enable? It certainly is convenient to be able to inspect and hack on the back end of a repl while it's running.

tooling

but also Socket REPLs are a necessity when you want one JVM and N repls, one for Clojure & ClojureScript

pREPL is also big for tooling - since it’s really not that realistic to use regular REPLs for tooling

but even without all that

having multiple REPLs can be convenient, since each REPL has it’s own state (current ns etc.)

right

also you could be doing something in browser REPL, and then want to try something without messing with your browser REPL state

like pipe to nc localhost 5555 to run something and write to a file or whatever

basically all this stuff is to make ClojureScript more capable without all the annoying ceremony

and when separate "sessions" share the same compiler state but maintain separate var bindings, right? So, same compile time state, different run time state, right?

they share the same compiler environment which mirrors Clojure semantics, runtime and compile time

but the REPL state is different, really just the current ns

but of course fancier REPLs like Figwheel could do much more

if that made sense for some reason

Awesome 🙂

also w/ I/O redirection, you could imagine a REPL that just logs stuff w/o cluttering your main session

anyways people should start playing with it - lots of possibilities if you start messing around with it

I've got an almost working implementation of but I can't yet get them to manage their *out*s well yet. Almost there though.

right you need to pass some kind of tag, and you need to track those tags on the CLJ side

that’s how the shared env Socket REPLs work

Yeah, I'm grabbing the thread id. But I'm not using the ConcurrentHashMap yet

I'm using an atom now. Not sure why an atom wouldn't work. But I'm going to try the CHM next

atom should work fine, I just used a CHM because it also works fine 🙂

ah, it's probably something simple then

@dnolen I finally got a chance to test against my actual code base. It fixed the issue for most libraries, however I was still having issue with cljs-time. I've updated https://github.com/Jumblemuddle/cljs-code-split-bug with a minimal example of the issue. It seems like there's an issue when a closure module with multiple provides is imported in multiple places. (Uncommenting the require to code.example.bravo in :b fixes the issue.)

@ghopper looking

Thanks

@ghopper it works for me

Loading module :b does?

Give me a minute. I'll do another build of master.

yes

alpha and bravo are both loaded fine

I am skeptical that your repo will have a problem

however that doesn’t mean your report about cljs-time isn’t true

but it needs to be more minimal

but I’d be willing to look at it if you can’t do that

I'd started with cljs-time and slowly narrowed it down. It's probably a case of something having been cached. I'm testing more now.

but why did you think it didn’t work?

it didn’t work in your project?

Yeah, there was definitely an issue in my project, and directly copying cljs-time code into this example project wasn't working. I slowly narrowed it down to this result, and it was still having the same issue of goog.provide redefining on the global eval.

note in your project it’s possible you may have other issues

and there’s nothing wrong with :modules anymore, you need to determine this

@ghopper what does :modules look like in your actual project?

@ghopper since I already have this loaded up …

can I replace alpha & bravo w/ requiring cljs-time.core?

Alright, with a clean cljs.jar from master and this example project, moduleloader.js:222 catches this error: "Namespace "goog.i18n.DateTimeSymbols" already declared."

I just don’t see this problem

"Error: Namespace "goog.i18n.DateTimeSymbols" already declared.
    at Object.goog.provide ()
    at eval (eval at goog.globalEval (), <anonymous>:33:6)
    at eval (<anonymous>)
    at Object.goog.globalEval ()
    at goog.module.ModuleLoader.evaluateCode_ ()
    at goog.module.ModuleLoader.handleSuccess_ ()
    at goog.net.BulkLoader.goog.events.EventTarget.fireListeners ()
    at Function.goog.events.EventTarget.dispatchEventInternal_ ()
    at goog.net.BulkLoader.goog.events.EventTarget.dispatchEvent ()
    at goog.net.BulkLoader.finishLoad_ ()"

Yeah, I'm not sure what's going on now...

but yes or no to the above?

cljs-time.core require instead of alpha bravo

Yes, you can. :thumbsup:

It's a different error, but still a case of a namespace already being declared.

trying that now

Thanks

I'm starting to think there's just a ghost in my machine.

works

I’m trying with 1.10.217 via deps.edn, trying with the uberjar

Yeah, I'm on the same version; building with the uberjar. I copied the source of cljs-time into the src directory instead of deps.edn though.

How do I use deps.edn with the uberjar?

the uberjar isn’t really a great way to test this, since we’re going to stop using that soon

just use deps.edn

anyhow, I’m skeptical now that cljs-time is the problem

it just works here

I've only just gone through the quickstart to create a minimal bug report the other day. How do I just use the deps.edn?

gisting your :modules is probably a good idea

Give me a second, I have an idea.

Nah, symlinks weren't it. This example repo is definitely causing the issue on my machine, and since it's minimal, I'm going to continue testing with it. I'm going to try with some other browsers.

works in Chrome, Safari for me

works in Firefox too

@ghopper in your actual project what are you using?

I’m assuming not the uberjar

fwiw I just don’t see how this couldn’t work

the earlier report made sense

we were accidentally not removing the other provided nses when computing the dependency graph

I'm testing with that example repo I linked. There aren't any changes except my copying the latest cljs.jar into it. I build with java --add-modules java.xml.bind -cp cljs.jar:src clojure.main build.clj and serve with the npm packages http-server.

I totally get that. I'm as confused as you are.

so what you were seeing was that we would load something from base

which had deps lower down

the whole “already loaded” stuff is just a red herring

and should be ignored

either the dep order looks right or it looks wrong

it was obvious before when you print the module graph that it was wrong

if it’s not wrong then what you are describing isn’t possible

Alright, that makes sense. I'll start looking at the module graph instead.

i.e. before goog.History was in base, when the deps it needed were in child modules :a etc.

@dnolen I've committed the out directory. Can you pull that repo and tell me if the build loads module :b correctly for you?

sorry this just going down the wrong path for me

it won’t tell me anything other than I cannot reproduce some detail about your environment

first I would try to reproduce with some other tool

That's fair. Thanks for your time. I'll let you know if I can isolate the issue.

i.e. clj

clj -m cljs.main -v -co build.edn -c -s

@ghopper that’s your build.edn file

deps.edn is {:deps {org.clojure/clojurescript {:mvn/version "1.10.217"}}}

you don’t need bother with anything else

the clj command I gave you above will start a server

How is the cljs command built from master?

remove out etc.

there is no cljs command

clj

just use 1.10.217 that is master

Sorry, How is the clj* command built from master. Typo.

you don’t need to build from master brew install clojure

Ok :thumbsup:

it has nothing to do with ClojureScript beyond it’s a way of running ClojureScript that I believe isn’t adding random variables

clicking "Load Module B1" causes:

... sorry. clicking on those buttons a bunch of times causes that output 🙂

@john Thanks for testing. There's definitely something wrong on my system.

@john I think we need to consistently repro with one click first

That's just on load

looks fine

clicking left button:

also looks fine

right button:

yes - it’s working as advertised (TM)

@ghopper have you tried cloning your repo into a fresh dir and trying?

@john Good call. I'll do that.

(you should definitely be blowing away out each time, I’m assuming you are, disable caches in browser etc.)

Also, I'm not entirely sure about this, but I like to eliminate any global deps.edn file when testing. If you might have ever installed clj tool in the past and forgot, make sure you don't have any strange global confs in your ~/.clojure/deps.edn file

clj -Srepro is your friend

@dnolen does clj -Srepro do exactly that? I should go read the docs on that

doesn’t use anyting but local deps.edn

@dnolen Yeah, it's clean each time. 🙂 @john The file exists, but everything is commented out.

k

What OS?

Same result. Nixos

» java -version                                                                                                   ~
openjdk version "9.0.4-internal"
OpenJDK Runtime Environment (build 9.0.4-internal+0-adhoc..jdk9u-jdk-9.0.411)
OpenJDK 64-Bit Server VM (build 9.0.4-internal+0-adhoc..jdk9u-jdk-9.0.411, mixed mode)
» chromium -version                                                                                               ~
Chromium 64.0.3282.186

that's mysterious

I'd try on another box for my own sanity if I were you 🙂

I don't have the 1.10 version of clj at the moment. I'm going to spin up a Docker machine to test this on.

Good call

@dnolen So the clj command invocation wouldn't work, because it couldn't locate cljs/main, I assume that's because it's only included in 1.10? Anyways, I was able to invoke the cljs.main from the uberjar with the same command, and it works like a charm... java -cp cljs.jar:src cljs.main -v -co build.edn -c -s works, but java -cp cljs.jar:src clojure.main build.clj doesn't. When you were testing my repo, did you actually use the build.clj or just use clj with cljs.main? I'm still not sure what this clj command is exactly. Is there documentation somewhere about what it does exactly?

@ghopper https://clojure.org/guides/deps_and_cli & https://clojure.org/reference/deps_and_cli

This is all very new and more docs are in the works

Thanks, @john!

@john, were you by any chance using that when testing it, or did you use the uberjar?

clj here

no prob!

And thank you for the awesome debugging! 🙂

Alright, I wonder if the uberjar and cljs.build.api is indeed causing my issues.

Heh, thanks for your patience. This has been a great learning experience for me.

» diff out-cljs-main out-clojure-main --color=always                                          ~/cljs-code-split-bug
Common subdirectories: out-cljs-main/cljs and out-clojure-main/cljs
diff '--color=always' out-cljs-main/cljs_base.js out-clojure-main/cljs_base.js
106a107
> document.write('<script>goog.require("code.example.bravo");</script>');
diff '--color=always' out-cljs-main/cljs_deps.js out-clojure-main/cljs_deps.js
11a12
> goog.addDependency("../code/example/bravo.js", ['code.example.bravo'], ['cljs.core', 'goog.date.Date']);
diff '--color=always' out-cljs-main/cljsc_opts.edn out-clojure-main/cljsc_opts.edn
1c1
< {:verbose true, :output-dir "out", :asset-path "/out", :modules {:a {:entries #{code.split.a}, :output-to "out/a.js"}, :b {:entries #{code.split.b}, :output-to "out/b.js"}, :c {:entries #{code.split.c}, :output-to "out/c.js"}}, :output-to "out/main.js", :aot-cache true}
\ No newline at end of file
---
> {:output-dir "out", :asset-path "/out", :modules {:a {:entries #{code.split.a}, :output-to "out/a.js"}, :b {:entries #{code.split.b}, :output-to "out/b.js"}, :c {:entries #{code.split.c}, :output-to "out/c.js"}}}
\ No newline at end of file
Common subdirectories: out-cljs-main/clojure and out-clojure-main/clojure
Common subdirectories: out-cljs-main/code and out-clojure-main/code
Common subdirectories: out-cljs-main/goog and out-clojure-main/goog
Common subdirectories: out-cljs-main/process and out-clojure-main/process

Yeah, it might be interesting to try building your jar with pack or depstar, which are newer jar builders for the clj/deps.edn stuff.

There's definitely a difference between the two outputs.

In general, clj is the repro method accepted for bug reports

It works like a charm when I remove the extra two lines added to cljs_base.js and cljs_deps.js. @john That's fair. I'm really curious what's causing the difference though.

hmm. I wonder if AOT cache could have anything to do with it...

Alright, that's definitely the issue. Using cljs.build.api (via build.clj) results in two extra lines being added:

cljs_base.js
> document.write('<script>goog.require("code.example.bravo");</script>');

cljs_deps.js
> goog.addDependency("../code/example/bravo.js", ['code.example.bravo'], ['cljs.core', 'goog.date.Date']);

@john That's an interesting thought. I should be able to just wipe out the folder to test, right?

I wiped out ~/.cljs, and the lines are still added.

It wasn't recreated. I guess it's only used when using cljs.main?

what wasn't created?

oh the folder

Yeah, the aot cache folder.

Just a guess here, but it may well be that the build API needs some updating... A lot of work has gone into making cljs.main a usable entry point, so some stuff may have gotten moved around.

to include lots of work on the caching system

So, cljs.main excises code.example.bravo, because nothing requires it, but cljs.build.api adds requires is. Interesting.

But underneath, cljs.main is using cljs.build.api I believe so it should work.

I guess it's calling it with slightly different parameters. I need to dig into cljs.main I haven't looked at it yet.

Has anything changed about defining macros in .clj or .cljc files and making them available in .cljs via :require-macros? When building with cljs.build.api?

I’m getting a Could not locate groom/dsl__init.class or groom/dsl.clj on classpath. in file src/main/groom/dsl.cljs error when building a .clj file with a defmacro and a .cljs file that requires it with :require-macros: https://gist.github.com/Jannis/e9c8fdc15a670c7fa402cda49105ad18

@dnolen I believe I've found the issue. There are two additional lines added in the out directory to cljs_base.js and cljs_deps.js (requires to code.example.bravo) when building with java -cp cljs.jar:src clojure.main build.clj that aren't there when building with java -cp cljs.jar:src cljs.main -v -co build.edn -c -s. It works fine when building with cljs.main. The cljsc_opts.edn file is identical in the two outputs.

@jannis might be that you have src as your classpath instead of src/main? but no nothing changed

@thheller Mh, yeah, I have (cljs.build.api/watch "src" ...) because I’m building an example that’s in src/examples/groom/foo.cljs against a library that’s in src/main/groom/....

I wonder how to do that right…

@jannis that is not the classpath. if you use deps.edn its :paths ["src/main"]

clojure is used for :require-macros and that only looks at the classpath. no cljs config affects this at all.

Ah!

@thheller Perfect, that was it! Thanks 🙂

@ghopper when calling cljs.build.api you pass src as first argument, this means include everything in there in the build, even orphans, when you use cljs.main you don’t specify a directory, so it won’t get included

I see now how that could cause a problem

@dnolen you made a dev happy 🎉

cat cljsc_opts.edn 
{:main cli-repro.core
 :verbose true
 :optimizations :none
 :target :nodejs
 :install-deps true
 :npm-deps {:left-pad "1.1.3"}}

clojure -m cljs.main -re node -co cljsc_opts.edn -r
ClojureScript 1.10.217
cljs.user=>

@richiardiandrea 🙂