This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-06-14
Channels
- # announcements (2)
- # aws (12)
- # aws-lambda (5)
- # beginners (42)
- # calva (56)
- # cider (16)
- # clj-kondo (1)
- # cljs-dev (45)
- # cljsjs (1)
- # cljsrn (25)
- # clojure (171)
- # clojure-europe (3)
- # clojure-italy (16)
- # clojure-losangeles (2)
- # clojure-nl (49)
- # clojure-spec (2)
- # clojure-sweden (3)
- # clojure-uk (11)
- # clojurescript (84)
- # component (11)
- # core-async (12)
- # core-logic (2)
- # cursive (8)
- # datomic (41)
- # events (2)
- # fulcro (48)
- # graalvm (1)
- # graphql (1)
- # hoplon (12)
- # jackdaw (1)
- # jobs (1)
- # jobs-discuss (45)
- # joker (5)
- # keechma (10)
- # nyc (3)
- # off-topic (14)
- # pathom (16)
- # qa (1)
- # re-frame (22)
- # reagent (12)
- # reitit (4)
- # remote-jobs (1)
- # shadow-cljs (40)
- # spacemacs (3)
- # timbre (3)
- # tools-deps (29)
Can I use cljs.analyzer.api
to analyze a whole project, obtaining a large map with all kind of info?
Envisioned usage: I analyze a project -> I inspect the resulting map -> I can query with all accuracy the type/metadata/... of symbols at an arbitrary point (e.g filename f
, line 30, column 10)
nice! how does one do it? the api shows how to analyze one file, not a whole project. not sure if one has to manage traversal himself or...?
in shadow-cljs I could tell you how to get access to the complete build state after compilation
> in shadow-cljs I could tell you how to get access to the complete build state after compilation this would be usable for me, feel free to share 🙂
but it contains a :compiler-env
key which is the entire analyzer data from that build
> but it contains a :compiler-env
key which is the entire analyzer data from that build
awesome stuff.
so (keys (get-in build-state [:compiler-env :cljs.analyzer/namespaces 'cljs.core :defs]))
or so
> well what in particular are you trying to do? let's make an hypothetical example, a "find usages" API, for accurate refactoring
but the basics are: read forms using tools.reader, analyze it, process AST in any way you need
doing that for the entire build is where things get a bit more complicated since you have to analyze things in the correct order and so on
> but the basics are: read forms using tools.reader, analyze it, process AST in any way you need would seem less accurate than a project-wide analysis, right? anyway, thanks for all the help, now I can understand the landscape better!
well yes you process the entire project that way and produce whatever data you need. ie. a call graph
anyone know of a reason logging to the console from a goloop would be broken in IE11?
are there any clojurescript http libraries that play well with Transfer-Encoding: chunked
?
Can anyone explain the technical differences between (.log js/console :foo)
and (js/console.log :foo)
. It seems the async macros are particularly sensitive to the difference in a goloop
@dpsutton here is a mfikes answer http://tank.hyperfiddle.com/:dustingetz.storm!view/~entity('$',(:dustingetz.post!slug,:cljs-js-console-log-future-proof))
interesting. well i seem to have found an interesting case in IE11 with the dev console closed lol
@dpsutton I've written more on the subject here https://stackoverflow.com/questions/49502163/most-idiomatic-way-to-console-log/49848990#49848990
Thanks for this
thanks very much @mfikes. I think i was wrong and this is unrelated to the distinction between (.log js/console
and (js/console.log
. Hard to pin down a smallest reproduction in the app
cljs.user=> (macroexpand '(.log js/console))
(. js/console log)
cljs.user=> (macroexpand '(js/console.log :foo))
(js/console.log :foo)
@dpsutton coreasync treats the first one speciallyThis is why core.async
has heartburn with and
and or
cljs.user=> (let [x true y false] (macroexpand '(and x y)))
(js* "((~{}) && (~{}))" x y)
cljs.user=> (macroexpand '(and a b))
(let* [and__4120__auto__ a] (if and__4120__auto__ (cljs.core/and b) and__4120__auto__))
I think what happens is that you might have some code that does indeed get inferred in a way that causes js*
to be emitted, and then core.async
will lift things out of the js*
special form, IIRC, cause some sort of breakage. Let me see if I can find the JIRA.
The way I look at it, just like if
is a special form that can suppress evaluation of its arguments, js*
can essentially do the same.
Interesting. At first blush, this makes me think it might be an easy fix. Just teach it that js*
is special, and don't rearrange code involved with it. But I have a naïve understanding of core.async
at best.
> It is too hard to remember to not use and
and or
in go
blocks, though, to be honest.
i've never even heard that folklore, that's wild
I think it only matters if you are passing things in where the failure to short-circuit can bite you, owing to side effects