Fork me on GitHub
#conjure
<
2020-05-12
>
Olical10:05:33

@nate Fun things wrt line joining! My test still passes, this code works:

(do
  (print (apply str (take 500 (repeat \x))))
  (println (apply str (take 300 (repeat \y)))))
But this one doesn't!
(do
  (print (apply str (take 500 (repeat \x))))
  (println (apply str (take 300 (repeat \x)))))

Olical10:05:29

Not sure if you have another repro that involves mixed characters? As far as I can tell the line joining only breaks if it's a loooooong string of the same character (for some reason).

Olical10:05:35

Oh no! It's a race condition! It's not to do with the same letters!

Olical11:05:02

Trying to chase it down now. I think there's some suuuuuper subtle and rare race condition around nREPL messages and things being entered into the log.

Olical11:05:41

I think fixing the root cause of this will actually make it even faster for rapid output. I'm basically batching things and removing as many scheduled callbacks as I can.

Olical11:05:49

Batching up into chunks of message processing.

nate11:05:01

For me, it happens more reliably at 1024 character boundaries.

Olical11:05:21

Fixed it all. I'm a big dumb dumb. I had a get-in where I wanted a get.

Olical11:05:52

Also I fixed a bunch of stuff and improved batched nREPL handling, but that wasn't the problem. So I've fixed the problem and accidentally made the architecture of message handling better.

Olical12:05:39

I refactored that function and broke it, I really need to add some tests for this. But it requires a fully nREPL server running in CircleCI and I don't want to tackle that right now/

Olical12:05:57

Pushed to develop!

nate12:05:11

Awesome. I'll try it out today.

nate12:05:30

Thank you for tackling this. I really appreciate it.

Olical12:05:14

Not a problem! I broke it while trying to improve things which sucks, I should've noticed. I need to get full nREPL + CIDER + Clojure integration tests running in CI to catch these things.

nate12:05:59

It's totally ok. This is part of the deal when working on and using brand new software. I've benefitted enormously from the new conjure, hitting a few small snags along the way is a small price to pay for that.

🎉 4
nate12:05:18

Please don't put too much pressure on yourself. It'll get there. In the meantime, I'm happy to be an analog CI. 🙂

nate15:05:05

@olical this looks to be fixed

🎉 4
Olical12:05:09

What do people think of an option (off by default) to auto require the buffer you switch to :thinking_face: I think it's dangerous to have on by default, but for some users and projects it might be really useful. Could address that issue I just closed too.

martinklepsch12:05:08

This is something I’ve actually been wondering about. Or something related to this anyways. Currently I always evaluate the buffer when switching buffers before I can run any of the code inside that buffer. Is that intentional or might that be a shadow/cljs-repl issue?

Olical13:05:40

Hmm, so I think that's because I do an in-ns to swap you to the namespace name defined in your buffer. In CLJS, if that ns doesn't exist it causes REALLY weird behaviour, so you have to at least have it required or defined in some way.

Olical13:05:06

Auto require on file open could be really useful (not sure about buf enter, maybe file load) for getting around this.

Olical13:05:24

I just wouldn't want to turn it on by default just in case it caused side effects, but maybe that's really not that much of an issue.

Olical13:05:13

The issue about not being able to eval things until you eval the buffer after switching to it should only happen the first time, right? Not every time you change buffer? If so, that's a big issue.

Olical13:05:31

The first time you open a buffer I think you need to do it if the namespace isn't loaded yet.

dharrigan14:05:09

auto-require would slow things down a bit, if opening the file, if there are lots of other namespaces being required?

Olical14:05:31

It's async, so shouldn't block anything

Olical14:05:00

The only time this would be bad is if you wanted to browse a bunch of slow to require files but never evaluate them. In which case, you probably want auto-require turned off. But that smells like a BIG edge case to me.

martinklepsch20:05:35

What I’m seeing is that even after evaluating/requiring a buffer once I have to “switch into it” manually. As in it seems the in-ns call isn’t actually happening. But I think I know how to enable debug nrepl logging so I guess I can just see for myself 🙂

martinklepsch20:05:30

Yeah, so when I switch buffers and have ConjureConfig clojure.nrepl/debug? true I am not seeing any in-ns stuff being evaluated in the log buffer. Should I?

Olical21:05:21

Yep, you should definitely be seeing it :thinking_face: are you on shadow-cljs?

Olical21:05:34

(I see it locally, but will investigate if so)

martinklepsch21:05:41

I’m on shadow cljs, I’m not using ShadowSelect though but I’ll try with that too

martinklepsch21:05:43

Not seeing output with ShadowSelect sessions either.

martinklepsch21:05:22

I’m gonna make sure cider is up to date 🙂

martinklepsch21:05:34

Upgrade to cider-nrepl 0.24.0, still no logs in the in-ns direction

martinklepsch09:05:28

Ah so I was testing if switching buffers would trigger in-ns but it seems to be done before evaluations. Anyhow I did another :PlugUpdate and looking at the debug output it looks like it’s working now. I’ll report back if this crops up again! Thanks for your help!

Olical11:05:36

Ah, yes, sorry! in-ns is only fired before doc and eval!

👍 4
martinklepsch14:05:49

Hm. I’m seeing this again. :thinking_face: I think the path to reproduce might be: 1. Evaluate buffer of namespace A 2. Switch to buffer with namespace B 3. Evaluate form in namespace B that uses a function defined in namespace B What I’m seeing is that the evaluation fails at first but succeeds on subsequent runs.

martinklepsch14:05:21

Yeah it looks like a second evaluation fixes it pretty consistently. Maybe the difference in what I’m doing is that I’m mostly evaluating full buffers? Curious if that is the suggested workflow? Do you save the buffer and require/reload?

martinklepsch09:05:54

Hey Oliver 🙂 I was wondering if the behavior above seems completely impossible from your understanding or if I might be doing something wrong here.

Olical09:05:19

Hey, sorry, this slipped the net, thanks for the reminder.

Olical09:05:41

Hmm, I don't think I've seen this behaviour so I'll try to reproduce myself with a few buffers and shadow cljs.

Olical09:05:59

It SHOULDN'T happen, but that doesn't mean it isn't.

martinklepsch09:05:20

No problem at all, thanks a lot for taking a look 🙂

Olical09:05:48

Like I'm not doing anything too special with the evals deliberately so things like this don't happen. There's now an initial require on bufenter (fine if it fails) and an in-ns before each call.

Olical09:05:00

But that's it :thinking_face:

martinklepsch09:05:03

FWIW I am starting the repl via shadow/node-repl and am not connecting to a specific build. Probably this should make a difference but I figured I’ll mention it just to be safe

Olical09:05:43

Hmm, yeah, I wouldn't expect much or a difference but I'll give that a look.

Olical10:05:44

I can switch between buffers and eval things first time after loading the buffer or file :thinking_face: none of this "fails on the first eval" in sight. Would you be able to give :ConjureShadowSelect [appname] a go? Just in case?

Olical10:05:08

The node-repl function doesn't work at all for me, I get all sorts of errors.

Olical10:05:25

It can't find .shadow-cljs/builds/node-repl/dev/out/cljs-runtime/clojure.walk.js 😬

martinklepsch10:05:04

Interesting, I’ve been using that very happily ever since I started using Conjure 😄

Olical10:05:07

Oh! What command are you running in the cli for the server? Maybe I need some specific shadow config

martinklepsch11:05:03

(shadow-server/start!)
  (shadow/watch :functions)
I’m just doing something like the above and then (shadow/node-repl {:config-merge [{:compiler-options {:reader-features #{:node}}}]})

martinklepsch11:05:20

I’m seeing the same behavior when connecting to a build using ShadowSelect btw.

martinklepsch11:05:28

Both REPLs are node repls

martinklepsch11:05:06

Maybe I should try creating a minimal repro

martinklepsch11:05:54

But it just seems so odd that the in-ns just isn’t sent

martinklepsch11:05:56

Wait hold on, now it does seem to work. I’m confused 😄

martinklepsch11:05:46

Eval at mark is such an amazing feature btw, super hyped about it!

🎉 4
Olical08:05:11

YAY! I'm glad to hear that! So does it kind of look okay now? It's kinda weird, I can't see any reason why in-ns wouldn't be sent. The form that sends it is directly before the one that sends your code with no conditional wrapping. So it's not like there's a logic bug somewhere preventing it from triggering.

martinklepsch10:05:29

I’m equally baffled. I’ll just keep an eye out for it. For now it seems to work 🙌

Olical10:05:35

Accidental success! Currently wrestling with some updates to Aniseed but I was going to try out your method of shadow-cljs clj-repl (I think?) and then drop into a REPL via eval in a buffer.

Olical10:05:40

Just in case I can spot a difference.

Olical10:05:10

The other shadow issue I'm baffled by is this one https://github.com/Olical/conjure/issues/89 Hopefully I can settle all of this and get shadow support perfectly stable!

Olical10:05:17

Yep, still can't launch a node-repl inside shadow-cljs clj-repl like you

Olical10:05:19

¯\(ツ)

martinklepsch15:05:10

does it work if you run shadow-cljs clj-repl and then (shadow.cljs.devtools.api/node-repl) in the resulting REPL?

Olical10:05:38

Nope, same error!

martinklepsch11:05:44

Weird. I think that should be working… Do you have a shadow-cljs.edn?

Olical11:05:16

Yep, it all works fine if I start it up with watch and then do a select from inside the REPL.

Olical11:05:50

I tried deleting my .shadow-cljs dir just in case some file was missing and wasn't being regenerated but nope. Maybe a fresh project will do it, I might have some cache laying around somewhere.

Olical11:05:27

I suppose by doing it your way you can have a single JVM you startup and boot everything from within.

Olical11:05:38

Hah, deleted node_modules and now it works. Damn npm strikes again

Olical11:05:48

If I had a penny for every time rm -rf node_modules fixed my problem...

Olical11:05:06

Oh no, it just displayed more of a prompt and then threw the same error.

Olical11:05:28

code: 'ENOENT',
  path: '/home/oliver/repos/olical/conjure/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/clojure.walk.js'
}

martinklepsch12:05:58

Very odd. Let me try in a fresh project

Olical12:05:00

I also managed to see your issue where the in-ns hadn't applied! I have a horrible feeling I am sending it but it's a race condition on the receiving end, so the in-ns might happen after the code?

Olical12:05:05

Digging into it now.

Olical12:05:34

I'm refactoring how and when namespaces are switched + passive requires of buffers. Just trying to make it all a lot more robust.

Olical12:05:39

Might fix it by accident.

martinklepsch12:05:44

“fixed by accident” is the best fix

martinklepsch12:05:07

I created a fresh project and cannot reproduce your failing case: 1. new dir 2. npm install shadow-cljs 3. npx shadow-cljs init 4. shadow-cljs server start 5. open CLJS file buffer 6. :ConjureEval (shadow/node-repl) 7. evaluations in the CLJS buffer work

Olical12:05:12

Going to pop to the shops and then I think I'll release this current version 👀

Olical12:05:22

As long as the school seems to work for people, that is.

Olical12:05:21

Especially the trial script https://github.com/Olical/conjure/tree/develop#try-before-you-buy (just comment out conjure and fennel.vim from your plugin manager and see if the school still works via that script basically)

Olical14:05:33

I've added auto-require 😬 I hope it works okay! It can be turned off with ConjureConfig clojure.nrepl/eval.auto-require? false

Olical14:05:50

It'll require the namespace you're editing after you connect or open a buffer while connected.

Olical14:05:09

This should mean even if your file isn't loaded by default, it'll be loaded as you go to edit it.

Olical14:05:28

Let me know what you think! 😄 I want to cut a release but I keep adding and fixing things 😬

Olical14:05:48

Run :helpg auto-require? to read a little more on it.

Olical14:05:26

(@martinklepsch might interest you, although I don't require after piggieback or shadow select right now)

dharrigan14:05:20

What do people do about comment blocks

dharrigan14:05:45

for example, in my main.clj file, I have a comment block that starts things off (i.e., by loading in the right edn file into clip, then invoking start)

dharrigan14:05:54

do people mark that then eval?

Olical14:05:37

I would personally either EasyMotion to whatever form I want or mark and eval, yup. Even if it's a few forms within the comment. If you want them run in a block you can always comment a do.

nate15:05:12

I have many kinds of comment blocks, I usually put ones right underneath the function I'm writing if it's small. If it's more involved or I want to keep them, I throw them in a separate file. I usually only do the eval at mark on the former as evaling across files requires capital letters and that's an extra chord.

nate15:05:47

oddly enough, the one thing I've never put into comment blocks is my start/stop/reset component repl stuff, I still run that in the terminal repl

nate15:05:33

since conjure does a good job of printing output, I'm going to try running them from inside my editor and see how that goes

dharrigan15:05:31

I'm sorta the same. My juxt clip start/stop I put into my repl and eval it

dharrigan15:05:50

other things, I do a mix of eval on the spot, or inside the repl (in another terminal)

dharrigan15:05:33

Maybe it might be nice for conjure to eval inside a comment block...but I think Oliver is going to ponder on that one 😉

👍 4
nate15:05:02

another nuance for me is that I hardly ever use actual (comment ...) blocks. I use #_(...) instead, so my ,er will properly find the root form

Olical16:05:56

ooo, didn't think of this tbh, I like

nate16:05:38

one cool thing would be if conjure's ,er ignored the top level (comment ...) form, so it would be useful in that context too

Olical17:05:05

As long as someone didn't do ,er on a comment that did bad things or did lots of things 😬 I tend to have multiple things inside a comment form that I can eval. This is basically implicitly turning a comment form into a do form :thinking_face: I kinda like the idea but the accidental silliness that could occur worries me.

nate17:05:13

ah, I mean just evaluate the top of the form that the cursor is in, not all the things in the comment block

nate17:05:16

(comment
  (do-big-thing1)
  (do-big-%thing2)
  (do-big-thing3)
)

Olical17:05:24

Hmm I could think of times where you do want it to evaluate everything inside though. This is why I haven't committed to a solution to this

nate17:05:32

if cursor was at %, then ,er would just run (do-big-thing2)

nate17:05:56

I see what you mean

nate17:05:22

interesting idea for "evaluate all in this comment block"

Olical17:05:25

In your specific example, ,ee is the way to go there

nate17:05:01

ah, yes, you're right

Olical17:05:08

I don't really want existing mappings to change behaviour depending on the context like that. I think it'd be tricky to implement and confusing

nate17:05:26

my forms are usually a bit more nested and take too much navigation to hop to the top of the form I want to evaluate

Olical17:05:35

Yeah, I've thought about this a lot and haven't found anything I really like yet 😅

Olical17:05:47

I know what you mean though, yeah

Olical17:05:04

It's "one form from root"

nate17:05:21

second-to-top

nate17:05:30

we could call it the vice-form

😂 4
Olical17:05:44

Providing number prefixes to eval current and root form to offset them would be good and generic. Usable in any language.

👍 4
Olical17:05:02

But not sure if it's possible, so need to experiment

nate17:05:06

oh, very interesting idea

nate17:05:21

,et1 ,et2, etc...

Olical17:05:40

Ah was thinking 2,er if possible

nate17:05:54

oh, even more vimmy

Olical17:05:04

Or 2,ee to go 2 out, where without the number would be like 1,ee

nate17:05:04

as it is right now, I'm just fine with #_, in fact I rather like it

nate17:05:12

no rush on any new feature 😉

Olical17:05:32

It's a fun idea though, still mulling it over. Last time I thought about this I settled on number prefixes

Olical17:05:36

But not sure if it's possible

dharrigan15:05:04

that's interesting

dharrigan15:05:16

I must try that

nate15:05:27

the bestest part about ,er is that my cursor doesn't move

nate15:05:32

@olical does the auto require only require when you first open a file or every time you enter it?

nate15:05:56

this seems to be a useful feature, almost none of my namespaces have side effects just by loading them

nate15:05:26

the only thought is maybe this would be an issue when editing babashka scripts, which might not have a main

Olical16:05:21

On bufenter, which is the first time I think?

martinklepsch20:05:59

> this seems to be a useful feature, almost none of my namespaces have side effects just by loading them On the other hand it does seem kinda risky for the ones who do! 😄