This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-26
Channels
- # adventofcode (2)
- # beginners (69)
- # boot (37)
- # cider (6)
- # clara (31)
- # cljs-dev (75)
- # cljsrn (5)
- # clojure (72)
- # clojure-dev (7)
- # clojure-italy (11)
- # clojure-nl (8)
- # clojure-russia (2)
- # clojure-spec (56)
- # clojure-uk (54)
- # clojure-za (1)
- # clojurescript (156)
- # cursive (2)
- # datomic (34)
- # emacs (1)
- # fulcro (227)
- # hoplon (74)
- # jobs (1)
- # jobs-discuss (16)
- # leiningen (5)
- # lumo (17)
- # off-topic (9)
- # om (3)
- # onyx (10)
- # other-languages (1)
- # portkey (2)
- # re-frame (2)
- # reagent (36)
- # reitit (1)
- # remote-jobs (1)
- # ring-swagger (8)
- # shadow-cljs (85)
- # slack-help (2)
- # spacemacs (6)
- # specter (3)
- # sql (17)
- # test-check (15)
- # tools-deps (80)
@folcon man that is a confusing error, I just fixed it and released com.bhauman/rebel-readline 0.1.4
To be honest, it’s really great, I specifically spent about 30 minutes futzing around trying to get it working with clojure -A:dev:rebel
.
as I’m trying to understand how to use ions, and trying to work out how to use that and lein at the same time was too big a hill, however I really wanted a nicer repl, So thanks =)…
Is there a general rule for dynamic variables? If I have a top-level def for a namespace that I'd want to change in a test for easier testing should it be a dynamic var or should I just find a way to initialize the namespace so that subsequent function calls are set-up?
@theeternalpulse Are you trying to rebind vars for testing?
generally an explicit arg is better than a dynamic binding - you can provide a sensible default (one in a def even) via a slim helper if needed
(defn -frob [resource foo] ...)
(def good-resource ...)
(defn frob [foo] (-frob good-resource foo))
now the unit test can use -frob
and a test resource
@folcon yeah, I'm using kind of namespace scoped variables for certain constants and factors, but I want to test on simple cases where those factors aren't the crux of the calculation
I think noisesmith might have answered your question, but in my case I use let
for test values which are being passed in and binding
to redefine variables that aren’t. There’s a pretty good example here:
https://clojuredocs.org/clojure.core/binding#example-5784550fe4b0bafd3e2a049e
Hello guys, This is might be a silly question is there a more clean way to represent the following nested logical ops(and not or) in clojure (and (not (nil? dynamicRef)) (or (is-dynamic isDynamic) (is-valid-key-part keyDefinition keyPart)))
@huthayfa.ainqawi Can dynamicRef
be false
? If not -- if it's either a data structure or nil
-- then
(and dynamicRef
(or ...
...))
would be idiomaticNaming-wise dynamic?
and valid-key-part?
are more idiomatic than is-...
I think (assuming they produce Boolean results).
is clojure.edn/read-string
safe by default? seen that some bind also *read-eval* false
on top of that.
hi, i'm getting an error I don't understand:
java.lang.IllegalArgumentException: No implementation of method: :query* of protocol: #'reflection.util/IDataSource found for class: reflection.component.datomic.DatomicDataSource
I'm using Stuart Sierra's component library. I haven't actually change the defrecord
or defprotocol
since the last time this worked. It even worked once after not working for a while then went back to consistently not working, which makes me wonder if I was dreaming. I found an article indicating maybe the order the repl loads files could lead to this error: https://nelsonmorris.net/2015/05/18/reloaded-protocol-and-no-implementation-of-method.html. Not sure.
my protocol is:
(defprotocol ^:once IDataSource
(query* [this q params])
(pull [this pattern eid])
(transact* [this transaction])
(resolve-tempid [this tempids tempid]))
my record is
(defrecord DatomicDataSource [uri schema initial-data connection]
component/Lifecycle
(start [component]
(let [c (d/connect uri)]
(assoc component :connection c)))
(stop [component]
(assoc component :connection nil))
u/IDataSource
(query* [{:keys [connection] :as component} q params]
(let [db (d/db connection)]
(apply d/q q db params)))
...
@captaingrover i've seen that error when you call the fn with the wrong number of args
hmm... calling it like this:
(defn query [component q & params]
(u/query* component q params))
looks like the right number of args to me. am i missing anything?i have this process, where i'd need to extract two pieces of information from either of two places. my naive solution was
(let [[a b] (try-place-1)]
(if (and a b)
(actually-use a b)
(actually-use (:a other-place) (:b other-place))))
how could i do this without duplicating the (actually-use
code?Not prettier or clearer, but:
(apply actually-use (if (and a b) [a b] [(:a other-place) (:b other-place)]))
yeah (actually-use)
is a pretty ugly big function call with lots of other parameters so i really don't want to have it twice there
What's the expectation for libraries in terms of spec? As in, if I, as a library author, provide s/fdef for each function, that still doesn't make it terribly easy for a consumer of that library to actually check their calls conform - they'd have to explicitly enable instrumentation on each of them. If I instead add an (s/assert ...)
as the first line of the function - well, that seems somewhat awkward compared to s/fdef
.
I do know/have seen orchesta with its defn-spec
, but I'd hope there is an answer to this without having to pull in another library...
explicitly enabling instrumentation is good, I agree - but explicitly enabling it for every single function in a library I'm integrating is not so great in terms of developer experience
I don't think defn+spec is a good idea for various reasons.. But fundamentally if you cannot proceed with invalid payloads, you must assert of some sort
well, I disagree. in a web request handler you expect junk to be thrown at you, so you have to fail gracefully. As a library author, I do not want to or need to care about someone throwing junk at the functions I provide, but I do want to be helpful in terms of sanity-checking arguments
I guess I'm more looking for something like s/check-asserts
to enable all instrumentation or similar
that's great, but that's not what I'm looking for. I'm talking explicitly about library functions
i would love to see more libraries do what react does, which is essentially provide two versions: one with extensive type checking and helpful error messages for development and one for production. it seems to me library authors could just offer a flag to auto instrument everything.
but two variants doesn't make much sense when you can just have one variant, and toggle instrumentation
indeed. now I just need a way to toggle instrumentation, which spec doesn't seem to provide (other than on a function-by-function basis).
i agree in clojure it doesn’t make sense (it might make sense in cljs because of code size and depending on how well DCE works)
actually, I was wrong and there is a way to instrument all. just (stest/instrument)
without any further arguments
which is not the case for what I was asking. I just needed a way of turning on instrumentation during development
for example, https://github.com/arohner/spectrum is unusable with full instrumentation
I'm reading more about generative testing with test.check, and would love some insight into what that might look like in a "real" system (i.e: testing against stateful/complex components)
https://www.youtube.com/watch?v=H18vxq-VsCk is a good talk walking through testing a complex stateful system (dropbox) using property based testing
basically you create a model of whatever you are testing, and generate sequences of operations that you execute on your system and model, then check your model against the system