Re: Glib::IO->add_watch
On Thu, Apr 4, 2019 at 6:45 AM Jeff via gtk-perl-list wrote: > > On 03/04/2019 00:35, Daniel Kasak via gtk-perl-list wrote: > > Hi all. I'm trying to adapt some code I have for tailing the output of > > an app. When I fork using open() ... things work ( I have some issues > > with tail never exiting, but that's to be expected ). When I open a > > filehandle for reading these redirected log files however, my callback > > I passed to add_watch() gets called in a busy loop, and nothing else > > happens. I assume I'm just doing something simple wrong? What is that > > thing? :) Thanks ... > > The _watch_cmd() sub in gscan2pdf does what you want - uses > Glib::IO->add_watch() on stdout and stderr and triggers a callback on > every line read: > > https://sourceforge.net/p/gscan2pdf/code/ci/master/tree/lib/Gscan2pdf/Frontend/CLI.pm#l504 Thanks for the response Jeff ... but the example you linked is very similar to what I have ( in another codebase ) that works. ie I don't have problems with this method when *forking* a process - it works really well. I have problems with this method when I want to tail ( or use Glib::IO->add_watch() on ) STDOUT & STDERR of the *current* process. Dan ___ gtk-perl-list mailing list gtk-perl-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO->add_watch
On 03/04/2019 00:35, Daniel Kasak via gtk-perl-list wrote: > Hi all. I'm trying to adapt some code I have for tailing the output of > an app. When I fork using open() ... things work ( I have some issues > with tail never exiting, but that's to be expected ). When I open a > filehandle for reading these redirected log files however, my callback > I passed to add_watch() gets called in a busy loop, and nothing else > happens. I assume I'm just doing something simple wrong? What is that > thing? :) Thanks ... The _watch_cmd() sub in gscan2pdf does what you want - uses Glib::IO->add_watch() on stdout and stderr and triggers a callback on every line read: https://sourceforge.net/p/gscan2pdf/code/ci/master/tree/lib/Gscan2pdf/Frontend/CLI.pm#l504 Regards Jeff signature.asc Description: OpenPGP digital signature ___ gtk-perl-list mailing list gtk-perl-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-perl-list
Glib::IO->add_watch
Hi all. I'm trying to adapt some code I have for tailing the output of
an app. When I fork using open() ... things work ( I have some issues
with tail never exiting, but that's to be expected ). When I open a
filehandle for reading these redirected log files however, my callback
I passed to add_watch() gets called in a busy loop, and nothing else
happens. I assume I'm just doing something simple wrong? What is that
thing? :) Thanks ...
Dan
---
# Redirect STDOUT / STDERR to log files
my $app_log_path = "$logdir/app_" . $timestamp . ".log";
my $err_log_path = "$logdir/err_" . $timestamp . ".log";
my ( $STDOUT_READER , $STDERR_READER );
say( "Redirecting:\nSTDOUT: $app_log_path\nSTDERR: $err_log_path" );
open STDOUT, '>', $app_log_path or die "Can't redirect STDOUT: $!";
open STDERR, '>', $err_log_path or die "Can't redirect STDERR: $!";
# open $STDOUT_READER , "<" , $app_log_path or die( "Can't open stdout
log file!: $!" );
open( $STDOUT_READER, "tail -f $app_log_path |" )
|| die( "Can't fork!\n" . $! );
# open $STDERR_READER , "<" , $err_log_path or die( "Can't open stderr
log file!: $!" );
open( $STDERR_READER, "tail -f $err_log_path |" )
|| die( "Can't fork!\n" . $! );
Glib::IO->add_watch( fileno( $STDOUT_READER ) , ['in'] , sub {
my ( $fileno, $condition ) = @_;
# parse logs and write to textview
}
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO->add_watch - file descriptor got locked till the end of all incoming data
On Aug 3, 2009, at 2:14 PM, anguila wrote: Solved, I just put a new line to set the end of line and it works :) If you control both sides, that's the cleanest solution. Rock. i cant use sysread because i doesnt know the length of the input each time. That's generally not a problem if the file handle is set to non- blocking; sysread() should read what's available up to the buffer size you give. -- The trees on the bus go "pyoo pyoo pyoo..." -- Yvonne, singing, um, something ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO->add_watch - file descriptor got locked till the end of all incoming data
Solved, I just put a new line to set the end of line and it works :), i cant
use sysread because i doesnt know the length of the input each time.
On Sun, Aug 2, 2009 at 7:34 PM, muppet wrote:
>
> On Aug 2, 2009, at 3:03 AM, anguila wrote:
>
> I want to update a treeview and this is the reason why i'm using the
>> add_watch function. The child is sending data all the time for many reasons
>> and the problem that i have is the file handler which have the incoming data
>> from child to parent. With watcher each time the child sent data the $line =
>> <$reader> must save this data in $line and call the function.
>> But dont know why the <$reader> just get locked till the end of all
>> $writer>write() and then it save all those data into $line, and i dont want
>> that, i want to save the data of ->write in $line each time child send data.
>>
>> Any idea?
>>
>
> $watcher{$pid} = Glib::IO->add_watch($reader->fileno(), ['in',
>> 'hup'], sub {
>>my ($fileno, $condition) = @_;
>>
>>print "->cond = $condition\n";
>>if ($condition & 'in') {
>>print "->reading from parent!!!\n";
>>$line = <$reader>;
>>
>
> Don't mix and match buffered reads and an unbuffered event watcher.
>
> The <> operator will read until end of line, but the watch is based on
> select(), and fires when any data is available on the file descriptor. The
> end of line may not have arrived yet, and the <> will block until the end of
> line does arrive.
>
> You want to use sysread() here. This may involve keeping a partial string
> checking to see if it contains an entire line.
>
>
>
> --
> Teeter tots are shaped like marshmallows.
> -- Zella.
>
>
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO->add_watch - file descriptor got locked till the end of all incoming data
On Aug 2, 2009, at 3:03 AM, anguila wrote:
I want to update a treeview and this is the reason why i'm using the
add_watch function. The child is sending data all the time for many
reasons and the problem that i have is the file handler which have
the incoming data from child to parent. With watcher each time the
child sent data the $line = <$reader> must save this data in $line
and call the function.
But dont know why the <$reader> just get locked till the end of
all $writer>write() and then it save all those data into $line, and
i dont want that, i want to save the data of ->write in $line each
time child send data.
Any idea?
$watcher{$pid} = Glib::IO->add_watch($reader->fileno(),
['in', 'hup'], sub {
my ($fileno, $condition) = @_;
print "->cond = $condition\n";
if ($condition & 'in') {
print "->reading from parent!!!\n";
$line = <$reader>;
Don't mix and match buffered reads and an unbuffered event watcher.
The <> operator will read until end of line, but the watch is based on
select(), and fires when any data is available on the file
descriptor. The end of line may not have arrived yet, and the <> will
block until the end of line does arrive.
You want to use sysread() here. This may involve keeping a partial
string checking to see if it contains an entire line.
--
Teeter tots are shaped like marshmallows.
-- Zella.
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Glib::IO->add_watch - file descriptor got locked till the end of all incoming data
I want to update a treeview and this is the reason why i'm using the
add_watch function. The child is sending data all the time for many reasons
and the problem that i have is the file handler which have the incoming data
from child to parent. With watcher each time the child sent data the $line =
<$reader> must save this data in $line and call the function.
But dont know why the <$reader> just get locked till the end of all
$writer>write() and then it save all those data into $line, and i dont want
that, i want to save the data of ->write in $line each time child send data.
Any idea?
my ($reader, $writer);
$reader = FileHandle->new;
$writer = FileHandle->new;
socketpair($reader, $writer, AF_UNIX, SOCK_STREAM, PF_UNSPEC) or die
"socketpair: $!";
my $pid = fork();
$reader->autoflush(1);
$writer->autoflush(1);
if ($pid){
# PARENT
shutdown($writer, 0);
print "Pare!\n";
my $line;
$watcher{$pid} = Glib::IO->add_watch($reader->fileno(), ['in',
'hup'], sub {
my ($fileno, $condition) = @_;
print "->cond = $condition\n";
if ($condition & 'in') {
print "->reading from parent!!!\n";
* $line = <$reader>;*
print "--->line = $line!\n";
my @data=split(/,/,$line);
&update_treeview(@data);
}
if (($condition & 'hup') and (! defined($line) or $line eq
'')) {
return FALSE; # uninstall
}
else {";
my $line = <$reader>;
print "\n---line= $line\n";
my @data=split(/,/,$line);
&update_treeview(@data);
}
return TRUE; # continue without uninstalling
});
}
else {
...
child sent info to parent through $writer->write(data)
and then $writher->flush;
}
Thanks,
David
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO::add_watch doesn't work in Windows
On Thu, 08 Nov 2007 14:04:11 +0800
"Ye Wenbin" <[EMAIL PROTECTED]> wrote:
>Hi,
>The add_watch function seem not work in Windows. I test using
>this script:
>
>use Gtk2 '-init';
>use Glib qw/FALSE TRUE/;
>Glib::IO->add_watch(
> fileno(STDIN),
> 'in',
> \&callback,
> \*STDIN,
>);
>Gtk2->main;
>
>sub callback {
> my ($fd, $cond, $fh) = @_;
> my $line = <$fh>;
> print "You just input $line\n";
> return FALSE;
>}
>
>The script works in Ubuntu.
>But in windows, seem the program is block in the mainloop, and
>all inputs will appear in the command line after I press Ctrl-C.
Sorry for the late reply, but I just happen to see this.
I don't use windows, but try readline instead of <>
sub watch_callback {
# print "@_\n";
my ($fd, $condition, $fh) = @_;
my $line = readline STDIN;
print $line;
#always return TRUE to continue the callback
return 1;
}
zentara
--
I'm not really a human, but I play one on earth.
http://zentara.net/Remember_How_Lucky_You_Are.html
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Does Glib::IO->add_watch work on pipes on Win32?
Hi, This is just a long shot, but since I don't have a Windows computer, I thought I would ask. Does Glib::IO->add_watch work on pipes in Win32? I doubt that it does, but I didn't see anything mentioned about it in the GLib::MainLoop manpage. For instance, if I open a piped command on win32, like: open(my $fh, "some_command.exe | ) or warn "$!\n'; will an IO watch work on $fh? I guess I'm just hoping that Glib has a way to make it work on win32. Thanks, zentara -- I'm not really a human, but I play one on earth. http://zentara.net/Remember_How_Lucky_You_Are.html ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO->add_watch and reading the filehandle
"Matthew Braid" <[EMAIL PROTECTED]> writes: > > opened with IPC::Open2 I've been using Proc::SyncExec because it's got good exec error reporting. Doesn't look like Open2/Open3 has that, you'd think they probably should. > I was trying to figure out why the filehandle wasn't being picked up > as 'still readable' Sounds like it should be right, if nobody else is doing a buffered read. You could try you own select() in the io handler to see how it looks at the point you would go back to the main loop. Myself I've been using a non-blocking pipe or socketpair and reading in the handler until EWOULDBLOCK. > use Fcntl; > fcntl($FROM_CHILD, F_SETFL, fcntl($FROM_CHILD, F_GETFL, 0) | O_NONBLOCK); "MYHANDLE->blocking(0)" might be easier (after loading IO::Handle or whatever package it is that slips in that method). ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO->add_watch and reading the filehandle
Hi, 2008/7/17 muppet <[EMAIL PROTECTED]>: > The trick in C code is to mark the file as non-blocking, and read chunks until > read returns 0 bytes. I can't take the time to experiment right now, but i'm > reasonably certain that this works in perl, as well. Gah. I'm still thinking in Perl/Tk terms. I was trying to figure out why the filehandle wasn't being picked up as 'still readable' instead of looking for a lower level solution. I've been doing a lot of head slapping lately > Unless you're using datagram sockets, there is no guarantee that an entire > message showed up at once, so you always have to be able to handle partial > reads. Partial reads aren't a problem (the main program just buffers the data until it gets a whole message as long as the message so far is structurally valid) it was just that sometimes that 'too big' message wasn't followed by another message for a very long time, so the buffer was never getting flushed. If I use: use Fcntl; fcntl($FROM_CHILD, F_SETFL, fcntl($FROM_CHILD, F_GETFL, 0) | O_NONBLOCK); that should do the trick. Ta :) MB ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO->add_watch and reading the filehandle
Matthew Braid wrote: > Every so often it would stop working (ie, the helper process would > claim it sent a message, but the main process wouldn't act on it), and > after a lot of debugging it turned out that if an incoming message was > longer than 1024 characters the remaining part after the first 1024 > characters wouldn't be handled until the _next_ message was sent - in > other words, if I sysread 1024 characters off a 1025 > character-available stream, the Glib::IO watch doesn't still see the > file handle as readable, and so doesn't trigger the callback until > more data is pushed onto it. Unfortunately I can't use a while > (sysread(...)) in the callback cos then it hangs waiting for data. The trick in C code is to mark the file as non-blocking, and read chunks until read returns 0 bytes. I can't take the time to experiment right now, but i'm reasonably certain that this works in perl, as well. Unless you're using datagram sockets, there is no guarantee that an entire message showed up at once, so you always have to be able to handle partial reads. -- muppet ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Glib::IO->add_watch and reading the filehandle
Hi all,
I've just run into a little problem in one of my programs involving a
Glib::IO watch.
In order to allow the main program to run smoothly while Big Stuff(tm)
is happening, I've shifted a lot of time intensive work off to a
helper process which has been opened with IPC::Open2. Messages are
sent to the helper process and responses are picked up by the Glib::IO
watch. Usually this works fine with the following callback:
sub {
my ($fno, $cond, $self) = @_;
if ($cond & 'in' and
sysread($self->{FromChild}, my $buff, 1024)) {
$self->recvchunk($buff);
}
if ($cond & 'hup') {
$self->recvchunk("\n");
$self->{PipeOK} = 0;
return 0;
}
return 1;
}
(to clarify, $self is passed in as data to the callback and is an
object that handles incoming and outgoing messages, translating as
needed. recvchunk is the sub that handles incoming blocks of data, and
$self->{FromChild} is the filehandle for the incoming messages).
Every so often it would stop working (ie, the helper process would
claim it sent a message, but the main process wouldn't act on it), and
after a lot of debugging it turned out that if an incoming message was
longer than 1024 characters the remaining part after the first 1024
characters wouldn't be handled until the _next_ message was sent - in
other words, if I sysread 1024 characters off a 1025
character-available stream, the Glib::IO watch doesn't still see the
file handle as readable, and so doesn't trigger the callback until
more data is pushed onto it. Unfortunately I can't use a while
(sysread(...)) in the callback cos then it hangs waiting for data.
As a workaround I upped the sysread to 10240 characters (which is
very, very large for a message in this system), but I'm pretty sure
this isn't Behaving As Expected, so I wanted to make sure I haven't
done something stupid in my callback.
Since I control both sides of the communication, I _can_ ensure that
the helper script never sends a message exactly 1024 characters in
length (empty lines are ignored, so sticking a newline at the end of a
1024 char message will work fine) and change my callback to something
like:
sub {
my ($fno, $cond, $self) [EMAIL PROTECTED];
if ($cond & 'in') {
while (1) {
my $cnt = sysread($self->{FromChild}, my $buff, 1024);
$self->recvchunk($buff);
last if $cnt != 1024;
}
}
if ($cond & 'hup') {
$self->recvchunk("\n");
$self->{PipeOK} = 0;
return 0;
}
return 1;
}
but that only works _because_ I have full control on the incoming data
and isn't really a generic solution.
In case its important, messages sent back and forth are always
hashrefs that have been serialised into YAML and then Base64 encoded
and wrapped in '--- START MESSAGE---' and '---END MESSAGE---' lines,
so a full message is never a single unbroken line. Filehandles have
also been unbuffered with select.
TIA,
MB
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Glib::IO::add_watch doesn't work in Windows
Hi,
The add_watch function seem not work in Windows. I test using
this script:
use Gtk2 '-init';
use Glib qw/FALSE TRUE/;
Glib::IO->add_watch(
fileno(STDIN),
'in',
\&callback,
\*STDIN,
);
Gtk2->main;
sub callback {
my ($fd, $cond, $fh) = @_;
my $line = <$fh>;
print "You just input $line\n";
return FALSE;
}
The script works in Ubuntu.
But in windows, seem the program is block in the mainloop, and
all inputs will appear in the command line after I press Ctrl-C.
--
Best regards.
Ye Wenbin
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO->add_watch and log files
On Mar 19, 2007, at 10:50 PM, Daniel Kasak wrote:
> open LOGFILE, "<", "$self->{globals}->{appdir}/app.log";
> $| = 1;
>
> Glib::IO->add_watch ( fileno(LOGFILE), ['in', 'hup'], sub {
> my ($fileno, $condition) = @_;
> if ($condition eq 'hup') {
You should check for $condition >= 'hup', not simply eq 'hup', and
should always do this check *after* reading any available input.
Reason: you can get 'hup' and 'in' on the same callback, and if you
do the hup check first in that situation, you'll silently drop the
last chunk of input.
> warn "done\n";
> close LOGFILE;
> return 0; # uninstall
> }
> my $line;
> sysread LOGFILE, $line, 1024;
A very quick experiment with your code shows that sysread is simply
returning 0 here for all reads after reaching the end of the file.
It appears that you simply don't get a 'hup' at the end of input when
reading a local disk file.
I think that you want to add this line here:
my $nread = sysread LOGFILE, $line, 1024;
return 0 unless $nread; # quit if we've reached the end of
the file
> $buffer->insert($buffer->get_end_iter, $line);
> return 1;
> });
Now, if what you're wanting to do is show new input when it arrives,
a la "tail" in follow mode... well, from a quick glance at the
source to GNU tail, that appears to be done by polling the file
system for size changes.
--
If the monkey could type one keystroke every nanosecond, the expected
waiting time until the monkey types out Hamlet is so long that the
estimated age of the universe is insignificant by comparison ... this
is not a practical method for writing plays.
-- Gian-Carlo Rota
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Glib::IO->add_watch and log files
Hi all.
I'm starting up an application and redirecting STDOUT with:
open STDOUT, '>', "$self->{globals}->{appdir}/app.log" or die "Can't
redirect STDOUT: $!";
$| = 1;
Then later on I'm using some code I found on the list from a while back
( modified a bit ... I suppose I broke it ... ):
my $buffer = $self->{form}->get_widget( "AppLog_TextView" )->get_buffer;
open LOGFILE, "<", "$self->{globals}->{appdir}/app.log";
$| = 1;
Glib::IO->add_watch ( fileno(LOGFILE), ['in', 'hup'], sub {
my ($fileno, $condition) = @_;
if ($condition eq 'hup') {
warn "done\n";
close LOGFILE;
return 0; # uninstall
}
my $line;
sysread LOGFILE, $line, 1024;
$buffer->insert($buffer->get_end_iter, $line);
return 1;
});
When this runs, the above subs keeps getting called ( apparently without
reading anything ... if I warn $line I get nothing ), and my app never
gets any further! What have I done?
--
Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
email: [EMAIL PROTECTED]
website: http://www.nusconsulting.com.au
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Glib::Flags boolean operators (was Re: Glib::IO->add_watch not uninstalling)
On Feb 25, 2007, at 9:46 AM, Jeffrey Ratcliffe wrote:
> On 25/02/07, muppet <[EMAIL PROTECTED]> wrote:
>> Well, TIMTOWDI, of course. :-) But, yes, the ">=" operator, which is
>> overloaded for Glib::Flags bitsets to mean the same as "&", which is
>> "are all of the flags listed on the right hand side set in the left
>> hand side?" is how i would write it.
>
> I can see that &, >= and * should be the same for this example.
>
>> The Glib::Flags operators are explained in the "This Is Now That"
>> section of the Glib manpage.
>
> But in the manpage, it implies (to me at least) that there is a
> difference between &, >= and *. Is there difference?
For a boolean test, no. & and >= are implemented differently, but *
and & are the same. The names (and operators) are derived from set
theory, but you can also use any knowledge of binary logic operations
from C.
(Warning: potentially redundant but intended-to-be complete
information follows.)
Glib.pm contains this:
package Glib::Flags;
use overload
'bool' => \&bool,
'+'=> \&union, '|'=> \&union,
'-'=> \&sub,
'>=' => \&ge,
'==' => \&eq,'eq' => \&eq, # eq for is_deeply in
Test::More
'*'=> \&intersect, '&'=> \&intersect,
'/'=> \&xor, '^'=> \&xor,
'@{}' => \&as_arrayref,
'""' => sub { "[ @{$_[0]} ]" },
fallback => 1;
Those subs are implemented essentially like this:
bool := NOT NOT a
if any of the bits in a are set, the expression evaluates to TRUE
union := a OR b
the result contains all of the bits set in a and b
that is, the result is the union of the two sets.
the | mnemonic is for the C (and Perl) bitwise OR operator.
the + mnemonic is for union of two sets -- you're adding them
together.
sub := a AND NOT b
the result contains all the bits set in a minus the bits that
were also on in b.
this is subtracting the set of b from the set of a.
the - mnemonic is awesome, because "a & ~b" is bizarre looking.
ge := (a AND b) IS b
the result is TRUE if the bits in b are on in a.
other bits may be on in a, but they are ignored (by the AND).
hence, this is true if the set of a is greater than or equal
to the set of b.
eq := a IS b
the result is TRUE iff the same set of bits are on in both.
intersect := a AND b
the result contains all of the bits that are on in both a and b.
that is, it returns the intersection of sets a and b.
the & mnemonic is the C (and Perl) bitwise AND operator.
the * mnemonic is for the intersection of two sets.
xor := a XOR b
the result contains all of the bits that are on in either or
both a and b.
the bits that are on in both are not included; this is the
exclusive or of the two sets.
the ^ mnemonic is for the C (and Perl) bitwise XOR operator.
All that said, i think the only ones i have ever used are the >= and
bool operators.
--
If the monkey could type one keystroke every nanosecond, the expected
waiting time until the monkey types out Hamlet is so long that the
estimated age of the universe is insignificant by comparison ... this
is not a practical method for writing plays.
-- Gian-Carlo Rota
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO->add_watch not uninstalling
On 25/02/07, Torsten Schoenfeld <[EMAIL PROTECTED]> wrote: > * and & return the elements that are in both sets -- evaluating this in > a bool context works because an empty set turns into false and a > non-empty set turns into true. Note that * and & are commutative: > > a * b == b * a. > > >=, on the other hand, specifically tests if the first set contains the > second set -- so >= is not commutative. Thanks! Jeff ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO->add_watch not uninstalling
On Sun, 2007-02-25 at 15:46 +0100, Jeffrey Ratcliffe wrote: > > The Glib::Flags operators are explained in the "This Is Now That" > > section of the Glib manpage. > > But in the manpage, it implies (to me at least) that there is a > difference between &, >= and *. Is there difference? * and & return the elements that are in both sets -- evaluating this in a bool context works because an empty set turns into false and a non-empty set turns into true. Note that * and & are commutative: a * b == b * a. >=, on the other hand, specifically tests if the first set contains the second set -- so >= is not commutative. -- Bye, -Torsten ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO->add_watch not uninstalling
On 25/02/07, muppet <[EMAIL PROTECTED]> wrote: > Well, TIMTOWDI, of course. :-) But, yes, the ">=" operator, which is > overloaded for Glib::Flags bitsets to mean the same as "&", which is > "are all of the flags listed on the right hand side set in the left > hand side?" is how i would write it. I can see that &, >= and * should be the same for this example. > The Glib::Flags operators are explained in the "This Is Now That" > section of the Glib manpage. But in the manpage, it implies (to me at least) that there is a difference between &, >= and *. Is there difference? Thanks for the help Jeff ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO->add_watch not uninstalling
On Feb 25, 2007, at 7:29 AM, Jeffrey Ratcliffe wrote:
> On 25/02/07, muppet <[EMAIL PROTECTED]> wrote:
>> The only thing i see is that you handle 'hup' before checking for
>> 'in'. It *is* possible to get both conditions in the same callback.
>> However, this would only result in losing the last chunk of input,
>> not a hang.
>
> This is exactly what is happening. I got him to run a modified version
> which prints the conditions, and he was getting
>
> [ in hup ]
>
> (as opposed to [ hup ], which I was getting). Of course
>
> if ($condition eq 'hup') {
>
> is then no longer true. Is
>
> if ($condition >= 'hup') {
>
> the RIght Way To Do It?
Well, TIMTOWDI, of course. :-) But, yes, the ">=" operator, which is
overloaded for Glib::Flags bitsets to mean the same as "&", which is
"are all of the flags listed on the right hand side set in the left
hand side?" is how i would write it.
The Glib::Flags operators are explained in the "This Is Now That"
section of the Glib manpage.
"eq" or "==" is rarely correct for testing Glib::Flag variables.
And, since you can get both conditions in the same callback, you need
to change the order of handling the conditions in your callback.
This idiom usually gets me where i want to go:
if condition contains "in"
read and handle data
if condition contains "write"
write data
if condition contains "hup"
close and clean up
return FALSE to stop watching
return TRUE to keep watching
Note the lack of "else"s.
--
I hate to break it to you, but magic data pixies don't exist.
-- Simon Cozens
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO->add_watch not uninstalling
On 25/02/07, muppet <[EMAIL PROTECTED]> wrote:
> The only thing i see is that you handle 'hup' before checking for
> 'in'. It *is* possible to get both conditions in the same callback.
> However, this would only result in losing the last chunk of input,
> not a hang.
This is exactly what is happening. I got him to run a modified version
which prints the conditions, and he was getting
[ in hup ]
(as opposed to [ hup ], which I was getting). Of course
if ($condition eq 'hup') {
is then no longer true. Is
if ($condition >= 'hup') {
the RIght Way To Do It?
> In an attempt to rule out perl or gtk2-perl, attached is a quick port
> of your demo to C. The comment on the first line contains the
> command needed to compile it. Please have your user compile and run
> this and report the behavior.
Thanks. I've passed it on.
Thanks for the help
Jeff
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Glib::IO->add_watch not uninstalling
On Feb 23, 2007, at 12:25 PM, Jeffrey Ratcliffe wrote: A user running FreeBSD has reported a bug that I can't personally reproduce in my gtk2-perl application. With his help, however, I have distilled it down to the attached demo. He reports that the progress bar pulses for three seconds, then CPU usage goes up to 100% and stays there. I take it, therefore, that the Glib::IO->add_watch call isn't uninstalling itself properly. On my Ubuntu Edgy and Red Hat boxes, it runs OK, i.e. after pressing the button, the progress bar pulses for three seconds and then stops. That's how it behaves for me on FC2 with glib 2.4.8 and Glib 1.080. (Yes, i haven't updated the stock copies in a while. ;-) Am I doing something wrong? The only thing i see is that you handle 'hup' before checking for 'in'. It *is* possible to get both conditions in the same callback. However, this would only result in losing the last chunk of input, not a hang. Or is there some problem with Glib::IO->add_watch under FreeBSD? That's quite possible, though i think it's more likely that it would be with either glib's main loop or with perl's signal handling. I don't have a FreeBSD box at my disposal for testing. Anyone? In an attempt to rule out perl or gtk2-perl, attached is a quick port of your demo to C. The comment on the first line contains the command needed to compile it. Please have your user compile and run this and report the behavior. iowatch.c Description: Binary data (For those playing along, i've mostly left the original perl code in comments next to the C version. It may interest you to see what level of pain you're missing by using gtk+ in perl, and how similar the C and Perl versions of the APIs really are. :-) -- If the monkey could type one keystroke every nanosecond, the expected waiting time until the monkey types out Hamlet is so long that the estimated age of the universe is insignificant by comparison ... this is not a practical method for writing plays. -- Gian-Carlo Rota ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Glib::IO->add_watch not uninstalling
A user running FreeBSD has reported a bug that I can't personally
reproduce in my gtk2-perl application. With his help, however, I have
distilled it down to the attached demo. He reports that the progress
bar pulses for three seconds, then CPU usage goes up to 100% and stays
there.
I take it, therefore, that the Glib::IO->add_watch call isn't
uninstalling itself properly. On my Ubuntu Edgy and Red Hat boxes, it
runs OK, i.e. after pressing the button, the progress bar pulses for
three seconds and then stops. Am I doing something wrong? Or is there
some problem with Glib::IO->add_watch under FreeBSD?
In the real application, the Glib::IO->add_watch call obviously reads
the output of a piped command without blocking.
Grateful for any help
Jeff
#!/usr/bin/perl
use warnings;
use strict;
use Gtk2 -init;
use Glib qw(TRUE FALSE); # To get TRUE and FALSE
my $window = new Gtk2::Window;
my $vb = new Gtk2::VBox(0, 0);
my $b = new Gtk2::Button('Pulse');
$window->signal_connect('destroy', sub {Gtk2->main_quit});
# Set up ProgressBar
my $pbar = Gtk2::ProgressBar->new;
$pbar -> set_pulse_step(.1);
$b->signal_connect('clicked', sub {
my $running = TRUE;
# Timer will run until callback returns false
my $timer = Glib::Timeout->add (100, sub { if ($running) {
$pbar->pulse;
return TRUE;
}
else {
return FALSE;
} });
my $cmd = "sleep 3";
# Interface to frontend
my $pid = open my $read, '-|', $cmd or die "can't open pipe: $!";
# Read without blocking
Glib::IO->add_watch ( fileno($read), ['in', 'hup'], sub {
my ($fileno, $condition) = @_;
if ($condition eq 'hup') {
close $read;
$running = FALSE;
return FALSE; # uninstall
}
my $line;
sysread $read, $line, 1024;
return TRUE; # continue without uninstalling
});
});
$window->add($vb);
$vb->add($pbar);
$vb->add($b);
$window->show_all();
Gtk2->main;
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Using Gtk2::Helper->add_watch() or Glib::IO->add_watch
> use Gtk2 '-init', '-threads-init'; > > Note, however, that i have not personally played with this thread- > safety stuff to any degree, so YMMV. Hmmm... I tried the following script on two environments Windows XP: Glib 1.060 Gtk2 1.060 Glib built for 2.4.2, running with 2.6.1 Gtk2 built for 2.4.9, running with 2.6.1 Debian3.1: Glib 1.082 Gtk2 1.082 Glib built for 2.6.4, running with 2.6.4 Gtk2 built for 2.6.4, running with 2.6.4 # # use strict; use warnings; use Gtk2 '-init', '-threads-init'; my $window = Gtk2::Window->new; $window->set_default_size( 400, 300 ); $window->show_all(); Gtk2->main; # # On debian, things work just fine. I see a window pop up and the whole world is in order. On win32, things are not quite so good. A window pops up but it seems to be stuck in a loop. I see the hour-glass and the ui is not responsive. Is this another win32 quirk or is the version difference causing misbehaviour ? Any ideas ? Another thing I noticed is that the script that I sent out with the previous email (without the -threads-init) works fine on both win32 and debian. But that may be just a case of "programming by coincidence" ;) _Ofey. ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Using Gtk2::Helper->add_watch() or Glib::IO->add_watch
On Aug 23, 2005, at 8:30 PM, ofey aikon wrote: That's quite possible. Win32 is infamous for its rather broken pipes. One aspect of that is that pipes and network sockets behave differently wrt select(), mostly in that pipes tend to be broken while sockets work. Well, after spending a bit more time on this, I concluded that using pipes on win32 is definitely impossible. So I decided to model the functionality that I need using threads instead. I have re-written the FAQ example to use threads instead of pipes. The inspiration of course was from muppet's code at http://mail.gnome.org/archives/gtk-perl-list/2003-November/ msg00028.html That example predates some other important developments in threading support... You want to have: use Gtk2 '-init', '-threads-init'; The -threads-init import option is equalivent to calling Gtk2::Gdk::Threads->init(). This makes the calls to Gtk2::Gdk::Threads->enter() and Gtk2::Gdk::Threads->leave() actually have effect for wrapping calls to gui functions from child threads; see the C reference docs for gdk_threads_enter() and gdk_threads_leave (). You'll also want to call Glib::Object->set_threadsafe (TRUE); before doing much of anything; this enables object tracking within the bindings, to avoid the "object destroyed out from under you" problem. The bindings must be built with thread support, which is the default. Note, however, that i have not personally played with this thread- safety stuff to any degree, so YMMV. -- And then mama would throw the live crawdads in the boilin' water. And one day I decided I'd make my own crawdads. So I threw the crawdads in the pot, but without any water. It was just like makin' popcorn. - Ear-bending cellmate, "Raising Arizona" ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Using Gtk2::Helper->add_watch() or Glib::IO->add_watch
> That's quite possible. Win32 is infamous for its rather broken > pipes. One aspect of that is that pipes and network sockets behave > differently wrt select(), mostly in that pipes tend to be broken > while sockets work. Well, after spending a bit more time on this, I concluded that using pipes on win32 is definitely impossible. So I decided to model the functionality that I need using threads instead. I have re-written the FAQ example to use threads instead of pipes. The inspiration of course was from muppet's code at http://mail.gnome.org/archives/gtk-perl-list/2003-November/msg00028.html I am attaching the code. If no one sees issues with it, I can add this as a recipe. Regards, _Ofey. thread-file-reader.pl Description: Binary data ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Using Gtk2::Helper->add_watch() or Glib::IO->add_watch
On Aug 18, 2005, at 1:06 AM, ofey aikon wrote: The FAQ however has some minor syntax errors. It's a wiki, please fix it. :-) I tried the code that muppet has posted in that thread. Somehow that quite doesn't work for me either . I'm on windoze XP. I am wondering if it has anything to do with the fact that I'm on win32. That's quite possible. Win32 is infamous for its rather broken pipes. One aspect of that is that pipes and network sockets behave differently wrt select(), mostly in that pipes tend to be broken while sockets work. I'd give more and better details but i don't have a win32 machine handy to verify my recollections. Here is the code that I'm running FYI, this code works flawlessly on Mac OS X Tiger and on Linux. -- How come hair colors for women take an hour, but "wash out the gray" stuff for men only five minutes? This is so unfair! -- Elysse, complaining about commercials ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Using Gtk2::Helper->add_watch() or Glib::IO->add_watch
* ofey aikon <[EMAIL PROTECTED]> [2005-08-18 07:10]:
> The FAQ however has some minor syntax errors. I found it being
> discussed here
> http://mail.gnome.org/archives/gtk-perl-list/2005-March/msg00107.html
Fixed.
> I am wondering if it has anything to do with the fact that I'm
> on win32.
Probably. I think the pipe-open doesn’t work on native Win32.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Using Gtk2::Helper->add_watch() or Glib::IO->add_watch
>
> http://live.gnome.org/GTK2_2dPerl_2fFrequentlyAskedQuestions#head-3b88c68683fd189b09455a462d5e41669b7b1142
Thanks !
The FAQ however has some minor syntax errors. I found it being discussed here
http://mail.gnome.org/archives/gtk-perl-list/2005-March/msg00107.html
I tried the code that muppet has posted in that thread. Somehow that
quite doesn't work for me either . I'm on windoze XP. I am wondering
if it has anything to do with the fact that I'm on win32.
The behaviour I notice is as follows. My textview buffer doesn't get
anything written into it. My command prompt gets filled with
"reading... read" messages (with no sleep in between) and it seems to
be in an infinite loop. (no stopping after 9 seconds).
Am I missing something here ? Does this have to do with buffering
related to open(FILEHANDLE, EXPR).
Here is the code that I'm running
#!/usr/bin/perl -w
use strict;
use Gtk2 -init;
my $window = Gtk2::Window->new;
my $scroll = Gtk2::ScrolledWindow->new;
my $textview = Gtk2::TextView->new;
my $buffer = $textview->get_buffer;
$window->add ($scroll);
$scroll->add ($textview);
$window->show_all;
$window->signal_connect (destroy => sub { Gtk2->main_quit });
open(IN, q^perl -e '$|++; for $i (0..9) { $sum+= $i; print "Line $i:
sum = $sum\n"; sleep 1;}'|^)
or die "Failed running perl subprocess\n";
Glib::IO->add_watch ( fileno(IN), ['in', 'hup'], sub {
my ($fileno, $condition) = @_;
if ($condition eq 'hup') {
warn "done\n";
close IN;
return 0; # uninstall
}
warn "reading...\n";
my $line;
sysread IN, $line, 1024;
warn "read $line\n";
$buffer->insert($buffer->get_end_iter, $line);
return 1;
});
Gtk2->main;
Thanks,
_Ofey.
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Using Gtk2::Helper->add_watch() or Glib::IO->add_watch
* ofey aikon <[EMAIL PROTECTED]> [2005-08-17 08:25]:
> Unfortunately, the docs for these APIs didn't help me too much.
> Google search didn't return much either. Any good samaritan
> here willing to share some code snippets on how to achieve this
> ;) ?
http://live.gnome.org/GTK2_2dPerl_2fFrequentlyAskedQuestions#head-3b88c68683fd189b09455a462d5e41669b7b1142
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Using Gtk2::Helper->add_watch() or Glib::IO->add_watch
I am trying to build the functionality where my app issues an sql statement and constantly updates a progressbar (or some other form of feedback) while the sql is being executed by the database. I know this has been discussed here before and one of the solutions was to fork the sql execution into a separate "thread" using Gtk2::Helper->add_watch() or Glib::IO->add_watch. Unfortunately, the docs for these APIs didn't help me too much. Google search didn't return much either. Any good samaritan here willing to share some code snippets on how to achieve this ;) ? I promise to add a recipe for this once I figure it out with a lil' help from you folks. Thanks, _Ofey ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
