This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-27
Channels
- # announcements (1)
- # babashka (2)
- # beginners (64)
- # cider (1)
- # cljs-dev (49)
- # cljsrn (2)
- # clojure (49)
- # clojure-europe (3)
- # clojure-norway (1)
- # clojure-spec (7)
- # clojurescript (116)
- # conjure (3)
- # cursive (4)
- # datomic (1)
- # emacs (2)
- # fulcro (15)
- # graalvm (10)
- # kaocha (1)
- # leiningen (4)
- # meander (1)
- # music (1)
- # off-topic (7)
- # re-frame (37)
- # reagent (3)
- # releases (1)
- # rewrite-clj (6)
- # sci (4)
- # shadow-cljs (16)
- # sql (8)
- # tools-deps (16)
- # xtdb (5)
I'm trying to use depot, but it only reports outdated dependencies in my main :deps
; it doesn't seem to check dependencies in aliases even when I add those aliases at the CLI. Is this just me? If not, have others found a way around this?
For example: clojure -A:outdated:backend
Here's a minimal deps edn for the above:
{:deps {}
:aliases {:backend {:extra-deps {org.postgresql/postgresql {:mvn/version "42.2.12"}}}
:outdated {:extra-deps {olical/depot {:mvn/version "1.8.4"}}
:main-opts ["-m" "depot.outdated.main"]}}}
With depot
, you have to use -a
for the aliases that your project uses.
Run clj -A:outdated --help
for more details.
Thanks!
You may already be aware of this, but it bit me in coming over from lein-ancient
: depot
only checks your explicitly declared dependencies, but does not check transitive dependencies.
This is why deps.edn
-based tooling should use t.d.a. to handle the dependencies instead of trying to read the EDN files directly. You get confusing semantics.
We gave up on Depot at 2.0 when they changed the semantics (from t.d.a. to reading EDN files) and we wrote a script based on clojure -Stree
to do arbitrary depth outdated deps analysis.
It's ugly but it has the "correct" semantics and it can check any path through your classpath building alias combinations.
@seancorfield I couldn't find anything quickly - why did they decide to read EDN files instead of using t.d.a?
The original Depot (up to 1.8.4) used t.d.a. for the analysis but the update/rewrite code had to read the EDN file anyway and it had different semantics (first bad idea) then in 2.0 the analysis was rewritten to use the same EDN processing as the update/rewrite code (second bad idea).
Sorry for coming back in so late, but by any chance is your script available somewhere public, @seancorfield?
Haha... no, I'm somewhat ashamed of it -- it's a pretty serious hack! I may try to turn it into a releasable form at some point but it's low on my priority list.
It's about 30 lines of fgrep
and sed
🙂
The TL;DR is that it runs clojure -Stree
(with whatever aliases you want) and then pulls all the top-level dependencies from that output. Then it creates a new temp project and builds a deps.edn
file with all those dependencies with versions replaced with {:mvn/version "RELEASE"}
, and then it runs clojure -Stree
on that project and then sorts and diffs the output of the two clojure
commands, and formats that into a nice table.
Thanks!
Question about clojure.core.reducers
: that namespace has several ForkJoin helpers declared, most of which are private https://github.com/clojure/clojure/blob/master/src/clj/clojure/core/reducers.clj#L20-L34 but strangely both pool
and fttask
are public, although they are not part of the API documentation https://clojure.github.io/clojure/clojure.core-api.html#clojure.core.reducers -- If a library wants to implement CollFold
, it's likely to need the equivalent of these helpers, and it seems like it should also use the same pool
so I'm wondering how folks are going about this?
I'm working on next.jdbc
and making plan
support CollFold
. The result of execute!
is already foldable because it's "just" a vector and c.c.r already has a fork-join implementation for vectors (`foldvec`). Since you need to use plan
if you want to stream result sets from a database and process them on-the-fly, I want that to be foldable so you can reduce in parallel to improve the performance of processing very large streamed result sets. I have a working implementation but I found myself copying in some of those private helpers as they clean up the code substantially and I am relying on clojure.core.reducers/pool
so that my CollFold
implementation shares compute resources rather than competes with the reducers library.
How many folks are using the reducers stuff and, in particular, the parallel fold stuff? Has anyone implemented CollFold
?
Interesting article on choosing Discourse over Slack: https://dgraph.io/blog/post/dgraph-shutting-slack-using-discourse/
This doesn't belong in this channel. #community-development is for discussions about Slack alternatives etc. @U0W13P4LX
Feel free to post it in that channel if you want. I've deleted it from here.
@seancorfield Ghadi recently placed this comment on Reddit:
> Besides the idea of fold
, I would not use reducers anymore. Transducers are a much better construct/design, fully decoupled from collection.
https://www.reddit.com/r/Clojure/comments/hf772r/reducers_in_clojure/fvzqjye?utm_source=share&utm_medium=web2x
Yeah, I had a feeling that I'd seen something around that @borkdude Thanks for the link. @dpsutton https://grep.app/search?q=%23%27r/fj shows that quite a few libraries out there are relying on the internals of clojure.core.reducers
at this point 😐
Interesting that @ghadi calls out fold
as being still worthwhile. I wonder if we'll see an official parallel fold implemented over transducers...
We talked about it when transducers went in
That tesseract library has an impl of this I think?
https://github.com/aphyr/tesser is what I’m thinking of
But maybe I misremember
"Tesser folds do not preserve the order of inputs" 😞
Tesser is way more complex than I'd want to use, when there's clojure.core.reducers
available today. If I wanted to easily managed Hadoop jobs etc, yup, Tesser looks great.
what web servers support websockets? I've been using immutant for a long time, but I've been hearing that its basically un-maintained nowadays
I've been using http-kit, https://github.com/http-kit/http-kit. I think it's also looking for maintainers, but I haven't had any issues with it and I'm not sure what new features I would be interested in
Yeah, I'm still pretty happy with Immutant, so I doubt I'll be changing code that isn't broken. But I am curious what I should be using for new projects. I'll look at http-kit, thanks.
Jetty supports WebSockets according to its docs.
At work we're using Netty and a Java-based http://Socket.IO library via interop but that's a fair bit of heavy lifting.
If you're using a http://Socket.IO client, I don't know how easy it is to use anything except that server-side library so it'll depend on what you need WebSockets for @U0LE4C7CK
https://gist.github.com/hiredman/9a086f7b34f8d4fc3f95a251a616bafd is a toy nio server that speaks just enough http to upgrade to websockets (and doesn't support all of the websockets rfc)
The subscription support in Lacinia is based on Pedestal (Jetty) and web sockets. So Pedestal does a good job, AFAIK.
Ok, I looked at Clojure Web Servers blog post by http://purelyfunctional.tv[0] and it looks like there aren't a ton of choices if you want websockets. I'm thinking the ring-jetty9-adapter[1] looks promising, I don't know if I'm ready to go into pedestal-land. [0]https://purelyfunctional.tv/mini-guide/clojure-web-servers/
I am looking forward to see how https://github.com/metosin/pohjavirta progresses, too. I like ikitommi's focus on performance. That and those metosin guys keep coming up with brilliant stuff
Jetty supports websockets decently. Jetty is my goto-choice because it has like all the features. Of course there are alternatives, but HTTP is sort of complicated these days.