This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-06-05
Channels
- # announcements (10)
- # beginners (59)
- # calva (172)
- # cider (13)
- # clj-kondo (1)
- # cljdoc (10)
- # cljs-dev (4)
- # cljsrn (65)
- # clojure (144)
- # clojure-europe (2)
- # clojure-italy (26)
- # clojure-losangeles (1)
- # clojure-nl (14)
- # clojure-spec (26)
- # clojure-uk (91)
- # clojurescript (75)
- # core-async (53)
- # cursive (11)
- # datomic (16)
- # fulcro (42)
- # graalvm (29)
- # graphql (9)
- # kaocha (3)
- # leiningen (22)
- # off-topic (26)
- # qa (1)
- # re-frame (3)
- # reagent (7)
- # reitit (10)
- # rewrite-clj (56)
- # robots (1)
- # shadow-cljs (107)
- # spacemacs (10)
- # specter (5)
- # sql (15)
- # tools-deps (39)
- # vim (11)
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
based on recent conversations and looking at the source, it looks like the things that throw from sexpr include: comment, some reader nodes, uneval, whitespace, comma, newline. most of those throw unconditionally, at least one only sometimes.
ah, iiuc, it looks like all of the existing reader nodes provide sexpr-fns so they all don't throw by default.
comma, newline, and whitespace can be tested for via node/whitespace? comment can be tested for via node/comment? if something analogous existed for uneval (similar thing in clj-kondo's utils), then perhaps one could have sexprable? be something that used whitespace?, comment?, and uneval?
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.
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
do you think a tool that tests for api breakages between versions would be of general interest?
martin klepsch goes over this type of idea in his recent talk: https://youtu.be/8klBWIwYfsY?t=1934
there is mention of detection of changes under the heading "automatic changelogs". the detection part could use its own name imho 🙂 i think it'd be nice to have this while writing intend-to-commit code -- so comparing between what is already committed and what is in the current tree.
digressing a bit -- after "automatic changelogs" he mentions "examples". along those lines, one of the things i'm using rewrite-clj for is testing the idea of annotating code within rich-comment-blocks with test info. such code looks like:
(comment
^{:ael/want 2}
(+ 1 1)
)
coming back to the code later, i have a record of what the results should be, but also, someone else examining the code might have a better idea of what concrete values are expected.
further, using rewrite-clj, all of the code in the rich comment blocks can be extracted and turned into runnable tests -- the metadata annotations are then used for checking the results and labelling.
the generated tests can be saved to a file to be run later and/or distributed as tests.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 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
based on recent conversations and looking at the source, it looks like the things that throw from sexpr include: comment, some reader nodes, uneval, whitespace, comma, newline. most of those throw unconditionally, at least one only sometimes.
there is mention of detection of changes under the heading "automatic changelogs". the detection part could use its own name imho 🙂 i think it'd be nice to have this while writing intend-to-commit code -- so comparing between what is already committed and what is in the current tree.
digressing a bit -- after "automatic changelogs" he mentions "examples". along those lines, one of the things i'm using rewrite-clj for is testing the idea of annotating code within rich-comment-blocks with test info. such code looks like:
(comment
^{:ael/want 2}
(+ 1 1)
)
coming back to the code later, i have a record of what the results should be, but also, someone else examining the code might have a better idea of what concrete values are expected.
further, using rewrite-clj, all of the code in the rich comment blocks can be extracted and turned into runnable tests -- the metadata annotations are then used for checking the results and labelling.
the generated tests can be saved to a file to be run later and/or distributed as tests.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
@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.
I take it back, the kaocha example is not really related to what you are doing. But it is kind of cool, right?
@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
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.
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.
ah, iiuc, it looks like all of the existing reader nodes provide sexpr-fns so they all don't throw by default.
comma, newline, and whitespace can be tested for via node/whitespace? comment can be tested for via node/comment? if something analogous existed for uneval (similar thing in clj-kondo's utils), then perhaps one could have sexprable? be something that used whitespace?, comment?, and uneval?