Fork me on GitHub

@folcon man that is a confusing error, I just fixed it and released com.bhauman/rebel-readline 0.1.4


I’ll give it a go 😃


Yep, all is happy!


it should switch to no color when an overflow occurs


That is what happened


perfect! I'm glad its working for you




so very confusing


I'm glad you brought it up


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:


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 idiomatic


Naming-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.


It's safe by default


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: 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]
  (start [component]
         (let [c (d/connect uri)]
           (assoc component :connection c)))
  (stop [component]
        (assoc component :connection nil))

  (query* [{:keys [connection] :as component} q params]
          (let [db (d/db connection)]
            (apply d/q q db params)))


any clues would be appreciated


@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


your solution is pretty awesome


i'll combine it with partial and call it a day! thanks a lot!

✌️ 4
Alex H20:06:42

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.

Alex H20:06:35

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

Alex H20:06:24

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


Just like in a web request handler -- you check explicitly and handle


But I wouldn't do that for every function

Alex H20:06:42

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

Alex H20:06:08

I guess I'm more looking for something like s/check-asserts to enable all instrumentation or similar


that's what I meant with the web requests.


(if (s/valid?...) {:status 200} {:status 400 :body (s/explain-data ....)}) or similar


assertions don't let you do that


neither does instrument for that matter

Alex H20:06:15

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.


especially in closure where code size isn’t at a premium


I find auto instrument flags useful


but two variants doesn't make much sense when you can just have one variant, and toggle instrumentation

Alex H20:06:22

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)


@alex340 stest/enumerate-namespace


can combine that with instrument, or bundle it into a little helper

Alex H20:06:53

actually, I was wrong and there is a way to instrument all. just (stest/instrument) without any further arguments

Alex H20:06:56

so never mind 🙂


that'll turn on a lot and slow the program way down @alex340

Alex H20:06:14

why would that matter other than in production?

Alex H20:06:51

which is not the case for what I was asking. I just needed a way of turning on instrumentation during development


depending on how specced out the clj files are, it could slow down development a bit


also depends on whether your code is CPU bound or IO bound


for example, is unusable with full instrumentation


Does anyone have good resources around best practices for testing in clojure?


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)


trying to grok the test.check/clojure.spec mentality

👍 4
hiredman21:06:11 is a good talk walking through testing a complex stateful system (dropbox) using property based testing

👍 8

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

👍 4

awesome, thanks!