HDTenEightyP/NetNews huggingface dataset:
From: kanderso@bbn.com
Newsgroups: comp.lang.clos
Subject: Re: Built-in functions (was Re: Beginner's Question - CLOS)
Date: 7 Oct 92 11:04:21 GMT
Article-I.D.: news.9210071901.AA12962
Organization: The Ohio State University Department of Computer and Information Science


  To: comp.lang.clos@cis.ohio-state.edu
  Date: 20 Sep 92 14:18:02 GMT
  Organization: School of Mathematics, University of Bath, UK
  From: C D Burdorf <mascdb@gdr.bath.ac.uk>
  Sender: commonloops-request@cis.ohio-state.edu
  References: <9209181825.AA08510@thelonius.mitre.org>.edu
  Subject: Re: Built-in functions (was Re: Beginner's Question - CLOS)
  
  In article <9209181825.AA08510@thelonius.mitre.org> john@linus.mitre.org writes:
  >
  >True, but many (most?) of the "built-in" functions in a Lisp
  >implementation are neither implemented in assembly language, nor are
  >they usually open-coded into calling code. 
  
  I'm suprised people are arguing with me on this point.  I C coded
  the exponential distribution function and did a foreign function
  interface to CMU Lisp and it was many times faster than what the
  CMU common lisp compiler could produce with declares and speed at 3
  and safety at 0.  
  
  I've seen over and over again cases where people can write
  assembly code that is faster than what Lisp compilers produce.
  
  HCL is a very fast (on sun3's) lisp and part of the reason is
  that much of it is written in assembly language.

To avoid comparing apples to oranges, it might be helpful to get examples
of code from people who have been commenting about performance of C and
Lisp.  Often when someone rewrites software, it has different performance
characteristics the second time.  For example, porting to a parallel
processor can make your code faster even on a uniprocessor, if you spend
more time worrying about performance than you did when your first wrote
your algorithm.

I can imagine that simply proclaiming speed 3 and saftey 0 may not help
performance much unless you do other things too.  For example, if your Lisp
conses floats, or your algorithm uses trig functions that require crossing
the Lisp/C boundary a lot.

I can imaging that there must be things that are equally fast in C,
assembly, or Lisp.  For example, a properly declared (AREF X 3) is still
only 1 instruction in all these languages.
From: ssmith@LOX.intel.com
Newsgroups: comp.lang.clos
Subject: how to neatly destroy instances?
Date: 15 Oct 92 15:47:22 GMT
Reply-To: <ssmith@LOX.intel.com> (Stephen P. Smith)
Organization: Az-Kal

In article<9210142115.AA04377@skinner.cs.uoregon.edu>will@skinner.cs.uoregon.edu (William Clinger) writes:
> ... 
> 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.
> 

Forgive my lack of knowledge (or perhaps more likely lost memory
pathways) and laziness in not finding and reading the right
papers:

Could you please give a 2 paragraph summary/tutorial on how the
modern generational schemes give time proportional to the number
of live nodes?  How do they maintain which are live and which
dead?

Dr. Stephen P. Smith
Newsgroups: comp.lang.clos
From: miller@cs.rochester.edu
Subject: How to neatly destroy instances?
Organization: The Ohio State University Department of Computer and Information Science
Date: Wed, 14 Oct 1992 19:58:25 GMT

> Date: Wed, 14 Oct 92 12:14:03 PDT
> From: jonl%kuwait@lucid.com (Jon L White)

> But that's the beauty of "generational" style collectors!

You're right; I recant (or recast) my position vis: "Always cheaper"; I
had in mind only large structures, such as (most... in my applications)
CLOS instances, that are relatively long-lived, not basic cons cells.
Clearly generational scavanging is a big win in the latter case.

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. 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'.

Newsgroups: comp.lang.clos
From: chyde@pecos.ads.com (Clinton Hyde)
Subject: Re: clos & environment available?
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
	960-7300
Date: Tue, 13 Oct 1992 15:47:39 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.

is there a clos imp? yes, there are at least two. Lucid and Franz Inc.
both have pretty good versions of CLOS. I use Franz' version. because
of this, following answers apply only to it...

class examiner: none that I know of. 

good debugger: well, it's not bad, but not the window debugger. I'm
working on a window debugger that runs under CLIM (the version I have
is for Lucid...which I can't test).

network capability: not sure what you mean, but it is possible to do
IPC/RPC sorts of things via sockets.

multi-process: lightweight processes are there. i use them all the
time. the startup stream is really more equivalent to the cold-load
stream. 

ipc: i worked a project with this last year, using a third-party comm
toolkit (ISIS). once ISIS settled down (it was prone to wedging until
V3), it went pretty smoothly, for about 8 machines (incl two SGs). 

I don't know what "file cm/cc" is...

whatever you get, it's not going to be Genera.

Franz at least has decent link with Emacs/Epoch, which I use. that's
about the closest to ZMACS as is possible.

 -- 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: chyde@pecos.ads.com (Clinton Hyde)
Subject: Re: How to neatly destroy instances?
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
	960-7300
Date: Fri, 16 Oct 1992 18:45:53 GMT


actually, i'd like to be able to do so. I'm working something now
which is likely to create a bunch of junk on the fly (using the
copy-instance code I mentioned [speaking of which, there was someone
at uni-ulm.de who wanted it--i cant' reply to you]), whose lifetime
may be fairly short, and I know that when it's gone I need it gone
immediately, and it will point to things in a database which shadow
it, and they need to go to, but the GC won't/can't do that.

weak pointers I don't think I need, but as it is I am going to have to
do some obj-mgmt destructors behavior myself.

 -- 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: jeff@aiai.edinburgh.ac.uk (Jeff Dalton)
Subject: Re: How to neatly destroy instances?
Organization: The Ohio State University Department of Computer and Information Science
Date: Tue, 13 Oct 1992 13:40:40 GMT

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

I don't know why the original poster felt this need, but I
recently needed something in that general area, namely a way
to provide "finalization" code for when an instance was
freed by the garbage collector (or by me, I suppose).
A possible case might be a file: when I'm done with it, I
want it closed.  What I actually had was some instances
that were "handles" on objects held by another program
that I was communicating with via a pipe.  If a handle
was garbage collected, I wanted to tell the other program
to delete the corresponding object.

Some cases of this sort can be handled in the manner of
WITH-OPEN-FILE, but not all of them.

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.

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

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

re: >>>>> "Brad" == Brad Miller <miller@cs.rochester.edu> writes:

      Brad> This is in general true, and why Lisp tneds to be a nice language 
      Brad> for exploratory programming. However, once you are trying to 
      Brad> optimize a program and actually make it efficient at runtime, it 
      Brad> is always cheaper for an application to explicitly free memory 
      Brad> than it is for the gc to do it. What would be really nice is to 
      Brad> have, as on the lisp machine, areas of memory (heaps) that are not
      Brad> gc'd, but must be explicitly freed by the programmer.

    *Always cheaper* ?! I think there are a couple of people, Ben Zorn in
    particular, who would claim that automatic garbage collection is better
    than explicit memory management. Here are three arguments I can think of
    where GC could win:
    1) The cost of calculating when to free memory could be cheaper.
    2) Memory compaction.
    3) The elimination of memory management errors.

    In short, I'm not so sure the issue is that cut and dried.

At the 1992 ACM Lisp & Functional Programming Conference, Will CLinger
had to stand up and rebut this "urban myth" about explicit storage
reclamation always being faster (it had been repeated in one of the
technical papers presentations).  Will, a Professor at University of
Oregon and a long time Wizard of SCHEMEology, alleged to be writing a
paper on just this topic.

In fact one of the most interesting bugs I ever saw logged against the
Lucid Common Lisp system was: "GC runs to fast"!!!   It seems that the
end user had an application that would create hundreds of thousands of 
little particles of data and "drop them on the floor" all within the space 
of a couple seconds (these were intermediate expression temporaries), and 
this process would go on for several minutes in a row.  Of course, about 
every few seconds or so, an "ephemeral" or "generational" scavenge would 
be invoked, and by careful monitoring the user discovered that each such 
scavenge was taking much less than 25 milliseconds (on a SparcStation; 
maybe an SS2?).  Since it was manifestly impossible to "reclaim" the 
nearly one megabyte of garbage in just a few milliseconds, he figured 
that the GC wasn't actually performing its work.


But that's the beauty of "generational" style collectors!


If you need more convincing about this topic, just try calculating how 
long 200,000 calls to _free would take in C.  Or, wait for Will's paper.



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

re: Finalizations are quite useful and appropriate for a few very kinds of
    purposes.  Generally these involve explicit ``system programming''
    tasks such resource management for very large or otherwise expensive
    objects, or objects that require some active cleanup of non-Lisp
    resources, such as closing a Unix stream if inadvertently abandoned.
    . . . 

More of the beauty of a good Lisp implementation -- the lines between
Lisp-system programmer and end-application programmer are blurred.
A sophisticated Lisp user -- while not necessarily understanding every
thing about the Lisp implementation he is using -- will ultimately 
wind up needing many of the ``system programming'' facilities developed
by the Lisp implementor.  Such as RESOURCE's, Finalization, etc.


re: . . . 
    I don't think finalizations belong in the language standard -- they
    are a non-standard agreement between application writer and the
    implementation's storage management system.  

They are "a non-standard agreement ..." by historical accident -- not
by nature or by definition.


re: . . . It is still conceivable
    that memory architectures might someday change and someone might
    implement a lisp that doesn't need a gc because it can arbitrarily
    grow memory.  Although fanciful, such an implementation shouldn't be
    precluded, therefore the very concept of garbage itself doesn't belong
    anywhere in the language spec -- except tangentially with things like
    the DYNAMIC-EXTENT declaration.  It provides advice to the compiler
    and doesn't add any semantic content to the language.

See my paper in the 1980 Lisp conference: "Address/Memory Management
in a Gigantic Lisp Environment, or GC Considered Harmful."  The 
conference record has been reprinted by ACM, and this paper in
particular has been reproduced in an early issue of Lisp Pointers.


-- JonL --
From: jeh@windrider.llnl.gov (Jose E. Hernandez)
Newsgroups: comp.lang.clos
Subject: Why not a copy protocol
Keywords: clos copy copy-protocol
Date: 10 Oct 92 21:41:25 GMT
Reply-To: jeh@llnl.gov (Jose E. Hernandez)
Organization: Lawrence Livermore National Laboratory

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...

thank you!

jose'

PS  I am looking for reasons why CLOS doesn't include a copy protocol,
not necessarily for examples on how to implement one.
Newsgroups: comp.lang.clos
From: chyde@pecos.ads.com (Clinton Hyde)
Subject: Re: Fate of obsolete accessors
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
	960-7300
Date: Tue, 13 Oct 1992 15:40:02 GMT


without verifying this, what probably happens is that there is still
an accessor called GET-A, which will operate on an object of the type
is was created for. when called, you get some error about the object
not having that slot any longer...

of course, if something else is actually done to GET-A...

it'd be fairly simple to force the obsolete methods to vanish...

 -- clint (who's been doing some digging in CLOS the last few weeks)
--

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
From: kennedy@Intellection.COM (Brian M Kennedy)
Newsgroups: comp.lang.c++
Subject: Re: RPCGEN and C++
Date: 14 Oct 92 21:58:51 GMT
Organization: Intellection Inc.
Supersedes: <KENNEDY.92Oct12083407@fuller.Intellection.COM>

In article <1992Oct8.131946.5836@cs.brown.edu> rbb@cs.brown.edu (Robert Baynes) writes:

   We are writing a rather large distributed system using C++. We  
   are now generating our own xdr stuff (using rpcgen) for the 
   clients and servers. All of this code is generated in C. Does
   anyone know of something similar to rpcgen that would produce
   the client, server and xdr code in C++? 

In the 1992 USENIX C++ Proceedings there is a paper Minnear,
Muckelbauer, and Russo (Purdue U) titled "Integrating the Sun
Microsystems XDR/RPC protocols into the C++ stream model" that
presents a *very* nice looking approach to XDR/RPC.  The paper
says:
  The source for the new I/O stream library and the XDR/RPC
  classes discussed in this paper is public available for 
  free distribution.  Interested parties should contact 
  the authors for more information.
and gives the authors' email addresses:
  {minnear|muckel|russo}@cs.purdue.edu

Sound great?!?

HOWEVER, I have *repeatedly* tried to contact the authors to
get the software and have not yet succeeded.  :-( :-{
(Though I did get one response offering PostScript source for
 the paper.)

Has anyone successfully acquired this software?  I would sure
like to get it.

Thanks,

== Brian M Kennedy <kennedy@intellection.com> ==
== Intellection, Inc.  =========================
From: ric@updike.sri.com (Richard Steinberger)
Newsgroups: comp.lang.c++
Subject: vsprintf vs. incore-formating: philosophy
Date: 7 Oct 92 15:28:06 GMT


	Can anyone provide some advice on whether to use vsprintf() in 
a C++ program?  This C library function is not overloadable/extensible,
but it does exactly what I need done with standard data types.  Do people
generally feel that it is worth the effort to develop a similar 
function using incore formatting and thus follow "the spirit of C++"?
	If an extensible vsprintf-like function were available in C++, I
would probably use it, but I am reluctant to try to write one when
vsprintf() today is adequate to current needs.  Any thoughts?

regards,
	ric steinberger
	ric@updike.sri.com
From: ar097@mesrx.UUCP (anand ramamurthy)
Newsgroups: comp.lang.c++
Subject: Re: Good book on C++
Date: 9 Oct 92 18:44:24 GMT
Distribution: usa
Organization: Measurex Inc. Cupertino, Ca

I am new to this group. I request suggestions on good C++ book for a
beginner, which also has lot of good examples.

Thanks in advance.

anandR

Newsgroups: comp.lang.c++
From: doug@monet.ads.com (Doug Morgan)
Subject: Re: My objects are too big - why?
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
	960-7300
	<23858@alice.att.com>
Distribution: comp
Date: Mon, 12 Oct 1992 22:19:33 GMT

In article <23858@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
   doug@monet.ads.com (Doug Morgan) writes
    > The upshot for C++ is that a programming style using many abstract
    > virtual base classes can put an almost unbelievably high memory
    > overhead on each instance.  (What, your "simple" edge object takes 758
    > bytes and you need 100,000 of them per image?)  As Stroustrup said:
    > "My impression is that people seriously underestimate the value of
    > abstract classes."  Unfortunately, current C++ implementions may
    > justify such underestimates.

   Hmm. I recommend abstract classes, not ``many abstract virtual base
   classes.'' In my experience the precense of many virtual bases in
   a single object is a fairly typical beginner's design error caused
   by someone getting carried away by the idea of having ``everything
   a separate class.''

I don't think I'm laboring under a typical beginner's design error,
but I could be.  I'll briefly state my design problem, approach, and
impressions on the error's cause.

My problem area is general modeling, estimation, and control.  This
involves many well-known structures from math and physics, such as
set, relation, function, real-valued-function-on-a-finite-domain,
measure, discrete-measure, continuous-measure , bayesian-network,
manifold, spatial-object, relational-database, constraint-network,
image, local-image-approximations (edges) etc.  These structures are
related in many well-documented ways.  I want to factor the common
parts of these related structures to enhance commonality and reuse and
use inheritance to do so.  For best effect the many common classes
should be abstract and virtual.

Now, this approach admittedly doesn't map well to C++, so it is by
definition my design error in trying to use C++.  However, the
approach

  O does map well to other object systems
  O does manage the complexity of the problem area.

So, my impression is that the design error is not fundamental.  Rather
it is a consequence of running into rough spots in C++ virtual base
classes.

   [ Several examples and analysis. ]

I find that the real usefulness of virtual bases and abstract classes
(especially the virtual part) is not apparent until want dozens of
abstractly specified cooperating classes.  Small examples just don't
show the complexity increase caused by avoiding virtuals (to avoid
C++'s difficulties with scaling to many virtual bases).

doug
--------------------------------------------------------------------
Doug Morgan, doug@ads.com, (415) 960-7300
Advanced Decision Systems (a division of Booz-Allen & Hamilton Inc.)
1500 Plymouth St., Mountain View, CA 94043-1230
--------------------------------------------------------------------
From: mdk34398@uxa.cso.uiuc.edu (Mike Krupicka)
Newsgroups: comp.lang.c++
Subject: Re: streams
Date: 14 Oct 92 14:20:35 GMT
Organization: University of Illinois at Urbana

kanze@us-es.sel.de (James Kanze) writes:
>Somebody's sure to point out a better way, but it can be done with a
>pointer, ie:
>    main()
>    {
>        ostream*        finPtr ;
>        if ( stdflag )
>            finPtr = &cin ;
>        else
>            finPtr = new ofstream( "test.in" ) ;
>        ostream&        fin = *finPtr ;
>        //  ...
>        if ( ! stdflag )
>            delete finPtr ;         //  Close file
>    }

This is what I am using and does work. Thanx for all of the different ideas
sent to me.

Mike Krupicka
beaker@uiuc.edu
From: warsaw@nlm.nih.gov (Barry A. Warsaw)
Newsgroups: comp.lang.c++
Subject: Re: downcasting and "contravariants"?
Date: 16 Oct 92 17:17:15 GMT
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.


I should add that I think covariance could not only eliminate most
questionable downcasts, but also most needs for RTTI, which, for real
downcast safety, I'd have to use.
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.c++
Subject: Re: Is pointer in my address space?
Date: 10 Oct 92 21:22:51 GMT
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
In-reply-to: crlstu4@bnr.ca's message of 9 Oct 92 23:06:08 GMT

In article <1992Oct9.230608.4278@bnr.ca> crlstu4@bnr.ca (Goetz von Escher) writes:

   Is there a way to find out if a pointer is a valid pointer in C/C++?

There is no portable way, and there isn't even a widely accepted
unportable way.

   Or in other words: If I want to read a value in memory, how do I
   know wether I can read the value at this address without causing
   an exception (bus error, segmentation fault and that stuff)?

That's not the same. There are many invalid pointers that won't cause
an exception when read.

   To justify my demand: I can think of at least three problems, where it
   would be very useful to test a pointer before reading the memory it
   points to:

   [3] In the problem I'm actually dealing with:

   I am writing an error handling module within a software project.
   In case of a serious error we want to save the user data if possible. The
   data consists out of objects connected together by pointers. Now before
   I follow a pointer to test wether the data at this memory address *could*
   be an object, I have to make sure that I can read the memory address.
   Otherwise I get an exception in my error handling, which will basically
   trigger the error handling again...

The most portable way to find out whether you can read a pointer
without getting an exception is to read it and see what happens. It
doesn't take much to make sure that the second exception is handled
correctly. For example, you can change the signal handler before you
read the pointer, or you can have a global flag that is used by the
signal handler to decide what to do with the exception.

					Thomas.

PS:

   [1] When you write a debugger

   [2] When pointers come from outside the program ->user input

In those cases, there are better techniques available.
Newsgroups: comp.lang.c++