Issue resolved! thanks to the #cider crew. It was a cider-nrepl mismatch that I had.

Quick question. Is transit (format) suitable for persisting to disk or is it strictly for conveying values between applications? I seem to recall in the early days RH said some representations may change, so don’t persist to disk, but presumably it’s out of alpha now and it’s safe to persist to disk in transit format?

it's as safe to persist to disk as any other format. it has not changed since it was first released. the caveat on the spec is - "readers and writers are expected to use the same version of Transit and you are responsible for migrating/transforming/re-storing that data when and if the transit format changes".

version 0.8 is the only version of the transit format

@alexmiller Per the original warning, it sounded like Transit was still subject to breaking changes (unlike, say, EDN). Is that no longer the case?

If not, it’s odd that a warning exists at all.

It was released 6 years ago and no reason has been found to change it. I don’t know how else to say it’s stable.

There are no plans for changes, breaking or otherwise

If someone I trust and who controls something tells me, “This is subject to change,” I believe them. It doesn’t matter the time horizon of the change.

promising backwards compatibility for a wire format would potentially compromise the core goals of a wire format (speed). even if it hasn't happened in practice

Historical behavior irrelevant, actually. 😄

The best way to say, “it’s stable” is to say, “It’s finalized. No more breaking changes.”

Apologies if I seem confrontational. I’m just trying to reconcile what I’m hearing. I’m gonna take a stab and say: There were once vague ideas for improvements which would require breaking changes. Rich hasn’t let those ideas go, but also has no plans to work on Transit for the foreseeable future. Is that accurate? If so, I’m completely cool with that state of things. I will just continue preferring EDN for disk! 😄

@alexmiller thank you!

I've read https://www.grammarly.com/blog/engineering/building-etl-pipelines-with-clojure-and-transducers/ from Grammarly on etl with transducers. We have a very similar setup but, for us, it's kind of broken. We need to collect errors that occur during the process and return them. The type of error(s) that may have occurred will dictate varying actions from us. The flow goes something like this: 1) Return a IReduceInit that pulls data from a paginated API 2) if, at any point, that API returned an error, the error map should not be passed down the transform pipeline 3) dissect and transform items 4) any transformed items that are invalid should be collected and not included in the pipeline results 5) store the items 6) analyze errors I'm considering something like what's in the snippet. Transducers make handling the "happy path" really nice. Getting the things that are malformed/errors out is less clear. I couldn't find any info online on approaches to this sort of process. Curious if folks doing etl have done something similar.

I'm trying to convert my macro to the following expansion:

(re-frame.core/reg-event-db
 :some-name
 (fn [db [foo bar]]
   (assoc db :foo foo :bar bar)
   ))

(defmacro db-event [name params & body
                    ]
    `(re-frame.core/reg-event-db
      ~name
      (fn [db ~params]
        [email protected]
        )
      )
  )

(db-event :foo [foo bar] (assoc db :foo foo :bar bar))

------ WARNING - :undeclared-var -----------------------------------------------
 Resource: :1:17
 Use of undeclared Var vendo.macros/foo
--------------------------------------------------------------------------------
------ WARNING - :undeclared-var -----------------------------------------------
 Resource: :1:21
 Use of undeclared Var vendo.macros/bar
--------------------------------------------------------------------------------
------ WARNING - :undeclared-var -----------------------------------------------
 Resource: :1:33
 Use of undeclared Var vendo.macros/db
--------------------------------------------------------------------------------
------ WARNING - :undeclared-var -----------------------------------------------
 Resource: :1:41
 Use of undeclared Var vendo.macros/foo
--------------------------------------------------------------------------------
------ WARNING - :undeclared-var -----------------------------------------------
 Resource: :1:50
 Use of undeclared Var vendo.macros/bar
--------------------------------------------------------------------------------

(re-frame.core/reg-event-db {:foo nil, :bar nil} (cljs.core/fn [vendo.macros/my-db nil]))

How do I unroll a map as parameters? Suppose I have the following: (let [foo {:bar1 1 :bar2 2}] (assoc {} ...) ) What can I replace the ... with so that I get (assoc {} :bar1 1 :bar2 2)?

Hello i am reading mongoDB ,and i saw that they provide so many commands that we can run with runCommand(....)

is there a reason to use the java driver or the clojure wrappers like monger,instead of runCommand()?

I get so so many Grammarly ads... haha.... never knew they used Clojure! Now I'll feel much better about seeing the ads. I turned off personalized ads on YouTube so that's why they come through so much.

Hi guys, I have some questions, regarding startup times. So there is a lot of terms tossed around. AoT - ahead of time compilation. I see this flag in lein. I heard its part of JDK11. Another term that comes up is - GraalVM and native-image. So in context of startup times and performance what are the differences? I presume graalvm and native produce binary that is statically linked(with different vm)? Wheras aot in java produces a jar and requires runtime env? So what are the implications for startup time?

In simplest terms: native image is that: everything is pre-compiled for you, in terms of starting the jvm and your application jar, you have the overhead of the JRE starting, your application classes being loaded, Clojure runtime etc.

Oh ok, yeah skipped the jre impact. Thanks, had hard time understanding why Graalvm is so great(and then you actually read about problems and limitations) if jdk supports aot, but that makes sense.

@roguas "Wheras aot in java produces a jar" -- just to clarify: AOT in Clojure is not actually needed. You can build a JAR or "uberjar" without using AOT at all. You can run such a jar like this

java -cp path/to/the.jar clojure.main -m your.entry.namespace

If you AOT compile your Clojure application (not library) starting from your.entry.namespace and you have (:gen-class) in that namespace and a public -main function and the JAR file also includes a "manifest" file and that file names your.entry.namespace as the Main-Class, then you can run such a jar like this:

java -jar path/to/the.jar

also on a linux system you can just treat a jar like that as an executable (no need to explicitly invoke java)

It's probably also worth noting that even with such a jar (AOT compiled, with a designated main class etc), you can still run a Clojure REPL:

java -cp path/to/the.jar clojure.main

java -cp path/to/the.jar clojure.main -m another.namespace

True, yes, you can just double-click a JAR file on some systems too.

Ok, so there is a measurable startup penalty, when using jdk, aot or jit? as oposed to Graalvm

It depends on a lot of things. If you're trying to run something as if it were a command line script, you'll notice the startup time of the JVM and, especially, the compile-on-demand time of Clojure if it's anything but a fairly simple program. If you AOT compile the Clojure code for the uberjar, that compile-on-demand time will go away but you'll still have the startup time of the JVM and the time it takes to load all the compiled classes from the JAR file. If you can get your code compiled and acceptable to Graal to produce a native image, that startup time will be very small -- but you lose a number of dynamic features of Clojure doing that.

I don't find startup time to be much of a problem in practice because I run my REPL for days (or weeks) so I only pay that startup time overhead once a week or so -- and our production uber JARs are AOT compiled and they're long-lived server processes anyway so it doesn't matter if they take "a few seconds" to startup.

Yeah sure I get that, but if you intend to run code in FaaS it does 🙂

What are the features that go missing in case of graal? Is the usability of clojure in that case questionable?

It's static: you cannot dynamically load any classes, meaning you cannot define new functions, vars etc. Think of it as a immutable version of your program. It has extra restrictions in terms of compilation (you need to typehint your code) as well as you're restricted in terms of library choice. It really depends on what you're after - if it's a simple clojure interpreter with fast startup time check out #babashka

The codebase already exists, im just making rounds trying to optimize it/retrofit it into faas.

It's sufficiently large, I managed to compile it(with graal) but had to downgrade to 1.8.