Clojurians Log v2

ah, thanks for mentioning that -- i think i see some here: https://github.com/borkdude/clj-kondo/blob/master/src/clj_kondo/impl/utils.clj

would things break if: 1) sexpr was removed from the Node protocol, 2) another protocol was created with just sexpr, 3) only those things that don't purely throw exceptions for sexpr implement sexpr (participate in the protocol for 2), 4) before using sexpr, one could use satistfies? to check whether it would be safe to call sexpr ?

that would probably break the API yes. afaik the only things not seprs-able are comments and unevals? so it’s easy to write a predicate for that I guess

yeah, one of my goals is no breaking changes. I might almost achieve it - but have migrated cljs positional fns to clj positional support so there’s at least one!

on that topic... do you guys know of any tools to test for breaking changes? I was thinking of comparing api fn signatures from current rewrite-cljs and rewrite-clj against my work.

doesn’t rewrite-clj proper have a test suite you can run against your changes?

clj-kondo has 70 tests and 500 assertions right now, you could maybe also try that

yeah it does have a good suite but rewrite-cljs suite was much smaller. just want to take what care I can to avoid unintentional breaking changes

why not incorporate all of rewrite-clj’s existing tests?

I have done that

just trying to be extra careful

do you think a tool that tests for api breakages between versions would be of general interest?

I think a test suite already takes care of that?

maybe it does if you you have complete coverage and haven’t made a human error

so you tool would write tests for free? seems awesome 😉

ha! no

(afk now)

it would only compare api fn signatures between versions

I’m getting the strong impression you would not value such a tool :simple_smile:

martin klepsch goes over this type of idea in his recent talk: https://youtu.be/8klBWIwYfsY?t=1934

I would value it, but I don’t see what it adds compared to a test suite. A good test suite tests all the arities of an API, that’s my assumption

I’ll watch the talk section

I mean, as a library author, it should not come as a surprise that you’re breaking an API when you remove an arity 🙂

as a library consumer that would be interesting I guess, since you’re not in control

clj-kondo already saves the arities of functions in a cache, I guess diffing the cache on a next run wouldn’t be too hard

but maybe it makes more sense as a standalone tool, so please go ahead @lee

as part of cljdoc it would be useful for a wider audience I guess

ah sorry, i see that the link had a time in it. thanks!

yeah for this hypothetical api comparison tool, I’m thinking of cases where either you’ve maybe come in as a maintainer of an existing lib (my case) and when there are many contributors - I expect newbies would like to know if they’ve accidentally broken the api

i expect some non-newbies would like to know too 🙂

:simple_smile: I’ll ping martin to learn if he’s found any existing work.

@sogaiu I think Arne Brasseur is doing something interesting that might be related. I think he’s generating docs for kaocha from tests. Here’s a random example: https://cljdoc.org/d/lambdaisland/kaocha/0.0-418/doc/cli-print-the-kaocha-configuration

your comment block idea is interesting too. Personally, after experimenting, I convert to unit tests and delete my comment blocks.

but your comment blocks can become unit tests… interesting.

I take it back, the kaocha example is not really related to what you are doing. But it is kind of cool, right? :simple_smile:

https://github.com/xsc/rewrite-clj/issues/76#issuecomment-499267655

@lee it is interesting for sure. i've been thinking to record execution of code and generate / analyze results -- generating draft docs is one thing that could be done with this sort of thing.

comment blocks that become tests, that sounds also like https://github.com/cognitect-labs/transcriptor

@borkdude indeed, that's one of the inspirations

there were some problems w/ transcriptor, and this is an experiment to work around some of them

@borkdude, I manually tried your problem file in my cljs playground a while ago and forgot to tell you. I parsed it in and spit it out successfully.

with tools.reader 1.3.2?

confirmed, I tested it now too

was there anything in particular you changed to make it work, or it just worked?

just worked

yes I am using tools.reader 1.3.2

the bug I’m getting with the original is that it tries to check if an empty string is a string consisting of linebreaks

hmmm… I started this so long ago I don’t recall changes I made. But something must be different!

I’m going to try to focus on finishing up my cljs ticket for now. If this is blocking you, let me know and I’ll take some time to dig in.

Not really blocking, I’ll figure something out

Thanks