From gavin.brock@nssmb.com

Created by zaragoza@usa.net

The following code fails​:

package Foo;
use IO​::Socket;
use base qw(IO​::Socket​::INET);

sub new {
  my ($pack,$tk) = @​_;
  my $obj = $pack->SUPER​::new(Proto => 'udp');

  $$obj->{Foo_prop1} = "value1"; # OK, foo's property
  $tk->fileevent($obj, 'readable', sub {warn "FooBar"});

  ## The above line badly ties the object,
  ## so the following line fails
  $$obj->{Foo_prop2} = "value2";

  return $obj;
}

package main;
my $tk = Tk​::MainWindow->new();
my $foo = Foo->new($tk);
Tk​::MainLoop;

Error​:
  Can't locate object method "FETCH" via package "Tk​::Event​::IO" at ./test.pl line 14.

I can work arroun this, by duping my $obj as a IO​::Handle, but it's ugly. Why
does Tk tie my $obj without asking?

Cheers, Gavin

Site configuration information for perl 5.00503:

Configured by jonathon at Tue Mar 30 09:51:19 JST 1999.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
    osname=solaris, osvers=2.5.1, archname=sun4-solaris
    uname='sunos pueblo 5.5.1 generic_103640-22 sun4u sparc sunw,ultra-1 '
    hint=previous, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
    cc='gcc', optimize='-O', gccversion=2.8.1
    cppflags='-DPURIFY -DPACK_MALLOC -DTWO_POT_OPTIMIZE -I/usr/local/include'
    ccflags ='-DPACK_MALLOC -DTWO_POT_OPTIMIZE -I/usr/local/include'
    stdchar='unsigned char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib'
    libpth=/lib /usr/lib /usr/ccs/lib /usr/local/lib
    libs=-lsocket -lnsl -ldl -lm -lc -lcrypt
    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00503:
    /home/user/gb83196/perl/lib/
    /home/sb/perl5.005/sparc-sunos5/lib
    /home/sb/perl5.005/share/lib
    /home/sb/perl5.005/sparc-sunos5/lib/site_perl
    /home/sb/perl5.005/sparc-sunos5/lib/site_perl/ph
    /home/sb/perl5.005/share/lib/site_perl
    .


Environment for perl 5.00503:
    HOME=/home/user/gb83196
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/home/user/gb83196/rvplayer:/usr/dt/lib
    LOGDIR (unset)
    PATH=/usr/dt/bin:/usr/openwin/bin:/usr/bin:/usr/ccs/bin:/usr/ucb:/usr/local/bin:/usr/share/local/bin:/opt/bin:/home/sb/perl5.005/share/bin:/home/sb/perl5.005/sparc-sunos5/bin:/usr/sbin
    PERLLIB=/home/user/gb83196/perl/lib/
    PERL_BADLANG (unset)
    SHELL=/home/user/gb83196/bin/sun5/tcsh

From [Unknown Contact. See original ticket]

Gavin Brock <zaragoza@​usa.net> writes​:

This is a bug report for perl from zaragoza@​usa.net,
generated with the help of perlbug 1.26 running under perl 5.00503.

-----------------------------------------------------------------
[Please enter your report here]

The following code fails​:

package Foo;
use IO​::Socket;
use base qw(IO​::Socket​::INET);

sub new {
my ($pack,$tk) = @​_;
my $obj = $pack->SUPER​::new(Proto => 'udp');

$$obj->{Foo_prop1} = "value1"; # OK, foo's property
$tk->fileevent($obj, 'readable', sub {warn "FooBar"});

## The above line badly ties the object,

It does not "badly tie" it it ties it with TIEHANDLE.

I can work arroun this, by duping my $obj as a IO​::Handle, but it's ugly.

You could also work round it by defining :

sub Tk​::Event​::IO​::FETCH
{
my ($globref,$key) = @​_;
...
}

Why
does Tk tie my $obj

So that​:
A. if you close() the handle I get a chance to remove the thing
  from data structures before Tk crashes due to access to no longer
  valid file handle.
B. if you attempt to read() more than is there I can
  despatch Tk events while waiting.

without asking?

So what should I do ? - popup a dialogue

  ->messageBox(-message => "May I tie $obj", -type => 'YesNo')
 

You have (via the fileevent call) "given" the object to Tk.
So you "asked me" to "look after this object" ;-)

From [Unknown Contact. See original ticket]

Nick Ing-Simmons writes​:

## The above line badly ties the object,

It does not "badly tie" it it ties it with TIEHANDLE.

Which is not expected, thus bad.

I can work arroun this, by duping my $obj as a IO​::Handle, but it's ugly.

You could also work round it by defining :

sub Tk​::Event​::IO​::FETCH
{

If so, this should have been done by Tk itself. But I doubt it.

  $tk->fileevent($obj, 'readable', sub {warn "FooBar"});

$obj is probably a glob ref, right?

  $$obj->{Foo_prop1} = "value1";

$obj is a hash ref ref, right? I'm confused.

Unles a glob can work as a hash ref in the above syntax, and you tie
the glob ref instead of the glob.

Ilya

From [Unknown Contact. See original ticket]

Ilya Zakharevich <ilya@​math.ohio-state.edu> writes​:

Nick Ing-Simmons writes​:

## The above line badly ties the object,

It does not "badly tie" it it ties it with TIEHANDLE.

Which is not expected, thus bad.

fileevent is passed a filehandle - it happens to implement its
behaviour by tie-ing that handle.

I can work arroun this, by duping my $obj as a IO​::Handle, but it's ugly.

You could also work round it by defining :

sub Tk​::Event​::IO​::FETCH
{

If so, this should have been done by Tk itself.

Why - Tk was expecting to be passed a file handle (globref) - it was not
expecting calling code to be messing with glob elements via that ref.
FETCH would presumably have to handle SCALAR, ARRAY and HASH elements of
the glob - I was not even aware that tie'ing the glob (as a HANDLE)
has any effects on the other elements.

$tk->fileevent($obj, 'readable', sub {warn "FooBar"});

$obj is probably a glob ref, right?

Yes.

$$obj->{Foo_prop1} = "value1";

$obj is a hash ref ref, right? I'm confused.

Unles a glob can work as a hash ref in the above syntax, and you tie
the glob ref instead of the glob.

I assumed that syntax is messing with the hash part of the glob via
the reference. Doing that is asking for trouble when multiple modules
are involved (IO​::Socket, Tk​::Event​::IO, ...) and user has found that
trouble ;-)

From [Unknown Contact. See original ticket]

On Sat, May 13, 2000 at 10​:41​:15AM +0100, Nick Ing-Simmons wrote​:

It does not "badly tie" it it ties it with TIEHANDLE.

Which is not expected, thus bad.

fileevent is passed a filehandle - it happens to implement its
behaviour by tie-ing that handle.

You could also work round it by defining :

sub Tk​::Event​::IO​::FETCH
{

If so, this should have been done by Tk itself.

Why - Tk was expecting to be passed a file handle (globref) - it was not
  ^^^^^^^
expecting calling code to be messing with glob elements via that ref.
  ^^^^^^^^^

... and *this* is a bug.

If Tk meeds messing with the FH, it should be messing with IO part of the
glob, not with the glob as a whole.

Ilya

From [Unknown Contact. See original ticket]

Ilya Zakharevich <ilya@​math.ohio-state.edu> writes​:

On Sat, May 13, 2000 at 10​:41​:15AM +0100, Nick Ing-Simmons wrote​:

It does not "badly tie" it it ties it with TIEHANDLE.

Which is not expected, thus bad.

fileevent is passed a filehandle - it happens to implement its
behaviour by tie-ing that handle.

You could also work round it by defining :

sub Tk​::Event​::IO​::FETCH
{

If so, this should have been done by Tk itself.

Why - Tk was expecting to be passed a file handle (globref) - it was not
^^^^^^^
expecting calling code to be messing with glob elements via that ref.
^^^^^^^^^

... and *this* is a bug.

If Tk meeds messing with the FH, it should be messing with IO part of the
glob, not with the glob as a whole.

Ok. But as far as I am aware you have to pass a glob to tie to achieve
TIEHANDLE behaviour.

What I have at present is​:

sub fileevent
{
my ($widget,$file,$mode,$cb) = @​_;
my $imode = imode($mode);
unless (ref $file)
  {
  no strict 'refs';
  $file = Symbol​::qualify($file,(caller)[0]);
  $file = \*{$file};
  }
my $obj = tied(*$file);
$obj = tie *$file,'Tk​::Event​::IO', $file unless $obj && $obj->isa('Tk​::Event​::IO');
if (@​_ == 3)
  {
  return $obj->handler($imode);
  }
else
  {
  my $h = $obj->handler($imode,$cb);
  undef $obj;
  untie *$file unless $h;
  }
}

I will gladly change that to any incantation which will effect a tie
of the incoming HANDLE so that I can intercept close(), readline()
read() etc.

From [Unknown Contact. See original ticket]

On Sat, May 13, 2000 at 02​:59​:37PM +0100, Nick Ing-Simmons wrote​:

If Tk meeds messing with the FH, it should be messing with IO part of the
glob, not with the glob as a whole.

Ok. But as far as I am aware you have to pass a glob to tie to achieve
TIEHANDLE behaviour.

Then *this* is a bug. ;-) Or if it is not, the fact that
tiehandle()ing messes the SCALAR etc. parts is a bug.

my $obj = tied(*$file);
$obj = tie *$file,'Tk​::Event​::IO', $file unless $obj && $obj->isa('Tk​::Event​::IO');

No warning on re-tie()ing? [Not that it will help in the discussed case...]

Ilya

From [Unknown Contact. See original ticket]

Ilya Zakharevich (lists.p5p)​:

Then *this* is a bug. ;-)

I seriously hate to say this, but in the past two days you have
identified seven bugs and fixed zero.

From [Unknown Contact. See original ticket]

Simon Cozens writes​:

Then *this* is a bug. ;-)

I seriously hate to say this, but in the past two days you have
identified seven bugs and fixed zero.

And your point is "So shut up"? Sorry, but you need to have more
credentials that what you have for me to listen to such an advice.

And BTW, this is going to continue. I'm not interested much in perl
development any more. And I do not consider this as *my* fault.

Hope this helps,
Ilya

From [Unknown Contact. See original ticket]

Nick, Ilya,

I sent a reply on this thread a while back, but it seems to have
disappeared. The highlight was that when I defined my own
Tk​::Event​::IO​::FETCH sub, it turned out that is was the scalar tie fetch
(not the hash one) that was being called. Once this was defined "sub
Tk​::Event​::IO​::Fetch { $_[0] }" all worked fine under 5.005. No other
function (eg STORE) were required.

However, I then tested under 5.6.0, when I tried to access the hash key in
the DESTROY sub, I got the following​:

(in cleanup) Can't call method "FETCH" on an undefined value at test.pl
line 21 during global destruction.

Below is the perl-bug output for my 5.6 build.

Cheers,

Gavin

Flags:
    category=core
    severity=low

Site configuration information for perl v5.6.0:

Configured by jonathon at Tue Apr 18 15:42:45 JST 2000.

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
    osname=solaris, osvers=2.5.1, archname=sun4-solaris
    uname='sunos pueblo 5.5.1 generic_103640-31 sun4u sparc sunw,ultra-2
'
    config_args=''
    hint=previous, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define
    use64bitint=undef use64bitall=undef uselongdouble=undef
usesocks=undef
  Compiler:
    cc='gcc', optimize='-O', gccversion=2.95.2 19991024 (release)
    cppflags='-DPACK_MALLOC -DTWO_POT_OPTIMIZE -fno-strict-aliasing
-I/usr/local/include'
    ccflags ='-DPACK_MALLOC -DTWO_POT_OPTIMIZE -fno-strict-aliasing
-I/usr/local/include'
    stdchar='unsigned char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=4
    alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags ='-L/usr/local/lib -R/usr/local/lib '
    libpth=/lib /usr/lib /usr/ccs/lib /usr/local/lib
    libs=-lsocket -lnsl -ldb -ldl -lm -lc -lcrypt -lsec
    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib -R/usr/local/lib'

Locally applied patches:



@INC for perl v5.6.0:
    /home/user/gb83196/perl/lib/
    /opt/perl5.6/lib/5.6.0/sun4-solaris
    /opt/perl5.6/lib/5.6.0
    /opt/perl5.6/lib/site_perl/5.6.0/sun4-solaris
    /opt/perl5.6/lib/site_perl/5.6.0
    /opt/perl5.6/lib/site_perl
    .


Environment for perl v5.6.0:
    HOME=/home/user/gb83196
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/home/user/gb83196/rvplayer:/usr/dt/lib
    LOGDIR (unset)

PATH=/home/user/gb83196/bin:/home/sb/teknekron/tss_root/rel_s4_5x/bin:/usr/d
t/bin:/usr/openwin/bin:/usr/bin:/usr/ccs/bin:/usr/ucb:/usr/local/bin:/usr/sh
are/local/bin:/opt/bin:.:/home/user/gb83196/bin:/home/user/gb83196/private-b
in:/home/sb/perl5.005/share/bin:/home/sb/perl5.005/sparc-sunos5/bin:/usr/sbi
n:/xenv/java/sun4/5.x/1.1.3/bin:/home/user/gb83196/rvplayer
    PERLLIB=/home/user/gb83196/perl/lib/
    PERL_BADLANG (unset)
    SHELL=/home/user/gb83196/bin/sun5//tcsh

From [Unknown Contact. See original ticket]

On Sun, May 14, 2000 at 11​:12​:56PM +0900, Gavin Brock wrote​:

I sent a reply on this thread a while back, but it seems to have
disappeared. The highlight was that when I defined my own
Tk​::Event​::IO​::FETCH sub, it turned out that is was the scalar tie fetch
(not the hash one) that was being called. Once this was defined "sub
Tk​::Event​::IO​::Fetch { $_[0] }" all worked fine under 5.005. No other
function (eg STORE) were required.

Here is the problem​:

perl -MDevel​::Peek -wle "sub a​::TIEHANDLE {bless []} tie *x,'a'; Dump \*x"
SV = RV(0x5b814) at 0x40c94
  REFCNT = 1
  FLAGS = (TEMP,ROK)
  RV = 0x319d0
  SV = PVGV(0x3e7c0) at 0x319d0
  REFCNT = 4
  FLAGS = (GMG,SMG,RMG,MULTI)
  IV = 0
  NV = 0
  MAGIC = 0x84518
  MG_VIRTUAL = &vtbl_packelem
  [...]

There is no reason why this tie should have set SMG and RMG flags.

Ilya

From @chorny

On perl 5.14.0, output is "FLAGS = (MULTI,IN_PAD)" and example from the
first message of ticket does not die.

On Sun May 14 02​:48​:14 2000, RT_System wrote​:

On Sun, May 14, 2000 at 11​:12​:56PM +0900, Gavin Brock wrote​:

I sent a reply on this thread a while back, but it seems to have
disappeared. The highlight was that when I defined my own
Tk​::Event​::IO​::FETCH sub, it turned out that is was the scalar tie fetch
(not the hash one) that was being called. Once this was defined "sub
Tk​::Event​::IO​::Fetch { $_[0] }" all worked fine under 5.005. No other
function (eg STORE) were required.

Here is the problem​:

perl -MDevel​::Peek -wle "sub a​::TIEHANDLE {bless []} tie *x,'a'; Dump \*x"
SV = RV(0x5b814) at 0x40c94
REFCNT = 1
FLAGS = (TEMP,ROK)
RV = 0x319d0
SV = PVGV(0x3e7c0) at 0x319d0
REFCNT = 4
FLAGS = (GMG,SMG,RMG,MULTI)
IV = 0
NV = 0
MAGIC = 0x84518
MG_VIRTUAL = &vtbl_packelem
[...]

There is no reason why this tie should have set SMG and RMG flags.

Ilya

--
Alexandr Ciornii, http​://chorny.net

@iabyn - Status changed from 'open' to 'resolved'

From gavin@brock-family.org

Thanks Alexandr, never expect to see this old one show up again!! Have
to go and find out why I wanted it again...