Re^2: Echoless terminal state after exiting Tk/Term::ReadLine event loop (Solved!)

[gnosti]

in reply to Re: Echoless terminal state after exiting Tk/Term::ReadLine event loop (Solved!)
in thread Echoless terminal state after exiting Tk/Term::ReadLine event loop (Solved!)

Thanks. I have Tk and Term::ReadLine playing well together using the same basic code as this example.

In the same project, I also have a use case where Tk is not running. I am using Event.pm there. From the link you provided, I see that event loops can live together. I'm also curious if I can simplify my code by using AnyEvent to provide the same interface, regardless of the underlying event loop.

[zentara]

I see that event loops can live together.

to be honest, it seems that you want to do complicated nested loop operations, but by using a distinct set of modules, which may or may not be thread safe or reliable together

there is a solution, however.... the GLib module, which is the Perl interface to the glib, (upon which gtk2 is based.... so its on alot of systems.... firefox uses it on linux)

So Glib has your basic eventloop, that has been well thought out..

...it works in threads....you can nest the loops.....you can give threads context, and priorities.... etc....

So I would switch to GLib if you want looping complexity.....and for that matter.....the glib c library is pretty simple to code for basic loop recipes like timers and filehandle watching.....plus the c does a cleaner job of thread memory reclamation(as compared to Perl)..... it is so elegant in depth, that you probably could model the thought process with it

[gnosti]

Nice of you to suggest Glib, which appears to be useful for many functions besides events.

My needs at present are really pedaestrian--just a couple of basic watchers--only complicated because the app I'm working on has terminal-based and Tk-GUI interfaces. I pretty much have to use Tk::event for the Tk and Tk/ReadLine side. I have similar watchers written using Event.pm for the text interface, because I don't want to force Tk on people who might be console users. So it won't be both loops together. Just one of the other. It looks like AnyEvent will let me code identically to both Event and Tk::event backends, as well as to Glib or Wx if I decide I want to snazz up my GUI.

[zentara]

.... just keep the dream going.... :-) .... i was toying with the idea of modeling thought after the concept of "living loops" that spawn new loops, etc... i figure i would have the master controlling loop written in c, but the spawned loops would be Perl for ease of writing. Keeping the master loop as c, would really simplify memory cleanup; and having Perl as the secondary loop language, would greatly simplify writing realtime code..... sort of self-writing code .... ok i have to stop.... this is getting too close to the tru.....