Using the new Language Console API
This should be dead easy from what I have seen in the code most of the work in creating a custom language console is done by the base class implemenations, and the console does appear to work, but its connection to my Process's stdout and stderr is behaving strangely. I get no stdout at all, and I only get stderr if I kill the language console by pressing the stop icon.
For example i can type some garbage text, press enter, then stop the language console, and I will see the error message from the interpreter for the invalid input.
Nothing I have done has allowed me to see stdout.
Meanwhile I am able to run scripts against the same interpreter using my plugins' run configurations.
The language console API looks really great, and I really want to add support for it, but I havent been able to effectively debug this issue.
Anyone have any advice?
请先登录再写评论。
Can you post some snippets of the relevant code, or can we see what you're doing online somewhere? I've spent quite a lot of time with this recently, but without seeing the code it's hard to say what's going on.
There is literally almost no code since there is so much implemented in the base classes.
https://bitbucket.org/sylvanaar2/lua-for-idea/src/86506d5ffeda/src/console/
The problem is in the textAvailable() method of your ProcessHandler - this will be called with each line of output from the process. You can see how this works in OSProcessHandler - the ReadProcessThread breaks the output into lines and calls its textAvailable() method which calls notifyTextAvailable(), and the ColoredProcessHandler implementation of this calls your textAvailable().
Try something like this:
protected void textAvailable(String text, Key attributes)
{
ConsoleViewContentType outputType = ConsoleViewContentType.NORMAL_OUTPUT;
LanguageConsoleImpl.printToConsole(myLanguageConsole, text, outputType, null);
}
That should at least get you started seeing some output. The implementations that I've seen of this method use it to remove prompts from the output etc, you can also style it and so forth.
Thats just it - this function is not called except with the initial command text, you never see stdout and only see stderr one time when terminating the process.
Hmm, in that case, I'm not sure, sorry. I based my console off the one in the Clojure plugin - looking at how yours is set up, in the Clojure plugin a lot of the initAndRun() function from AbstractConsoleRunnerWithHistory is duplicated in ClojureConsoleRunner, I'm not sure why. The only thing I can suggest is debugging that part of OSProcessHandler to see if you can see what's going on. Sorry to not be more help.
I appreciate your trying to help - sometimes this stuff can be really tricky. It might just be a bug in the new API's default implementation.
I checked out your implmentation, and indeed it does do basically what the default implementation does for the most part. I could go that route too, it may just be how you have to do it. I don't know.
Thanks Again,
Jon
Yeah, it took me a while to understand what was going on, for sure. My implementation is more complex now (I have some code I have to push) since I wanted to handle various REPL types (an in-process one, a normal process one and one over a socket connection) and because I wanted it to work in a normal tool window. It has some nice features now, like multiple simultaneous REPLs in tabbed panes in the tool window etc, but it's taken me a while to get it there. There's quite a lot of trickiness around making it usable too, mine is still pretty slow - I'm not sure if this is something I'm doing wrong or not. Formatting is quite a pain too.
Anyway, let me know if you have more questions - if I get some time I might try to write all this up, it's kind of difficult to get started.
i can run cmd.exe (under windows) and stdout/err are recieved just fine.I missed the obvious.
I think the problem is really that my interpreter process doesnt think its running in a shell so it doesnt have the same interactive mode and flush its stdout like I need it to. In fact I know this is the case now that I have looked at the interpreter source. It uses _isatty() to check if stdin has been redirected (which it has) and if so it doesnt do its normal console outputs and prompting, it just processes stdin and writes to stdout
Ugh after all this, i found a switch that places the interpreter in interactive mode even when stdin is redirected.
It all works now. I can't believe it took me this long to figure this out.
Ugh, yeah, I had a similar problem with Kawa, but fortunately it was easier to find since Kawa just exited with an error rather than silently doing something different. Still, glad it's working now!