Clojurians Log v2
unrepl
How serious is the SPEC about order of repl creation?
Currently it seems to expect (or recommend?) that the first connection is for user interaction.
And from there you create auxiliary repls.
As I understood the latter are more "affiliated" than "auxiliary".
So I would actually reverse the order of things.
The first connection would be actually immediately upgraded to a sideloader connection.
Followed by the second connection for control.
And then only the third connection would be the one for user interaction. (If I have that one at all....)
I would guess that it perfectly possible (the SPEC says "typically"), but I'd rather confirm this.
Sideloader-Aux-user is not a possible order.
đ
Is there a specific reason why that is so?
aux-sideloader-user seems to be ok, does it not?
Unless I overlook something aux/user are not technically different. Itâs just a matter of ownership.
I somehow expect tools to treat aux connections as a growing pool. Need to send a command but all connections busy? Spawn a new one!
Yeah. That was basically my question.
Whether I can use the first connection for non-user concerns.
The sideloader also has to be created relatively early so that I can require the tooling stuff.
whether the first is tooling and the second is sideloader or vice versa is not really the problem. I have to set up both anyway.
I should (or better: you could, send more eyeballs to the code) double check thereâs nothing special about âstart-auxâ upgrades except they share the sideloader.
I did and did not find anything special.
It just starts the repl other than creating the classloader setup.
Therefore rather "affialiated" than "auxiliary".
Twin? Fork? Sibling?
sibling sounds nice.
It's not necessarily a twin. Because one could be tooling, one user interop.
Fork somehow sounds more disconnected.
I think sibling fits well. The same family.
I must be a masochist.
Wasnât your dedication to vim scripting enough of a hint?
I just the regular reconfirmation.
Vim me harder!
The most difficult thing with vim is quitting.
Seems so. đ Haven't found my way out, yet.
Are there plans to define some :unrepl.tooling/doc-lookup &c. API?
You might find this useful then https://itsfoss.com/how-to-exit-vim/
đ "pkill vim" from another terminal. đ
(No. I'm currently not going to try, whether this actually works.)
API question regarding generic actions.
(The idea of a common tooling library coming back to my mind....)
@kotarak where can I follow your work?
Soon here: http://bitbucket.org/kotarak/vimpire
But it's not there, yet.
Previously each time the blob was sent it was creating new gensymmed namespaces. Now it always create the same namespaces unless they exist.
Namespaces are named after their content so different code -> different name. Thus thereâs no risk of clash.
Hmmm.... It seems I cannot require through the side loader. It is not asked for the .clj file. Although it's listening after a side-loader/hello.
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.
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
In the screenshot twice. The first for calls failed because base64. The second require w/ :reload caused the second four requests.
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
Can you confirm?
works for me, eg for (require âfoo.bar)
~$ nc localhost 5555
user=> (unrepl.repl$aNSc1LtUH91sIAn6Wgp$CUFDTME/attach-sideloader! :session505)
[:unrepl.jvm.side-loader/hello]
[:resource "foo/bar__init.class"]
nil
[:resource "foo/bar.clj"]
nil
[:resource "foo/bar.cljc"]
nil
[:class "foo.bar__init"]
nil
just thought I'd give an update regarding an issue I experienced in the past where Datomic transactions, if evaluated at repl, would cause Unrepl clients to crash. It turns out that the return value of Datomic transactions contain an object which effectively points to the db and when this object is dereferenced it will completely dump the entire database on screen. My current guess is that perhaps whatever elision is being done on the transaction may somehow be dereferencing the db object and dumping out all the datoms