Clojurians
#lumo
<
2018-02-08
>

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

richiardiandrea02:02:03

In anger, but stack traces will be correctly mapped soon :smile: https://github.com/anmonteiro/lumo/pull/349

mfikes19:02:48

@richiardiandrea If you end up bundling the core namespace map files, I’d recommend taking a look at what Planck does. In particular, delay loading them until they are actually needed (when a stack trace needs to be mapped), because they are expensive to load. Also, Planck reduces the source map files to the bits that actually matter, so when they are loaded, this is done nearly instantly, as opposed to taking several seconds.

richiardiandrea19:02:50

@mfikes thanks! I think @anmonteiro was already looking at that :smile: My PR at the moment just enables inline map parsing from the :source-maps key that as you saw in #cljs-dev was bumpy. It works with workarounds and some things maybe not fully understood on my side (the ?rel= for instance, seems unnecessary in node)

mfikes19:02:55

Ahh, cool. Yeah, I wonder if Node even honors the inlined source maps. It was my vague impression that they could be parsed out by browsers and used if an exception occurs there, but JavaScriptCore in Planck definitely treats it as an unecessary comment. :slightly_smiling_face:

richiardiandrea19:02:05

@mfikes what do you think about tagging commits/issue with a label that says "look lumo/planck", this might be interesting for you

richiardiandrea19:02:22

I was scanning the commits today for things to port over

richiardiandrea19:02:30

and it is pretty time consuming :smile:

mfikes19:02:50

Sounds fine with me. One thing I tend to do, which might be similar, is tag issues as being upstream.

mfikes19:02:09

But, there are a class of issues that are not upstream and affect both Lumo and Planck.

richiardiandrea19:02:13

yep, this is not really upstream though, is more "lateral" :smile:

mfikes19:02:43

I don’t mind actually logging an issue in Lumo when I find one in Planck.

richiardiandrea19:02:56

oh that would be fantastic

mfikes19:02:17

In other words, I don’t mind trying a quick repro and logging one in Lumo’s issue list.

richiardiandrea19:02:02

ok then...I think we don't need a label if we do that

richiardiandrea19:02:56

but I don't know if you need it as well

richiardiandrea19:02:56

see the two issues I opened in CLJS as well: CLJS-2492 & CLJS-2493

mfikes19:02:41

Hmm. Not following completely @richiardiandrea. I’ll look more deeply. For now, this Planck behavior seems correct:

(ns foo.user-with-underscores)

(defn try-it []
  (ffirst 1))
cljs.user=> (require 'foo.user-with-underscores)
nil
cljs.user=> (foo.user-with-underscores/try-it)
1 is not ISeqable
	seq (cljs/core.cljs:1212:20)
	first (cljs/core.cljs:1221:15)
	ffirst (cljs/core.cljs:1733:11)
	foo/user-with-underscores/try-it (foo/user_with_underscores.cljs:3:29)

richiardiandrea19:02:34

@mfikes looks correct yep! Are you populating :source-maps in any way. I completely rely on what's set by ClojureScript. There is something else to say, I might have fixed the problem without knowing the cause

mfikes19:02:16

I don’t recall. There is plenty of stuff I have Planck do to work around various things.

richiardiandrea19:02:57

actually I am thinking now that the :file key that I pass to *load-fn* might be used in the :file of the source map...so lumo maybe is not passing it correctly or something...I will check js.cljs again