I don't agree with everything he mentions on that gist tho 🙂

his point about when-vs-if is something I've been saying for years, everyone does it and it drives me mad

imho about if: it just reads better to have when and if. But it's highly subjective and depends on what you were used to in other languages I guess

it's objective that when implies do when should have been called doif

> Clojure indentation treats lists differently from vectors Clojure doesn't have any indentation, tools do. And tools approach it differently. They are free to implement indentation differently for vectors in the :import form. E.g. Cursive does let you configure different indentation for different forms, but I think it currently only works for list forms and is based on what the first item of a list is. > I know it was discussed recently here and that [] was deemed more common or even prefered Could you please point me to that discussion? I'm a bit surprised by both of the sentiments so would be curious to read more.

I asked Rich about the [] vs () once and he thought this was a silly argument and we should just use [] for all of these cases.

My own 2 cents is that Clojure broke from Lisp in primarily using () only to mean invocation (there are a few exceptions in Clojure) and generally using [] for grouping, and require and import are both grouping not invocation

you mean import 🙂

Both

I still prefer [] for require, I think also phil only meant to use () for imports. But I guess it's one of those things that will fall in the same folder as tab vs space

I'm in a deep groove of using when for single-branch control flow, and I really like it. But I can't tell if it's just because of familiarity that I feel like the pure/effectful distinction wouldn't help me much. I feel like there's loads and loads of single-branch points in any code base, and every when lightens the mental load of reading the code a little bit, and that all adds up to a lot. The other distinction wouldn't occur quite as often. And I can't know if a non-core function call in an if is pure or not, anyways, so it's not like it's a clear distinction between pure if and unpure when.

ok since we're drifting, sorted requires is the one and true way 😁 Just for consistency's sake.

especially now that it can be automated via lsp (on save)

I’ve automated that in Emacs for 10 years 😅

But yes, agree, sorted requires or GTFO!

I also agree with @U0AQ3HP9U’s point on single case when - it lightens the load

When he says “This is a lisp convention…” does “this” refer to using single-branch if’s or not using them? which one is the old convention? I’m having antecedent confusion.

I read it as "single-branch if is a lisp convention". Now, I've never been a common lisper, but this is weird because at least half the CL sources I find say that when or unless are preferred over single-branch if. I guess this is an old debate?

This makes me realize just how little overlap there is in my Clojure career with Common Lisp (or other non-Clojurey lisps). I know nothing about what's going on with those languages and their communities. Keep hearing Racket's great, but haven't found reason to explore.

The logger name is probably migratus.core.

thanks... trying that

Ah, they're probably hierarchical - both migratus.core and migratus worked for me just fine. Are you sure that logback config is used?

no

Curious - how do you use "down" migrations for your tests?

how do i know

i have a fixture

(defn with-db
  [f]
  (start)
  (reset-db)
  (seed-db)
  (f))

Not sure if there's a way to know if programmatically, but it should be used if it's named logback.xml and is somewhere at the top level on your classpath (i.e. (io/resource "logback.xml") returns something in a test).

I see that that fixture creates a DB, but where does it run "down" migrations? And why would it do that?

this is all the logback references i have in the code base

Check which logback.xml is on the classpath when the tests are being run.

just like (println (io/resource "logback.xml")) ?

Yeah, should work.

ohhh

i don't have a dev/resources dir

You do have it. Otherwise, that call to io/resource would've returned nil.

It's just that that change that you made with level="off" wasn't done to that file.

temporariy blind sorry

restarting docker... excited

hopeful

🙂

Seems like you have multiple config files and the classpath can sometimes have more than one of them. You should try to avoid that situation.

But still - why the down migrations? Why not just create a DB for tests from scratch and run each test in its own transaction?

Personally, I never use down migrations. In fact, I have them outright disabled in Migratus. :) If I ever need to work on some different branch with incompatible DB changes, I just clone the DB. And if something ends up being broken in production after a migration, I create a new migration that fixes it in a way that's specific to that failure. Otherwise, it's waaaay to easy to lose data with a down migration.

yeah... fair point

i am terrified of the idea of accidentally being connected to prod and running tests from the rel

REPL

Heh.

i prefer only using datomic with clojure projects 🙂

for which... also no down migrations, you just give it your schema and it detects changes

BEAUTIFUL

logs are GONE!

😅

now i can actually find my debug statements

On that note - consider stuff like tap> and Portal. :)

jars include a pom manifest of the deps they depend on. pom files have no mechanism for declaring a dependency on a git dep (this is a deps.edn feature), so there is no way for a Maven jar artifact to state a dependency on a git dep

tools.build is also published as a Maven artifact, so in this case, you could replace that transitive dep in the dependency tree using :override-deps in an alias

the equivalent artifact here would be io.github.clojure/tools.build {:mvn/version "0.9.6"}

Thanks for the reply! I actually thought that using a Github instead of a Clojars/Maven dep was the reason at first, but then I thought “wouldn’t we’ve noticed it first with other libraries”?

When googling I did see that this problem occurred when one uses purely local deps, but I thought “GH deps aren’t local so they should work, right?”

generally, Maven artifacts should (can only) depend on other Maven artifacts

This sounds like something grasp or clj-kondo could identify. A script that identified these usages in your own source or transitive libs would be so helpful

If you have a working branch, I can try to find usages with core-regression

I should have mentioned this, but already asked @U04V15CAJ to include this - see https://github.com/clj-kondo/clj-kondo/issues/2260

outstanding. Also really nice to connect what goodies we can get when we do “the right thing”™ instead of something that just happens to work.

I can see just from searching that there are many occurrences of this in the world, so no need to test anything, it's definitely a wide-spread occurrence we have to take into account

my plea is to stop making more of it :)

I’ve never known whether to do clojure.lang.PersistentQueue/EMPTY or (clojure.lang.PersistentQueue/EMPTY) so nice to know there’s a right answer and why it’s the correct answer

that is one I see a lot of examples of

would that interest you in a var in clojure.core exposing that? (i love the persistent queue)

I noticed that the Clojure Essential Reference book has a bad example of (Math/-PI) in it /cc @U054W022G - should be just Math/PI . The - there particularly highlights something - because static fields and static methods have distinct syntax C/xyz will never overlap with (C/xyz) and there is no need for the - distinguisher, so C/-field has also never been a valid syntax (although (C/-field) frustratingly accidentally works).

that is far rarer in the wild, but this particular example is doubly bad in this way

@U11BV7MTK we have a ticket for it somewhere

I see • https://ask.clojure.org/index.php/3365/implement-reader-literal-support-persistentqueue-structure?show=3365#q3365 • https://ask.clojure.org/index.php/3821/add-queue-and-queue-to-clojure-core?show=4079#a4079 upvoted both. thanks

Is this an instance of "undefined behavior" that now has a defined behavior? or is this "defined behavior" with new changed semantics?

it's "undefined behavior", tbd what it will be

my apologies, i meant the (Classname/field) syntax

that's how I understood you

How were you searching to find the offending code? I could open some PRs to help ease the transition for folks

I grep.app-ed for (System/out) , there were quite a few of those

just grepped for common static fields in the jdk - System/out, System/err, File/separatorChar, File/pathSeparatorChar, Long/MAX_VALUE, Integer/TYPE, etc

everything I tried had examples :(

Why would the instance field access still be allowed using wrapping parens btw?

if the static field held something invokable, you could invoke it

(and note in the future, more things may be invokable then what is invokable now)

No I mean, why would there be a difference between static vs instance for accessing fields?

instance fields always have an instance, so are always parens

not sure if that answered your question

right, I guess I misremembered both supporting (.-foo x) and (.foo x) for fields

those are both valid for instance fields

that's a pity ;)

I remember supporting that exact use case in SCI: https://github.com/babashka/sci/issues/714

and here is the one that should no longer work in clojure 1.12: https://github.com/babashka/sci/issues/257

I was totally unaware people tried getting static fields with function calls like that. Thankfully my own code is safe, it seems but all bets are off for the majority of the Clojure ecosystem. Maybe it's time for Clojure 2.0 ? 😁

if the static field held something invokable, you could invoke itwhat if the instance field held something invokable, why would (.foo x) not invoke it vs (.-foo x) get the invokable? (currently both just get the field value)

(note that ClojureScript does make a distinction between the two)

You’re comparing different things here (.field instance) or (.-field instance) is field access (as defined on the interop page)

It should return you the value of the field, just as AClass/field should return you the field value

yeah, JS doesn't distuingish between fields and functions, they're just stuff in an object

Yes, I’m sure the crossover from other langs is part of the mistaken expectation here