Use of uninitialized value in concatenation (.)

[p5pRT]

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

Searchable as RT2902$

[p5pRT]

From hermit@BayView.COM

Created by hermit@komodo.bayview.com

This is a bug report for perl from hermit@​komodo.bayview.com\, generated with the help of perlbug 1.28 running under perl v5.6.0.

----------------------------------------------------------------- The warning message that appears when you use an uninitialized variable in string interpolation (double quotes) is wrong. It says "Use of uninitialized value in concatenation (.)" when in fact there is no concatenation (.) operator on that line. Instead\, there is double-quoted string interpolation. The warning message is misleading\, as novice users might go looking for a concatenation operator (a . between two scalar values) when in fact the problem is with something different.

Perl Info

``` Flags: category=core severity=medium Site configuration information for perl v5.6.0: Configured by hermit at Tue Mar 28 15:34:43 PST 2000. Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=linux, osvers=2.0.36, archname=i586-linux uname='linux komodo 2.0.36 #5 thu may 20 02:14:07 pdt 1999 i586 unknown ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='gcc', optimize='-O2', gccversion=2.7.2.3 cppflags='-I/usr/local/include' ccflags ='-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' stdchar='char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldbm -ldb -ldl -lm -lc -lposix -lcrypt libc=/lib/libc-2.0.7.so, so=so, useshrplib=true, libperl=libperl.so Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/local/perl5.6/lib/5.6.0/i586-linux/CORE' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Locally applied patches: @INC for perl v5.6.0: /usr/local/perl5.6/lib/5.6.0/i586-linux /usr/local/perl5.6/lib/5.6.0 /usr/local/perl5.6/lib/site_perl/5.6.0/i586-linux /usr/local/perl5.6/lib/site_perl/5.6.0 /usr/local/perl5.6/lib/site_perl . Environment for perl v5.6.0: HOME=/home/hermit LANG=C LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/hermit/cis33/lab7:/usr/local/perl5.6/bin:/home/hermit/cis33:/home/hermit/cis33/lab6:/home/hermit/bin:/usr/ucb:/usr/sbin:/bin:/usr/bin:/usr/bin/mh:/usr/old:/usr/etc:/etc:/usr/bsd:/usr/5bin:/usr/local/bin:/usr/local/etc:/usr/old:/usr/nas/bin:/bin:/usr/bin/X11:/usr/X11/bin:/usr/games:/sbin:/usr/sbin PERL_BADLANG (unset) SHELL=/usr/bin/tcsh ```

[p5pRT]

From [Unknown Contact. See original ticket]

This is a bug report for perl from hermit@​komodo.bayview.com\, generated with the help of perlbug 1.28 running under perl v5.6.0.

----------------------------------------------------------------- The warning message that appears when you use an uninitialized variable in string interpolation (double quotes) is wrong. It says "Use of uninitialized value in concatenation (.)" when in fact there is no concatenation (.) operator on that line. Instead\, there is double-quoted string interpolation. The warning message is misleading\, as novice users might go looking for a concatenation operator (a . between two scalar values) when in fact the problem is with something different.

That is\, however\, what's happening​:

% perl -MO=Deparse\,-q -e '@​scalar = @​array = (1..10); print "this $scalar and that @​array\n"' @​scalar = (@​array = (1\, 2\, 3\, 4\, 5\, 6\, 7\, 8\, 9\, 10)); print 'this ' . $scalar . ' and that ' . join($"\, @​array) . "\n";

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen writes​:

This is a bug report for perl from hermit@​komodo.bayview.com\, generated with the help of perlbug 1.28 running under perl v5.6.0.

----------------------------------------------------------------- The warning message that appears when you use an uninitialized variable in string interpolation (double quotes) is wrong. It says "Use of uninitialized value in concatenation (.)" when in fact there is no concatenation (.) operator on that line. Instead\, there is double-quoted string interpolation. The warning message is misleading\, as novice users might go looking for a concatenation operator (a . between two scalar values) when in fact the problem is with something different.

That is\, however\, what's happening​:

% perl -MO=Deparse\,-q -e '@​scalar = @​array = (1..10); print "this $scalar and that @​array\n"' @​scalar = (@​array = (1\, 2\, 3\, 4\, 5\, 6\, 7\, 8\, 9\, 10)); print 'this ' . $scalar . ' and that ' . join($"\, @​array) . "\n";

I assumed as much\, but I still don't think it's reasonable to expect the user to know that.

--Bill.

-- William R Ward hermit@​bayview.com http​://www.bayview.com/~hermit/

---

The secret of being creative is making something that's not very new but just a little bit different in the right direction - Marvin Minsky

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen writes​:

That is\, however\, what's happening​:

% perl -MO=Deparse\,-q -e '@​scalar = @​array = (1..10); print "this $scalar and that @​array\n"' @​scalar = (@​array = (1\, 2\, 3\, 4\, 5\, 6\, 7\, 8\, 9\, 10)); print 'this ' . $scalar . ' and that ' . join($"\, @​array) . "\n";

Many years ago when I started doing Perl I picked up the idea that it is always more efficient to do double-quote interpolation than spelling it out with '.' between each element. Of course\, that was in the days of Perl4. I assume that is no longer a concern? Was it ever\, or was I misinformed? I've done a lot of Perl hacking\, but have never spent time digging around in the actual interpreter itself.

I also was told that if there are no variables to be interpolated to always use single quotes rather than double quotes\, as the extra parsing required was expensive. Is/was this true?

--Bill.

-- William R Ward hermit@​bayview.com http​://www.bayview.com/~hermit/

---

The secret of being creative is making something that's not very new but just a little bit different in the right direction - Marvin Minsky

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen writes​:

That is\, however\, what's happening​:

% perl -MO=Deparse\,-q -e '@​scalar = @​array = (1..10); print "this $scalar and that @​array\n"' @​scalar = (@​array = (1\, 2\, 3\, 4\, 5\, 6\, 7\, 8\, 9\, 10)); print 'this ' . $scalar . ' and that ' . join($"\, @​array) . "\n";

To resolve this bug I would like to see one of two things happen​:

1. Remember whether we are doing variable interpolation or if the user actually spelled it out with '.' between each part of the string\, and give either "... in concatenation (.)" or "... in string interpolation" as the warning\, or

2. Modify the warning message to not be so specific\, like this​: "... in concatenation (.) or string interpolation"

Obviously #2 is easier\, but #1 is probably the Right Way(tm). Ideas?

--Bill.

-- William R Ward hermit@​bayview.com http​://www.bayview.com/~hermit/

---

The secret of being creative is making something that's not very new but just a little bit different in the right direction - Marvin Minsky

[p5pRT]

From [Unknown Contact. See original ticket]

% perl -MO=Deparse\,-q -e '@​scalar = @​array = (1..10); print "this $sc\ @​scalar = (@​array = (1\, 2\, 3\, 4\, 5\, 6\, 7\, 8\, 9\, 10)); print 'this ' . $scalar . ' and that ' . join($"\, @​array) . "\n";

I assumed as much\, but I still don't think it's reasonable to expect the user to know that.

Here's the code​:

Perl_report_uninit(pTHX) {   if (PL_op)   Perl_warner(aTHX_ WARN_UNINITIALIZED\, PL_warn_uninit\,   " in "\, PL_op_desc[PL_op->op_type]);   else   Perl_warner(aTHX_ WARN_UNINITIALIZED\, PL_warn_uninit\, ""\, ""); }

And here's how you go there​:

Breakpoint 1\, Perl_report_uninit () at sv.c​:221 221 if (PL_op) (gdb) bt #0 Perl_report_uninit () at sv.c​:221 #1 0x73c92 in Perl_sv_2pv (sv=0x101c24\, lp=0xdfbfd91c) at sv.c​:2157 #2 0x65e21 in Perl_pp_concat () at pp_hot.c​:151 #3 0x6521b in Perl_runops_debug () at run.c​:56 #4 0x577d in S_run_body (oldscope=1) at perl.c​:1395 #5 0x5382 in perl_run (my_perl=0xf5030) at perl.c​:1319 #6 0x177f in main (argc=3\, argv=0xdfbfd9d0\, env=0xdfbfd9e0) at perlmain.c​:52 (gdb) p *PL_op $3 = {op_next = 0x103080\, op_sibling = 0x1030c0\,   op_ppaddr = 0x65c88 \<Perl_pp_concat>\, op_targ = 1\, op_type = 66\, op_seq = 6\,   op_flags = 6 '\006'\, op_private = 2 '\002'}

That sure looks like a concat op to me. Do you have a suggested code patch? Shall we just stop telling them things they don't understand? I happen to appreciate knowing what opcode was unhappy with me\, but if it's too much for folks\, I guess we should delete this feature.

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

To resolve this bug I would like to see one of two things happen​:

It's not a bug. It may not be a feature\, but it's not a bug. The best way to resolve it is with a doc patch.

1. Remember whether we are doing variable interpolation or if the user actually spelled it out with '.' between each part of the string\, and give either "... in concatenation (.)" or "... in string interpolation" as the warning\, or

I'd like to see the patch for that. Shall we invent new opcode types and just toss compiler optimizations to the wind just because people are dumb?

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen writes​:

To resolve this bug I would like to see one of two things happen​:

It's not a bug. It may not be a feature\, but it's not a bug. The best way to resolve it is with a doc patch.

Giving the user incorrect data is a bug. There's no "." in that line of code\, so even though it optimizes to a line that contains "."\, it doesn't help the user unless he/she knows that. Most Perl programmers don't know much about the way Perl works internally and wouldn't necessarily assume that it optimizes things that way. A doc patch would help a little\, but I don't think that's enough.

Simply saying "use of uninitialized variable in line xxx" is fine\, but once you start trying to tell the user what operator went wrong\, you have to be accurate when you do so.

1. Remember whether we are doing variable interpolation or if the user actually spelled it out with '.' between each part of the string\, and give either "... in concatenation (.)" or "... in string interpolation" as the warning\, or

I'd like to see the patch for that. Shall we invent new opcode types and just toss compiler optimizations to the wind just because people are dumb?

I'm sure the patch for that would be a pain in the ass to implement. It might be the wrong trade-off in terms of performance.

I just think that if you're going to try to tell the user what caused the error\, you should tell them what actually caused it. And since the user didn't use '.' in that spot\, it would cause a lot of confusion trying to hunt it down.

Also\, remember that novices are often told to turn on warnings\, and so they would be the most likely to be bit by this problem.

--Bill.

-- William R Ward hermit@​bayview.com http​://www.bayview.com/~hermit/

---

The secret of being creative is making something that's not very new but just a little bit different in the right direction - Marvin Minsky

[p5pRT]

From [Unknown Contact. See original ticket]

Simply saying "use of uninitialized variable in line xxx" is fine\, but once you start trying to tell the user what operator went wrong\, you have to be accurate when you do so.

That *was* accurate. They just are unable to understand that accuracy.

I'm sure the patch for that would be a pain in the ass to implement. It might be the wrong trade-off in terms of performance.

I just think that if you're going to try to tell the user what caused the error\, you should tell them what actually caused it. And since the user didn't use '.' in that spot\, it would cause a lot of confusion trying to hunt it down.

Patches speak louder than words.

Also\, remember that novices are often told to turn on warnings\, and so they would be the most likely to be bit by this problem.

  use strict;   use warnings;

It's more than just a good idea.

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen writes​:

That is\, however\, what's happening​:

% perl -MO=Deparse\,-q -e '@​scalar = @​array = (1..10); print "this $sc\ @​scalar = (@​array = (1\, 2\, 3\, 4\, 5\, 6\, 7\, 8\, 9\, 10)); print 'this ' . $scalar . ' and that ' . join($"\, @​array) . "\n";

Many years ago when I started doing Perl I picked up the idea that it is always more efficient to do double-quote interpolation than spelling it out with '.' between each element. Of course\, that was in the days of Perl4. I assume that is no longer a concern?

The v4 compiler didn't do at compile time the things the v5 compiler does.

Was it ever\, or was I misinformed? I've done a lot of Perl hacking\, but have never spent time digging around in the actual interpreter itself.

These days\, it's the compiler you should be thinking about here. By which point\, the interpreter just does what it's told.

I also was told that if there are no variables to be interpolated to always use single quotes rather than double quotes\, as the extra parsing required was expensive. Is/was this true?

As far as "expensive" goes\, that one belongs up there with the advice to eschew comments and whitespace as it takes longer to parse them. There may be semantic difference to consider\, of course. Still\, double quotes tend to stand out better than single ones. Notice how many technical book publishers get their single vs back quotes completely messed up. I wouldn't be surprised if there weren't folks who used double quotes just so they could see them better.

--tom

[p5pRT]

From @tamias

On Thu\, Mar 30\, 2000 at 08​:12​:12PM -0800\, William R. Ward wrote​:

Simply saying "use of uninitialized variable in line xxx" is fine\, but once you start trying to tell the user what operator went wrong\, you have to be accurate when you do so.

I agree. The same correction was made for the comparison operators; originally the warning did not distinguish between numeric and string comparison operators. The warning should accurately reflect the code as written.

Ronald

[p5pRT]

From [Unknown Contact. See original ticket]

I don't think you want to start down this path. We have a compiler. It does things for you. You have to learn this.

  % perl -e 'if(0) { 1; FRED​: 2; 3 } goto FRED'   Can't find label FRED at -e line 1.

Huh\, what do you mean you can't find the label? It's right there! What a stupid compiler.

  % perl -MO=Deparse -e 'if(0) { 1; FRED​: 2; 3 } goto FRED'
  '???';   goto FRED;

or this one​:

  % perl -MO=Deparse -e 'if (1) { print "now" } else { print "then" }'   print 'now';;   -e syntax OK

or this one​:

  % perl -ce 'if (eval { sqrt(-10); 1 } ) { print "ok" } '   Can't take sqrt of -10 at -e line 1.

or this​:

  % perl -e 'sub neg10() { -10 } if (eval { sqrt neg10(); 1 } ) { print "ok" } '   Can't take sqrt of -10 at -e line 1.

Lok at that\, it's compile-only\, and it still copmlains. I never told the compiler to take the sqrt of -10. I said to take it of neg10(). Er\, didn't I?

Again\, are you *REALLY* sure you want to go down this road and unravel all the things the compiler and do and then say which will confuse the ignorant? Isn't it better to cure ignorance -- or\, failing that\, simply ignore them?

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

I agree. The same correction was made for the comparison operators; originally the warning did not distinguish between numeric and string comparison operators. The warning should accurately reflect the code as written.

So\, you prefer a nonoptimizing compiler\, eh?

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen writes​:

I agree. The same correction was made for the comparison operators; originally the warning did not distinguish between numeric and string comparison operators. The warning should accurately reflect the code as written.

So\, you prefer a nonoptimizing compiler\, eh?

I would prefer warnings the way they used to be\, if it's that hard.

--Bill.

-- William R Ward hermit@​bayview.com http​://www.bayview.com/~hermit/

---

The secret of being creative is making something that's not very new but just a little bit different in the right direction - Marvin Minsky

[p5pRT]

From @tamias

On Thu\, Mar 30\, 2000 at 09​:26​:54PM -0700\, Tom Christiansen wrote​:

I agree. The same correction was made for the comparison operators; originally the warning did not distinguish between numeric and string comparison operators. The warning should accurately reflect the code as written.

So\, you prefer a nonoptimizing compiler\, eh?

Yes\, but only if I get a turn putting words in your mouth. ;)

Ronald

[p5pRT]

From [Unknown Contact. See original ticket]

I would prefer warnings the way they used to be\, if it's that hard.

The "used to be" way was less information. That's just stupid. If the kiddies aren't old enough to know the truth\, tell them to use BASIC.

Or you can go back to Perl4. Or hey\, try python. Its compiler doesn't do squat for you. Which\, apparently\, is a feature.

--tom

[p5pRT]

From @tamias

On Thu\, Mar 30\, 2000 at 08​:29​:00PM -0800\, William R. Ward wrote​:

Tom Christiansen writes​:

I agree. The same correction was made for the comparison operators; originally the warning did not distinguish between numeric and string comparison operators. The warning should accurately reflect the code as written.

So\, you prefer a nonoptimizing compiler\, eh?

I would prefer warnings the way they used to be\, if it's that hard.

I would prefer your Option #2\, "... in concatenation (.) or interpolation ... "

Specifying the operator involved is too useful to back out over one point of confusion.

Ronald

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen writes​:

I would prefer warnings the way they used to be\, if it's that hard.

The "used to be" way was less information. That's just stupid. If the kiddies aren't old enough to know the truth\, tell them to use BASIC.

Less information is better than wrong information.

--Bill.

-- William R Ward hermit@​bayview.com http​://www.bayview.com/~hermit/

---

The secret of being creative is making something that's not very new but just a little bit different in the right direction - Marvin Minsky

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen writes​:

I would prefer warnings the way they used to be\, if it's that hard.

The "used to be" way was less information. That's just stupid. If the kiddies aren't old enough to know the truth\, tell them to use BASIC.

Less information is better than wrong information.

This is the last time I'm going to say it​: it's not wrong information. You just don't understand why it's right. There are millions of cases like this.

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

I would prefer your Option #2\, "... in concatenation (.) or interpolation ... "

Never mind. Just delete the messages. That one is worse. I guess that you were both right after all​: People who aren't smart enough to use accurate information don't deserve it.

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Tom Christiansen writes​:

Tom Christiansen writes​:

I would prefer warnings the way they used to be\, if it's that hard.

The "used to be" way was less information. That's just stupid. If the kiddies aren't old enough to know the truth\, tell them to use BASIC.

Less information is better than wrong information.

This is the last time I'm going to say it​: it's not wrong information. You just don't understand why it's right. There are millions of cases like this.

I understand perfectly well why it says that. But it's still wrong because the warning message is telling the user that there is a "." which is causing a problem on such-and-such line. There is no "." (or if there is\, it isn't what it's complaining about). Therefore it is wrong. QED.

--Bill.

-- William R Ward hermit@​bayview.com http​://www.bayview.com/~hermit/

---

The secret of being creative is making something that's not very new but just a little bit different in the right direction - Marvin Minsky

[p5pRT]

From [Unknown Contact. See original ticket]

I understand perfectly well why it says that. But it's still wrong because the warning message is telling the user that there is a "." which is causing a problem on such-and-such line. There is no "." (or if there is\, it isn't what it's complaining about). Therefore it is wrong. QED.   ^^^

I hate misuse of that term.

Fine. Go delete the part that says "(.)". Now we'll get the kiddies whingeing because they're too slow to handle the big catty word.

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

On Thu\, Mar 30\, 2000 at 08​:12​:12PM -0800\, William R. Ward wrote​:

Simply saying "use of uninitialized variable in line xxx" is fine\, but once you start trying to tell the user what operator went wrong\, you have to be accurate when you do so.

I agree. The same correction was made for the comparison operators; originally the warning did not distinguish between numeric and string comparison operators. The warning should accurately reflect the code as written.

I don't think there's anything "dumb" about a user potentially (or in reality) being confused by a message that describes a concatenation operator but refers to a line containing only a double-quoted string. It looks more like Perl is the dummy here.

Let's consider the notion that users should shoulder responsibility for deciphering "best effort" messages from the compiler. Personally\, I find that repugnant. Bogus error messages and\, to a lesser extent\, poor error recovery (leading to a cascade of seriously bogus error messages) are the product of poor design\, poor engineering\, and/or poor programming. It is possible for a compiler to generate accurate\, appropriate error messages. It's just not all that common nowadays.

During the ten or so years when I was writing interpreters and compilers off and on as part of my work\, I took pride in my attempts (mostly successful) to have my software generate sensible parse and run-time error messages. Because users often interacted with me directly\, and because I generally worked as a contractor\, I never had the option of telling my users "Well\, if you don't know what my software is telling you\, it's not my problem. You're just stupid." I mean\, we've all had idiot users\, but since when is a software tool supposed to be\, on its face\, an intellectual challenge for its users? So when users came to me and told me\, "Hey\, I have no idea what this error is\," I tried to make it clearer. Generating error messages that even an idiot can (potentially) understand is a source of pride\, not shame\, for me.

I'm dumbfounded that anyone would take a position that not only accepts Perl's sometimes (often?) poor error handling\, but in fact advocates it\, as though Perl should be some kind of continually stimulating intellectual puzzle. I'm even more amazed when the poor messages in question come from the warnings feature\, which is ostensibly present in large part for the benefit of the less clueful. Is the point here that Perl should always be confusing\, even if you activate the features that are supposed to make it safer and friendlier?

I think it's clear on its face that "Use of uninitialized value in concatenation (.)" as described in the original message is inappropriate behavior. Dragging "it's the same ops" into the issue is silly. That's the reason for the misbehavior\, of course\, but it doesn't excuse the poor message.

I've never thought Perl should be a language that deliberately gets in your way\, like the school bully crowding the doorway\, asking for your lunch money. Or in this case\, asking you to find the hidden dot operator.

  -joseph

[p5pRT]

From [Unknown Contact. See original ticket]

--- Tom Christiansen \tchrist@&#8203;chthon\.perl\.com wrote​:

I agree. The same correction was made for the comparison operators; originally the warning did not distinguish between numeric and string comparison operators. The warning should accurately reflect the code as written.

So\, you prefer a nonoptimizing compiler\, eh?

Why make this into an argument about the stupidity of people who don't know the compiler internals? Is "knowing how to use Deparse\, and how to follow its output for large programs" going to be the new minimum bar for acceptable knowledge of Perl? That seems unreasonable.

The suggestions to make the message non-specific as to the operator involved would make things clearer to the user\, and not break anything.

What's wrong with that?

[p5pRT]

From [Unknown Contact. See original ticket]

--- Tom Christiansen \tchrist@&#8203;chthon\.perl\.com wrote​:

Tom Christiansen writes​:

I would prefer warnings the way they used to be\, if it's that hard.

The "used to be" way was less information. That's just stupid. If the kiddies aren't old enough to know the truth\, tell them to use BASIC.

Less information is better than wrong information.

This is the last time I'm going to say it​: it's not wrong information. You just don't understand why it's right. There are millions of cases like this.

Ah\, I see now. Ok\, then\, the solution is (in Tom's mind) to append "Please use the Deparse feature so you can understand this message" to every message that might result from optimizations?

I'm sorry if I'm extending this argument needlessly\, but I think it's just plain _wrong_ to require the end user of a compiler to understand the internal optimizations just to decode the error messages.

Especially when many acceptable (to everyone but TomC apparently) alternatives exist.

How about making the message "Use of uninitialized value $... on line xxx (in operator . after optimization)". The phrasing clearly needs work :)

Then the users at least have a hint as to where the mysterious . came from.

[p5pRT]

From [Unknown Contact. See original ticket]

Mike Giroux (lists.p5p)​:

I'm sorry if I'm extending this argument needlessly\, but I think it's just plain _wrong_ to require the end user of a compiler to understand the internal optimizations just to decode the error messages.

Oh\, for heaven's sake\, stop being ridiculous. It's nothing to do with the internal optimisations. It's about the user working out what the error messages mean. And if the user can't even be expected to do that - and I don't want pass Perl users off as that stupid\, even if you're happy to do so - the user has perldiag.

You know we have perldiag\, right? You know we have it for a reason?

[p5pRT]

From [Unknown Contact. See original ticket]

Lightning flashed\, thunder crashed and "Joseph N. Hall" \joseph@&#8203;5sigma\.com whi spered​: | I don't think there's anything "dumb" about a user potentially (or | in reality) being confused by a message that describes a concatenation | operator but refers to a line containing only a double-quoted string. | It looks more like Perl is the dummy here.

Well said Joseph. I was beginning to remember why I quit reading P5P while reading this thread. I'm glad there are still a few voices of reason here.

Tom\, saying that just because an underlying implementation detail is accurate\, doesn't make it accurate in this case. Think about if I brought you a car and the windshield wipers didn't work. If I told you "I think there's something wrong with the wiper motor" would you argue "actually\, it isn't the motor that is the problem\, it is the electromagnets inside the motor that aren't working correctly."

-spp

[p5pRT]

From [Unknown Contact. See original ticket]

Tom\, saying that just because an underlying implementation detail is accurate\, doesn't make it accurate in this case. Think about if I brought you a car and the windshield wipers didn't work. If I told you "I think there's something wrong with the wiper motor" would you argue "actually\, it isn't the motor that is the problem\, it is the electromagnets inside the motor that aren't working correctly."

Yeah whatever\, Mr Smarty Pants. I don't see any patches about this issuing from *your* neck of the woods. Perhaps you should just go back to your non-reading status\, since with that would come also non-whining. Until you have a concrete suggestion about precisely how to go about "fixing" this non-bug particularly in light of the related matters you're ignoring\, you're just pissing in the wind.

SUMMARY​: Less pissing\, more patching!

For years people whined about not knowing what operators were causing that warning. Now that they're actually being told\, they whine about not being smart enough to understand what an operator *is*. Talk about punching a gift horse in the mouth! You get something valuable you didn't have before\, and all you can do it complain. Well\, you don't deserve it then\, now do you? Kindly examine opcode.h and explain which kind of opcode you expect us to be using here. Hint​: it's not pp_stringify.

The simple fact is that string "interpolation" is just syntactic sugar for catenation. This happens in more places than you're even thinking about right now. It's too bad if you're unwilling or unable to understand that\, but that's just your tough luck\, now isn't it?

Shall we break the following just to pacify the ignorant?

% cat /tmp/a print \<\<EOF\, qq'what $x is that?'\, This here little expansion of the bogus var $x that we have sure is fun\, isn't it? EOF qx{   echo 'And tell me\, how do   you feel about this $x\,   eh there?' }\, $\,\, qx'echo "oh boy\, here is $x all over again"'\, $y . $x . $y;

Notice all those catenative constructs!

% perl -w /tmp/a Use of uninitialized value in concatenation (.) at /tmp/a line 1. Use of uninitialized value in concatenation (.) at /tmp/a line 1. Use of uninitialized value in concatenation (.) at /tmp/a line 1. Use of uninitialized value in concatenation (.) at /tmp/a line 1. Use of uninitialized value in concatenation (.) at /tmp/a line 1. Use of uninitialized value in concatenation (.) at /tmp/a line 1. Use of uninitialized value in print at /tmp/a line 1. This here little expansion of the bogus var that we have sure is fun\, isn't it? what is that?And tell me\, how do   you feel about this \,   eh there? oh boy\, here is all over again

As you can plainly see\, the interpreter is faithfully and honestly reporting the condition of the code the compiler handed it​:

% perl -MO=Deparse\,-q /tmp/a print "This here little\nexpansion of \nthe bogus\nvar " . $x . " that we have \nsure is fun\, isn't it?\n"\, 'what ' . $x . ' is that?'\, `\n echo 'And tell me\, how do \n\t you feel about this $x\, \n\t eh there?'\n`\, $\,\, `echo "oh boy\, here is \n\$x all over again"`\, $y . $x . $y;

I suppose you expect `` to say one thing and qx() another thing\, too? And of course\, those silly heredocs better tell you just what they are -- none of this concat business. Tell me\, what's the herdoc opcode? When you write it\, make sure that they also say what the problem was and where within the string it occurred\, their ending strings\, their real line numbers\, everything. I do hope you intend that that be "fixed" as well.

The solution is simple​: Go for it\, Stephen! Go create us a bunch of spurious opcode types in you interpreter redesign. While you're at it\, don't forget to fix the line numbers\, since of course that little problem with print didn't occur at line 1\, but further on in the middle of various here docs (that don't even confess to their nature or terminating strings!)\, which I expect to see you fix to say where in the source code these occurred. Make sure you can tell the difference between a symbolically specified "\n" and a literal linefeed\, too\, since one ought to add a line number and the other oughtn't. You get to figure out which is which. Oh\, and do please fix the stunning lack of variable names. What cheek! I fully expect perl to tell me the name of the variable that went awry.

Or\, perhaps\, especially since I don't see you "fixing" a million other things pilot brain damage effects--let alone this one--maybe just maybe you might possibly instead consider trying to educate away this ignorance rather than locking it in. Offer up your patch to perldiag and perltrap\, and probably to other places\, too. If you must be squeaky wheel\, then you should be greasing your own squeaks.

But maybe I'm wrong. Maybe it *is* better that programmers not be told about any of this at all\, since that would be a lot easier than actually doing what we can to keep them honestly informed. Instead of teaching how any sort of string expansion--irrespective of any syntactic sugar such as heredocs or the various denotations for dq-strings or backticks--is really a compile-time catena of individual operations\, we could if you insist instead go back to what many consider the bad old days of making them guess the operator. Or we could go back even further to the dark ages when the compiler didn't actually compile interpolation at compile time and make it an idiotically redundant and gratuitously error-prone run-time operation again.

Where's your plan\, Stephen? Patches speak louder than words. Offer up your patch\, you or any others who about this might squeak\, and let then that patch be duly judged.

SUMMARY​: Less squeaking\, more patching!

--tom

[p5pRT]

From @tamias

On Fri\, Mar 31\, 2000 at 01​:31​:08PM +0000\, Simon Cozens wrote​:

Mike Giroux (lists.p5p)​:

I'm sorry if I'm extending this argument needlessly\, but I think it's just plain _wrong_ to require the end user of a compiler to understand the internal optimizations just to decode the error messages.

Oh\, for heaven's sake\, stop being ridiculous. It's nothing to do with the internal optimisations. It's about the user working out what the error messages mean. And if the user can't even be expected to do that - and I don't want pass Perl users off as that stupid\, even if you're happy to do so - the user has perldiag.

You know we have perldiag\, right? You know we have it for a reason?

=item Use of uninitialized value%s

(W uninitialized) An undefined value was used as if it were already defined. It was interpreted as a "" or a 0\, but maybe it was a mistake. To suppress this warning assign a defined value to your variables.

Please be so kind as to point out which part of that paragraph explains that interpolation becomes concatenation when the code is compiled.

We could just as easily encode each error message as a unique integer\, and then expect the user to 'work out what the error messages mean'. If the error message is written properly\, its meaning should be clear.

Ronald

[p5pRT]

From [Unknown Contact. See original ticket]

I would prefer your Option #2\, "... in concatenation (.) or interpolation ... "

% perl -lwe '@​a[0\,2] = (0\,2); print "@​a $a"\, "$a"\, $a' Use of uninitialized value in join at -e line 1. Use of uninitialized value in concatenation (.) at -e line 1. Use of uninitialized value in string at -e line 1. Use of uninitialized value in print at -e line 1.

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Note also that the interpreter sometimes does concatenation that the user doesn't see\, it sometimes also does *NOT* do concatenation that the user *DOES* see​:

% perl -MO=Deparse\,-q -e 'print "foo" . " bar"' print 'foo bar';

% perl -Dx -e 'print "foo" . " bar"' { 6 TYPE = leave ===> DONE   FLAGS = (VOID\,KIDS\,PARENS)   REFCNT = 0   { 1 TYPE = enter ===> 2   }   { 2 TYPE = nextstate ===> 3   FLAGS = (VOID)   LINE = 1   PACKAGE = "main"   }   { 5 TYPE = print ===> 6   FLAGS = (VOID\,KIDS)   { 3 TYPE = pushmark ===> 4   FLAGS = (SCALAR)   }   { 4 TYPE = const ===> 5   FLAGS = (SCALAR)   SV = PV("foo bar"\0)   }   } }

Look! No concat operator!

--tom

[p5pRT]

From @tamias

On Fri\, Mar 31\, 2000 at 09​:21​:54AM -0700\, Tom Christiansen wrote​:

I would prefer your Option #2\, "... in concatenation (.) or interpolation ... "

% perl -lwe '@​a[0\,2] = (0\,2); print "@​a $a"\, "$a"\, $a' Use of uninitialized value in join at -e line 1. Use of uninitialized value in concatenation (.) at -e line 1. Use of uninitialized value in string at -e line 1. Use of uninitialized value in print at -e line 1.

Ick... That does make a difference in what to do about the possible confusion.

So\, if the warning were changed\, that would be more like​:

% perl -lwe '@​a[0\,2] = (0\,2); print "@​a $a"\, "$a"\, $a' Use of uninitialized value in join/string at -e line 1. Use of uninitialized value in concatenation (.)/string at -e line 1. Use of uninitialized value in string at -e line 1. Use of uninitialized value in print at -e line 1.

Are there other warnings\, besides "Use of uninitialized value"\, that specify an operator? Perhaps a patch to perldiag that explains this issue would be preferred?

Ronald

[p5pRT]

From [Unknown Contact. See original ticket]

I'll grant that it seems as if Perl's innards were designed with the sole objective of making it hard to distinguish between an explicit use of dot and a concatenation arising from interpolation.

The simple fix is just change the message.

  Use of uninitialized value in concatenation (.)

Becomes

  Use of uninitialized value in concatenation (.) or string interpolation

which would mean changing a line in opcode.h. I don't see any problem with calling the concat op "concatenation (.) or string interpolation" because that's an accurate description of what it is. It's not just the dot operator.

The only way to effect a fix that actually distinguishes between is to introduce some change to an op or a new op\, and it would be difficult. I can see three basic options​:

(1) split concatenation into different ops

(2) add something to the concatenation op that indicates what kind of   concatenation it is

(3) add another type of marker op like COP that marks the begin/end of   string interpolation (and indicates what sort of string it is etc.)

(1) seems like a Bad Idea\, (2) seems unlikely to work because by the time a concat op gets generated\, the context of how it was generated is already lost in the lexer. But (3) might work.

What are the negatives of (3)? It adds bytecode bloat\, probably a small but significant amount (1-5 percent?) because string interpolation is a common operation. It probably has no significant effect on speed. It's hard to implement and would add more obfuscation to the lexer.

So I vote for the one-liner fix. I dispute the claim that the current message is "accurate information" because\, as I said above\, the concat op in the innards of perl is not just the dot operator\, and therefore characterizing it as such is inaccurate from both the perspective of the naive user and from the perspective of what's really happening.

It's unfortunate that the design of the lexer and run-time innards don't allow for a good error message\, but that's how it is.

  -joseph

[p5pRT]

From [Unknown Contact. See original ticket]

Seems to me there is a book in here somewhere​:

"Learning and Testing Perl with One Liners"

does anyone know any perl authors?

cliff rayman genwax.com

Tom Christiansen wrote​:

I don't think you want to start down this path. We have a compiler. It does things for you. You have to learn this.

% perl \-e 'if\(0\) \{ 1; FRED​: 2; 3 \} goto FRED'
Can't find label FRED at \-e line 1\.

Huh\, what do you mean you can't find the label? It's right there! What a stupid compiler.

% perl \-MO=Deparse \-e 'if\(0\) \{ 1; FRED​: 2; 3 \} goto FRED'
'???';
goto FRED;

or this one​:

% perl \-MO=Deparse \-e 'if \(1\) \{ print "now" \} else \{ print "then" \}'
print 'now';;
\-e syntax OK

or this one​:

% perl \-ce 'if \(eval \{ sqrt\(\-10\); 1 \} \) \{ print "ok" \} '
Can't take sqrt of \-10 at \-e line 1\.

or this​:

% perl \-e 'sub neg10\(\) \{ \-10 \} if \(eval \{ sqrt neg10\(\); 1 \} \) \{ print "ok" \} '
Can't take sqrt of \-10 at \-e line 1\.

Lok at that\, it's compile-only\, and it still copmlains. I never told the compiler to take the sqrt of -10. I said to take it of neg10(). Er\, didn't I?

Again\, are you *REALLY* sure you want to go down this road and unravel all the things the compiler and do and then say which will confuse the ignorant? Isn't it better to cure ignorance -- or\, failing that\, simply ignore them?

--tom

[p5pRT]

From [Unknown Contact. See original ticket]

Are there other warnings\, besides "Use of uninitialized value"\, that specify an operator? Perhaps a patch to perldiag that explains this issue would be preferred?

There are many\, but I don't know of a simple way to find them all. For example​:

Perl_croak(aTHX_ "Can't coerce %s to integer in %s"\, sv_reftype(sv\,0)\,   PL_op_desc[PL_op->op_type]);

Perl_warner(aTHX_ WARN_NUMERIC\,   "Argument \"%s\" isn't numeric in %s"\, tmpbuf\,   PL_op_desc[PL_op->op_type]);

Perl_croak(aTHX_ "Can't coerce %s to string in %s"\, sv_reftype(sv\,0)\,   PL_op_name[PL_op->op_type]);

I don't know that there are many (or any?) that are as inherently confusing as the issue with concat\, though.

The classic example of "bad error message that probably seemed like a good idea at the time" of course​:

/usr/local/bin/perl5.003 -we '"@​foo"' Literal @​foo now requires backslash at -e line 1\, within string Execution of -e aborted due to compilation errors.

perl -we '"@​foo"' In string\, @​foo now must be written as \@​foo at -e line 1\, near "@​foo" Execution of -e aborted due to compilation errors.

The first message seems quite reasonable to someone who knows the history of "foo@​bar.com" but as anyone who read clpm in those days knows\, it totally baffled newbies\, who rightfully were unable to draw any parallels between the behavior of "$undefined_thingy" and "@​undefined_thingy" or understand what the meaning of "Literal @​foo" was or where the "required" backslash should go. The current message doesn't explain the crux of the problem but at least it leaves the user at the station rather than putting him on the wrong train out of town -- AND if he reads perldiag he'll get some reasonable clues.

I'm not completely convinced that adding markers to the bytecode stream to indicate when run-time interpolation is in effect is such a bad idea. It might allow finer-grained control over interpolation (with overload? or?) as well as more accurate Deparse\, both of which might turn out to be quite valuable. Just to resolve the problem with the warning message\, though\, it's way too much work.

  -joseph

[p5pRT]

From [Unknown Contact. See original ticket]

At 12​:26 PM 3/31/00 -0700\, Joseph N. Hall wrote​:

I'm not completely convinced that adding markers to the bytecode stream to indicate when run-time interpolation is in effect is such a bad idea. It might allow finer-grained control over interpolation (with overload? or?) as well as more accurate Deparse\, both of which might turn out to be quite valuable. Just to resolve the problem with the warning message\, though\, it's way too much work.

An added field could be thrown into the opcodes\, but the problem with that is the opcodes take even more memory than they used to. They keep getting bigger\, and I think we're seeing slowdowns as it is from larger opcodes. (The bigger they are the fewer fit in a page or the processor cache\, though we're pretty profligate with D-space as it is)

It might be worth doing to opcodes what we do to SVs and make the opcode itself smaller with the 'extras' hanging off a secondary structure\, but I don't know that it'd be a win overall.

  Dan

--------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@​sidhe.org have teddy bears and even   teddy bears get drunk

[p5pRT]

From [Unknown Contact. See original ticket]

William R. Ward writes​:

1. Remember whether we are doing variable interpolation or if the user actually spelled it out with '.' between each part of the string\, and give either "... in concatenation (.)" or "... in string interpolation" as the warning\, or

Easy.

  a) Define 2 new opcodes concat_qq and joint_qq with proper descriptions.

  b) Put

  #define pp_concat_qq pp_concat   #define pp_join_qq pp_join

  c) Make tokenizer produce these opcodes instead of OP_JOIN and OP_CONCAT.

Basically\, it is a 6-lines patch.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri\, 31 Mar 2000 14​:42​:52 -0500 dan@​sidhe.org (Dan Sugalski) wrote​:

* At 12​:26 PM 3/31/00 -0700\, Joseph N. Hall wrote​: * >I'm not completely convinced that adding markers to the bytecode * >stream to indicate when run-time interpolation is in effect is such * >a bad idea. It might allow finer-grained control over interpolation * >(with overload? or?) as well as more accurate Deparse\, both of which * >might turn out to be quite valuable. Just to resolve the problem * >with the warning message\, though\, it's way too much work. * * An added field could be thrown into the opcodes\, but the problem with that * is the opcodes take even more memory than they used to. They keep getting * bigger\, and I think we're seeing slowdowns as it is from larger opcodes. * (The bigger they are the fewer fit in a page or the processor cache\, though * we're pretty profligate with D-space as it is)

I doubt that is really a problem for the ages\, though. In the near future\, if not now\, caches will be large and/or capable enough that cache busting really isn't something to design against. Nevermind that there is one Perl and a zillion different cache architectures.

* It might be worth doing to opcodes what we do to SVs and make the opcode * itself smaller with the 'extras' hanging off a secondary structure\, but I * don't know that it'd be a win overall.

What is going on at runtime is already so complex that I wonder how much more indirection and complexity would be worthwhile. My biggest objection to adding more stuff to the guts of Perl isn't that it makes Perl bigger or slower\, but that it brings the guts closer to "write-only" as far as current and possible future developers/patchers are concerned. Bigger and slower are problems that 6 months of progress in the CPU wars will solve. Incomprehensible is a problem that is almost impossible to solve.

I'm certainly impressed at all the indirection that has crept into the guts. My look at sprintf the other day and this message issue today have made it clear to me that C/C++ acumen and smarts and good programming skills are not enough qualification to work on even relatively simple Perl patches. Which brings up the notion that "patches welcome" might at times be more a vacuous retort than a real offer\, but I shouldn't go there.

  -joseph

[p5pRT]

From [Unknown Contact. See original ticket]

At 01​:01 PM 3/31/00 -0700\, Joseph N. Hall wrote​:

On Fri\, 31 Mar 2000 14​:42​:52 -0500 dan@​sidhe.org (Dan Sugalski) wrote​:

* At 12​:26 PM 3/31/00 -0700\, Joseph N. Hall wrote​: * >I'm not completely convinced that adding markers to the bytecode * >stream to indicate when run-time interpolation is in effect is such * >a bad idea. It might allow finer-grained control over interpolation * >(with overload? or?) as well as more accurate Deparse\, both of which * >might turn out to be quite valuable. Just to resolve the problem * >with the warning message\, though\, it's way too much work. * * An added field could be thrown into the opcodes\, but the problem with that * is the opcodes take even more memory than they used to. They keep getting * bigger\, and I think we're seeing slowdowns as it is from larger opcodes. * (The bigger they are the fewer fit in a page or the processor cache\, though * we're pretty profligate with D-space as it is)

I doubt that is really a problem for the ages\, though. In the near future\, if not now\, caches will be large and/or capable enough that cache busting really isn't something to design against. Nevermind that there is one Perl and a zillion different cache architectures.

Ick. No offense but I absolutely loathe that particular attitude. I've got a VAXStation II/GPX (with a whopping 1/3 VUPs of power) around that I like to work on when I've got time--if things run OK there they should run nicely anywhere.

Perl itself is getting slower with each release and that's troublesome. Machines get faster\, but data volumes get larger faster. I may be unusual in chugging through runs of 80G of data and 10-20M files at a shot\, but not *that* unusual.

* It might be worth doing to opcodes what we do to SVs and make the opcode * itself smaller with the 'extras' hanging off a secondary structure\, but I * don't know that it'd be a win overall.

What is going on at runtime is already so complex that I wonder how much more indirection and complexity would be worthwhile. My biggest objection to adding more stuff to the guts of Perl isn't that it makes Perl bigger or slower\, but that it brings the guts closer to "write-only" as far as current and possible future developers/patchers are concerned. Bigger and slower are problems that 6 months of progress in the CPU wars will solve. Incomprehensible is a problem that is almost impossible to solve.

Well\, Topaz is supposed to take care of the complexity issues\, at least somewhat. And the guts themselves are pretty near incomprehensible to mere mortals.

I'm certainly impressed at all the indirection that has crept into the guts. My look at sprintf the other day and this message issue today have made it clear to me that C/C++ acumen and smarts and good programming skills are not enough qualification to work on even relatively simple Perl patches.

The guts are pretty much beyond the reach of most everyone\, and honestly I think they'll *always* stay that way. Perl's not simple under the hood\, and neither is any programming language of any significance. We could partition things out so it was easier to understand and expand individual bits\, and we could certainly document it better\, but I think the bar's pretty high and will always stay that way in general.

  Dan

--------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@​sidhe.org have teddy bears and even   teddy bears get drunk

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri\, 31 Mar 2000 15​:22​:35 -0500 dan@​sidhe.org (Dan Sugalski) wrote​:

* At 01​:01 PM 3/31/00 -0700\, Joseph N. Hall wrote​:

* >I doubt that is really a problem for the ages\, though. In the near * >future\, if not now\, caches will be large and/or capable enough that * >cache busting really isn't something to design against. Nevermind * >that there is one Perl and a zillion different cache architectures. * * Ick. No offense but I absolutely loathe that particular attitude. [...] * Perl itself is getting slower with each release and that's troublesome. * Machines get faster\, but data volumes get larger faster. I may be unusual * in chugging through runs of 80G of data and 10-20M files at a shot\, but not * *that* unusual.

If it's a choice between "faster" and "more useful" in Perl\, I'll come down on the side of "more useful" just about every time. That said\, Perl has more speed and memory "issues" than it seems like it ought to. The huge growth in the core from 5.005 to 5.6 without any serious new fully-operational functionality is rather disappointing to me.

  -joseph

[p5pRT]

From [Unknown Contact. See original ticket]

Joseph N. Hall writes​:

The huge growth in the core from 5.005 to 5.6 without any serious new fully-operational functionality is rather disappointing to me.

It looks like you think that 5.6 is out. It is not. 5.6.0 is a late alpha release of 5.6. Nothing more.

We did not even start a public beta cycle yet. Mind boggles why it was thought advantageous to release late-alpha-quality code as an "official release". With the disaster of 5.005_00 the explanation was the pressure from commercial entities (ORA and AS).

Who was pressing Sarathy for a premature ejaculation of 5.6.0? The only significant timestamp I can see around is a release of PP v3 (when?). Was it a pressure from ORA this time too? Was it the pressure from Larry & co?

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

At 01​:31 PM 3/31/00 -0700\, Joseph N. Hall wrote​:

On Fri\, 31 Mar 2000 15​:22​:35 -0500 dan@​sidhe.org (Dan Sugalski) wrote​:

* At 01​:01 PM 3/31/00 -0700\, Joseph N. Hall wrote​:

* >I doubt that is really a problem for the ages\, though. In the near * >future\, if not now\, caches will be large and/or capable enough that * >cache busting really isn't something to design against. Nevermind * >that there is one Perl and a zillion different cache architectures. * * Ick. No offense but I absolutely loathe that particular attitude. [...] * Perl itself is getting slower with each release and that's troublesome. * Machines get faster\, but data volumes get larger faster. I may be unusual * in chugging through runs of 80G of data and 10-20M files at a shot\, but not * *that* unusual.

If it's a choice between "faster" and "more useful" in Perl\, I'll come down on the side of "more useful" just about every time. That said\, Perl has more speed and memory "issues" than it seems like it ought to. The huge growth in the core from 5.005 to 5.6 without any serious new fully-operational functionality is rather disappointing to me.

I'll disagree this time. We've added a lot of functionality (well\, sort of) to this release\, and perl's overdue for a good performance boost. Honestly I think a performance and stability work-through should be the primary focus for the 5.8 release\, with getting the current alpha/experimental stuff either working or tossed as a secondary goal. We can add in more functionality for 5.9/5.10.

What we really need is three or four people who can work on perl near full-time for this\, but that's not likely to happen\, for economic reasons if nothing else. :(

  Dan

--------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@​sidhe.org have teddy bears and even   teddy bears get drunk

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri\, 31 Mar 2000 15​:39​:04 -0500 (EST) ilya@​math.ohio-state.edu (Ilya Zakharevich) wrote​:

* Joseph N. Hall writes​: * > The huge growth in the core from 5.005 to 5.6 without any serious new * > fully-operational functionality is rather disappointing to me. * * It looks like you think that 5.6 is out. It is not. 5.6.0 is a late * alpha release of 5.6. Nothing more. * * We did not even start a public beta cycle yet. Mind boggles why it * was thought advantageous to release late-alpha-quality code as an * "official release". With the disaster of 5.005_00 the explanation was * the pressure from commercial entities (ORA and AS). * * Who was pressing Sarathy for a premature ejaculation of 5.6.0? The * only significant timestamp I can see around is a release of PP v3 * (when?). Was it a pressure from ORA this time too? Was it the * pressure from Larry & co?

I'll leave it to you hypothesize motive\, but I don't see much that is new and working\, yet. Threads? Compiler? Unicode? ("no") x 3\, for the moment.

I don't see what's the point in inflicting module rebuilds on a population that isn't getting a whole lot of new functionality for its trouble\, but I guess that's where we're at.

I'll have the mindset "5.6 is out and ready to use" when at least one of qw(threads compiler unicode) is pronounced stable and robust. For now\, it's just a new release that appears to be roughly as stable as 5.005_03\, with roughly the same feature set. Maybe I'm missing something.

  -joseph

[p5pRT]

From [Unknown Contact. See original ticket]

At 01​:49 PM 3/31/00 -0700\, Joseph N. Hall wrote​:

I'll leave it to you hypothesize motive\, but I don't see much that is new and working\, yet. Threads? Compiler? Unicode? ("no") x 3\, for the moment.

Well\, there's IThreads and fork() on Win32\, along with a lot of infrastructure work\, but you're right that not much visible has changed.

Maybe for 5.6.1.

  Dan

--------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@​sidhe.org have teddy bears and even   teddy bears get drunk

[p5pRT]

From @doughera88

On Fri\, 31 Mar 2000\, Joseph N. Hall wrote​:

I don't see what's the point in inflicting module rebuilds on a population that isn't getting a whole lot of new functionality for its trouble\, but I guess that's where we're at.

For most systems\, 5.6.0 shouldn't be inflicting module rebuilds. 5.6.0 is generally binary compatible with 5.005_03\, and will\, by default\, search for and successfully use your old 5.005_03 modules.

  Andy Dougherty doughera@​lafayette.edu   Dept. of Physics   Lafayette College\, Easton PA 18042

[p5pRT]

From @gsar

On Fri\, 31 Mar 2000 15​:39​:04 EST\, Ilya Zakharevich wrote​:

It looks like you think that 5.6 is out. It is not. 5.6.0 is a late alpha release of 5.6. Nothing more.

We did not even start a public beta cycle yet. Mind boggles why it was thought advantageous to release late-alpha-quality code as an "official release". With the disaster of 5.005_00 the explanation was the pressure from commercial entities (ORA and AS).

Who was pressing Sarathy for a premature ejaculation of 5.6.0? The only significant timestamp I can see around is a release of PP v3 (when?). Was it a pressure from ORA this time too? Was it the pressure from Larry & co?

If anyone honestly thinks that somebody pressured me into releasing 5.6.0 prematurely\, them I'm truly disappointed.

I set about making a 5.6.0 release because​:

  * Nobody but me was working to make the now experimental features   stable   * I ran out of time a _long_ time ago (you wouldn't believe the   amount of "real work" that has slipped just so I can herd the Perl   cats into reasonable shape for a release)   * It's been too long since there has been a proper release\, and   what we had had enough bug fixes to be a proper release on its   own merits   * I entertain vague hopes that perhaps putting out a release will   spur contributions to address the experimental features

Binary builds of the beta releases (provided by ActiveState) were tested by upwards of 50\,000 individuals (on Windows\, Linux\, and Solaris). In terms of sheer numbers\, I doubt that any other major release has been as widely tested as 5.6.0 has been.

Sarathy gsar@​ActiveState.com

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri\, Mar 31\, 2000 at 01​:49​:29PM -0800\, Gurusamy Sarathy wrote​:

I set about making a 5.6.0 release because​:

* Nobody but me was working to make the now experimental features stable

I understand your frustration about this fact. However\, allow me to note that IMO this may be explained in part by your ways to treat patches sent to p5p.

Say\, now I have very little interest in participation in Perl development.

* I ran out of time a _long_ time ago (you wouldn't believe the amount of "real work" that has slipped just so I can herd the Perl cats into reasonable shape for a release)

There is no way to make a bullet-proof whatever.whatever.0 release. However\, since we know it is *very much* flawed\, having it mentioned in the announcement would look more proper.

* It's been too long since there has been a proper release\, and what we had had enough bug fixes to be a proper release on its own merits

This is a double-edge argument. Since it was so long\, having an extra couple of months of a public beta (even if marked as 5.6.0!) would not make things any more delayed.

* I entertain vague hopes that perhaps putting out a release will spur contributions to address the experimental features

Definitely. We on p5p have a clear understanding of the (mis)quality of 5.6.0\, so will not deploy it as if it were a stable release. So *for us* an early release is a plus​: more testing\, more bug reports etc.

However\, it does not look fair wrt poor sysadms who are pressed by lusers "there is a latest and greatest new release\, we need it NOW!".

Ilya

[p5pRT]

From @gsar

On Fri\, 31 Mar 2000 17​:47​:30 EST\, Ilya Zakharevich wrote​:

* I ran out of time a _long_ time ago (you wouldn't believe the amount of "real work" that has slipped just so I can herd the Perl cats into reasonable shape for a release)

There is no way to make a bullet-proof whatever.whatever.0 release. However\, since we know it is *very much* flawed\, having it mentioned

This is pure FUD. AFAIK\, 5.6.0 has fewer bugs than 5.005_03 does.

If you think otherwise\, prove it. (For proof to the contrary\, you can start by running the 5.6.0 testsuite with 5.005_03. ;-)

in the announcement would look more proper. [...]

* I entertain vague hopes that perhaps putting out a release will spur contributions to address the experimental features

Definitely. We on p5p have a clear understanding of the (mis)quality of 5.6.0\, [...]

Er\, I think you're in the Land of Conclusions again.

Sarathy gsar@​ActiveState.com

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri\, 31 Mar 2000 15​:39​:04 -0500 (EST) ilya@​math.ohio-state.edu (Ilya Zakharevich) wrote​:

* Joseph N. Hall writes​: * > The huge growth in the core from 5.005 to 5.6 without any serious new * > fully-operational functionality is rather disappointing to me. * * It looks like you think that 5.6 is out. It is not. 5.6.0 is a late * alpha release of 5.6. Nothing more. * * We did not even start a public beta cycle yet. Mind boggles why it * was thought advantageous to release late-alpha-quality code as an * "official release". With the disaster of 5.005_00 the explanation was * the pressure from commercial entities (ORA and AS). * * Who was pressing Sarathy for a premature ejaculation of 5.6.0? The * only significant timestamp I can see around is a release of PP v3 * (when?). Was it a pressure from ORA this time too? Was it the * pressure from Larry & co?

Ilya\,

Speaking both for O'Reilly and for everyone involved with the Camel​:

  No\, we did not pressure Sarathy to release 5.6.0.

In fact\, from O'Reilly's perspective\, it would have been better had Sarathy delayed the release until closer to the conference.

Is the Camel forcing a new release of Perl? No. Is this conference forcing releases of Perl? No.
Is this conference forcing the next edition of the Camel? Yes.

-Jon

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri\, 31 Mar 2000 18​:14​:40 -0500 (EST) orwant@​oreilly.com (Jon Orwant) wrote​:

* Ilya\, * * Speaking both for O'Reilly and for everyone involved with the Camel​: * * No\, we did not pressure Sarathy to release 5.6.0. * * In fact\, from O'Reilly's perspective\, it would have been better had * Sarathy delayed the release until closer to the conference. * * Is the Camel forcing a new release of Perl? No. * Is this conference forcing releases of Perl? No. * Is this conference forcing the next edition of the Camel? Yes.

I wouldn't imagine there was any outside pressure to release 5.6.0. From a bugfix standpoint it seems like a good idea to release something\, and I don't see how it could have been called 5.005_04\, because of all the changes in the guts. But on the other hand\, considering that there isn't much visible change and that the "major" features haven't advanced very much\, and the amount of new stuff that doesn't (fully) work has increased rather than decreased\, calling it 5.6.0 with the fanfare associated with a major release will probably turn out to be a miscue.

Maybe it should have been called 5.5.5 or something like that.

Just my opinion of course. Cat's out of the bag now and it's not a disaster\, just underwhelming. Good excuse for XS module authors to rev their code if nothing else.

Of course\, the improvements in the core modules count too\, and that's probably more user-visible. BUT where is all that documented. Not in any central location\, is it?

  -joseph