HDTenEightyP/NetNews huggingface dataset:
From: miller@cs.rochester.edu (Brad Miller)
Newsgroups: comp.lang.clos
Subject: Re: Deleting an Instance
Date: 31 Jul 92 14:21:19 GMT
Organization: University of Rochester


barmar@think.com writes:

 A possible solution, though, is to use "resources".  These are collections
 of similar objects that are made available for reuse when they're no longer
 needed instead of becoming garbage.  Some Common Lisp implementations
 (Symbolics, Lucid, probably Franz) provide them as an extension; if you're
 using an implementation that doesn't, it's pretty easy to write yourself
 (there may even have been an article in a past issue of Lisp Pointers that
 discussed them and provided an implementation).

In fact, there is a version available in cl-lib or Mark's archive that I 
wrote (called resources.lisp); both are mentioned in the FAQ as to where to 
look. Known to work in allegro and symbolics (though unecessary on the latter).

Brad Miller


--
----
Brad Miller             U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}
-- 
----
Brad Miller             U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}
Newsgroups: comp.lang.clos
From: jonl%kuwait@lucid.com (Jon L White)
Subject: Deleting an Instance
Organization: The Ohio State University Department of Computer and Information Science
Date: Thu, 30 Jul 1992 17:29:25 GMT

re: How can I get rid of the unnecessary instances after I've used them?

By not "pointing" at them.   Let the GC do it's thing.


Seriously.  This question is asked every 6 months or so on this
mailing list, and evokes the remembrance of "destructors" in C++.
But the concept of "getting rid" of something in Lisp has been
around for over 30 years, and it's the same issue for "instances"
as it is for CONS cells and most other objects.

Howver, note that certain kinds of objects are "registered" in global
places, and will not be reclaimed simply because the user has dropped
all pointers to them from his code.  The Common-Lisp PACKAGE system has 
a registry that maps strings into PACKAGE's, as well as the obvious set 
of mappings form strings into SYMBOL's; and CLOS obviously is mapping 
class-names into CLASS objects.  There may be other registrations like
this depending on the implementation.

For example, in order to "get rid of" a symbol, you may have to call
UNINTERN numerous times; and to get rid of a package, you may have to
call DELETE-PACKAGE (see CLtL2).  And a few CLOS implementation support 
a partial function for DELETE-CLASS, although this function isn't in
the ANSI CL proposal (I say "partial", because depending on the class 
inheritance topology, this isn't always a well defined operation.)




-- JonL --

Newsgroups: comp.lang.clos
From: john@linus.mitre.org
Subject: (none)
Organization: The Ohio State University Department of Computer and Information Science
Date: Tue, 28 Jul 1992 14:37:25 GMT

kanderso@bbn.com writes:
  
    ... how do I exit from a primary method such that :AFTER method
    are skipped?  I'd like to avoid use of THROW and non-standard
    method combination.  Is it possible?
  
  Use an :AROUND method.   Do you consider than non-standard?

No, but do you mean an :AROUND to CATCH the THROW from the primary?  I
think the idea was to avoid non-standard method combination and *also*
avoid THROW, not just avoid the combination of the two.


John Burger
john@mitre.org
Newsgroups: comp.lang.clos
From: charest@Aig.Jpl.Nasa.Gov (Len Charest)
Subject: return-from GF with :after methods?
Followup-To: comp.lang.clos
Reply-To: charest@aig.jpl.nasa.gov
Organization: NASA/Jet Propulsion Laboratory
Date: Tue, 28 Jul 1992 18:54:23 GMT

I have a generic function with a primary method and at least one :after method. The GF uses standard method combination. In the body of the primary method I have a conditional RETURN-FROM statement which I had assumed would throw out of the *GF* altogether and skip execution of the :after method (essentially overriding the semantics of standard method combination). However, in Lucid 4.0.2 the :after method is executed anyway--the net effect of RETURN-FROM being immediate exit from the primary method only. 




Is this correct behavior? If so, how do I exit from a primary method such that :after method are skipped? I'd like to avoid use of THROW and non-standard method combination. Is it possible?
..................................................
                                  Len Charest, Jr.
                 JPL Artificial Intelligence Group
                          charest@aig.jpl.nasa.gov
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.clos
Subject: Re: Deleting an Instance
Date: 30 Jul 1992 17:11:11 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1992Jul30.162753.11173@athena.mit.edu> wwinston@athena.mit.edu (R. Whitney Winston) writes:
>How can I remove an instance?

In general, you can't.  This is Lisp, and unused objects are removed
automatically by the garbage collector.  If your objects aren't going away,
either there's a problem with your GC or you've still got references to the
objects you claim you don't need.

A possible solution, though, is to use "resources".  These are collections
of similar objects that are made available for reuse when they're no longer
needed instead of becoming garbage.  Some Common Lisp implementations
(Symbolics, Lucid, probably Franz) provide them as an extension; if you're
using an implementation that doesn't, it's pretty easy to write yourself
(there may even have been an article in a past issue of Lisp Pointers that
discussed them and provided an implementation).

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.clos
Subject: Re: return-from GF with :after methods?
Date: 28 Jul 1992 23:05:41 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1992Jul28.185423.22804@jpl-devvax.jpl.nasa.gov> charest@aig.jpl.nasa.gov writes:
>I have a generic function with a primary method and at least one :after
>method. The GF uses standard method combination. In the body of the
>primary method I have a conditional RETURN-FROM statement which I had
>assumed would throw out of the *GF* altogether and skip execution of the
>:after method (essentially overriding the semantics of standard method
>combination). However, in Lucid 4.0.2 the :after method is executed
>anyway--the net effect of RETURN-FROM being immediate exit from the
>primary method only.

>Is this correct behavior? If so, how do I exit from a primary method such
>that :after method are skipped? I'd like to avoid use of THROW and
>non-standard method combination. Is it possible?

This is correct.  RETURN-FROM is a lexical operator, and returns from the
lexically-enclosing block with the given name.  Since the generic function
definition doesn't lexically enclose the RETURN-FROM, there's no way it
could do what you expected.

If you don't want to use another method combination, then the most obvious
solution is to put a CATCH in an :AROUND method and a THROW in the primary
method.  This won't necessarily throw out of the entire generic function,
though; if a subclass defines an :AROUND method of its own, it will enclose
your :AROUND method, and the CATCH will return to it.

To better ensure what you want, you could break your GF into two functions,
e.g. GF1 and GF2.  GF1 would contain the CATCH and a call to GF2, and the
primary method for GF2 would contain the THROW.  You might make GF1
non-generic, so that subclass authors wouldn't be tempted to add :AROUND
methods to it.

P.S. Please hit Return every 70-80 characters when posting to the net.
Each of your paragraphs was on one long line; don't assume that everyone is
using a mail/news reader that wraps nicely (since most of us aren't).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.clos
From: harrisr@cs.rpi.edu (Richard Harris)
Subject: Re:  Compilation of PCL under KCL
Organization: The Ohio State University Department of Computer and Information Science
Date: Fri, 31 Jul 1992 12:38:59 GMT

I don't have enough information to tell you what the
problem is.  What is the value of pcl::*pcl-system-date*?

Before you load defsys.lsp, type the following forms:
(defun si::error-set (form)
  (let ((si::*break-enable* t))
    (values-list (cons nil (multiple-value-list (eval form))))))
(use-fast-links nil)

Then, once you get the error and are in the debugger, type:
:bt


Richard Harris

Newsgroups: comp.lang.clos
From: gregor@parc.xerox.com (Gregor Kiczales)
Newsgroups: comp.lang.clos
Subject: Re: where is the bug in the use of slot-value-using-class
Date: 26 Jul 92 19:40:23 GMT
Organization: Xerox Palo Alto Research Center


   From: mayers@philemon.IRO.UMontreal.CA (Andre Mayers)
   Date: 24 Jul 92 17:03:18 GMT

   Does someone know what I am doing wrong in the following program:

This message really needs to be looked into by someone at Franz.
But, judging from the behavior you report, there is a bug in the
code that is optimizing compiled calls to MAKE-INSTANCE.

   Does someone know how to use the following generic functions:
   map-dependents, add-dependents and remove-dependents?

These are actually documented pretty well in the specification, chapter
5 of the AMOP to be precise.  If you don't have the whole book, you can
FTP the specification from parcftp.xerox.com.

Gregor
Newsgroups: comp.lang.clos
From: dourish@EuroPARC.Xerox.COM (Paul Dourish)
Subject: Re: Where can I get the CLOS meta-object protocol description?
Reply-To: dourish@EuroPARC.Xerox.COM (Paul Dourish)
Organization: Rank Xerox EuroPARC, Cambridge, UK
Distribution: usa
Date: Wed, 22 Jul 1992 17:25:20 GMT

> The sources for the final CLOS Metaobject Protocol Specification are now
> available for anonymous FTP from arisia.xerox.com.  You need to get the
> file /pcl/mop/spec.tar.Z.

Please note that arisia has gone away, and has been replaced by
parcftp.xerox.com (13.1.64.94). The pcl directory lives under /pub.

                                                  -- Paul.

--
Paul Dourish, Rank Xerox EuroPARC, Cambridge, UK   <dourish@europarc.xerox.com>

          "Ain't they got no barbers where you come from, boy?"
Newsgroups: comp.lang.clos
From: john@linus.mitre.org
Subject: return-from GF with : after methods?
Organization: The Ohio State University Department of Computer and Information Science
Date: Tue, 28 Jul 1992 12:01:47 GMT

Len Charest (charest@ai-cyclops.jpl.nasa.gov) writes:

  I have a generic function with a primary method and at least one
  :AFTER method.  The GF uses standard method combination. In the body
  of the primary method I have a conditional RETURN-FROM statement
  which I had assumed would throw out of the *GF* altogether and skip
  execution of the :AFTER method (essentially overriding the semantics
  of standard method combination)

No, RETURN-FROM is entirely a lexical construct, and refers to the
implicit block wrapping the body of your primary method.  This is
exactly the correct behavior (see CLtL2, page 839).

  ... how do I exit from a primary method such that :AFTER method are
  skipped?  I'd like to avoid use of THROW and non-standard method
  combination.  Is it possible?

Briefly, no.  I can't think of anything else.


John Burger
john@mitre.org
Newsgroups: comp.lang.clos
From: rouquett@Aig.Jpl.Nasa.Gov (Nicolas Rouquette)
Subject: Portability: Adding a slot to a class
Reply-To: rouquett@aig.jpl.nasa.gov
Organization: NASA/Jet Propulsion Laboratory
Date: Thu, 30 Jul 1992 23:42:18 GMT

How can I add a slot to a class? One solution is to redefine class but that
isn't terribly portable since it requires having the source definition
of the class. P. 203 of the AMOP describes how a slot instance can be
created, e.g., (make-instance  'clos:standard-slot-definition ...).
Then, the question becomes how can a slot instance be added to a given class
as if it were (almost) a re-definition of the class? Can this be done
in a portable manner? If not, I'd be equally interested in an
implementation-specific solution for Lucid 4.0.2 on sparc.

As an example, adding slots can be used to store additional state information
on objects so as to modify the behavior of an algorithm on those objects.
The algorithm modifications can be implemented as redefinitions of the
public methods of the algorithm so as to use the additional state information.
This approach seems to me elegant and portable. In terms of efficiency,
adding information on the object themselves seems to be the fastest way to
get at that information compared to other storage techniques such as lists,
arrays, or hash tables. 

-- 
Nicolas Rouquette
Artificial Intelligence Group
Jet Propulsion Laboratory
California Institute of Technology
4800 Oak Grove Drive
M/S 525-3660
Pasadena, CA 91109

phone: (818) 306-6171
fax:   (818) 306-6912
Email: rouquett@aig.jpl.nasa.gov
Newsgroups: comp.lang.clos
From: kerry@ADS.COM (Kerry Koitzsch)
Subject: SAVE-OBJECT 7a alpha code available---CMU CL and AKCL test sites wanted
Summary: Code to save ASCII representations of all LISP objects available.
Keywords: AKCL, CMU CL, ASCII representation, MAKE-LOAD-FORM
Organization: Advanced Decision Systems, Mtn. View, CA (415) 960-7300
Date: Fri, 31 Jul 1992 00:01:24 GMT

Hello CLOS users:

SAVE-OBJECT is a utility for saving LISP objects to files in ASCII representation. Many of you have used this code and provided much helpful feedback on
improving the code. This new version fixes several old bugs and includes supp-
ort for CMU Common Lisp and Austin Kyoto Common Lisp, as well as Symbolics,
Allegro, Mac Common Lisp, and Lucid Common Lisp; both PCL and native CLOS
(when present) are supported. Unfortunately I have only limited access to
MCL, CMU CL, and AKCL platforms for testing, and would especially like to
hear from those who would like to try the code on MCL,CMUCl, and AKCL plat-
forms; however, if you would like this new version of the code for any
platform, please send me an email: your comments are welcome and will help
to build the next version of this utility.

Thank you,

kerry@ads.com





Newsgroups: comp.lang.clos
From: jclose@chesapeake.ads.com (Jeff Close)
Subject: Where can I get the CLOS meta-object protocol description?
Organization: Advanced Decision Systems division of Booz, Allen & Hamilton
Distribution: usa
Date: Wed, 22 Jul 1992 16:10:25 GMT


The subject says it -- is there an archive or ftp version of the meta-object
description, or where can I find documentation on it?

THanks for any help...

Jeffrey
-- 
-----------------------------------------------------------------------------
jclose@ads.com: ADS BA&H/2111 Wilson Bd #800/Arlington, VA 22201 703-243-1611

Anarchists don't believe in rules.  Surrealists make up their own.
Newsgroups: comp.lang.clos
From: doug@monet.ads.com (Doug Morgan)
Subject: Re: Where can I get the CLOS meta-object protocol description?
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
	960-7300
Distribution: usa
Date: Wed, 22 Jul 1992 17:39:45 GMT


See below.  There is also a spec.ps.Z.

doug
--------------------

From Gregor@parc.xerox.com Mon Apr 22 14:39:38 1991
From: Gregor@parc.xerox.com (Gregor Kiczales)
Newsgroups: comp.lang.clos
Subject: MOP Specification
Date: 22 Apr 91 21:03:54 GMT
Distribution: inet
Organization: CommonLoops


The sources for the final CLOS Metaobject Protocol Specification are now
available for anonymous FTP from arisia.xerox.com.  You need to get the
file /pcl/mop/spec.tar.Z.  This is a uuencoded tarfile, so use binary
mode to copy it.  Once you have uudecoded and untared it, run spec.tex
through LaTeX and you should be all set.

This material corresponds to Chapters 5 and 6 of the forthcoming "The
Art of the Metaobject Protocol" and, as such, is copyright MIT Press.
But, to encourage further development, the copyright for these chapters
has been relaxed to something similar to copyleft.  See page one of the
material for details.

Have fun.
Newsgroups: comp.lang.clos
From: kanderso@bbn.com
Subject: Re: return-from GF with : after methods?
Organization: The Ohio State University Department of Computer and Information Science
Date: Tue, 28 Jul 1992 13:37:28 GMT

  To: comp.lang.clos@cis.ohio-state.edu
  Date: Tue, 28 Jul 1992 12:01:47 GMT
  Organization: The Ohio State University Department of Computer and Information Science
  From: john@linus.mitre.org
  Sender: commonloops-request@cis.ohio-state.edu
  Subject: return-from GF with : after methods?
  
  Len Charest (charest@ai-cyclops.jpl.nasa.gov) writes:
  
    I have a generic function with a primary method and at least one
    :AFTER method.  The GF uses standard method combination. In the body
    of the primary method I have a conditional RETURN-FROM statement
    which I had assumed would throw out of the *GF* altogether and skip
    execution of the :AFTER method (essentially overriding the semantics
    of standard method combination)
  
  No, RETURN-FROM is entirely a lexical construct, and refers to the
  implicit block wrapping the body of your primary method.  This is
  exactly the correct behavior (see CLtL2, page 839).
  
    ... how do I exit from a primary method such that :AFTER method are
    skipped?  I'd like to avoid use of THROW and non-standard method
    combination.  Is it possible?
  
Use an :AROUND method.   Do you consider than non-standard?

Newsgroups: comp.lang.clos
From: jmg@inference.COM (Jeff Greif)
Subject: Deleting an Instance
Organization: Inference Corporation
Date: Thu, 30 Jul 1992 17:31:37 GMT

If the classes of your instances are in the
standard-class metaclass, the instances should be
garbage when you relinquish all pointers to them, and the
garbage collector should reclaim the storage.  The
implementation is broken if this doesn't happen.

If your classes do instance-registration (keeping a list
or all their instances, or some such), you will have to
unregister all those that should disappear.

If your implementation has no garbage collector, then you
need to manage the instance memory yourself.  You could
define a new metaclass which allocates an expandable
pool of raw instances for each class.  You could then
provide an around method on allocate-instance for this
metaclass which would allocate from the pool or call the
next method as necessary.  Also provide a destroy method on the base
class of this metaclass which returns the storage of the
instance to the pool.  It should get specialized by the
subclasses to do other cleanup processing via :before
methods.  Either destroy or allocate-instance must reinitialize
the slots to be unbound.
Newsgroups: comp.lang.clos
From: wwinston@athena.mit.edu (R. Whitney Winston)
Subject: Deleting an Instance
Organization: Massachusetts Institute of Technology
Date: Thu, 30 Jul 1992 16:27:53 GMT


How can I remove an instance?
The problem is that I'm creating about 25,000 instances
but after about 4000 instances, I run out of memory; however,
I don't need more than 1000 at a time.  As soon as I finish
with the first 1000, I no longer need them and they can
be forgotten.  How can I get rid of the unnecessary instances
after I've used them?

Thanks,

Whitney Winston
<wwinston@athena.mit.edu>
<wwinston@speckle.ncsl.nist.gov>
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++
Subject: Re: Renew?
Date: 25 Jul 92 18:27:40 GMT
Article-I.D.: alice.23315
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Liberty Corner NJ

In article <THOTH.92Jul25110048@wave.cis.ufl.edu> thoth@wave.cis.ufl.edu (Robert Forsman) writes:

> The absence of an analog for realloc is one of my MAJOR gripes with
> C++

So make a proposal.  I and several other people have thought about
it from time to time but so far I have not seen a proposal I like.

There is also the problem that it is potentially very difficult to
implement in a C-based environment if it is required to use realloc.
The trouble is that you can't tell whether realloc will move something
until after it's too late.

>   It is.  If they're too busy considering other stuff, they can put it
> on hold.  This is more important.

It may be more important to you; it is probably not more important
to most of the committee members.  For example, I do not think anyone
has actually sent in a proposal for it.

>   Well, I'm not sure I like that.  I'd much rather see a bcopy instead
> of a copy construction and a deletion in almost every case (almost).
> I may have missed the discussion about why this is bad.

If I write a copy constructor in my class, I expect that constructor
to be called when an object of that class is copied.  Period.

>   Why not have ANOTHER special method (in addition to copy
> construction, deletion and assignment) which is only called when an
> object is being MOVED from one memory location to another?

That is much too much added complexity for one special case.  I can
confidently guarantee that if such a feature were added, the majority
of C++ programs would either misuse it or forget to use it altogether.

Simple things are hard enough without looking for more ways of
complicating them.
-- 
				--Andrew Koenig
				  ark@europa.att.com
From: cs911209@ariel.yorku.ca
Newsgroups: comp.lang.c++
Date: 18 Jul 92 03:50 MDT
Subject: Re: boolean (was: Re: typedef vs enum)
Nf-ID: #R:1992Jul11.195547.18323@cmcl2.nyu:1382747533:1992Jul17.235055.13535@newshub.a:231667568:001:1037
Nf-From: ariel.yorku.ca!cs911209    Jul 18 03:50:00 1992


In article <DOUGM.92Jul17133255@titan.cs.rice.edu> dougm@titan.cs.rice.edu (Doug Moore) writes:
>In article <23195@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:
>Andrew> I would love to see a built-in Boolean type in C++, but
>Andrew> unfortunately it's too big a change from C.
>
	6 lines deleted..

>I would also love to see a built-in Boolean type in C++.  I would
>gladly engage in a discussion on how it could be done.  What specific
>problems do you believe make a Boolean-type extension to C++
>infeasible?
>

	One thing that makes C a nice language to program in, is the fact
that NULL and 0 can mean false, and non-NULL and non-zero can mean true.
	I would like to see some kind of consistent boolean type in C++,
but I would also like to be able to say:

SomeObject *ptr;
...
while (ptr)
...

	and:

if (!(fptr = fopen( "myfile", 'r')))

	etc.

	I think the best way to do this would be to have some typecasting
rules from int to boolean and from pointer types to boolean.

Michael Davis			York University, Toronto
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.c++
Subject: Re: inlining a virtual function.
Summary: no problem
Keywords: inline virtual
Date: 24 Jul 92 01:31:03 GMT
Article-I.D.: alice.23302
Organization: AT&T Bell Laboratories, Murray Hill NJ



mittle@watson.ibm.com (Josh Mittleman @ IBM T.J. Watson Research Center) writes

 > > class A {
 > >   virtual int f() { return 1; }
 > > };
 > 
 > > "x.c", line 1: warning: virtual function  A::f() cannot be inlined
 > 
 > > My question is why CANT we inline a virtual function?
 > 
 > An inline function does not have an address, because it does not generate a
 > function call.  Instead, it is expanded at compile time (sort of like a
 > macro).  A virtual function has to have an address, which will be stored in
 > the virtual function table, and must always be accessed through a function
 > call. 

Actually, you can take the address of an inline function. The semantics of taking
the address of an inline is that a non-inline copy of the function is layed down
and its address is then used.

In some implementations this can lead to memory overhead caused by "outline inlines"
and in many calls inlining cannot be done for an inline virtual (because it cannot
be known at compile time exactly which f() is to be invoked). For example:

void (A* p, A obj)
{
	p->f();	// cannot inline (*p might be of a class derived from A with a different f() )
	obj.f() // can inline
}
Newsgroups: comp.lang.c++