Fork me on GitHub

In anger, but stack traces will be correctly mapped soon 😄


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


@mfikes thanks! I think @anmonteiro was already looking at that 😄 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)


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


just checked this....this code should go to core for bootstrap so that we save up some memory while running! 😄


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


I was scanning the commits today for things to port over


and it is pretty time consuming 😄


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


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


yep, this is not really upstream though, is more "lateral" 😄


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


oh that would be fantastic


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


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


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


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


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


@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


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


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