Only downside/hesitation is that this info *must* be collected at the callsite,
which means that it affects the performance of *all* created signals.
Adds ~30-50 nsecs per signal.
Previously:
It was possible to provide a vector of middleware fns when creating
signals or adding handlers, e.g.:
(event! ::ev-id1 {:middleware [fn1 fn2 ...]}),
(add-handler! ::handler-id1 <handler-fn> {:middleware [fn1 fn2 ...]})
After this commit:
Middleware is always expected to be a single fn, or nil.
A `comp-middleware` util has been added to make it easy to compose multiple
middleware fns into one.
Motivation:
The previous (auto-composition) behaviour was nice when adding handlers,
but incurred a (small but non-trivial) runtime cost when creating signals.
The actual benefit (convenience) of auto-composition is very small, so
I've decided to just remove this feature and add the `comp-middleware` util.
Note that I ruled out the option of doing auto-comp only when adding handlers
since that've meant an inconsistency and so complexity for little benefit.
These seem to cause intermittent issues with GitHub actions. Seems like GHA might
be caching builds somehow, even when a caching action isn't present?
Can't reproduce locally, and haven't had an opportunity yet to identify or fix the
underlying cause, so just disabling these for now.
Thanks to @AdamFrey for reporting this issue!
Ref. <https://clojurians.slack.com/archives/C06ALA6EEUA/p1713805333272469>
Previously:
Attempting to run AOT'd code using Telemere would result in errors like:
"Attempting to call unbound fn: #'taoensso.telemere.handlers.open-telemetry/handler:open-telemetry-logger"
The approach I was using of conditionally requiring namespaces and then aliasing vars seems to be inherently
fragile under AOT, and was leading to the remote source var being unbound.
With this commit I've now switched to a simpler approach - where we conditionally require namespaces *without*
the need for any aliasing.
