This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-20
Channels
- # arachne (11)
- # aws (2)
- # beginners (33)
- # boot (167)
- # cider (71)
- # clara (2)
- # cljs-dev (28)
- # cljsrn (3)
- # clojars (1)
- # clojure (83)
- # clojure-austin (21)
- # clojure-dev (24)
- # clojure-russia (19)
- # clojure-spec (33)
- # clojure-uk (108)
- # clojurescript (114)
- # component (1)
- # core-async (1)
- # cursive (7)
- # datomic (13)
- # editors (1)
- # emacs (15)
- # hoplon (10)
- # lein-figwheel (4)
- # leiningen (3)
- # mount (2)
- # om (134)
- # om-next (4)
- # onyx (42)
- # pedestal (41)
- # quil (2)
- # re-frame (29)
- # reagent (4)
- # remote-jobs (6)
- # ring-swagger (5)
- # untangled (9)
@bronsa I’m working with some tools.analyzer.jvm stuff and I wanted to just check that my understanding is correct. What I would ideally like is that analyze+eval of an (ns foo)
form would result in some observable change to the (new) current namespace. So my question is just verifying that there is nothing to do that “automatically” right now, right?
it seems like the expanded ns form contains the call to (in-ns ) with a resulting :env and the new :ns in it which I could find and apply to the next call in its env :ns
the greater context is in analyzing a .clj file without a priori knowing its namespace. I might just change that aspect instead, just trying to decide.
oh, and a 2nd question I haven’t tried to answer myself is whether its possible to control gensym creation in analyzer macro expansion so its repeatable
@alexmiller so in *ns* = 'user
, you'd like (analyze+eval '(ns foo))
to "report" that the current namespace got changed?
there's no available built-in that does that, other than inspecting the :env ns of the value next to in-ns
, or doing a backup of the current *ns*
pre analyze+eval and manually checking for change
ok, I didn’t look at *ns*
but that would work
I can also see the change in the :namespaces of the global env, but that’s a little indirect
re: 2nd question I think with-redefs of gensym
before analyze+eval
is the only way to do it
cool, I will give that a shot at some point
thank you for the quick read
what I’d like is to get something repeatable if I grab the form for an analyzed expression
btw if you're running analyze+ns on a full file, consider using analyze-ns
or look at its code and adapt it, there are a few gotchas that needs to be handled correctly
I’m actually trying to avoid analyze-ns as I need more reader control
but I have been looking at the code
and I am adapting parts of it
thank you for its existence :)
if that's the case you can probably control it by monkey-patching bits of the uniquify
pass
won’t locals-counter in there be dependent on what’s already been analyzed?
I haven’t looked at this in a couple months, so apologies I don’t have it at top of mind. was just asking while bothering you on other things. I think I’ve got enough pointers to be dangerous for now.