search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.85k stars 523 forks source link

A minor list->array change in perlsub manpage #5155

Closed p5pRT closed 21 years ago

p5pRT commented 22 years ago

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

Searchable as RT8705$

p5pRT commented 22 years ago

From tagunov@motor.ru

This is a bug report for perl from "Anton Tagunov" \tagunov@​motor\.ru\, generated with the help of perlbug 1.33 running under perl v5.6.1.

Hi! The perlsub manpage has the following​:

-- (@​a\, @​b) = upcase(@​list1\, @​list2);

  Like the flattened incoming parameter list\, the return list is also flattened on return. So all you have managed to do here is stored everything in @​a and made @​b an empty list. --

Maybe better to write

--   ...and made @​b an empty array. --

?

Regards!

Flags​:   category=docs   severity=none

Site configuration information for perl v5.6.1​:

Configured by anthony at Wed Oct 31 20​:29​:27 2001.

Summary of my perl5 (revision 5 version 6 subversion 1) configuration​:   Platform​:   osname=MSWin32\, osvers=4.0\, archname=MSWin32-x86-multi-thread   uname=''   config_args='undef'   hint=recommended\, useposix=true\, d_sigaction=undef   usethreads=undef use5005threads=undef useithreads=define usemultiplicity=define   useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef   use64bitint=undef use64bitall=undef uselongdouble=undef   Compiler​:   cc='cl'\, ccflags ='-nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READFIX'\,   optimize='-O1 -MD -DNDEBUG'\,   cppflags='-DWIN32'   ccversion=''\, gccversion=''\, gccosandvers=''   intsize=4\, longsize=4\, ptrsize=4\, doublesize=8\, byteorder=1234   d_longlong=undef\, longlongsize=8\, d_longdbl=define\, longdblsize=10   ivtype='long'\, ivsize=4\, nvtype='double'\, nvsize=8\, Off_t='off_t'\, lseeksize=4   alignbytes=8\, usemymalloc=n\, prototype=define   Linker and Libraries​:   ld='link'\, ldflags ='-nologo -nodefaultlib -release -libpath​:"C​:\usr\local\lib\CORE" -machine​:x86'   libpth="E​:\apps\vc98\sdk.1\Lib\." "E​:\apps\ibm\db2p\LIB" "C​:\usr\local\lib\CORE"   libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib   perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib   libc=msvcrt.lib\, so=dll\, useshrplib=yes\, libperl=perl56.lib   Dynamic Linking​:   dlsrc=dl_win32.xs\, dlext=dll\, d_dlsymun=undef\, ccdlflags=' '   cccdlflags=' '\, lddlflags='-dll -nologo -nodefaultlib -release -libpath​:"C​:\usr\local\lib\CORE" -machine​:x86'

Locally applied patches​:   ACTIVEPERL_LOCAL_PATCHES_ENTRY

@​INC for perl v5.6.1​:   C​:/usr/local/lib   C​:/usr/local/site/lib   .

Environment for perl v5.6.1​:   HOME=C​:\   LANG (unset)   LANGUAGE (unset)   LC_ALL=EN_US   LD_LIBRARY_PATH (unset)   LOGDIR (unset)   PATH=E​:\apps\ibm\vaj\eab\bin;C​:\usr\local\bin\;e​:\Program Files\ibm\gsk5\lib;E​:\APPS\ROSE\RATION~1\NUTCROOT\bin;E​:\APPS\ROSE\RATION~1\NUTCROOT\bin\x11;E​:\APPS\ROSE\RATION~1\NUTCROOT\mksnt;e​:\java\sun\java131\bin;e​:\apps\vbroker\jre\Bin;e​:\apps\vbroker\Bin;C​:\WINNT\system32;C​:\WINNT;c​:\program files\util;E​:\apps\CacheSys\Bin;C​:\Program Files\rksupport;C​:\WINNT\ton\bin;E​:\apps\rose\common;E​:\apps\rose\Rational Test;E​:\apps\borland\delphi\Bin;E​:\apps\borland\delphi\Projects\Bpl;E​:\apps\ibm\IBM\IMNNQ;E​:\apps\ibm\db2p\BIN;E​:\apps\ibm\db2p\FUNCTION;E​:\apps\ibm\db2p\SAMPLES\REPL;E​:\apps\ibm\db2p\HELP;e​:\apps\ibm\websphere\bin   PERL_BADLANG (unset)   SHELL (unset)

p5pRT commented 22 years ago

From [Unknown Contact. See original ticket]

Hi! How about this?

Inline Patch ```diff --- pod/perlsub.pod.orig Wed Feb 20 18:02:38 2002 +++ pod/perlsub.pod Thu Mar 7 00:30:53 2002 @@ -169,7 +169,7 @@ Like the flattened incoming parameter list, the return list is also flattened on return. So all you have managed to do here is stored -everything in C<@a> and made C<@b> an empty list. See +everything in C<@a> and made C<@b> an empty array. See L for alternatives. A subroutine may be called using an explicit C<&> prefix. The @@ -727,8 +727,8 @@ sub ioqueue { local (*READER, *WRITER); # not my! - pipe (READER, WRITER); or die "pipe: $!"; - return (*READER, *WRITER); + pipe (READER, WRITER) or die "pipe: $!"; + return (*READER{IO}, *WRITER{IO}); } ($head, $tail) = ioqueue(); --end of patch-- ```

Have I been too bold with adding {IO}? To tell the truth I do not understand what is happening completely\, so it's again a blindfolded strike. I guess that with my patch instead of typeglobs this sample starts returning references to file handles.

Is that okay? Is that smth to recommend to people?

--

And a silly question to show me as a green novice\, not a hacker​: how can a typeglob be returned if it refers to a localized variable? Some magic?

- Anton

p5pRT commented 22 years ago

From @nwc10

On Thu\, Mar 07\, 2002 at 01​:25​:55AM +0300\, Anton Tagunov wrote​:

Hi! How about this?

--- pod/perlsub.pod.orig Wed Feb 20 18​:02​:38 2002 +++ pod/perlsub.pod Thu Mar 7 00​:30​:53 2002 @​@​ -169\,7 +169\,7 @​@​

Like the flattened incoming parameter list\, the return list is also flattened on return. So all you have managed to do here is stored -everything in C\<@​a> and made C\<@​b> an empty list. See +everything in C\<@​a> and made C\<@​b> an empty array. See

Not sure. I'd like to find a way to phrase that without describing @​b as either "list" or array. It's set to an empty list\, but it is an array. And finding a way of saying that without using either word feels best.

L\ for alternatives.

A subroutine may be called using an explicit C\<&> prefix. The @​@​ -727\,8 +727\,8 @​@​

 sub ioqueue \{
     local  \(\*READER\, \*WRITER\);    \# not my\!

- pipe (READER\, WRITER); or die "pipe​: $!"; - return (*READER\, *WRITER); + pipe (READER\, WRITER) or die "pipe​: $!"; + return (*READER{IO}\, *WRITER{IO}); } ($head\, $tail) = ioqueue();

--end of patch--

Have I been too bold with adding {IO}? To tell the truth I do not understand what is happening completely\, so it's again a blindfolded strike. I guess that with my patch instead of typeglobs this sample starts returning references to file handles.

Is that okay? Is that smth to recommend to people?

Not sure. I'm not sure what's going on with the IO\, but it's late an I'm tired. However\, I'm replying because I can see a syntax error that the patch removes\, and as nothing has been applied\, that syntax error remained.

Was there ever a feasible plan on how to automate syntax checking of all the code examples in the pod snippets?

[I remember this rant I had about perlipc once. (rant-and-patch\, IIRC) I also remember another thing that fell off my to-do list - try to make some of the perlipc examples into regression tests. That was related to the SOCKS5-rant]

Nicholas Clark -- Even better than the real thing​: http​://nms-cgi.sourceforge.net/

p5pRT commented 22 years ago

From [Unknown Contact. See original ticket]

Hello Nicholas!

AT> -everything in C\<@​a> and made C\<@​b> an empty list. See AT> +everything in C\<@​a> and made C\<@​b> an empty array. See

NC> Not sure. I'd like to find a way to phrase that without describing @​b as NC> either "list" or array. It's set to an empty list\, but it is an array. NC> And finding a way of saying that without using either word feels best.

What about

Inline Patch ```diff --- pod/perlsub.pod.orig Wed Feb 20 18:02:38 2002 +++ pod/perlsub.pod Mon Mar 11 23:23:43 2002 @@ -169,7 +169,7 @@ Like the flattened incoming parameter list, the return list is also flattened on return. So all you have managed to do here is stored -everything in C<@a> and made C<@b> an empty list. See +everything in C<@a> and made C<@b> empty. See L for alternatives. A subroutine may be called using an explicit C<&> prefix. The @@ -727,7 +727,7 @@ sub ioqueue { local (*READER, *WRITER); # not my! - pipe (READER, WRITER); or die "pipe: $!"; + pipe (READER, WRITER) or die "pipe: $!"; return (*READER, *WRITER); } ($head, $tail) = ioqueue(); ```

? :-))

AT> - return (*READER\, *WRITER); AT> + return (*READER{IO}\, *WRITER{IO}); AT> AT> Have I been too bold with adding {IO}? NC> Not sure. I'm not sure what's going on with the IO\, but it's late Err\, still curious\, is that any good ?

Regards\, Anton

p5pRT commented 22 years ago

From [Unknown Contact. See original ticket]

At 2002-03-11 23​:27​:47\, tagunov@​motor.ru wrote​:

--- pod/perlsub.pod.orig Wed Feb 20 18​:02​:38 2002 +++ pod/perlsub.pod Mon Mar 11 23​:23​:43 2002 @​@​ -169\,7 +169\,7 @​@​

Thanks\, applied. (#15190)

- ams

p5pRT commented 22 years ago

From @ysth

In article \19718223544\.20020307012555@&#8203;motor\.ru\, Anton Tagunov \tagunov@&#8203;motor\.ru wrote​:

- return (*READER\, *WRITER); + return (*READER{IO}\, *WRITER{IO});

Have I been too bold with adding {IO}? To tell the truth I do not understand what is happening completely\, so it's again a blindfolded strike. I guess that with my patch instead of typeglobs this sample starts returning references to file handles.

Is that okay? Is that smth to recommend to people?

--

And a silly question to show me as a green novice\, not a hacker​: how can a typeglob be returned if it refers to a localized variable? Some magic?

In general\, any local or my thing that has a reference to it stashed away somewhere (or\, in the case of GLOBs\, is returned or stored in some scalar that is available in some fashion after leaving the scope) doesn't actually get destroyed. The local restores the symbol table *READER and *WRITER at the end of the sub but you are left with a copy of the local version. (But for GLOBs it has a special FAKE flag that makes it fail in some circumstances--I forget where). In general\, you should use Symbol​::gensym now instead of local\, and globrefs instead of actual globs.

I wouldn't recommend using iorefs (what you get from *FOO{IO}) since I don't feel they have been used by enough people to shake the bugs out (play with readline *STDIN{IO} and print $.\, for instance; also they *look* like objects blessed into IO​::Handle (unless you've previously used FileHandle) but there is no provision for automatically loading IO​::Handle if you try to use them as objects; even if there was some such provision\, the FileHandle hack means you are at the mercy of any modules you use--if they happen to use FileHandle\, you won't get IO​::Handle methods available on the object).

I had hoped to stir up some interest in making IO thingies more accessible and dependable and get away from using globs as much as possible for 5.9.

p5pRT commented 22 years ago

From @nwc10

On Mon\, Mar 11\, 2002 at 10​:16​:23PM -0800\, Yitzchak Scott-Thoennes wrote​:

I wouldn't recommend using iorefs (what you get from *FOO{IO}) since I don't feel they have been used by enough people to shake the bugs out (play with readline *STDIN{IO} and print $.\, for instance; also they

I had hoped to stir up some interest in making IO thingies more accessible and dependable and get away from using globs as much as possible for 5.9.

How many of the bugs are encapsulated in TODO regression tests? Is it easy to take the regression tests for normal file handles\, and other the IO modules\, and turn them into *FOO{IO} thingy syntax? That at least would give everyone a start in knowing where the problems were.

[Although I'm not suggesting that such a patch got applied until until 5.9 appears after 5.8 is released (or escapes\, or whatever the term is)]

Nicholas Clark -- Even better than the real thing​: http​://nms-cgi.sourceforge.net/

p5pRT commented 22 years ago

From [Unknown Contact. See original ticket]

Yitzchak Scott-Thoennes \sthoenna@&#8203;efn\.org writes​:

In article \19718223544\.20020307012555@&#8203;motor\.ru\, Anton Tagunov \tagunov@&#8203;motor\.ru wrote​:

- return (*READER\, *WRITER); + return (*READER{IO}\, *WRITER{IO});

Have I been too bold with adding {IO}? To tell the truth I do not understand what is happening completely\, so it's again a blindfolded strike. I guess that with my patch instead of typeglobs this sample starts returning references to file handles.

Is that okay? Is that smth to recommend to people?

With perl5.6+ I would much rather recommend :

  sub ioqueue {   my ($reader\,$writer); # YES my!   pipe ($reader\, $writer) or die "pipe​: $!";   return ($reader\,$writer);   }

FWIW $reader/$writer are auto-vivified as references to globs not as references to IOs.

I wouldn't recommend using iorefs (what you get from *FOO{IO}) since I don't feel they have been used by enough people to shake the bugs out

A number of things don't work right with them. When they _are_ used what usually happens at C level it that a temporary glob is created\, the IO stored in it and then the glob is used :-(

I had hoped to stir up some interest in making IO thingies more accessible and dependable and get away from using globs as much as possible for 5.9.

Fine by me.

-- Nick Ing-Simmons http​://www.ni-s.u-net.com/

p5pRT commented 22 years ago

From [Unknown Contact. See original ticket]

Nicholas Clark \nick@&#8203;unfortu\.net writes​:

On Mon\, Mar 11\, 2002 at 10​:16​:23PM -0800\, Yitzchak Scott-Thoennes wrote​:

I wouldn't recommend using iorefs (what you get from *FOO{IO}) since I don't feel they have been used by enough people to shake the bugs out (play with readline *STDIN{IO} and print $.\, for instance; also they

I had hoped to stir up some interest in making IO thingies more accessible and dependable and get away from using globs as much as possible for 5.9.

How many of the bugs are encapsulated in TODO regression tests? Is it easy to take the regression tests for normal file handles\, and other the IO modules\, and turn them into *FOO{IO} thingy syntax?

I would rather we did not encourage the *FOO{IO} syntax - I don't think perl6 is going that way. Much better IMHO if we make the

open(my $fh\,...)

style the encouraged form.

Which is not to say that internals-wise it would not be better to use references to IO (why not just IOs?)

I know extra levels of indirection are handly sometimes - but 3​:

PerlIO *f = IoIFP(GvIO(SvRV(globref)));

Seems excessive.

That at least would give everyone a start in knowing where the problems were.

[Although I'm not suggesting that such a patch got applied until until 5.9 appears after 5.8 is released (or escapes\, or whatever the term is)]

Nicholas Clark -- Nick Ing-Simmons http​://www.ni-s.u-net.com/

p5pRT commented 22 years ago

From [Unknown Contact. See original ticket]

Nick Ing-Simmons wrote​:

Yitzchak Scott-Thoennes \sthoenna@&#8203;efn\.org writes​:

In article \19718223544\.20020307012555@&#8203;motor\.ru\, Anton Tagunov \tagunov@&#8203;motor\.ru wrote​:

- return (*READER\, *WRITER); + return (*READER{IO}\, *WRITER{IO});

Have I been too bold with adding {IO}? To tell the truth I do not understand what is happening completely\, so it's again a blindfolded strike. I guess that with my patch instead of typeglobs this sample starts returning references to file handles.

Is that okay? Is that smth to recommend to people?

With perl5.6+ I would much rather recommend :

sub ioqueue \{
    my \($reader\,$writer\);      \# YES my\!
    pipe    \($reader\,  $writer\)     or die "pipe&#8203;: $\!";
    return \($reader\,$writer\);
\}

Is there any reason not to write this as​:   sub ioqueue {   pipe( my ($reader\, $writer) ) or die "pipe​: $!";   return ($reader\, $writer);   } ? Or is that too obfuscated? :)

FWIW $reader/$writer are auto-vivified as references to globs not as references to IOs.

Once the bugs are all shaken out of them\, might they possibly be auto- vivified as IO refs? Or would this break too much old code?

I wouldn't recommend using iorefs (what you get from *FOO{IO}) since I don't feel they have been used by enough people to shake the bugs out

A number of things don't work right with them. When they _are_ used what usually happens at C level it that a temporary glob is created\, the IO stored in it and then the glob is used :-(

Ick... is there any way to get around that?

I had hoped to stir up some interest in making IO thingies more accessible and dependable and get away from using globs as much as possible for 5.9.

Fine by me.

-- print reverse( "\,rekcah"\, " lreP"\, " rehtona"\, " tsuJ" )."\n";

p5pRT commented 22 years ago

From [Unknown Contact. See original ticket]

Benjamin Goldberg \goldbb2@&#8203;earthlink\.net writes​:

With perl5.6+ I would much rather recommend :

sub ioqueue \{
    my \($reader\,$writer\);      \# YES my\!
    pipe    \($reader\,  $writer\)     or die "pipe&#8203;: $\!";
    return \($reader\,$writer\);
\}

Is there any reason not to write this as​: sub ioqueue { pipe( my ($reader\, $writer) ) or die "pipe​: $!"; return ($reader\, $writer); } ? Or is that too obfuscated? :)

See if it works - I think it will but​: A. I wasn't sure what a my() would do to pipe's "prototype". B. I was keeping code as similar as possible to what was   already there.

FWIW $reader/$writer are auto-vivified as references to globs not as references to IOs.

Once the bugs are all shaken out of them\, might they possibly be auto- vivified as IO refs? Or would this break too much old code?

That was the original plan - still makes sense.

I wouldn't recommend using iorefs (what you get from *FOO{IO}) since I don't feel they have been used by enough people to shake the bugs out

A number of things don't work right with them. When they _are_ used what usually happens at C level it that a temporary glob is created\, the IO stored in it and then the glob is used :-(

Ick... is there any way to get around that?

Tooth-combing the C code and tidying it up - I don't remember the culprits it is a long time since I looked.

I think main snag was/is that there is a handy C API to say "give me a GV" but not for "give me an IO"

I had hoped to stir up some interest in making IO thingies more accessible and dependable and get away from using globs as much as possible for 5.9.

Fine by me. -- Nick Ing-Simmons http​://www.ni-s.u-net.com/

p5pRT commented 22 years ago

From @ysth

In article \20020313084050\.1265\.5@&#8203;bactrian\.elixent\.com\, Nick Ing-Simmons \nick\.ing\-simmons@&#8203;elixent\.com wrote​:

Nicholas Clark \nick@&#8203;unfortu\.net writes​:

On Mon\, Mar 11\, 2002 at 10​:16​:23PM -0800\, Yitzchak Scott-Thoennes wrote​:

I wouldn't recommend using iorefs (what you get from *FOO{IO}) since I don't feel they have been used by enough people to shake the bugs out (play with readline *STDIN{IO} and print $.\, for instance; also they

I had hoped to stir up some interest in making IO thingies more accessible and dependable and get away from using globs as much as possible for 5.9.

How many of the bugs are encapsulated in TODO regression tests? Is it easy to take the regression tests for normal file handles\, and other the IO modules\, and turn them into *FOO{IO} thingy syntax?

I would rather we did not encourage the *FOO{IO} syntax - I don't think perl6 is going that way. Much better IMHO if we make the

open(my $fh\,...)

style the encouraged form.

I want that (eventually) to generate an IO reference\, not a glob ref.

Which is not to say that internals-wise it would not be better to use references to IO (why not just IOs?)

I think we need to use references since they are objects.

I know extra levels of indirection are handly sometimes - but 3​:

[Although I'm not suggesting that such a patch got applied until until 5.9 appears after 5.8 is released (or escapes\, or whatever the term is)]

Yes. (Assuming you don't mean to wait until 5.9.0 is actually released)

p5pRT commented 21 years ago

From @cwest

Bug fixed in change #15190.

p5pRT commented 21 years ago

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