develooper Front page | perl.perl5.porters | Postings from January 2012

Re: [perl #108470] Term::ReadLine should use AE instead of Tk for event looping

From:
Darin McBride
Date:
January 18, 2012 07:14
Subject:
Re: [perl #108470] Term::ReadLine should use AE instead of Tk for event looping
Message ID:
1433060.Cg7QTNGf9G@naboo
My apologies for the duplicate posts... apparently the delay on email was 
longer than I had expected. :-(

On Wednesday January 18 2012 1:40:21 AM you wrote:
> I am author of a Audio::Nama, a Tk application that uses
> Term::ReadLine::Gnu with the tkRunning option to allow the
> user to control the app by entering commands via T::RL
> as well as by manipulating Tk widgets.
> 
> While I don't really understand how event loops work,
> it appears that the tkRunning setting actually
> belongs to Term::ReadLine::Gnu. IOW, it is necessary to
> install the latter for the tkRunning setting to work.

Looking through the T::RL::G code, it calls $self->register_Tk, which is in 
T::RL::Tk - where my patches are, and I *think* it registers the perl Tk_getc 
function as the getc for readline (it's hard for me to follow), which, again, 
is where my patches are.

> So I wonder, will it be sufficient to patch
> Term::ReadLine? Perhaps Gnu ReadLine will
> need patched as well?

Perhaps.  However, at worst, the Tk mode won't be affected.

> Second, I wonder, why change the existing API?
> Couldn't another setting, AERunning, be simply
> added rather than replacing tkRunning?
> As you point out, not everyone may want to
> add another dependency to their code.

The existing API isn't changed, but my answer to that is that AE is both more 
modern (not sufficient by itself) and more generic.  The point of AE seems to be 
to support any event model you might need, including Tk.

> Third, if such patches were proposed, I would want
> them to be tested fully (and I will be happy to help.)

My issue here is merely that the existing tests seem less than adequate.  I've 
run some sample code manually - with AE, Tk, and AE & Tk, and it all seemed to 
work.  However, that's all manual, and with T::RL::Perl, not T::RL::Gnu (I 
never have luck with T::RL::G, I don't know why).  I'll have to look at the 
tests for the T::RL implementations to see if they have anything I can use for 
a base for testing.  Otherwise, I have some really nasty ideas - we'll have to 
see.  I'm having problems enough keeping up the test files for $work :-)

> A final note, Audio::Nama already uses AnyEvent,
> allowing a choice of event loops. Event is selected
> for terminal-only mode and Tk for terminal+Tk mode.

I'm curious as to how you would receive events registered wtih Event while 
T::RL is waiting for text, since T::RL is currently going to be spinning the 
Tk event loop, not the Event event loop, unless you have an idle callback 
registered with Tk that simply spins the Event loop once.

In other words, as far as I can tell, today, T::RL will only spin a Tk loop.  
If Tk isn't loaded, it won't spin any loop, and all events will be on hold 
(with a possible exception of signal handlers) until the user hits enter.

> As far as I understand, the Tk event loop will
> still be required for Tk applications to play friendly
> with Term::ReadLine, however the AnyEvent layer
> might allow me to, for example, rewrite the GUI in Qt.

Right - by switching T::RL to use AE (or at least default to it when it's 
there), your GUI can use anything.  I would also suggest reading some of the 
Anyevent::Impl::* modules' perldocs - they're informative as to what bugs the 
author had to overcome.  In the Tk module, he talks about limitations 
regarding the event loop, and how the event IDs can wrap around, clobbering 
events.  "So don't run Tk programs for more than an hour or so."  Allowing the 
user of the module the ability to work around these types of issues simply by 
using another event model seems prudent.

> Bonus questions: Does any know if tkRunning setting supports
> other Tk implementations such as Tcl::Tk or Tkx? Do they
> provide events such as Tk::after?

One of my "test that I didn't break anything" scripts is using Tk::after just 
to prove that the events are being called.  I don't know about Tcl::Tk or Tkx 
- I actually don't use Tk, which is one of the driving factors behind this 
itch.

> If so, it may be necessary that these sister implementations
> of Tk be verified to function properly under patches
> proposed to Term::ReadLine, Term::ReadLine::Gnu, or
> possibly Gnu ReadLine.

More testing == good.  (But too much testing == unreasonable delay)  Since my 
new patch leaves everything alone when AE is not loaded, but works fine with Tk 
when AE and Tk are loaded, these should continue to work.  But testing our 
questions is definitely good - I just don't know anything about these other 
modules to know how to test them.

> All this is written in theoretical ignorance, but with
> a measure of actual experience with the packages in
> question.

:-)

Thanks!



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About