This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-19
Channels
- # announcements (15)
- # babashka (4)
- # beginners (55)
- # calva (92)
- # cider (70)
- # circleci (1)
- # clj-kondo (136)
- # cljdoc (2)
- # clojars (11)
- # clojure (48)
- # clojure-australia (1)
- # clojure-europe (30)
- # clojure-nl (3)
- # clojure-sweden (2)
- # clojure-uk (7)
- # clojurescript (40)
- # conjure (5)
- # core-async (11)
- # cursive (55)
- # data-science (1)
- # datomic (10)
- # degree9 (2)
- # development-containers (15)
- # events (1)
- # fulcro (14)
- # gratitude (13)
- # helix (5)
- # lsp (35)
- # malli (10)
- # meander (18)
- # off-topic (24)
- # pathom (13)
- # polylith (12)
- # practicalli (6)
- # re-frame (13)
- # reagent (33)
- # reitit (4)
- # remote-jobs (1)
- # shadow-cljs (13)
- # spacemacs (31)
- # specter (1)
- # stepwise (2)
- # tools-deps (19)
- # vim (1)
- # xtdb (7)
Any opinions on using immutant vs http-kit? Are they necessarily mutually exclusive?
They are both HTTP servers. Like Jetty.
Immutant hasn't been updated in 3 1/2 years. http-kit is still maintained (but not actively developed I believe at this point).
Jetty is the most common HTTP server that folks use with Clojure I think @bradj4333
We use Jetty at work -- to power the backend of 40+ online dating sites.
We used http-kit for a while but New Relic, which we use for monitoring, doesn't support it very well, so we switched (back) to Jetty.
We still use the http-kit client library but once our legacy apps are off Java 8, we'll probably switch to Java's built-in HTTP client.
Does that help @bradj4333?
Thanks @seancorfield that's very helpful. I think I'll want to use Jetty too, then. I didn't know that immutant isn't updated anymore. I see lots of tutorials that use it.
Just letting you know in case you're interested that the 3rd edition of book Web Dev with Clojure was just published: https://pragprog.com/titles/dswdcloj3/web-development-with-clojure-third-edition/ It is what I am working through now. I am only on the second chapter but it is written by the author of one of the most commonly used Clojure web dev 'frameworks'. It is not free but given the author and that it is just published, it is likely to be good info and up-to-date, which can be a problem as you notice with many existing tutorials using now out-of-date tools and libraries.
Hello guys, for those of you uses websockets, has anyone ever used https://github.com/ptaoussanis/sente in a commercial product? The background is I'm weighing different solutions between i) native websocket ii) sente iii) http://socket.io (by https://github.com/mrniko/netty-socketio)
Not in a commercial product, but certainly a few hobby projects. If you're a pure clj/cljs stack it's extremely excellent and handles a lot of the crap bits for you (eg shaky connections)
there's some weirdness (eg. an underlying utility lib that has weird code that's way too low level and sometimes has very strange bugs), but it works. I'd be tempted to use the websocket API directly next time to be honest, with a router on each end (I bet bidi could be used directly, it's not that http specific...)
Does anybody know of a good tutorial on clojure + mpi? My google-fu mainly points to comments from several years ago, that clojure and mpi aren't really a thing, so I am not sure what the current status of that is. Any help/direction would be much appreciated.
I think neanderthal might be the place to start - if I interpret what MPI is correctly
“message passing interface” i think
Yes, MPI="message passing interface". I mainly work on HPC systems at the moment, which uses mpi to communicate between compute nodes. Will check out neanderthal, thanks.
http://mpjexpress.org/ this one is the most advanced (imho)
then we can figure out what/if any conveniences it would be nice to have for clojure apps
What is the use of s/keys
's :opt
? The guide says:
> We’ll see later where optional attributes can be useful. Also note that ALL attributes are checked via keys, not just those listed in the :req and :opt keys.
But I cannot find the later part that it refers to.
https://clojure.org/guides/spec#_entity_maps
one use case is generators: :opt
allows them to generate maps with both required and optional attributes.
This and documentation
it is more about cluster of GPUs )
still new to clojure. haven't used in a while, and I know nothing of java. But from googling, yes it seems a java lib may be the way to go. In terms of the kind of communication, on the systems I work on, the only way for a set of tasks to be distributed over a set of nodes (so between the nodes, and therefore leverage more compute), is to use the mpi protocol. The program interfaces with a scheduler like SLURM or TORQUE, and sadly LSF too. So you effectively have
srun -n 12 java ...<best process and code ever>...
jsrun -n 12 -a 1 python ...<more awesome stuff>....
Could anyone explain the difference between wrapped :require
entries and ones that aren't wrapped in a vector? Here is an example: https://github.com/fulcrologic/fulcro/blob/174f5ad36373eba5385fb1e3e9f85b1943547c0b/src/main/com/fulcrologic/fulcro/algorithms/tx_processing.cljc#L18
> A libspec is a lib name or a vector containing a lib name followed by options expressed as sequential keywords and arguments.
(doc require)
. But the shorthand is that you need to require code so that it is compiled by clojure and available. You can optionally add an alias to the namespace so you don't need to use a fully qualified name. (:require clojure.set)
and then in code (clojure.set/union ...)
vs (:require [clojure.set :as set])
and in code (set/union ...)
@dpsutton but in the example link I posted there are these three lines (in order):
[com.fulcrologic.fulcro.specs]
[com.fulcrologic.fulcro.inspect.inspect-client :as inspect :refer [ido ilet]]
com.fulcrologic.fulcro.specs
So the first one is wrapped in a vector, and the last one is not. They are otherwise identical. Neither of them refer any symbols or alias the namespace.:as inspect
creates an alias for the namespace. :refer [id ilet]
refers to symbols in the namespace. i'm not following what you mean
just between libspec
and [libspec]
there is no different. the unwrapped version is preferred i believe
and the duplication should be caught by a linter and removed but does not harm anything
Linters will typically assume [libspec]
means you're loading the namespace for its side-effects (declaring spec, protocols, multimethods) and will not flag it as unused.
> Linters will typically assume [libspec] means you're loading the namespace for its side-effects
that's odd, because my convention was always that [libspec]
means I intend to use the ns explicitly, but don't want and alias, while libspec
is loading purely for side effects
this is sort of a back-formation though - seeing that both syntaxes are allowed and then deciding on a distinction that seems to suit that variation
oh, I bet you mean [libspec]
as opposed to [libspec :as ...]
Correct. Because I always wrap all my libspecs.
(but I think some linters do draw a distinction)
I just checked clj-kondo and it does not seem to care so maybe I'm wrong.
But that's just convention.
I prefer seeing wrapped libs always -- and in alphabetical order (my OCD!). I think it looks really odd to see a mix of wrapped and unwrapped -- and in the code above, it's just a "bug" that the same ns is required twice. It's harmless but should be "fixed".
(I have clj-kondo configured to flag unsorted ns requires as an error and my colleague wrote a little Clojure script that sorts ns requires so I don't complain in PR reviews 🙂 )
Thanks for the input. To be clear, I was only wondering about the difference between [libspec]
and libspec
in the :require
reference, as well as the duplication. It sounds like I should just stick to the wrapped libspec and the duplication is of no significance in this case.
@seancorfield Interesting that you prefer them to be sorted. In Python there is a convention of putting the most low-level imports near the top and working your way down to imports from your own application last. I've been naively following the same convention in Clojure, but I guess it's not a thing I should be doing.
different styles and "best practices" come up because people tend to flock to one or another. But there is always room for new patterns to emerge. And that pattern is not without its merits.
> Linters will typically assume [libspec] means you're loading the namespace for its side-effects
that's odd, because my convention was always that [libspec]
means I intend to use the ns explicitly, but don't want and alias, while libspec
is loading purely for side effects
this is sort of a back-formation though - seeing that both syntaxes are allowed and then deciding on a distinction that seems to suit that variation