HDTenEightyP/NetNews huggingface dataset:
From: lwall@netlabs.com (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: minor bug report (or interesting behavior)
Date: 14 Aug 92 01:14:13 GMT
Distribution: na
Organization: NetLabs, Inc.

In article <1992Aug6.154354.29565@spool.cs.wisc.edu> cargille@calypso.cs.wisc.edu (Allan Cargille) writes:
: 
: Hi, I just started using perl and didn't know where to send bug
: reports.  These may not even be bugs (depending on your definition, of
: course!)
: 
: 1.  I tried to use a format field of "@<<<<<<<<<<<<<<<>>>>>>>>>>>>>"
:     just for fun, to see if perl would justify both ends.  I invoked
:     perl and I assume it started to compile the code.  The machine
:     hung and the disk paged like crazy until I got an "out of memory"
:     error!  During this time I couldn't kill it with control-C or halt
:     it with control-Z.  Interesting.  I know the answer is "don't do
:     that!" but thought someone want to know.
: 
: 2.  Also trying for the same result, I tried a format statement of
: 	@<<<<<<<<<<<<<<<<<<@>>>>>>>>>>>>>>>>>>>>
: 	$_, $_
:     and it appeared to use the same information in $_ twice.  If
:     arguments are passed "by value" then this would be correct; if "by
:     reference" then it wouldn't be.  Which is it?  Is there a way to
:     force this to do what I wanted it to?

The short answer is: If you want nroff, use nroff.

The long answer is: Perl can only left or right justify fields as a
whole.  To do both ends at once implies some kind of fancy algorithm to
insert spaces in the middle.  Perl has no such algorithm, and I have no
intention of trying to supply one.  Durn ugly anyway.  Mutter, grumble...

Of course, if you're excruciatingly persuasive, I reserve the right to
change my mind.  :-)

Larry
Newsgroups: comp.lang.perl
From: Tom Christiansen <tchrist@convex.COM>
Subject: Re: pwbitch
Originator: tchrist@pixel.convex.com
Date: Tue, 18 Aug 1992 14:13:44 GMT
Reply-To: tchrist@convex.COM (Tom Christiansen)
Organization: CONVEX Realtime Development, 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 george@ache.mad.adelaide.edu.au (George Travan):
:Anyone got 'pwbitch' to work. i tried it on a dummy passwd file and it 
:didnt complain at all. Anyone indicate how I should run this program?
:I have little info and understanding of perl.
:
:Sorry if this appears trivial to some, but its not to me.
:
:btw. Any other sysadmin type tools around??

pwbitch reads output from pwchkr.

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

    It's documented in The Book, somewhere...
            --Larry Wall in <10502@jpl-devvax.JPL.NASA.GOV>
Newsgroups: comp.lang.perl
From: andy@orchid.bdc.ubc.ca (Andrew Dwelly)
Subject: Re: Arrays of filehandles
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Thu, 13 Aug 1992 16:46:05 GMT

In article <1992Aug13.145758.14449@news.uit.no> tomg@stud.cs.uit.no (Tom  
Grydeland) writes:

Stuff deleted

> The `@' in `@this[$that]' tells perl that you're refering to an array  
value,
> i.e the array slice with one value, $this[$that].
> 
> The first `$' in $this[$that]' tells perl that you're refering to a  
scalar
> value.
> 
> thus:   @this[$that] == ($this[$that])
> 
> 

Thanks for clearing up my confusion Tom, but surely this means that 
given a file of data "one", the following piece of code should just
echo it ....

#!/local/bin/perl

open($a[0],"<one");
while (<$a[0]>)
{
    print;
}

Which fails to work.
whereas, in perl 4.035 under SunOS 4.1.2, the best I've been able to
come up with is ....

#!/local/bin/perl

open(scalar($a[0]),"<one");
$foobar = $a[0];
while (<$foobar>)
{
    print;
}

That is, not only must the array be made explicitly scalar during the  
assignment of the file handle, but also it must be assigned to
an ordinary scalar before use in angle brackets (I suspect this is because 
perl defines <scalar($a[0])> as a syntactic no-no).

The second version works, but is rather inelegant. Is there any way it can  
be improved to remove the superfluous $foobar ?

Andy Dwelly (andy@bcu.ubc.ca)
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.clos
Subject: Re: is PCL/CLOS commercially supported?
Date: 17 Aug 1992 15:31:05 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <9208171245.AA09144@hpb.lut.ac.uk> A.H.Al_ashaab@lut.ac.uk (AH Al_ashaab) writes:
>"Is PCL/CLOS commercially supported? If YES who is supporting it?

PCL is not commercially supported.

CLOS is built into or available with most commercial Common Lisp systems
these days.  Each vendor is supporting its implementation.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.clos
From: lange@lanai.cs.ucla.edu (Trent Lange)
Subject: Re: PCL and MACL 2.0, anyother MOP?
Organization: UCLA Artificial Intelligence Laboratory
Distribution: usa
Date: Thu, 13 Aug 92 09:32:57 GMT

In article <63920@cup.portal.com> Thomas_E_Morgan@cup.portal.com writes:
>
>First, how badly will I regret attempting to get PCL working in MACL 2.0?  
>I've made an innocent stab, making some easy changes in some LOW.LISP 
>code and in some DEFSETF's, but have bumped into changes in environment 
>representations that bother the walker code.  Am I wandering into a swamp 
>here?

Which version of PCL are you using (i.e. what is *pcl-system-date*)?
I don't know what the last version of PCL was successfully tested in
MACL 2.0 or earlier (maybe somebody can volunteer that information), but
it should be possible to get July 92 PCL working without too much trouble,
if you're willing to do some guided patching.  You'll also have to specify
where you start having problems.

>Second, if the answer is yes, then what LISP and what machine would you 
>suggest I get myself to run a LISP with a strong MOP - either one that comes 
>with the LISP, or PCL.  (Money is not exactly no object here, but I don't want 
>to spend unreasonable amounts either.  The less I have to think about the 
>machine, the better.).
>
>   ...Tom M 

Different people will suggest different things here.  But the latest
versions of PCL have a nearly complete version of the AMOP implemented
and are pretty efficient.  July 92 PCL has been relatively thouroughly
tested in Lucid, Allegro, CMU CL, and AKCL, at least on Sun 4s and NeXTs.

- Trent Lange

Newsgroups: comp.lang.clos
From: john@linus.mitre.org
Subject: Re: CLOS Stylistic Questions -- Program Structuring
Organization: The Ohio State University Department of Computer and Information Science
Date: Mon, 17 Aug 1992 08:03:35 GMT

Joe Konstan (konstan@cs.berkeley.edu) writes:

  Certain things need to be loaded before others can be loaded
  or compiled.

  One solution is to use some version of defsystem and to
  carefully assure that the dependencies can be met on a
  per-file basis (i.e., no circular dependencies between files).

  A second alternative (which I've been using) is to create a 
  "header" file with all of the needed declarations and
  definitions.  This includes "empty" defclasses (no contents, 
  just the class name and superclass names), macro definitions,
  and some defgenerics and proclamations.  

I agree with Jeff Dalton's comments, especially the observation that
the C world essentially uses a DEFSYSTEM facility.  Here are some of
my own comments.

Many of the systems I've developed use macros or DEFVARs that require
other macros, or even classes and methods, to be loaded before they
can be compiled or loaded.  For example, a computed macro expansion
may contain an embedded constant CLOS instance.  This would seem to
require interleaving your header files with non-headers.  Also, some
meta-object programming might require the full class definition, not a
stub, to be loaded when a referring method is compiled or loaded.

An implicit assumption in your second alternative is the existence of
a load file or load function, which refers to all the files.  I find
it MORE modular, maintainable and declarative to use a DEFSYSTEM
facility.  Otherwise you must maintain separate functions for each
operation (load, compile, dump-to-tape, and so on), with many of the
same dependencies duplicated in those functions.  These functions
become one more piece of code you must worry about maintaining, with
the added complication that not one, not two, but, by definition,
EVERY person working on the system has reason to make changes.  This
is true for a DEFSYSTEM declaration as well, but I find the latter
much more maintainable in a multi-person project.

Also, a DEFSYSTEM lets you declare local dependencies, rather than
requiring the computational closure of all dependencies.  For example,
compiling "GAMMA.LISP" directly requires loading "BETA.LISP", but
loading "BETA.LISP" requires loading "ALPHA.LISP".  Thus, compiling
"GAMMA.LISP" requires loading "ALPHA.LISP".  The system we're working
on now comprises over 500 files.  We'd rather not figure this stuff
out for each of them.

A DEFSYSTEM also (presumably) lets you define modules, subsystems and
utility systems, allowing you to modularize dependency declarations
appropriately.  This in turn makes it easier to have several different
versions of a system, each of which may load some files that others do
not.

John Burger
john@mitre.org
From: lou@cs.rutgers.edu (Lou Steinberg)
Newsgroups: comp.lang.clos
Subject: books/articles on object design methodology
Date: 21 Aug 92 17:19:01 GMT
Reply-To: lou@cs.rutgers.edu
Distribution: comp
Organization: Computer Science Dept., Rutgers University, New Brunswick, NJ
	08903

I will be teaching a course on AI Programming this semester which will
include a segment on CLOS.  Can anyone point me to good books or
articles on design methodologies for objects?  I.e., given that we have
CLOS available as a tool, how do we design a set of objects and methods
to implement some functionality?  I'd be interested either in readings
for the class or in background reading for me.

Thank you.
--
					Lou Steinberg

uucp:   {pretty much any major site}!rutgers!aramis.rutgers.edu!lou 
internet:   lou@cs.rutgers.edu
From: lange@lanai.cs.ucla.edu (Trent Lange)
Subject: Re: Example of other slot :allocation
Organization: UCLA Artificial Intelligence Laboratory
Date: Wed, 19 Aug 92 01:47:24 GMT

In article <64244@cup.portal.com> Thomas_E_Morgan@cup.portal.com writes:
>
>Now I've got a question on slots with allocation other than :instance
>or :class in the Aug 4 version of PCL.
> [...]
>When I make slots with :allocation :versioned, and supply the various
>ALLOCATE-INSTANCE, and SLOT-xxx-USING-CLASS behaviors to deal with
>slots with this :allocation, I'm missing some necessary step to make
>the slots  BOUNDP-FUNCTION, READER-FUNCTION WRITER-FUNCTION 
>of STANDARD-EFFECTIVE-SLOT-DEFINITION useable - I get failures because
>BOUNDP-FUNCTION is unbound, long before getting to my SLOT-xxx-USING-CLASS
>methods. 
>
>Can anyone suggest where I can look to see a working example of slots with
>allocation other than :instance or :class for this PCL version, or where
>in the PCL code I can see the protocol for initializing these slots.
>
>   Thanks
>   ...Tom M 

This looks like a bug from March-92-PCL that is apparently still in the
(unstable) August 4 version of PCL.  The problem is that the PCL internal
function INITIALIZE-INTERNAL-SLOT-FUNCTIONS is not called on effective
slot definitions that aren't of :allocation :instance or :class.

This bug is fixed in July 92 PCL, which is relatively stable.  So I would
suggest either using July 92 PCL;  or you can try replacing August 4's :around
method on COMPUTE-SLOTS specialized on std-class (in std-class.lisp)
with the one in July 92 (no guarantees here, however).

- Trent Lange

P.S.  Let us know when you get the final patches for MCL 2.0 so we can
include them in the next versions of PCL.

Newsgroups: comp.lang.clos
From: rharris@rdrc.rpi.edu
Subject: Re: The class STANDARD-OBJECT
Organization: The Ohio State University Department of Computer and Information Science
Date: Tue, 18 Aug 1992 15:19:28 GMT

> Also, it would be good to define a class whose direct subclasses are
> STANDARD-CLASS and FUNCALLABLE-STANDARD-CLASS (PCL has no such class;
> in Lucid's CLOS this class is called CLOS::SLOTTED-CLASS).
PCL has this class; it is called PCL::STD-CLASS.
From: davis@reaumur.ilog.fr (Harley Davis)
Newsgroups: comp.lang.clos
Subject: Re: Accessors specified in a defclass don't seem to use slot-value in 
         Lucid
Date: 17 Aug 92 11:50:18 GMT
Organization: ILOG S.A., Gentilly, France
In-reply-to: jeff@aiai.edinburgh.ac.uk's message of 14 Aug 92 14:01:15 GMT


In article <28265.9208141401@subnode.aiai.ed.ac.uk> jeff@aiai.edinburgh.ac.uk (Jeff Dalton) writes:

   > With regard to the performance implications of doing it this way, Trent
   > Lange has already pointed out that the newest PCL does this efficiently.
   > It's too bad that earlier versions of PCL (one which some commercial
   > implementations are based) had the bug where they didn't implement this
   > aspect of the MOP properly.

   Ordinary accessors can be efficient by not going through
   slot-value-using-class, but what about the accessors that
   _do_ have to go through slot-value-using-class?  How big
   a price do you pay for actually using the MOP?

I think this is the biggest conceptual bug in the CLOS MOP.  Although
the description of the implementation of the MOP in AMOP tries to do
as much as possible at definition time, the language itself specifies
too much which has to be done at runtime.  The TELOS (EuLisp) MOP
tries to fix this bug in a number of places.  For example, slot access
is done by a single accessor function computed at definition time by
calling COMPUTE-SLOT-READER-USING-CLASS.  This has a far smaller
runtime cost than SLOT-VALUE-USING-CLASS, especially when you write
new methods for it.  However, in many places the penalty might still
be too large, since you may end up calling a function for an operation
which should be completely inlined.  (Harry Bretthauer's IMSA '92
paper will discuss this at more length.)

I think the ideal would be a MOP which was completely executed at
compile-time, using compilation environment representations of object
system components to generate some well-defined intermediate language.
I understand that the PARCies are working on something like this for
non-OO aspects of computer languages.  Is there any available progress
reports on this work yet?

-- Harley Davis
--

------------------------------------------------------------------------------
nom: Harley Davis			ILOG S.A.
net: davis@ilog.fr			2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66			94253 Gentilly Cedex, France
Newsgroups: comp.lang.clos
From: Thomas_E_Morgan@cup.portal.com
Newsgroups: comp.lang.clos
Subject: PCL and MACL 2.0, anyother MOP?
Date: Thu, 13 Aug 92 18:07:03 PDT
Organization: The Portal System (TM)
Distribution: usa

Well, Gregor and Trent's advice give me confidence to
proceed.

I'm using the July PCL as a base, and was happily
making small changes, until I got a failure in some
code walker function, while running compile-pcl.

The code was unhappy about the way in which environments
were represented in the new MCL.

I'll hack away and report back results.

   ...Tom M
From: gregor@parc.xerox.com (Gregor Kiczales)
Subject: Re: Accessors specified in a defclass don't seem to use slot-value in Lucid
Organization: Xerox Palo Alto Research Center
Date: 12 Aug 92 13:32:20

In article <9208111754.AA06971@jupiter.risc.rockwell.com> kal@jupiter.risc.rockwell.com (Kevin Lovette) writes:

   From: kal@jupiter.risc.rockwell.com (Kevin Lovette)
   Date: 11 Aug 92 17:54:14 GMT

   I have some code that uses (setf slot-value-using-class) to trigger the update
   of windows on my display.  When I ported this code from Franz to Lucid it
   stopped working.  It turns out that accessors in Franz are implemented with
   slot-value, but in lucid accessors seem to directly access the slot without
   calling slot-value. 

   Is there a finalized CLOS MOP specification yet? If so, what does it specify? 

The MOP specification is available via two means.  The specification
alone is available by anonymous FTP from parcftp.xerox.com.  It is also
available, along with conceptual material about MOPs, as chapters 5 and
6 of `The Art of the Metaobject Protocol,' by Gregor Kiczales, Jim des
Rivieres and Daniel G. Bobrow.  MIT Press.  ISBN # 0-262-61074-4.

As it turns out, the specification never comes right out and says that
automatically generated accessor methods must call SLOT-VALUE-USING-CLASS
and (SETF SLOT-VALUE-USING-CLASS).  But that is certainly what was
intended.  Otherwise, code like your's becomes difficult (perhaps even
impossible) to write.

The current version of PCL, unless something has changed I don't know
about, supports this.  It is pretty easy to do without undue performance
penalty.

Gregor
Newsgroups: comp.lang.clos
From: lange@lanai.cs.ucla.edu (Trent Lange)
Subject: Re: Accessors specified in a defclass don't seem to use slot-value in Lucid
Organization: UCLA Artificial Intelligence Laboratory
Date: Thu, 13 Aug 92 09:17:44 GMT

In article <9208122211.AA15742@quaestor> jmg@inference.COM (Jeff Greif) writes:
>>>>>> gregor@parc.xerox.com (Gregor Kiczales) writes:
>
>-> The current version of PCL, unless something has changed I don't know
>-> about, supports this.  It is pretty easy to do without undue performance
>-> penalty.

Indeed, in the current version of PCL (July 92 PCL, and also in March 92 PCL),
accessor methods effectively go through slot-value-using-class without
any performance penalty at all in the normal case.  The accessor methods
simply use the fastest possible slot-accessing code (directly accessing
the slot from the index stored in a closure variable).  If somebody later
adds a slot-value-using-class method, the appropriate accessor methods are
updated to use the new slot-value-using-class effective method.

- Trent Lange

Newsgroups: comp.lang.clos
From: jonl%kuwait@lucid.com (Jon L White)
Subject: Optimizer--or my misunderstanding?
Organization: The Ohio State University Department of Computer and Information Science
Date: Fri, 21 Aug 1992 19:00:11 GMT

re: (defmethod doit ((self foo)) (funcall (a self) 3))

How about

    (defmethod doit ((self foo)) (funcall (the function (a self)) 3))


In 4.1 FUNCTION is the right type to use(because of ANSI compliance); 
in 4.0, use SYS:PROCEDURE; but you can use SYS:PROCEDURE in either one.

Another possibility is to have a local FTYPE declaration for A.


-- JonL --
From: gregor@parc.xerox.com (Gregor Kiczales)
Newsgroups: comp.lang.clos
Subject: Re: Accessors specified in a defclass don't seem to use slot-value in Lucid
Date: 13 Aug 92 17:26:10 GMT
	<9208122211.AA15742@quaestor>
Organization: Xerox Palo Alto Research Center


(Again, the question had to do with whether automatically generated
accessor methods should call slot-value-using-class and (setf
slot-value-using-class).  That is the intention of the MOP spec, (as if
a document could have intentions) but it doesn't say it anywhere
explictly.)

In article <9208122211.AA15742@quaestor> jmg@inference.COM (Jeff Greif) writes:

   The user can override the automatically-generated accessor methods, or
   supply :around, :before or :after qualifiers to the accessor methods to carry
   out the desired side-effect, without going through SLOT-VALUE-USING-CLASS.
   This would solve Mr. Lovette's problem, but then somebody could call 
   slot-value-using-class instead of the accessor method.
   The real issue is that if there are two paths to change a slot value
   you have to modify both.

What you are proposing, will surely work in some sense.  It corresponds
to changing the program, and you can always do anything you want that
way.  But suppose that Mr. Lovette has a large number of classes, each
with a large number of accessor methods, that he wants to have behave
differently?  Then, your approach becomes cumbersome.

In cases like this, what the MOP allows the user to do is "change the
language itself," in this case so that slot access has some different
behavior, so that the {\em unaltered} program now has a different
behavior.  This ability, properly used, makes it possible to express the
behavior Mr.  Lovett (and others) are after more concisely and elegantly
than under traditional approach of modifying, perhaps in a textually
distributed fashion, the original program.

The point of the MOP, and metaobject protocols in general, is that they
provide a {\em different} cut on affecting the behavior of your program
-- specifically, the difference between changing the program vs.
changing the language it is written in.

With regard to the performance implications of doing it this way, Trent
Lange has already pointed out that the newest PCL does this efficiently.
It's too bad that earlier versions of PCL (one which some commercial
implementations are based) had the bug where they didn't implement this
aspect of the MOP properly.

Gregor
From: Thomas_E_Morgan@cup.portal.com
Newsgroups: comp.lang.clos
Subject: Example of other slot :allocation
Date: Tue, 18 Aug 92 17:06:45 PDT
Organization: The Portal System (TM)
Distribution: world

Back again; I got PCL running on MCL 2.0 (but slowly - still trying to
find out how to do the implimentation specific code for funcallable instances 
from Apple. In the mean time its running with closures and a hash table for the
 fins)

Now I've got a question on slots with allocation other than :instance
or :class in the Aug 4 version of PCL.

Apparently, there are some slots in the STANDARD-EFFECTIVE-SLOT-DEFINITION
(for BOUNDP-FUNCTION, READER-FUNCTION and WRITER-FUNCTION) that get initialized
for slots with :allocation :instance or :class.

I need to make slots with dynamic allocation, something like the 
example on page 101 of the MOP book.

When I make slots with :allocation :versioned, and supply the various
ALLOCATE-INSTANCE, and SLOT-xxx-USING-CLASS behaviors to deal with
slots with this :allocation, I'm missing some necessary step to make
the slots  BOUNDP-FUNCTION, READER-FUNCTION WRITER-FUNCTION 
of STANDARD-EFFECTIVE-SLOT-DEFINITION useable - I get failures because
BOUNDP-FUNCTION is unbound, long before getting to my SLOT-xxx-USING-CLASS
methods. 

Can anyone suggest where I can look to see a working example of slots with
allocation other than :instance or :class for this PCL version, or where
in the PCL code I can see the protocol for initializing these slots.

   Thanks
   ...Tom M 
Newsgroups: comp.lang.clos