it doesn't look like it's exposed for reflection/direct instantiation, but the class is "included":

user=> (class (fs/path "."))
sun.nio.fs.WindowsPath

Need more context, why do you need this? If you need to deal with paths, you can use babashka.fs or cast to a public super class. sun. classes are implementation details that you should usually not refer to directly

I was trying to serialize paths to edn as a tagged thing so that I could read it back into a path. I expect to be told that it's a bad idea and I should put it in a defrecord instead or not do it at all.

(defmethod print-method sun.nio.fs.WindowsPath [c ^java.io.Writer w]
  (spit w (str "#path " (pr-str (str c)))))

print-method dispatches by the class and I don't know how to make that work with a superclass.

@UPD88PGNT

user=> (defmethod print-method java.nio.file.Path [c ^java.io.Writer w] (spit w (str "#path " (pr-str (str c)))))
#object[clojure.lang.MultiFn 0x1d24865a "clojure.lang.MultiFn@1d24865a"]
user=>  (pr-str (fs/path "."))
"#path \".\""

you could also walk the structure and do the conversion yourself

Oh. It's working now. Thanks! I don't know why it wasn't working before.

There is currently no way to evaluate middleware in user space

Of course we could figure out a way to accomplish this!

E.g. by adding the middleware as a bb.edn dependency and then evaluating it. There is a programmatic way of starting the nrepl server already in: babashka.nrepl.server/start-server! where users could maybe pass the middleware or so

I'm still in the process of understanding. babashka.nrepl.server/start-server! can be passed an :xform , where I pass middleware, correct? And my middleware I can hypothetically load in user space? I checked and I can load almost all of cider.nrepl (middleware) with bb

yes, you can pass an xform, but I'm not sure if this works in user space. you can view the babashka nrepl tests how this works, it's transducer-based

https://github.com/babashka/babashka.nrepl/blob/master/doc/middleware.md

I see. Yea I need to bend my mind into juggleling the 2 phases of graalvm program and user space. So those examples I make work by either running a clojure program (already did) or compiling them with graalvm (basically a bb version with middleware?)

You need to make a change in babashka to enable user-space middleware

you can run bb using the jvm for development

👍

I do this using clj -M:babashka/dev :

:babashka/dev {:paths []
                          :deps {babashka/babashka {:local/root "/Users/borkdude/dev/babashka"}}
                          :main-opts ["-m" "babashka.main"]
                          }

The middleware xform implementation isn't something that I came up with myself but was designed by @U7RJTCH6J - perhaps he has ideas how to enable middleware from the JVM nrepl ecosystem

it would be sweet if we could just re-use the cider inspector middleware for example

yea with as little wrapper as possible I suppose.

I suspect there will be a way to transform a JVM nREPL middleware function to a bb-middleware compatible thing, at least, I hope

else we could maybe implement another stack of JVM middleware on top of the xform stuff

maybe it would be good to start with the simplest / dumbest middleware example and try to make that work

yea first a user defined middleware that logs all requests to file for example. The cider inspect

yeah or even a middleware which logs all requests using timbre, the debugging middleware :)

I think the exposed nrepl server function should just take the (fn [handler msg]) kind of middleware and not expose this :xform stuff to users since it's more or less for people who want to implement a babashka-like thing, but bb users are likely not familiar with that

maybe the babashka.nrepl library should also support passing those, as an alternative to :xform

👍

As long as babashka.nrepl.server/start-server! is available from within the sci context, I think passing the xform based middleware should work.

> it would be sweet if we could just re-use the cider inspector middleware for example When I looked into this previously. It didn't seem like it was possible to reuse existing cider middleware without pulling a bunch of dependencies. If you're pulling in a bunch of dependencies, then why not just use cider's nrepl implementation?

> I think the exposed nrepl server function should just take the (fn [handler msg]) kind of middleware and not expose this :xform stuff The xform and the handler forms are mostly just rearrangements of the same stuff:

(def my-handler-middleware
  (fn [handler msg]
    (handler response)))

(defn my-xform-middleware
  (fn [rf]
    (fn [result msg]
      (rf result response))))

> If you're pulling in a bunch of dependencies, then why not just use cider's nrepl implementation? Because those would not be babashka's own dependencies, but dependencies in bb.edn in user space

So to convert a handler to an xform-middleware you can do:

(defn handler->xform-middleware [handler]
  (fn [rf]
    (fn [result msg]
      (rf result (handler identity msg))))

I was looking back at the old issue, https://github.com/babashka/babashka.nrepl/issues/11#issuecomment-879300306. I think you can convert it with:

(defn middleware->transducer
  ([middleware]
   (fn [rf]
     (fn
       ([] (rf))
       ([result] (rf result))
       ([result input]
        ((middleware #(rf result %)) input))))))

right!

@U02CV2P4J6S Is that enough for you to work with? I think any custom middleware should go through that function and then be "appended" to the default xform middlewares

I try tomorrow. I suspect its enough to work with 😛

:)

@U04V15CAJ for loading the middleware. Maybe we pass a list of symbols with --middleware , then in babashka.main.clj we resolve those with the sci context right? Maybe then we produce a middleware handler that in turn uses sci/eval ?

Something like this yes