Fork me on GitHub
#cljs-dev
<
2018-03-19
>
john00:03:57

geez, once wasm swallows the jvm, project detroit will give us v8 inside of the jvm inside of wasm inside of v8....

john00:03:53

So we'll also be able to .postMessage Clojure code from ClojureScript into a wasm v8 for execution, which can also call into an internal v8 instance. Sort of loopy.

Garrett Hopper01:03:29

@dnolen Alright, I think I've finally found my issue. When dependency requires closure modules in a split, they're added to the split, however they're also in :cljs-base, which results in it being loaded once by the script tag for cljs_base.js and again for the global eval of cljs.loader/load. I've created a simple repo to demonstrate it: https://github.com/Jumblemuddle/cljs-code-split-bug It's just the code-split test with an added dependency (kibu/pushy, though it also happens with a few other dependencies I've tested: cljs-http, etc.). Should I create a Jira ticket for this, or am I just doing something wrong? I may have missed a required step when importing dependencies.

r0man09:03:49

@ghopper I have seen the errors you are describing. however, this was before https://github.com/clojure/clojurescript/commit/78b2395960767ea44b68ddd632d1dfe9a4957853 I don't see them now anymore

dnolen11:03:02

just wrapped up a fairly significant refactor of the Node.js REPL

dnolen11:03:29

fixes a lot of long outstanding issues - the most important being non-determinism around printing & evaluation result order

dnolen11:03:18

Socket REPL over shared Node.js REPL environment appears to work great

dnolen11:03:28

clj -J-Dclojure.server.repl="{:port 5555 :accept cljs.server.node/repl}"

dnolen11:03:33

nc localhost 5555

dnolen11:03:53

try stuff like (println (range 10000)) you should always see printing and then nil

john01:03:34

nice, works with this ws implementation

john01:03:42

tried to copy your implementation and it connects. Trying to nc localhost 5555 again from a third terminal though throws BindException

john01:03:12

And the socket repl version should allow for multiple connections, right?

john01:03:22

ah, mine is launching a new server on each connect

dnolen12:03:20

I’m thinking it’s getting close to release time - I’ve updated the changes file

dnolen14:03:44

on master browser REPL now works even if the user refreshes

mfikes14:03:21

I put a lock-free (CAS-based) atom implementation in https://github.com/mfikes/mt-cljs, exploring what it might mean if ClojureScript were to ever support multithreading in JavaScript engines. There has to be tons of corner cases, but, surprisingly the use case exercised there appears to work fine. In other words, it seems to indicate that if multithreading ever became a thing, ClojureScript would be within reach of leveraging it.

dnolen14:03:35

Yeah I don’t think it will be hard to do when engines support it

dnolen14:03:57

WebKit idea is particularly promising because backwards compat

mfikes14:03:27

Even if it never takes off in the general JS ecosystem, if Detroit happened…

dnolen14:03:45

I think it will be hard to make Nashorn really work - you still need something like final fields for deftype

mfikes14:03:03

Yeah—and I’d be worried about lazy sequences doing the right thing, etc.

Garrett Hopper14:03:56

@r0man Hmm, this was with a recent build of master. Has anything changed with that in the past month?

dnolen14:03:25

@ghopper yes more fixes

dnolen14:03:35

Should test with master

Garrett Hopper14:03:03

This was tested with master, so perhaps it was somehow broken again.

Garrett Hopper14:03:34

I still need to take a look at that change you linked @r0man and see what was changed exactly.

r0man14:03:42

@ghopper yes, I read that this happend on the latest master.

dnolen14:03:06

I haven’t had time to look at the case to see if there’s a real problem here

mfikes14:03:16

In terms of release, the documentation suite seems to be fairly close. https://gist.github.com/mfikes/bdbe214f03abac88ae384adb1ac26490

r0man14:03:27

@ghopper When I had those problems, some namespaces were missing and the google module loader tried to load those namespaces

Garrett Hopper14:03:37

This seems to be a different issue then. cljs.loader is trying to evaluate module code that is already on the page from cljs_base.js.

tmulvaney14:03:14

Possibly doing something wrong, but when I run the above snippet for a Socket REPL on latest master I get an unable to resolve symbol PrintWriter-on error

danoyoung14:03:21

same here….

richiardiandrea15:03:52

You need the latest clojure 10, alpha 4, iirc

danoyoung15:03:58

coolio, that worked, thanx!

dnolen15:03:02

@tmulvaney Clojure 1.10.0-alpha4 is a requirement for the Socket REPL stuff

danoyoung15:03:15

thanx, that worked!

dnolen15:03:28

@ghopper you need to clean up that repo, please remove the jars

richiardiandrea15:03:13

Ops sorry didn't read the answer there :)

Garrett Hopper15:03:57

@dnolen Done. I wasn't sure how to use external libraries with just the uberjar. I've removed them and added a deps.edn now, though I'm not sure how to get the uberjar to use it.

dnolen15:03:17

uberjar isn’t necessary

dnolen15:03:40

clj / deps.edn covers us now for acceptable minimal cases

Garrett Hopper15:03:58

Ok, good to know. :thumbsup: Thanks

dnolen15:03:00

I don’t see how this could be minimal

dnolen15:03:09

either it’s needed to repro or it isn’t

Garrett Hopper15:03:19

It's just an example of a cljs library which required google closure modules. The same occurs with e.g. cljs-time and others.

dnolen15:03:42

@ghopper so you can’t reproduce if the closure modules don’t come via transitive deps in JARs?

dnolen15:03:59

issues need very exact descriptions

Garrett Hopper15:03:29

Actually, that's a good test case I haven't done yet... Sorry I'll try pulling the code from both libraries into the project directly.

dnolen15:03:45

I want to see if you can repro without this thing first

dnolen15:03:54

you’re already including gclosure modules in your repro

Garrett Hopper15:03:25

It could very well be the way those two libraries are including the modules that's the problem. I'll get back to you.

Garrett Hopper15:03:16

@dnolen Good call; that definitely wasn't minimal. https://github.com/Jumblemuddle/cljs-code-split-bug It seems to stem from an issue with (:import) statements for google closure modules.

dnolen15:03:50

@ghopper looking into - but needed shave a yak first 🙂

dnolen15:03:20

-co and -ro can now take @/resource, @resource, or file

Garrett Hopper15:03:36

🙂 Thanks Let me know if there's anything else I can do.

dnolen16:03:49

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

dnolen16:03:15

should eliminate the need for scripts

dnolen16:03:48

unless you’re doing something fancy

jannis16:03:36

@dnolen Is it worth mentioning the new :package-json-resolution flag in changes.md?

jannis16:03:46

I should’ve included a mention in my original patch.

dnolen16:03:14

@jannis we could but I don’t think so, for you it just worked w/o explicit configuration

dnolen16:03:42

I’d like to be conservative about explaining all these NPM knobs until a lot more stuff is working

dnolen16:03:33

clj -m cljs.main -co build.edn:prod.edn -c

dnolen16:03:52

though I guess you can use clj :main-opt aliases for this

dnolen16:03:40

but it all merges so not a big deal if we support

mfikes16:03:40

This provides a nice way to have config in your :main-opts prior to https://dev.clojure.org/jira/browse/TDEPS-56 being fixed 🙂

john16:03:20

does -ro recognize :nrepl-middleware?

john16:03:37

if I have the necessary deps in place?

dnolen16:03:28

cljs.main only knows about ClojureScript stuff

dnolen16:03:45

and it will stay that way - there are hooks present if you want to reuse the architecture

john16:03:08

Trying to rework weasel's weasel-example project to use deps.edn

john16:03:02

I'm pretty sure @bhauman had an example deps.edn config up somewhere that did something like this, I just can't find it

dnolen16:03:25

clj -m cljs.main -co build.edn:prod.edn -c is indeed pretty slick

dnolen16:03:29

landed in master

danoyoung17:03:03

this is badass….awesomeness!

richiardiandrea16:03:43

(I surely would need to find other adjectives)

dnolen17:03:14

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

dnolen17:03:26

is definitely succinct for looking at repros

richiardiandrea17:03:47

I know we discussed about this approach but I think folks would expect :main to work there as well...basically a better solution to this https://dev.clojure.org/jira/browse/CLJS-2612

jannis17:03:31

@dnolen If you call :package-json-resolution :nodejs “w/o explicit configuration” then yes. The default is still a mode that doesn’t work with e.g. graphql-js.

dnolen17:03:58

@jannis ok then yes we should mention it

dnolen17:03:15

@ghopper can reproduce, something about goog.History

dnolen17:03:20

nothing to do with :import

dnolen17:03:50

I can load :c but :b is broken because it’s incomplete

dnolen17:03:01

whatever you were saying about cljs_base.js seems completely untrue

dnolen17:03:23

the only thing that appears to need fixing is the dependencies of :b are wrong

Garrett Hopper17:03:59

@dnolen It's not just goog.History though, it also happens when importing others. I don't know what exactly at the moment though. Give me a minute to get my context again.

dnolen17:03:41

@ghopper one thing I’m looking at is that goog.History provides multiple things

dnolen17:03:48

which is a Closure-ism

dnolen17:03:01

but again nothing to do with :import

dnolen17:03:05

nothing to with the base module

dnolen17:03:10

so let’s set all that stuff aside

dnolen17:03:31

from what I’m seeing right now, there’s just some kinds of Closure namespaces we can’t handle

dnolen17:03:34

one’s with multiple provides

dnolen17:03:57

anyways I’m on it

Garrett Hopper17:03:00

Putting a breakpoint (in Chrome Devtools) on line 222 of goog/module/moduleloader.js shows what the error was when evaluating. The issue is that it's trying to load an already loaded module (`goog.dom.InputType` in this case). This module isn't actually loaded at all if the import of goog.History is removed, it seems like it should be a dependency of :b, but it ends up also being loaded on the page by :cljs-base. Closure namespaces with multiple provides certainly seems to be the source of the issue.

dnolen17:03:24

probably red herrings 🙂

dnolen17:03:30

anyways I have the information that I need

dnolen17:03:39

it doesn’t really matter that runtime problems you are running to

dnolen17:03:41

it could never work

dnolen17:03:53

because the deps are just wrong

Garrett Hopper17:03:05

Fair enough. I'm definitely unfamiliar with a lot of this. Thanks

dnolen17:03:41

it’s a good catch, surprised it wasn’t reported before, but maybe particular to :none is why

Garrett Hopper18:03:26

I believe this is only for :none, though I haven't really A/B tested it.