Not that I can see, no. I also get a file-missing-error when i try to run the .jar

How are you creating the uberjar?

clojure -A:depstar -m hf.depstar.uberjar target/app.jar -S

is it idiomatic to include resources in the jar, or should they be distributed through some other means and placed in the file system?

It's not so much an idomatic thing, just normal. You find that too in Java, Kotlin etc...anything that is "distributable"

Of course, it also depends upon the usecase, for example, some applications load things from the filesystem, some from a database...all down to the needs of the application.

Clojure is no different in that respect, or rather the bundling.

What is your directory layout?

that makes sense, in this case, I just want to deploy a ring-application, so I need an .edn with some data and the regular web-sidekicks

In my projects, I have this in my project-local deps.edn

{:paths ["src" "resources"].........}

When I build an uberjar, everything under resources gets bundled in.

and in there, I have edn files that I load from the classpath.

ah, now the files seem to be there! I had it under :extra-paths,

but i still get Exception in thread "main" .FileNotFoundException: edn/cocktail-schema.edn (No such file or directory)

even though the path in the jar should be edn/*.edn. Is it because I’m reading it with slurp?

Try using io/resource

Let me get you a reference a moment...

https://clojuredocs.org/clojure.java.io/resource

so try (io/resource "edn/cocktail-schema.edn")

If you need to slurp a file from a JAR file, don't call io/file on the result of calling io/resource, or you will get an exception that says the resource is "not a file". Instead, call slurp directly on the result of io/resource.

that makes sense! I guess my naked slurp tried to read form the file system, as it should

that worked, thank you!

You're most welcome.

You may want to ask on the #datascript or #datahike channels for such questions, too.

Also I’m running this with ring.adapter.jetty/run-jetty but the REPL doesn’t seem to be in sync with the state of the server running separately.

are the repl and server in the same vm?

I suspect @games is evaluated before (create-game name) since arguments are evaluated left-to-right in function calls.

here the value of "game" will either be a specific game (if it exists) or all the games defined so far (if it wasn't found, so created)

because swap! returns the entire state of the atom

Hmm, good point. That's another bug.

oh! never mind, this is even worse - game is a global state - the name of the game will change on every request no, I was right the first time

I was momentarily confused by the weird structure of the hash

user=> (def foo (atom {}))
#'user/foo
user=> (defn bar [n] (swap! foo assoc n {:name n}))
#'user/bar
user=> (get @foo "hello" (bar "hello"))
{"hello" {:name "hello"}}
user=> (get @foo "hello" (bar "hello"))
{:name "hello"}
user=> (get @foo "world" (bar "world"))
{"hello" {:name "hello"}, "world" {:name "world"}}
user=> (get @foo "world" (bar "world"))
{:name "world"}
user=> 

In the first get, @foo is {} and does not contain "hello" so the not-found value is used, which is the full hash map after creating the new item.

In the second get, @foo is now the hash map containing "hello" so its value is returned.

Hmm

as for the atom not changing at all, I go back to my first question: you mention a repl and a http server, are they in the same jvm?

> are the repl and server in the same vm? it’s one lein repl and one lein run separately

so the answer is no, so the one in the repl won't change

atoms are local to one process

Ah, I see!

And so is the code -- so changing things in the REPL won't affect your running server.

So I would start the jetty server in the repl process

right,launching a future and binding it is handy for that (def server (future (run-jetty ...)))

that way you can still get at the process (to check if it exited with realized? or see the return value / error by using deref if it has...)

Created a namespace like this with stuff to evaluate when developing:

(ns spyfall.dev
  (:require [ring.adapter.jetty :refer [run-jetty]]
            [ring.middleware.reload :refer [wrap-reload]]
            [spyfall.game]))

(comment
  (def server
    (future
      (run-jetty (wrap-reload #'spyfall.game/handler)
        {:port 3000 :join? false})))
  )

if you use join? false already, you don't need a future, sorry

but yeah, that's the idea

😄

Sorry I’m completely new to this

oh no, the facepalm was at myself, I should have remembered that run-jetty already lets you start in a background thread and return a server handle

But it’s interesting with the more general approach

Knowledge that can be transfered

So this made things work better

(defonce games (atom {}))

(defn view [game]
  (layout
    [:div (view-name (:name game))
     [:pre {} @games]]
    ))

(defn create-game [name]
  {:name name
   :players []})

(defn handler [request]
  (let [name (->> (:uri request)
                       url-decode
                       (remove #{\/})
                       (apply str))
        game (get @games name (create-game name))]
    (swap! games assoc name game)
    {:status 200
     :headers {"Content-Type" "text/html"}
     :body (html (spyfall.game/view game))}))

Thank you for your help! 🙂

@US3HM05U5 If you have multiple concurrent requests to the same "game" URI you will have a race condition there because you're fetching the game's current value and then swapping it back into the atom as two separate operations.

Depending on exactly how/where you are also updating that atom, you may lose changes (because both concurrent get's could get the old version of the game, make changes, and then whichever assoc happens last will "win").

Ah, ok! I’m not sure how that can be mitigated. I guess the only way to make sure is to queue up the mutations so that they happen one at a time?

And I guess that’s something that databases are good at? 😛

I just want this ad hoc “database” atom for my program. Implementing something my co-worker did in Elixir to see how the implementations differ. 🙂

swap! is fine, if you operate on the current value rather than trying to fetch a value first and then bashing it back in.

Consider swap! with update instead of assoc and take a look at fnil as a way to provide a "default" for a nil value.

Right, I’ll take a look! Thank you! 🙂

ring uses middleware to add features to the http stack, using those middleware allows using json automatically, but seeing the data as clojure data in your code (in your params or response)

wrap-json-body takes a request handler function, and returns a new one which will transform output data into json

Answering my own question... it seems, since bidi is data based and compatible with Ring, I need to wrap my handlers one by one before passing them to bidi's make-handler fn