Clojurians Log v2

@wilkerlucio I love the idea of (>fn). :) That doesn't actually exist, right? And if you start a Google Doc with any thoughts on instrumentation and performance, I'd love to collaborate. I actually have a very poor understanding of how it works, and I don't even understand what "production mode" actually is and how to enable it. I'd love to learn and integrate it into the docs. Thx!!!

@wilkerlucio PS: I agree on the default settings. That was actually my first question in this channel, to the effect of "how do I actually generating a run time typing error?"

Hey @genekim, I vaguely remember having a conversation about this and I think it might have been with you. 🙂 My suggestion then was the same as it is now, which is not to use anonymous functions:

(defn event-handler [_ _] ...)
(rf/reg-event-db :initialize event-handler)

Since Ghostwheel is simply using the existing clojure.spec APIs and to my knowledge they don't let you do instrumentation on anonymous functions, doing it that way isn't really possible at the moment. I think it shouldn't be too hard to implement actually, but it's still adding complexity which I'm not entirely convinced is worth it. I feel the cases where you'd need that you might as well create a top-level function, spec that and call it instead of the anonymous function.

Ah yes! @clojurians.net I'll record this and put in PR, so I don't ask a third time! :)

@genekim Production mode at the moment is basically when Ghostwheel is disabled, that is – no external config exists for it in the compiler options and the JVM option "-Dghostwheel.enabled=true" isn't set. In that situation it simply strips all gspecs at compile time and otherwise doesn't do anything that would impact a production build. However due to external dependencies being pulled in, it might still increase the size of a production build if dead code elimination fails to fully strip all the extra code (and especially if you're not using advanced compilation which is necessary for DCE). For that reason 0.4.0 will have a separate stub package you add to your production profile/alias which has no external dependencies and the regular module will be enabled by default to make getting started easier. @wilkerlucio In that context enabling instrumentation by default for specced functions might actually make sense, I'll definitely give it some thought. As for expound – that was already meant to be enabled by default, but there were some issues with how it was done, especially in connection with cljs 1.10.520 which changed the way all of this is done. It's all sorted in 0.4.0 which is slightly delayed, I expect the beginning of next month, but you can have a look at 0.4.0-SNAPSHOT for the preview.

P.S. Actually the newest stubs module is backwards-compatible with the older ghostwheel version: https://github.com/gnl/ghostwheel.stubs

Glad you're digging it, see below for my response to the other point. 🙂