HDTenEightyP/NetNews huggingface dataset:
From: mrt+@CS.CMU.EDU (Mary Thompson)
Newsgroups: comp.os.mach
Subject: Re: i386 Mach availability
Date: 27 Aug 92 16:24:53 GMT
Organization: Carnegie Mellon University

A complete Mach/Unix-interface operating system is available from CMU 
IF AND ONLY IF the machine you want to run it on is covered by a BSD4.3
license which has a prerequisite of an AT&T source license AND you are
able to get the files via an internet connection. We do not have the resources
to make tapes or floppies available. This distribution is free and runs
on the hardware specified in /usr/mach/public/doc/papers/i386_install.doc
on mach.cs.cmu.edu. 

The Mach 3.0 micro-kernel sources are available without license restrictions
via anonymous FTP from /usr/mach/public/src. This is not a complete operating
system.

Mt Xinu sells a source version of Mach which requires that the customer has
an AT&T source license and also a binary version for which you do not need
any previous licenses. Their distributions come on tapes so you do not need
network connection to install them. The source distribution also includes 
12 volumes of printed documentation. They can sell binary only releases 
because they have a commerical AT&T license that allows distribution to
non-licensed site (with the appropriate royalty paid to USL). CMU has an
AT&T educational license which does not allow such redistrbution.

CMU was distributing a BSS single server and user environment based on
Bill Jolitz's relase of the BNR2 code. We have suspended this distribution
since the announcement of the USL CSRG lawsuit. 

				Mary Thompson
				Project Mach Distribtution Manager
From: nerd@percival.rain.com (Michael Galassi)
Newsgroups: comp.os.mach
Subject: Re: Mach 3.0 on 386/486
Date: 30 Aug 92 05:39:34 GMT
Article-I.D.: percy.Bts7q1.1I5
Organization: Percy's mach, Portland, OR

rcd@raven.eklektix.com (Dick Dunn) writes:

>ewanco@kalvin.enet.dec.com writes:

>>Do NOT, repeat, do NOT buy Mach from Mt. Xinu!!...

>Do NOT, repeat, do NOT listen to this bozo!!

>mt Xinu is one of the oldest bastions of UNIX development in the commercial
>world.  Not to say they've never slipped up, but they know what they're
>doing.  Mach/386 is a good product.

Hmm, maybe, maybe not, as of 2 months ago they had not gotten the freopen
library routine to work right so you could not type common things like
"compress -d *", you had to use "for i in * ; do compress -d $i ; done".
They have known about this one for at least a year now.  The floating
point libraries are broken in more ways than one.  Shadow password files
are not supported.  nslookup was not in their source tree when I asked
why it was not included.  When bugs are fixed, there is no way to get
the fixes unless you have their overpriced autosupport (Sun, SCO, and
HP all make fixes available over the internet.

>Yeah, right..."my friend told me"...care to tell us who this illustrious
>flamer was?  The "appeal to authority" argument fallacy is bad enough,
>without the "authority" being anonymous.

No friends here, I bought the stuff and would sell it in a flash.

>Actually, I ran Mach/386 for a fair while (not running it currently, only
>because I have 2 more operating systems than machines!) and found it to be
>a quality system.  I used it for real development (i.e., a large piece of
>software I was being paid to develop).  I also found the folks at mt Xinu
>very helpful, easy to deal with, and professional.

I find it telling that you are not running it now, if I could afford
BSDI's product I would not be running this stuff either.

>I have to wonder if "several revs behind" means "not on the bleeding
>edge"--waiting for code to settle down before using it.

It means that root is forced to uid -2 even for trusted boxes over NFS
unless you tweek the kmem value for nobody's uid among other things.

>Second, because you might want support, and CMU isn't in the support biz.
>That's why they arranged with mt Xinu to do the commercial version.

support?  mt Xinu?  I laugh in your general direction.
-- 
Michael Galassi -- nerd@percival.rain.com
Newsgroups: comp.object,comp.lang.clos
From: graham@maths.su.oz.au (Graham Matthews)
Subject: Re: Implementation Question
Organization: School of Mathematics and Statistics, University of Sydney
Date: Thu, 3 Sep 1992 10:15:57 GMT


Graham:
>Now my problem is as follows. How do OO implentations handle the 
>space allocation for an instance of class B? Does an instance of B
>have to have space allocated for all the instance variables in B as 
>well as all the instance variables in all the classes of which B is 
>a sub-class (in this case class A). I ask this for three reasons :-

barmar@think.com (Barry Margolin) writes:
>This is the distinction between inheriting behavior and structure.  
>Most OO languages use the same mechanism for both, thus making it 
>tricky to do what you want.

(Urs Hoelzle) writes:
>Exactly.  And I can't resist mentioning that Self does The Right Thing
>(TM) - with the nice side effect that no code ever depends on the 
>format of an object (i.e. whether is has an x instance variable or an
>x method).

There are two problems here :-

a) often one wants to force the inheritance of behaviour (eg: all 
subclasses of a group class must have a multiplication method or
they are not a subclass).

b) code that does not depend on the format of an object is slow.
In some application domains such code is unacceptably slow.

graham
--
Graham Matthews                 And it's true we are immune
Pure Math, Uni.Sydney, Oz       When fact is fiction and T.V. is reality
graham@maths.su.oz.au
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class Specifications
Date: 3 Sep 92 14:39:22 GMT

johnson@m.cs.uiuc.edu (Ralph Johnson) writes:

|After examining an example of Rumbaugh's,
|"Ronald C. Schultz" <p00058@mail.psi.net> writes:

|The class looks fine to me.  I can see where you
|are coming from, since I have argued with Ed Berard on this point a
|lot.  Basically, I think your assumption that a Circle shouldn't know
|anything about a Line is mistaken.  You wouldn't want to make Circle
|independent of Point, would you?  If you want to be able to intersect
|geometric figures, and I claim that is *essential* to the meaning of
|geometric figures, then you have to be able to compare one with another.
|This means that you have to have something like intersectLine.

The problem here is one of context.  A circle, in and of itself,
should not need to know anything about a Line.  However, if that
Circle is part of a family of objects, all of which know how to find
their intersection with a Line, then the knowledge of Line is an
attribute of the family which is inherited by its members.  This is
proper.

|I claim that you don't want to make a Circle class that is an independent
|standalone entity.  The problem with small classes is that it takes too
|much work to reuse them.  There is much bigger payoff when classes come
|in families of similar classes, because then you can learn one class and
|then just reuse your knowledge for all the other classes.  A Circle should
|be part of a GeometricObject family of classes.  There will be a standard
|set of operations that all the classes must implement, such as intersecting
|with a point or another GeometricObject.  These classes will be designed
|as a family and will probably be used as a family.  You are unlikely to use
|a Circle in an application and not use a Line.  

Agreed.




--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
From: objsys@netcom.com (Bob Hathaway)
Newsgroups: comp.object
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Date: 1 Sep 92 22:54:27 GMT
Organization: Object Systems

>In article <31cnnr+.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) writes:
>   [ use CLOS terminology in preference to Bob + Coplien ]
>
>   Then we'd be left with the more verbose but precise: "multiply-polymorphic
>   methods" terminology.  People might still get confused over whether
>   "methods" referred to CLOS, classical OO or some other kind of method.
>
>So?  Do you claim that if we all adopt your terminology there will be
>no confusion?

Ok.  If there's confusion I won't add to it.  I will use the unabbreviated
terms multiple-argument dispatch or multiply-polymorphic methods when
applicable.  This makes clear the intended meaning without adding superfluous
orthogonal detail.

>   CLOS stores methods specialized to a class with that class anyway. 
>
>Shouldn't that be "CLOS stores methods specialized to _classes_ with
>_those_ classes anyway" as the whole point is that it allows you to
>specialise on more than one argument.  Anyway, what does it matter how
>it is _implemented_, it is the semantics that are important.

Nope, storing it based on the first argument specializer is simple because
of the left-to-right priority.  The implementation I was referring to came
from a subset implementation of CLOS and helps with reflection by allowing
all methods specialized on a class to be accessed or listed together.  This
makes sense with a left-to-right argument specialization precedence which
I believe emulates receiver priority.  I mentioned it to show the close
semantic similarity between the approaches.

For example:

1) fn(A a, B b, C c, D d);	// CLOS
2) class A{
     fn(B b, C c, D d);
   };
3) fn(A a, B b, C c, D d);	// ordinary function

1) is not symmetrical, in fact it is almost the same as 2) but the CLOS style
is still enforcing a left to right priority scheme for the rest of the
parameters.  In 2), The class member function does specialize on its receiver
but is typically symmetrical for the rest of the arguments.  3) is truly
symmetrical because it is a function and treats all arguments equally.
Intercessory protocols can be used to provide arbitrary orthogonal argument
matching but the defaults still define typical usage.

So CLOS' approach to encapsulation - functions with complete access to all
specialized (and perhaps non-specialized) arguments - is irrelevant from
an argument matching perspective.  And I still disagree with the dropping
of protection on all but the first object since per-object protection is
(reasonably) required for the separation of types and classes and IMHO without
this separation a language is of little use for advanced applications.

bob
objsys@netcom.com
From: moss@cs.umass.edu (Eliot Moss)
Newsgroups: comp.object
Subject: Re: Advanced Degrees in OOP
Date: 1 Sep 92 15:36:10 GMT
Reply-To: moss@cs.umass.edu
Distribution: usa
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
In-reply-to: paul@svl.cdc.com's message of 1 Sep 92 05:39:23 GMT

>>>>> On 1 Sep 92 05:39:23 GMT, paul@svl.cdc.com (Paul Kohlmiller) said:

Paul> I would like to get an advanced degree in CS with an emphasis in
Paul> OOP.

As a CS educator in a dept that grants MS and PhD degrees, I think this is too
narrow a focus for a degree. I can see focusing on "theory", or "AI", or
"architecture", or ..., but what you seem to be aiming at I would call
"software engineering", and I would hope you'd be educated to a lot more than
(a) OO approaches and (b) programming. After all this is supposed to be
computer *science*, not something like Evelyn Wood speed reading. That is, we
are trying to teach something more borad and longlasting than the latest fad.
(Which doesn't mean that we should not respond to advances in the state of the
art!).

Clearly you hit a kind of "hot button" here!
--

		J. Eliot B. Moss, Associate Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
Newsgroups: comp.object
From: jeffery@flood.com (Jeffery Cavallaro)
Subject: Re: Future Issues of Object Orientation
Organization: The Flood Group, Inc.  Torrance, Ca.
Date: Fri, 4 Sep 92 16:20:52 GMT

In article <1992Sep2.151821.643@afs.com> dave@afs.com (David J. Anderson) writes:
>
>I think the singular critical issue will still be the interfaces and  
>connectivity of objects.
>
>Inevitably, we will build objects which are complex; today's applications  
>will be tommorrow's building blocks ...
>
>This is a very organic situation ...
>

I believe that Dave is correct, especially when he points out that the
"building blocks or tomorrow" are todays object's that have evolved through
adaptations in their connectivities.  Many people, (OK, managers) look upon
reuse as a cut and paste or black box activity.  As Dave points out, this
type of reuse only gets you so far.  We can design an interface to sufficiently
serve a couple of applications, but it is virtually impossible to design an
interface to cover all uses/interactions of an object,

In my opinion, the two major points that need to be resolved are as follows:

    1.  What is and how do you design an adaptable interface?

    2.  What is the agent that forces the adaptation?

Objects do not change in and of themselves.  I assert that all object changes
in the real world occur due to some outside influence.  When programming, we
have an end result in mind, suggesting that the outside agent has knowledge of
the objects it is affecting and the desired result - but this is not the way
it happens in nature.  Although certain feedbacks between an object and its
environment give rise to some level of cooperation, in general the environment
is a forcing function that embodies no purpose in relation to the objects in
the environment.  Thus, things like ecosystems form not because the initial
environment desired an ecosystems, but because the objects in the environment
adapted and connected according to the attributes of the environment.

[BTW: I am a Christian and do not find that last statement in conflict with
      my religious beliefs, but that is another discussion group...]

Anyway, these are very hard questions, so I do not think that connectivity as
Dave wishes it to be will be a near future concern.  That doesn't mean that
we shouldn't keep it in mind though.



Newsgroups: comp.object,comp.c++
From: zygote@cs.uiuc.edu (The seed of all life)
Subject: Re: c++ public domain and code
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Thu, 3 Sep 1992 20:51:50 GMT

Stefan Monnier <sm86+@andrew.cmu.edu> writes:

>Excerpts from netnews.comp.c++: 31-Jul-92 c++ public domain and code
>Liang Liu@seas.gwu.edu (95)

>> Hi there, I am looking for C++ public domain locations.

>It is GCC !

>All GNU software can be found at ftp.uu.net  (in /packages/gnu)
>For specific sites, it is highly machine dependant !

Is there an OO Lisp available in the public domain?  (please post,
this account has mail problems currently).

Thanks

Newsgroups: comp.object
From: oherb@jhunix.hcf.jhu.edu (Zoher B Bambot)
Subject: Re: GC (was Let's build a new OOP language)
Organization: HAC - Johns Hopkins University, Baltimore
Date: Fri, 28 Aug 1992 20:29:29 GMT


I am working on developing classes for simulation of finite element meshes
using the object-oriented language c++. I would be grateful if anyone could
send me any programs in c++ which would help me in my work. Also has anyone 
developed a class for the simulation of a FEM for any particular structure.
You can mail them to me at my e-mail address and then I will summarize in
the net. Also are there any ftp sites from where I could get any useful
information. Thanx in advance.
                         Zoher.
From: drew@netcom.com (Drew Wade)
Newsgroups: comp.object
Subject: Re: Versant, Objectivity or any other OODB language?
Date: 31 Aug 92 22:29:45 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

Objectivity's contact information is below.

We sell Objectivity/DB, an object DBMS, and related products.  Our
particular strengths in the engine area include a unique full
distribution and heterogeneity, that delivers a single logical view
across multiple databases on a mixture of heterogeneous machines,
and high performance that scales with objects and users.
On the broader environment, we work with more tools, etc., off-the-shelf
due to our use of standard languages (no modifications to c or c++
or proprietary pre-processor required), and also have built our tools
around an open backplane that can be integrated with third party
tools and backplanes, and in fact has been so integrated with HP Softbench.

Drew Wade
Objectivity, Inc.
800 El Camino Real
Menlo Park, CA  94025 USA
drew@objy.com
l1(415)688-8000 voice
l1(415)325-0939 fax
admin ass't:  Vickie Clements (vickie@objy.com)
information:  info@objy.com

67 South Bedford St., Ste. 400W
Burlington, MA  01803
(617) 229-5817
(617) 272-0558 fax

11050 Strathmore Dr., #316/300B
Los Angeles, CA  90024
(310) 208-6117
(310) 208-5677 fax

-drew wade



In article <1992Aug31.043714.20818@sunb10.cs.uiuc.edu> ywlee@sparc2.cs.uiuc.edu (Youngwhan Lee) writes:
>Hi,
>Do any of you out there know anything about Versant and/or Objectivity?
>
>In particular, I need to know,
>
>1) who are the manufacturers?, telephone numbers? addresses?
>2) Pros and cons?
>3) We are to investigate writing a DB application. Are they right
>candidates for the programming tool? 
>(I don't even knwo what they exactly are. :-P
>
>Thanks in advance.
>
>youngwhan.
>-- 
>ywlee@uiuc.edu, ywlee@cs.uiuc.edu           | University of Illinois
>1408 W. University Ave., Urbana, IL. 61801  | Computer Science 
>(217) 244-7551   			    |
>Yes, I believe in science, but nothing else.| Innosys? What is it?
Newsgroups: comp.object,comp.lang.clos
From: hoelzle@Xenon.Stanford.EDU (Urs Hoelzle)
Subject: Re: Implementation Question
Organization: CS Department, Stanford University, California, USA
Date:  2 Sep 92 19:16:29 GMT

barmar@think.com (Barry Margolin) writes:

>In article <graham.715435125@galois> graham@maths.su.oz.au (Graham Matthews) writes:
>>Now my problem is as follows. How do OO implentations handle the 
>>space allocation for an instance of class B? Does an instance of B
>>have to have space allocated for all the instance variables in B as 
>>well as all the instance variables in all the classes of which B is 
>>a sub-class (in this case class A). I ask this for three reasons :-

>This is the distinction between inheriting behavior and structure.  Most OO
>languages use the same mechanism for both, thus making it tricky to do what
>you want.

Exactly.  And I can't resist mentioning that Self does The Right Thing (TM)
- with the nice side effect that no code ever depends on the format
of an object (i.e. whether is has an x instance variable or an x
method).

-Urs

[Adv: For more details on Self, get selfPower.ps.Z and organizing.ps.Z
from self.stanford.edu:/pub/papers]
From: paul@svl.cdc.com (Paul Kohlmiller)
Newsgroups: comp.object
Subject: Re: Advanced Degrees in OOP
Date: 3 Sep 92 06:03:21 GMT
Distribution: usa

I appreciate the comments so far. I wasn't thinking of an MBA in OOP but 
something like that. Let's call it a MSCS with OO emphasis.
I agree that OOP might be too restrictive but not OO. I don't think I see OO as
more narrow than AI but I'm getting dangerously close to AI bashing again.
At ObjectWorld Steve Jobs said something like "Aren't we in danger of having the
phrase 'object oriented' become as meaningless as 'Artificial Intelligence'?
"
The context was some OO demos that naturally looked a little sickly next to NeXT
On the other hand, OO will someday be replaced with something else but probably
something that does an even better job of modeling reality (whatever that is).
Certainly, all of the programming techniques (languages and style and design)
that I learned in college have been replaced. I still need to decipher hex
numbers but I learned that in 7th grade. I'm not sure if the transient nature
of software technology makes it too narrow of a focus.

--
     // Paul H. Kohlmiller             //  "Cybers, Macs and Mips"    //
     // Control Data Systems, Inc.    // Internet: paul@svl.cdc.com  //
     // Acronym under construction.  // America Online: Paul CDC    //
     // All comments are strictly my own. I won't lie but my       //
     // perception of reality is at best a personal hunch.        //
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Wed, 2 Sep 1992 11:15:20 GMT
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Organization: Hewlett-Packard Laboratories, Bristol, UK.
From: jeffery@flood.com (Jeffery Cavallaro)
Subject: OBJECT CREATION FROM RAW ATTRIBUTES
Organization: The Flood Group, Inc.  Torrance, Ca.
Date: Tue, 1 Sep 92 01:26:39 GMT

Greetings, All!

We have run into an interesting problem.  Maybe someone can lay a little
theory on us, or point us to the proper references.

We are essentially "attribute collecting" from several data streams.  The goal
is to create persistent objects based on attribute values.  A couple of the
streams can be referred to as "necessary" in that the relations that are
derived from the combined values are required to identify unique objects.
The remaining streams can be referred to as "auxiliary" in that their values
further amplify existing (or soon to exist) objects.  The criteria are as
follows:

    1.  Make object creation as independent of stream data order as possible.

    2.  Facilitate queries both by (a) object and by (b) object attribute.

    3.	Make the objects physically self-contained so that the raw stream data
        can be cleaned up at will.

Our first solution was strictly relational.  Each data stream was plunked into
a database table.  Relational queries and joins were then used to massage the
data into whatever form was necessary.  This approach really only satisfied
criteria (2b) and there was no object creation.  The only thing that you could
say is that all "form massages" were equally expensive, and no resources were
spent favoring one form over another.

The new solution that we are toying with will use the RAIMA network model to
form self-contained objects (allowing for a little bit of data duplication).
The part we are struggling with is balancing when to identify set relations to
RAIMA with criteria (1).  Do we update all relationships for each new data
point from any stream, or do we do things periodically?

Anyway, any and all feedback is appreciated!
Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: Object-Oriented Methodologies - Class Specifications
Date: Wed, 02 Sep 92 19:57:03 GMT
Organization: Object Systems

  [Please forgive my brief interjection, I haven't been following.]

In article <BtyJK8.GFH@rice.edu> mcw@cs.rice.edu (Michael Wirth) writes:
>It's very interesting to note how our use of language (both programming and
>human) influences our thinking.  In particular, use of a message passing style
>of OOP, where methods are "owned" by their target class, leads to the curious
>asymmetry noted above.  In a language, CLOS, which uses generic functions and
>multi-methods (i.e., which specialize on more than one argument), this
>asymmetry can be avoided, i.e., we would define a generic function, INTERSECT,
>which would specialize on both its arguments.  One specific method which it
>would be useful to define then would specialize on lines and circles:
>        INTERSECT((x, LINE) (y, CIRCLE))

In "OOP" the INTERSECT function could be made a "friend" of LINE and CIRCLE
granting INTERSECT access to both classes without violating a strong form of
encapsulation.  Perhaps "strict OO messaging" could be substituted for "OOP".
But I'd keep in mind that such implementation access isn't always a good thing.

>Who "owns" this method?  Probably some higher level entity, like the "geometry
>package".

I agree.

bob
objsys@netcom.com
Newsgroups: comp.object