Clojurians Log v2

True, running a local REPL instance on a production server, that can spin up the same DB connections etc, is "safer" in terms of not letting you accidentally blow up a running production process. Well, at least not letting you redefine the code -- you can still blow up production via the DB at that point 🙂

With great power (REPL) comes great responsibility!

Hey everyone, this is a wonderful discussion! Glad to come back and find so many comments. I think that's a great point @didibus -- the argument for a remote Clojure REPL (if I'm understanding this correctly) -- and the argument for ssh are effectively the same argument. (also @seancorfield your notable insight is really helpful. Always good to see/hear how the pros like you and @hiredman do it!)

Hello, I'm trying to understand why this happens:

user=> (var (symbol "meta"))
Syntax error (ClassCastException) compiling var at (REPL:1:1).
clojure.lang.PersistentList cannot be cast to clojure.lang.Symbol
user=> (eval `(var ~(symbol "meta")))
#'clojure.core/meta

var is a special form so var tries to convert a list (symbol "meta") (not a symbol meta as a result of the evaluation of (symbol "meta")) to a Var object and then explodes.

you can use resolve to do it

user=> (resolve (symbol "meta"))
#'clojure.core/meta

https://clojuredocs.org/clojure.core/resolve

https://clojure.org/reference/special_forms#var > Special forms have evaluation rules that differ from standard Clojure evaluation rules and are understood directly by the Clojure compiler.

How to run a ring server while using deps.end instead of lein ?

@suren Take a look at https://github.com/seancorfield/usermanager-example which is a deps.edn project using Ring (and a few other libraries) to provide a fairly simple web app example.

I guess everybody knew this, but I didn’t:

(let [input {:a 1}
        {:keys [a b] :or {b :default} :as m} input]
    ; Why isn't the (:default in) b carried forward in m in this case?
    ; The `:or` assigns defaults for some of the keys for this scope, 
    ; but doesn't alter the m, this has bitten me a couple of times now...
    [a b m]
    
    ; I have to assoc in order to bring the default further, or reimplement the 
    ; default in the next context:   
    (passing-further (assoc m :b :default))

To me the :or clause in the destructuring reads like "if the symbol b is unassigned give it the value :default" and says nothing about m ... m is the whole thing you're trying to destructure (basically input)

Yes, that is totally reasonable

But while reading the code, my mind went on a completely different road, so to speak

the :keys bit is just shorthand for {b :b a :a} and could equally be {b :fish} and you'd still write the symbol not the keyword in the :or ... as in {b :default} not {fish :default}

So I could put arbitrary assignments in the :or section?

I don't think so no

right…

you'd have to do

(let [input {:a 1}
        {:keys [a b c] :or {b :default c 1} :as m} input]
    [a b m c])

or

(let [input {:a 1}
        {:keys [a b] c :other :or {b :default c 1} :as m} input]
    [a b m c])

that last one does not make much sense to me

but I see that it allows for mentioning the c in the :or section

the :keys part is expanded out into {a :a b :b ... } so adding c :other is just adding a new local that's bound to the value of (:other input)

so the :other is just for keeping the fields even

you look at the code that actually gets generated with

(destructure '[{:keys [a b] c :other :or {b :default c 1} :as m} {:a 1}])

yeah ... the :other keyword is just something that's not expected to be there ... but I'd not expect that to be something you'd actually write in a program ... I just meant it as a response to your arbitrary assignments question .... if you wanted another local that was nothing to do with the input that's getting destructured, why would you include it in the destrucuring form rather than as a local in a let?

am I making sense?

absolutely

cool ... first time for everything 😉

thats cool

I found the destructure function useful when learning how that all worked ... and it's great that you can just call it from your own macros (if you need to) 😉

over the last few days I've played with java FileLocks and found that that a popular pattern, namely obtaining .lock from a FileChannel from a RandomAccessFile, simply doesn't work (on macOS, encrypted APFS). Other files will also be able to obtain the lock, while other process holds it, allowing race conditions to happen. Luckily this doesn't happen when using FileChannel/open directly. I think it's because RandomAccessFile is more oriented towards per-file-region locks, while FileChannel/open is more oriented towards whole-file locks. And my hypothesis is that per-region locks are less guaranteed to be implemented across all OSes/FSes. Does this sound familiar to anyone?

I have not used these methods before, but this StackOverflow Q&A might be relevant: https://stackoverflow.com/questions/56458266/java-nio-filelock-allows-other-process-to-write-to-a-locked-file

It appears that part of the Java docs for those methods say that locking behavior is OS-specific.

Yes, but file locking is certainly possible in my machine. Both java FileChannel/open, and traditional C flock (which I tried out via Ruby) effectively lock a file acros processes. It looks like in the JVM, some advanced features, if cannot be offered, degrade to "no locking at all" instead of to "a more coarse-grained kind of locking" Which would seem a pretty poor choice

Given the Java documentation for the FileLock class, all it promises is "advisory locking". If you want any more guarantees than that, it appears that those Java methods will not guarantee anything more for you. You can test and/or dig deeper into implementation details of how your JVM implements those methods, but without that work, you aren't going to get more promises from those methods than what is documented.

I can easily imagine that file locking mechanisms differ enough across different OS's that it would be at least difficult, and perhaps impossible, to promise the same behavior across all OS's.

that is, to promise mandatory, versus merely advisory, file locking on all OS's

the mechanisms I described as "working" are advisory and I'm fine with it - I just want multiple JVMs under my control to honor a protrocol I think that RandomAccessFile can grant a "no-op" lock, not advisory I might even try reporting it as a bug although I wouldn't be optimistic :)

what’s the benefit of using a namespaced keyword versus a qualified one? since i may not be using the exact correct terminology, an example:

(ns acme.events)

;...
::foo
;...

(ns acme.views
  (:require [acme.events :as events]))

[:a {:on-click #(submit ::events/foo)} "foo"]

(ns acme.views)

[:a {:on-click #(submit :events/foo)} "foo"]

You are welcome to, but realize that they might just point you at that part of the Java documentation 🙂

::foo is a sugar for :current-namespace/foo and if you have aliased bar to b, ::b/foo is a sugar for :bar/foo

sometimes the extra information of the precise namespace the keyword was generated in is useful

or maybe a function expects a keyword matching its own namespace, to avoid collisions

If it got a "/" in it, the keyword is "namespaced", the keyword namespace being what's before the "/" and the name what's after. "Keyword namespaces" and "clojure namespaces" have nothing to do with one another - but one can otherwise use matching names to imply provenance. I tend to use: • :foo/bar in entities (data that models a domain, the namespace identifies the entity and the name the attribute). • :actual.clj.nsp/bar when I want the keyword to give me a hint on what clojure namespace it's in relation with (where functions that make and process it are); also when I want to make sure I'm not gonna be in conflict with other libs / project / portions of colleagues code using the same keyword for a different purpose. • :plain otherwise

IMO ::foo should be avoided for any keywords that will be used outside of code that you control, e.g. sent over the wire or used in a library config, since it limits your ability to make namespace changes to data. (We’re used to carefully considering the location of code that will be exposed as part of a public API, but we’re less accustomed to considering the location of values within our code as part of a public API.)

how does it limit it? one can use the fully qualified name externally, ie. :some.nsp/foo

but that means a namespace refactoring inside your code means matching changes can be needed elsewhere

you would normally never have ::foo to send over a wire in the first place

printing will never print an autoresolved keyword

I think they meant the value produced by resolving ::foo - since it includes the ns

ok

which means the implementation detail of your ns organization is now part of your data model

Sorry, I don’t mean literally sending ::foo – more that if you send :com.company.util.routing/something and then want to move that, now your code is forced to reference a keyword namespaced with a prefix that no longer reflects your code structure. I guess I’m just encouraging people to be particularly intentional about the selection of namespaces for values, and :: kind of lets you wave your hands over that decision.

I’ve often wondered about what the implications of a separate namespace universe for “values” would be. But in lisp that distinction is really blurry, so I think that idea would probably fall apart pretty quickly. (Possibly shares some of the same tradeoffs from the lisp1/lisp2 argument.)

I use keyword in clojure namespace to enforce the requirement of the namespace:

(ns a)
(defmulti  my-multi :kw)
(ns b)
(defmethod a/my-multi ::foo [_] (println "here am I"))
(ns c)
(require '[a :refer [my-multi]] '[b :as b])
(my-multi {:kw ::b/foo})

So this is mostly an issue with public data, right? Would it be prevented by always putting public API specs in a namespace that is either: 1. separate from where the code is, e.g. <org>.<app>.spec or 2. generic enough that it won't be changed, e.g. <org>.<app>.api? The reasoning here is to be able to replicate the user's experience, so renaming a namespace as described above should break the api on your end before it breaks on the user's end. I'm pretty sure I'm missing something though 🙂

Can changes be made atomically? If yes, then you’re right, this is probably a non-issue. If not, then you should be designing your data model with longevity in mind. “Public data” can’t be changed atomically. Neither can private data that crosses a non-transactional boundary. It turns out that most values cannot be reliably changed atomically - the only common exception that I can think of is library implementation details.

I was mostly talking about detecting a breakage before it reaches the user. If you already know that e.g. renaming a map key breaks your api maybe you shouldn't do it or if you really don't like the current name, I can see two paths forward: 1. add the new name but keep the old one for compatibility reasons 2. depending on the extent of the breakage you might need to introduce a second API At least this is what I got out of https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/Spec_ulation.md...

Oh, I misunderstood you. Yeah, spec seems like a great way to draw a line in the sand between public and private values.