matcher-combinators

lread 2022-11-10T18:17:20.828209Z

@lee has joined the channel

lread 2022-11-10T18:17:21.123799Z

set the channel description: Nubanks' matcher combinators library

logbot 2022-11-10T18:18:00.839279Z

@logbot has joined the channel

2022-11-10T18:18:24.275289Z

@zulip-mirror-bot has joined the channel

lread 2022-11-10T18:19:30.856049Z

set the channel topic: https://github.com/nubank/matcher-combinators

ericdallo 2022-11-10T18:20:21.377559Z

@ericdallo has joined the channel

lread 2022-11-10T18:29:28.530339Z

https://github.com/nubank/matcher-combinators/pull/180 a badge for this channel in README.

🎊 1
ericdallo 2022-11-10T18:32:53.341339Z

Merged, thanks!

❤️ 1
1
2022-11-10T18:50:28.406909Z

@dchelimsky has joined the channel

2022-11-10T18:51:51.590299Z

Impetus for this channel: https://clojurians.slack.com/archives/C03S1KBA2/p1668100660564529

borkdude 2022-11-10T18:56:49.001949Z

@borkdude has joined the channel

borkdude 2022-11-10T21:09:08.999209Z

Started using macher-combinator in babashka now as well, for some tests. I needed to compare expected text spanning multiple lines against actual text. I didn't know if mc had something for this, so I just broke everything in lines and then compared a sequence of lines

borkdude 2022-11-10T21:10:18.477649Z

I think it would be useful if mc had something like: This is the expected multi-line string and the actual output should at least start with that. And when it doesn't match, don't output the large string blob, but point into the string where it starts to diverge

2022-11-10T21:10:55.052859Z

Is matcher-combinators.matchers/regex insufficient?

2022-11-10T21:11:10.343799Z

Oh - I see the bit about the blob.

2022-11-10T21:11:11.595619Z

Hmm.

borkdude 2022-11-10T21:11:41.596349Z

This is my diff to move from my own logic to mc: https://github.com/babashka/babashka/commit/ac1b16bfc89e394b7dce555dad329d97a6fa0e8c

borkdude 2022-11-10T21:12:53.625249Z

So this is basically my matching logic now:

(defmacro multiline-equals [s1 s2]
  `(let [lines-s1# (str/split-lines ~s1)
         lines-s2# (str/split-lines ~s2)
         max-lines# (max (count lines-s1#) (count lines-s2#))
         lines-s1# (take max-lines# lines-s1#)
         lines-s2# (take max-lines# lines-s2#)]
     (is (~'match? (map str/trimr lines-s1#) (map str/trimr lines-s2#)))
     #_(run! (fn [i]
               (let [l1 (get lines-s1 i)
                     l2 (get lines-s2 i)]
                 (if (and l1 l2)
                   (is (= l1 l2)
                       (format "Lines did not match.\nLine: %s\nLeft:  %s\nRight: %s"
                               i (pr-str l1) (pr-str l2)))
                   (is false (format "Out of lines at line: %s.\nLeft:  %s\nRight: %s"
                                     i (pr-str l1) (pr-str l2))))))
             (range max-lines))))
The commented out thing is what I did before

borkdude 2022-11-10T21:14:01.974659Z

(I moved form a function to a macro for better line info in test failures)

borkdude 2022-11-10T21:15:36.987859Z

This works already pretty well but it also ties into an issue that @lee mentioned yesterday: If you have two sequences and they start to diverge because there is one element in between, all the elements after are reported as non-matching

borkdude 2022-11-10T21:16:19.518619Z

e.g.

[1,2,3,4] ~ [1,1,2,3,4]
everything after the first 1 is dismissed as non-matching, while you could argue that it should only report the second 1 in the last element

lread 2022-11-10T21:22:17.701429Z

@borkdude I also use the split lines strategy when using kaocha to get nice diff results.

lread 2022-11-10T21:27:50.166269Z

Would be cool to have such a matcher built into matcher-combinators, and it would make sense if it https://github.com/nubank/matcher-combinators/issues/177.