Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

disabling event_loop support makes plot display hang #24

Closed
devel-chm opened this issue Feb 8, 2013 · 9 comments
Closed

disabling event_loop support makes plot display hang #24

devel-chm opened this issue Feb 8, 2013 · 9 comments

Comments

@devel-chm
Copy link
Member

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
Copy link
Member

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
Copy link
Member

run4flat commented Aug 6, 2014

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
Copy link
Member Author

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
#24 (comment)
.

@run4flat
Copy link
Member

run4flat commented Aug 7, 2014

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.

@run4flat run4flat closed this as completed Aug 7, 2014
@devel-chm
Copy link
Member Author

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
#24 (comment)
.

@run4flat
Copy link
Member

run4flat commented Aug 7, 2014

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
Copy link
Member Author

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
#24 (comment)
.

@run4flat
Copy link
Member

run4flat commented Aug 7, 2014

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
Copy link
Member Author

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
#24 (comment)
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants