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.

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