Hey thanks for all your work! I found something in the docs:

<localleader>rr          Refresh all changed namespaces.
<localleader>rr          Refresh all namespaces, even unchanged.

Ah, good spot!

Thanks!

Fixed

What did you evaluate out of interest?

is a file, but is a pathom project that reloads all the maps of resolvers and mutations and returns as result of the eval (don't know why they decided to this in this way)

Ah okay. Would be interesting to see if evaluating (do (slow-thing) nil) and also evaluating as normal but with pretty printing off would make a difference.

I will try both

I haven't evaluated anything that returns a big enough result yet, but I suspect something with a LOT of lines involves time pretty printing, parsing and then formatting and inserting into the log buffer.

It'll even incur more data to be parsed because of all the whitespace!

yeap pretty print false did the trick

can we disable it when the output is to big

but this lead to another question what is to big?

Interesting! But Neovim locked up entirely while you were waiting?

haha

yes

like full lock

had to kill my process

I'm not in control of the pprint flag after eval, I turn it on before eval.

It's done by nREPL itself

without the pretty print is super fast

oh

I think the problem is the efficiency of inserting so many lines to be honest. I'll have a look at what could be slow at inserting lots into the buffer.

I will go with eval.pretty-print = false, since is similar of what I had on the older conjure

I'll get some way to reproduce it myself and try to fix it rather than just turn off pprint. It shouldn't really be a problem.

maybe parse a huge internet json

into a edn

and print

dunno

Yup, something like that good idea!

Hmm, evaluated range 10000 and it was fine, didn't lock up neovim at all, so I wonder if it's the syntax highlighting etc.

So maybe if I fold large results it'll fix it :thinking_face:

can I somehow store the eval result to check how many lines?

Hmm, you could capture it with (def x (my-code)) then (count (clojure.string/split-lines (with-out-str (clojure.pprint/pprint x))))

One other thing you could try since I can't seem to reproduce and I have a hunch: Open up the log buffer, run :set ft=text and then try to reproduce the issue.

If it's suddenly fast, it proves it's Vim locking up trying to syntax highlight.

with the pretty-print true

Yup!

still hangs, but maybe I have to disable the hud

Nope that's okay, I'd expect it to be pprinted, but not highlighted?

because it stills shows up pprinted

It should just be black and white (depending on your terminal)

still hangs

Wow, well I'd love to know how big that result is when pretty printed then 😄

but is faster

with sintax highlight I locked vim forever

now It just hangs

some seconds

like 20 secs hahaha

Interesting! So it does look like there's some streaming / chunking options for nREPL evals. Maybe I'll make it cap at a save level and you can request the rest if you really need it and are okay waiting for everything to catch up. I've added it to my todo list and will try to address it asap alongside some other things around stdout display.

Turning off pprint will be the best bet for now, but yeah, I'll pick something big that's slow and try to get it evaluating efficiently. The best solution for now would be to wrap anything you know that's got a HUGE result in (do ... nil) I think.

I'll find a way to stop parsing and printing when things get too large and give you the option to request the rest. Somehow.

strange is not soooooooooooooooo big is like 65000k lines

Oof, and how many characters? (just count the string without splitting lines)

Ah, I managed to cause a lock up, a small one but still. About 20k lines

(lasted 1-2 seconds)

cool, I mean nice that is reproducible

probably chunk is a good option

Might write a timing wrapper function or something and try to pin point the delay.

CHARACTERS 3862488  SPACE 1531184

Looks like the biggest delay might be in splitting the lines.

do you think is possible to conditionally do something? if not I'm fine with sintax off

I think just turning off pprint until I've optimised it is the best bet

I might know why, working on some tweaks now

ah, another question, is there a way to clear the buffer?

Although I'll be doing dinner and coming off soon, I'll work on this tomorrow too. I want Conjure to easily handle this kind of output. Maybe a little delay, but it should still be usable.

When I clear the buffer I just open it in a split or tab then dgg, like any old buffer 🙂

thanks

ahh ok

sure, I still didn't realized that is a normal buffer haha

You can write more code in there and eval it too, it's like a buffer REPL

quite cool

Updated Aniseed's string splitting algo (Lua doesn't come with a good string split so I had to write my own Clojure like one and it was SLOW)

My repro case is now too fast to notice...

How's yours? I would imagine it'll still lag a bit but should be MUCH better?

dude you fast

I will update here

😄

I just poured coffee on aniseed.string/split

yeap looks like is solved

I will keep testing it on my production apps haha

😱 you mean that huge output is now mostly performant and doesn't lock up vim at all?

(I would expect something that big to slow the buffer down no matter what, it's just huge)

yeap, seamlessly

but if I do some evals

😍 that worked better than expected

after some I have to clean the buffer

because is huge anyways

haha

computer problems

but is really fine now

So the log does trim automatically when it's too long but there's an edge case that you're hitting. I don't trim as well when there's one REALLY big result.

Default config is in the docs, I think it's past 10k lines it is cut to 6k?

yeah is a big big map

So if want it to trim more aggressively (depends on your CPU and RAM I guess) you could set it to like trim at 3000 lines down to 1000?

https://github.com/Olical/conjure/blob/b622ac812173b2c5f331140450995faa86921d1f/doc/conjure.txt#L259-L265

OK cool

perfect

Trimming could maybe be better in that case though :thinking_face:

will make a note

So if you had 50k line result in the buffer, it'll fill the buffer. Then as soon as you eval anything else it'll ALL get deleted. Or do you think just cutting the top off the big result is better :thinking_face:

I kinda think just delete the whole thing, it's too big, and you can see it again with <prefix>v2 to view the 2nd most recent result again.

yeap I think delete all will be easier to handle

that way you don't end up with half a form that ruins your highlighting too

WDYT about add some information about Piggieback and cider-nrepl in the readme installation part?

Very subtle as Tim Pope did in fireplace.vim

Oh you mean about installing those specifically?

I'd probably make it another part of vim help :thinking_face:

Or just saying you will have limited options without then