HDTenEightyP/NetNews huggingface dataset:
From: huangp@wasser.Colorado.EDU (PeiYu Huang)
Subject: How to neatly destroy instances?
Reply-To: huangp@wasser.Colorado.EDU (PeiYu Huang)
Organization: University of Colorado, Boulder
Date: Mon, 12 Oct 1992 22:35:05 GMT

     Well, by "neatly" I mean something other than:

       cl>(setq my-instance (make-instance 'MY-CLASS))
          #<MY-CLASS @ .......)

       cl>(setq my-instance NIL)

All suggestions are welcome. Thanks in advance..

P. Huang
Newsgroups: comp.lang.clos
From: john@linus.mitre.org
Subject: FIXNUM declarations (was How to neatly destroy instances)
Organization: The Ohio State University Department of Computer and Information Science
Date: Thu, 15 Oct 1992 16:52:14 GMT

Jeff Dalton (jeff@aiai.edinburgh.ac.uk) writes:

  ...  For instance, why should I write code for vectors with as many
  as, say, 1000 elements when I can write instead for "vectors as big
  as this Lisp can handle"?  Why should I have to pick a number?

Well, this probably only works for that particular example, but you
can always build implementation constants into your own type
definitions:

  (DEFTYPE VECTOR-INDEX ()
    '(INTEGER 0 #.(1- ARRAY-TOTAL-SIZE-LIMIT)))

  (DEFUN TRAVERSE-VECTOR (V)
    (DECLARE (TYPE VECTOR V))
    (DOTIMES (I (1- (LENGTH V)))
      (DECLARE (TYPE VECTOR-INDEX I))
      ...
      (ELT V I)
      ...))

I do this all the time.  Then again, by type inference, the compiler
SHOULD be able to figure out the range of I anyway.

John Burger
john@mitre.org
Newsgroups: comp.lang.clos
From: little@sei.cmu.edu (Reed Little)
Subject:  clos & environment available?
Organization: The Software Engineering Institute
Date: Mon, 12 Oct 1992 20:09:09 GMT


i miss my symbolics.  is there a clos implementation & development
environment available for "standard" architectures (sparc & hp specifically)
i need such things as a class examiner (like the symbolics flavor examiner),
good debugger, network capability, multi-processes, good inter-process
communication (both on the same box and other boxes on the network), and 
a file cm/cc system.  thanks.

========================================================================
	reed little
	software engineering institute - carnegie mellon university
	little@sei.cmu.edu, +1.412.268.5792
From: hrothgar@oclc.org (Roger H. Thompson)
Newsgroups: comp.lang.clos
Subject: PLease Remove me from mailing list
Date: 16 Oct 92 19:38:08 GMT
Article-I.D.: chaos.9210161938.AA07844
Organization: The Ohio State University Department of Computer and Information Science


Please remove me from the mailing list, as I now get the news feeds 


		Roger Thompson

 US MAIL:	Office of Research, MC-410
		OCLC, Online Computer Library Center, Inc.
		6565 Frantz Road
		Dublin, OH 43017-0702
		USA

  OFFICE:	(614) 761-5023
     FAX:	(614) 764-2344
INTERNET:	hrothgar@rsch.oclc.org
From: simon@lia.di.epfl.ch (Simon Leinen)
Newsgroups: comp.lang.clos
Subject: Re: How to neatly destroy instances?
Date: 13 Oct 92 15:37:58 GMT
Organization: DI-LIA -- Ecole Polytechnique Federale de Lausanne
In-reply-to: jeff@aiai.edinburgh.ac.uk's message of 13 Oct 92 13:40:40 GMT
X-Md4-Signature: 029feb1de317a5929f3130e7178357ca

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

   Now, one thing that didn't happen in X3J13's revision of Common
   Lisp was changes to garbage collection to support such things 
   as finalization and weak pointers.  I think it was reasonable
   not to do this, but I want to add my voice to those saying
   "we want it" in the hope that implementors will be influenced.

Me too! (But maybe it's too late to complain to vendors :-) Allegro CL
4.1 has "weak vectors" and finalization, the Lucid 4.1 announcement
talks about new features called "weak pointers and finalization".
(Maybe this is going to be the next major application of #+/#- :-)

   I'm not really sure finalization is a good idea though.

Why not? Let me guess: Programs that rely on finalization methods a
lot will be difficult to debug; people will use finalization where
macros like WITH-OPEN-FOO would be more appropriate... finalization
just gives you more rope to hang yourself, seems to be compatible with
the CL approach - down with Bondage-and-Discipline languages!
-- 
Simon.
Newsgroups: comp.lang.clos
From: chyde@pecos.ads.com (Clinton Hyde)
Subject: copying instances
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
	960-7300
Date: Tue, 13 Oct 1992 16:13:25 GMT


there was some discussion recently about copying objects. barmar
appears not to like the idea over much.

there are good points and bad points. a good point is that it's
actually fairly easy. a bad point is that it's not going to be easy to
bypass the create and setf (and before/after) methods if you need to.

I have code to do the copying. it works quite well, and there's an
extra control so that you can avoid copying slots (by name) if there's
a reason to do so (believe me, there will be). it's smart enough not
to make new copies of things already copied and referenced different
places. I use it all the time on my current project. it's not
completely generalized regarding when not to copy things, and I won't
swear that it copies all possible lisp objects (i don't work with
hash-tables, so I don't know if it can handle them...other things
likewise). 

be happy to give a copy of my code to anyone...

 -- clint
--

Clint Hyde		"Give me a LispM or give me death!" -- anonymous

Advanced Decision Systems/BAH	Internet:  chyde@chesapeake.ads.com
1953 Gallows Rd, Suite 600
Vienna, VA  22182-3934		(703) 902-7130
Newsgroups: comp.lang.clos
From: Sing.Bing.Kang@ius4.ius.cs.cmu.edu
Subject: Problem in compiling
Organization: The Ohio State University Department of Computer and Information Science
Date: Fri, 16 Oct 1992 22:33:47 GMT

When I try compiling PCL, this is what I get:

    g9]pcl% cl
    Allegro CL 3.1.13.1 [Sun4] (0/0/0)
    Copyright (C) 1985-1990, Franz Inc., Berkeley, CA, USA
    <cl> (load "defsys")

    ; Loading /usr0/sbk/pcl/defsys.lisp.

    T
    <cl> (pcl::compile-pcl)
    
    Loading binary of PKG...
    Loading binary of WALK...
    Loading binary of ITERATE...
    Loading binary of MACROS...
    Loading binary of LOW...
    Loading binary of EXCL-LOW...
    Loading binary of FIN...
    Loading binary of DEFCLASS...
    Loading binary of DEFS...
    Loading binary of FNGEN...
    Loading binary of CACHE...
    Loading binary of DLISP...
    Loading binary of DLISP2...
    Loading binary of BOOT...
    Loading binary of VECTOR...
    Loading binary of SLOTS-BOOT...
    Loading binary of COMBIN...
    Loading binary of DFUN...
    Loading binary of FAST-INIT...
    Compiling BRAID...
    ; --- Compiling file /usr0/sbk/pcl/braid.lisp ---
    ; Compiling ALLOCATE-STANDARD-INSTANCE
    ; Compiling ALLOCATE-FUNCALLABLE-INSTANCE-SLOTS
    ; Compiling ALLOCATE-FUNCALLABLE-INSTANCE
    ; Compiling ALLOCATE-STRUCTURE-INSTANCE
    ; Compiling INITIAL-CLASSES-AND-WRAPPERS
    ; Compiling BOOTSTRAP-META-BRAID
    ; Compiling BOOTSTRAP-ACCESSOR-DEFINITION
    ; Compiling BOOTSTRAP-ACCESSOR-DEFINITIONS
    ; Compiling BOOTSTRAP-INITIALIZE-CLASS
    ; Compiling BOOTSTRAP-MAKE-SLOT-DEFINITIONS
    ; Compiling BOOTSTRAP-MAKE-SLOT-DEFINITION
    ; Compiling EARLY-INITIALIZE-SLOT-GFS
    ; Compiling EARLY-INITIALIZE-CLASS-PREDICATES
    ; Compiling BOOTSTRAP-BUILT-IN-CLASSES
    ; Compiling WRAPPER-FOR-STRUCTURE
    ; Compiling BUILT-IN-OR-STRUCTURE-WRAPPER1
    ; Compiling WRAPPER-OF-MACRO
    ; Compiling CLASS-OF
    ; Compiling WRAPPER-OF
    ; Compiling STRUCTURE-WRAPPER
    ; Compiling EVAL-FORM
    ; Compiling SLOT-INITARGS-FROM-STRUCTURE-SLOTD
    ; Compiling FIND-STRUCTURE-CLASS
    ; Compiling BUILT-IN-WRAPPER-OF
    ; Compiling METHOD-FUNCTION-RETURNING-NIL
    ; Compiling METHOD-FUNCTION-RETURNING-T
    ; Compiling MAKE-CLASS-PREDICATE
    ; Compiling (:PROPERTY SLOT-OBJECT EXCL::DEFTYPE-EXPANDER)
    ; Compiling |(FAST-METHOD NO-APPLICABLE-METHOD (T))|
    ; Writing fasl file "/usr0/sbk/pcl/braid.fasl"
    ; Fasl write complete
    Loading binary of BRAID...
    Error: Wrong number of args passed to CHECK-WRAPPER-VALIDITY
    
    [changing package from "USER" to "PCL"]
    [1] <cl>

It appears that it failed when trying to evaluate (bootstrap-built-in-classes)
near the end of file braid.lisp. I am running this in a Sun4 SPARCstation 1+ 
in Allegro CL 3.1.13.1.

Thanks.

Sing Bing Kang
The Robotics Institute
Carnegie Mellon University
Pittsburgh, PA 15213
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.clos
Subject: Re: Why not a copy protocol
Date: 12 Oct 1992 01:24:58 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com
Keywords: clos copy copy-protocol

In article <138668@lll-winken.LLNL.GOV> jeh@llnl.gov (Jose E. Hernandez) writes:
>Does anyone know why CLOS does not provide a copy protocol.  Although it
>is true that in some cases the semantics (as well as the implementation)
>of what do we mean by making a copy of an instance can be non-trivial, I
>would argue that the same is true with changing the class of an
>instance.  Nevertheless, CLOS provides a protocol for this, why not for copy...

CLOS has no copy (nor an equivalence) protocol because the appropriate type
of copying and equality is often context-sensitive.  A simple COPY-OBJECT
or EQUAL-OBJECT generic function would force a particular case of this to
be distinguished as the "default", which would be error-prone (a caller
might have a different expectation from the implementor of a particular
method).

Many of us believe that even the functions EQUAL and EQUALP were a mistake;
EQUAL was simple enough in the early days when Lisp only had one structured
type (conses), but now its behavior on arrays, structures, and CLOS
instances is confusing.

An example of a function that provides general capabilities without falling
into this trap is SORT.  Rather than requiring all types to implement a
generic LESS-THAN operator, the caller provides the comparison function
that's appropriate to his context.

I once tried to design completely general copying and equality generic
functions.  They had a number of options that allowed the caller to specify
what type of recursion should be performed.  It ended up being more complex
than I was comfortable with.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.clos
From: mm%acid-rain@lucid.com (Martin Mikelsons)
Subject: Re: clos & environment available?
Organization: The Ohio State University Department of Computer and Information Science
Date: Sat, 17 Oct 1992 00:09:08 GMT


;;Reed Little writes: 
;;i miss my symbolics.  is there a clos implementation & development
;;environment available for "standard" architectures (sparc & hp specifically)
;;i need such things as a class examiner (like the symbolics flavor examiner),
;;good debugger, network capability, multi-processes, good inter-process
;;communication (both on the same box and other boxes on the network), and 
;;a file cm/cc system.  thanks.

We all miss our Symbolics (even if we never worked with one).  The concept
of window and mouse oriented programming tools integrated with the run-time
and the editing environment is without question a big winner.  Symbolics
was a leader and inovator in the field.  But Lisp on general-purpose
architectures has been catching up.  Each of the major Lisp suppliers has
an entry in the field:  Harlequin has Lispworks, Franz has Composer, and
Lucid has XLT.  As the principal developer of one of these (XLT) I would
like to reply that we are attempting to satisfy Mr. Little's needs and
wishes.

XLT is a set of advanced Lisp an CLOS programming tools for Lucid Common 
Lisp.  It is becoming available on a variety of "standard" architectures,
including Sparc, RS6000, HP700/800 and Decsystem.  It includes a range 
of facilities which are (very briefly) mentioned below:

	Run-Time Tools
	 Data Inspectors for all Common Lisp data types
	  Inspect and modify all components with simple
	  mouse gestures
	 CLOS Inspectors specially adapted to the OO world
	  Instance inspector to view and modify all slots
	  Class, Generic Function and Method viewers
	  Class Browser to show a graphic view of the class
	   hierarchy
	 Debugging Tools
	  Stack Inspector shows the call chain in one Lisp
	   sub-process, and allow various restart actions
	  Frame Inspector to view and modify arguments and
	   local variables
	  Visual Stepper
	  
	Source-Level Tools
	 Program Analyzer
	 Program Follower
	  Control Graph
	  Data Flow Graph
	  Class and Accessor usage
	 Defsys facility

	Interface to GNU Emacs
	 Network connection provides a dynamic peer-to-peer interface
	  between Lucid Common Lisp and GNU Emacs
	 Emacs commands to fetch arglist, description, macroexpanded
	  form;  send form(s) to be evaluated, compiled, inspected.
	 Mouse click in inspector can bring up source in 
	  Emacs buffer.

As the developer of XLT, I may be somewhat biased when I claim that 
Lisp environments on gp architectures have achieved most of the
functionality of their dedicated ancestors and rivals.  In addition,
portability of code among a wide variety of platforms allows one to
exploit more effectively todays heterogenous networked computing 
environment.

Sincerely,    Martin Mikelsons <mm@lucid.com> (415)329-8400 x5533
              Lucid, Inc., 707 Laurel Street, Menlo Park CA 94025
From: mcalpink@cs.aston.ac.uk (K MCALPINE,,,,universe(ucb))
Newsgroups: comp.lang.clos
Subject: CLOS development systems
Date: 7 Oct 92 09:33:42 GMT
Reply-To: mcalpink@cs.aston.ac.uk
Organization: Aston University (Comp Sci)

Hi.
I've just started looking at CLOS and was wondering if anybody could recommend any good development systems/compilers for CLOS running on either a PC, Sparc, or Archimedes.
The system would need a good set of library routines for developing windowing apps.

Cheers

Keith
Newsgroups: comp.lang.clos
From: Sing.Bing.Kang@ius4.ius.cs.cmu.edu
Subject: Xerox PCL
Organization: The Ohio State University Department of Computer and Information Science
Date: Fri, 16 Oct 1992 19:28:48 GMT

I am interested in obtaining the Xerox PCL software, which I understand to be
an implementation of CLOS and is free to those who request it. Please let me
know how I can get this software.

Thank you.

Sing Bing Kang
The Robotics Institute
Carnegie Mellon University
5000 Forbes Ave.
Pittsburgh, PA 15213
Newsgroups: comp.lang.clos
From: cs631114@umbc8.umbc.edu (cs631114)
Subject: Retrieving documentation of slots?
Organization: UMBC CS Dept
Date: Tue, 13 Oct 1992 18:13:08 GMT


Hmm, I finally got around to trying to use doc strings on slots, and much
to my embarrassment realized I didn't know how to retrieve them! Assumedly
I am overloooking the obvious. Hints, anyone?

Newsgroups: comp.lang.clos
From: lange@lanai.cs.ucla.edu (Trent Lange)
Subject: Re: Retrieving documentation of slots?
Organization: UCLA Artificial Intelligence Laboratory
Date: Wed, 14 Oct 92 14:06:04 GMT

In article <1bf7hrINNg9g@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>
>No, you're not overlooking anything.  As it says in the Notes section of
>the dpANS description of DOCUMENTATION:
>
>    This standard prescribes no means to retrieve the \term{documentation
>    strings} for individual slots specified in a \macref{defclass} form,
>    but \term{implementations} might still provide debugging tools and/or
>    programming language extensions which manipulate this information.
>    Implementors wishing to provide such support are encouraged to consult
>    the \term{Metaobject Protocol} for suggestions about how this might be
>    done.

Has this been changed?  On p. 840 of Steele 2nd edition, it defines
that a DOCUMENTATION method should be specialized on
"STANDARD-SLOT-DESCRIPTION", which I presume was meant to be the
equivalent of the current STANDARD-SLOT-DEFINITION.

In any case, in July 92 PCL you can get the documentation of an
effective or direct slot definition object through (PCL::DOCUMENTATION
<slot-def>).

Getting the slot definition object itself is of course a simple matter
of searching along the CLASS-SLOTS of a class for the slot definition
with appropriate SLOT-DEFINITION-NAME.  (In PCL one can use
(PCL::FIND-SLOT-DEFINITION <class> 'slot-name)).

- Trent Lange

Newsgroups: comp.lang.clos
From: jonl%kuwait@lucid.com (Jon L White)
Subject: How to neatly destroy instances?
Organization: The Ohio State University Department of Computer and Information Science
Date: Wed, 14 Oct 1992 20:09:44 GMT

re: So I still claim having an explicit free (or at least
    some amount of low-level control on memory allocation, WHEN NEEDED AND
    APPROPRIATE) would be 'a good thing'.

Quite true.  For just this reason, many vendors -- Symbolics and Lucid
included -- supply an explicit RESOURCE management facility (but this
isn't part of the ANSI proposal.)

Ususally, however, the issue for explicit RESOURCE's isn't efficiency of 
GC or whatnot, but rather the pressing need to avoid invoking a potentially
heavyweight(**) GC at an inopportune time --  "Cons-free coding".

I think someone else earlier brought this up too.


-- JonL --



(**)  Statistically, speaking, the "ephemeral" scavenges will do the work
      "most" of the time; but ocasionally they may trigger an ordinary
      dynamic GC, which is not constant-bounded the way an "ephemeral"
      scavenge is; the time required for this kind of regular GC typically
      depends linearly upon the total size of the live data.
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.clos
Subject: Re: How to neatly destroy instances?
Date: 13 Oct 1992 23:23:10 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1490.719005371@bbn.com> jmorrill@BBN.COM writes:
>If you "let go" of an object in the sense of removing the last pointer
>to it, then couldn't the application "finalize" the object at that time?
>Why is it better to wait until the garbage collector gets around
>to cleaning up the bits?

The whole reason for automatic garbage collection is that it's difficult
for the application to know when it's removing the last pointer to an
object.

Here's an example where finalization may be useful: When programming the
Connection Machine in Lisp (either CM-Lisp or *Lisp) there are front-end
objects that act as handles to memory allocated on the CM; in *Lisp these
are called pvars (Parallel VARiables).  Currently we require the program
either to explicitly create and destroy pvars, or create them with dynamic
extent (a la WITH-OPEN-FILE).  We would like to support garbage collection
of pvars, but we need a hook into the garbage collector so that we know
when the CM memory has become available.  Finalization would provide that
hook.  (It has been pointed out to me that this wouldn't be a great scheme,
as CM2 memory isn't virtual, so it's much more limited compared to
front-end memory.)
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: will@skinner.cs.uoregon.edu (William Clinger)
Newsgroups: comp.lang.clos
Subject: Re:  How to neatly destroy instances?
Date: 14 Oct 92 07:15:51 GMT
Article-I.D.: skinner.9210142115.AA04377
Organization: The Ohio State University Department of Computer and Information Science


    I think it is intuitively obvious that for most such structures the
    application is in a far better position to know when the structure will
    be of no further use.

Whether obvious or not, I don't think this is true.  In complex
applications with shared data structures, the only way the application
can know when a structure will be of no further use is by maintaining
some kind of reference count, or by implementing a custom garbage
collector.  Automatic garbage collection is more reliable, and is
usually faster as well because more programming effort can be justified
for a general-purpose collector than for a single-purpose collector.

    ...A substantial portion of the time to GC isn't
    sticking cons cells back on the free list, but deciding which ones need
    to be so stuck. So I still claim having an explicit free (or at least
    some amount of low-level control on memory allocation, WHEN NEEDED AND
    APPROPRIATE) would be 'a good thing'.

At best, explicit deallocation takes time proportional to the number
of nodes being freed.  Modern garbage collectors can and often do
operate in less time than explicit deallocation, because they use
algorithms whose time is proportional to the number of nodes that
are live in heuristically chosen regions that have a low percentage
of live data.

Your argument is similar to the argument that explicit storage
overlays will always outperform automatic paging.  Garbage
collection has a theoretical advantage over explicit deallocation,
however, so the case for garbage collection is even stronger than
was the case for automatic paging.

William Clinger
Xref: sparky comp.lang.clos:881 comp.lang.lisp:2642
From: tar@ISI.EDU (Thomas A. Russ)
Newsgroups: comp.lang.clos,comp.lang.lisp
Subject: Re: How to neatly destroy instances?
Date: 13 Oct 92 00:24:46 GMT
Reply-To: tar@isi.edu
Organization: USC-ISI
In-reply-to: huangp@wasser.Colorado.EDU's message of 12 Oct 92 22:35:05 GMT


In article <...> huangp@wasser.Colorado.EDU (PeiYu Huang) writes:

 >      Well, by "neatly" I mean something other than:
 > 
 >        cl>(setq my-instance (make-instance 'MY-CLASS))
 >           #<MY-CLASS @ .......)
 > 
 >        cl>(setq my-instance NIL)
 > 
 > All suggestions are welcome. Thanks in advance..
 > 

If you don't use global (special) variables, then you don't need to do
anything to eliminate unused instances.  One simple solution would be:


(let ((my-instance (make-instance 'MY-CLASS)))
  ....)

After the let form, my-instance is not bound and the instance of
MY-CLASS that was created is freed for the garbage collector.

Why do you feel a need to destroy instances explicitly?
--

Thomas A. Russ                                             tar@isi.edu    
USC/ISI, 4676 Admiralty Way, Marina del Rey, CA 90292      (310) 822-1511
Newsgroups: comp.lang.clos
From: jeff@aiai.edinburgh.ac.uk (Jeff Dalton)
Subject: Re: FIXNUM declarations (was How to neatly destroy instances)
Organization: The Ohio State University Department of Computer and Information Science
Date: Fri, 16 Oct 1992 15:24:16 GMT

> Jeff Dalton (jeff@aiai.edinburgh.ac.uk) writes:
> 
>   ...  For instance, why should I write code for vectors with as many
>   as, say, 1000 elements when I can write instead for "vectors as big
>   as this Lisp can handle"?  Why should I have to pick a number?
> 
> Well, this probably only works for that particular example, but you
> can always build implementation constants into your own type
> definitions:

Sure, but what should I have to do this?

Indeed, there's a huge range of object indexing applications where
fixnums are virtually guaranteed to work.  Why?  Because in most
implementations the number of bits in a fixnum is at least as great
as the number in a pointer.  Maybe you lose on the sign bit, but
then objects are almost never (un)aligned so that all pointer bits
are needed.

If you want to worry, you can check.  Often people don't check.
Does this mean their code isn't portable?  Probably.  But so is
code that assumes it can make arrays with more than 1024 elements.
Does that mean code that calls MAKE-ARRAY without checking is
completely beyond the pale?  That it might as well be written as
a random sequence of characters?  I think not.  (But some people
claim something very close to this when it comes to standards.
I think they are wrong.)

> Then again, by type inference, the compiler SHOULD be able to figure
> out the range of I anyway.

Certaily in some cases.

-- jd
From: lewocz@acsu.buffalo.edu (John S. Lewocz)
Newsgroups: comp.lang.clos
Subject: Introductory tutorial on CLOS
Date: 15 Oct 92 19:58:11 GMT
Organization: State University of New York at Buffalo/Comp Sci

Could someone suggest a text-like bookon the subject.

Thanks.

--John S. Lewocz



--