Fork me on GitHub

Hi, good day everyone! I’m trying to get my feet wet with Clojure internals. Currently I’m reading iterate implementation in src/jvm/clojure/lang/ and it caught my attention that _seed and _next are volatile variables. I’ve also seen that in first implementation seed was just final and got changed to volatile. Could someone explain a bit, or show me a path to understand why is that? Why it’s important for _seed and _next to have always the same value visible in all threads? What would happen if that wasn’t the case? Is that anyhow connected with laziness?


👋 ! Did you check ? That should answer the first question (specifically, see how commits are linked to JIRA tickets)


> Why it’s important for seed and next to have always the same value visible in all threads? I think this question answers itself... :) imagine if this wasn't the case and that (take 10 an-iterate-object) returned different results depending on the thread you're on. That would seem very broken


hi! thanks for response 🙂 I checked commits, yes 🙂 I’m just starting to understand multithreading and I lack proper mental models, so it’s hard for me to imagine particular situation and particular error that could happen because those variables were not volatile


Sure :) rich recommends the JCIP book, I can second that; with it the 'why' for volatile etc will come more naturally

👍 3

that's a good question

Alex Miller (Clojure team)12:08:54

Writes to non volatile fields are not guaranteed to be seen by other threads

👍 6
Nathan K08:08:44

any vscode / calva users? How do I stop a command in the repl? lol.. it's just looping


There is a #calva channel if you don’t get an answer here


next.jdbc question - where can i specify the builder-fn in here? Want to get lowercase qualified keys

(with-open [conn (jdbc/get-connection config/h2-spec)]
    (sql/query conn ["select * from connections"]))


Got it myself

(with-open [conn (jdbc/get-connection config/h2-spec)]
  (sql/query conn ["select * from connections"] {:builder-fn rs/as-lower-maps}))

👍 3

Hi, is there some kind of "in memory" file / buffer that can act as a file? Basically want to test reading files, but I don't want to actually create any on the filesystem.


is using files part of the end user contract?


if not, I strongly disrecommend using files explicitly, and instead build things to use inpustream / outputstream


Even if files are part of the end user experience, it's much easier to use i/o streams internally, and make the fact that it's a file a runtime implementation detail. The JVM already guarantees you can do the same things with file streams you can do with other streams, that doesn't need special test coverage.


it is for the enduser. And I've split my code in two parts. One that reads the file, the other that does the processing. And I can do most of my testing on the second part, but I still want to write a few tests for the first


Oh looks like this works (let [a (.ByteArrayOutputStream.)] (spit a "foo") (slurp (.toByteArray a)))


If there's a cleaner way then I'm all open for suggestions


Hi, I have a set of tests (using clojure.test), all in one namespace that have an each fixture declared. Now I want to run the same set of tests unchanged (same input / output and assertions) twice, where the only difference is that in the each function, a different file is loaded for the second run. I guess there is a way to do that, but cannot come up with one right now that is simple, so, I'd be interested in ideas in how to solve that. It would also be great to see, if a test fails, with which precondition it failed.


@sveri About the only place where I use dynamic vars is with clojure.test-related code. Might also work in this case.


Would it bea idiomatic to run the test function twice? Something like:

(defn database-setup [f]


where database-setup is the each fixture.


@sveri are you aware of test-ns-hook ?


@jason358 No, thank you, I will have a look


-.- I am using kaocha, which has an open issue for support of test-ns-hook So unless I change my test runner I will have to look for a different solution.


Hi everyone. As an experienced Clojurist, how often do you use's (comment ) form in your day to day development? Do you have any other use case for it other than trying out something during development? Do you later delete it or do you push it along to production?

Alex Miller (Clojure team)20:08:49

I use it every day as a place to evaluate code into my repl. I often leave the blocks in committed code for the next time I'm working there

thanks3 3
💯 6

Anyone with experience with depstar?


@hadilsabbagh18 We use it at work to build all our deployment artifacts. And I maintain it.


Hi @seancorfield! I figured out the problem I was having. Sorry to bother you...


@kraulain I use (comment ..) every day. I leave a lot of the comment blocks in the code when it is committed. I use it both to explore the problem space and the solution space, as well as to provide "set up" code for use with the REPL. You'll see that sort of thing in several of my open source projects too, for example

🙏 3

I also generally have a (comment ...) block at the bottom of my files. It's often my scratchpad for building up functions and implementations. Sometimes I migrate them into tests.

🙏 3