that nil should be a sting indicating the shorthand name of the argument

so "-u"

the default might run in the validate fails, it doesn't work in either case.

so don't have that as nil either

i also just wouldn't use clojure.tools.cli unless i had to meet some contract to deliver to another developer wasn't going to learn clojure. clojure deps has a thing for running functions for one and secondly i just eval functions in my repl. I know there are lots of cases where you might need to use a CLI program though, just making sure you were aware of the trade offs.

I suspect the nil in the shorthand argument position is intentional, it looks like OP knows what he’s doing. drew might be correct though, the :default might be silencing your validation error. Try removing it and see what happens?

I guess nil could be a way to say "i dont' want to supply that". I prefer to use keys for that to avoid this kind of confusion. then you just dont include the key value pair.

If you can use recur then it’s tail recursive. Using recur in a non tail recursive position will cause an error. then it’s tail recursive.

thanks max, i should have used the term "tail call optimized". I think the funny thing here is that this will throw an error regardless, just depends on which and how fast it happens.

But i take your meaning, the compiler wont even accept it in some cases.

i don't think this is regular tail call since its not actually calling the function but requiring the programmer to use a goto. tail call optimization would be (defn foo [x y] (foo y (+ x y)) and that would hit the integer overflow not the stack overflow

this:

(ns foo)
(loop [f_n-2 0 f_n-1 1] (recur f_n-1 (+ f_n-1 f_n-2)))

1. Unhandled java.lang.ArithmeticException
   integer overflow

              Numbers.java: 1576  clojure.lang.Numbers/throwIntOverflow
              ... 

i likely have lost track of what it means to be "tail call recursive" again though.

(dpsutton: err sorry i shouldnt DM especially this late at night)

https://clojure.org/reference/special_forms#recur "`recur` is the only non-stack-consuming looping construct in Clojure" for example:

(defn foo [x y]
  (foo y (+ x y)))

(defn foo [x y]
  (foo y (+' x y)))

(defn foo [x y]
  (recur y (+' x y)))

(defn foo [x y]
  (when (recur y (+' x y)) 42))

in practice, "tail call optimization" means that the compiler will emit a "better/faster" code for that recursion In the case of clojure, when using recur it emits a while (that do not accumulate stack, that is faster) when not using recur, it will call the function again, as expected

> i should have used the term "tail call optimized" tail call optimization is the only thing recur is capable of doing, if you are not in tail position it will error, if you are it compiles into a goto in the byte code (same as a Java for)

Thanks that makes sense. So when using recur the recursive calls aren't creating a stack. So nothing to consume.

looks like recur is working just fine. The error is because an integer is not infinite and the loop doesn't have a condition to stop it looping and so keeps increasing the integer values until overflow.... I'm sure you've spotted that by now though.

Yeah, they are no longer files when bundled in a jar. I had this same exact issue in Optimus. Check out the code here for some answers: https://github.com/magnars/optimus/blob/master/src/optimus/class_path.clj

Is (instance? clojure.lang.IEditableCollection form) enough?

Should be, that's how Clojure itself checks it.

Pedestal is staying strong and "boring" which is a good thing in this churn-y dev world! There's also pedestal 2 in the works apparently from what I heard the other day.

Not that i'm aware of. I initially had a repl friendly reitit setup going without state managers.

I may be incorrect on it, but I didn't have good experiences with reloadability last time I tried it, some while ago.

This is a more general problem. Making and keeping things REPL friendly in Clojure has a learning curve. Similar to making things HMR friendly in the front end.

In the case of Reitit, the reloading is described here: https://cljdoc.org/d/metosin/reitit/0.5.15/doc/advanced/dev-workflow

do you know by any chance if there are any benchmarks that compare competing libraries?

https://cljdoc.org/d/metosin/reitit/0.5.15/doc/misc/performance this has some good links and data

Please write an issue about reloadability, would be easy to add a dev-mode, that compiles the route tree on each request.

Juxt has some amazing stuff but I think they need help with naming things 😂

Thanks for the reference, this looks interesting especially because I was planning to use bitemporal db anyway

Malcolm/Jon have a rule that all our libraries must contain only 4 letters, no one knows why and at this point we're too afraid to ask

I am avoiding abstract class and re-implementing the interfaces.

my question was: how can I deal with copy pasting the implementations for all the methods that make up the abstract class

since I am going for interfaces, I will have to implement them every time

macros is a good way to avoid this boilerplate

or at least that is what I understood

you can also use functions

(defn foo-build [{:keys [foo-fn bar-fn]}]
  (reify Interface (method [this] (foo-fn this ..)) ...))

The abstract implementations are provided by the macro, overriding implementations by the user

The expanded form will have all the methods every time

@UK0810AQ2: I'm new to this so, do you have an example I can follow? What I understood is that I can write a macro that I can call to define a new Table and the macro will handle default implementations for methos. When I do call the macro I will have the option to provide different implementations for some/all of the methods defined in the macro .

now that I write it, is kind of makes sense. Thanks, let's see when I get there - now it's project setup 🙂

Oh okay i misunderstood that.

another benefit to using functions in your method implementations is that you can avoid a lot of hassle / weirdness that comes with class reloading, since you can't change methods on instantiated classes, but if you change a function implementation the var lookup does the right thing on each invocation