@raymcdermott I've tried a limited version of your code and this seems to work (when tested with nc on command line):

(defn configured-prepl
  []
  (clj-server/io-prepl :valf identity))

(defn shared-prepl
  [opts]
  (let [socket-opts {:port          5555
                     :server-daemon false                   ; Keep the app running
                     :accept        `configured-prepl}]
    (let [server (clj-server/start-server (merge socket-opts opts))]
      (println "listening on port" (.getLocalPort ^ServerSocket server)))))

(clj-server/remote-prepl "localhost" 5555)

nc localhost 5555
(+ 1 1)
{:tag :ret, :val 2, :ns "user", :ms 0, :form "(+ 1 1)"}
(defn foo 1)
{:tag :ret, :val {:cause "Call to clojure.core/defn did not conform to spec:\nIn: [1] val: 1 fails spec: :clojure.core.specs.alpha/arg-list at: [:args :bs :arity-1 :args] predicate: vector?\nIn: [1] val: 1 fails spec: :clojure.core.specs.alpha/args+body at: [:args :bs :arity-n :bodies] predicate: (cat :args :clojure.core.specs.alpha/arg-list :body (alt :prepost+body (cat :prepost map? :body (+ any?)) :body (* any?)))\n", :via [{:type clojure.lang.Compiler$CompilerException, ...

(pr-str (Object.))
#object[java.lang.Object 0x66a64b49 "java.lang.Object@66a64b49"]

(read-string (pr-str (Object.)))
RuntimeException No reader function for tag object  clojure.lang.LispReader$CtorReader.readTagged (LispReader.java:1430)

{:tag :ret, :val {:cause "Call to clojure.core/defn did not conform to spec:\nIn: [1] val: 1 
fails spec: :clojure.core.specs.alpha/arg-list at: [:args :bs :arity-1 :args] predicate: vector?\nIn: [1] 
val: 1 fails spec: :clojure.core.specs.alpha/args+body at: [:args :bs :arity-n :bodies] 
predicate: (cat :args :clojure.core.specs.alpha/arg-list :body (alt :prepost+body
 (cat :prepost map? :body (+ any?)) :body (* any?)))\n", :via [{:type clojure.lang.Compiler$CompilerException, 
:message "clojure.lang.ExceptionInfo: Call to clojure.core/defn did not conform to spec:\nIn: [1] 
val: 1 fails spec: :clojure.core.specs.alpha/arg-list at: [:args :bs :arity-1 :args] predicate: vector?\nIn: [1] 
val: 1 fails spec: :clojure.core.specs.alpha/args+body at: [:args :bs :arity-n :bodies] predicate: (cat :args :clojure.core.specs.alpha/arg-list 
:body (alt :prepost+body (cat :prepost map? :body (+ any?)) :body (* any?)))\n #:clojure.spec.alpha{:problems
 ({:path [:args :bs :arity-1 :args], :pred clojure.core/vector?, :val 1, :via [:clojure.core.specs.alpha/defn-args :clojure.core.specs.alpha/args+body
 :clojure.core.specs.alpha/arg-list :clojure.core.specs.alpha/arg-list], :in [1]}
 {:path [:args :bs :arity-n :bodies], :pred (clojure.spec.alpha/cat :args :clojure.core.specs.alpha/arg-list 
:body (clojure.spec.alpha/alt :prepost+body (clojure.spec.alpha/cat :prepost clojure.core/map? 
:body (clojure.spec.alpha/+ clojure.core/any?)) :body (clojure.spec.alpha/* clojure.core/any?))), :val 1,
 :via [:clojure.core.specs.alpha/defn-args :clojure.core.specs.alpha/args+body :clojure.core.specs.alpha/args+body], :in [1]}), 
:spec #object[clojure.spec.alpha$regex_spec_impl$reify__2436 0x233319e7 \"clojure.spec.alpha$regex_spec_impl$reify__2436@233319e7\"]
,,,

yeah, he mentioned the valf option

thanks for testing it out @jumar

in theory with valf set to identity we should get a :data property and we can then read that directly

so I’m going to play with a remote-prepl as you suggest

tbh I’m struggling on what to give it as a Reader and an out-fn …. so I’m in :thinking_face: mode at the moment

if you have any ideas … I am in the market 🙂

This is interesting and probably ultimately needs a change in spec reporting. Rather than send the spec instance, it should be sending the spec name or form where you are seeing the object. For now, I think you’ll need to intercept either on the server or client side and either remove or transform it yourself

I think hooking the default data reader to fall back to using tagged-literal is a pretty good dodge that covers many potential issues like this

How would I alias a namespace that isn't required? Circular dependency is a problem if I require it

I want to keep a separate namespace/file for my spec but use another namespace

Like my-namespace with functions and my-namespace.spec with the spec

But using :t/id instead of having to write :my-namespace/id

So do you mean like. Inside of my-namespace you have some spec like (s/def :t/id) instead of (s/def ::id) or (s/def :my-namespace/id)

As far as i understood you have to require the namespace the spec is in, to use it in a different namespace. But i could be wrong

So you might want to just move your spec somewhere else to get around the circular dependencies? I ended up just giving certain specs fake namespaces to and not using ::id. Instead something like :user/id

in my-namespace.spec I have a (s/def ::id nat-int?) . Resulting in :my-namespace.spec/id

I would like the spec to remain in my-namespace.spec but be registered to :my-namespace/id

try this instead (s/def :my-namespace/id nat-int?)

That will work, but it feels wrong when I have a lot of defs

You will still need to require my-namespace.spec in a different ns if you want to use the spec contained

yeah

but then you can refer to it like :my-namespace/id instead

I think my counter argument to "but it feels wrong when I have a lot of defs" would be its a bit redundant to have .spec in the spec name

:my-namespace.spec/id vs :my-namespace/id

like you know they are both specs

so is .spec really needed?

(this is just my opinion though, so someone else feel free to correct me etc)

Only reason for the .spec is that I want to have a separate namespace for the specs vs the functions

Yeah i had user and user.spec too, because it felt nicer to separate them

yeah exactly the same thought process

But i ended up moving away from :: notation to something/id instead

A bit worried about keyword collisions when doing it that way, but everything you say makes sense

I think thats more a case of you having a consistent naming convention really

>keyword collisions

i mean

I would have prefered to do something like (alias 't 'my-namespace)

The troubles i was having were similarly named fields

user/name vs something else /name

so if u had a (s/def ::name) that was a string and one that was something else

it would cause headaches

if that makes sense?

Yeah, but I might be using a third party library that also implement :user/name or something

But that is a problem for future me 🙂 Thanks a lot for the help

sure but then you can prefix to to Andreas.user/name or Projectname.user/name etc :thumbsup:

nps! Good luck!

Hopefully i was helpful haha

Afternoon. I was wondering if anyone else uses sets with their (s/keys...) calls?

In the docs it mentions vectors, but wouldn't a set of keys make more sense, like: (s/keys :req-un #{::a ::b})?

conceptually, yes

I ask because I've seen a weird issue where UUIDs are not being coerced by spec-tools if I use a set 😅

You can reproduce it with

(s/def ::a (st/spec uuid?))
(s/def ::b (s/keys :req-un #{::a}))
(st/decode ::b {:a "4c6e852b-e8a3-4686-8916-4e345be53731"} st/json-transformer)
;; => {:a "4c6e852b-e8a3-4686-8916-4e345be53731"}

If you replace the set with a vector it works fine and coerces the UUID string into an actual UUID. I was thinking "maybe this is an issue with spec-tools", but if you're supposed to use a vector anyway this is technically okay, just a confusing gotcha.

Seems like https://dev.clojure.org/jira/browse/CLJ-2123 is related to my question about aliases