Re: status of fileevent support? (for use with Tcl::pTk)

[Christopher Chavez]

(Continuing discussion from https://github.com/gisle/tcl.pm/issues/14 here per Vadim's suggestion)

chrstphrchvz commented Jul 11, 2018, 3:06 PM CDT:

I came across an issue using fileevent from Tcl::pTk on macOS, which I've documented here: https://rt.cpan.org/Ticket/Display.html?id=125662

I noticed there's comments in Tcl::pTk's fileevent suggesting it be rewritten, since it has known shortcomings (e.g. only supporting 'readable', relies on polling interval). Another suggestion it makes is for Tcl.pm to support CreateFileHandler.

But do Tcl::Tk and/or Tkx already allow using fileevent 'as-is' through Tcl.pm? (I haven't yet successfully tried; is there a readily available example somewhere?) If that's the case, then I'm wondering if it's a matter of making Tcl::pTk recognize fileevent as something it should just pass through to Tcl.pm if it's syntax is sufficiently compatible with Perl/Tk's.

vadrer commented Jul 12, 2018, 2:46 AM CDT:

I haven't tried tcl/tk's fileevent, and actually I have no much plans on doing so.
The reason is that I mostly use tcl/tk for GUI, and perl for IO;

however it is possible to use tcl/tk's fileevent, but in this case we should expect for it to perform said IO.
problem with Tcl::pTk could be that it should "join" perl IO and tcl/tk IO; which is not very easy, plus I do not foresee much benefits from doing so.

For the program I'm working on (cf. https://github.com/hotwolf/HSW12/issues/16) the existing fileevent is for reading a serial port. It already uses separate read and write filehandles; it might be sufficient to use Tcl syntax to open a read handle for the device and make a fileevent for it (from Tcl rather than Perl), while continuing to use a Perl write filehandle in UI event callbacks.

For other uses, I'm not quite sure what the best approach will be. It doesn't seem possible to use some modern module like IO::Async in the same thread with e.g. Tcl::pTk due to separate event loops. If combining the file handles is best, that seems like something needing to be done from C/XS (not pure Perl or Tcl), which is what using Tcl_CreateFileHandler would entail.

[huck]

I use a variation on
https://www.nntp.perl.org/group/perl.tcltk/2011/03/msg524.html
with filrevents in tkx to read from sockets. i use it to read from
http sourced ports as well as stock sockets.

i dont have a simple example right now.

At 07:31 AM 7/29/2018, you wrote:

>(Continuing discussion from

><https://github.com/gisle/tcl.pm/issues/14>https://github.com/gisle/tcl.pm/issues/14

>here per Vadim's suggestion)
>
>>
>>

>><https://github.com/chrstphrchvz>chrstphrchvz commented Jul 11,

>>2018, 3:06 PM CDT:
>>
>>
>>>I came across an issue using fileevent from Tcl::pTk on macOS,
>>>which I've documented here:

>>><https://rt.cpan.org/Ticket/Display.html?id=125662>https://rt.cpan.org/Ticket/Display.html?id=125662

>>>
>>>I noticed there's comments in

>>><https://metacpan.org/source/CERNEY/Tcl-pTk-0.92/lib/Tcl/pTk/Widget.pm#L2109>Tcl::pTk's

>>>fileevent suggesting it be rewritten, since it has known
>>>shortcomings (e.g. only supporting 'readable', relies on polling
>>>interval). Another suggestion it makes is for Tcl.pm to support
>>>CreateFileHandler.
>>>But do Tcl::Tk and/or Tkx already allow using fileevent 'as-is'
>>>through Tcl.pm? (I haven't yet successfully tried; is there a
>>>readily available example somewhere?) If that's the case, then I'm
>>>wondering if it's a matter of making Tcl::pTk recognize fileevent
>>>as something it should just pass through to Tcl.pm if it's syntax
>>>is sufficiently compatible with Perl/Tk's.
>
>

><https://github.com/vadrer>vadrer commented Jul 12, 2018, 2:46 AM CDT:

>
>
>
>>I haven't tried tcl/tk's fileevent, and actually I have no much
>>plans on doing so.
>>The reason is that I mostly use tcl/tk for GUI, and perl for IO;
>>
>>however it is possible to use tcl/tk's fileevent, but in this case
>>we should expect for it to perform said IO.
>>problem with Tcl::pTk could be that it should "join" perl IO and
>>tcl/tk IO; which is not very easy, plus I do not foresee much
>>benefits from doing so.
>
>
>For the program I'm working on (cf.

><https://github.com/hotwolf/HSW12/issues/16>https://github.com/hotwolf/HSW12/issues/16)

[Konovalov, Vadim]

> For the program I'm working on (cf.
> https://github.com/hotwolf/HSW12/issues/16) the existing fileevent is for
> reading a serial port. It already uses separate read and write filehandles; it
> might be sufficient to use Tcl syntax to open a read handle for the device and
> make a fileevent for it (from Tcl rather than Perl), while continuing to use a
> Perl write filehandle in UI event callbacks.
> For other uses, I'm not quite sure
> what the best approach will be. It doesn't seem possible to use some modern
> module like IO::Async in the same thread with e.g. Tcl::pTk due to separate
> event loops. If combining the file handles is best, that seems like something
> needing to be done from C/XS (not pure Perl or Tcl), which is what using
> Tcl_CreateFileHandler would entail.

My personal preference is to avoid perl threads - always, even with careful
separation - GUI for one thread and all other for another.

Perl threads are officially discouraged, so I don't.

A point with different event loops for IO::Async and Tcl-based GUI-or-IO is a problem, indeed.

A question - is it still a problem for perl/Tk? (actually I think so)

Spinning 2 event loops is impossible, either by 2 threads or by one single thread
with any tricks or whistles or prays.

This means that a solution with tcl-only GUI and async-io is actually the preferred
one.

IOW you're correct with 'fileevent' question, :)

In case you see that pure-tcl not possible and indeed you need to
use API, including Tcl_CreateFileHandler, we could happily add that to XS.

[Konovalov, Vadim]

> I use a variation on
> https://www.nntp.perl.org/group/perl.tcltk/2011/03/msg524.html
> with filrevents
> in tkx to read from sockets. i use it to read from
> http sourced ports as well
> as stock sockets.

Yes, that's pretty much reasonable :)