Clojurians Log v2

@seancorfield Pinging you because of your question a month or so back about this topic. Feel free to ping others that you believe are interested.

I moved a few things around in a newly published version today. I tried to put most or all of the functions focused on REPL development into the first section of the cheatsheet. That first section used to be called "Documentation" with one sub-section named "clojure.repl/". Proposed new organization is that first section is called "REPL", with sub-sections "Documentation", "Add libs", and "Other". "Add libs" contains the new add-lib/add-libs functions.

Not everything can be first, of course, but REPL-based development is prominent enough it seems worth putting first.

Thanks for those who made suggestions. I don't think I followed them all, but if you want to look at an updated version with most of the new vars from Clojure 1.12.0 included, you can find several variants of it here: https://jafingerhut.github.io/

The changes that I made in that version are described here, in case you have any difficulty noticing the few changes made: https://github.com/clojure/clojure-cheatsheets/pull/56/files#diff-f7b49a1753d620c71bb5025133592b107d8c5cd8c458aa8d6be2df146e8f2bc7

I believe that all of the links to http://ClojureDocs.org for the new vars lead to custom 404-like page on that site, because http://ClojureDocs.org has not had those vars added to it. In those variants of the cheatsheet with tooltips, you can see the doc string in a tooltip by hovering the cursor over the symbol name.

There is a PR created that makes these changes in the cheatsheet, here: https://github.com/clojure/clojure-cheatsheets/pull/56

Note: These changes have not been made to the version of the cheatsheet published here: https://clojure.org/api/cheatsheet. The ones linked above are my own published version, which is sometimes a version or two different than the one on http://clojure.org

personally I haven't run into much use of streams in java. so I don't know how useful those are to include, but they're short and sweet. sync deps/etc. is such a boost to the REPL stuff it's probably worth including. I might be inclined to merge all of Documentation with Other/REPL, and then include the new deps stuff in this new section. I haven't looked enough at the new -v variants, I know they solve a problem in the old ones. I might be inclined to think that in new code the new variants should be the default, so replacing them on the cheat sheet might make most sense?

@andy.fingerhut It'll be a while before I have feedback -- in the middle of moving house.

if the ticket has a great problem and solution description, the patch is often obvious and easy to review

but it obviously varies widely depending on the complexity of the problem and solution

my experience, from the outside, is largely it is the steps before a patch is created(identifying the problem, considering solutions) that get objections, and once they are objected to it is very hard to get an movement on an issue. A patch on a ticket often seems to get it ignored as seeming to be a "solved" problem, while the objections to the problem statement stop it from being considered for inclusion, and there rarely is much feedback when the problem statement and solution exploration is considered to be lacking

to be clear, this isn't me subtly asking "why haven't y'all reviewed my patch!"

there are a lot of tickets and patches that have sat around for 5+ years without any movement, and it's hard to know why that is. hiredman's explanation is helpful.

i think there are a lot of people (myself included) in the clojure community who would love to help make clojure better. throwing random patches at the core team isn't the way to do it, so i'm wondering if it's possible to help the core team out by... doing work ahead of time? doing code reviews of existing patches, cleaning up/rewriting/expanding issue problem statements and discussions, etc

i hold "open source is not about you" at the forefront of my mind when i think about attempting to contribute to clojure

better tickets are always appreciated, even more so than patches

but it does seem like there are ways that the i/the community could help without stepping on the core team's toes

A lot of that stuff is based on the judgement of the people doing it, so it order to effectively offload/delegate it you need to trust the judgement of whoever you are delegating to, enlarging that circle of trust is a tricky thing

the reality is, most of the time we simply aren't working on jiras, or sometimes we are but in the context of a bigger scope

yeah, fairly common to if you have a detailed jira issue laying out and issue and solutions with patches, for the issue to get reworked and for a core team member to write a new patch; which sounds like the kind of workflow that would result from jira issues informing some other work list / agenda and then when the work is done the two need reconciling

for example, we are spending 95% of our time right now on either core.async vthreads and/or flow (which overlap slightly in terms of release ordering). a consequence of the vthread work is that we are moving towards a world where the go analyzer/expander is no longer used (unless you explicitly ask for it and/or vthreads is not available). there are a bunch of core.async bugs that are effectively "go analyzer doesn't work like Clojure analyzer" that become irrelevant if there is only the Clojure analyzer. so we're "working" on that set of jiras in a very indirect way. same thing happens in Clojure too sometimes.

sometimes there are also a bunch of jiras that are really the same problem but we don't understand what the real problem is or even recognize the link. once you somehow find the right entry point to the issue, you can retroactively find the jiras that were all related. The locals clearing stuff we did in 1.11.4 / 1.12.0 was like that.

I'd like to say that once a week or a month or whatever we looked at patches and reviewed stuff but I've never been able to coax Rich into that kind of rhythm

Right, that all makes sense. I was more thinking of something like https://clojure.atlassian.net/jira/software/c/projects/CLJ/issues/CLJ-2896 (zip/up is called 3 times, i wrote the patch which is why i have it on hand) or https://clojure.atlassian.net/jira/software/c/projects/CLJ/issues/CLJ-2905 (extend deref to Optionals), where problem is self-contained, the issue is descriptive, the change is small, and the impact is small but meaningful. is there a... resistance to spending time on it because of the low impact?

what I can do is make good queues ready for that time. my current 1.13 queue is here: https://clojure.atlassian.net/issues/?filter=10046 (the ordering here of bugs before improvements is Rich's preference). Many things on here need work, don't have patches, etc

a change like https://clojure.atlassian.net/jira/software/c/projects/CLJ/issues/CLJ-880 (syntax-quote as macro) is bigger, has limited usefulness, and isn't a bug so i understand why it wouldn't necessarily be the top of mind

would it be helpful for you if i looked over those tickets and touched them up, added better problem statements, wrote patches, etc?

yes

hell yeah brother

(vaguely puzzled to discover I reported CLJ-880, I guess that rings a bell)

https://clojure.atlassian.net/issues/CLJ-2822 would be a great one for some attention

things marked Prescreened probably do not need attention