It seems there is no request. Vim can dump the traffic. But there is nothing in the log. A try read also didn't get anything "stuck".
Ok, over the weekend Iโve worked on simplifying blob generation. The resulting blob is easier to read (for a human) and I guess the generator is easier to understand too.
The load
logic: https://github.com/clojure/clojure/blob/3d9b356306db77946bdf4809baeb660f94cec846/src/jvm/clojure/lang/RT.java#L429
summary:
1/ find resources for the class and a source file (clj or else cljc)
2/ if .class
is strictly more recent (or not found) then try to load it as a class [Comment #1]
3/ if sucess done
4/ if there was a source file, load it
[Comment #1] great it means that classes go over the network twice, once for the timestamp (that we donโt provide and time is relative) once for actual loading [AOT sucks]
It may explain why @gcast find loading libs through the network super slow (iirc you wree loading from an AOT compiled uberjar, no?)
If anyone is looking for a project: mix https://github.com/djpowell/liverepl and unrepl
that looks fun
indeed
@dominicm The code is now online. But it doesn't work, yet. Only manually sending stuff. And appending (part of) the response to the current buffer.
side loading works, though. ๐
Very cool
EDN is a bit of a pain, though. In particalur the actions being actual clojure code.
Vim (and a lot of other languages, I fancy) doesn't have lists and vectors. Similar for symbols. So I had to introduce quite a bit of magic tagging to make these identifyable.
For normal data it might not be that of a big deal. You loose a bit. But for code things are not that easy. You mustn't loose info.
However, It should work now. Albeit inefficient and probably half-broken.
I know this slippery slope, we went down it once. It ended with bencode.
I know.
I think that @pesterhazy had to do some tagging even with cljs.
Huh?
A vague memory
Anyway, the response works really well.
I'll probably need some load testing, but things are otherwise smooth.
The response?
The side loading was very easy to implement, inparticular.
The response processing, I meant.
For the loader it was just to get things set up correctly.
Then it was a breeze.
Now I'll have to retrofit the asyncronicity to all kinds of interaction.
It should work for most. Eg. for doc lookup or macro expansion, one should not find a difference.
The only thing I already know will be troublesome is the completion.
It seems the internet delivered already on the latter. Although I always read "python". shiver
???
Asyncronuous completion.
There seem to be some dark voodoo incantations to make it happen. So, off we go, Lord Samedi.
@kotarak probably worth looking at hooking deocomplete and nvim completion manager
"python" is for me a no-go.
If there is a way without, we'll see.