Fork me on GitHub
#unrepl
<
2018-02-25
>
kotarak07:02:08

How serious is the SPEC about order of repl creation?

kotarak07:02:06

Currently it seems to expect (or recommend?) that the first connection is for user interaction.

kotarak07:02:16

And from there you create auxiliary repls.

kotarak07:02:26

As I understood the latter are more "affiliated" than "auxiliary".

kotarak07:02:42

So I would actually reverse the order of things.

kotarak07:02:23

The first connection would be actually immediately upgraded to a sideloader connection.

kotarak07:02:31

Followed by the second connection for control.

kotarak07:02:58

And then only the third connection would be the one for user interaction. (If I have that one at all....)

kotarak07:02:28

I would guess that it perfectly possible (the SPEC says "typically"), but I'd rather confirm this.

cgrand07:02:19

Sideloader-Aux-user is not a possible order.

kotarak07:02:37

Is there a specific reason why that is so?

cgrand07:02:43

Yes because to start a side loader you need (least you change the spec) to have already upgraded one connection to unrepl

kotarak07:02:57

aux-sideloader-user seems to be ok, does it not?

cgrand08:02:30

somehow I’m not getting your concern. You create one unrepl? From this you get affordances to create another one and a sideloader. You create these twos and wait for them@to be ready before continuing. Then you arbitrarily assign one of the unrepl to thes user. The other is for the tool.

cgrand07:02:43

Yes because to start a side loader you need (least you change the spec) to have already upgraded one connection to unrepl

cgrand07:02:44

Unless I overlook something aux/user are not technically different. It’s just a matter of ownership.

cgrand07:02:46

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!

cgrand08:02:30

somehow I’m not getting your concern. You create one unrepl? From this you get affordances to create another one and a sideloader. You create these twos and wait for them@to be ready before continuing. Then you arbitrarily assign one of the unrepl to thes user. The other is for the tool.

kotarak08:02:57

Yeah. That was basically my question.

kotarak08:02:12

Whether I can use the first connection for non-user concerns.

kotarak08:02:34

The sideloader also has to be created relatively early so that I can require the tooling stuff.

kotarak08:02:41

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.

cgrand08:02:53

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.

kotarak08:02:15

I did and did not find anything special.

kotarak08:02:33

It just starts the repl other than creating the classloader setup.

kotarak08:02:46

Therefore rather "affialiated" than "auxiliary".

cgrand08:02:25

Twin? Fork? Sibling?

kotarak08:02:27

sibling sounds nice.

kotarak08:02:52

It's not necessarily a twin. Because one could be tooling, one user interop.

kotarak08:02:04

Fork somehow sounds more disconnected.

kotarak08:02:17

I think sibling fits well. The same family.

kotarak08:02:31

I must be a masochist.

cgrand08:02:23

Wasn’t your dedication to vim scripting enough of a hint?

kotarak08:02:36

I just the regular reconfirmation.

kotarak08:02:40

Vim me harder!

cgrand08:02:18

The most difficult thing with vim is quitting.

kotarak08:02:58

Seems so. 😄 Haven't found my way out, yet.

kotarak09:02:47

Are there plans to define some :unrepl.tooling/doc-lookup &c. API?

cgrand09:02:28

Yes hopefully we will develop a common vocabulary for common actions.

kotarak09:02:31

🙂 "pkill vim" from another terminal. 😉

kotarak09:02:04

(No. I'm currently not going to try, whether this actually works.)

kotarak09:02:53

API question regarding generic actions.

kotarak09:02:59

(The idea of a common tooling library coming back to my mind....)

cgrand09:02:28

Yes hopefully we will develop a common vocabulary for common actions.

dominicm10:02:17

@kotarak where can I follow your work?

kotarak14:02:18

But it's not there, yet.

cgrand15:02:40

Previously each time the blob was sent it was creating new gensymmed namespaces. Now it always create the same namespaces unless they exist.

cgrand15:02:38

Namespaces are named after their content so different code -> different name. Thus there’s no risk of clash.

kotarak17:02:15

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.

cgrand21:02:40

Can you confirm?

cgrand23:02:09

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

kotarak07:02:31

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".

cgrand08:02:59

Is your blob custom ?

cgrand08:02:57

Did you try manually? May there be a buffer?

kotarak08:02:07

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.

kotarak12:02:02

Result: one must not upgrade an unrepl to a side-loader.

kotarak12:02:53

Also: it asks always twice for the file?

cgrand12:02:47

Result 2: you may start getting what I was getting at when I was talking about upgrading from unrepl

kotarak12:02:09

Also: base64.... seems to have several interpretations.

kotarak12:02:14

It asks first for the class. Then for the clj. Then again for the class and again for the clj.

cgrand12:02:28

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?

cgrand12:02:13

half clojure/hald jvm behaviour

kotarak12:02:44

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.

cgrand12:02:49

classloaders can load resource or classes

cgrand12:02:56

there are different things

cgrand12:02:58

so :resource or :class keyword is there to convey this information

kotarak12:02:41

Yes. I understood. But it asks for the classfile as resource.

cgrand12:02:07

@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?

cgrand12:02:51

was me paraphrasing clojure trying to load a ns

kotarak12:02:30

Then it could stop after two, could it not?

cgrand12:02:57

which two? why? how?

kotarak12:02:28

In the main thread there is now also the picture...

kotarak12:02:03

Well, I provided it the clj file, no?

cgrand12:02:07

How many times did you call require?

cgrand12:02:22

the logic behind load

kotarak12:02:31

In the screenshot twice. The first for calls failed because base64. The second require w/ :reload caused the second four requests.

cgrand12:02:18

I’m ok with revisiting the sideloading protocol to narrow it to have the same semantics as loading from several jars

kotarak13:02:47

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.

kotarak13:02:11

Fun fact: the EDN lib will be changeset 666. The signs are telling!

cgrand13:02:23

vimpire buffer slayer

cgrand13:02:57

gates of .el are opening

kotarak13:02:34

MUHARHARHAR

gcast23:02:19

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