Fork me on GitHub
#announcements
<
2021-12-09
>
quoll00:12:40

https://github.com/quoll/cljs-math 0.1.0 is now out. This includes a full set of generative tests to compare cljs-math implementations on ClojureScript to the equivalent JVM functions, and fixes a few inconsistencies and bugs from 0.0.1. Special thanks to @borkdude for writing the ClojureScript repl access, and to @mfikes for detailed optimization advice. https://github.com/quoll/cljs-math

💛 2
👀 4
🙌 4
👍 6
❤️ 2
🎉 43
🧡 2
💜 4
💚 2
alexmiller14:12:20

would you like to contribute those tests to Clojure? would be happy to add them

1
🎉 1
quoll15:12:02

Well, they test that my implementations of the functions return the same values as the functions in java.lang.Math. (First, by running them on the JVM, and then by running them against a cljs repl). Since Clojure’s implementation is just a wrapper around java.lang.Math then I’m not sure that there’s much to contribute there?

alexmiller15:12:25

well, that's why we didn't make them originally, but since you already did, would be happy to add the coverage

alexmiller15:12:12

I can do the work to adapt them into the clojure test framework (not that much should be needed)

harryvederci13:12:31

I'm creating a small Clojure dev library to record the inputs and outputs of functions. It does a bunch of spying in functions in other namespaces, so I named it NSA - Namespace Agency 🙂 Old scenario: • You're working on an API. To trigger a certain endpoint you have to execute 10 steps in a UI. • You change some code. You manually execute the UI steps again. Repeat. • At some point, you get tired of this and add a bunch of `(def x x)`  lines to the function, and rerun it from there. New scenario: • You create a spy from the comfort of `<project root>/dev/user.clj` • You execute the UI steps manually, once. The spy records the input and output. • From then on you can: ◦ Get the first/last/nth result of calling the function, without actually calling it. ◦ Rerun the function with the latest input. ◦ Etc (anything you can think of, I guess) It's based on / inspired by  `tortue/spy` Main differences with `tortue/spy`: • It changes the actual function instead of creating a spy that wraps it. • It has one atom containing the calls/responses of all spies, instead of 1 atom per spy. Very very early stage, but feedback is welcome. Also let me know if this already exists. Sauce: https://github.com/harryvederci/nsa

simple_smile 1
thinking-face 3
4
👍 4
delaguardo14:12:13

Thank you! Sounds useful :) You might want to look at https://github.com/clojure/tools.trace Maybe it can be useful for your library

👍 3
harryvederci14:12:15

Will do, thanks!

Marc O'Morain14:12:01

We have a similar library named Bond: https://github.com/circleci/bond

👍 1
Marc O'Morain14:12:35

(require ‘[bond.james :as bond])

13
😂 3
harryvederci16:12:43

Thanks for the suggestions, I'll look into them to see how it fits in. The main value nsa has for me personally is that I don't have to alter a function its code in order to "spy" on its input/output, which keeps the codebase uncluttered. Values within a function can't be spied on with nsa (at least for now), but maybe if that's an issue it's an indicator that my functions are doing too much and that I have to split them up, after which I can unleash nsa on them again 🙂

Jakub Holý16:12:57

I appreciate the name! Though Bond is also a fine one :)

harryvederci16:12:10

Haha, agreed! Thanks!

metasoarous17:12:21

This is the content I'm here for

😊 1
athos02:12:53

Another similar one: https://github.com/athos/Postmortem nsa’s API looks like a specialized version of instrument in Postmortem.

Lukas Domagala11:12:51

i’m working on something similar: https://github.com/Cyrik/omni-trace you start the spy/trace from the outside and can even capture all outgoing calls from the function and if you want everything inside the function. works for clojurescript as well. oh and you get a pretty flamegraph to view your data. I guess i should extend docs and find a better spy name 😉

👍 1
harryvederci11:12:36

Oof, that inner trace feature looks nice! 👀

Lukas Domagala11:12:53

the inner trace is 90% debux. i just modified debux to be able to actually save the trace instead of printing and added a way to wrap the debux call around an existing function. there is no visualization for it yet, but you can just look at the output in the instrument/workspace atom. i’d love some more user feedback so if anything is missing i’m open to suggestions