PSA: We just released some changes to Clojars. - rsyncing of the Clojars repo is now disabled (see https://github.com/clojars/clojars-web/issues/735) - GET or HEAD requests to the on-disk repo will now redirect to the CDN-fronted repo (see https://github.com/clojars/clojars-web/issues/734). This means that GET https://clojars.org/repo/whatever will return a 302 Found status code with a location header pointing to https://repo.clojars.org/whatever. We'll change that to a 301 Moved Permanently once this change has had time to settle and we don't have any issues reported that causes us to revert the change. Resolving dependencies should continue to work, since aether (the lib used by boot/lein/maven/tools.deps to resolve dependencies) should follow redirects correctly. Deploying to Clojars should be unaffected by this change - you can still deploy to https://clojars.org/repo/ or https://repo.clojars.org. If you (or someone you love) is negatively affected by either of these changes, please let us know by commenting on one of the above issues. See https://groups.google.com/d/msg/clojure/ZXBOQD5Ubbc/D4ktv8aFCQAJ for the rationale.

What's the point of allowing to define an unbound non-dynamic var? Such as: (def a)

(source declare) is an instance of binding to an unresolved binding

And why it is necessary

But nothing prevents repeatedly redefining the same var right? Namespaces are inherently mutable objects

Ya, but I mean: (def a nil) is a thing too.

Are you saying that (declare a) is just (def a) under the hood?

That’s what (source declare) is telling me in replete

Hum, it is haha

`(do [email protected](map #(list 'def (vary-meta % assoc :declared true)) names))

With a :declared true annotation

I kind of would think it best if (def a) was a compile error. Since it feels like a mistake to me, or at least a pretty bogus thing.

I’ll go grep the source in a minute, but I’m guessing there’s special casing for unbound vars in the compiler

So you need to disambiguate nil (a legal value) from an unbound var

Well, for the declare case I understand

I guess I'm a bit surprised by it. I'd have thought that (def a) would be a compile error. Even more so that (def a) (a) would be one. But it isn't.

So it seems you don't really need to declare, you can just define an Unbound var

it looks like the only place that checks for the :declared meta is now no longer used? includesExplicitMetadata seems never called

Interesting, the meta makes it feel like maybe it wanted to not allow an unbound def unless it was specifically a declared one. But who knows

You do not get exception attempting to eval the second expression of (def a) (a) ?

i think the thought was that (declare a) didn't do any more work than just (def a). was expecting a compiler error rather than a runtime error

ie, expecting it to be the same as just (a) without the declaration

Ya, but its run-time exception.

I assumed since there is declare, that the reason was because an empty def was not allowed.

(declare a) followed by a call to a that is inside of another defn is not a compiler error by design, yes?

That's the primary use case for declare

Ya, I understand for declare. What surprised me is that is is also true of (def a) (a)

Sorry, I may be catching up to what you meant earlier.

And actually, declare under the hood just does a def

no worries

this is not true in clojurescript though. There the analyzer does use the metadata set from being declared rather than def'ed without an object

I've seen declare used in a few projects, but don't recall ever seeing anyone do def without a value.

Sorry, wrong example above, I mean: (def a) (defn some-other-fn [] (a)) or some like that

Eh, it's at most a weird wrinkle that affects pretty much no one.

Where I'd have expected (def a) to throw a compile error, and that you'd need to use declare instead.

i'm not complaining. i'm just learning 🙂

There are much subtler bugs in code I've seen.

ClojureDocs has a note about declare that says you can also use (def a) instead. I feel we should almost delete that note :thinking_face:

that don't cause exceptions or obvious failures.

Seems like it would be bad style

Like, see if you notice the bug here:

(deftest my-critical-test
  (= 5 (some-important-function {:a 1 :c 4})))

Missing is ?

And uneven map ?

That's a compile error though I'm pretty sure

The man wins a prize! Not very obvious in a big file of tests, though, and I've seen dozens of projects with them. Granted, maybe not for "critical' tests, but they lie there doing nothing useful, catching no problems.

Ya, I agree. I'm surprised deftest doesn't validate that. Would there ever be a reason to deftest without an is inside?

missing is. No compiler warning or error. No run-time error.

Sorry, I meant for the uneven map {:a 1 :4} but I guess that was just a typo 😛

Sorry, that was Slack doing something weird with a colon followed by a b

oh okay

I'll add an issue to clj-kondo about deftest without an is as well I guess 😛

I've edited it, which is unfair to your former answers. The missing is is the only mistake I intended to write.

One of the first things I implemented in Eastwood

Ah that's good actually. Got eastwood running at work, glad it's got that check and I don't need to worry about our tests having that problem 😛

Along with finding this mistake:

(deftest my-good-tests
  (is (= 5 (something-important {:a 1 :c 5}))))

(deftest my-good-tests
  (is (= 7 (something-else-important 8))))

If you want a hint: very easy copy-and-paste mistake to make while maintaining a test file

Oh, redefined the previous test ?

yes. The first ones never get run. No compiler error or warning. No run-time issues.

Ya, that would be another good clj-kondo linter

And an existing Eastwood one for a few years.

Actually seems clj-kondo catches that last one already

It's certainly nice if clj-kondo can do everything Eastwood does and more, given how much attention borkdude puts into it.

I like Eastwood, but its pretty slow to run, which is why I have it only setup to run on build, and not like inside my editor as I type

I feel clj-kondo is the best thing to happen to Clojure in the last year 😛 Sorry to any other amazing thing I'm forgetting. But for me, it has been a huge help to quickly correct some stupid mistakes like that. And its also great for beginners to help them out.

There's a lot of things I feel I always wanted the Clojure compiler to catch and make as errors, which clj-kondo addresses as a linter.

Hey, it appears clj-kondo already lints for missing test assertions in deftest!

Toss borkdude a hat tip of thanks when you see him next -- I don't know how much time he spends on that and other projects, but it seems huge.

He's been on fire. clj-kondo, sci and babashka are probably the 3 Clojure projects I'm most excited about to see grow in the next few years.

So ya, big shout out!

@borkdude ^

❤️

@didibus @andy.fingerhut there's also https://github.com/borkdude/missing.test.assertions for catching missing test assertions at runtime which is a pretty simple and small but effective lib

Re #eastwood slowness. Most of it is caused by the analyzer. I’ve got a patch against tools.analyzer (https://clojure.atlassian.net/plugins/servlet/mobile?originPath=%2Fbrowse%2FTANAL-130#issue/TANAL-130) which should speed things up a bit.

Since tools.analyzer is bundled with Eastwood, I could of course monkey patch it.

Hi I basically have a tree structure like this:

(def tree
  [:a :b :c
   [[:d
     [[:e]
      [:h :i]
      [:y :z]]]
    [:f :g]
    [:q :x]]])

[[:a :b :c :d :e]
 [:a :b :c :d :h :i]
 [:a :b :c :d :y :z]
 [:a :b :c :f :g]
 [:a :b :c :q :x]]

Any reason transients don’t support first peek or empty?? The docs say:

Transients support the read-only interface of the source, i.e. you can call nth, get, count and fn-call a transient vector, just like a persistent vector.

It could be simply that implementing the necessary APIs for those operations on transient Java objects was overlooked. I looked through Clojure tickets in JIRA, and didn't notice any issues asking about that (but did find a dozen or so issues related to transients that have been fixed years ago).

i thought i remember a ticket about empty? and that was going to be added?

There is a long historical debate about how many ops transients should support. They intentionally do not support all of them

I’m getting the impression that the scope of using them is much smaller than I initially expected

https://clojure.atlassian.net/browse/CLJ-1872 is the ticket about implementing empty? on transients

I should probably looking at transducers

Transients tend not to remain transients for long

That’s fair

The goal of using transients should be to get to a persistent data structure, not to do a bunch of compute using transients

It is in this context

The problem is the persistent structure I’m trying to get is a map…

All of this is done in a loop recur

Which is what I thought the correct context was

Can you post an example?

based on the docs

https://github.com/Folcon/delaunator-cljc/blob/master/src/cljc/delaunator_cljc/delaunay.cljc#L408

I’m just trying to build up state, should I be breaking this into smaller steps?

Not sure - can you explain the code a bit?

Which part is the transient, etc

Well how far I can go is highly dependant on how flexible transients are… Ultimately there are a lot of assoc’s happening from line 423 to 425.

which get repeated a lot

I originally was trying to use transient and persist at the level of the state on line 410.

If the lookups can be done in a persistent version that isn't "the most up to date", you can do that, of course, but you are probably only asking because you need the lookup results from the latest modified version at the time of the lookup.

but it looks like I should perhaps split out :hull-tri and :hull-next in the loop recur

Remember transient only applies to one map, no nesting

treat them as transients and then pull them back in after

Right, that wasn’t super clear

in fact I don’t think the word nest is even used in the docs

(BTW which docs were you excerpting from earlier?)

https://clojure.org/reference/transients

ty

Which I would expect to be canonical

np

ok, so I should work out a good way of unpacking the nesting =)…

Thanks

It is canonical. The official docs do contain edges/corner cases that could stand improvement in a few places.

noted =)…

Perhaps explode the state into more loop locals

If there is no nesting in the data

(But that is a trade-off)

Depending upon how important time optimizations are for the code in question to you, remember that Java is Clojure's in-line assembler 🙂

Back to your original question, first will not work on transients because it needs a read only seq on the vec/map

There is an open bug for empty?

Fair

I can’t quite do that @andy.fingerhut, I’m trying to keep the code cross platform. So any java I write, comes with writing an equivalent javascript…

Understood. Yeah, I forgot the .cljc suffix on your source file.

It does seem like doing this sort of thing is still rather clunky… Really want to get to the write once run anywhere =)…

Thanks @ghadi

You have the write once run anywhere, now you want to add "and even faster" on top

Those goals aren't always in tension/odds with each other, but certainly often are.

nth appears to work on transient vectors, so you can use index 0 and count-1 to emulate first and peek on transient vectors, at least.

I feel a table for operations that work vs. do not on transients in my future ...

😃

Perhaps

is there a way to get bulk archives of https://clojurians-log.clojureverse.org/ ?