Adding a condition to evaluations before logging? #566
-
Hi! I'm using the python client and it is working very well, but I'm experiencing one issue that I would love to resolve. Namely, when evaluating some very long list (~30k elements), nvim freezes completely as it attempts to log it to the log buffer. My question is if/how one could log only e.g. the first 10 elements if the evaluated expression is a list over a given size? Sorry if this has been asked before or if it is a trivial question, I'm very new to nvim in general. Any help would be greatly appreciated! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
So the Clojure client has this because the REPL protocol does the trimming for us, I have a feeling a couple of other REPLs do too but not all of them, so this is quite a common problem. Right now I think all you can do is wrap your calls in a call to some function like The was we could "fix" this in the Python client specifically would be to wrap every evaluation you perform in more code that will check the result type and try to trim it down if it's too big, but then we also need a way to say "ignore that rule, just give me everything even if it's slow". I also worry that by introducing wrapping code we'll potentially break some code you're trying to evaluate in unintended ways. Although maybe it's worth the risk... what we'd have to do is extend this code so we had two paths, one for wrapped with a limiter and one without (which is what we have right now). conjure/fnl/conjure/client/python/stdio.fnl Lines 114 to 122 in dfb9f75 Then we'd need to update the mappings or add some config so we either use the truncating version or non-truncating, it'd probably have to be two mappings, or maybe an option you can easily set to What do you think, would it be easy to write some Python that would look at a value, truncate it if it's too big then return that truncated result, maybe with some warnings attached to show that data had been truncated? That's what I'd struggle with, writing the Python to do that nicely with all data types we can think of. I suppose it'd mostly be lists and dictionaries? |
Beta Was this translation helpful? Give feedback.
-
To expand this discussion a bit, would a
be a replacement of sys.__displayhook__ which is the default implementation for sys.displayhook? The Python version 3.8 docs for sys.displayhook show a pseudo-code implementation of reprlib was introduced in Python version 3.2 and provides an alternate
would be rendered like:
The truncation function could provide some global variable that toggles between the different representations. This toggle could be flipped by a key mapping for the Conjure Python client. Another detail would involve how to add the truncation function to the Python REPL that the Conjure Python client is connected to. |
Beta Was this translation helpful? Give feedback.
So the Clojure client has this because the REPL protocol does the trimming for us, I have a feeling a couple of other REPLs do too but not all of them, so this is quite a common problem.
Right now I think all you can do is wrap your calls in a call to some function like
take
which will only return the firstn
items from a given list, that way you can cap your output on expressions that you know will return a lot of items.The was we could "fix" this in the Python client specifically would be to wrap every evaluation you perform in more code that will check the result type and try to trim it down if it's too big, but then we also need a way to say "ignore that rule, just give me everything…