This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (63)
- # beginners (1)
- # boot (83)
- # cider (17)
- # clojure (33)
- # clojure-android (3)
- # clojure-france (3)
- # clojure-gamedev (1)
- # clojure-russia (20)
- # clojure-sg (9)
- # clojurescript (81)
- # core-async (77)
- # cursive (13)
- # datomic (30)
- # hoplon (7)
- # instaparse (54)
- # ldnclj (1)
- # off-topic (4)
- # om (2)
- # onyx (23)
- # re-frame (16)
- # reagent (3)
- # yada (2)
@sveri: I just opened a new PR on joplin, fixing the 2 bugs I introduced in the previous one . I'm sure I tested it better this time, and it worked fine in my tests, but it would be great if you could check it too
Is anyone else having "strange environment issues" on leiningen 2.5.2? I wouldn't be surprised if the change in arguments parsing in
lein run affected other projects and not only joplin 0.2.x
anyone know if it's possible to use slf4j markers with clojure.tools.logging? http://www.slf4j.org/faq.html#fatal
@timvisher It simply isn't possible, and the c.t.logging maintainers are not open to extending support for markers, as its too specific. At Aviso, we had to fork c.t.logging to add marker support, and that was a pain.
FYI, I'm a stickler for privacy in code, I want minimum public surface area for namespaces. That can get in the way of testing. Here's an approach I'm currently using:
e.g. (private find-data-type-mapping sw/default-swagger-options StringBuffer) calls the private function find-data-type-mapping, almost as if it has been referred into the current namespace.
But this makes it clear that it is a private function being invoked bypassing normal visibility.
Im new to learning macros and understand to a certain degree the notion of "code is data". Im currently reading Mastering Clojure Macros by Colin Jones (excellent book) but have become confused a little everytime I see a macro that could clearly be written as a function. Take for instance Clojure's core
this could easily be written as
(defmacro -when [test & body] (list 'if test (cons 'do body)))
so my question is... when would I choose to use a macro over a function?
(defn -when-fun [test & args] (if test (do args)))
Macros are most useful for controlling evaluation. In your
args is evaluated whether or not
test is true, so if you have any side effects, such as logging or saving something to a database, it'll be executed regardless of
user=> (-when-fun true (println "hi")) hi (nil) user=> (-when-fun false (println "hi")) hi nil user=> (when true (println "hi")) hi nil user=> (when false (println "hi")) nil
You could wrap your arguments in a function and call it (as in
(defn -when-fun [test arg] (if test (arg)))), but this quickly becomes impractical for common idioms.
How do we know whether a given function should really be a function, rather than a macro? Most of the time there is a clear distinction between the cases which call for macros and those which don’t. By default we should use functions: it is inelegant to use a macro where a function would do. We should use macros only where they bring us some specific advantage.
before I write this fn, does it exist yet? `"Same as memoize, but takes an extra function, memo-args. f will be memoized on the result of (memo args). Useful when you want to memoize, but one arg is not a value, e.g. a DB connection”`