Fork me on GitHub

(let [conj! (fn [] (prn 10))]

(let [set! (fn [] (prn 10))]


first works, second causes syntax error, the reason is because set! is special form ?


i know that we cant do this for if also


we can't ovverride all special forms?


special forms (lists that start with a symbol that the compiler assigns explicit meaning to) will always be compiled as the special form, regardless of any variable shadowing


ok thank you hiredman, i forgot this again and i was stuck sometime


it can be confusing because the line between special form and macro gets a little blurry sometimes, and macros do allow shadowing


for example. the doc string for let and fn both claim to be special forms, but are in fact macros, and the shadowing behavior is the macro one


user=> (let [let (constantly nil)] (let 1))
user=> (let [fn (constantly nil)] (fn 1))
user=> (let [try (constantly nil)] (try 1))


ok thanks, so macro can be shadowed also, if needed i can test it, but those are rarely needed, i am just making DSL thing


so happened


I have an app that uses dependency A, which in turn has a dependency on B-vX, but the app excludes dependency B and declares a dependency on B-vY. The app is also using a library that I am working on, this library also depends on A. Might this cause problems for the app? Specifically in this case A is com.taoensso/timbre and B is com.taoensso/encore. Ideally I'd like for the app to be able to inject a logger, but for now I just want to know what I can do to not mess it up for app while still using timbre in the library.


Just what you describe in your first sentence can cause problems for the app. The only way to come close to a guarantee not to mess this up is to check why particular libraries depend on particular versions. Or to exhaustively test everything. Neither can provide a 100% guarantee of course. Also, if you see that timbre uses an older version of encore, it might be worth it to just ask Peter Taoussanis to update timbre so it uses the latest version of encore.


Thanks! What I describe first there is battle tested in the app. The way this organization operates makes me think it was also pondered hard before being configured the way it is. (But that's speculation)


If I make the apps dependency on ”my” library also exclude encore, would that shrink the risk any?


Exclusion is just a way to prioritize your classpath. If the app depends on B-vY, I'm 90% certain there's no need to exclude B anywhere as the app's dependency will simply override all transitive dependencies.


That makes it clearer for me. Thanks! I'll ask around to see why we have this B-vY thing in there.

👍 1

We're on timbre 4.0.10 still, which is probably the reason. I'm guessing Peter T is not so interested in patching that one. 😃

Noah Bogart16:03:32

with-redefs question: i have a function exception-helper which uses timbre/error to print certain information about the exception i'm catching (inside a custom catch* macro). i'd like to silence that logging during certain tests where i deliberately throw an exception to test certain code-paths. in my test, if I write (with-redefs [taoensso.timbre/error (constantly nil)] ...), the error still prints because the with-redefs call didn't bind. If I change the invocation in exception-handler to (#'timbre/error exc "Exception happened"), the with-redefs call binds correctly. is there someway I can do this rebind without modifying the originating call?


couldn't you set the level in your tests?

👍 1
Ferdinand Beyer16:03:49

@UEENNMX0T I think the problem you are facing is that timbre/error is a macro, not a function. From what I can see all logging macros in Timbre end up at timbre/-log!, maybe you can redef this? Or as @U4YGF4NGM mentioned, can you use a test fixture that silences timbre using a special config?

Noah Bogart16:03:04

setting the level is smart. and i did not realize that timbre/error was a macro, that probably explains it.

Ian Fernandez23:03:16

I have a require that is executing an IO that interacts with a global state that I'm dealing with, how can I trace the execution inside a (ns ,,, :require [,,,,]) statement to see which one executes the stuff that I'm looking for?

Ian Fernandez23:03:44

Is there some kind of :verbose for ns statement?


(the docstring for ns says :require supports the same options as require, the docstring for require describes :verbose)


(alter-var-root #'clojure.core/*loading-verbosely* (constantly true)) in the repl while turn it on everywhere

Alex Miller (Clojure team)23:03:56

why not just use the :verbose flag in the require?


I might not know exactly where I need to put the verbose flag

Alex Miller (Clojure team)23:03:51

your definition of lazy is weird :)

Alex Miller (Clojure team)23:03:27

(:require ...yadayada... :verbose)

Alex Miller (Clojure team)23:03:59

or (require ... :verbose) depending on whether you're in ns or repl

👍 1
clojure-spin 1

I mean, I dunno, it has been a while and I don't entirely recall why I set it the last time I did, but I imagine it was because something else was controlling code loading and I didn't want to add :verbose in every require in a project, I just wanted to see everything load


If you have something blocking the load, you can take a thread dump with jstack or ctrl+\