-
-
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
new repl wrong STDERR stream #7633
Comments
Interestingly, on Linux, I don't even get the prompt: $ ./julia 2> stderr.txt
$ cat stderr.txt
ERROR: `convert` has no method matching convert(::Type{TTY}, ::IOStream)
in TTYTerminal at no file
in _start at ./client.jl:363 |
oops, i probably should have posted exactly what I tested, rather than demonstrating a different bug the following reproduces my original result on OSX:
and on Ubuntu:
|
In Windows error messages and warnings don't appear in STDOUT. It is redirected with the commands below in the console (REPL), so if they were seen in STDOUT, they should have disappeared after redirection:
Similar experiments with STDERR:
The warning is not shown in the console anymore, indicating that it is sent to STDERR. If it is the correct stream for warnings is debatable. However, the error message is still shown in the console, and It is put neither in STDOUT nor in STDERR, just got displayed in the console window. If it is the intended behavior, the STDERR stream is superfluous, as error messages do not appear in there. |
@LaszloHars, we are discussing a separate question from what file descriptors are used for side effects from The question raised by @vtjnash is what file descriptor the REPL should ultimately write its output to, and in particular whether it should use different file descriptors for writing the result of evaluated expressions vs. exceptions caught from those expressions. |
I'm not actually convinced that this is a bug. Why should the REPL write its exception output to stderr? If I write To make an analogy, if you run |
In fact, my inclination would be to go in the opposite direction:
This way, if you have some fancier way you want to display exceptions in the REPL, you can push a corresponding display onto the display stack. But it would go to standard output by default. |
I was told in a julia-users Google group conversation about STDERR that this was the relevant issue in github. Sorry if it was not the case. Anyway, @Steve:
If the REPL does not write error to STDERR, then what is the purpose of this stream? The documentation ought to mention that STDIN, STDOUT and STDERR must not be used from the REPL, otherwise naive users (like me) spend days struggling with them. |
And you can use And part of the reason you've been struggling is that you've been spending nearly a month ignoring the repeated advice of experienced developers on the mailing list. |
I really like the idea of ExceptionData. It would better solve my problems than redirecting STD streams. Could we expect changes in this direction in the near future? (Still, the documentation ought to say something about STD streams and the REPL.) |
"Ignoring the repeated advice of experienced developers on the mailing list" Almost all of the "repeated advice" was about something else than the question at hand. I asked, how to capture the REPL output. The pieces of advice I got were "do this instead of capturing the output". I did not need those pieces of advice, since I had working "hacks". As I learned, the simple answer to my question: "you cannot do that with code of reasonable complexity". |
A rather long time ago (in Julia), we had discussed various ways of improving backtrace handling in Exceptions. Proposals included adding a backtrace to every Exception, or making an ExceptionData type. I guess we didn't have enough motivation at the time to actually try implementing some of these ideas. One of the problems is that generating a backtrace is extremely expensive – perhaps 99% of the work of throwing an exception – so it would be nice to be able to avoid creating one when it's not used
I don't have an answer. My best attempt at an answer is "that's what I expected". It seems inconsistent otherwise (since the stream used to print the error depends on whether it is caught by the REPL, or one of the other error handler, such as the client loop or root task unhandled exception handler). It's also what python does: $ python 2> /dev/null
>>>
>>> xx
>>> ^D
$ python
Python 2.7.5 (default, Mar 9 2014, 22:15:05)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> xx
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'xx' is not defined
>>> ^D
I tried to use case in some of my answers to differentiate between
Julia developers on the mailing list tend to try to answer questions of the form "how can I solve problem X by doing Y" by telling you why doing Z is better at solving problem X then using Y. If your hack was working, you wouldn't have needed to spend the past month asking for functionality to be removed from the REPL so that your hack from 0.2 would still work in 0.3. |
@vtjnash, my suggestion is that the REPL would only create the (You could also make |
Note that, in principle, what stream the REPL displays its exceptions to is orthogonal to whether we use But I'm still skeptical that this should go to |
My statement was generally orthogonal also, since you want the
It gets a little bit trickier with But I digress from this issue. I'm also skeptical that these should go to STDERR, so I've added the decision tag. The question is whether this was an intended change in behavior with respect to the 0.2 release that we want in the 0.3 release, or if we didn't want this behavior to change, but simply hadn't noticed/tested for it. |
https://gist.github.com/vtjnash/9cd53434cc7f7e2f7a29 please comment/edit the gist if this sounds reasonable (since it would be a breaking change) and I can create another issue Julep here |
@vtjnash, the gist seems good to me. |
The backtrace thing is a separate issue, feel free to open one. See also #7283. We also have a "stream repl", used when reading from a pipe, implemented with a small bit of code in client.jl. First, it would be nice to get rid of this and only have one REPL (the new REPL implements functions with the same names, such as |
OMG! This was what I always needed, and nobody mentioned it in the 3 julia-users Google group conversations, where I asked for help. PLEASE don't remove it, but tell, how to use it! |
It gets used for example by |
What needs to be done here? |
nothing? |
Seems that way to me? |
the new repl is incorrectly writing errors to STDOUT rather than STDERR (as would usually be expected)
The text was updated successfully, but these errors were encountered: