HDTenEightyP/NetNews huggingface dataset:
From: bill@ksr.com (Bill Mann)
Newsgroups: comp.lang.perl
Subject: Re: Perl language formatting conventions?
Date: 27 Aug 92 16:47:23 EDT
	<1992Aug25.152315.20630@news.eng.convex.com>
Distribution: comp
Organization: Kendall Square Research, Waltham, MA
In-reply-to: tchrist@convex.COM's message of 25 Aug 92 11:23:15 EDT

In article <1992Aug25.152315.20630@news.eng.convex.com> tchrist@convex.COM (Tom Christiansen) writes:
> From the keyboard of dave@pipi.iis.u-tokyo.ac.jp (David Wuertele):
> :Is there a Perl formatting convention similar to the one for C advocated
> :by GNU?  Since Perl derives a bit of syntax from C I have been using that
> :instead, but the perl-mode.el tab function seems to want to format things
> :differently.
> :
> : ...
>
> I think that the GNU guidelines (which I've only ever read in what
> you've posted) are pretty ugly.  
>
> A friend of mine would like to see a style guide for Perl code 
> similar to the BSD KNF (Berkeley's Kernel Normal Form), which is
> actually pretty much what I (and Larry) seem to use.  I'm actually
> trying to develop this, but it's not ready for publication yet.

Personally, I try to use the existing style when maintaining code or
documentation.  New standards are fine for major rewrites or new
development, but within limits style is pretty much a matter of taste.

For a table showing how to customize perl-mode for various styles,
type ^hm while in perl-mode, and look near the bottom of the *Help*
buffer.  The default values where chosen to match the style Larry
uses, and which I like.

Bill Mann
bill@ksr.com (ksr!bill@uunet.uu.net)
--

Bill Mann
bill@ksr.com (ksr!bill@uunet.uu.net)
Newsgroups: comp.lang.perl
From: rray@lookout.it.uswc.uswest.com (Randy J. Ray)
Subject: Using $*, but pattern doesn't match
Organization: US WEST Communications, Inc. -- Denver, CO
Date: Tue, 25 Aug 1992 18:18:18 GMT

I am trying to match a multi-line pattern. I have set $* in the subroutine that
is performing the match. I have a string called $body that contains several
lines of perl code, read in from a file. The lines are newline-terminates (I
did not chop them). An example value of $body would be:
   
    local(*logflag, *syntax_OK, *prj, *rls1, *rls1_tar, *rls2, *rls2_tar,
           *pltfrm) =  @_;

	.
	. [deleted for breveity]
	.

    $syntax_OK = 1;
    return(1);

The whole text is not important; it is the body of a subroutine, after the 
"sub <name> {" and before the ending "}". To this string, I am doing a search:

$body =~ /$SUBARGS/o

Where $SUBARGS is a pseudo-constant (it is known to never change), hence the
'o' modifier. The value of $SUBARGS is:

^\s+local\s*\((.*)\)\s*=\s*\@_\s*;

Which *should* match the local() declaration that handles the passed arguments
to said subroutine, leaving the list of arguments in $1. It works fine if the
local() declaration is on one line, but with the above example it fails to
match. I thought that ".* would match anything (up to a final ")" in this case)
with $* set to 1?

No stylistic flames, please. This tool is written to do analysis on perl
scripts developed with a specific set of coding standards.

Randy
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Randy J. Ray -- U S WEST IT/CSD         rray@{lookout,uswat}.it.uswc.uswest.com
I'd rather talk religion with Charles Manson than discuss ethics with Congress.
     -me                                                   Phone: (303)595-2852
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: lwall@netlabs.com (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: Novice questions
Date: 27 Aug 92 06:00:25 GMT
Organization: NetLabs, Inc.

In article <17h2onINNrt0@darkstar.UCSC.EDU> haynes@cats.ucsc.edu (Jim Haynes) writes:
: 
: 1.  what's the current version?  Using archie I find 4.019 and 4.035
: both - is one of these considered the current production version?

4.035 could be considered slightly currenter, though both of them are pretty
stable.

: 2.  where to send bug reports?

lwall@netlabs.com or this newgrope.

: Please reply via email.

That too.

: "Any clod can have the facts, but having opinions is an Art."
:         Charles McCabe, San Francisco Chronicle

That's a fact, in my opinion.

Larry
From: cracraft@rice-chex.ai.mit.edu (Stuart Cracraft)
Newsgroups: comp.lang.perl
Subject: leaving a block
Date: 4 Sep 92 04:09:07 GMT
Organization: MIT Artificial Intelligence Lab


What is the best way of leaving a non-looped block?
Stuart Cracraft
Toshiba America & Project GNU
Newsgroups: comp.lang.perl
From: robt@is.morgan.com (Rob Torop)
Subject: perl user's digest
Organization: Morgan Stanley & Company
Distribution: comp.lang.perl
Date: Thu, 3 Sep 1992 13:15:52 GMT

How can I subscribe to the perl user's digest that people have been
mentioning?  Is it posted here, and I misssed it?  Thanks.


--
-- Rob Torop

+---------------------------------------------------------------------+
| The views expressed here are neither mine nor those of my employer. |
+---------------------------------------------------------------------+
Newsgroups: comp.lang.perl
From: jfriedl+@CS.CMU.EDU (Jeffrey Friedl)
Subject: Re: Just another Perl hacker
Reply-To: jfriedl@cs.cmu.edu
Organization: Carnegie Mellon / Omron Corporation
Date: Wed, 26 Aug 1992 03:17:38 GMT

|> >Ok, so why isn't there an Obfuscated Perl Contest?
|> 
|> Every day is a Obfuscated Perl Contest.

Other people have mentioned this, and I don't think it (should be) true.
Poor programmers can write unreadable code in any language.
Good programmers can write readable in any language.

(Ok, so I made a gramatical mistake in using "poor" above, but I'm talking
about programming languages, so I can claim to be a "good" programmer and
still write unreadable English :-)

If you can believe it, I've even seen (and written) non-trivial yet
readable programs in FORTH.

If a perl program or construct is not easily readable by someone with
"reasonable" knowledge of perl (vagueness is intentional), perhaps it's
been written poorly.
(there, now I've got the usage of "poor" correct :-).

	*jeff*
-------------------------------------------------------------------------
Jeffrey Eric Francis Friedl   jfriedl@cs.cmu.edu -or- jfriedl@omron.co.jp
Omron Corporation, Section RZE, Shimokaiinji, Nagaokakyo Kyoto 617, Japan
Visiting researcher to the Mach Project, Carnegie Mellon University
Newsgroups: comp.lang.perl
From: Tom Christiansen <tchrist@convex.COM>
Subject: Re: Using $*, but pattern doesn't match
Originator: tchrist@pixel.convex.com
Date: Wed, 26 Aug 1992 01:42:29 GMT
Reply-To: tchrist@convex.COM (Tom Christiansen)
Organization: Convex Computer Corporation, Colorado Springs, CO
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

From the keyboard of ram@eiffel.com (Raphael Manfredi):
:>    Though I'll admit readability suffers slightly... 
:>                    --Larry Wall in <2969@jato.Jpl.Nasa.Gov>
:
:Your quote fits perfectly. Do you have an intelligent signature daemon
:behind your ~/.signature named pipe ? :-)

Maybe, but if so, the question then becomes whether the demon is a
fallen one or not. :-)

Really, it happens all the time.  Now maybe it's just because I send out
so much mail and news articles that occasionally it's bound to appear to
have special relevance (and certainly my comp.lang.perl selections differ
from my alt.usage.english ones) but it occurs with such frequency that I
have occasion to shake my head at least daily.

--tom
-- 
    Tom Christiansen      tchrist@convex.com      convex!tchrist

    "There is no problem so big that it cannot be run away from."                  
	_Illusions_, Richard Bach
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.lang.perl
Subject: Re: locsym - First major upgrade ;-)
Date: 28 Aug 92 19:57:47 GMT

Marvelous little program! Much better than the  clumsy  sh  tool  that
I've been using.  I'll keep my old one around for use on systems where
I can't sneak perl in, but locsym is definitely  better,  even  if  it
does get its speed by using a chunk of disk.

There was, however, one very curious "bug" in both of the versions, as
they reached here.  They contained the line:

X		if (/^.*\s+[ATDS]\s+([^_.].*)/o) { $symbol = $1 };

The perl here rejected this because the sequence of tokens  "$1 }"  is
not  legal.   I  changed the last two chars to ";}" and it worked just
fine.  It was a bit of a surprise that version 2 had the same problem.

Is this legal syntax in some later patch that I don't have?  The  perl
here  probably  isn't up to date, but I've never even seen this syntax
before, or any hint that it might actually be legal.  Or  did  perhaps
some  demented mailer along the path munge just these two bytes?  This
is one of the weirder problems that I've seen in all my years of being
a computer weenie ...

| This is perl, version 4.0
| $RCSfile: perl.c,v $$Revision: 4.0.1.4 $$Date: 91/06/10 01:23:07 $
| Patch level: 10

Newsgroups: comp.lang.perl
From: dhami@cs.ubc.ca (Mandeep S Dhami)
Subject: A comparison (was simple question?)
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Date: Thu, 27 Aug 92 03:56:05 GMT

Purely out of curiosity:

$x="ffefab30";
$y=join(".",grep($_=hex,unpack("a2a2a2a2",$x)));
$y=join(".", unpack("C4", pack("N", hex($x))));  <-- 17% faster (of 1000 iter.)

# After all it has 4 fn. calls compared to 7 in 1st (though hex is
# quicker than others).

Mandeep.

--
__________________________________________________________________
"I'm very brave generally," he went on in a low voice:
"only to-day I happen to have a headache."
                                      -- Lewis Carroll
From: lwall@netlabs.com (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: how to 'write' cr-nl
Date: 2 Sep 92 06:38:34 GMT
Organization: NetLabs, Inc.

In article <400@carssdf.UUCP> watson@carssdf.UUCP (John Watson -- Self Empl. Sys.Integrator) writes:
: In article <ASHERMAN.92Sep1091415@laser.fmrco.com> asherman@fmrco.COM writes:
: >What's wrong with:
: >
: >format STDOUT =
: >@<<<<<<<<<<<<<<<<<< Test: @>>>>>>>>>>>> ^M
: >.
: 
: My problem here, besides forgeting to put it in on a line or two, and
: creating a debugging mess is possibily
: 
: entering spaces after the ^M which are not visible by the vi editor,
: creating leading white space on the next line.

It shouldn't do that, because formats drop any trailing spaces on the line.

Alternative 1.

    format STDOUT =
    @<<<<<<<<<<<<<<<<<< Test: @>>>>>>>>>>>> @
    $foo,                     $bar,        "\r"
    .

Alternative 2.

    $child = open(STDOUT, "|-");
    die "Phooey" unless defined $child;
    if (!$child) {
	$\ = "\r\n";
	while (<STDIN>) {
	    chop;
	    print;
	}
	exit;
    }

Larry
From: lwall@netlabs.com (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: 4.035 bug or feature...why does this run?
Date: 28 Aug 92 18:56:20 GMT
Organization: NetLabs, Inc.

In article <BtnMC5.51s@news.cso.uiuc.edu> ejk@ux2.cso.uiuc.edu (Ed Kubaitis - CCSO) writes:
: -->Subject: relaxed requirement for semicolon at the end of a block

Yes, but note that it's still recommended that you use semicolon in
general.  You *have* to use it if you want to be backward compatible.
You *ought* to use it for readability and ease of maintenence unless
you're writing very short block that fits on one line along with its
braces:

    sort { $a <=> $b } @list;
    sub println { print @_,"\n" }
    do { &one } until $done;

but

    do {
	&one;	# Put semicolon in case you add another statement after.
    } until $done;

Basically, it's one of those features that you can't use in a portable
program right now, but maybe in a year or two it'll start to be considered
portable when most everyone's running version 5.  

(On the other hand, I *still* don't use enums in C.  Probably mere paranoia
by now...}

Larry
From: kentd@FtCollins.NCR.com (Kent Dalton)
Newsgroups: comp.lang.perl
Subject: Any documentation on the perl test suite?
Date: 26 Aug 92 08:12:43 GMT
Reply-To: Kent.Dalton@FtCollinsCO.NCR.com
Distribution: world
Organization: NCR Microelectronics, Ft. Collins, CO


I'm porting perl to a new platform (AmigaDOS 2.04) and am having some
trouble getting it to pass all of the regression tests (in the t/
directory of the standard distribution.)... 

Since I'm a perl novice (I have to port it before I can learn it :^), I
don't necessarily understand what all the tests are trying to do. I do
have the camel book as a reference, so I can figure it out eventually..
but, I was hoping there might be some documentation somewhere on what
each test is basically trying to do. I don't need a line by
line analysis, just an overview of what is being tested, etc. 

Any help would be much appreciated.
--
/**************************************************************************/
/* Kent Dalton                   * EMail: Kent.Dalton@FtCollinsCO.NCR.COM */
/* NCR Microelectronics          * Phone: (303) 223-5100 X-319            */  
/* 2001 Danfield Ct. MS470A      *   FAX: (303) 226-9556                  */
/* Fort Collins, Colorado 80525  *                                        */
/**************************************************************************/
..  hubub, hubub, HUBUB, hubub, hubub, hubub, HUBUB, hubub, hubub, hubub.
From: lwall@netlabs.com (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: select misses pending data on socket
Date: 1 Sep 92 21:31:09 GMT
Organization: NetLabs, Inc.

In article <1992Aug31.201931.14111@uvaarpa.Virginia.EDU> dov@menora.weizmann.ac.il writes:
: The print line of $rout shows that select reports that there is no data
: to be read on the socket. How can that be?

Because there isn't any data to be read on the socket.  It's already been
read into the stdio buffers.

Don't use select with <>.  Use sysread() or recv() instead.

I suppose I really ought to make select work with stdio, but that can
get gory...

Larry
From: zzassgl@uts.mcc.ac.uk (Geoff Lane)
Newsgroups: comp.lang.perl
Subject: Re: UTS idiosyncracies...
Date: 25 Aug 92 14:18:59 GMT
Organization: Manchester Computing Centre, Manchester, England, M13 9PL.

In article <1992Aug25.122422.6189@uvaarpa.Virginia.EDU> gaspar@stepsun.army.mil writes:
>
>   Just in case someone else out there has the (err...) great, good fortune to
>work on a UTS machine, I thought I would post this experience.  I was compiling
>4.035 on an Amdahl 300E running UTS 5.2 (upgrading from 4.019).
>Al Gaspar	<gaspar@st-louis-emh2.army.mil> <--Reply here


I would suggest that you get your UTS system upgraded to UTS 2.1.3.  UTS 5.2
is very old now and somewhat weird.  I've not tried to port 4.035 to our UTS
2.1.3 system yet but 4.019 went straight on and passed all tests within a
couple of hours.  There is a couple of nasties to look out for (ftell/fseek
use off_t [==long long on UTS] rather than long's and st_size has an unusual
type that must be taken care of) but nothing seriously broken.

 

-- 
Geoff. Lane.                                  Janet: zzassgl@uk.ac.mcc.uts
UTS Sys Admin, Manchester Computing Centre, Oxford Rd, Manchester, M13 9PL
Newsgroups: comp.lang.clos
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.clos
Subject: Re: Generic Macro Proposal (really interpreted/compiled semantics)
Date: 25 Aug 1992 17:53:59 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <10367.9208251621@subnode.aiai.ed.ac.uk> jeff@aiai.edinburgh.ac.uk (Jeff Dalton) writes:
>> Since the above program isn't conforming, anything is legal. 
>
>If this is what the dpANS says, I think it should change.  

Actually, I think I was overstating it.  Perhaps I should have said, "since
it isn't conforming, the standard doesn't specify which one it returns."

>							    Does anyone
>seriously think that the behavior of the following program is or
>should be completely undefined, ie that it might be anything at all?
>
>(defun g ()
>  (flet ((f (x) x))
>    (typep #'f 'compiled-function)))

Lisp's introspective facilities make it difficult to use general rules
about interpreter/compiler equivalence (we considered getting rid of the
COMPILED-FUNCTION type, though).  I agree that it's not totally undefined,
but it isn't well-defined whether it returns T or NIL.  Once it's been
compiled it's guaranteed to return T, but before then it could return
either.  On some systems it will return T all the time, even though these
systems use a traditional interpreter; to simplify FUNCALL and APPLY, they
implement interpreted functions as a closure of a compiled interpreter
function over the lambda expression.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: miller@FS1.cam.nist.gov (Bruce R. Miller)
Newsgroups: comp.lang.clos
Subject: Re: Beginner's Question - CLOS
Date: 26 Aug 92 16:53:12 GMT
Organization: NIST - Computing and Applied Mathematics Laboratory


In article <9208261407.AA05332@news.cis.ohio-state.edu>, cb writes:
> >It sounds like you don't need C++ as much as a Petri net compiler that
> >takes your nice object oriented specification and spits out fast code, like
> >a big PROG, for example.
> >
> >k
> 
> I could do that, but part of the reason I started doing this was
> to show that petri-nets are a good example of something that maps
> well into object-oriented simulation.  As far as the programming
> of it goes, it is real nice to represent Places and transitions as
> objects and have the actions on them represented as methods.  However,
> if it's that much faster to compile the petri net spec into non-object-based
> code, then its pretty hard to argue that object-oriented simulation is
> a good thing.
> 
> 
> Chris

Since I haven't much idea about Petri nets, I'm sticking my neck out,
but...
Maybe rather than object-oriented _simulation_ you might think about
object-oriented _compilation_;  If Lisp & Clos allow you to quickly
write a program which `compiles' the petri net into a fast running
program --- it can even write a C program for all I care --- then it's
served a worthwhile purpose, no?

Ie. rather than have the objects & methods simulate whatever, why not
have them produce code which does the simulation?

I've done something similar generating some impressively fast Fortran
code from Lisp.  I would have hated to deal with the datastructures to
do the same using C, and Fortran!?!?! Ha.  Nobody would have attempted
to write the generated code manually in Fortran.

In anycase, you invent a mini-language on top of lisp;  the
specification of the Petri net (whatever that may be), in effect,
becomes the program.
Newsgroups: comp.lang.clos
From: bil@cmn16.Stanford.EDU (Bill Schottstaedt)
Subject: shared :initarg problem in August 4 PCL
Organization: DSO, Stanford University
Date: Thu, 27 Aug 92 13:46:02 GMT


In August PCL (8/4/92), using a shared :INITARG to initialize two slots at  
once breaks in INITIALIZE-INSTANCE-SIMPLE with the error:
		Error: bad index to nthcdr: -1
This has worked in all earlier releases of PCL.
Im using: Allegro CL 3.1.20 [NeXT] (3/7/91)
Copyright (C) 1985-1990, Franz Inc., Berkeley, CA, USA
=====
<cl> (in-package :pcl)
#<The PCL package, 2958 internal, 136 external>

<cl> (defclass foo ()
       ((list :initarg :list)
        (head :initarg :list)))
#<Standard-Class FOO 135516001>

<cl> (make-instance 'foo :list ())
Error: bad index to nthcdr: -1
[1] <cl> :zoom
Evaluation stack:

 ->(ERROR "bad index to nthcdr: ~s" -1)
   (NTHCDR -1 NIL)
   (INITIALIZE-INSTANCE-SIMPLE #(T 1) ((INSTANCE-SET 1  
#<Standard-Effective-Slot-Definition LIST 135521071>)) (:LIST NIL) #<FOO  
135676621>)
   (#:|.INITIALIZE-INSTANCE-SIMPLE-FUNCTION.ae45a0e2| #<FOO 135676621>  
(:LIST NIL))
   (|MAKE-INSTANCE FOO (:LIST) NIL| FOO (:LIST NIL))
   (MAKE-INSTANCE FOO :LIST NIL)
   (EVAL (MAKE-INSTANCE 'FOO :LIST NIL))
   (EXCL::START-REBORN-LISP)
[1] <cl>
---
Rick Taube
Zentrum fuer Kunst und Medientechnologie
Karlsruhe, Germany
hkt@zkm.de



(Respond to Rick, not me -- I am just a human gateway -- Bill).
Newsgroups: comp.lang.clos
From: rharris@unix.ecs.rpi.edu (Richard Harris)
Subject: Re: August 28 PCL
Organization: Rensselaer Design Research Center, RPI, Troy, NY
Date: Tue, 1 Sep 1992 19:07:58 GMT

I have not tested this PCL in Allegro 3.1 yet.  
I will be doing that today.  I will let you know what I find.

My email address is rharris@rdrc.rpi.edu.

  Richard Harris

Newsgroups: comp.lang.clos
From: rpg%inferno@lucid.com (Richard P. Gabriel)
Subject: Beginner's Question - CLOS
Organization: The Ohio State University Department of Computer and Information Science
Date: Tue, 25 Aug 1992 17:35:03 GMT

I have a broad view. I used to work for Lawrence Livermore National
Laboratories, which is a nuclear weapons design lab. All we cared
about is the performance of programs that ran for weeks on Crays.

I wrote the book ``Performance and Evaluation of Lisp Systems'' in
which I pointed out that it is improper to assign to any one benchmark
the overall `performance' of a Lisp system. If you assume a reasonably
competent programmer (I use this as a shorthand for designer/coder),
it is most likely that things like dispatch don't happen as the only
operation in the only inner loop that matters. More likely to affect
performance is the design of the algorithms and the data structures.

In my shop we did a several person-decade project in C++ during which
I witnessed a factor of 3 productivity decline over the Lisp group. By
my reckoning, using C++ instead of Lisp cost me $4,000,000 (US), and
the end result was no faster (as judged by comparing it with a similar
Lisp-written product) than it would have been in Lisp.


			-rpg-
Newsgroups: comp.lang.clos
From: jonl%kuwait@lucid.com (Jon L White)
Subject: Beginner's Question - CLOS
Organization: The Ohio State University Department of Computer and Information Science
Date: Tue, 25 Aug 1992 19:22:51 GMT

re: it is most likely that things like dispatch don't happen as the only
    operation in the only inner loop that matters. More likely to affect
    performance is the design of the algorithms and the data structures.

Henry Baker has written a series of little papers, to be published 
in the upcoming issue of Lisp Pointers, in which he takes a revisionist
view of the actual code in your now-famous book.  Agreed that the 
point of the particular codes (i.e., Lisp Programs) is to serve as
as standard benchmark from some micro-areas of Lisp System performance, 
but one could view the code as expressing an algorithm for a certain 
problem.  In the latter view, Baker asks how a few clever re-coding tricks 
would have altered the end results.  Factors of 10 and more pop up.  As 
you say, "design of the algorithms . . ."

Check it out in Lisp Pointers.


-- JonL --