Fork me on GitHub
#babashka
<
2020-04-09
>
borkdude12:04:00

Informal presentation about babashka and implementing an nREPL server: https://youtu.be/0YmZYnwyHHc

ales.najmann14:04:57

briliant πŸ™‚

sogaiu12:04:36

discussion concerning specifcs of the nrepl bits seems to start at around 13:00

skuro14:04:40

Good point, I updated the video title / description to add the extra chapter

nate15:04:43

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.

borkdude15:04:03

* Almost all of Clojure * No Protocols * No eval It does have eval btw πŸ™‚

nate15:04:44

Oh drat. It does.

borkdude15:04:53

Nice presentation btw! πŸ™‚ Thanks for doing this.

borkdude15:04:35

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.

nate15:04:17

You are quite welcome. It was a lot of fun and there was a lot of good discussion.

nate15:04:40

Thanks again for working so hard on babashka and sharing it with the rest of us.

nate15:04:30

I bet babashka existing has reduced the number of google searches for bash and jq.

nate15:04:40

It's definitely had that effect on me.

jkrasnay15:04:42

Has anyone tried the babashka nrepl server with vim-fireplace? I can connect with :FireplaceConnect but trying to eval just coughs up some errors 😦

borkdude15:04:06

@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).

borkdude15:04:28

It does work with vim-iced btw. Also you can use the socket repl instead for now.

jkrasnay15:04:39

Hrm, looks like the request never even makes it to babashka. Must be something on the fireplace side.

borkdude15:04:23

Are you connecting to the right port?

jkrasnay15:04:19

I get some bb output when fireplace connects, but not when it tries to eval, so the port must be right.

borkdude15:04:48

and bb doesn't print the eval request?

jkrasnay15:04:52

No, no bb output on eval. I’m thinking the error happens in fireplace before it can send.

borkdude15:04:15

Maybe the error happens because of the response on the message before it

borkdude15:04:13

@jkrasnay If you run babashka from source, you can start the nREPL server like:

BABASHKA_DEV=true clojure -A:main --nrepl-server
and uncomment this line here:
(defn send [^OutputStream os msg]
  ;;(when @dev? (prn "Sending" msg))
  (write-bencode os msg)
  (.flush os))
so you can also see what it sends

jkrasnay15:04:06

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.

mauricio.szabo01:04:17

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.

borkdude06:04:43

Is that something that should be fixed on bb's end?

mauricio.szabo14:04:03

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"

mauricio.szabo14:04:27

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)

mauricio.szabo14:04:17

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"

mauricio.szabo14:04:35

It needs to concatenate 5 messages to be able to capture the same content before...

mauricio.szabo15:04:50

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 πŸ™‚

borkdude15:04:18

I honestly don't know what I'm doing differently than normal Clojure. I'm even calling .flush on the outputstream after sending.

borkdude15:04:34

But in general you should be reading until status done for the id you expect back

borkdude15:04:49

(I think... cc @ )

mauricio.szabo16:04:09

Is it possible that .flush flushes slower than normal Java while running on native-image?

borkdude16:04:38

you can try running the bb nREPL server with the JVM to find out

borkdude16:04:52

BABASHKA_DEV=true clojure -A:main --nrepl-server

jkrasnay12:04:05

Tried with bb binary v0.0.82 and also with the latest source. No success with either. I still suspect the problem is with Fireplace or something else in my Vim config.