Open viebel opened 3 years ago
I’ve never used it in production, but in staging yes. As long as it’s on the classpath when the process is started you can just repl in and require it from any namespace.
I have no absolute recommendation, but here are some things to consider:
Is it safe to include scope-capture to our code base ?
(sc.api/spy ...)
call somewhere in your code is a fantastic way to get a memory leak, since each recorded scope gets saved in a global atom and won't get garbage-collected. sc.api/dispose-all!
to clean up after yourself. Is there a way to dynamically load scope-capture ?
I guess the situation for scope-capture is the same as for any dependency-free Clojure library:
Does that answer your questions @viebel ?
@vvvvalvalval : for completeness, other than a plain' ol mem leak (due to the atom), is there any other significant impact in terms of performance or correctness?
is there any other significant impact in terms of performance or correctness?
@vemv for performance, nothing I can think of - the sources of overhead are the effects of saving to the atom and logging.
For correctness, the main risk is that the sc.api/spy
macro does side-effects at macro-expansion. Some compilation toolchains may rely on the assumption that macro-expansion is purely functional, and thus avoid re-doing macro-expansion when you would like it to. That kind of stuff.
What is your recommendation about using scope-capture in production so that we could connect to a nREPL (e.g. with lein) and inspect our code?
Is there a way to dynamically load
scope-capture
? Is it safe to include scope-capture to our code base ?