Clojurians
#cljs-dev
<
2018-03-20
>

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

dnolen11:03:58

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

dnolen11:03:40

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

mfikes11:03:09

Master LGTM for all my non-trivial projects.

jumblemuddle12:03:12

@dnolen Awesome, thanks for your patience. :)

mfikes12:03:32

Canary is good with current master.

tmulvaney12:03:21

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

tmulvaney12:03:23

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

rauh12:03:53

Yeah, there are tickets for those in the repo

tmulvaney12:03:56

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

tmulvaney13:03:20

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

mfikes13:03:00

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

tmulvaney13:03:07

@mfikes correct

mfikes13:03:44

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

tmulvaney13:03:07

yeah transit-cljs dispatches on the type

mfikes13:03:00

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

mfikes13:03:25

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

mfikes13:03:58

(eduction (take 3) (range))

tmulvaney13:03:12

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

mfikes13:03:24

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.

jannis13:03:12

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

jannis13:03:40

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

tmulvaney13:03:21

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

mfikes13:03:14

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

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

#
object
[
cljs.core/Eduction
]

dnolen14:03:43

@jannis sure

jannis14:03:30

Let me know if that’s too long :slightly_smiling_face:

dnolen14:03:54

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

dnolen14:03:10

in Clojure you can cover expanding concrete types via an interface

dnolen14:03:24

cutting another release

jannis14:03:05

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

dnolen15:03:26

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

dnolen15:03:39

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

mfikes15:03:11

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.

mfikes15:03:35

Perhaps that ticket should be low priority anyway

mfikes15:03:51

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

dnolen15:03:30

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

dnolen15:03:45

also there’s no way to detect this

dnolen15:03:57

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

mfikes15:03:39

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

dnolen15:03:20

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

dnolen15:03:52

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

dnolen15:03:13

@mfikes does it seem available yet?

mfikes15:03:28

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

danoyoung15:03:51

looks like it just showed up

danoyoung15:03:11

Downloading: org/clojure/clojurescript/1.10.217/clojurescript-1.10.217.pom from 
Downloading: org/clojure/clojurescript/1.10.217/clojurescript-1.10.217.jar from 
ClojureScript 1.10.217
cljs.user=> 

mfikes15:03:01

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

mfikes15:03:39

1.10.217 has appeared now

juhoteperi15:03:56

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

juhoteperi15:03:56

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.

mfikes16:03:24

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

john16:03:50

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

dnolen16:03:28

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

dnolen16:03:28

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

dnolen16:03:31

but even without all that

dnolen16:03:21

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

dnolen16:03:15

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

dnolen16:03:33

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

dnolen16:03:10

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

john16:03:18

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?

dnolen16:03:45

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

dnolen16:03:03

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

dnolen16:03:14

but of course fancier REPLs like Figwheel could do much more

dnolen16:03:32

if that made sense for some reason

john16:03:08

Awesome :slightly_smiling_face:

dnolen17:03:03

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

dnolen17:03:42

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

john17:03:40

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.

dnolen17:03:37

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

dnolen17:03:45

that’s how the shared env Socket REPLs work

john17:03:47

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

john17:03:31

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

dnolen17:03:10

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

john17:03:31

ah, it's probably something simple then

jumblemuddle17:03:07

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

dnolen18:03:42

@jumblemuddle looking

dnolen18:03:23

@jumblemuddle it works for me

jumblemuddle18:03:39

Loading module :b does?

jumblemuddle18:03:56

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

dnolen18:03:07

alpha and bravo are both loaded fine

dnolen18:03:40

I am skeptical that your repo will have a problem

dnolen18:03:48

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

dnolen18:03:57

but it needs to be more minimal

dnolen18:03:17

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

jumblemuddle18:03:30

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.

dnolen18:03:41

but why did you think it didn’t work?

dnolen18:03:46

it didn’t work in your project?

jumblemuddle18:03:21

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.

dnolen18:03:09

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

dnolen18:03:26

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

dnolen18:03:19

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

dnolen18:03:59

@jumblemuddle since I already have this loaded up …

dnolen18:03:12

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

jumblemuddle18:03:28

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

dnolen18:03:49

I just don’t see this problem

jumblemuddle18:03:54

"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_ ()"

jumblemuddle18:03:06

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

dnolen18:03:23

but yes or no to the above?

dnolen18:03:29

cljs-time.core require instead of alpha bravo

jumblemuddle18:03:41

Yes, you can. :thumbsup:

jumblemuddle18:03:27

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

dnolen18:03:42

trying that now

jumblemuddle18:03:10

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

dnolen18:03:38

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

jumblemuddle18:03:55

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.

jumblemuddle18:03:23

How do I use deps.edn with the uberjar?

dnolen18:03:44

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

dnolen18:03:49

just use deps.edn

dnolen18:03:40

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

dnolen18:03:42

it just works here

jumblemuddle18:03:07

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?

dnolen18:03:09

gisting your :modules is probably a good idea

jumblemuddle18:03:22

Give me a second, I have an idea.

jumblemuddle18:03:29

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.

dnolen18:03:11

works in Chrome, Safari for me

dnolen18:03:38

works in Firefox too

dnolen18:03:54

@jumblemuddle in your actual project what are you using?

dnolen18:03:04

I’m assuming not the uberjar

dnolen18:03:00

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

dnolen18:03:05

the earlier report made sense

dnolen18:03:32

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

jumblemuddle18:03:33

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.

jumblemuddle18:03:02

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

dnolen18:03:06

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

dnolen18:03:14

which had deps lower down

dnolen18:03:23

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

dnolen18:03:41

and should be ignored

dnolen18:03:52

either the dep order looks right or it looks wrong

dnolen18:03:05

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

dnolen18:03:14

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

jumblemuddle18:03:15

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

dnolen18:03:11

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

jumblemuddle18:03:05

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

dnolen18:03:43

sorry this just going down the wrong path for me

dnolen18:03:58

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

dnolen18:03:59

first I would try to reproduce with some other tool

jumblemuddle18:03:02

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

dnolen18:03:30

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

dnolen18:03:19

@jumblemuddle that’s your build.edn file

dnolen18:03:47

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

dnolen18:03:09

you don’t need bother with anything else

dnolen18:03:17

the clj command I gave you above will start a server

jumblemuddle18:03:02

How is the cljs command built from master?

dnolen18:03:02

remove out etc.

dnolen18:03:15

there is no cljs command

dnolen18:03:31

just use 1.10.217 that is master

jumblemuddle18:03:34

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

dnolen18:03:49

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

dnolen18:03:14

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

john19:03:06

clicking "Load Module B1" causes:

john19:03:49

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

jumblemuddle19:03:19

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

dnolen19:03:44

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

john19:03:58

That's just on load

dnolen19:03:14

looks fine

john19:03:20

clicking left button:

dnolen19:03:40

also looks fine

john19:03:42

right button:

dnolen19:03:04

yes - it’s working as advertised (TM)

john19:03:50

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

jumblemuddle19:03:42

@john Good call. I'll do that.

dnolen19:03:02

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

john19:03:09

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

dnolen19:03:26

clj -Srepro is your friend

john19:03:13

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

dnolen19:03:30

doesn’t use anyting but local deps.edn

jumblemuddle19:03:10

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

john19:03:30

What OS?

jumblemuddle19:03:33

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

john19:03:58

that's mysterious

john19:03:55

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

jumblemuddle19:03:22

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.

jumblemuddle19:03:00

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

john20:03:24

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

jumblemuddle20:03:26

Thanks, @john!

jumblemuddle20:03:05

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

john20:03:13

clj here

john20:03:20

no prob!

john20:03:10

And thank you for the awesome debugging! :slightly_smiling_face:

jumblemuddle20:03:38

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

jumblemuddle20:03:53

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

jumblemuddle20:03:19

» 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

john20:03:26

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.

jumblemuddle20:03:28

There's definitely a difference between the two outputs.

john20:03:25

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

jumblemuddle20:03:30

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.

john20:03:33

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

jumblemuddle20:03:04

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']);

jumblemuddle20:03:25

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

jumblemuddle20:03:19

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

jumblemuddle20:03:56

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

john21:03:12

what wasn't created?

john21:03:29

oh the folder

jumblemuddle21:03:59

Yeah, the aot cache folder.

john21:03:40

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.

john21:03:59

to include lots of work on the caching system

jumblemuddle21:03:16

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

john21:03:49

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

jumblemuddle21:03:42

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

jannis21:03:39

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?

jannis21:03:55

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

jumblemuddle21:03:20

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

thheller21:03:19

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

jannis21:03:20

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

jannis22:03:18

I wonder how to do that right…

thheller22:03:16

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

thheller22:03:28

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

jannis22:03:28

@thheller Perfect, that was it! Thanks :slightly_smiling_face:

dnolen22:03:51

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

dnolen22:03:37

I see now how that could cause a problem

richiardiandrea23:03:07

@dnolen you made a dev happy :tada:

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=>
Starts perfectly and quickly.

dnolen23:03:44

@richiardiandrea :slightly_smiling_face: