Output to internal console is not immediately available #868
Comments
|
From techtonik@gmail.com on 2011-12-03T05:14:37Z Why it is important? Because it complicated plugin debug and development. |
|
From pierre.raybaut on 2011-12-03T09:59:35Z There is a signal emitted by the SysOutput object (spyderlib/widgets/internalshell.py), which is SIGNAL("void data_avail()"), that should trigger the shell to write all pending data of the output stream. This is a known (by me at least) bug. It's just that I hadn't take the time to dig further and understand what's going wrong. |
|
From techtonik@gmail.com on 2011-12-06T03:59:54Z Is it possible to create some kind of development widget, which will allow to debug signals and handlers? For me internal signal weaving and threading looks like a complicated stuff without any entrypoint. I'm looking for something that will help me to track signals at run-time (dynamically) and help other people to understand what's going on (intuitive visualization). Maybe Qt provides some API? I need to:
|
|
From techtonik@gmail.com on 2011-12-13T03:48:14Z Moved signal rant into issue As for this issue, the problem is that output to internal console is buffered. I don't know why it is done, so I need your approval before committing an attached change. Status: Started Attachment: flush.output-to-internal-console.diff |
|
From techtonik@gmail.com on 2011-12-14T15:26:01Z This issue was closed by revision 2f20ab9bc6ce . Status: Fixed |
|
From pierre.raybaut on 2011-12-14T23:12:59Z Sorry Anatoly, I'm quite busy these days and I hadn't the time to check out this. After reading the diff, I think that's it's not a fix but a workaround because even if it's buffered the output should be print right away. In other words, the bug is elsewhere. By the way, the internal console is buffered for performance reasons, if I remember correctly (it's been a long time now since I've coded this part). And if I still remember correctly, to test the output performance, you may simply do this inside the console: import time |
|
From techtonik@gmail.com on 2011-12-14T23:55:54Z The performance results after the patch are impressive: 388 seconds on internal console vs 2.4 in standard. So, if the buffering is done for performance reasons only, then the bug should manifest for all consoles. I think I know what a proper fix is. "void data_avail()" signal results in merely putting the data into output buffer, and buffer sets timer in widgets.shell.ShellBaseWidget.write(), but this timer is only checked on the next write. So, the proper fix is to fire off a timer for a flush action, which will call flush() on timeout. Every write should postpone timeout for this timer. If the timer is made with Qt signal, I see two problems:
Need to try out. Status: Started |
|
From pierre.raybaut on 2011-12-15T01:08:19Z "So, if the buffering is done for performance reasons only, then the bug should manifest for all consoles." -> I don't think so because the other console (the external console) -thanks to the QProcess stdout/stderr pipes- is also "buffered" (even if that's not a real buffer but the result is the same: the console widget is not overwhelmed with print requests). As for the rest of your comment, you may have found the source of the problem indeed. I really have to take the time to look into it. In the meantime, we have to remove this 'flush=True' option. |
|
From techtonik@gmail.com on 2011-12-15T01:25:33Z I'd like to have a few hours to submit a better fix, but if you'd like to wrap 2.1.5 in the meanwhile (or if I won't be able to do anything and revert r2f20 myself), then please go ahead and remove it. |
|
From pierre.raybaut on 2011-12-15T03:49:42Z No there is no rush. The 2.1.5 release can wait a little more. |
|
From techtonik@gmail.com on 2011-12-15T10:05:56Z Tried QTimer() with no result. Then read the magic phrase: "This implies that a timer cannot fire while your application is busy doing something else." (c) http://developer.qt.nokia.com/doc/qt-4.8/timers.html A pity. Will try combined approach. |
|
From techtonik@gmail.com on 2011-12-15T10:14:38Z Observing very-very strange performance behavior without any modifications from my side: Active Console - 2.24s. |
|
From techtonik@gmail.com on 2011-12-15T12:13:22Z This issue was updated by revision de6511e56c70 . Status: Fixed |
From techtonik@gmail.com on 2011-12-03T08:11:59Z
What steps will reproduce the problem?
1.The easiest way is to use attached plugin What is the expected output? What do you see instead? If you open Spyder's console, you'll notice only one string being output - 'Me imported!' (or maybe two - it's not consistent). After you press "Enter", you'll see the rest.
I thought that after line is written to the output, it should signal immediately to console that output is availble. Where does it happen in the source code?
As for inconsistency, there might be a race condition in plugin/widget initialization order. Are they initialized asynchronously? When a new threads are created during initialization, does the main process wait until their init is complete?
Attachment: p_plugman.py
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=868
The text was updated successfully, but these errors were encountered: