BrenBarn
commented
8 years ago I finally got irritated enough to take another look at this and managed to create a "manual override" like I described above. The change can be seen on my fork at https://github.com/BrenBarn/dreampie/commit/cd59da455e237609fdaf5cf218b79dd1e2256120 . It is a simple change that just adds an "unclog" menu item.
The problem is that somehow DreamPie gets into a state where it thinks there is a result in the pipeline from the subprocess, so it waits for it. But there is no result, so it waits forever. I wasn't able to figure out exactly how it arises, but this manual override seems to successfully fix it when it occurs. However, this override could cause havoc if used when DreamPie is not "stuck", so you have to be careful to use it only when it is really stuck in this particular way.
Unfortunately there seems to be little chance of this (or any of the other issues here) getting resolved in the official version of DreamPie, since there is no activity on this project. That is a shame, since DreamPie is very useful.
I occasionally encounter a problem where the subprocess seems to become stuck in the busy state, so that trying to execute any command gives a beep and "The subprocess is currently busy" in the status bar. I'm not sure if it can be caused in different ways, but I recently found a situation that seems to reproduce it reliably, although it requires some timing.
If you have an object with a very large number of attributes, and you type its name type
.and then hit tab to autocomplete attribute names, and then immediately delete the object name, or part of it (for instance by hitting backspace quickly several times), the subprocess becomes stuck in busy mode. Even interrupting it (with Ctrl-C) doesn't work. This doesn't happen every time, but seems more likely to happen the quicker you do the deletion. Sometimes it happens even with a long delay. Even if the stuck-busy state does no thappen, no autocomplete popup is ever displayed.It seems that DreamPie can get stuck somewhere in the middle as it waits for the subprocess to provide the list of attributes, then group them for display. Ideally, this problem could be fixed "for real", in the sense that user action that interrupts the autocomplete population would cause a clean abort of the autocomplete. As a stopgap, the autocomplete could maybe have an early failsafe check to abort if the length of
dir(obj)is too large (but whether this will work depends on whether the problem occurs while waiting fordirto return, or at a later stage).I'm not sure if this is the cause of every stuck-busy situation I've encountered or not. I don't know what is going on in the innards here, but it seems unlikely that the subprocess is really busy all that time, because the actual operations don't take that long. It seems more likely that DreamPie is getting mixed up and thinks the subprocess is busy when it actually isn't. It would be nice, if possible, to have some sort of "manual override" that would force DreamPie to reset the busy state in cases like this.