[23807] in Perl-Users-Digest
Perl-Users Digest, Issue: 6010 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 29 19:46:25 2004
Date: Thu, 29 Jan 2004 16:45:41 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 29 Jan 2004 Volume: 10 Number: 6010
Today's topics:
Re: How to use select (select(2)) in Perl? <bernie@fantasyfarm.com>
Re: How to use select (select(2)) in Perl? <usenet@morrow.me.uk>
Re: How to use select (select(2)) in Perl? (Kenny McCormack)
Re: How to use select (select(2)) in Perl? <uri@stemsystems.com>
Re: How to use select (select(2)) in Perl? <bernie@fantasyfarm.com>
Re: How to use select (select(2)) in Perl? <usenet@morrow.me.uk>
Re: How to use select (select(2)) in Perl? <bernie@fantasyfarm.com>
Re: How to use select (select(2)) in Perl? <usenet@morrow.me.uk>
Re: How to use select (select(2)) in Perl? <bernie@fantasyfarm.com>
Re: How to use select (select(2)) in Perl? <tassilo.parseval@rwth-aachen.de>
Re: How to use select (select(2)) in Perl? <usenet@morrow.me.uk>
Re: How to use select (select(2)) in Perl? <bernie@fantasyfarm.com>
Re: How to use select (select(2)) in Perl? <bernie@fantasyfarm.com>
Re: How to use select (select(2)) in Perl? <usenet@morrow.me.uk>
Re: How to use select (select(2)) in Perl? <usenet@morrow.me.uk>
Re: How to use select (select(2)) in Perl? <tassilo.parseval@rwth-aachen.de>
Re: How to use select (select(2)) in Perl? <usenet@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 21 Jan 2004 10:20:42 -0500
From: Bernie Cosell <bernie@fantasyfarm.com>
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <pv5t001ods6hsq6earl2s2gsm15777j6qt@library.airnews.net>
Ben Morrow <usenet@morrow.me.uk> wrote:
} Joe Smith <Joe.Smith@inwap.com> wrote:
} > Kenny McCormack wrote:
} >
} > > I think the documentation of select() is cryptic even by Perl standards.
} >
} > I agree. Back in the days of perl4, the docs for many functions
} > basically said "works like the function with the same name in the
} > C library". There was no need to duplicate what was in the man
} > pages since everyone who had perl had access to the `man` command.
} >
} > Nowadays there are many users that have `perldoc` but not `man`.
} > Not all the PODs have been rewritten to be complete enough to
} > stand alone.
}
} The only needed addition is 'do not use this, use IO::Select instead'.
I disagree -- perhaps *AFTER* you clearly document how it actually works
and how it is supposed to be used you could refer users to IO::Select, but
having a ref like that in *place* of documenting the machinery just ain't
right, IMO [even disregarding that you could always read the code in the
module and try to puzzle out how it works and what it is doing -- I'll note
that it was basically impossible [probably still is] to figure out quite
how "use vars" works -- the necessary tricks [which I can't even remember]
just aren't documented, and reading the code for 'use vars' doesn't reveal
the magic [I had to ask here and someone explained it, but I've forgotten
and I'll *bet* that that bit of lore hasn't made it into any of the docs].
I'd prefer that there were _fewer_ "this is magic, use the module" parts of
Perl rather than more...
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
bernie@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
Date: Wed, 21 Jan 2004 18:55:03 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <bumhu7$9ei$1@wisteria.csv.warwick.ac.uk>
Bernie Cosell <bernie@fantasyfarm.com> wrote:
> Ben Morrow <usenet@morrow.me.uk> wrote:
> }
> } The only needed addition is 'do not use this, use IO::Select instead'.
>
> I disagree -- perhaps *AFTER* you clearly document how it actually works
> and how it is supposed to be used you could refer users to
> IO::Select,
The point is that it *isn't* supposed to be used. Since IO::Select was
made core, the select function it is based on should really be
considered internal to that module.
> but having a ref like that in *place* of documenting the machinery
> just ain't right, IMO
So do you want documentation on how 'use strict' works, or
Filter::Util::Call? The point of these modules is that you don't need
to know how the internals work.
> I'll note that it was basically impossible [probably still is] to
> figure out quite how "use vars" works -- the necessary tricks [which
> I can't even remember] just aren't documented, and reading the code
> for 'use vars' doesn't reveal the magic
Ummm.... as far as I can see it's perfectly clear. 'use vars
qw/$foo/;' (called from package 'My::Pack') chops the '$' off '$foo',
makes sure it's fully qualified, does some error checking and then
executes
*My::Pack::foo = \$My::Pack::foo;
. The reason why this stops the error is not explained anywhere in the
perl docs, I grant you, but it isn't hard to figure out. strict 'vars'
gives an error for a given package variable iff it doesn't already
exist in the symbol table (at compile time). The expression above
causes the entry for $My::Pack::foo to be created; as it's happening
in a 'use' statement, code that is after it in the file will be
compiled with that variable existing.
At the risk of sounding arrogant, I would say that if you can't work
that out for yourself you are better off not knowing it. Hell, I
worked that out for myself and *I'd* probably be better off not
knowing it: certainly, I avoid using that knowledge whenever I can
(basically, always).
> I'd prefer that there were _fewer_ "this is magic, use the module"
> parts of Perl rather than more...
The point is that core modules like 'strict', 'vars', 'IO::Select' and
'IO::Socket' should be considered part of the Perl language, in the
same way as stdio is considered part of C. You do not need to know how
they work, just as you do not need to know how perly.c works.
If you want to find out, feel free to read the source and do so, and I
for one will be more than happy to tell you what I know (which isn't
much); but be careful to distinguish between 'finding out how the
internals work for curiosity's sake' and 'finding out how the
documented interface works for the sake of using it'.
Ben
--
Musica Dei donum optimi, trahit homines, trahit deos. |
Musica truces mollit animos, tristesque mentes erigit. | ben@morrow.me.uk
Musica vel ipsas arbores et horridas movet feras. |
------------------------------
Date: Thu, 22 Jan 2004 00:10:37 GMT
From: gazelle@yin.interaccess.com (Kenny McCormack)
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <bun4pr$d4$1@yin.interaccess.com>
In article <pv5t001ods6hsq6earl2s2gsm15777j6qt@library.airnews.net>,
Bernie Cosell <bernie@fantasyfarm.com> wrote:
>Ben Morrow <usenet@morrow.me.uk> wrote:
>
>} Joe Smith <Joe.Smith@inwap.com> wrote:
>} > Kenny McCormack wrote:
>} >
>} > > I think the documentation of select() is cryptic even by Perl standards.
>} >
>} > I agree. Back in the days of perl4, the docs for many functions
>} > basically said "works like the function with the same name in the
>} > C library". There was no need to duplicate what was in the man
>} > pages since everyone who had perl had access to the `man` command.
>} >
>} > Nowadays there are many users that have `perldoc` but not `man`.
>} > Not all the PODs have been rewritten to be complete enough to
>} > stand alone.
>}
>} The only needed addition is 'do not use this, use IO::Select instead'.
>
>I disagree -- perhaps *AFTER* you clearly document how it actually works
>and how it is supposed to be used you could refer users to IO::Select, but
>having a ref like that in *place* of documenting the machinery just ain't
>right.
Gee, a voice of reason. You obviously don't belong in this newsgroup.
The very idea that the paragraph you wrote above could be considered
controversial is proof that this newsgroup really is populated by lunatics.
------------------------------
Date: Thu, 22 Jan 2004 04:16:04 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <x7ptdcaa9o.fsf@mail.sysarch.com>
>>>>> "KM" == Kenny McCormack <gazelle@yin.interaccess.com> writes:
KM> In article <pv5t001ods6hsq6earl2s2gsm15777j6qt@library.airnews.net>,
KM> Bernie Cosell <bernie@fantasyfarm.com> wrote:
>>
>> I disagree -- perhaps *AFTER* you clearly document how it actually works
>> and how it is supposed to be used you could refer users to IO::Select, but
>> having a ref like that in *place* of documenting the machinery just ain't
>> right.
KM> Gee, a voice of reason. You obviously don't belong in this
KM> newsgroup. The very idea that the paragraph you wrote above could
KM> be considered controversial is proof that this newsgroup really is
KM> populated by lunatics.
that doesn't change the fact that you are a maroon. just reading about
select which refers to the vec function and then not reading about vec
is proof. you hate perl so why do you even bother? we don't need your
<SARCASM>sanity</SARCASM> here.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Sun, 25 Jan 2004 12:36:17 -0500
From: Bernie Cosell <bernie@fantasyfarm.com>
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <o9u710d2nh3rei0ffa3m74jqajcrt6gujf@library.airnews.net>
Ben Morrow <usenet@morrow.me.uk> wrote:
}
} Bernie Cosell <bernie@fantasyfarm.com> wrote:
} > I'll note that it was basically impossible [probably still is] to
} > figure out quite how "use vars" works -- the necessary tricks [which
} > I can't even remember] just aren't documented, and reading the code
} > for 'use vars' doesn't reveal the magic
}
} Ummm.... as far as I can see it's perfectly clear. 'use vars
} qw/$foo/;' (called from package 'My::Pack') chops the '$' off '$foo',
} makes sure it's fully qualified, does some error checking and then
} executes
}
} *My::Pack::foo = \$My::Pack::foo;
Actually, that leaves something out -- I think you have to be in a
different package assigning into the original or something like that. I
tried to do a in-line use-vars and there was some [undocumented]
packageness requirement [if I remember right] or else the * = \ assignment
didn't turn off the error...
} . The reason why this stops the error is not explained anywhere in the
} perl docs, I grant you, but it isn't hard to figure out.
Oh? Consider:
use strict ;
*main::c = \$main::c;
$c = 4 ;
Will that compile and run or not?
[SPOILER:
$ perl test.pl
Variable "$c" is not imported at test.pl line 6.
Global symbol "$c" requires explicit package name at test.pl line 6.
Execution of test.pl aborted due to compilation errors.
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
bernie@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
Date: Sun, 25 Jan 2004 18:22:53 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <bv11ht$cod$2@wisteria.csv.warwick.ac.uk>
Bernie Cosell <bernie@fantasyfarm.com> wrote:
> Ben Morrow <usenet@morrow.me.uk> wrote:
>
> } Ummm.... as far as I can see it's perfectly clear. 'use vars
> } qw/$foo/;' (called from package 'My::Pack') chops the '$' off '$foo',
> } makes sure it's fully qualified, does some error checking and then
> } executes
> }
> } *My::Pack::foo = \$My::Pack::foo;
>
> Actually, that leaves something out -- I think you have to be in a
> different package assigning into the original or something like that. I
> tried to do a in-line use-vars and there was some [undocumented]
> packageness requirement [if I remember right] or else the * = \ assignment
> didn't turn off the error...
Yes, OK, you are right. I had forgotten that. The assignment has to
occur in a different package from that which you are assigning into.
> } . The reason why this stops the error is not explained anywhere in the
> } perl docs, I grant you, but it isn't hard to figure out.
>
> Oh? Consider:
>
> use strict ;
>
> *main::c = \$main::c;
> $c = 4 ;
>
> Will that compile and run or not?
You have missed the most important part of my explanation: as the
*foo=\$foo is happening in a BEGIN block (or rather a 'use'
statement), it happens at *compile* *time*, and thus its effects are
present for the rest of the compilation.
Consider:
use strict;
BEGIN {
package Foo;
*main::c = \$main::c
}
$c = 4;
The fact that this incantation is what is required to turn off the
error is indeed undocumented, but that simply means *you do not need
to know it*. The documented means for avoiding strict warnings are my,
our and use vars.
Do you understand the meaning of 'modularity' with respect to software
design?
Ben
--
Every twenty-four hours about 34k children die from the effects of poverty.
Meanwhile, the latest estimate is that 2800 people died on 9/11, so it's like
that image, that ghastly, grey-billowing, double-barrelled fall, repeated
twelve times every day. Full of children. [Iain Banks] ben@morrow.me.uk
------------------------------
Date: Mon, 26 Jan 2004 14:56:34 -0500
From: Bernie Cosell <bernie@fantasyfarm.com>
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <28qa10phdsrkd05j9fbt3cot6ejq6uf73a@library.airnews.net>
Ben Morrow <usenet@morrow.me.uk> wrote:
} Bernie Cosell <bernie@fantasyfarm.com> wrote:
} > Ben Morrow <usenet@morrow.me.uk> wrote:
} >
} > } Ummm.... as far as I can see it's perfectly clear. 'use vars
} > } qw/$foo/;' (called from package 'My::Pack') chops the '$' off '$foo',
} > } makes sure it's fully qualified, does some error checking and then
} > } executes
} > }
} > } *My::Pack::foo = \$My::Pack::foo;
} >
} > Actually, that leaves something out -- I think you have to be in a
} > different package assigning into the original or something like that. I
} > tried to do a in-line use-vars and there was some [undocumented]
} > packageness requirement [if I remember right] or else the * = \ assignment
} > didn't turn off the error...
}
} Yes, OK, you are right. I had forgotten that. The assignment has to
} occur in a different package from that which you are assigning into.
That was my point: WHERE EXACTLY is that documented?? How did you learn
that little tidbit to have forgotten it???
} You have missed the most important part of my explanation:
No, I didn't -- the part of your explanation that actually bore on my
question, and that qualifies as an arrogant Lucy science lecture was this:
>>> The reason why this stops the error is not explained anywhere in the
>>> perl docs, I grant you, but it isn't hard to figure out. strict 'vars'
>>> gives an error for a given package variable iff it doesn't already
>>> exist in the symbol table (at compile time). The expression above
>>> causes the entry for $My::Pack::foo to be created; as it's happening
>>> in a 'use' statement, code that is after it in the file will be
>>> compiled with that variable existing.
Very tidy, and very wrong.. there's something *ELSE* afoot beyond just
"causes the entry...to be created". As for the example I gave, that was
just a slip -- put what I gave you into a BEGIN block and it fails as well:
/tmp$ cat test.pl
#!/usr/bin/perl -w
use strict ;
BEGIN
{ *main::c = \$main::c; }
$c = 4 ;
/tmp$ perl test.pl
Variable "$c" is not imported at test.pl line 6.
Global symbol "$c" requires explicit package name at test.pl line 6.
Execution of test.pl aborted due to compilation errors.
The *real* key part is the hidden, undocumented secret, which is that the
magic only works *across*packages*. If your rather patronizing explanation
was actually correct, which it is not, then what I wrote above would have
worked... but it doesn't.
I haven't a clue *WHY* perl requires that, or why *HOW* you create the
symtab entry makes a difference to the 'strict' machinery, but a while back
[when I needed to write my own version of 'use vars'] it was VERY
frustrating not being able to find that bit of lore. You're trying to
argue that it is a *good*thing* to leave stuff like that undocumented?
} Do you understand the meaning of 'modularity' with respect to software
} design?
Sure do -- and it has nothing to do with what's going on here. Same thing
with GetOpt - I use it when it fits what my application needs, but I mess
with ARGV directly when I have to. Ditto, recently, with Mail::POP3Client
-- it didn't do what I needed, and so instead of warping my program'
functionality to fit the library, I wrote a module that did *exactly* what
I needed... I don't understand your point.
And back to the topic of this thread, what's non-modular about wanting
things to be properly documented? Even if IO::Select does *exactly* what
you want, how is it a good thing not to document the underlying machinery
properly?
IMO, only the most myopic and narrow-minded of folk [mostly brainwashed
from having taken too many undergraduate "object oriented programming"
classes, I suspect] really believe that there's only ONE way to do any
task, and when "the right way" is enshrined in some kind of
library/module/package that that then becomes the ONLY way anyone
is/shouldbe permitted to do it. Just because I'm doing a task that
involves select() but I don't use IO::Select to do it doesn't mean that my
code isn't modular. FEH!
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
bernie@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
Date: Mon, 26 Jan 2004 20:55:49 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <bv3usl$ib9$1@wisteria.csv.warwick.ac.uk>
Bernie Cosell <bernie@fantasyfarm.com> wrote:
> Ben Morrow <usenet@morrow.me.uk> wrote:
> } Yes, OK, you are right. I had forgotten that. The assignment has to
> } occur in a different package from that which you are assigning into.
>
> That was my point: WHERE EXACTLY is that documented?? How did you learn
> that little tidbit to have forgotten it???
It is not documented. It is perl internals. Do you know what all the
various values of $^H do? Where are they documented? They aren't: they
are private between perl and the core pragmas, and subject to change
at any time without notice. The same applies to this: p5p are
perfectly entitled to change this behaviour at any time, without
warning, as long as use vars continues to work.
This is what I mean by 'modularity'. use vars is *not* a library: it
is part of the language. The same goes for IO::*.
As for where I learnt it, it's kinda obvious from the
message. "Variable "$x" is not imported": hence, if it had been
imported, it would have been OK; what is the difference between
importing a variable and what you wrote? That an import occurs in the
package the variable is imported from.
> I haven't a clue *WHY* perl requires that, or why *HOW* you create the
> symtab entry makes a difference to the 'strict' machinery, but a while back
> [when I needed to write my own version of 'use vars'] it was VERY
> frustrating not being able to find that bit of lore. You're trying to
> argue that it is a *good*thing* to leave stuff like that
> undocumented?
Yes, I am, because it is subject to change. If p5p change that
behaviour, it is likely your use vars will cease to work. [The fact
that the behaviour probably can't be changed for other reasons is
beside the point...] Why did you need to rewrite use vars anyway,
especially in such a way that it was doing the importing from the
receiving package?
> } Do you understand the meaning of 'modularity' with respect to software
> } design?
>
> Sure do -- and it has nothing to do with what's going on here. Same thing
> with GetOpt - I use it when it fits what my application needs, but I mess
> with ARGV directly when I have to.
Right. ARGV is documented, so feel free to do what you like with it.
> I don't understand your point.
Things that are undocumented are undocumented because they are not for
public use. Indeed, plenty of things are documented, but should not be
used because they are private to perl, for instance the SvIOKp flag on
a scalar.
> IMO, only the most myopic and narrow-minded of folk [mostly brainwashed
> from having taken too many undergraduate "object oriented programming"
> classes, I suspect]
Myopic I may be (-10 and -12 dioptres, with astigmatism :), but I am
not narrow-minded; and I have *certainly* never taken an undergraduate
OOP class.
Ben
--
I've seen things you people wouldn't believe: attack ships on fire off the
shoulder of Orion; I've watched C-beams glitter in the darkness near the
Tannhauser Gate. All these moments will be lost, in time, like tears in rain.
Time to die. |-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-| ben@morrow.me.uk
------------------------------
Date: Tue, 27 Jan 2004 06:39:35 -0500
From: Bernie Cosell <bernie@fantasyfarm.com>
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <vhhc101fugrdumi4mv312mt7usbt0v7sba@library.airnews.net>
Ben Morrow <usenet@morrow.me.uk> wrote:
} Bernie Cosell <bernie@fantasyfarm.com> wrote:
} > Ben Morrow <usenet@morrow.me.uk> wrote:
I notice that you skipped over the comment about your patronizing Lucy
science lecture: indeed, I had done that same analysis (which is hardly
difficult) and STILL couldn't figure out why use vars worked but the
version I needed wouldn't.
} > } Yes, OK, you are right. I had forgotten that. The assignment has to
} > } occur in a different package from that which you are assigning into.
} >
} > That was my point: WHERE EXACTLY is that documented?? How did you learn
} > that little tidbit to have forgotten it???
}
} It is not documented. It is perl internals.
Perhaps -- odd argument, I think. What *IS* someone supposed to do if 'use
vars' doesn't do quite what they want? Is that really some deep secret
part of the system in your view? [and it still leaves me a bit mystified
as to WHY the simple global-assignment doesn't work, but the
global-assignment *across* a package does. that means that somehow when
you do "$pack::var" perl does something a tiny bit different if you're *in*
package 'pack' or in some other package... Odd...:o)]
} This is what I mean by 'modularity'. use vars is *not* a library: it
} is part of the language. The same goes for IO::*.
Gad, I hope you won't be part of the core implementation group -- I can
only assume that you'll argue that the documentation for 'open' should be
removed, since IO::File is "part of the language".
} > I don't understand your point.
}
} Things that are undocumented are undocumented because they are not for
} public use....
You think that 'select()' shouldn't be for public use? None of the
available docs even hint at such a thing...
} > IMO, only the most myopic and narrow-minded of folk [mostly brainwashed
} > from having taken too many undergraduate "object oriented programming"
} > classes, I suspect]
}
} Myopic I may be (-10 and -12 dioptres, with astigmatism :), but I am
} not narrow-minded; and I have *certainly* never taken an undergraduate
} OOP class.
Well, sounds like it on two fronts:
1) you're apparently an advocate that there should only be ONE way to do
things. IO::File is there, and the direct use of 'open' is now, in your
world, deprecated. [oh, sorry, you were just making the parallel arg about
IO:Select and select()..:o)]
2) the recommendation at hand, to use IO::Select, basically forces a
[relatively] behemoth OO package down our throats, even if we happen not to
want to be doing OO right there -- again, the usual stance of the pedant,
who believes that OO is the only-true-right way to accomplish any task. It
is one thing to carp about $^H, which is clearly documented:
$^H WARNING: This variable is strictly for internal
use only. Its availability, behavior, and con
tents are subject to change without notice.
but in IO::Select, it just says:
The "IO::Select" package implements an object approach to
the system "select" function call.
Which hardly sounds like "THIS IS THE ONLY APPROVED WAY TO DO SELECT IN
PERL", does it? Granted, for the true believer, non-OO is tantamount to
heresy, but not all of us have been quite so brainwashed...
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
bernie@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
Date: 27 Jan 2004 12:10:22 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <bv5kfe$m39$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Bernie Cosell:
> Ben Morrow <usenet@morrow.me.uk> wrote:
> } Bernie Cosell <bernie@fantasyfarm.com> wrote:
> } > Ben Morrow <usenet@morrow.me.uk> wrote:
>
> I notice that you skipped over the comment about your patronizing Lucy
> science lecture: indeed, I had done that same analysis (which is hardly
> difficult) and STILL couldn't figure out why use vars worked but the
> version I needed wouldn't.
>
> } > } Yes, OK, you are right. I had forgotten that. The assignment has to
> } > } occur in a different package from that which you are assigning into.
> } >
> } > That was my point: WHERE EXACTLY is that documented?? How did you learn
> } > that little tidbit to have forgotten it???
> }
> } It is not documented. It is perl internals.
>
> Perhaps -- odd argument, I think. What *IS* someone supposed to do if 'use
> vars' doesn't do quite what they want? Is that really some deep secret
> part of the system in your view? [and it still leaves me a bit mystified
> as to WHY the simple global-assignment doesn't work, but the
> global-assignment *across* a package does. that means that somehow when
> you do "$pack::var" perl does something a tiny bit different if you're *in*
> package 'pack' or in some other package... Odd...:o)]
There is always a moment in which you wish that the core of the language
was different from the way it is. If you find the 'vars' pragma
unsuitable for your task, then it's your privilege to look at its
internals and come up with something more suitable.
You have to keep this in mind: the people who designed and made Perl are
not infallible. When they did 'vars', they had something in mind and
honstly believed that it would be sufficient and cover all cases. It's
tough luck that it maybe doesn't quite achieve this degree of
perfection.
The assumption that the innards of 'vars' are undocumented due to the
developers' malice is wrong. There just didn't happen to be someone
around who thought it would be necessary or worth the pain to document
it. If you know how and why it works and you are willing to add the
missing piece of explanation to, say, perlref.pod, I am sure the porters
wouldn't reject such an addition.
As far as the development of Perl is concerned, there has always been
one important rule: Either complain and whine, or fix it and make the
world a better place.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Tue, 27 Jan 2004 13:21:47 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <bv5olb$sg1$1@wisteria.csv.warwick.ac.uk>
Bernie Cosell <bernie@fantasyfarm.com> wrote:
> Ben Morrow <usenet@morrow.me.uk> wrote:
> } Bernie Cosell <bernie@fantasyfarm.com> wrote:
> } > Ben Morrow <usenet@morrow.me.uk> wrote:
>
> I notice that you skipped over the comment about your patronizing Lucy
> science lecture: indeed, I had done that same analysis (which is hardly
> difficult) and STILL couldn't figure out why use vars worked but the
> version I needed wouldn't.
This is mostly because the term 'Lucy science lecture' is not one I am
familiar with: I take it refers to the fact that my analysis, although
perhaps convincing, was incorrect? I apologise. As I said, I don't
think the final step was that hard to figure out, either.
> [and it still leaves me a bit mystified
> as to WHY the simple global-assignment doesn't work, but the
> global-assignment *across* a package does. that means that somehow when
> you do "$pack::var" perl does something a tiny bit different if you're *in*
> package 'pack' or in some other package... Odd...:o)]
Think about it. Use strict has to shout at you about using a global
unless
1. you have declared it with our,
2. it is fully qualified, or
3. it has been exported by some module.
This odd behaviour covers case 3, of which use vars is a special case.
> } This is what I mean by 'modularity'. use vars is *not* a library: it
> } is part of the language. The same goes for IO::*.
>
> Gad, I hope you won't be part of the core implementation group -- I can
> only assume that you'll argue that the documentation for 'open' should be
> removed, since IO::File is "part of the language".
I don't think that documentation should ever be removed, unless it is
confusing and does more harm than good. I have also never used
IO::File, and (since the development of lexical FHs) can't see any
reason why I ever should.
> } > I don't understand your point.
> }
> } Things that are undocumented are undocumented because they are not for
> } public use....
>
> You think that 'select()' shouldn't be for public use? None of the
> available docs even hint at such a thing...
About the only sensible point in this discussion... yes, I was
suggesting that direct use of select() should be deprecated in favour
of IO::Select. I would say the same of IO::Socket and the low-level
socket functions.
> } Myopic I may be (-10 and -12 dioptres, with astigmatism :), but I am
> } not narrow-minded; and I have *certainly* never taken an undergraduate
> } OOP class.
>
> Well, sounds like it on two fronts:
>
> 1) you're apparently an advocate that there should only be ONE way to do
> things. IO::File is there, and the direct use of 'open' is now, in your
> world, deprecated. [oh, sorry, you were just making the parallel arg about
> IO:Select and select()..:o)]
There is an important difference between IO::Select and IO::File,
which is that IO::Select actually does something useful. As you found
out, doing a low-level select call yourself is fiddly and requires
some rather cryptic and unintuitive, not to mention C-like, operations
to construct the arguments and get the data back out. IO::Select is a
very thin wraper around that, that provides a Perlish interface. I'd
be willing to bet that if perl hadn't had select in the first place,
and IO::Select where to be implemented now as an extension, the
interface would be much as it is now; perhaps with a note in the
documentation saying 'the underlying select(2) call is available as
IO::Select::sysselect'.
IO::File, OTOH, gives you nothing over a simple open: indeed, I find
my $fh = IO::File->new("< file");
substantially harder to read than
open my $FH, "< file";
.
> 2) the recommendation at hand, to use IO::Select, basically forces a
> [relatively] behemoth OO package
!!! hardly. Have you read the source? I can't be bothered to benchmark
it, but I bet if you did it would be no slower than doing all the
vec() stuff by hand.
> down our throats, even if we happen not to want to be doing OO right
> there -- again, the usual stance of the pedant, who believes that OO
> is the only-true-right way to accomplish any task.
This is mudslinging, so I will only say that until I found Perl's OO,
which lets you do OO when it's convenient and not when it's not, I
would have said that OO was not something I would want to use.
> It is one thing to carp about $^H, which is clearly documented:
>
> $^H WARNING: This variable is strictly for internal
> use only. Its availability, behavior, and con
> tents are subject to change without notice.
>
> but in IO::Select, it just says:
>
> The "IO::Select" package implements an object approach to
> the system "select" function call.
>
> Which hardly sounds like "THIS IS THE ONLY APPROVED WAY TO DO SELECT IN
> PERL", does it?
No. What I was suggesting was that, since the documentation for select
is (apparently) cryptic and inadequate to enable anyone without
intimate knowledge of perl internals to use it, it be changed to say
something more along those lines. Then perhaps we wouldn't get muppets
here asking questions whose answers require nothing more than a small
amount of thought.
Ben
--
And if you wanna make sense / Whatcha looking at me for? (Fiona Apple)
* ben@morrow.me.uk *
------------------------------
Date: Wed, 28 Jan 2004 08:23:15 -0500
From: Bernie Cosell <bernie@fantasyfarm.com>
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <ptcf10tjr113md4jufef4j90h56nft0m03@library.airnews.net>
Ben Morrow <usenet@morrow.me.uk> wrote:
}
} Bernie Cosell <bernie@fantasyfarm.com> wrote:
} > [and it still leaves me a bit mystified
} > as to WHY the simple global-assignment doesn't work, but the
} > global-assignment *across* a package does. that means that somehow when
} > you do "$pack::var" perl does something a tiny bit different if you're *in*
} > package 'pack' or in some other package... Odd...:o)]
}
} Think about it. Use strict has to shout at you about using a global
} unless
}
} 1. you have declared it with our,
} 2. it is fully qualified, or
} 3. it has been exported by some module.
Would you care to say where you got these three rules from? I got this
from MY version of the online perl docs:
(F) You've said "use strict vars", which indicates
that all variables must either be lexically scoped
(using "my"), declared beforehand using "our", or
explicitly qualified to say which package the global
variable is in (using "::").
I didn't see anything that lead to inferring your tidy-three rules. There
was a mention that I found a bit cryptic [even knowing what it was supposed
to mean]:
(F) While "use strict" in effect, you referred to a
global variable that you apparently thought was
imported from another module, because something else
of the same name (usually a subroutine) is exported by
that module. It usually means you put the wrong funny
character on the front of your variable.
Perhaps we could agree that the ONLY real change in the documentation
that'd finesse this tempest in a teacup would be to add your third rule to
the first bit of documentation... something like
declared beforehand using "our",
explicitly qualified to say which package the global
variable is in (using "::"), or exported into the current
package from some other package.
If there's no disagreement about the above [and it is actually correct],
I'll be happy to put that tiny change into perldiag. [although I don't
think I'm a 'registered' guy so I'd have to find out how to go about doing
that...]
} > Well, sounds like it on two fronts:
} >
} > 1) you're apparently an advocate that there should only be ONE way to do
} > things. IO::File is there, and the direct use of 'open' is now, in your
} > world, deprecated. [oh, sorry, you were just making the parallel arg about
} > IO:Select and select()..:o)]
}
} There is an important difference between IO::Select and IO::File,
} which is that IO::Select actually does something useful. As you found
} out, doing a low-level select call yourself is fiddly and requires
} some rather cryptic and unintuitive, not to mention C-like, operations
} to construct the arguments and get the data back out.
Speak for yourself at how fiddly an "unintuitive" it is. And you think the
rules for ">" "+>" "&" "|" etc aren't 'fiddly' and C/unix-like with open?
The difference is only that you don't understand 'select()' and aren't
comfortable with the vec stuff, and perhaps others are [you run into
similar things with using raw sockets and messing with "packed" IP
addresses -- some programmers can't stand dealing with the machinery, other
prefer to have to flexibility to use it directly]
} ... IO::Select is a
} very thin wraper around that, that provides a Perlish interface.
No, not "perlish" but "perl object-oriented". And not so paper thin -- it
pulls in more of the IO:: machinery [IO::Handle, at the least]. Not a huge
amount of stuff, I meant "relatively" behemoth, because you have the [at
least two] packages you don't otherwise need, and the OO overhead on all
the operations, compared with, well, just doing "select()".
} ... I'd
} be willing to bet that if perl hadn't had select in the first place,
} and IO::Select where to be implemented now as an extension, the
} interface would be much as it is now; perhaps with a note in the
} documentation saying 'the underlying select(2) call is available as
} IO::Select::sysselect'.
I don't know: is there *ANY* other facility in Perl that is *ONLY*
available through an OO interface??
} IO::File, OTOH, gives you nothing over a simple open: indeed, I find
}
} my $fh = IO::File->new("< file");
}
} substantially harder to read than
}
} open my $FH, "< file";
Again, your bias that you'd impose on us all, I guess? You seem to have
that bias on your feeling about using select().
} > It is one thing to carp about $^H, which is clearly documented:
} >
} > $^H WARNING: This variable is strictly for internal
} > use only. Its availability, behavior, and con
} > tents are subject to change without notice.
} >
} > but in IO::Select, it just says:
} >
} > The "IO::Select" package implements an object approach to
} > the system "select" function call.
} >
} > Which hardly sounds like "THIS IS THE ONLY APPROVED WAY TO DO SELECT IN
} > PERL", does it?
}
} No. What I was suggesting was that, since the documentation for select
} is (apparently) cryptic and inadequate to enable anyone without
} intimate knowledge of perl internals to use it, it be changed to say
} something more along those lines. Then perhaps we wouldn't get muppets
} here asking questions whose answers require nothing more than a small
} amount of thought.
And we disagree -- I think that if anything, someone who cares *should*
make the available docs useable [even if it is only with comments in
IO::Select!]. I do believe that what the current docs *say* for IO::Select
is the proper philosophical path: that it is not the one-true-way to
achieve selectness, but provides an *OO* approach for those who prefer it.
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
bernie@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
Date: Wed, 28 Jan 2004 08:23:13 -0500
From: Bernie Cosell <bernie@fantasyfarm.com>
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <dsbf105sk3i6kj0h1havhm3s21f8jcpjp9@library.airnews.net>
"Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de> wrote:
} Also sprach Bernie Cosell:
}
} > Perhaps -- odd argument, I think. What *IS* someone supposed to do if 'use
} > vars' doesn't do quite what they want? Is that really some deep secret
} > part of the system in your view? [and it still leaves me a bit mystified
} > as to WHY the simple global-assignment doesn't work, but the
} > global-assignment *across* a package does. that means that somehow when
} > you do "$pack::var" perl does something a tiny bit different if you're *in*
} > package 'pack' or in some other package... Odd...:o)]
}
} There is always a moment in which you wish that the core of the language
} was different from the way it is. If you find the 'vars' pragma
} unsuitable for your task, then it's your privilege to look at its
} internals and come up with something more suitable.
I agree -- I didn't have a problem with that. Even just a *comment* to the
effect that "this has to go across a package boundary" in vars.pm would've
done fine by me -- I'm not opposed to reading code, and if I gave the
impression of the opposite have miswritten...
} You have to keep this in mind: the people who designed and made Perl are
} not infallible. When they did 'vars', they had something in mind and
} honstly believed that it would be sufficient and cover all cases. It's
} tough luck that it maybe doesn't quite achieve this degree of
} perfection.
Ah, you think it is *intentional* that the necessary bit of magic that
makes use-vars work as it does is undocumented... that we *SHOULD* be
compelled to use 'use vars'.. That's fine, and that's a viable argument.
'use vars' and the magic of strict are certainly closer to 'innards' than
many things are [I looked at 'use integer' and *there's* something that
clearly shouts "innards" to the casual reader..:o)].
But IMO it doesn't hold up for the case at hand -- compelling folk to use
IO::Select and using that as an argument not to document "select()"
} The assumption that the innards of 'vars' are undocumented due to the
} developers' malice is wrong. There just didn't happen to be someone
} around who thought it would be necessary or worth the pain to document
} it. If you know how and why it works and you are willing to add the
} missing piece of explanation to, say, perlref.pod, I am sure the porters
} wouldn't reject such an addition.
Actually, I don't even know the true thing that makes use-vars work. Is it
that the coloned-global assignment must be to a package *other* than the
one you're in? It is such an abstruse thing, I'm not sure even *where*
you'd document it [other than in vars.pm!] -- maybe someplace in the
'strict' documentation if anywhere]. BUT: I wouldn't mind a little
intution-helping explanation of how [if not why] a cross-package
fully-qualified assign does something different than a same-package
fully-qualified assign. [with a double lurking-question here: are there
any OTHER odd/hidden effects of cross vs self FQ-assigns, and are there any
other sorts-of-operations that can have a similar effect for 'strict'
*other* than a cross-package FQ assign]
} As far as the development of Perl is concerned, there has always been
} one important rule: Either complain and whine, or fix it and make the
} world a better place.
I agree -- the argument at hand was whether select() *should* be properly
documented or not and I was *NOT* my whining that it wasn't. I've used
'bare select' quite successfully in the past, and I *did* get my use-vars
workalike working, and I haven't whined about either [although I did have
to ask for help here to get my use-vars working].
The statement here that I think was at issue was that it was a *good*thing*
that select() not be documented [that is, to *discourage* someone from
documenting it] because "IO::Select" should be all you need].
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
bernie@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
Date: Wed, 28 Jan 2004 16:47:09 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <bv8p2d$4ua$1@wisteria.csv.warwick.ac.uk>
Bernie Cosell <bernie@fantasyfarm.com> wrote:
> Actually, I don't even know the true thing that makes use-vars work. Is it
> that the coloned-global assignment must be to a package *other* than the
> one you're in?
Yes, exactly that.
> It is such an abstruse thing, I'm not sure even *where* you'd
> document it [other than in vars.pm!] -- maybe someplace in the
> 'strict' documentation if anywhere]. BUT: I wouldn't mind a little
> intution-helping explanation of how [if not why] a cross-package
> fully-qualified assign does something different than a same-package
> fully-qualified assign. [with a double lurking-question here: are there
> any OTHER odd/hidden effects of cross vs self FQ-assigns, and are there any
> other sorts-of-operations that can have a similar effect for 'strict'
> *other* than a cross-package FQ assign]
The only real explanation is in sv.c:
/* copy sstr into dstr (I've only left in the relevant bits :) */
void
Perl_sv_setsv_flags(pTHX_ SV *dstr, register SV *sstr, I32 flags)
{
register U32 sflags;
register int dtype;
register int stype;
sflags = SvFLAGS(sstr);
if (sflags & SVf_ROK) { /* if the source is a ref */
if (dtype >= SVt_PV) {
if (dtype == SVt_PVGV) { /* and the dest is a glob */
SV *sref = SvREFCNT_inc(SvRV(sstr));
/* sref is the deref of sstr: what sstr pointed at */
switch (SvTYPE(sref)) {
/* snip lots of cases, leaving only 'ordinary' scalars */
default:
GvSV(dstr) = sref; /* make the assignment */
if (!GvIMPORTED_SV(dstr)
/* if the dest isn't marked as imported yet */
&& CopSTASH_ne(PL_curcop, GvSTASH(dstr)))
/* and the current pkg is different from
* the dest pkg (a pkg is called a STASH
* in the perl core) */
{
GvIMPORTED_SV_on(dstr); /* mark it as imported */
}
break;
}
}
}
}
}
This GvIMPORTED_SV flag is what strict checks for when it finds an
unqualified global. There are equivalent flags for the hash, array and
code slots in the glob.
Ben
--
And if you wanna make sense / Whatcha looking at me for? (Fiona Apple)
* ben@morrow.me.uk *
------------------------------
Date: Wed, 28 Jan 2004 17:14:31 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <bv8qln$6am$1@wisteria.csv.warwick.ac.uk>
Bernie Cosell <bernie@fantasyfarm.com> wrote:
> Ben Morrow <usenet@morrow.me.uk> wrote:
> } Bernie Cosell <bernie@fantasyfarm.com> wrote:
>
> } Use strict has to shout at you about using a global
> } unless
> }
> } 1. you have declared it with our,
> } 2. it is fully qualified, or
> } 3. it has been exported by some module.
>
> Would you care to say where you got these three rules from?
Err.... I can't remember :). I'm sure I read them somewhere, along
with an statement about glob assignment not working into the current
package... I would suspect the Camel, but I can't find it anywhere
with a quick check.
> Perhaps we could agree that the ONLY real change in the documentation
> that'd finesse this tempest in a teacup would be to add your third rule to
> the first bit of documentation... something like
>
> declared beforehand using "our",
> explicitly qualified to say which package the global
> variable is in (using "::"), or exported into the current
> package from some other package.
>
> If there's no disagreement about the above [and it is actually correct],
> I'll be happy to put that tiny change into perldiag. [although I don't
> think I'm a 'registered' guy so I'd have to find out how to go about doing
> that...]
I'd certainly agree with that.
> } > Well, sounds like it on two fronts:
> } >
> } > 1) you're apparently an advocate that there should only be ONE way to do
> } > things. IO::File is there, and the direct use of 'open' is now, in your
> } > world, deprecated. [oh, sorry, you were just making the parallel arg about
> } > IO:Select and select()..:o)]
> }
> }
> } There is an important difference between IO::Select and IO::File,
> } which is that IO::Select actually does something useful. As you found
> } out, doing a low-level select call yourself is fiddly and requires
> } some rather cryptic and unintuitive, not to mention C-like, operations
> } to construct the arguments and get the data back out.
>
> Speak for yourself at how fiddly an "unintuitive" it is. And you think the
> rules for ">" "+>" "&" "|" etc aren't 'fiddly' and C/unix-like with
> open?
open isn't at all C-like; shell-like, rather. By 'fiddly' I mean that
performing a select operation manually requires one statement per FH
to build the args, one for the select and one per FH to test the
output. IO::Select reduces that to two statements: one to build the
object and one to perform the test. (I would actually like a select()
function that simply takes three lists of FHs and a timeout, and
returns three lists of FHs. This seems the obvious Perl
implementation, to me.)
> The difference is only that you don't understand 'select()' and aren't
> comfortable with the vec stuff, and perhaps others are
I am perfectly happy with select in C. One of the reasons I would
choose to write Perl rather than C is because things are not done like
that in Perl: there is a general provision of a slightly higher-level,
more intuitive (to a Perl programmer) interface for nearly
everything. You have said you don't like Perl, which is fine: if you'd
rather do all the little bits yourself the go ahead and write C. I
would suggest that most people who prefer Perl to C would prefer
IO::Select over a raw select call.
> } ... IO::Select is a
> } very thin wraper around that, that provides a Perlish interface.
>
> No, not "perlish" but "perl object-oriented". And not so paper thin -- it
> pulls in more of the IO:: machinery [IO::Handle, at the least].
Err... nope.
> Not a huge
> amount of stuff, I meant "relatively" behemoth, because you have the [at
> least two] packages you don't otherwise need,
A 'package' is nothing. No overhead whatsoever. IO::Select pulls in
Exporter (which has had all the complicated bits ripped out into
Exporter::Heavy, so you don't get them if you don't need them),
strict, warnings and vars.
> and the OO overhead on all the operations,
This is the only overhead on top of performing the vec()s yourself. As
I said, I haven't benchmarked it; but I'd be willing to bet it's
completely trivial.
> } ... I'd
> } be willing to bet that if perl hadn't had select in the first place,
> } and IO::Select where to be implemented now as an extension, the
> } interface would be much as it is now; perhaps with a note in the
> } documentation saying 'the underlying select(2) call is available as
> } IO::Select::sysselect'.
>
> I don't know: is there *ANY* other facility in Perl that is *ONLY*
> available through an OO interface??
Yup. Lots of them. Tied variables, for a start; then there're all the
Net::* modules for the various network protocols, CGI (the function
interface is a wrapper round the OO, rather than the other way round),
'most anything that needs some sort of state. It's simply the natural
way to do things like that in Perl.
Perl5 is a very different language from perl4.
Ben
--
Joy and Woe are woven fine,
A Clothing for the Soul divine William Blake
Under every grief and pine 'Auguries of Innocence'
Runs a joy with silken twine. ben@morrow.me.uk
------------------------------
Date: 28 Jan 2004 19:36:25 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <bv92vp$mg0$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Ben Morrow:
> Bernie Cosell <bernie@fantasyfarm.com> wrote:
>> It is such an abstruse thing, I'm not sure even *where* you'd
>> document it [other than in vars.pm!] -- maybe someplace in the
>> 'strict' documentation if anywhere]. BUT: I wouldn't mind a little
>> intution-helping explanation of how [if not why] a cross-package
>> fully-qualified assign does something different than a same-package
>> fully-qualified assign. [with a double lurking-question here: are there
>> any OTHER odd/hidden effects of cross vs self FQ-assigns, and are there any
>> other sorts-of-operations that can have a similar effect for 'strict'
>> *other* than a cross-package FQ assign]
>
> The only real explanation is in sv.c:
>
> /* copy sstr into dstr (I've only left in the relevant bits :) */
> void
> Perl_sv_setsv_flags(pTHX_ SV *dstr, register SV *sstr, I32 flags)
> {
[...]
> if (!GvIMPORTED_SV(dstr)
> /* if the dest isn't marked as imported yet */
>
> && CopSTASH_ne(PL_curcop, GvSTASH(dstr)))
> /* and the current pkg is different from
> * the dest pkg (a pkg is called a STASH
> * in the perl core) */
> {
> GvIMPORTED_SV_on(dstr); /* mark it as imported */
> }
> break;
> }
> }
> }
> }
> }
>
> This GvIMPORTED_SV flag is what strict checks for when it finds an
> unqualified global. There are equivalent flags for the hash, array and
> code slots in the glob.
According to Perl_gv_fetchpv() only variables with type SVt_(PV|AV|HV)
need to be imported. This is totally consistent with the way you call
functions. They never have to be package-qualified or exported in a
funny way over package-boundaries.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Thu, 29 Jan 2004 08:34:51 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: How to use select (select(2)) in Perl?
Message-Id: <bvagjc$e4j$1@wisteria.csv.warwick.ac.uk>
tassilo.parseval@post.rwth-aachen.de wrote:
> Also sprach Ben Morrow:
> > This GvIMPORTED_SV flag is what strict checks for when it finds an
> > unqualified global. There are equivalent flags for the hash, array and
> > code slots in the glob.
>
> According to Perl_gv_fetchpv() only variables with type SVt_(PV|AV|HV)
> need to be imported. This is totally consistent with the way you call
> functions. They never have to be package-qualified or exported in a
> funny way over package-boundaries.
This is true, of course; however, there is a GvIMPORTED_CV flag to
check for overridden builtins. (At least, it looks to me from toke.c
as though that's what it does.)
Ben
--
don't get my sympathy hanging out the 15th floor. you've changed the locks 3
times, he still comes reeling though the door, and soon he'll get to you, teach
you how to get to purest hell. you do it to yourself and that's what really
hurts is you do it to yourself just you, you and noone else * ben@morrow.me.uk
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 6010
***************************************
