This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (24)
- # aws (2)
- # babashka (20)
- # beginners (147)
- # cider (20)
- # clara (43)
- # clj-kondo (3)
- # cljdoc (15)
- # cljsjs (1)
- # cljsrn (36)
- # clojars (19)
- # clojure (64)
- # clojure-europe (4)
- # clojure-italy (45)
- # clojure-nl (1)
- # clojure-spec (20)
- # clojure-uk (26)
- # clojurescript (16)
- # cursive (9)
- # datomic (18)
- # dirac (14)
- # docker (3)
- # fulcro (48)
- # keechma (1)
- # leiningen (32)
- # luminus (1)
- # off-topic (40)
- # pedestal (1)
- # quil (1)
- # re-frame (24)
- # reagent (3)
- # reitit (3)
- # remote-jobs (2)
- # ring-swagger (4)
- # shadow-cljs (115)
- # spacemacs (22)
- # specter (4)
- # tools-deps (76)
I'm having a funny situation where the jetty server in a default pedestal app is not reachable over the local network on an osx machine with the firewall opened up for that... all other servers such as the node type servers (http-server) work fine... thoughts?
@macrobartfast check whether it's binding to
The defaults will differ across the variant server types I suspect.
ok... I'll take a look.
I had grepped unsuccessfully for a reference to either but I'll look more carefully.
Some bsd jvm builds (from which the osx openjdk builds were originally derived) would preferentially bind to ipv6 addresses
Why is it recommended in The Clojure Style Guide (https://guide.clojure.style/) to prefer
reset! ? I was checking the implementation of both functions in the Clojure source code and I thought they looked very similar
swap! and reset! are mutations per ce. So you probably want to show in your source code what kind of mutations you want to apply. Also most of code base are not static thing and during refactoring you might catch some problems because you silently dropping everything from the atom
Oh I see, that about dropping silently is a good point! It's actually just a coding challenge, in this case I believe it might be necessary to go with
swap! , but I will certainly consider to use it in other projects to prevent losing data. Thanks for this insight @U04V4KLKC!
For me, both are fine depending on the context. I prefer
reset! by default but only if semantically it makes more sense - i.e. there's no point in trying to force what you're doing into a
swap! at the expense making less expressive code.
I felt that when I tried to force myself to replace it with
swap! and came to mind that maybe it wasn't worth because the data structure stored in the atom wasn't complex, but I wasn't sure, maybe due to my lack of experience, and the style guide did not provide arguments on that recommendation :thinking_face: Thanks @UJF10JP8A
I dunno if the recommendation is about style really. A
(swap! a (constantly x)) can always be replaced by a
(reset! a x) without any problems.
On the other hand, let's say you have an atom that you want to use as a counter. You can't replace a
(swap! a inc) with a
(reset! a (inc @a)) because your count will be less than correct with the second code sometimes.
I believe the section about
swap! in the style guide is missing the point and fails to explain why you should use
reset! (cc @U051BLM8F)
reset! is totally fine if you just want to ... eh .. (re)set a single value that doesn't depend on the previous value
https://www.braveclojure.com/zombie-metaphysics/ is a good resource about this
> Rich Hickey designed Clojure to specifically address the problems that develop from shared access to mutable state. In fact, Clojure embodies a very clear conception of state that makes it inherently safer for concurrency than most popular programming languages
If you use
reset! For updating it you just negate the usefulness of an atom and are using it just as a regular variable like other languages, which is not its purpose
I like that the style guide goes beyond guidance on naming and indentation, going on to recommend better practices. This style guide was probably the single most useful document when I was learning Clojure.
I think you're supposed to avoid pulling values from an atom, calculating new ones and then reset! As that will be more risky than using swap!
I think it means in cases where you read the value of an atom, and then want to update it, you should prefer swap! over reset!
So @U6PCW7E9F, the way you describe your use, it does sound like you're trying to update from a read. You probably want to use swap! then, unless you don't have to be thread safe
I thought both swap! and reset! were thread safe, the code implementation is almost the same for both. I thought that because of the things I had read about as well :thinking_face:
both are atomic, but
f atomically, while
(reset! (f @a)) doesn't (stuff can happen between reading and then updating and resetting the atom)
try this snippet for instance:
(defn inc-val [v] (Thread/sleep 1000) (inc v)) (let [a (atom 1)] (.start (Thread. (fn  (println "With reset:" (reset! a (inc-val @a)))))) (Thread/sleep 400) (swap! a inc)) (let [a (atom 1)] (.start (Thread. (fn  (println "With swap:" (swap! a inc-val))))) (Thread/sleep 400) (swap! a inc))
Could not transfer metadata foo:bar/maven-metadata.xml from/to releases ( pretty often. Any suggestion what might be wrong and how to get around?
compile check any timestamps or anything else to determine that the result is already up to date to avoid unneded compilation?
Thanks! Thought so. An interesting issue because of that. I start using a library v1, I compile its sources, all is good. Turns out, before I compiled it, v2 was released. Eventually, I upgrade to v2 not even thinking about the compilation step since it's done automatically. Since v2 timestamps are before I ran my compilation, the classes are never recompiled. v2 is on the classpath, but in fact v1 is uses.
By any chance does macOS like to randomly hide Java from the Dock? It hinders Swing usability
(normally I set
-Dapple.awt.UIElement=true so it's hidden upfront. Not this time)
...I would say that for a few hours this worked correctly, then java was removed from the Dock just like that
yes e.g. https://hypirion.github.io/clj-xchart/examples was working for me this morning, now it doesn't even after restarting jvm
The library doesn't work at all (how does it fail)? Or using the library you don't get a dock icon?
* the resulting JFrame isn't visible
* no java element shows up in the Dock
(doto ... (.setSize 800 600) (.pack) (.setVisible true) (.toFront) (.show)) doesn't improve anything
the lib worked this morning, 100% sure I didn't change the code or my jvm setup. macOS just decided to stop displaying a Dock icon which makes it hard ever see the JFrame
Let's say you have several components in a project which use sente. What are the factors you consider when determining if the sente object should be totally private/internal to the component, or passed to the component as a dependency, or allowing the user to choose between these two?
@jjttjj as far as I'm concerned one of the main benefits of using a component library is explicitly defining an interface of a module of your program, I'd start by thinking about what makes sense in a flow diagram for the component to consume from another component, and provide to other components, and refine that flow so that it makes it easier to understand your application design
another consideration is when testing that module / the modules that consume it, what would you want to parameterize in order to make the tests as functional and data-oriented as possible
the thing that still trips me up in my projects is config - I definitely want to have parameterized config during testing, but in a system diagram config ends up being an input to everything which seems like a problem
maybe I'm missing something obvious there
Have you played with Integrant at all? I have just a little bit but it seems like it attempts to help this issue
It helps to separate configuration of your comments (usually static) and runtime configuration
@jjttjj yes I use integrant with my current app, and my approach is to explicitly consume a sub-key of config in each component rather than the whole map (but this is a convention and not enforced by integrant)
of course nothing prevents calling
alter-var-root inside a component init then using the config as a var