Fork me on GitHub
#clojure
<
2018-06-26
>
bhauman00:06:53

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

folcon00:06:44

I’ll give it a go 😃

folcon00:06:23

Yep, all is happy!

bhauman00:06:52

it should switch to no color when an overflow occurs

folcon00:06:26

That is what happened

bhauman00:06:36

perfect! I'm glad its working for you

folcon00:06:44

Definitely

bhauman00:06:04

so very confusing

bhauman00:06:37

I'm glad you brought it up

folcon00:06:39

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.

folcon00:06:42

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 =)…

theeternalpulse00:06:37

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?

folcon01:06:52

@theeternalpulse Are you trying to rebind vars for testing?

noisesmith01:06:04

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

noisesmith01:06:53

(defn -frob [resource foo] ...) (def good-resource ...) (defn frob [foo] (-frob good-resource foo))

noisesmith01:06:16

now the unit test can use -frob and a test resource

theeternalpulse01:06:33

@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

folcon01:06:04

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

huthayfa04:06:35

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)))

seancorfield04:06:08

@huthayfa.ainqawi Can dynamicRef be false? If not -- if it's either a data structure or nil -- then

(and dynamicRef
     (or ...
         ...))
would be idiomatic

seancorfield04:06:57

Naming-wise dynamic? and valid-key-part? are more idiomatic than is-... I think (assuming they produce Boolean results).

2
ikitommi06:06:28

is clojure.edn/read-string safe by default? seen that some bind also *read-eval* false on top of that.

emil0r06:06:28

It's safe by default

Desmond07:06:15

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

Desmond07:06:26

any clues would be appreciated

PiGuy12:06:54

@captaingrover i've seen that error when you call the fn with the wrong number of args

Desmond15:06:49

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?

valerauko14:06:28

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?

petterik14:06:09

Not prettier or clearer, but: (apply actually-use (if (and a b) [a b] [(:a other-place) (:b other-place)]))

valerauko14:06:58

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

valerauko14:06:04

your solution is pretty awesome

valerauko14:06:18

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

✌️ 1
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...

ghadi20:06:36

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

ghadi20:06:29

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

ghadi20:06:40

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

ghadi20:06:02

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

ghadi20:06:10

that's what I meant with the web requests.

ghadi20:06:50

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

ghadi20:06:03

assertions don't let you do that

ghadi20:06:13

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

justinlee20:06:33

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.

justinlee20:06:38

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

ghadi20:06:31

I find auto instrument flags useful

ghadi20:06:45

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

justinlee20:06:36

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)

ghadi20:06:19

@alex340 stest/enumerate-namespace

ghadi20:06:57

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 🙂

ghadi20:06:22

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

ghadi20:06:30

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

arohner20:06:26

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

arohner20:06:09

for example, https://github.com/arohner/spectrum is unusable with full instrumentation

shayanjm21:06:10

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

shayanjm21:06:36

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)

shayanjm21:06:46

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

👍 1
hiredman21:06:11

https://www.youtube.com/watch?v=H18vxq-VsCk is a good talk walking through testing a complex stateful system (dropbox) using property based testing

👍 2
hiredman21:06:11

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

👍 1
shayanjm21:06:28

awesome, thanks!