This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # architecture (20)
- # aws (22)
- # babashka (41)
- # beginners (191)
- # chlorine-clover (66)
- # cider (19)
- # clj-kondo (54)
- # cljs-dev (15)
- # cljsrn (78)
- # clojars (1)
- # clojure (148)
- # clojure-android (4)
- # clojure-europe (7)
- # clojure-gamedev (15)
- # clojure-germany (6)
- # clojure-losangeles (46)
- # clojure-nl (23)
- # clojure-survey (3)
- # clojure-uk (46)
- # clojurescript (24)
- # conjure (21)
- # crux (37)
- # cursive (21)
- # data-science (11)
- # datomic (5)
- # events (2)
- # fulcro (28)
- # garden (32)
- # joker (2)
- # kaocha (6)
- # lambdaisland (4)
- # mount (2)
- # off-topic (11)
- # pathom (10)
- # pedestal (13)
- # re-frame (7)
- # shadow-cljs (15)
- # spacemacs (21)
- # specmonstah (1)
- # wasm (1)
- # windows (1)
Informal presentation about babashka and implementing an nREPL server: https://youtu.be/0YmZYnwyHHc
@nate Is your presentation published online? https://twitter.com/focusaurus/status/1248265232058683393
https://github.com/justone/bb-present is the presentation, the "slides" were just editing files in vim. It was recorded, so I hope to make the video available at some point.
Yeah, the thing with eval is that GraalVM itself cannot compile code that uses eval, because eval generates classes at runtime. But babashka does have eval, because the entire thing is an interpreter.
Has anyone tried the babashka nrepl server with vim-fireplace? I can connect with
:FireplaceConnect but trying to eval just coughs up some errors 😦
@jkrasnay If you start the server like this:
BABASHKA_DEV=true bb --nrepl-server it will print what kind of messages it receives from the client. Maybe vim-fireplace expects the server to have certain functionality that isn't there (yet).
Hrm, looks like the request never even makes it to babashka. Must be something on the fireplace side.
I get some bb output when fireplace connects, but not when it tries to eval, so the port must be right.
No, no bb output on eval. I’m thinking the error happens in fireplace before it can send.
@jkrasnay If you run babashka from source, you can start the nREPL server like:
and uncomment this line here:
BABASHKA_DEV=true clojure -A:main --nrepl-server
so you can also see what it sends
(defn send [^OutputStream os msg] ;;(when @dev? (prn "Sending" msg)) (write-bencode os msg) (.flush os))
OK, I’ll give that a try. Interestingly, when I first connect from fireplace I get an error:
Vim(let):E684: list index out of range: 1 but trying to connect again works, so maybe the connection isn’t clean.
One of the problems I had while integrating nREPL with bb is that bb sends the full nREPL operation, BUT my plug-in did only receive part of the message - it had to "wait" until it received more data to parse the result. It seems, to me, that Fireplace is having the same problem @jkrasnay.
I don't think so. It's just the nature of sockets, probably. For example, this is the message exchange between Chlorine and nREPL protocols (connect, clone the session, and detect which Clojure implementation is connected to): With Clojure:
:RECEIVED "d2:id11:new-session11:new-session36:3fc57586-4d3d-4bdb-84cd-a213425763317:session36:0a80ce17-73af-45da-8635-9cae17371d456:statusl4:doneee" :RECEIVED "d2:id6:eval462:ns4:user7:session36:3fc57586-4d3d-4bdb-84cd-a213425763315:value4::clje"
It receives two complete blocks of message via the "onData" callback (the only way to listen to messages on ClojureScript is to wait for a callback - there's no way to block the thread until it receives some kind of data)
Now, with bb:
:RECEIVED "d2:id11:new-session11:new-session36:c0e2bccb-92b6-4972-be6b-1f57500075787:session4" :RECEIVED ":none6:statusl" :RECEIVED "4:doneee" :RECEIVED "d" :RECEIVED "2:id6:eval532:ns4:user7:session36:c0e2bccb-92b6-4972-be6b-1f57500075785:value3::bbe"
It needs to concatenate 5 messages to be able to capture the same content before...
But that's just how Node.JS works, to be honest. What I did was wrongly assume that the full
clone result would always be a full message 🙂
I honestly don't know what I'm doing differently than normal Clojure. I'm even calling .flush on the outputstream after sending.
Is it possible that
.flush flushes slower than normal Java while running on native-image?