Not easily - the CLI has a hard wired dep on Clojure in the root deps.edn

But you can get around that a few ways, like by using an alias with :classpath-overrides or :extra-paths that points to a jar or dir

something like that would work also, let me see

hmm but it only works with a local folder or jar maybe, so no way of replacing your clojure compiler with a clojars one?

No, this was not considered a core use case when we designed it :)

I just created this https://ask.clojure.org/index.php/12658/feature-request-excluding-default-clojure-compiler-project , do you think there is a chance for it?

Sure, not against it but would need to think about how it could happen

great! Thanks!

I guess really it would require suppressing the root deps.edn, similar to how -Srepro ignores the user deps.edn

what else would that bring down? apart from the default compiler?

What about org.clojure/clojure {:local/root "yourown"}?

@U04V15CAJ yeah but if you want to provide that dev compiler as a tool for other people is kind of inconvenient

That’s the only dep (well, transitively spec and core specs), but this is also how you get :deps alias and paths etc, so this would break other expectations

Let me step back and ask if your goal is to test something or to actually distribute something that depends on this?

my goal is to create a fork of the clojure compiler that you can use only for dev. So it is the exact same clojure compiler but with a couple of patches I can keep rebasing with each version, patches for emitting some extra bytecode for debugging your code. So for it to be convenient you need a way of specifying the dev clojure compiler under your dev alias, and then have your standard clojure compiler for everything else

does it make sense?

to be more concrete I have been experimenting with https://github.com/jpmonettas/flow-storm-debugger but instead of instrumenting on demand by re-evaluating code, just modifying the compiler so everything is always automatically instrumented

if you want to have it under your dev alias, you can do {:aliases {:dev {your-compiler {:mvn/version ...}}}} and your compiler will be on the classpath before the official compiler and it would "just work" ™️ ?

oh, so it is guaranteed that every class and .clj file will be loaded instead of the ones of the original compiler by just doing that?

.class files are always loaded before .clj ones

but if your clojure compiler mirrors the .class + .clj structure of the original, then it'll work

yes they do, since it is the clojure compiler with a big patch which doesn't move files around

if that works then that is all I need

I'll give it a try

thanks!

I don’t get why you think that will work borkdude

deps and paths in aliases go before top level deps on the classpath, right? at least that's what I've been seeing. that is why it will work

Not deps

extra-paths, then paths, then the merged deps, which are in depth order then alpha sorted at each depth right now

oh I see, then it won't work

damn, was too good to be true

but classpath-overrides will still work, probably

It does but you have to give it an explicit path

nil works

or ""

(That’s one way I work with Clojure dev)

I'm also using classpath overrides in bb to remove clojure + spec from the classpath when loading bb deps

but you can't use mvn coordinates with classpath overrides, which makes it inconvenient for tooling

@U0739PUFQ What you do is:

{:aliases {:dev {:extra-deps {your-compiler {:mvn/version}}
  :classpath-overrides {org.clojure/clojure nil}}}

oh, I see

so that is basically the :exclude-clojure? true I was asking for the the Ask clojure question then

nice, will give that a try! thanks!

did that work?

I'd be surprised if it didn't:

/tmp $ clj -Spath -Sdeps '{:aliases {:no-clj {:classpath-overrides {org.clojure/clojure nil}}}}' -A:no-clj
src:/Users/borkdude/.m2/repository/org/clojure/core.specs.alpha/0.2.62/core.specs.alpha-0.2.62.jar:/Users/borkdude/.m2/repository/org/clojure/spec.alpha/0.3.218/spec.alpha-0.3.218.jar

yes, it worked!!

I'll add a comment to the ask clojure question

thanks @U04V15CAJ and @U064X3EF3!

oh, you already added it @U04V15CAJ, great!

the nil thing used to raise an error but pretty sure I fixed that for some use case like this in the past

I think I used to do an empty string or nil and then you suggested the reverse (can't remember which) but this ended up adding an empty path on the classpath, which you then fixed

https://github.com/clojure/tools.deps.alpha/commit/1fbcc510a71075f9b86e8ef83c0b8bd8400f3583

This was exactly my use case in bb and I remember it being discussed around that time in 2021

ah

None, as far as I know, as it’s something Rich invented

We did publish impls in Java, JavaScript, and Python though, as examples

It is a little similar to stream fusion in Haskell, but that’s compiler magic

racket has something somewhat similar

iirc it was written after the clj implementation, inspired by it

@U064X3EF3 as far as you know, was there any source of inspiration (thinking of academic papers for example) for the concept itself? (the answer to this might well be in A history of Clojure I guess)

It was Rich’s invention. He did actually search for papers where someone may have come up with it and did not find any

There are some papers with things called transducers that are different things

An implementation for Scheme https://www.thatgeoguy.ca/blog/2023/01/04/reflections-on-transducers/

I recall a scala person I know talking about something called transducers in the scala lib and found this : https://stackoverflow.com/questions/27816946/what-are-the-similarities-and-differences-between-scala-transducers-and-clojure ... but I think that they're slightly different things ... (my scala is pretty feak and weeble)

Isn't it equivalent to operators fusion?

Karsten Schmidt implemented transducers in Typescript: https://github.com/thi-ng/umbrella/tree/develop/packages/transducers

@UK0810AQ2 Operator fusion[1][2] minimizes the cost of the plumbing between the operations in a series by reducing the number of operations in the series. Transducers minimize the cost of the plumbing by eliminating the plumbing. [1] https://akarnokd.blogspot.com/2016/03/operator-fusion-part-1.html [2] https://learn.microsoft.com/en-us/windows/ai/directml/dml-fused-activations#how-to-fuse-activations

@U0HG4EHMH since java doesn't have multi stage evaluation, isn't operators fusion implemented like transducers in Rx streams?

I don't know if I'm up-to-date, but in any case what the linked pages [1] and [2] describe as "operator fusion" is significantly different from Hickey's transducers: In both [1] and [2], the framework relies on specially-coded special cases based on knowledge of the operations it provides, and the operators are built to operate in only one context, e.g., streams. Transducers, on the other hand, are an open set, each one blissfully unaware of the others and of the processing context.

I could not really find anything, but in theory it's not hard, even though it might be very computationally expensive I guess

comparing any form with any form at least, if we just limit to defns maybe then it's not too bad

https://github.com/Datomic/codeq you might want to look at codeq, which allows for Datalog queries against a Clojure codebase.

I think there was a more recent effort at putting the output of tools.analyzer in a Datalog DB but haven’t found it yet.

https://github.com/bsless/tools.analyzer.datalog

these might be interesting ways of trying to do form-level comparisons across a codebase

ah yes I just remembered that there is this as well https://github.com/jpmonettas/clindex

which might be handy as well

It's a bit old now but I like [this clojure-saxon library](https://github.com/pjt/saxon). It allows you to write clojure functions that are backed by XPath statements. XPath is a language you can use to extract nodes from a given xml document. It's the same sort of concept as the clojure specter library.

hiccup makes a decent xml interop layer. Are you just putting the xlm straight in, or transforming it?

I guess you first want to define heavy load and on what kind of hardware(or VM) you want to run. (CPU count, memory etc.)

It might be helpful to discuss why you want an alternative to jetty or undertow

and what is the limiting factor? CPU? network I/O or disk I/O?

Jetty has been pretty dependable at work, we dabbled in httpkit but of I recall switched back to jetty because newrelic was better able to report metrics for it out of the box

I’ll try to get those specific answers and report back.

Undertow has a particular threading model, which I don't think the ring adapters I have seen for it handle well

We also use jetty at work with very very high scale

We also use a netty based http server at work, netty being a kit for building http servers, and I hate it (mostly because netty is very commonly used and managing dependencies in a large project with it is gross)

That was my understanding as well, that it was very robust.

I would avoid any talk about virtual threads. I understand the enthusiasm for them, but it is way too early for any best practices or understanding how they impact api design

While I’m waiting on the answers (other than 8 core 64GB CPU) is it foolish to run benchmarks on a mac while deploying on Linux? Even if only to get general impressions of performance?

general impression I would say yes, but the real thing might be different of course.

There are also guides out there for tuning jetty (although I don't think we change any of the defaults)

Yes I have to say in my experiments I got the best performance out of http kit and undertow But I want to revisit them

While HTTP Kit receives little maintenance, it works well and I couldn't get other servers to beat it in my benchmarks

we have been running http-kit for 8 years under all kinds of loads, never had performance issue with it.

There is a new option with nima - Someone wrote a ring adapter recently too. Don't know its relative performance though

For heavy load (as in maintain potentially a hundred active websocket connections that cause the server to run various handlers and make pretty expensive database queries) on top of ordinary HTTP API endpoints being hit, Undertow has been reliable for this purpose. I can’t comment on HTTP Kit besides it being relatively small and the client not supporting cookies yet… I’ve briefly tried using it for a server but didn’t feel comfortable with the lack of HTTP/2 support.

It all depends on the nature of your application. In most situations, it's likely that the main bottleneck will be the database - running many non-trivial concurrent queries it's gonna impose a great load on it.

So we went through several options: aleph, jetty9, jetty11, undertow, httpkit w/virtual threads, and we ended up back at jetty9. Httpkit looked good, but doesn’t do streaming responses, and that’s a must for us.