On some of our services we have adopted a re-frame-esque approach to handling the effects. The one function that did all those side effects would now return a "fx" map. That fx map would get passed to a small function that just doseqs over the map and executes each effect via a multimethod. This approach lets us test the whole flow without actually firing any missiles.

Yeah, something like this. One would think this kind of pattern maybe widely adopted and used, it seems that’s not the case

It's been quite successful for us. Maybe it's a bit too simple and possibly use-case dependent to turn into a library?

Maybe you could share a gist with an example

It's essentially this:

(defmulti mutate! ::name)

(defn run-mutations!
  [mutations]
  (doseq [[mutation-name mutation-map] mutations]
    (mutate! (assoc mutation-map ::name mutation-name))))

The previously effectful function just returns a "mutation-map".

This is really good. But sadly it does’t give me an answer I could immediately apply. This for example: > My idea of development: > Everything is RMDB. > Send SQL, > Get Results ( or side effects). > Playing table tennis between Clojure and RMDB. What does this exactly mean?

The stuff about "Everything is RMDB", I admit I have no idea. I think some nuance is lost in translation. My interpretation of what the blog posts are about in concrete (clojure) terms is: - Use "pass the world"-style context maps, pass this around - Structure your functions as: [optional verification step] -> followed by a threading macro of pure functions -> end the function with a side-effect - Each function may have a single side-effect - Favour using simple functions like reduce, map, pmap and aim to keep your call stack as shallow as possible The way you described the general flow of your functions made me think of PurefunctionPipelineDataflow

@U145X0BPE This isn't always a trivial thing to do, especially with complex specs & a large information model. We have been using this lib in production to convert explain-data to user friendly error messages https://github.com/Provisdom/user-explain. It's manual, tedious work but will allow you to cover anything you'd possibly want.

Attaching additional info to specs when they fail does seem valuable. Predicates often do not return enough information to allow you to figure out what went wrong.

that's awesome 🙂

thank you

but i'm curious if spec maybe in the future support that, to attach messages in case of failure ?

You can see another approach in #announcements from @U0WL6FA77. It's less general but might be easier to understand.

But yes, I'd also like a way to attach more info when a predicate fails.

The only thing, that comes to mind for me is to route everything through a proxy but that seems like a lot of overhead.

generally just logging. tap> etc. you can also connect to your running server process with a repl and poke around at any state you keep

Yeah, it seems like general debugging is the way to go.

in my experience with server side dev: log/tap> all the things. and if you can store what you’re tapping in something queryable even better

I'll try that, thanks.

(read-string (str “0x” hex-string))

that would just yield the value. weird to want a hex literal

yeah I’m assuming he meant “value”. if you want a literal you type it with your hands 🙂

that said, if you are literally emitting code for something else: (symbol (str “0x” “22"))

I am parsing some data, where I have hex strings, and need to compare them. Its just more cleaner to have a map of hex literals in my code, rather than hex strings. Will go with the strings for now.

You can parse into an integer and compare integers.

(Long/parseLong "22" 16)
=> 34

The last param 16 is the base.

^^

then use .toHexString() if you want it as a hex literal string.

(Integer/toHexString 55)still gives me a string and not a literal.

the literal form of integer in Clojure are java.lang.Long values

those always print as base 10

the reader is able to read other forms, 0x etc

yup but something like this 0x55 is also a literal with base 16

read-string outputs that as base 10

in what context do you want to print it as 0x55?

there are ways to influence how the printer prints things if you have some context for doing so

I have a hash map {"55" :a "FF" :b} etc, where the key is a hex value. I would have liked to represent them as literals instead of strings, its just more cleaner. However to do that I will also have to convert my input hex string to hex literals.

0x22 and 34 will be the same value (a java.lang.Long) in your data

The parsed value (the integer) can be used for this. "Literal" usually means a representation of a value before it is processed by the reader, so this term is confusing us I think. :-)

you can represent them as a long, which will get printed as base 10. you can represent them as a string, which will get printed as a string, or you can represent them as a symbol, which will get printed as a bare word. aside from the printing, those three different types of value are associated with wildly different behaviour

if you really, truly, do not care that the value is a number, if it’s just an abstract “thing” that you want printed as 0x55 but you’ll never ever try to do number things with it, you’ll never try and pass it to anything (database, serialisation tool, library) that expects it to be a number, then a symbol will give you that

hmm let me rethink it and get back.

@alexmiller thanks for pointing out that internally both are stored as java.lang.Long which means this works ({0x03 :a} (Integer/parseInt "03" 16)). My assumption was that both have a diffrent representation and therefore the above will not work.

btw, you can control how a map is printed by attaching metadata to it and defining a custom printer for it

you should use Long/parseLong, not Integer/parseInt

In control, the main integral type is Long, not Integer

user=> (defmethod print-method :foo [v ^java.io.Writer w] (.write w "overridden!"))
#object[clojure.lang.MultiFn 0x32b9bd12 "clojure.lang.MultiFn@32b9bd12"]
user=> {:a :b}
{:a :b}
user=> (with-meta {:a :b} {:type :foo})
overridden!

the above works but only because longs and integers both hash the same and compare equal, but you are pushing on same fragile boundaries there

I'd say the printing thing is too clever and bound to trip you up eventually

agree

unless the thing printed out is really obviously custom. like it prints a table

@alexmiller thanks for pointing out the Long/parseLong and @U050MP39D for the printer

bfabry@18723-bfabry ~/C/c/mainstuff> lein test

lein test mainstuff.core-test

lein test :only mainstuff.core-test/a-test

ERROR in (a-test) (AFn.java:429)
FIXME, I fail.
expected: (filter true? [] [])
  actual: clojure.lang.ArityException: Wrong number of args (3) passed to: core/filter
 at clojure.lang.AFn.throwArity (AFn.java:429)

I suspect some code of yours or another library other than clojure.test is stealing the exception

Checking the contents of your $HOME/.lein/profiles.clj is a good idea. Feel free to paste it here if it isn't too long and you want advice on what might be causing issues.

clojure.test seems to do the right thing

leiningen monkey patches clojure.test reporting, not sure if that's a factor

if so, putting :monkeypatch-clojure-test false in project.clj would test that hypothesis and fix it

lein test does the right thing for me, with no profiles.clj

errors in fixtures are also handled different if I recall

you may also be experiencing an annoying feature of the is macro

(is (f ...)) isn't always calling the function f

@U050MP39D @U0CMVHBL2 @alexmiller @U0NCTKEV8 Thanks everyone for the hints. I'll check go through each of them to find where the problem is.

The problem was with one of the fixtures where the code was catching the exception. :face_palm:

Makes sense. Glad you were able to find the root cause.

I didn’t see anything in medley either.

My naive, inefficient impl:

(defn- select-vals
  "Given a map and a sequential of keys, returns a non-lazy sequential of the values of those keys
  in the map, in the same order as the keys. If a key is not present in the map, the corresponding
  entry in the result will be nil."
  [m ks]
  (reduce (fn [result k] (conj result (get m k)))
          []
          ks))

(map m k)

sweet, thanks!

I guess (mapv m ks) would be closer to my fn

((apply juxt ks) m)

if you're feeling a yearning to use juxt

only works for keyword / symbol keys though

When I feel a yearning to use juxt coming on, I go outside and take a walk and clear my head until it passes…

j/k (mostly)