Fork me on GitHub
#unrepl
<
2018-01-03
>
bozhidar07:01:40

> so if we want to side load also AOT-id/Java, probably the best option would be to refactor mranderson and package it as boot library

bozhidar07:01:08

Why so? Because unrepl is using boot?

cgrand07:01:48

No, unrepl uses Leiningen

bozhidar07:01:42

I’m assuming it won’t be hard to make mranderson play well with boot.

pesterhazy09:01:02

Personally I don't think there's anything wrong with lein, especially if it's used for a specific task like shading a library

volrath11:01:52

@cgrand last night I started thinking/coding a way to interactively switch the REPL namespace to the one my current working buffer holds, i.e. my user conn REPL is in the user ns, and I'm looking at a file/buffer that's represented by foo.bar ns, I want to have an editor command to switch the user conn's ns to foo.bar, so this would have to go through the aux conn... I couldn't find an easy way to do that, any thoughts?

cgrand11:01:04

You don’t want to send (ns foo) over the userconn?

cgrand11:01:02

(where (ns foo) is the full ns form)

volrath11:01:03

I could, but I'm avoiding it since I think this is more of a tooling thing.. it'd be an interactive editor command, don't know if I want that in the user repl history

cgrand11:01:47

If you want to read the repl log, knowing when you switch ns may be useful.

cgrand12:01:16

An aux command would also have to force reprompt on user otherwise there would be no feedback in the repl buffer

pesterhazy12:01:19

(ns foo) seems the natural thing to me as well

pesterhazy12:01:09

good point about the repl transcript too

volrath12:01:45

I agree with that on premise, and I also had implemented a notification system so that the user sees when this happens... what I don't like as much is cluttering *1 *2 *3 with things that the user may not have wanted to evaluate

volrath12:01:09

and what I mean by that, is that some times the editor may want to automatically switch to a namespace, without the user explicitly telling so

pesterhazy12:01:09

you mean this?

clojure.set=> (in-ns 'user)
#unrepl/ns user
user=> *1
#unrepl/ns user

volrath12:01:32

here's the use case I have in mind

pesterhazy12:01:49

are you talking about spiral-eval-buffer?

pesterhazy12:01:09

I'm wondering now if spiral-eval-last-sexp will affect *1

volrath12:01:39

the user repl is in user, and the user is looking at a foo.bar file. When the user tries to evaluate a form in foo.bar I want the REPL to automatically switch to foo.bar (this would be customizable of course), a notification will be seen so that the user know it happened and the form will be evaluated after the ns was switched

volrath12:01:22

at this point, *1 would hold the evaluated form, but if I sent the (ns foo.bar) through the user conn, *2 will hold that as well

cgrand12:01:24

and do you revert to user after?

volrath12:01:58

I'm meaning to make it customizable.. I might not

volrath12:01:10

I might stay in foo.bar

pesterhazy12:01:52

do people actually use *2 ...? I mostly care about *1

pesterhazy12:01:49

it's kind of a tradeoff between truth and convenience

pesterhazy12:01:16

truth: we don't want to hide unnecessarily what gets sent to the repl

pesterhazy12:01:44

convenience: access to previous evaluations you actually care about

cgrand12:01:44

`(do (ns foo) (my expr))` ?

cgrand12:01:01

splicing do

cgrand12:01:07

nah won’t work is there are syntax quotes, aliases etc.

pesterhazy12:01:28

also you can't switch back like that

volrath12:01:44

tbh, switching back is not something that I love

volrath12:01:21

in nrepl what they do is pass a :ns key to their input messages

pesterhazy12:01:38

suppose I'm working in the repl buffer visiting 'user and running a test command repeatedly (foo.bar/quux)

volrath12:01:52

so the REPL buffer can be in user, but the interactive buffer evaluations happen in the buffers ns (cider)

pesterhazy12:01:55

now I change quux - but that switches my ns in the repl buffer

cgrand12:01:55

(unrepl/do (ns foo))

volrath12:01:02

I think this is a source of confusion

pesterhazy12:01:37

(unrepl/incognito (ns foo))

volrath12:01:46

@cgrand that over the aux conn? I'm not entirely sure what unrepl/do does

cgrand12:01:52

unrepl/do only works at top level and works like top-level do except the return value is never printed and it doesn’t affect *1

cgrand12:01:05

it’s already in unrepl

cgrand12:01:43

and I was on the verge of removing it 😉

volrath12:01:38

ok, let me try that then 🙂

cgrand12:01:10

unrepl/do saved by the bell?

volrath12:01:22

(if (and (seq?  r) (= (first r) 'unrepl/do))
                                       (do
                                         (flushing [*err* (tagging-writer :err id write)
                                                    *out* (scheduled-writer :out id write)]
                                                   (eval (cons 'do (next r))))
                                         request-prompt)
                                       r)
haha it took me a while to find that definition

volrath12:01:37

cool, I'll try it out, I think it will work

cgrand12:01:39

^:unrepl/shhhh could be a better syntax

pesterhazy12:01:53

unrepl/undo 🙂

volrath12:01:11

gonna go grab something to eat first, then I'll try it

cgrand12:01:17

I like the metadata because it wouldn’t introduce a special

volrath12:01:51

what would be the problem with a special form? just curious

cgrand12:01:26

(use of *1 notwithstanding) a transcript could be replayable in any repl (metadata would be ignored); unrepl/do would break

pesterhazy12:01:55

you mean ^:silently (in-ns 'foo.bar) ?

pesterhazy12:01:22

I'm not so sure — metadata usually doesn't apply to fn calls, right?

pesterhazy12:01:56

only to literals

pesterhazy12:01:10

hmmmm that's not true actually

cgrand12:01:24

you can type hint an expression

cgrand12:01:36

there’s the ^:once metadata on fn*

pesterhazy12:01:01

it's still a bit of an obscure feature

cgrand12:01:22

and it doesn’t apply to a fn call: it’s an annotation on an expression 😉

pesterhazy12:01:26

a "repl-special form" is easier to grok

pesterhazy12:01:47

yeah not sure either

volrath14:01:54

@cgrand @pesterhazy alright I tried unrepl/do and it works but there are a couple of things that seem fishy somehow: 1. unrepl/do makes unrepl return a :read message with updated line-col positions, which is not a big deal to spiral, but to clients that use those values to keep sync with the input sent, it's problematic. 2. unrepl doesn't return an :eval message, which in this case is not a big deal cause I'm not interested in the result, but that may not always be the case

volrath14:01:23

I'm not entirely sure about #2 though, it might be a problem on my side, I'll confirm in a few minutes

cgrand14:01:16

I don’t see what’s wrong with #1

volrath14:01:55

no, you are right, that's not problematic...

volrath14:01:17

#2 is happening though

volrath14:01:34

I mean, there's no :eval back from unrepl/do

cgrand14:01:05

@otfrom welcome Bruce!

cgrand14:01:39

#2 is somehow by design

volrath14:01:28

hmm I do not feel it would be too crazy to think that some client would want to do an unrepl/do expecting some result back. but I can ping back if I'm ever into that situation

volrath14:01:52

great! it's a work in progress, let me know if you try it out 🙂

volrath14:01:28
replied to a thread:#2 is somehow by design

hmm I do not feel it would be too crazy to think that some client would want to do an unrepl/do expecting some result back. but I can ping back if I'm ever into that situation

cgrand14:01:32

I have the feeling we are over thinking here

cgrand14:01:49

A couple of observations: 1/ (ns foo.bar) in lumo doesn’t affect *1 and friends

volrath14:01:41

it does in clj, but I wouldn't mind if unrepl would take the lumo approach

volrath14:01:53

in clj it basically deletes *1 *2 *3

cgrand14:01:22

not the asumption I had, let me check

cgrand14:01:06

user=> 1
1
user=> 2
2
user=> 3
3
user=> (ns foo.bar)
nil
foo.bar=> [*1 *2 *3]
[nil 3 2]

cgrand14:01:25

so is doesn’t delete, it just shifts as usual

volrath14:01:21

other.test=> 1
1
other.test=> 2
2
other.test=> 3
3
other.test=> (ns new.ns)
nil
new.ns=> *1 *2 *3
nil
nil
nil
new.ns=> 

volrath14:01:27

bah, nevermind

cgrand14:01:00

*3 *3 *3 would be better 🙂

cgrand14:01:24

side effects, we ❤️ you

volrath14:01:37

haha yes ❤️

volrath14:01:00

when you do (ns some.ns)

cgrand14:01:03

2/ what you really want atm is (ns buffer.ns) (expr-from-buffer) and we are complaining that *1 is messed up with while there’s little chance that expr-from-buffer would ref it, so (ns buffer.ns) (set! *1 *2) (set! *2 *3) (expr-from-buffer) would be safe

cgrand14:01:22

not the asumption I had, let me check

cgrand14:01:38

The fact that lumo doesn not behave like clj tells that it may be wise to consider a command since behaviour is going to vary amongst targets

dominicm14:01:44

I think ns is quite weird in cljs, so I'm not particularly surprised the behaviour is different.

volrath14:01:27

lumo does its own handling of *1 *2 *3, from what I remember

cgrand14:01:13

true because handling of *1 etc is the repl job

cgrand14:01:13

true because handling of *1 etc is the repl job

volrath14:01:42

yep, there's no such thing as clojure.main/repl in cljs

cgrand14:01:08

@volrath @pesterhazy how your clients handle a :prompt out of the blue?

volrath14:01:50

mine just prints it, I'm not taking special precaution

cgrand14:01:14

so it could print a new prompt mid editing of the user?

volrath14:01:10

the user can only type when there's a prompt

volrath14:01:48

so if for any reason a new prompt would appear without the user hitting enter, it would print the new prompt and copy/paste the user's input into the new one

volrath14:01:08

that's what's coded, but I haven't tested it cause I don't know how to reproduce that

volrath14:01:31

you know what, I lied, I do take one precaution

cgrand14:01:40

so the scenario would be 1/ send command to aux 2/ wait for matching prompt on user 3/ send expr to user

volrath14:01:05

I distinguish between interactive evals and repl evals.. if the new prompt is associated with a repl eval, I print it, if not, I ignore it

volrath14:01:15

I don't understand that scenario 😕 when I send forms through aux I don't care about the prompts, I only care about user prompts

cgrand14:01:27

the :prompt appearing on user is the conformation that the ns had effectively been changed

cgrand14:01:20

it’s too complex

cgrand14:01:55

back to unrepl/do

cgrand14:01:45

I’m ok with it emitting an :eval

cgrand14:01:47

and renaming it

volrath15:01:53

ah, I see what you mean... I mean, tbh, I wouldn't mind just adding an extra check: if the user :prompt comes out of nowhere and its namespace is different from the one before (I always keep reference of the current namespace in the client) -> print it out

volrath15:01:12

but emitting :eval also works, an maybe it's better imo

volrath15:01:23

I'm not sure

volrath15:01:51

when you say "rename it" you mean emit another type of message different from :eval?

cgrand15:01:32

the whole scenario exposed above is brittle as you have to use two conns and wait etc.

cgrand15:01:04

re: “rename it”, no rename unrepl/do

cgrand15:01:03

I’m event thinking about a :sneaky command (that would just be (unrepl/do #unrepl/param :expr))

pesterhazy17:01:51

I think an unexpected :prompt should cause the prompt to be reprinted in unravel (and the ns portion to be changed)