I was able to get this working again by adding the following dep to deps.edn:

http-kit/http-kit {:mvn/version "2.7.0-alpha4"}

Spoke too soon, that cleared the issue when loading a file into the repl, but the electric compile is still failing with the same above error.

we will take a look in the morning. i think we removed our dependency on npm’s shadow entirely, the error (from portal?) suggests that perhaps shadow-cljs must be listed as a normal dependency in node modules? i think this is a portal question

scan the last 20 commits on electric github and you might see we removed shadow from package.json or similar

I'll look thanks for the pointer.

I think the latest portal release is broken. https://clojurians.slack.com/archives/C0185BFLLSE/p1678861984692559?thread_ts=1678861361.210829&cid=C0185BFLLSE

(defn wrap-websocket [next-handler ws-handler]
  (fn [request]
    (if (jetty/ws-upgrade-request? request)
      (jetty/ws-upgrade-response ws-handler)
      (next-handler request))))

(defn app [{:keys [routes
                   custom-content-negotiation
                   ws-handler
                   jira-handlers]}]
  (let [content-negotiation (muuntaja-options custom-content-negotiation)]
    (->
      (ring/ring-handler
        (ring/router
          [routes
           (atlassian-connect/routes jira-handlers)])
        (constantly not-found-response))
      (middleware/wrap-format content-negotiation)
      (catch-req-middleware)
      (wrap-params)
      (wrap-resource "public")
      (wrap-content-type)
      (wrap-index-as-root)
      (wrap-websocket ws-handler))))

(defn start-server
  [{:keys [port]
    :as server-config}]
  (println (str "\nStarting server on port: " port "\n"))
  (jetty/run-jetty
    (app server-config)
    {:port port
     :join? false}))

From different ns:

(def server-config
  {:port (server/get-port "electric")
   :ws-handler (adapter/electric-ws-adapter adapter/electric-ws-message-handler)})

(defn start-server [] (server/start-server server-config))

ERROR hyperfiddle.electric-jetty-adapter: Websocket error #error {
 :cause Wrong number of args (2) passed to: hyperfiddle.electric-jetty-adapter/electric-ws-message-handler
 :via
 [{:type org.eclipse.jetty.websocket.api.exceptions.CloseException
   :message org.eclipse.jetty.websocket.core.exception.WebSocketException: WebSocketAdapter$WebSocketPingPongListener$12d400b6 OPEN method error: Wrong number of args (2) passed to: hyperfiddle.electric-jetty-adapter/electric-ws-message-handler
   :at [org.eclipse.jetty.websocket.common.JettyWebSocketFrameHandler convertCause JettyWebSocketFrameHandler.java 506]}
  {:type org.eclipse.jetty.websocket.core.exception.CloseException
   :message org.eclipse.jetty.websocket.core.exception.WebSocketException: WebSocketAdapter$WebSocketPingPongListener$12d400b6 OPEN method error: Wrong number of args (2) passed to: hyperfiddle.electric-jetty-adapter/electric-ws-message-handler
   :at [org.eclipse.jetty.websocket.core.internal.WebSocketCoreSession lambda$onOpen$5 WebSocketCoreSession.java 404]}
  {:type org.eclipse.jetty.websocket.core.exception.WebSocketException
   :message WebSocketAdapter$WebSocketPingPongListener$12d400b6 OPEN method error: Wrong number of args (2) passed to: hyperfiddle.electric-jetty-adapter/electric-ws-message-handler
   :at [org.eclipse.jetty.websocket.common.JettyWebSocketFrameHandler onOpen JettyWebSocketFrameHandler.java 187]}
  {:type clojure.lang.ArityException
   :message Wrong number of args (2) passed to: hyperfiddle.electric-jetty-adapter/electric-ws-message-handler
   :at [clojure.lang.AFn throwArity AFn.java 429]}]
 :trace
 [[clojure.lang.AFn throwArity AFn.java 429]
  [clojure.lang.AFn invoke AFn.java 36]
  [hyperfiddle.electric_jetty_adapter$electric_ws_adapter$on_connect__23415 invoke electric_jetty_adapter.clj 57]
  [ring.adapter.jetty9.websocket$proxy_ws_adapter$fn__2484 invoke websocket.clj 153]
  [ring.adapter.jetty9.websocket.proxy$org.eclipse.jetty.websocket.api.WebSocketAdapter$WebSocketPingPongListener$12d400b6 onWebSocketConnect nil -1]
  [org.eclipse.jetty.websocket.common.JettyWebSocketFrameHandler onOpen JettyWebSocketFrameHandler.java 177]
  [org.eclipse.jetty.websocket.core.internal.WebSocketCoreSession lambda$onOpen$6 WebSocketCoreSession.java 410]
  [org.eclipse.jetty.server.handler.ContextHandler handle ContextHandler.java 1463]
  [org.eclipse.jetty.server.handler.ContextHandler handle ContextHandler.java 1482]
  [org.eclipse.jetty.websocket.core.server.internal.AbstractHandshaker$1 handle AbstractHandshaker.java 212]
  [org.eclipse.jetty.websocket.core.internal.WebSocketCoreSession onOpen WebSocketCoreSession.java 410]
  [org.eclipse.jetty.websocket.core.internal.WebSocketConnection onOpen WebSocketConnection.java 542]
  [org.eclipse.jetty.io.AbstractEndPoint upgrade AbstractEndPoint.java 451]
  [org.eclipse.jetty.server.HttpConnection upgrade HttpConnection.java 419]
  [org.eclipse.jetty.server.HttpConnection onCompleted HttpConnection.java 450]
  [org.eclipse.jetty.server.HttpChannel onCompleted HttpChannel.java 968]
  [org.eclipse.jetty.server.HttpChannel handle HttpChannel.java 485]
  [org.eclipse.jetty.server.HttpConnection onFillable HttpConnection.java 282]
  [org.eclipse.jetty.io.AbstractConnection$ReadCallback succeeded AbstractConnection.java 319]
  [org.eclipse.jetty.io.FillInterest fillable FillInterest.java 100]
  [org.eclipse.jetty.io.SelectableChannelEndPoint$1 run SelectableChannelEndPoint.java 53]
  [org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy runTask AdaptiveExecutionStrategy.java 412]
  [org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy consumeTask AdaptiveExecutionStrategy.java 381]
  [org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy tryProduce AdaptiveExecutionStrategy.java 268]
  [org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy lambda$new$0 AdaptiveExecutionStrategy.java 138]
  [org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread run ReservedThreadExecutor.java 407]
  [org.eclipse.jetty.util.thread.QueuedThreadPool runJob QueuedThreadPool.java 894]
  [org.eclipse.jetty.util.thread.QueuedThreadPool$Runner run QueuedThreadPool.java 1038]
  [java.lang.Thread run Thread.java 833]]}

Can you use the Jetty 9 version that the starter app uses? (Is there a reason for upgrading to Jetty 10?)

We are reorganizing this stuff this week for the next release, we might add CI/CD for the Jetty 10 version

Nah no reason to use 10, it just looked simpler and I interpreted the comments as if thats the preferred way but you go with 9 for java 8 compatibility. I'll give it a try after dinner!

electric-ws-message-handler takes the ring request as first argument. You can try with

(defn wrap-websocket [next-handler ws-handler]
  (fn [request]
    (if (jetty/ws-upgrade-request? request)
      (jetty/ws-upgrade-response (adapter/electric-ws-adapter (partial adapter/electric-ws-message-handler request))
      (next-handler request))))

he has that

i don't like this line:

ws-handler (adapter/electric-ws-adapter adapter/electric-ws-message-handler)

I don't see a line like that in our example

and i agree it doesn't typecheck

Adding the req with partial like geoffrey suggested worked!

I honestely do think what i posted is what you have in the examples, you just dont have that exact line like that because I sent it as an arg. Anyway thanks for the fix!

it looks like an e/server got dropped in a refactor

look for places where you're calling into datascript from the client

this would also explain the tap> malfunction, if it is called from the wrong site

So I just found the serializable issue, I was accessing datascript from the client side where it should have been server side, so the issues with the log entry are fixed. Still not getting taps though, in (e/client) or (e/server) code, taps just do not show up.

If I hit tap from a comment, loaded directly to the nrepl it works, but anything in electric code is just being swallowed.

Does println work?

yeah from server and client println is working, I see it on the terminal for server and on the browser console for client

alright, if you push your repo i'll take a look

It'll be a bit later tonight can only work on this outside work hours and my lunch hour is up.

I'm not sure exactly what caused this but it just started working for me after a clean start. Been a few days since I closed the repl I guess.

hm ok

i suspect an issue on portal side

I switched to using reveal, portal does not like the new electric seutp.

It's just to see taps so whatever works is fine by me.

But the problem I was seeing with taps not showing up is gone. It was happening for the shadow web tap stream too.

Now shadow tap stream and reveal both see taps

the gists aren’t maintained, there is a repo for the painter demo linked from the readme i believe

maybe the error is a missing e/client?

I think the gist is linked from the main readme - probably how I found it

The repo is here 🙂 https://github.com/formicagreen/electric-clojure-painter

Live demo: https://painter.up.railway.app/

Cool! @U04P1F17B2N we will take a look at optimizing that (on my machine the pen lags). It should 100% be fast

Yeah I managed to fix the cursor performance using only client-side values. Tried doing the same with the “currently drawing path” but somehow it didn’t work