This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-06
Channels
- # 100-days-of-code (15)
- # beginners (32)
- # calva (2)
- # cider (37)
- # clara (1)
- # cljs-dev (47)
- # clojure (177)
- # clojure-boston (1)
- # clojure-dev (2)
- # clojure-germany (1)
- # clojure-greece (5)
- # clojure-italy (13)
- # clojure-nl (2)
- # clojure-sanfrancisco (1)
- # clojure-uk (72)
- # clojurescript (46)
- # cursive (20)
- # datascript (7)
- # datomic (14)
- # devcards (6)
- # docker (1)
- # duct (1)
- # emacs (1)
- # figwheel (3)
- # figwheel-main (151)
- # graphql (2)
- # hyperfiddle (1)
- # interop (3)
- # jobs (3)
- # lumo (2)
- # off-topic (21)
- # pedestal (1)
- # re-frame (9)
- # reagent (25)
- # shadow-cljs (57)
- # slack-help (4)
- # specter (21)
- # tools-deps (53)
- # vim (2)
I'd like to assign https://dev.clojure.org/jira/browse/CLJS-2868 to Martin Kučera to ask if the CA has been signed, but I can't find his name or ID in the assign dropdown…
With <mailto:[email protected]|[email protected]>
(Sorry to bother you @kucerm2... I couldn't find a way to ask you via JIRA about the above. 🙂 )
hey @mfikes if I wanted to try to push https://dev.clojure.org/jira/browse/CLJS-1628 forward, do you think that would be worthy? it is really kind of terrible when this bug hits because it can happen when trying to print out diagnostics, which totally hides the original problem
Yeah, I honestly don’t know what the protocol / etiquette is in a case like that. If it were me I’d ping Roman and see if he’s given up on it or forgot, etc.
It is extremely gross, but might be worth it for this bit of tight-loop code: https://dev.clojure.org/jira/browse/CLJS-2894
@dnolen & @mfikes: these performance optimizations y'all have been doing are amazing! Much kudos and appreciation!
Cool. I have a follow up tweak / fix. Still testing some more and will assign to you in a bit.
(Hah, rough calculations show that this particular bit of code is executed billions of times in the Coal Mine test, so going for AtomicLong
ends up mattering.)
yeah I saw the source mapping updates were in the inner loop, but I didn’t think to do anything about it
btw the source-map data also contains a lot of data that I think might not actually be useful. I didn't check how those work yet but the source-map data is huge and writing it as cache to disk often takes longer than the actual compile.
{:gcol 6, :gline 1473, :name "cljs.core/missing-protocol"}
{:gcol 33, :gline 1473}
{:gcol 0, :gline 1479}
{:gcol 0, :gline 1479}
{:gcol 51, :gline 1479}
{:gcol 0, :gline 1480}
{:gcol 0, :gline 1480}
don't know how relevant all those lines without :name
are but there are a lot of those
I remember recalling that dropping stuff even if it doesn’t have names leads to problems - was long time ago though
quite possible. I have no idea how the encoding process works. just looked odd to me to have so many entries without :name
e.g. if there is one entry at each expression boundary, then could breakpoint down to the expression level even if unnamed?
makes sense. but why would there be so many :gcol 0
? like in the snippet I posted above. the same entry is repeated for 1479
and 1480
{:gcol 55, :gline 33804, :name "cljs.core/PROTOCOL_SENTINEL"}
{:gcol 0, :gline 33806}
{:gcol 0, :gline 33806}
{:gcol 0, :gline 33806}
{:gcol 0, :gline 33811}
{:gcol 0, :gline 33811}
{:gcol 0, :gline 33811}
{:gcol 0, :gline 33811}
I don’t think macroexpansion comes in here, I think we only generate source map stuff during emission
wouldn't it depend on how the line+col metadata was copied into the new AST made by macroexpansion?
FWIW, Planck culls a lot of stuff out of the source maps specifically so they can be loaded quickly.
Here is the fn of interest that does that https://github.com/planck-repl/planck/blob/2014da4d470d4811f3907b35e5ae129d7e27d1a2/planck-cljs/src/planck/repl.cljs#L1388-L1402
^ This code has been in place for about a year, with no problems. It made source map handling in Planck be instant, rather than several seconds. It would be nice if we did something similar in ClojureScript proper.