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

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

From:
Joel Roth
Date:
January 18, 2012 10:13
Subject:
Re: [perl #108470] Term::ReadLine should use AE instead of Tk forevent looping
Message ID:
20120118181323.GB19006@sprite
On Wed, Jan 18, 2012 at 07:27:35AM -0700, Darin McBride wrote:
> On Wednesday January 18 2012 1:40:21 AM Joel Roth wrote:
> > 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.

I use Event in a situation that the app runs without loaded
the Tk based GUI, to provide timers, etc. In that case,
tkRunning is not set.
 
> 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.

I'm glad no one told *me* that! :-)

A T::RL based command prompt seems to run fine alongside 
an Event event loop. I may be able to dig up some
test code to verify this FYI.
 
> > 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.

Ouch! This is an audio app that might record or play for
long periods. Thanks, I will look into it. 
 
> > 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!

Seems to be going both ways. :-)

-- 
Joel Roth



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