implicit split to @_ considered counterintuitive #335

p5pRT · 1999-08-03T16:41:07Z

Migrated from rt.perl.org#1164 (status was 'resolved')

Searchable as RT1164$

p5pRT · 1999-08-03T16:41:07Z

From @vlbrown

When I run this code:
#!/usr/local/bin/perl -w

$record = 'a b c d e f g';

$x = split(/\s+/, $record);

print $x, "\n";

(under Perl 5.005_02) I get:

Use of implicit split to @_ is deprecated at foo.pl line 5.
7

What implicit split to @_?

Sayeth the Camel: In scalar context, split returns the count of substrings
Which it does (7).

Sayeth perlfunc (on 5.005_03) under 'split':

"If not in list context, returns the number of fields found and splits
into the C<@_> array. (In list context, you can force the split into
C<@_> by using C<??> as the pattern delimiters, but it still returns
the list value.) The use of implicit split to C<@_> is deprecated,
however, because it clobbers your subroutine arguments."

Note the "returns the number of fields found *and* splits into @_" bit.

The use of implicit split to @_ is deprecated? TAKE IT OUT. It should
not be there. This is scalar context, not sorta scalar and sorta list and
I'll just put the data somewhere. Don't tell me that "in scalar context split
returns a number" and then warn me about some implicit @_. It should work or
not but not give a warning. That's dumb.

Perl Info



Site configuration information for perl 5.00502:

Configured by vlb at Tue Dec  1 13:04:02 PST 1998.

Summary of my perl5 (5.0 patchlevel 5 subversion 2) configuration:
   Platform:
     osname=solaris, osvers=2.6, archname=sun4-solaris
     uname='sunos jeeves 5.6 generic_105181-03 sun4u sparc 
sunw,ultra-enterprise '
     hint=recommended, useposix=true, d_sigaction=define
     usethreads=undef useperlio=undef d_sfio=undef
   Compiler:
     cc='gcc', optimize='-O', gccversion=2.8.1
     cppflags='-I/usr/local/include'
     ccflags ='-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=/usr/local/lib /lib /usr/lib /usr/ccs/lib
     libs=-lsocket -lnsl -ldb -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.00502:
     /usr/local/lib/perl5/5.00502/sun4-solaris
     /usr/local/lib/perl5/5.00502
     /usr/local/lib/perl5/site_perl/5.005/sun4-solaris
     /usr/local/lib/perl5/site_perl/5.005
     .


Environment for perl 5.00502:
     HOME=/export/home/vlb
     LANG (unset)
     LD_LIBRARY_PATH=/usr/usr2/oracle/product/8.0.5/lib
     LOGDIR (unset)
  
PATH=/usr/local/sbin:/export/home/vlb/bin:/export/home/vlb/nib:/usr/lo 
cal/bin:/opt/SUNWspro/bin:/usr/ccs/bin:/usr/ucb:/usr/bin:/bin:/etc:/sb 
in:/usr/sbin:/usr/openwin/bin:/usr/usr2/oracle/product/8.0.5/bin:/usr/ 
dt/bin:/usr/local/genome/bin:/usr/games:.
     PERL_BADLANG (unset)
     SHELL=/usr/bin/tcsh
-----
  //=\   Vicki Brown <vlb@deltagen.com>
  \=//    Journeyman Sourcerer: Scripts & Philtres
   //=\
   \=//     Scientific Programming <> Perl, Unix, Mac
    //=\     A little Web gardening on the weekends
    \=//
     //=\      Deltagen, Inc; 1031 Bing St, San Carlos, CA 94070

p5pRT · 1999-08-03T18:49:42Z

From [Unknown Contact. See original ticket]

Features must not be removed from Perl without first going through a
deprecation cycle. This is not dumb, but rather necessary to provide fair
warning to programmers who have been using the feature.

What do you think of making things scheduled like this become
mandatory warnings before they completely stop working?

I'll support giving the axe to the implicit split if we
can make // always repeat the last match irrespective of
success, the way it does in (fixed versions of) vi. :-)

--tom

p5pRT · 1999-08-03T18:49:42Z

From [Unknown Contact. See original ticket]

In message <v04210108b3cd04005beb@[207.135.77.148]>,
Vicki Brown writes:
: What implicit split to @_?

You ask this and then go on to quote the docs. I find that puzzling.

: Note the "returns the number of fields found *and* splits into @_" bit.

This is to support old code. Did you use version 4 or earlier?

: The use of implicit split to @_ is deprecated? TAKE IT OUT.

We don't like to snatch the rug from beneath people without bulletproof
reasons. Think of going through a deprecation cycle as a manner of
politeness a civility.

: It should not be there.

It's deprecated. That means it's likely to be on the way out. Larry
told Chip that anything that's currently deprecated is fair game for
the chopping block in Topaz.

: This is scalar context, not sorta scalar and sorta list and
: I'll just put the data somewhere.

It's documented behavior that has a long history.

: Don't tell me that "in scalar context split returns a number" and then
: warn me about some implicit @_.

Don't read the docs and you won't have to learn anything you don't want
to.

: It should work or not but not give a warning.

Try assigning to $* when you get a chance. You can disable warnings,
you know.

: That's dumb.

You misspelled "I'm".

Greg

p5pRT · 1999-08-03T18:49:46Z

From @tamias

On Tue, Aug 03, 1999 at 01:39:52PM -0700, Vicki Brown wrote:

The use of implicit split to @_ is deprecated? TAKE IT OUT. It should
not be there. This is scalar context, not sorta scalar and sorta list and
I'll just put the data somewhere. Don't tell me that "in scalar context split
returns a number" and then warn me about some implicit @_. It should work or
not but not give a warning. That's dumb.

Features must not be removed from Perl without first going through a
deprecation cycle. This is not dumb, but rather necessary to provide fair
warning to programmers who have been using the feature.

Ronald

p5pRT · 1999-08-03T19:40:33Z

From [Unknown Contact. See original ticket]

Tom Christiansen writes:

What do you think of making things scheduled like this become
mandatory warnings before they completely stop working?

Mandatory warnings suck.

Not as bad as breaking something.

--tom

p5pRT · 1999-08-03T19:40:33Z

From [Unknown Contact. See original ticket]

Tom Christiansen writes:

What do you think of making things scheduled like this become
mandatory warnings before they completely stop working?

Mandatory warnings suck. Have a deprecated warning set for the
lexical warnings, so you can say use warnings 'deprecation'; or use
warnings 'of imminent breakage'; or something like that.

Nat

p5pRT · 1999-08-03T19:40:33Z

From @vlbrown

At 16:39 -0600 8/3/99, Nathan Torkington wrote:

Tom Christiansen writes:

What do you think of making things scheduled like this become
mandatory warnings before they completely stop working?

Mandatory warnings suck. Have a deprecated warning set for the
lexical warnings, so you can say use warnings 'deprecation'; or use
warnings 'of imminent breakage'; or something like that.

or use warnings 'of extreme stupidity checking'
I could be very deliriously delighted with this :-)

As it stands right now, my choices are either to turn off -w (no :)
or to stop using split in scalar context (sigh).

By forcing me to get this warning,the simple use of split in scalar
context has effectively been deprecated along with the implicit split
to @_ (which happens to be undocumented, as near as I can tell, in
the 3/98 printing of The Camel, 2nd ed). That's sad, to say the
least. It's annoying to say more. I understand... I do not have to
like it.

I recognize the desire not to break code... although sometimes one
needs to bite the bullet. I also look forward with rapt anticipation
to the day when -w is a lot less overweening.
-- --
|\ _,,,---,,_ Vicki Brown <vlb@cfcl.com>
ZZZzz /,`.-'`' -. ;-;;,_ Journeyman Sourceror: Scripts & Philtres
|,4- ) )-,_. ,\ ( `'-' P.O. Box 1269 San Bruno CA 94066
'---''(_/--' `-'\_) http://www.cfcl.com/~vlb http://www.macperl.com

p5pRT · 1999-08-03T19:40:44Z

From [Unknown Contact. See original ticket]

Tom Christiansen writes:

Mandatory warnings suck.
Not as bad as breaking something.

These big breakages will only happen at a major version change, Larry
has said as much. Inserting a mandatory warning into 5 for something
that will break in 6 is silly. You should give people the option to
check whether their code will break under 6, by enabling a lexical
warning.

Nat

p5pRT · 1999-08-03T19:43:02Z

From [Unknown Contact. See original ticket]

These big breakages will only happen at a major version change, Larry
has said as much. Inserting a mandatory warning into 5 for something
that will break in 6 is silly. You should give people the option to
check whether their code will break under 6, by enabling a lexical
warning.

When Larry effectively changed the precedences in perl4 to perl5, this
caused some programs to *break*. It was not considered acceptable
that they should be silently doing the wrong thing. So we have cases
of mandatory warnings:

% perl -ce 'open FILE || die'
Precedence problem: open FILE should be open(FILE) at -e line 1.

This is just one step away from complete compilation failure:

% perl -ce 'print "fred@home"'
In string, @home now must be written as \@home at -e line 1, near "fred@home"
-e had compilation errors.

I believe that anything that's getting a -w deprecated warning now in
perl5 should in perl6 incur a mandatory warning if its functionality
changes. As you see, there's ample precedent for that, and that there
exist circumstances in which mandatory warnings are justifiable.

--tom

p5pRT · 1999-08-03T20:21:53Z

From [Unknown Contact. See original ticket]

As it stands right now, my choices are either to turn off -w (no :)
or to stop using split in scalar context (sigh).

Or to be more imaginative:

$count = do { my @tmp = split /:/, $line };

--tom

p5pRT · 1999-08-03T22:30:54Z

From [Unknown Contact. See original ticket]

Tom Christiansen[SMTP:tchrist@jhereg.perl.com] wrote:

As it stands right now, my choices are either to turn off -w (no :)
or to stop using split in scalar context (sigh).

Or to be more imaginative:
$count = do \{ my @&#8203;tmp = split /&#8203;:/\, $line \};

...or an old standby:

$count=@{[split /:/,$line]};

TMTOWTDI,

Jim Williams

p5pRT · 1999-08-04T00:37:34Z

From @perhunter

"WJP" == Williams, James P <James.P.Williams@USAHQ.UnitedSpaceAlliance.com> writes:

WJP> Tom Christiansen[SMTP:tchrist@jhereg.perl.com] wrote:
>> >As it stands right now, my choices are either to turn off -w (no :)
>> >or to stop using split in scalar context (sigh).
>>
>> Or to be more imaginative:
>>
>> $count = do { my @tmp = split /:/, $line };

WJP> ...or an old standby:

WJP> $count=@{[split /:/,$line]};

since it is only a single char, why not just use tr/// to count the :
and then bump it by 1 for the field count. gotta be much faster than any
of the split variations.

uri

--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
"F**king Windows 98", said the general in South Park before shooting Bill.

p5pRT · 1999-08-04T01:54:23Z

From [Unknown Contact. See original ticket]

On Tue, Aug 03, 1999 at 08:08:56PM -0500, "Williams, James P" wrote:

Tom Christiansen[SMTP:tchrist@jhereg.perl.com] wrote:
As it stands right now, my choices are either to turn off -w (no :)
or to stop using split in scalar context (sigh).

Or to be more imaginative:
$count = do \{ my @&#8203;tmp = split /&#8203;:/\, $line \};
...or an old standby:
$count=@{[split /:/,$line]};

$count = length$line&&1+$line=~tr/://;

:-)

mark

P.S. Errr ... it's late at night ... and the evil perl gremlin got to me ...

$count = length($line) && 1 + $line =~ tr/://;

It only works if the separator is one literal character, and the
behaviour you want is "split(pat, str, -1)". But it's faster... :-)

use Benchmark;

$line = "1:field2:this_is_field3:4:field5:this_is_field6";

timethese(500000, {
'TomC' => sub { $count = do { my @tmp = split /:/, $line } },
'JamesW' => sub { $count = @{[split /:/, $line]} },
'MarkM' => sub { $count = length($line) && 1 + $line =~ tr/:// },
} );

Output:

Benchmark: timing 500000 iterations of JamesW, MarkM, TomC...
JamesW: 32 wallclock secs (33.17 usr + 0.00 sys = 33.17 CPU)
MarkM: 10 wallclock secs (10.73 usr + 0.00 sys = 10.73 CPU)
TomC: 32 wallclock secs (30.96 usr + 0.00 sys = 30.96 CPU)

I don't even know why I'm still at work... sheesh...

But I did finally come up with a use for short circuiting &&... :-)

--
markm@nortelnetworks.com/mark@mielke.cc/markm@ncf.ca __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | CUE Development (4Y21)
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | Nortel Networks
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

p5pRT · 1999-08-04T05:01:49Z

From @pmqs

From: Nathan Torkington [mailto:gnat@frii.com]

Tom Christiansen writes:

What do you think of making things scheduled like this become
mandatory warnings before they completely stop working?

Mandatory warnings suck. Have a deprecated warning set for the
lexical warnings, so you can say use warnings 'deprecation'; or use
warnings 'of imminent breakage'; or something like that.

Err, there already is a "deprecated" lexical warning category.

Paul

p5pRT · 1999-08-04T05:45:58Z

From [Unknown Contact. See original ticket]

On Tue, 03 Aug 1999 at 13:39:52 -0700, Vicki Brown wrote:

$x = split\(/\\s\+/\, $record\);
Use of implicit split to @&#8203;\_ is deprecated at foo\.pl line 5\.

Sayeth the Camel: In scalar context, split returns the count of substrings
Which it does (7).

The Camel evidently tells not the full truth. Ask for your money back.
Well, some of it.

The use of implicit split to @_ is deprecated? TAKE IT OUT. It should
not be there. This is scalar context, not sorta scalar and sorta list and
I'll just put the data somewhere. Don't tell me that "in scalar context split
returns a number" and then warn me about some implicit @_. It should work or
not but not give a warning. That's dumb.

Not really dumb; it's history. Perl runs many scripts (it runs,
correctly, one of mine which has an SCCS revision date of 30 Nov 1989).
Some of them have implicit splits in them, and their owners need to be
told without the script breaking. It's normal for a feature to spend
its time in purgatory before being cast out into the outer darkness. Be
patient.

There isn't, I grant you, any handy way of counting RE matches in a
string [unless you use (?{}), of course], which your requested
non-splitting split would do, sort of. There should be a Better Way.

Ian
--
I am confident this explanation will dispell any feelings
of certainty that may have been troubling you.
- BWHOLMES@SJSUVM1.sjsu.edu (Cabbage) in <9601221753.AA27669@spock>

p5pRT · 1999-08-04T09:27:18Z

From [Unknown Contact. See original ticket]

Greg Bacon wrote:

In message <v04210108b3cd04005beb@[207.135.77.148]>,
Vicki Brown writes:
: What implicit split to @_?

You ask this and then go on to quote the docs. I find that puzzling.

The bit from "Sayeth perlfunc" up to "...split into @_" bit" (three
paragraphs) are actually from me. The bit before that was a post of
Vicki's to comp.lang.perl.moderated (Subject: implicit split to @_,
Message-ID: <v04210107b3cbf80d4537@[207.135.77.148]>), the next three
paragraphs are from my answer to her (on comp.lang.perl.moderated,
again; Message-ID: <37A6A8AE.3665E2B2@gmx.net>), and the final paragraph
of her posting to p5p is her text again (not previously posted to clpm).
This is not made clear in her submission through perlbug.

Cheers,
Philip

p5pRT · 1999-08-04T09:28:01Z

From [Unknown Contact. See original ticket]

Uri Guttman wrote:

since it is only a single char, why not just use tr/// to count the :
and then bump it by 1 for the field count.

Because the thread that started the posting used split(/\s+/, $record).
So tr/// wouldn't have worked for her.

Cheers,
Philip

p5pRT · 1999-08-04T10:37:56Z

From [Unknown Contact. See original ticket]

On Tue, Aug 03, 1999 at 04:41:22PM -0600, Tom Christiansen wrote:

Tom Christiansen writes:

What do you think of making things scheduled like this become
mandatory warnings before they completely stop working?

Mandatory warnings suck.

Not as bad as breaking something.

Mandatory warnings sometimes break things. We have projects that
are using legacy versions of Perl for the sole reason that running
with a newer version would emit warnings that break things. Some are
in a web environment, some are just pipelines where both stdout and
stderr are parsed by the next program in the pipe. True story.

Peace,
* Kurt Starsinic (Kurt.Starsinic@isinet.com) --------- Technical Specialist *
| `People keep pretending they can make things deeply |
| hierarchical, categorizable and sequential when they can't. |
| Everything is deeply intertwingled.' -- Ted Nelson |
Institute for Scientific Information http://www.isinet.com/

p5pRT · 1999-08-04T10:37:58Z

From [Unknown Contact. See original ticket]

On Tue, 03 Aug 1999 at 16:43:12 -0600, Nathan Torkington wrote:

Tom Christiansen writes:

Mandatory warnings suck.
Not as bad as breaking something.

These big breakages will only happen at a major version change, Larry
has said as much. Inserting a mandatory warning into 5 for something
that will break in 6 is silly. You should give people the option to
check whether their code will break under 6, by enabling a lexical
warning.

The reality is that people run scripts they don't fully (or at all)
understand, that crontabs run scripts, etc. etc. These will continue to
be used unchanged until they do break. And they don't say #!..perl5,
they just say 'perl'. Maybe this is the very last version of perl?
If so, that's a whole new breakage if we all have to go round changing
'perl' to 'topaz' everywhere.

If there is to be a continuity between what we have now and what somes
next, then (mis)features have to go on to death row, and a warning
should be on by default. Any suppression of the warnings should require
overriding in a clearly visible form, so that when it *does* break, the
maintainer can easily see that there's something dangerous going on.

[Of course, 'foolproof' underestimates the sheer tenacity of fools. I had
a boss whose perl scripts I inherited once. On one of them, he'd set -U
(you've never used that? good!). Why? Well, perl complained when he
tried to unlink a directory...]

Ian

p5pRT · 1999-08-04T12:16:32Z

From [Unknown Contact. See original ticket]

"Tom" == Tom Christiansen <tchrist@jhereg.perl.com> writes:

>> As it stands right now, my choices are either to turn off -w
>> (no :) or to stop using split in scalar context (sigh).

Tom> Or to be more imaginative:

Tom> $count = do { my @tmp = split /:/, $line };

Isn't

$cnt = () = split /:/, $line;

enough?

--
Stephen
---
"If 8-year-old boys discharging loaded firearms into their own legs
isn't necessary to the maintenance of a well-regulated militia, I
don't know what is." - Randal Cummings as reported in The Onion, 25/5/99

p5pRT · 1999-08-04T12:16:50Z

From [Unknown Contact. See original ticket]

On 04 Aug 1999 15:21:53 -0700, Stephen Zander wrote (in part):

Stephen> Isn't

Stephen> $cnt = () = split /:/, $line;

Stephen> enough?

Only in newer perls. 4.036 requires

$cnt = ($tmp) = split(/:/,$line);

/spider

p5pRT · 1999-08-04T12:30:49Z

From [Unknown Contact. See original ticket]

Isn't
$cnt = () = split /:/, $line;
enough?

Sure. But it *is* a neologism. :-)

-tom

p5pRT · 1999-08-04T13:45:35Z

From @mjdominus

$ perl -e '
$a = "a:b:c:d:e";
$cnt = () = split /:/, $a;
print "$cnt\n"
'
1

The right-hand side of the $cnt= assignment is a list assignment
expression. In scalar context, the value of a list assignment
expressions is the number of values available for assignment, which is
why

while (($k, $v) = each %h) { ... }

or

while (($x, $y, $z) = split ...) { ... }

work. The former terminates the loop when each() returns the empty
list, not when $v is false. The latter terminates the loop when
split() returns the empty list, not when $z is false.

When the result of split() is assigned to a list, the third argument
to split() defaults to the number of items in the list, plus one. For
example,

($x, $y) = split P, S;

is equivalent to:

($x, $y) = split P, S, 3;

In your example, you have

() = split /:/, $a;

This is equivalent to

() = split /:/, $a, 1;

Therefore, the number of items available for assignment is 1.
This is the value that is assigned to $cnt.

p5pRT · 1999-08-04T13:45:39Z

From [Unknown Contact. See original ticket]

On Wed, Aug 04, 1999 at 10:47:34AM -0600, "Tom Christiansen" wrote:

I thought the rule for:
scalar = list
Was that the scalar recieved the last scalar in the list???
Please RTFM. That's not what's going on here.

$ perl -e '
$a = "a:b:c:d:e";
$cnt = () = split /:/, $a;
print "$cnt\n"
'
1

Ok then. Colour me blinded by my experimentation?

$ perl -v

This is perl, version 5.005_03 built for sun4-solaris
(with 1 registered patch, see perl -V for more detail)
...

mark

--
markm@nortelnetworks.com/mark@mielke.cc/markm@ncf.ca __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | CUE Development (4Y21)
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | Nortel Networks
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

p5pRT · 1999-08-04T13:45:43Z

From @RandalSchwartz

"Mark" == Mark Mielke <markm@nortelnetworks.com> writes:

Mark> I thought the rule for:

Mark> scalar = list

Mark> Was that the scalar recieved the last scalar in the list???

there is no rule for:

scalar = list

because it can never happen. The right-hand side is evaluated in a
scalar context. What that means depends on what the syntax of the
right side is. for ($a,$b,$c) it's $c. For @x, it's the number of
elements of @x. for getpwnam, it's the userid element only. for m/.../g,
it returns the next match instead of all the matches. for <FOO> it reads
one chunk instead of all the chunks.

Get the idea? THERE CANNOT BE A LIST IN A SCALAR CONTEXT. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

p5pRT · 1999-08-04T13:45:43Z

From [Unknown Contact. See original ticket]

On Wed, 4 Aug 1999, Spider Boardman wrote:

On 04 Aug 1999 15:21:53 -0700, Stephen Zander wrote (in part):
Stephen> Isn't
Stephen> $cnt = () = split /:/, $line;
Stephen> enough?

Only in newer perls. 4.036 requires
$cnt = ($tmp) = split(/:/,$line);

Broken in _60 then?

perl -we '$line="q:a:d:e"; $cnt = () = split /:/, $line; print $cnt'
1

And surely $cnt = ($tmp) = split(/:/,$line); should always set $cnt = 2 ?
Or am I being completely stupid?

John.

p5pRT · 1999-08-04T13:50:06Z

From [Unknown Contact. See original ticket]

On Wed, Aug 04, 1999 at 09:22:29AM -0600, "Tom Christiansen" wrote:

Isn't
$cnt = () = split /:/, $line;
enough?
Sure. But it *is* a neologism. :-)

Umm... is anybody sure this works?

I thought the rule for:

scalar = list

Was that the scalar recieved the last scalar in the list???

mark

--
markm@nortelnetworks.com/mark@mielke.cc/markm@ncf.ca __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | CUE Development (4Y21)
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | Nortel Networks
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

p5pRT · 1999-08-04T13:50:41Z

From [Unknown Contact. See original ticket]

I thought the rule for:
scalar = list
Was that the scalar recieved the last scalar in the list???

Please RTFM. That's not what's going on here.

--tom

p5pRT · 1999-08-04T13:50:56Z

From @RandalSchwartz

"Mark" == Mark Mielke <markm@nortelnetworks.com> writes:

Mark> On Wed, Aug 04, 1999 at 09:54:20AM -0700, "Randal L. Schwartz" wrote:

"Mark" == Mark Mielke <markm@nortelnetworks.com> writes:
Mark> I thought the rule for:
Mark> scalar = list
Mark> Was that the scalar recieved the last scalar in the list???

there is no rule for:
scalar = list
because it can never happen.
Mark> ^^^^^^^^^^^^^^^^^^^^^ statement 1

The right-hand side is evaluated in a
scalar context.
Mark> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ statement 2

Mark> Of if there isn't a method of coercing a list into a scalar... but their
Mark> is a way of evaluating a list in scalar context... errr hmm...

no, there's no "list" in a scalar context. What are you calling a list?

Mark> Seem to me that "evaluating in scalar context" "coercing to a scalar"
Mark> and "assigning a list to a scalar" are all the same?

That's because you're erroneously making them the same.

There are no Perl constructs that even return a list in a scalar context.
So it cannot exist.

Mark> We're playing word games here???

No, *you* are.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

p5pRT · 1999-08-04T13:52:52Z

From [Unknown Contact. See original ticket]

On Wed, Aug 04, 1999 at 09:54:20AM -0700, "Randal L. Schwartz" wrote:

"Mark" == Mark Mielke <markm@nortelnetworks.com> writes:
Mark> I thought the rule for:
Mark> scalar = list
Mark> Was that the scalar recieved the last scalar in the list???

there is no rule for:
scalar = list
because it can never happen.
^^^^^^^^^^^^^^^^^^^^^ statement 1

The right-hand side is evaluated in a
scalar context.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ statement 2

Of if there isn't a method of coercing a list into a scalar... but their
is a way of evaluating a list in scalar context... errr hmm...

Seem to me that "evaluating in scalar context" "coercing to a scalar"
and "assigning a list to a scalar" are all the same?

We're playing word games here???

I just want to know why people are saying:

$cnt = () = split /:/, $line;

Works ... when I can't get it to work?

mark

--
markm@nortelnetworks.com/mark@mielke.cc/markm@ncf.ca __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | CUE Development (4Y21)
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | Nortel Networks
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

p5pRT · 1999-08-04T16:23:15Z

From [Unknown Contact. See original ticket]

Would some kind sole explain to me why this gives any result at all?

perl -wle '$cnt = () = (1,2,3); print $cnt'
3

I would have expected this to be a fatal error. Isn't () rvalued?

<chaim>

"GB" == Greg Bacon <gbacon@itsc.uah.edu> writes:

GB> In message <19990804125927.C24774@bmers31f.ca.nortel.com>,
GB> "Mark Mielke" writes:
GB> : I just want to know why people are saying:
GB> :
GB> : $cnt = () = split /:/, $line;
GB> :
GB> : Works ... when I can't get it to work?

GB> We discussed this on clpmisc recently. Incant

GB> $cnt = () = split /:/, $line, -1;

GB> Bug?

--
Chaim Frenkel Nonlinear Knowledge, Inc.
chaimf@pobox.com +1-718-236-0183

p5pRT · 1999-08-04T17:45:17Z

From [Unknown Contact. See original ticket]

paul.marquess@bt.com writes:

Mandatory warnings suck. Have a deprecated warning set for the
lexical warnings, so you can say use warnings 'deprecation'; or use
warnings 'of imminent breakage'; or something like that.

Err, there already is a "deprecated" lexical warning category.

We need another category: really-deprecated with warnings being *on*
by default. Then we can propagate implicit-split to this category,
and disable this misfeature in 5.006_50.

Could you do it before Sarathy is back?

Ilya

p5pRT · 1999-08-04T18:27:41Z

From @tamias

On Wed, Aug 04, 1999 at 03:31:45PM -0400, Chaim Frenkel wrote:

Would some kind sole explain to me why this gives any result at all?
perl \-wle '$cnt =  = $1\,2\,3$; print $cnt'
3
I would have expected this to be a fatal error. Isn't () rvalued?

Not sure why it would be a fatal error. It's a common idiom in Perl5.

It's just like this:

($foo) = (1,2,3);

except instead of being 2 lvalues short, it's 3 lvalues short. The extra
rvalues in the list just don't get assigned to an lvalue.

A list assignment in scalar context returns the number of values on the
RHS, so $cnt gets 3.

Ronald

p5pRT · 1999-08-04T18:31:54Z

From [Unknown Contact. See original ticket]

Are you saying that the "deprecated" lexical warning category is *not*
on by default? That's strange. Does it take three steps to get rid of
features now?

(1) deprecated warning off by default
(2) deprecated warning on by default
(3) feature removed

This is bad?

p5pRT · 1999-08-04T18:32:00Z

From [Unknown Contact. See original ticket]

On Wed, Aug 04, 1999 at 05:45:38PM -0400, Joshua N Pritikin wrote:

We need another category: really-deprecated with warnings being *on*
by default. Then we can propagate implicit-split to this category,
and disable this misfeature in 5.006_50.

Are you saying that the "deprecated" lexical warning category is *not*
on by default? That's strange.

perl5.005_60->./perl -le '$x = split'
perl5.005_60->./perl -wle '$x = split'
Use of implicit split to @_ is deprecated at -e line 1.
Name "main::x" used only once: possible typo at -e line 1.
Use of uninitialized value at -e line 1.

              Does it take three steps to get rid of
features now?

(1) deprecated warning off by default
(2) deprecated warning on by default
(3) feature removed

How would *you* do it?

Ilya

p5pRT · 1999-08-04T18:32:04Z

From [Unknown Contact. See original ticket]

On Wed, Aug 04, 1999 at 04:57:34PM -0400, ilya@math.ohio-state.edu wrote:

paul.marquess@bt.com writes:

Mandatory warnings suck. Have a deprecated warning set for the
lexical warnings, so you can say use warnings 'deprecation'; or use
warnings 'of imminent breakage'; or something like that.

Err, there already is a "deprecated" lexical warning category.

We need another category: really-deprecated with warnings being *on*
by default. Then we can propagate implicit-split to this category,
and disable this misfeature in 5.006_50.

Are you saying that the "deprecated" lexical warning category is *not*
on by default? That's strange. Does it take three steps to get rid of
features now?

(1) deprecated warning off by default
(2) deprecated warning on by default
(3) feature removed

--
"Never ascribe to malice that which can be explained by stupidity."
via, but not speaking for Deutsche Bank

p5pRT · 1999-08-04T19:22:24Z

From [Unknown Contact. See original ticket]

On Wed, Aug 04, 1999 at 03:55:26PM -0600, tchrist@jhereg.perl.com wrote:

Are you saying that the "deprecated" lexical warning category is *not*
on by default? That's strange. Does it take three steps to get rid of
features now?

(1) deprecated warning off by default
(2) deprecated warning on by default
(3) feature removed

This is bad?

Perhaps it is a good idea. It'll allow fewer objections from the
whiners and allow removal of more dubious semantics. Win, win?

--
"Never ascribe to malice that which can be explained by stupidity."
via, but not speaking for Deutsche Bank

p5pRT · 1999-08-04T21:48:51Z

From @gbarr

On Wed, Aug 04, 1999 at 01:44:06PM -0400, Mark Mielke wrote:

I think somebody just answered my question though. split() does appear
to have an implicit third argument.

Yes it does, and it's even documented too

I'm not sure if this is a bug. Comments?

No it is not. In

$cnt = () = split(/:/,$line)

$cnt has no more effect on the context that split is called in than
it would in

$cnt = @a = split(/:/,$line);

although this would give a different result to the first statement.

This is because this is two expressions, not one. First

() = split(/:/,$line)

is evaluated, this calls split in a list context. split is documented
that the third arguent defaults to the number of values the LHS
wants, plus one. So in this case it will be one

The secons expression is the scalar value of a list assignment. This
is documented (although maybe perldata may not be the best place) to
be the number of values that were returned on the RHS of the list assignment

So as you can see, I hope, this is not a bug.

--
Since you're clearly mad as a mongoose, I'll bid you good-day.
-- Edmund to Captain Rum : Black Adder II "Potato"

p5pRT · 1999-08-05T04:56:31Z

From @pmqs

From: Ilya Zakharevich [mailto:ilya@math.ohio-state.edu]

On Wed, Aug 04, 1999 at 05:45:38PM -0400, Joshua N Pritikin wrote:

We need another category: really-deprecated with warnings being *on*
by default. Then we can propagate implicit-split to this category,
and disable this misfeature in 5.006_50.

Are you saying that the "deprecated" lexical warning category is *not*
on by default? That's strange.

Correct. The current set of warnings in the 'deprecated' class are all
optional. I didn't move any existing warning from optional to default
(mandatory isn't the right word anymore when lexical warnings can actually
switch them off).

perl5.005_60->./perl -le '$x = split'
perl5.005_60->./perl -wle '$x = split'
Use of implicit split to @_ is deprecated at -e line 1.
Name "main::x" used only once: possible typo at -e line 1.
Use of uninitialized value at -e line 1.

The -w flag doesn't trigger lexical warnings.

use warning 'deprecated';
$x = split ;
{
no warning 'deprecated' ;
$y = split ;
}
$z = split ;

% perl5.00560 /tmp/lex
Use of implicit split to @_ is deprecated at /tmp/lex line 2.
Use of implicit split to @_ is deprecated at /tmp/lex line 7.

              Does it take three steps to get rid of
features now?

(1) deprecated warning off by default
(2) deprecated warning on by default
(3) feature removed

Isn't (1) all that has happened to date? Have we actually done (2) and/or
(3) with any feature?

Paul

p5pRT · 1999-08-05T04:56:36Z

From @pmqs

From: Ilya Zakharevich [mailto:ilya@math.ohio-state.edu]

Mandatory warnings suck. Have a deprecated warning set for the
lexical warnings, so you can say use warnings
'deprecation'; or use
warnings 'of imminent breakage'; or something like that.

Err, there already is a "deprecated" lexical warning category.

We need another category: really-deprecated with warnings being *on*
by default. Then we can propagate implicit-split to this category,
and disable this misfeature in 5.006_50.

The categories currently defined for lexical warnings are classed as
experimental. I would rather get the categories sorted out first before we
start dreaming up new ones.

Could you do it before Sarathy is back?

:-)

When does he get back?

Paul

p5pRT · 1999-08-05T06:29:53Z

From [Unknown Contact. See original ticket]

On Thu, Aug 05, 1999 at 09:12:09AM +0100, paul.marquess@bt.com wrote:

              Does it take three steps to get rid of
features now?

(1) deprecated warning off by default
(2) deprecated warning on by default
(3) feature removed
Isn't (1) all that has happened to date? Have we actually done (2) and/or
(3) with any feature?

We did not do it because it was not possible to do. And we will not
do it until there is STRONGLY_DEPRECATED category which is on by default.

Ilya

p5pRT · 1999-08-05T11:48:08Z

From [Unknown Contact. See original ticket]

That's not an obvious result, and what about the following?

$cnt = ($a, $b, $c) = () = (1,2,3);
print "$cnt: $a $b $c";
__END__
Use of uninitialized value at z.pl line 3.
Use of uninitialized value at z.pl line 3.
Use of uninitialized value at z.pl line 3.
0:

Why does the count get through on () = (1,2,3) case but not in
the chained case?

<chaim>

"RJK" == Ronald J Kimball <rjk@linguist.dartmouth.edu> writes:

RJK> On Wed, Aug 04, 1999 at 03:31:45PM -0400, Chaim Frenkel wrote:

Would some kind sole explain to me why this gives any result at all?

perl -wle '$cnt = () = (1,2,3); print $cnt'
3

I would have expected this to be a fatal error. Isn't () rvalued?

RJK> Not sure why it would be a fatal error. It's a common idiom in Perl5.

RJK> It's just like this:

RJK> ($foo) = (1,2,3);

RJK> except instead of being 2 lvalues short, it's 3 lvalues short. The extra
RJK> rvalues in the list just don't get assigned to an lvalue.

RJK> A list assignment in scalar context returns the number of values on the
RJK> RHS, so $cnt gets 3.

--
Chaim Frenkel Nonlinear Knowledge, Inc.
chaimf@pobox.com +1-718-236-0183

p5pRT · 1999-08-05T11:48:25Z

From @tamias

On Thu, Aug 05, 1999 at 10:39:00AM -0400, Chaim Frenkel wrote:

That's not an obvious result, and what about the following?

$cnt = ($a, $b, $c) = () = (1,2,3);
print "$cnt: $a $b $c";
__END__
Use of uninitialized value at z.pl line 3.
Use of uninitialized value at z.pl line 3.
Use of uninitialized value at z.pl line 3.
0:

Why does the count get through on () = (1,2,3) case but not in
the chained case?

In a scalar context, list assignment returns the number of elements on the
RHS. In a list context, list assignment returns the lvalues from the LHS.

Working from right to left:

() = (1,2,3)

assigns the list (1,2,3) to nothing.
This assignment is in list context, so it returns the empty list.

($a, $b, $c) = () = (1,2,3)

assigns the empty list to ($a, $b, $c).
This assignment is in scalar context, so it returns the number of items
assigned, which is zero.

$cnt = ($a, $b, $c) = () = (1,2,3)

assigns 0 to $cnt.

Ronald

p5pRT · 1999-08-05T17:40:11Z

From [Unknown Contact. See original ticket]

Chaim Frenkel writes:

RJK> In a scalar context, list assignment returns the number of
RJK> elements on the RHS. In a list context, list assignment
RJK> returns the lvalues from the LHS.
Please point me at the documentation for this.

chaim@localhost> grep -i 'list assignment' pod/*

pod/perldata.pod:List assignment in scalar context returns the number of elements

chaim@localhost> man perldata

Nat

p5pRT · 1999-08-05T17:40:56Z

From @tamias

On Thu, Aug 05, 1999 at 04:31:10PM -0400, Chaim Frenkel wrote:

"RJK" == Ronald J Kimball <rjk@linguist.dartmouth.edu> writes:

Why does the count get through on () = (1,2,3) case but not in
the chained case?

RJK> In a scalar context, list assignment returns the number of elements on the
RJK> RHS. In a list context, list assignment returns the lvalues from the LHS.

Please point me at the documentation for this.

perldata:

Array assignment in a scalar context returns the number of
elements produced by the expression on the right side of
the assignment:

$x = (($foo,$bar) = (3,2,1)); # set $x to 3, not 2
$x = (($foo,$bar) = f()); # set $x to f()'s return count

Note that this should say 'list assignment', not 'array assignment'. The
examples don't even contain any arrays.

I don't know if there is explicit mention of list assignment in list
context in the documentation. Both cases should probably be mentioned in
perlop, though.

Ronald

p5pRT · 1999-08-05T17:43:35Z

From [Unknown Contact. See original ticket]

"RJK" == Ronald J Kimball <rjk@linguist.dartmouth.edu> writes:

Why does the count get through on () = (1,2,3) case but not in
the chained case?

RJK> In a scalar context, list assignment returns the number of elements on the
RJK> RHS. In a list context, list assignment returns the lvalues from the LHS.

Please point me at the documentation for this.

<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
chaimf@pobox.com +1-718-236-0183

p5pRT · 1999-08-05T17:44:33Z

From [Unknown Contact. See original ticket]

On Thu, Aug 05, 1999 at 04:31:10PM -0400, "Chaim Frenkel" wrote:

"RJK" == Ronald J Kimball <rjk@linguist.dartmouth.edu> writes:
Why does the count get through on () = (1,2,3) case but not in
the chained case?
RJK> In a scalar context, list assignment returns the number of elements on
RJK> the RHS. In a list context, list assignment returns the lvalues from
RJK> the LHS.
Please point me at the documentation for this.

I can't seem to find it. (Doesn't mean it doesn't exist)

($rest) = ($first, $second) = split(/\s+/, "abc def ghi jkl");
print "$first, $second, $rest\n";

($rest) = ($first, $second) = ("abc", "def", "ghi", "jkl");
print "$first, $second, $rest\n";

Outputs:

abc, def, abc
abc, def, abc

And:

$scalar = ($first, $second) = ("abc", "def", "ghi", "jkl");
print "$scalar\n";
$scalar = ("abc", "def");
print "$scalar\n";

Outputs:

4D
def

So... it appears... in contradiction to what Randall believes...
There is such thing as a "list".

Apparent rules:

# FORM: scalar = value1, value2, ...;
# scalar gets scalar ("," operator returns last value)
$a = 1, 2, 3;

# FORM: scalar = rvalue_list;
# scalar gets last item in rvalue_list
$a = (1, 2, 3);
$a = &{ sub{ (1, 2, 3) } }; # Just to make a point... lists exist...

# FORM: scalar = lvalue_list = rvalue_list
# scalar gets length of rvalue_list
$a = ($b, $c) = (1, 2, 3, 6, 12);
$a = ($b, $c) = &{ sub{ (1, 2, 3, 6, 12) } };

# FORM: scalar = lvalue_list = split(pat, string)
# scalar gets assigned length of *lvalue_list* + 1
$a = ($b, $c) = split(/\s+/, "a b c d e f g h i j k l m n o p");

This all seems highly magical... anyways...

mark

--
markm@nortelnetworks.com/mark@mielke.cc/markm@ncf.ca __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | CUE Development (4Y21)
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | Nortel Networks
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

p5pRT · 1999-08-05T18:13:55Z

From @tamias

On Thu, Aug 05, 1999 at 05:01:30PM -0400, Mark Mielke wrote:

On Thu, Aug 05, 1999 at 04:31:10PM -0400, "Chaim Frenkel" wrote:

"RJK" == Ronald J Kimball <rjk@linguist.dartmouth.edu> writes:
Why does the count get through on () = (1,2,3) case but not in
the chained case?
RJK> In a scalar context, list assignment returns the number of elements on
RJK> the RHS. In a list context, list assignment returns the lvalues from
RJK> the LHS.
Please point me at the documentation for this.

I can't seem to find it. (Doesn't mean it doesn't exist)
 $$rest$ = $$first\, $second$ = split$/\\s\+/\, "abc def ghi jkl"$;
 print "$first\, $second\, $rest\\n";

 $$rest$ = $$first\, $second$ = $"abc"\, "def"\, "ghi"\, "jkl"$;
 print "$first\, $second\, $rest\\n";
Outputs:
 abc\, def\, abc
 abc\, def\, abc
And:
 $scalar = $$first\, $second$ = $"abc"\, "def"\, "ghi"\, "jkl"$;
 print "$scalar\\n";
 $scalar = $"abc"\, "def"$;
 print "$scalar\\n";
Outputs:
 4D
 def

Your input terminator is showing. :)

So... it appears... in contradiction to what Randall believes...
There is such thing as a "list".

s/Randall/Randal/;

Yes, there is such a thing as a list, but not in a scalar context.

Apparent rules:

 \# FORM&#8203;: scalar = value1\, value2\, \.\.\.;
 \#       scalar gets scalar \("\," operator returns last value\)
 $a = 1\, 2\, 3;

$a will be 1, not 3, because = has higher precedence than ,. The other
scalars are in a void context.

 \# FORM&#8203;: scalar = rvalue\_list;
 \#       scalar gets last item in rvalue\_list
 $a = \(1\, 2\, 3\);
 $a = &\{ sub\{ \(1\, 2\, 3\) \} \};   \# Just to make a point\.\.\. lists exist\.\.\.

In a scalar context, the comma operator evaluates its first argument, then
evaluates its second argument, and returns the value of the second
argument. At no time is there an actual list on the stack.

This is what is meant by "there is no such thing as a list in a scalar
context". In the Perl code, you see a comma-separated list, but during
execution it's just one item at a time.

 \# FORM&#8203;: scalar = lvalue\_list = rvalue\_list
 \#       scalar gets length of rvalue\_list
 $a = \($b\, $c\) = \(1\, 2\, 3\, 6\, 12\);
 $a = \($b\, $c\) = &\{ sub\{ \(1\, 2\, 3\, 6\, 12\) \} \};

 \# FORM&#8203;: scalar = lvalue\_list = split\(pat\, string\)
 \#       scalar gets assigned length of \*lvalue\_list\* \+ 1
 $a = \($b\, $c\) = split\(/\\s\+/\, "a b c d e f g h i j k l m n o p"\);

The scalar gets assigned the length of the rvalue_list, just as in the
previous example. This happens to be one greater than the length of the
lvalue list because of the magic of split and its assumed third argument.

Ronald

Peter-developer01 · 2023-03-09T06:41:52Z

Hello from 2023!!!

Peter-developer01 · 2023-03-09T06:42:15Z

😂😂😂😂😂😂😂😂😂😂😂😂

p5pRT closed this as completed Nov 28, 2003

p5pRT added Severity Fatal distro-Solaris type-library labels Oct 18, 2019

implicit split to @_ considered counterintuitive #335

implicit split to @_ considered counterintuitive #335

Comments

p5pRT commented Aug 3, 1999

p5pRT commented Aug 3, 1999

From @vlbrown

p5pRT commented Aug 3, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 3, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 3, 1999

From @tamias

p5pRT commented Aug 3, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 3, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 3, 1999

From @vlbrown

p5pRT commented Aug 3, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 3, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 3, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 3, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From @perhunter

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From @pmqs

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From @mjdominus

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From @RandalSchwartz

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From @RandalSchwartz

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From @tamias

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From [Unknown Contact. See original ticket]

p5pRT commented Aug 4, 1999

From @gbarr