Fork me on GitHub
#clojurescript
<
2017-08-14
>
tony.kay00:08:33

Not saying it isn’t possibly a hard problem. What if I only use L (implicitly) from one of my modules, and the dep graph for splitting decides to place it in that module because it is the only place it is used?

tony.kay00:08:31

well, actually, I’m still OK. Because then the module info would show it in that module, and that module writer would properly call set-loaded! when it was loaded.

tony.kay00:08:21

The error is also a bit misleading, because there are chained assertions. The call to loaded? here https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/loader.cljs#L66 is actually what is throwing the error (because loader is nil).

tony.kay00:08:07

the error message on line 65 is the same text as that of line 50…so it is easy to get a little confused about which thing is broken.

tony.kay00:08:48

OK. I have company that I’m ignoring. I’ll check in later tonight if I can.

ingesol08:08:47

Getting an error on my Windows 10 computer trying out https://ajpierce.github.io/posts/react-figwheel-npm-2/

ingesol08:08:26

Stacktrace java.lang.IllegalArgumentException: c:\dev\splort\node_modules\react-dom\index.js is not a relative path at http://clojure.java.io$as_relative_path.invokeStatic (io.clj:414) http://clojure.java.io$file.invokeStatic (io.clj:426) http://clojure.java.io$file.invoke (io.clj:418) cljs.closure$write_javascript.invokeStatic (closure.clj:1698) cljs.closure$write_javascript.invoke (closure.clj:1691) cljs.closure$process_js_modules$fn__15415.invoke (closure.clj:2348)

cmal10:08:38

Hi, I've wrote a this app: https://calm-wildwood-56255.herokuapp.com/#/chart , using CSS transitions. But those transitions does not work correctly in some of the components. In my app, only the components who are moving upwards works well, those who are moving downwards moves instantly without animation. (I want them both moves with animation.) CSS is here:

div.canvas {
    position: absolute;
    top: 90px;
    left: 60px;
    width: 640px;
    height: 480px;
    border: 1px solid #999;
    background: white;

}

div.canvas-rect {
    position: relative;
    margin-left: 20px;
    margin-top: 10px;
    height: 20px;
    background: green;

    transition: all 1s linear;
    -moz-transition: all 1s linear; /* Firefox 4 */
    -webkit-transition: all 1s linear; /* Safari 和 Chrome */
    -o-transition: all 1s linear; /* Opera */

}

cmal10:08:50

(defn rank-rects []
  (let [rank (rf/subscribe [:rank])]
    [:div.canvas-inner
     (doall (for [i    (range (count @rank))
                  :let [r (get @rank i)]]
              ^{:key r}
              [:div.canvas-rect
               {:style {:width (str (* 20 (inc r)) "px")
                        :top   (str (* i 30) "px")}}
               ]))]))

cmal10:08:35

(defonce ranks (repeatedly 100 (partial shuffle (range 5))))

cmal10:08:38

and every second, I set the db/rank to

(nth db/ranks (mod (- time db/init-time) 100))

darwin10:08:20

@cmal CSS transitions work only when updating existing elements, not when creating them from scratch. It looks to me, that you don’t have stable keys for .canvas-rect list of elements, so React might re-render them from scratch, because there is no good mapping between existing elements in the DOM and elements you want to render. Just a wild guess

darwin10:08:03

Anyways, you should be able to debug this in Chrome DevTools. This should be unrelated to ClojureScript.

cmal10:08:30

Yes, but why is the key not stable, I set them to 05 and they are always 05

darwin10:08:26

try to sort the items by rank in the for form

darwin10:08:11

so that you feed them into react in the same order every time, 0…4

cmal11:08:58

ok! Thanks for that.

cmal11:08:14

(defn dynamic-rank [time]
  (fn []
    [:div.canvas-inner
     (doall
      (let [rank (shuffle (range 5))]
        (for [r    rank
              :let [i (.indexOf rank r)]]
          ^{:key r}
          [:div.canvas-rect
           {:style {:width (str (* 20 (inc r)) "px")
                    :top   (str (* i 30) "px")}}
           ])))]))

darwin11:08:02

@cmal: I don’t see keys on those divs

darwin11:08:04

if you open in in the devtools and observe changes, you must see that the divs are not being re-created, just updated in-place

cmal11:08:04

sorry , the build process has not finished

cmal11:08:26

@darwin how to judge one element is being updated or created? the yellow color?

cmal11:08:48

the build is finished now.

darwin11:08:14

devtools highlights DOM changes in the Elements panel, either it highlights only changed attrs in purple or element tag in purple (that means the whole element was re-created)

darwin11:08:53

the new version still doesn’t have keys

cmal11:08:33

I see the key in react devtools, but not in chrome devtools

darwin11:08:22

but I’m sorry, I’m not going to follow with you on this, I’m not very familiar with react

cmal11:08:38

Thanks a lot..

hparyani4911:08:21

how do integrate email in my cljs project

dnolen12:08:40

@tony.kay try master when you can, I reverted the loader validation stuff - I was on the fence about that anyway

tony.kay13:08:34

@dnolen Hm. That doesn’t give me an assertion error, but the module loading is failing. I’m not sure why. It pulls the js file for the module. Possible an exception is getting thrown from within my namespace before set-loaded! is reached? I also see a lot more network traffic on the load than I did before.

dnolen13:08:40

@tony.kay possible, you can break on caught exceptions

dnolen13:08:51

@tony.kay remember set-loaded! is mandatory now

tony.kay13:08:59

yeah, it is there.

dnolen13:08:00

if you’re not calling it you’re going to load stuff that’s already loaded

tony.kay13:08:19

I’m calling it for the entry point on application start, and at the bottom of the loaded module.

tony.kay13:08:39

It works fine if I pin the library ns into the entry point module

tony.kay13:08:05

well, it did last night. I have not tried that on this version, cause I thought you were indicating it would not be necessary

dnolen13:08:14

I said no such thing

dnolen13:08:19

you were talking about too many different things

dnolen13:08:34

but now getting to what you are saying

dnolen13:08:41

is this namespace an “orphan”?

tony.kay13:08:56

an orphan in the sense that I would prefer not to pin it to a module? Yes

tony.kay13:08:04

it is “library code”

dnolen13:08:09

but is it even in the dependency graph?

tony.kay13:08:17

yes, it is required in both namespaces from both modules

dnolen13:08:25

then I don’t see the problem

dnolen13:08:33

or how it’s related to what you are seeing

tony.kay13:08:51

I just pinned it, and it works again

dnolen13:08:58

when I say “orphan” I mean true orphan, unreachable

tony.kay13:08:06

no, def not unreachable

dnolen13:08:29

so just need to understand what you are trying to do here, I do not

dnolen13:08:43

this ns is going to end up in base for sure

tony.kay13:08:59

the code is very short

tony.kay13:08:12

the fulcro.client.routing ns is the ns in question

tony.kay13:08:25

(that is the code for the module to load)

dnolen13:08:25

right but this is all a distraction for me

dnolen13:08:38

since if I can understand what’s going on the other stuff doesn’t really matter

dnolen13:08:03

so this ns ends up in base and it calls load - but it fails to load

dnolen13:08:36

given that it calls load after someone called set-loaded!, base is definitely already marked as loaded

dnolen13:08:47

so I don’t really see what could be going wrong

tony.kay13:08:10

so, when I pin it, I only see the load of the module. When I don’t, it triggers a bunch of loads

tony.kay13:08:13

is that expected?

dnolen13:08:34

unless something I said isn’t true and you aren’t communicating that

dnolen13:08:58

my lines above are my hypothesis and conclusion

tony.kay13:08:22

it didn’t seem right to me either, but I am doing the things I said. I can check that the common ns is in base

tony.kay13:08:32

(using optimizations none)

dnolen13:08:42

what triggers the load?

tony.kay13:08:58

the load is triggered by the ns that is not pinned.

dnolen13:08:07

but “when”

tony.kay13:08:13

on user click of a route

tony.kay13:08:18

so user event well after app load

dnolen13:08:30

ok so now I have some advice

dnolen13:08:36

in a REPL check your assumptions

dnolen13:08:44

(cljs.loader/loaded? :cljs-base)

dnolen13:08:51

before you click around

tony.kay13:08:24

going to have to restart…give me a min. I was manually compiling to get other variables out of the way. Don’t have a repl

dnolen13:08:43

or you can print it somewhere

dnolen13:08:54

it should be true

dnolen13:08:23

(you do need to print it after the final statement of your entry point)

tony.kay13:08:54

yeah, just a sec. The project was configured for figwheel, but I removed it to prevent side-effects from that. Adding REPL support via cljs

dnolen13:08:57

so then confirm that was is loading makes some sense

dnolen13:08:03

it should be stuff that isn’t already in base

dnolen13:08:30

it should be obvious from quick eyeballing, loads will happen roughly in dep order

tony.kay13:08:38

I can verify from browser console that the common lib ns is there

dnolen13:08:54

I’m talking about the triggered load - does it make sense

tony.kay13:08:34

it does not, really. It is loading stuff that would have needed to be there for it to get where it already was

tony.kay13:08:48

or at least getting the events from BulkLoader

tony.kay13:08:13

that’s odd. It didn’t fail this time…well, at least not in the same way

dnolen13:08:10

ok, but I’m still concerned about stuff loading that was already loaded

dnolen13:08:42

haven’t seen anything like that nor how to reproduce it - so I would think something else is still wrong

tony.kay13:08:06

yeah, something is strange. It is loading now, and loaded? reports true for the module. But the callback didn’t seem to fire, either, and there are all the extra loads.

dnolen13:08:29

possibly those are all different issues

dnolen13:08:44

callback didn’t fire means loading failed

dnolen13:08:24

if loading fails, then there are retries

tony.kay13:08:51

yeah, it was retrying earlier…but now it reports success. The callback may have fired and I’m just not seeing what I expect

tony.kay13:08:01

but it works with the ns pinned, so the code should be right

tony.kay13:08:00

[111.927s] [goog.net.BulkLoader] All uris loaded.
console.js:203  [111.928s] [goog.module.ModuleLoader] Code loaded for module(s): main
console.js:203  [111.929s] [goog.module.ModuleLoader] evaluateCode ids:main
console.js:203  [112.032s] [goog.module.ModuleManager] Module loaded: cljs_base
console.js:203  [112.034s] [goog.module.ModuleManager] Module loaded: main
shows, but I have a debug message in my callback that is not showing.

tony.kay13:08:03

This is the start of the messages when triggering load for the module:

[111.787s] [goog.module.ModuleManager] Registering callback for module: main
console.js:203  [111.788s] [goog.module.ModuleManager] Initiating module load: main
console.js:203  [111.789s] [goog.module.ModuleManager] Loading module(s): main
console.js:203  [111.789s] [goog.module.ModuleLoader] downloadModules ids:main uris:js/demos/goog/json/hybrid.js,js/demos/goog/net/xmlhttpfactory.js,js/demos/goog/module/moduleinfo.js,js/demos/goog/html/legacyconversions.js,js/demos/goog/useragent/product.js,js/demos/goog/module/abstractmoduleloader.js,js/demos/goog/structs/simplepool.js,js/demos/goog/net/wrapperxmlhttpfactory.js,js/demos/goog/net/eventtype.js,js/demos/goog/module/module.js,js/demos/goog/module/moduleloader.js,js/demos/goog/module/basemodule.js,js/demos/goog/net/xhrlike.js,js/demos/goog/net/bulkloaderhelper.js,js/demos/goog/module/moduleloadcallback.js,js/demos/goog/net/bulkloader.js,js/demos/goog/net/errorcode.js,js/demos/goog/net/httpstatus.js,js/demos/src/main/yahoo/intl-messageformat-with-locales.js,js/demos/goog/debug/tracer.js,js/demos/om/dom.js,js/demos/clojure/walk.js,js/demos/cljs/spec/gen/alpha.js,js/demos/cljs/spec/alpha.js,js/demos/fulcro/client/util.js,js/demos/fulcro/i18n.js,js/demos/fulcro/client/mutations.js,js/demos/fulcro/client/impl/om_plumbing.js,js/demos/fulcro/client/impl/data_fetch.js,js/demos/fulcro/client/network.js,js/demos/fulcro/client/impl/application.js,js/demos/fulcro/client/core.js,js/demos/cljs/loader.js,js/demos/fulcro/client/routing.js,js/demos/recipes/dynamic_ui_main.js
console.js:203  [111.790s] [goog.net.BulkLoader] Starting load of code with 35 uris.

dnolen13:08:11

you keep going back to pinning the ns fixing the issue

dnolen13:08:19

but that isn’t telling us anything yet really

tony.kay13:08:54

it’s telling us that the ns itself doesn’t have syntax errors that are killing eval 🙂

dnolen14:08:39

yeah ok, but that’s about it 🙂

dnolen14:08:24

@tony.kay yeah I think we should understand why stuff is loading multiple times when you don’t pin

mhuebert14:08:39

Are there documented differences between js-this and this-as behaviour under advanced compilation? I am switching a bunch of uses of aget to goog.object/get and found cases where (gobj/get (js-this) "someProperty") returns nil, while (aget (js-this) "someProperty") and (this-as this (gobj/get this "someProperty")) both return the correct value

tony.kay14:08:20

would it be helpful to see the diff on cljs base between the two?

dnolen14:08:08

what you are describing sounds impossible to me

dnolen14:08:24

base is loaded, but then loads of stuff in base are triggered again

tony.kay14:08:57

it does seem that way. The namespaces in question already have defs at the js console, at least

tony.kay14:08:09

at least one or two that I’ve checked

dnolen14:08:50

@mhuebert ClojureScript compiler may introduce closures, this-as captures this and creates scope

tony.kay14:08:18

I just rebuilt with the common lib ns pinned to the entry point module, and it only triggers a load for the one new ns.

dnolen14:08:31

@tony.kay so the bug must be here

dnolen14:08:52

somehow loads are triggered for already loaded stuff

dnolen14:08:21

the only way for this to happen (w/o finding some other bug) is if what you said just isn’t true

dnolen14:08:26

your dep graph isn’t what you said it is

dnolen14:08:33

and pinning creates the right one

dnolen14:08:21

one thing to understand is that your pages must include all module script tags

tony.kay14:08:23

ok, answer this: is it only requires that generate the dep graph, or is something else involved?

dnolen14:08:39

cljs_base.js, vendor.js, my_module.js etc. in order

tony.kay14:08:06

oh wait…the HTML needs more than just base?

dnolen14:08:11

absolutely

dnolen14:08:13

this is in the docs

tony.kay14:08:13

I don’t have vendor stuff

tony.kay14:08:26

oh, but it isn’t geenrated if I don’t use it, right?

dnolen14:08:43

vendor this just an example

tony.kay14:08:52

yes, I have base and the entry point module.

mhuebert14:08:02

(.call (fn []
         (prn 1 (aget (js-this) "greeting"))
         (prn 2 (gobj/get (js-this) "greeting"))
         (this-as this
           (prn 3 (aget this "greeting")))
         (this-as this
           (prn 4 (gobj/get this "greeting"))))
       #js {:greeting "Hello"})
^^ #2 above prints nil, the rest print "Hello"

tony.kay14:08:48

I’m not using cljs_deps.js. Is that one needed to be explicit?

dnolen14:08:07

@tony.kay no cljs_base.js loads that for you

tony.kay14:08:15

ok, thought so

dnolen14:08:20

you should eyeball your :output-to files

tony.kay14:08:44

:compiler     {:devcards      true
                               :output-dir    "resources/public/js/demos"
                               :asset-path    "js/demos"
                               :preloads      [devtools.preload]
                               :modules       {:entry-point {:output-to "resources/public/js/demos/demos.js"
                                                             :entries   #{cards.card-ui }}
                                               :main        {:output-to "resources/public/js/demos/main-ui.js"
                                                             :entries   #{recipes.dynamic-ui-main}}}
                               :optimizations :none}}

dnolen14:08:44

you should also check that cljs_deps.js looks ok

dnolen14:08:56

@tony.kay I mean the actual files

dnolen14:08:04

@mhuebert hrm strange, maybe some JS weirdness here?

dnolen14:08:48

@tony.kay the other thing is at the JS console you should look at goog.dependencies_.nameToPath

dnolen14:08:19

one problem I saw until I made some fixes is that goog/base.js would be loaded multiple times - that breaks everything

mfikes14:08:12

@mhuebert The problem seems to be related to :static-fns, not :advanced

tony.kay14:08:20

OK, here’s some info: The diff between base and deps on the pinned vs non-pinned js files are identical. The only difference is that when I pin the common lib ns, the diff of the entry point module now includes it in a goog.require (where it didn’t before).

tony.kay14:08:11

but deps does show the pinned file as being needed by the entry point code

mhuebert14:08:18

@mfikes I’ll try with both. I didn’t have a :static-fns option set on that build

mhuebert14:08:21

@mfikes ok you’re correct, with :static-fns false it works, :static-fns true it’s nil

mfikes14:08:44

For reference here is the JavaScript generated for each: https://gist.github.com/mfikes/da1d13186cb6f8ff38689c8791306fa3

mhuebert14:08:18

@mfikes thanks for that gist! seems odd that it is creating a new anonymous function there

mfikes14:08:24

@mhuebert My initial reaction is that your 4th form is correct, and the 2nd isn’t (additionally the 2nd is using a private macro)

tony.kay14:08:41

@dnolen So, without the explicit pin, I am getting a load of basemodule.js: [ 12.734s] [goog.net.BulkLoader] Received event “complete” for id 11 with uri js/demos/goog/module/basemodule.js

tony.kay14:08:48

among others

tony.kay14:08:00

[ 12.741s] [goog.net.BulkLoader] Received event “complete” for id 15 with uri js/demos/goog/net/bulkloader.js

tony.kay14:08:05

that one also seems pretty odd

tony.kay14:08:28

and module, moduleloader,e tc.

dnolen14:08:39

right that’s what I was saying

dnolen14:08:43

this should be impossible

dnolen14:08:47

already loaded

tony.kay14:08:26

not sure what you want me to look at in nameToPath…it has a lot of stuff. I take it this is just the way it knows a module name’s path

tony.kay14:08:29

looks ok to me

dnolen14:08:08

@tony.kay everything should be there is all

dnolen14:08:05

also examine (.-moduleInfoMap_ cljs.loader/*module-manager*)

tony.kay14:08:06

it has js objects for the three (base, entry point, and module to load)

tony.kay14:08:12

(I’ve loaded at this pt)

dnolen14:08:29

yes but do the contents make sense?

dnolen14:08:51

each entry is a module with uris_

tony.kay14:08:14

but URIs in that is wrong

tony.kay14:08:46

Yeah, the module info for the module to load has all that extra crap in it

mhuebert14:08:55

@mfikes yeah, the generated code for the 2nd looks right. it seems strange that the :static-fns option would wrap a call to gobj/get in an anonymous fn

tony.kay14:08:21

I’m calling it :main…that isn’t the issue I hope (name collision?)

dnolen14:08:04

hrm it shouldn’t matter but try

tony.kay14:08:31

just a sec…that’s a bit of a refactor

dnolen14:08:34

@tony.kay what you are saying though it sounds like you have a module graph with dupes

dnolen14:08:50

:main just doesn’t sound important to me - I would drop that for now

mfikes14:08:40

@mhuebert My guess, is that, since you used (js-this) you are referring to something in a larger scope, forcing it to essentially treat it like a let binding. Just like the code you get for

(let [k "hello"]
  (gobj/get #js {:greeting "hello"} k))
which is
(function (){var k = "hello";
return goog.object.get(({"greeting": "hello"}),k);
})()

mfikes14:08:50

Perhaps the aget avoids the issue given that it itself is a macro. Dunno (haven’t looked into it deeply)

tony.kay14:08:51

Yes, I can verify that things appear in cljs_base also appear in the module to load. ok, why would I have dupes?

dnolen14:08:24

@tony.kay and you don’t have circular deps?

tony.kay14:08:21

shouldn’t have. Wouldn’t the compiler puke on that?

dnolen14:08:43

not necessarily under :none

dnolen14:08:57

but that’s def the bug

dnolen14:08:03

duped entries

tony.kay14:08:10

I just eyeballed it…for the three files involved, I don’t. But there are a lot of files in the project.

dnolen14:08:14

a second load of critical nses is guaranteed to break stuff

tony.kay14:08:38

if I crank up optimizations will it detect circs?

dnolen14:08:13

it should yes, are you trying to load :main from :entry-point?

tony.kay14:08:26

no, :main gets loaded from the library ns

dnolen14:08:42

what you’re saying doesn’t make sense

tony.kay14:08:58

that saddens me 😕

dnolen14:08:00

are you saying it gets loaded via user interaction, yes or no?

dnolen14:08:10

we just need to be clear w/ our language here 🙂

tony.kay14:08:25

yes. The user interaction happens on entry point, but entry point runs a mutation that triggers code in a diff ns that does the load

dnolen14:08:47

so :main gets loaded from :entry-point effectively

dnolen14:08:49

that’s all that matters

tony.kay14:08:02

just want to be clear because ns used to matter

dnolen14:08:43

and do both :main and :entry-point dupe :cljs-base ?

tony.kay14:08:43

I tried simple optimizations. No warnings….but is broken worse.

dnolen14:08:07

(sounds like a bad dep graph to me, but withholding that conclusion for now)

tony.kay14:08:28

There has to be something going on in my project that just isn’t right, I think

tony.kay14:08:25

let me make sure something stupid like tools ns refresh isn’t getting hit during compile. I’ve had problems there before.

tony.kay14:08:01

Hm. Nope. I cleared up the source path to make sure. Still same problem.

dnolen14:08:35

@tony.kay if you use :verbose with higher optimization setting you will see output info about :modules and where entries are assigned

tony.kay14:08:11

I definitely see dupes between base and the module that is to be loaded

tony.kay14:08:07

I don’t even understand how this can be remotely right

tony.kay14:08:21

cljs.loader is only listed in the module to be loaded

tony.kay14:08:08

as is goog.module.ModuleLoader

tony.kay14:08:53

but when I pin the library ns to the entry point, it all clears up and looks fine…

tony.kay15:08:27

Building module :main
  adding entry (recipes.dynamic-ui-main)
  module :main depends on :cljs-base

tony.kay15:08:51

is exactly what I’d expect. But without pinning the library ns to the entry point, I get a bunch of stuff that makes no sense

tony.kay15:08:51

NOTE: the lib ns ends up listed in the module to load if it isn’t pinned

tony.kay15:08:14

but that ns is used by the entry point code

tony.kay15:08:56

and it is only listed in the “wrong place” if it isn’t pinned.

tony.kay15:08:38

(as in it isn’t a dupe)

dnolen15:08:10

so none of the things you are saying make sense and we have tests for that 🙂

dnolen15:08:35

if a ns is shared, it is automatically lifted to the deepest parent module

tony.kay15:08:43

So I guess it must be something in my project…but I cannot guess what

tony.kay15:08:01

Let me pull this out of devcards. Possibly that is confusing things

tony.kay15:08:42

that may have fixed it

tony.kay15:08:03

yeah, I think it is working now.

tony.kay15:08:59

not sure why that fixed it. Recompiling to make sure

tony.kay15:08:22

verified. works now

dnolen15:08:35

so maybe devcards has a problematic dep graph?

tony.kay15:08:04

possibly? That sucked 😛

dnolen15:08:22

also you wouldn’t see this under :optimizations since you probably have a different build sans devcards

tony.kay15:08:35

I was jsut editing the build

dnolen15:08:51

what did you change, just dropped devcards?

tony.kay15:08:16

yeah, I moved the app out of a card and mounted directly on DOM. But that also changed by dep graph

tony.kay15:08:32

cause I changed the entry point from the devcards UI to just my main code

tony.kay15:08:14

Does this ring any bells?

Uncaught TypeError: Cannot read property 'isValidElement' of undefined
    at Object.r.23.112 (cljs_base.js:sourcemap:12)
    at o (cljs_base.js:sourcemap:12)
    at cljs_base.js:sourcemap:12
    at Object.r.38.112 (cljs_base.js:sourcemap:13)
    at o (cljs_base.js:sourcemap:12)
    at cljs_base.js:sourcemap:12
    at Object.r.31.10 (cljs_base.js:sourcemap:13)
    at o (cljs_base.js:sourcemap:12)
    at cljs_base.js:sourcemap:12
    at Object.r.47.1 (cljs_base.js:sourcemap:14)

tony.kay15:08:27

cause that’s what I get (still) with :simple optimizations

tony.kay15:08:36

though the module output list is correct

dnolen15:08:15

doesn’t mean anything to me

tony.kay15:08:14

So, not a very good result overall 😕 Seems there are ways of making it lose its mind that remain a bit of a mystery

dnolen15:08:54

unfortunately what you’re doing sounds pretty dense wrt. moving parts

tony.kay15:08:01

I know. sorry

dnolen15:08:07

testing :modules with random tooling is not practical

dnolen15:08:46

however there is a way for me to repro

dnolen15:08:54

all I need is your :modules which I have above

dnolen15:08:01

and all inputs

dnolen15:08:10

and then I can run the module graph code on that to see how it gets messed up

dnolen15:08:22

one second

tony.kay15:08:09

well, but it only messes up in the presense of the tool stack

dnolen15:08:22

tool stack is not relevant

dnolen15:08:39

you got an impossible module graph

dnolen15:08:50

if we can detect that then we can at least maybe figure out blame

tony.kay15:08:13

well, but something in the tool stack is what has the trigger to it

dnolen15:08:33

sure but I’m just not concerned about that

dnolen15:08:47

good blame would be enough and then fixes can start there

dnolen15:08:59

@tony.kay I added :debug-inputs to master

dnolen15:08:18

this will dump all compiler inputs, please email me the result as an EDN file

dnolen15:08:39

then I can see how you ended up with a bad module graph given your :modules

tony.kay15:08:08

ah, ok, I see. I was thinking reproducible case and you have an alt route. Got it.

dnolen15:08:53

@tony.kay gotta step away for a bit, but will be back online later to look at this issue

tony.kay15:08:57

where is the file?

dnolen15:08:07

what file?

tony.kay15:08:15

the EDN it generates

dnolen15:08:21

it doesn’t generate anything

dnolen15:08:29

copy and paste it and email me 🙂

dnolen15:08:35

it’s just prints to standard out

mhuebert15:08:07

@mfikes so the act of calling (js-this) ends up generating a closure around its parent form which has a new this context

mfikes15:08:32

(js-this) simply macroexpands into (js* "this")

mhuebert15:08:47

right, I mean what the compiler is doing in response to that

mfikes15:08:13

OK. I haven’t delved into the compiler behavior

mhuebert16:08:58

so generally, if we need to use this inside a function, we should wrap the interior of the function with (this-as <some-sym>) and use <some-sym>, because at any other point inside the function, the compiler may create closures which change what this points to, and these closures aren’t represented lexically, nor are they predictable across different compile options

noisesmith16:08:53

intuitively I would expect the compiler to munge the arg to this-as, even if it was named this in my code

mhuebert16:08:34

@noisesmith yeah in the example that mfikes made (https://gist.github.com/mfikes/da1d13186cb6f8ff38689c8791306fa3) we see the compiler generating code like this$ = this and this_22 = this

mfikes16:08:28

You can get functions being generated for let forms. What’s odd in this case is there is no let form, but perhaps it is the same in the end: perhaps the compiler is generating a closure in order to access it. It is an interesting case.

mfikes16:08:06

Also, @mhuebert, it isn’t clear to me that js-this is meant for use in application code (it is marked as private)

mhuebert16:08:27

@mfikes ah I didn’t notice that

mhuebert16:08:42

it would make sense then that the behaviour can be unpredictable

mfikes16:08:59

Yeah, that’s consistent with it lacking a docstring, etc

tony.kay20:08:55

@dnolen So, I can verify that with a very bare-bones example that module loading works as expected now. Both with none and advanced optimizations.

tony.kay20:08:50

Next, in a more complex project, it works fine with no optimizations. However, all other optimization levels in my project seem broken. Won’t even start. Without modules, the program works fine (including all optimization levels). Not sure how to narrow that down. It seems to be React-related in at least a few of the levels (e.g. functions get renamed erratically or removed when they shouldn’t).

tony.kay20:08:35

That repo has three branches of interest: master is the minimum example, which works fine. The other two are minimal examples that leverage Om Next with Fulcro. The one without modules works for all opt levels. The one with modules works, but only for optimization none. They use a simple Python web server, and a shell script for build.

tony.kay20:08:22

(run.sh and build.sh)

tony.kay20:08:55

Hm. it is possible I did something wrong with respect to my i18n code…I use a raw js file and I didn’t configure it as a foreign lib

tony.kay20:08:00

well, I have a deps.cljs file for it, so actually, I think I did

lambdahands23:08:45

Hey y'all. I've been scratching my head for a few hours now trying to figure out an issue I'm having with compiling my project in development (`:optimizations :none`). I get an error that doesn't point to a line, just the file:

----  Could not Compile  /Users/lambdahands/<truncated>/db.cljs   ----

  failed compiling file:/Users/lambdahands/<truncated>/db.cljs 

----  Compiler Error : Please see /Users/lambdahands/<truncated>/db.cljs  ----
Mind you, I don't see this issue in advanced compilation, and the file isn't doing anything special, simply a few spec definitions and an initial UI data structure. Running it through planck doesn't show any errors either. I'm running this through boot and compiling with Figwheel 0.5.12 and the latest ClojureScript 1.9.854. Here's a gist of the file I'm attempting to compile: https://gist.github.com/lambdahands/6e1bded0fafa316c709dd5acfd83108c

lambdahands23:08:47

Also, I did recently upgrade to 1.9.854 - this file hasn't changed in our codebase since April or so

lambdahands23:08:49

(on a side note I upgraded our entire application to the Clojure 1.9 alpha in a debugging hail mary, and it was super painless! 😄)

lambdahands23:08:56

Aha! This is a classic "post your problem to Slack and the find the line that's causing it five minutes later" - so the following compiles:

#(re-matches #".+@.+\..+" %)
The following does not:
(s/def ::email #(re-matches #".+@.+\..+" %))

mfikes23:08:28

@lambdahands I can't repro:

$ java -cp ~/Downloads/cljs.jar:src clojure.main -m cljs.repl.node
ClojureScript Node.js REPL server listening on 50587
To quit, type: :cljs/quit
cljs.user=> *clojurescript-version*
"1.9.854"
cljs.user=> (require 'wont-compile)
WARNING: wont-compile is a single segment namespace at line 1 /Users/mfikes/Desktop/src/wont_compile.cljs
nil
cljs.user=> (dir wont-compile)
accounts-form
default-state
form-specs
users-form
nil

mfikes23:08:16

cljs.user=> (require '[clojure.spec.alpha :as s])
nil
cljs.user=> (s/def ::email #(re-matches #".+@.+\..+" %))
:cljs.user/email
cljs.user=> (s/valid? ::email "")
true

lambdahands23:08:41

Hmm, interesting - I wonder if there's a dependency causing this?

mfikes23:08:01

What error do you get when evaluating (s/def ::email #(re-matches #".+@.+\..+" %))?

lambdahands23:08:40

I actually don't get an error unless I uncomment that line in my project file and run through Figwheel - plank seems to accept my file OK

lambdahands23:08:20

But the project compilation fails with this:

----  Could not Compile  /Users/lambdahands/<truncated>/db.cljs   ----

  failed compiling file:/Users/lambdahands/<truncated>/db.cljs 

----  Compiler Error : Please see /Users/lambdahands/<truncated>/db.cljs  ----

mfikes23:08:28

If you have a REPL, perhaps you can try (require 'wont-compile :reload) to see if you get any error reported back that way

lambdahands23:08:35

Hrm, just tried and I get the same error in my REPL

mfikes23:08:59

Do a (pst), to see if you get more info

lambdahands23:08:29

Even stranger, I can compile that code running in the browser REPL

lambdahands23:08:35

I get nil after a (pst)

mfikes23:08:28

If you evaluate a require form, I wouldn't expect Figwheel to be involved (presuming Figwheel is the thing indicating the compiler errors you pasted above)

lambdahands23:08:01

That's a good point - maybe I should investigate in #lein-figwheel ?

mfikes23:08:27

Perhaps. But require is simply a macro that expands to an ns* special form.

mfikes23:08:40

There ain't much Figwheel can do to break that in any way 🙂

mfikes23:08:05

Unless... I wonder if you have require as a REPL special?

lambdahands23:08:18

Ah, I see - a REPL special?

mfikes23:08:21

Do a (doc require) to see if it is a macro

lambdahands23:08:37

Yep, it returns a macro

mfikes23:08:40

Yeah, require used to be a REPL special—a special form implemented in the REPL

lambdahands23:08:12

I have a feeling this could have something to do with some code on my classpath, but even after wiping it clean I still get the error

lambdahands23:08:16

Oh, interesting

mfikes23:08:35

Well, perhaps check to see what is in db.cljs, since it seems to be complaining about that namespace 🙂

lambdahands23:08:47

Is there any chance that the def macro in spec thinks my regex is a Java regex?

mfikes23:08:22

Yes... the reader will first read the regex as a Java regex

mfikes23:08:06

It has to be temporarily read in as a Java value, and then later the JavaScript equivalent is emitted

mfikes23:08:29

(This differs from self-hosted, where the reader reads regex's in as JavaScript regexs.)

mfikes23:08:28

At a certain point recently ClojureScript started using tools.reader so you may be on to something

lambdahands23:08:22

I'll see if I can find a way to reproduce then!

mfikes23:08:53

@lambdahands If it really turns out to be an issue with it temporarily being read in as a Java regex, I suppose you could work around it by having the reader only read symbols and strings via (js/RegExp. ".+@.+\\..+")