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.

@UHK6DHM19 a warning about eval - it isn't done in the current lexical context

(that shouldn't matter for vars of course)

Wow, never thought starting a ring server without lein can be this complicated. Thanks anyway.

Huh? There's nothing complicated about just starting a Ring server. It's like two lines.

But you want to learn about more than just Ring for building web apps and that combines a decent base of libraries -- and shows how you can start either Jetty or http-kit to run Ring.

(! 516)-> clj -Sdeps '{:deps {ring/ring {:mvn/version "RELEASE"}}}'
Downloading: ring/ring/maven-metadata.xml from clojars
Clojure 1.10.1
user=> (require '[ring.adapter.jetty :refer [run-jetty]])
2021-01-06 13:59:06.924:INFO::main: Logging initialized @18382ms to org.eclipse.jetty.util.log.StdErrLog
nil
user=> (defn app [req] {:status 200 :body "Hello, World!"})
#'user/app
user=> (run-jetty #'app {:port 8100 :join? false})
2021-01-06 13:59:44.580:INFO:oejs.Server:main: jetty-9.4.31.v20200723; built: 2020-07-23T17:57:36.812Z; git: 450ba27947e13e66baa8cd1ce7e85a4461cacc1d; jvm 15+36
2021-01-06 13:59:44.618:INFO:oejs.AbstractConnector:main: Started ServerConnector@658255aa{HTTP/1.1, (http/1.1)}{0.0.0.0:8100}
2021-01-06 13:59:44.619:INFO:oejs.Server:main: Started @56076ms
#object[org.eclipse.jetty.server.Server 0x26f46fa6 "Server@26f46fa6{STARTED}[9.4.31.v20200723]"]
user=> 

(! 627)-> curl localhost:8100
Hello, World!

(run-jetty #'app {:port 8100 :join? false})

@suren If it helps, I've just updated the example code to a) remove all the conditional logic around http-kit (and instead include comments showing how to switch from Jetty to http-kit) and b) add more comments about the promise used to wait in -main and c) add more REPL-friendly comments and code for the context of using a socket REPL in the running program.

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) 😉

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 :)

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

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

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.