? Spacemacs + clj-refactor problems ? Some documentation says that installing the clojure layer in Spacemacs automatically loads clj-refactor, but none of the cljr-blahblah functions show up in Meta-X. Then I read I should do (clojure :variables clojure-enable-clj-refactor t)) in the layer spec, but that sends Spacemacs into death-recovery mode. Then I tried installing the clj-refactor package in the Spacemacs place dotspacemacs-additional-packages and doing

(require 'clj-refactor)
(defun my-clojure-mode-hook ()
  (clj-refactor-mode 1)
  (yas-minor-mode 1)
  (cljr-add-keybindings-with-prefix "C-c C-m")
  )
(add-hook 'clojure-mode-hook #'my-clojure-mode-hook) 

Is it okay to have a cljc file sharing the same namespace as a clj file? And if so, how to I access the variables defined in the cljc file from the clj file?

Are there any resources/guides on how to incorporate testing a library's public API for breaking changes into a project's test suite? I'd like to automate the process of enforcing the https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/Spec_ulation.md constraints on an external API as I refactor a project so I don't accidentally impose a breaking change on myself.

i've just uncovered an interesting issue in our codebase around some tagged-literals seemingly violating the principle of least surprise we have been returning defrecord objects from a custom tagged-literal reader, and having those defrecord objects participate in a protocol - it's all been working just fine until i ran across this issue someone had put a tagged literal into a def (which seemed like a reasonable thing to do at first blush): (def foo #ctx/event-path [:blah]) which was ok... until c.t.n.r/refresh was called, after which point everything broke it turns out that the defrecord object foo had a stale class (presumably because tagged-literal induced dependencies are not recognised by tools.namespace, and namespaces were therefore recompiled out of order), and so no longer participated in the protocol should tools.namespace be able to recognise tagged-literal induced dependencies ? or is that a step too far for it ?

tagged literals are just tagged literals - they are only tied to classes via some context where reader fns are supplied

in foo , would it make sense to call the record constructor instead there? that would make an explicit reference to the implementation

yeah, i have a data_readers.cljc

it wouldn't make sense to call the record constructor, because the objects are part of a serializable pure-data definition... i can stop using records+protocols though and just use plain maps and multimethods

I think you'd still potentially have the same issue of dependency tracking (but maybe it wouldn't actually break due to the class differences)

I'm not sure whether it would make sense to change tools.namespace in this way, but would welcome an issue at https://ask.clojure.org so we can make a tns jira out of it

I am thinking, what if clojure.lang.LongRange/`clojure.lang.Range` implemented clojure.lang.Reversible? I guess the only complication would be in the infinite case. In the finite case, the reverse range could be computed in O(1) space/time with some integer arithmetic.

Hi folks. Just to confirm, is there a better method of getting the str representation of a var other than these options? Example: The var is #'foo/bar Expectation: “foo/bar” method 1)

(str (subs (str my-var) 2))

(let [var-meta (meta my-var)] (str (:ns var-meta) "/" (:name var-meta)))

if i have a function reference user$square , can I turn that into a var?