Scroll output in *nrepl-server* window

[vspinu]

No description provided.

[bbatsov]

Is this necessary given the fact the lein repl produces pretty much no output?

[vspinu]

Lein doesn't but all loggers do end up in nrepl-server. clojure.tools.logging does that by default and taoensso.timbre does it only with scheduled tasks (as with overtone.at-at). I guess it has to do with the futures and the output from different threads. Seem to be a well known thing in CIDER.

[bbatsov]

Lein doesn't but all loggers do end up in nrepl-server. clojure.tools.logging does that by default and taoensso.timbre does it only with scheduled tasks (as with overtone.at-at). I guess it has to do with the futures and the output from different threads. Seem to be a well known thing in CIDER.

This is a long-standing bug I haven't had time to tackle. Logger output should be treated as stdout IMO. Nothing but lein output should ever appear in this buffer.

[vspinu]

I guess it's nREPL thing. The out and err are probably not correctly bound in new threads. For the time being a lot of stuff for me ends up in server buffer. Besides loggers, composure web router also spits errors there. So it's quite common problem. Till this is fixed server buffer must scroll ;)

[bbatsov]

Yeah, I get this, but on the other hand - if the buffer doesn't scroll people will be more motivated to fix the actual problem. :-) I think this might be another workaround:

(alter-var-root #'*out* (constantly *out*))

[vspinu]

(alter-var-root #'*out* (constantly *out*))

Doesn't work for me.

[bbatsov]

Guess we need to debug this more then. At any rate I don't think we should make improvements to an undesirable/broken behaviour.

[vspinu]

Guess we need to debug this more then.

Given that this issue is there for very long time and no-one fixed it, it might take ages till it's really fixed. This particular lein/nrepl stuff is way beyond my understanding and I also won't be able to get deeper into it soon.

BTW, is there an open issue for this problem?

[bbatsov]

There used to one a long time ago, says here it was fixed in 0.1.6. After that you've been the only one to report this problem (or so it seems to me). I'm extremely busy this week, but I might try to reproduce and fix the issue next week.

[bbatsov]

After digging a bit I found the original issue report and an e-mail thread discussing the problem.

[vspinu]

That's exactly what I experience. After reading a bit, it looks pretty complicated.

On a local machine a workaround would be to send the output of the server to the repls. On remotes the issue is much worse as you don't even get the nrepl-server buffer.

I will fire a new issue tomorrow with simple instructions of how to replicated.

[cch1]

I too experience this behavior. Particularly annoying with log output -as that is a common technique for debugging. Without scrolling, viewing the log output is damnably frustrating.

I will add that moving the standard output from the nrepl buffer to the the cider repl buffer would be a big step backwards -it is very convenient to have logging separated from interactive output.

Also, I have noticed another issue relating to the nrepl buffer disappearing after a cider-restart or even a cider-quit followed by a cider-jack-in. Very annoying, and the only solution (that I can discern) is to quit emacs and restart. I'll raise another issue for that problem as I suspect it is more severe.

[cch1]

I have raised issue #912 to address the disappearing nrepl-server buffer.

[vspinu]

I will add that moving the standard output from the nrepl buffer to the the cider repl buffer would be a big step backwards -it is very convenient to have logging separated from interactive output.

I agree with this but the problem is that not only logging output can end in *nrepl-server*.

[cch1]

Not sure why this is closed...
For various reasons (e.g. org.apache.log4j.ConsoleAppender's early caching of System/out), applications send output to nrepl-server. Are you suggesting that we should switch from the ConsoleAppender (or whatever library we are currently using) to something else? Or that it's not realistic to expect scrolling in nrepl-server?

On a related note, is there a way to create a dedicated buffer (i.e. "MyTracingBuffer") and stream output to it from Clojure via the nrepl?

[vspinu]

I agree, till the issue is not fixed one way or another it probably should stay open.

[arrdem]

Agreed, this is something that has really gotten in my hair of late in hacking on Grimoire which uses a classical logging tool that doesn't write to the REPL.

[bbatsov]

The PR was closed because it's not a solution to the real problem. I think there's an open ticket somewhere tracking what to do with the output to the nREPL buffer, but if I'm mistaken we can start a new discussion.

[cch1]

What is the real problem?

On 21 Jan, 2015, at 01:58, Bozhidar Batsov [email protected] wrote:

The PR was closed because it's not a solution to the real problem. I think there's an open ticket somewhere tracking what to do with the output to the nREPL buffer, but if I'm mistaken we can start a new discussion.

—
Reply to this email directly or view it on GitHub #818 (comment).

[bbatsov]

@cch1 That the output in question should have never went to the *nrepl-server* buffer. Keep in mind this buffer doesn't even exist if you're not using cider-jack-in.

[cch1]

Hmmm.... I'm wondering then where this "real problem" originates. As a Clojure developer, I don't chose to send output to *nrepl-server* -it is a by product of log4j's startup behavior (which, I think we would agree, is not something that is reasonable to change) and perhaps leiningen, cider or nrepl. Based on some research (guided by your references above), it seems as though log4j binds early to System/out when using the ConsoleAppender. So do you have any idea how System/out gets sent to *nrepl-server* and how I (as a Clojure developer) might change it?

So far, I have heard nothing that indicates it is possible to change this behavior, and thus I am stuck with having log4j output in *nrepl-server*.

(I submit that having the application's standard output, including log output, in a buffer separate from interactive REPL output is desireable. I would go so far as to call it a feature. But if the only way to get scrolling log output is to send it to the *cider-repl* then I will happily do that if you can guide me.)