disabling event_loop support makes plot display hang

[devel-chm]

For the latest PDL::Graphics::Prima git (a.k.a., version 0.1201)

I was trying to get PDL::Graphics::Prima to safely interoperate with another module using the Term::ReadLine event_loop code by making is_happy_with return false. Unfortunately, the widget doesn't seem to display at all now. Is there something else that needs to happen to make it run again. The PDL::Graphics::Prima::Simple used to fork a separate process for cygwin and things worked great that way.

FYI, what I was trying to implement first in this module and then in PDL::Graphics2D was the following:

1. check for event_loop support
2. if available, check if already being used $term->tkRunning is true
   • if not already used, enable the GUI support
   • if running, use alternate display strategy (fork or block)

This allows for a quick implementation of some sort of either/or operation of multiple "customers" of the event_loop support. The next would be to add something clever like swapping hooks or daisy-chaining the calls to support multiple GUI options.

[run4flat]

Chris -

Good idea. I have modified the current behavior as you suggest. At the moment, the plot blocks when called without event_loop support, and event_loop support can fail if another user interface has already setup tkRunning on the readline (or if T::RL isn't new enough).

To facilitate things a bit, I have added the "twiddle" method to Prima windows. It is not perfect, however. It only really works for the windows that are returned when you call a plotting function in list context. I have yet to document this behavior because it is still rough around the edges and needs to be sorted out. For now, just know that if the plot blocks when you call it, you can use the twiddle method on the window that holds the plot. That is,

pdl> ($window, $plot) = line_plot(sin(sequence(100)/10));
# Blocks until you press q/Q
pdl> $window->twiddle
# Blocks again until you press q/Q

Note that the twiddle method is always present (when you use PDL::Graphics::Prima::Simple). It is a no-op if the event_loop support is enabled.

I originally implemented the forking behavior precisely so that we could have interactive plots and a responsive REPL. When I realized I could get both, I decided to toss out the forking behavior in favor of the Term::ReadLine event_loop approach. After all, playing with the widgets directly in the REPL makes learning a lot more fun, and easy.

One problem that I've noticed and been very annoyed with is how Term::ReadLine::Perl does not play nicely. I'm not sure what to do about this.

This is still experimental and needs some work, so I'm going to leave this open for now. However, I'm not quite sure about the best way to solve this, so feedback on this would be very much welcome!

[run4flat]

Since the previous comment on this discussion, the behavior of twiddle has substantially matured. I still do not have things working on Windows, however. Do you have any idea how to get event_loop working on Windows?

[devel-chm]

I haven't revisited the event_loop and twiddle support since the previous discussion. Most/all of my available PDL developer cycles have been spent on inching forward on fixing the 64bit index support for PDL-2.x.

On Wed, Aug 6, 2014 at 4:32 PM, David Mertens notifications@github.com wrote:

Since the previous comment on this discussion, the behavior of twiddle has substantially matured. I still do not have things working on Windows, however. Do you have any idea how to get event_loop working on Windows?

— Reply to this email directly or view it on GitHub https://github.com/run4flat/PDL-Graphics-Prima/issues/24#issuecomment-51392888 .

[run4flat]

No problem. At any rate, I believe that the original problem has been papered over in PDL::Graphics::Prima::ReadLine anyway, so I'm going to close this.

By the way, should this check for Cygwin be removed? https://github.com/run4flat/PDL-Graphics-Prima/blob/3612/lib/PDL/Graphics/Prima/ReadLine.pm#L10 I fell like you mentioned once that Cygwin does not give trouble in this arena.

[devel-chm]

I suggest taking out line 10 altogether. The current code silently fails to do anything for MSWin or cygwin and then gives a useless error message---if I read it correctly.

Problems can't be fixed if they aren't indicated. As messy as it is, the Term::ReadLine::Perl is currently the only universally available readline for Perl. Of course, anyone on a unix-ish platform always has GNU readline so there is no investment in making a better, more portable readline driver. Sigh.

On Thu, Aug 7, 2014 at 7:41 AM, David Mertens notifications@github.com wrote:

No problem. At any rate, I believe that the original problem has been papered over in PDL::Graphics::Prima::ReadLine anyway, so I'm going to close this.

By the way, should this check for Cygwin be removed? https://github.com/run4flat/PDL-Graphics-Prima/blob/3612/lib/PDL/Graphics/Prima/ReadLine.pm#L10 I fell like you mentioned once that Cygwin does not give trouble in this arena.

— Reply to this email directly or view it on GitHub https://github.com/run4flat/PDL-Graphics-Prima/issues/24#issuecomment-51460843 .

[run4flat]

No, that is not a silent failure, it is an explicit failure saying "PDL::Graphics::Prima plots cannot play nicely with this version of ReadLine." Thus, if somebody on Win32 or Cygwin says, line_plot or twiddle, it'll cause the REPL to block until the user presses Q in the plot window or closes the window. If I remove this line, then the plot window never updates when running under cmd.

There are complex solutions to this problem. If this situation is detected, I could spin off a new thread to hold all of the Prima stuff (Prima does not support multiple threads), and then create some sort of mock Plot object that communicates all of its commands to the Prima thread. I could use PDL::Parallel::threads to do all of the data sharing. Perhaps, however, this is better solved by working on the Prima side of things, rather than hacking a solution into PDL::Graphics::Prima.

Does PDL::Graphics2D solve this (with GLUT) using threads?

[devel-chm]

You aren't checking anything on line 10, just quietly failing for those two platforms and then without any error to the effect "This code does not support readline detection for windows and cygwin platforms".

I'm not sure why it wouldn't be better to do the actual check and have the actual fail? Maybe you could add darwin to line 10 to understand better how non-helpful the current implementation is.

One of my !favorite problems with perl portability is modules that don't or can't work on a platform but with no indication that that is the case.

I guess one optionwould be to leave the line 10 hack in but have theplatform listed as not applicable or have a test that would fail to show the problem.

On Thu, Aug 7, 2014 at 9:45 AM, David Mertens notifications@github.com wrote:

No, that is not a silent failure, it is an explicit failure saying "PDL::Graphics::Prima plots cannot play nicely with this version of ReadLine." Thus, if somebody on Win32 or Cygwin says, line_plot or twiddle, it'll cause the REPL to block until the user presses Q in the plot window or closes the window. If I remove this line, then the plot window never updates when running under cmd.

There are complex solutions to this problem. If this situation is detected, I could spin off a new thread to hold all of the Prima stuff (Prima does not support multiple threads), and then create some sort of mock Plot object that communicates all of its commands to the Prima thread. Perhaps, however, this is better solved by working on the Prima side of things, rather than hacking a solution into PDL::Graphics::Prima.

Does PDL::Graphics2D solve this (with GLUT) using threads?

— Reply to this email directly or view it on GitHub https://github.com/run4flat/PDL-Graphics-Prima/issues/24#issuecomment-51473071 .

[run4flat]

Enlightenment: The reason this is in place is to ensure that the user has at least a passable experience in the perldl shell. Without this, plots will not properly display, and the reason for this is because the Prima file IO watcher cannot detect keystrokes on regular Win32. (This probably isn't an issue on Cygwin.)

Looks like I need to change keystroke detection... and it looks like Term::ReadKey is the way to go with that.

[devel-chm]

Again, the problem is the lack of warning that win and cygwin are assumed broken in the error message. E.g., carp "win and cygwin not handled by ..." and return 0; or some such.

Term::ReadKey is definitely the portable way to go for Term::ReadLine::Perl. I recently looked at using Term::ReadKey as a way to add syntax highlighting to the PDL shells since the highlighting needs to be determined before the keystroke is displayed.

On Thu, Aug 7, 2014 at 12:34 PM, David Mertens notifications@github.com wrote:

Enlightenment: The reason this is in place is to ensure that the user has at least a passable experience in the perldl shell. Without this, plots will not properly display, and the reason for this is because the Prima file IO watcher cannot detect keystrokes on regular Win32. (This probably isn't an issue on Cygwin.)

Looks like I need to change keystroke detection... and it looks like Term::ReadKey is the way to go with that.

— Reply to this email directly or view it on GitHub https://github.com/run4flat/PDL-Graphics-Prima/issues/24#issuecomment-51496957 .