This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-08
Channels
- # aleph (2)
- # announcements (2)
- # asami (50)
- # babashka (39)
- # beginners (17)
- # calva (61)
- # cider (9)
- # clj-kondo (5)
- # clojure (37)
- # clojure-europe (52)
- # clojure-nl (1)
- # clojure-norway (14)
- # clojure-uk (5)
- # clojurescript (28)
- # cursive (3)
- # datahike (11)
- # datomic (28)
- # deps-new (11)
- # events (3)
- # fulcro (18)
- # google-cloud (1)
- # graphql (8)
- # introduce-yourself (4)
- # jobs (2)
- # leiningen (7)
- # lsp (15)
- # pathom (9)
- # re-frame (6)
- # reagent (35)
- # reitit (17)
- # releases (1)
- # shadow-cljs (20)
- # specter (1)
- # test-check (106)
- # tools-deps (8)
- # uncomplicate (1)
- # vim (29)
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
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))
nil
user=> (let [fn (constantly nil)] (fn 1))
nil
user=> (let [try (constantly nil)] (try 1))
1
user=>
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
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.
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. 😃
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?
@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?
setting the level is smart. and i did not realize that timbre/error
was a macro, that probably explains it.
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?
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
why not just use the :verbose flag in the require?
your definition of lazy is weird :)
(:require ...yadayada... :verbose)
or (require ... :verbose)
depending on whether you're in ns or repl
