Clojurians Log v2
unrepl
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".
Is your blob custom ?
Did you try manually? May there be a buffer?
Used your stock blob. A buffer is not entirely ruled out. Just did some quick tests. I suspect some trouble on my side. That will be a pain to debug. sigh Will check deeper later today.
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.
Result: one must not upgrade an unrepl to a side-loader.
Also: it asks always twice for the file?
twice?
Result 2: you may start getting what I was getting at when I was talking about upgrading from unrepl
Also: base64.... seems to have several interpretations.
It asks first for the class. Then for the clj. Then again for the class and again for the clj.
not quite: 1/ do you have the class file? 2/ maybe the clj file? 3/ let’s be more general: the cljc file? 4/ just out of curiosity you wouldn’t have the class bytes in memory?
half clojure/hald jvm behaviour
No class. Clj only. No cljc. And it asks weirdly for the first time for the class as :resource not :class. Tried to post a picture.
classloaders can load resource or classes
there are different things
so :resource or :class keyword is there to convey this information
Yes. I understood. But it asks for the classfile as resource.
@kotarak it wasn’t obvious but >>> 1/ do you have the class file? 2/ maybe the clj file? 3/ let’s be more general: the cljc file? 4/ just out of curiosity you wouldn’t have the class bytes in memory?
was me paraphrasing clojure trying to load a ns
Then it could stop after two, could it not?
which two? why? how?
In the main thread there is now also the picture...
Well, I provided it the clj file, no?
How many times did you call require?
the logic behind load
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]
In the screenshot twice. The first for calls failed because base64. The second require w/ :reload caused the second four requests.
It may explain why @gcast find loading libs through the network super slow (iirc you wree loading from an AOT compiled uberjar, no?)
I’m ok with revisiting the sideloading protocol to narrow it to have the same semantics as loading from several jars
Got it working. Problem was upgrade out of unrepl. Multi requests don't hurt. Further observation: base64 doesn't work from cli tool. More observation: Everything has to be newline terminated.
Fun fact: the EDN lib will be changeset 666. The signs are telling!
vimpire buffer slayer
gates of .el are opening
MUHARHARHAR
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.