-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option to suppress displaying value of assignment in REPL #31176
Comments
I would say I want to see the value at least 99.9% of the time :) |
For interactive analysis of data, this would be a really nice feature to be able to set. With a dataframe I am currently working with, I lose 15 minutes to wasted terminal I/O every time I forget the semicolon. |
If any large object displays the entire object in the REPL, then that's the real problem. All objects defined by Julia itself print truncated versions of themselves that don't take long to print. |
When I submitted this issue I wasn't aware that ending a statement with a semicolon suppresses printing the value. The fraction of the time I'm interested in seeing the value is much closer to 50% than 99.99%, but that's often enough that adding a semicolon when needed is the quickest and easiest way to accomplish this. In response to @smallory's issue, I think it could be of value to add a field to Currently, a hacky way of truncating output could be by modifying There is also |
There's no need for an option because REPL output should always be truncated. Any package that doesn't respect this should have issues filed against it. |
Is this thread the best documentation to share for this requirement? My google-fu is to weak to find documentation of package expectations elsewhere that have this, and I'd like to be able to recommend a switch to Julia for EDA on large sets. |
I guess we haven't really documented this, although it's been in the ethos of the Julia REPL ecosystem from early on—we went to great pains to make sure that huge matrices are summarized and printed efficiently in the REPL. May I ask which data types are not following this? |
DataFrame from DataFrames. |
@StefanKarpinski I very much disagree that there is no need for it. It may be true that REPL output should always be truncated, but third-party packages don't always follow this. |
We should document, but I'm not sure where. If anyone has any good ideas about where to document this, please either submit a PR or file an issue requesting that doc text be added. |
Huh? DataFrames are absolutely truncated by default in the REPL:
|
Also, it's very easy to trigger large amounts of output accidentally while you are developing and testing your own types. |
Thanks to Jeff's note, I poked around and found that this is terminal-dependent behaviour. If I use a fixed-size terminal with finite scrollback, I only get the first and last 13 lines. While I usually get over 12k lines dumped to the screen if I forget my semi-colon. It does appear that the truncation code that DataFrames has needs a bug report. And, when I'm in a terminal that is not correctly understood by a library I'm using, I'd like to turn off the default display of values. |
Julia provides a julia> displaysize(stdout)
(48, 74) Either that is not working correctly on your terminal or DataFrames is not using it to figure out how much of a DataFrame to display. What does that return in your setup? |
Rather than give you an option to mitigate the symptom of a bug, the right thing is to fix the bug. We clearly can't "turn off the default display of values" in the REPL because that's the whole point of a REPL. Without the display of values, it's just you typing a program incrementally (which you can do pretty easily if you want). The only thing that could be done is to suppress the printing of the result of assignment, but that's a hack because unlike Python where an assignment doesn't evaluate to anything, in Julia it does, and distinguishing between an assignment and not an assignment is not that clearcut: there are many expressions that do assignment but also do something else. That would also not fix the problem that examining a DataFrame when you're not doing assignment prints 12k lines of junk that you don't want to see. |
Starting up a fresh session to check
So I tried loading my data set, and it's now busy dumping output... apparently a DataFrames bug. And yeah, I get it about python's assignment hack. I pictured using the REPL more like IDL than python, where if I want to see something, I have to print it, and think about what parts I'm printing. |
Ok, would be great if you could file an issue with DataFrames since they should be using |
Okey, it is not only in DataFrames this issue. Also HDF5 produces the same behaviour on certain terminals. I really do not know if its a problem of HDF5 or of the terminal, but if I open a big array of an HDF5 file and assign it to a variable, it prints the whole thing... and if it is a 4096 by 179000 points array, it is simpler to kill the process than to wait. By the way, I use the terminal embedded in a Emacs session... Anyone has experienced this behavior within emacs? |
I'm going to need some cooperation from the people posting here:
If you don't do these things, nothing is going to improve. I can't test on your computer and I'm not going to file issues about things that I didn't witness personally and can't reproduce on packages. |
Okey, I think is something that may be with the Emacs and the displaysize and those packages. I will file things with them. |
Well, this is behavior that changed with a different version of Julia.
The emacs shell mode has well known limitations, but they did not
change. The cause for the change in behavior was internal to Julia. I
think the latest julia is expecting more from the shell than it used to,
but maybe it is readline or something else that is working a little
differently.
…-Ed
On 7/9/20 4:31 PM, kzapfe wrote:
Okey, I think is something that may be with the Emacs and the
displaysize and those packages. I will file things with them.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#31176 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABD4FGFI3NDKCL6D3MJ23J3R2ZHOPANCNFSM4G2ETQFQ>.
|
Folks. I explicitly asked for very detailed help to help you here, but no one has responded with that information. This cannot be done for you since only you have the system where this is a problem. If anyone wants this to improve they have to do what's asked in #31176 (comment) and report back. |
Thank you for coming back to this. Since this thread was closed, I had opened a new thread here: The displaysize and other information is mentioned in that new ticket, above, and it is all reasonable. The TL;DR seems to be:
|
I know this is a closed thread but I encountered something like this recently. What I found was that adding |
In Julia I guess assignment statements evaluate to the assigned value, so it makes sense from a language perspective that executing them in the REPL prints the result just as it would for any other statement. However I don't think I'm alone in that this is not desired a large proportion of the time (personally I would say at least 80-90% of the time I'm not interested in seeing the value). For some values it's not a big deal, but vectors take up one line per element when pretty printed so assigning even relatively small ones can take up most of my terminal height.
I just found out that adding a semicolon at the end suppresses printing, which definitely makes this less of an issue, but I think it would be very convenient to have a function or variable in the REPL module that lets you disable printing of assignments. In the case the user does want to see the value they just need to type the variable name again.
I see there is already a function
ends_with_semicolon(line)
that checks for the semicolon case and is usually used for theshow
argument toprint_response()
:julia/stdlib/REPL/src/REPL.jl
Line 1118 in de48421
It seems like it shouldn't be too difficult to add another condition, if this sounds like a good feature.
The text was updated successfully, but these errors were encountered: