HDTenEightyP/NetNews huggingface dataset:
From: THOMASG@epx.cis.umn.edu (Thomas D. Gasser)
Subject: Daveys Dingbats in Truetype format.
Organization: Department of Neurosurgery, University of Minnesota
Date: Thu, 12 Nov 1992 17:36:10 GMT

Is there a site that has Daveys dingbats in a truetype format.  Also looking 
for Logger in Truetype.

Thanks alot.

Sorry if you see two copies of this.  Trumpet failed while posting in a 
Windows window and I am not sure is it got to the news server.  God I love 
multitasking.



*********************************************************************
*  Thomas D. Gasser                                                 *
*  Department of Neurosurgery                *******     ******     *
*  University of Minnesota                    ***  *** *** ***      *
*  (612) 624-4427                             ***   *****  ***      *
*  E-Mail:  THOMASG@STAFF.TC.UMN.EDU         *****        *****     *
*                                                                   *
*********************************************************************
Newsgroups: comp.fonts
From: antjcb@gsusgi2.gsu.edu (J.C.Burns)
Subject: Re: Star Trek NEXT GEN. font! --REQUEST--
Organization: Georgia State University
Date: Fri, 13 Nov 1992 01:34:27 GMT


>there is no
  good tool available for converting MAC fonts to Windows fonts...
 
Maybe not on the Windows side, but on the Mac side, there's a shareware
program called TTConverter which converts from Mac TrueType to Windows,
and Ares' FontMonger does the deed, as well as Fontographer from Altsys.
 
--jcburns
(By the way, the 'credits' typeface is called Crillee, it's commercially
available in Mac and PC formats.)
Newsgroups: comp.fonts
Subject: Re: Ventura and TrueType??
From: dd@netlink.cts.com (Donna Druchunas)
Date: Fri, 13 Nov 92 07:13:48 PST
Organization: NetLink Online Communications, San Diego CA

Ventura 4.1 is now TrueType tolerant, in fact they've started endorsing 
TT use at VSI and are no longer including ATM with the package.  They 
still suggest using ATM and Type 1 fonts if you are actually printing to 
a postscript device.  The upgrade price for registered users of VP Win is 
$49 and if you purchased after September ? 1992 the upgrade is free but 
these prices are only good until December 31 1992.


--                    
INTERNET:  dd@netlink.cts.com (Donna Druchunas)
UUCP:   ...!ryptyde!netlink!dd
NetLink Online Communications * Public Access in San Diego, CA (619) 453-1115
From: chandran@comp.lancs.ac.uk (M. Ramchandran)
Newsgroups: comp.sw.components
Subject: Re: Reuse Discussion Topics (Was: Reuse and Software Components)
Date: 6 Nov 92 14:03:44 GMT
Organization: Department of Computing at Lancaster University, UK.

Dear Netters,

I agree with relaing SW to HW components. But, What we need to define is the
characteristics of reusable software components?
Not just Booch's characteristics alone we need objective and realisable
characteristics may be spcific to a domain and languages.

Chandran

Dr Ramachandran
Liverpool John Moores Univ
Liverpool
From: mattb@ssc-vax (Matt Baney)
Newsgroups: comp.sw.components
Subject: Automated Software Analysis
Date: 10 Nov 92 19:18:21 GMT
Reply-To: mattb@ssc-vax.boeing.com (Matt Baney)
Organization: Boeing Aerospace & Electronics

I am posting this for a colleague who doesn't have access to the net??
Please email any information directly to Debbie, or to me and I will
forward it??

thanks 
matt
-------------------------------------------------------------

  SUBJECT: Automated Software Analysis
  KEYWORDS:  Software analysis, reverse engineering, re-engineering,
             re-use.
  E-MAIL:  rickend@net.a1.ca.boeing.com   
             (!! thats a1 (as in the steak-sauce), and not aI or al !!)

  Recently attended a discussion on automated software analysis 
  tools for transformation of existing software systems into 
  reusable components.   I am looking for information on any tools 
  that may be available to parce an existing segment of source code, 
  create functionality flows, data control, flows, and/or relationships 
  of the functions and data (if possibly the source code is object 
  related), etc.  The purpose of these tools is to perform reverse
  engineering on existing software systems where the documentation and
  any diagrams of the system is out-of-date, and possibly incorrect.  
  Then the segments may then be incorporated into an upgraded version, 
  or even new, software systems (re-use).

  --Thanks,
  --Debbie


-- 
|  Matt Baney         | Boeing Defense and Space Division    |
|  -----------------  |   Knowledge Systems Group            |
| "I can't tolerate   | UUCP:        ..!bcstec!ssc-vax!mattb |        
| intolerant people!" | Internet:   mattb@ssc-vax.boeing.com |
Newsgroups: comp.sw.components
From: ksand@apple.com (Kent Sandvik )
Subject: Re: Reuse Discussion Topics (Was: Reuse and Software Components)
Date: Sat, 7 Nov 1992 06:08:10 GMT
Organization: Apple
Followup-To: comp.sw.components

In article <1992Nov6.175825.2978@ampex.com>, leepeng@ampex.com (Peng Lee)
wrote:
> 	In software, I believe X-window protocol, MS-Window API, DOS
> 	interrupt functions are good examples of some very successful 
> 	reuseable software components.   If we agree on this, maybe 
> 	we should start analysis why these APIs succeed. 

Well, I have to advertise for the Macintosh Toolbox, appeared 1984
and still going strong! It's really staggering actually to think
that people are using the same window creation routines then and
also today. 

Note also that when we made sure that the toolbox was the *one and
only* way to access the system, we gained two things:
a) uniform application look&feel, maybe one of the prime reasons
for our fame in user friendly computing
b) control so developers would not do skanky things behind our backs
(even if they do it now and then), like re-defining the look&feel.

The main idea is to make the use of the toolbox API (or component)
so compelling, that it's not worth the time and energy to rewrite
the functionality. It is true that we failed with some of the 
features, and developers immediately rewrote these.

Another aspect is to look at very clean and elegant ways to override
built-in functionality. In the toolbox case we allow developer to patch
into the toolbox calls, either before the call (preferred) or 
after (should be avoided, because we also patch for fixing problems).

Anyway, we have a long history inside Apple concerning how to make
developers reuse functionality. The interesting observation was that
this strategy worked well, but you just need a very good and compelling
reason. The evolving time-to-market cycle that is slowly decreasing to
> 1 year is IMHO one of the reasons why component based development
work will gain followers.

Cheers,
Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.
Newsgroups: comp.sw.components
From: peter@ferranti.com (peter da silva)
Subject: Re: Reuse Discussion Topics (Was: Reuse and Software Components)
Organization: Xenix Support, FICC
Date: Wed, 11 Nov 1992 18:45:02 GMT

In article <1992Nov6.175825.2978@ampex.com> leepeng@ampex.com (Peng Lee) writes:
> 	In software, I believe X-window protocol, MS-Window API, DOS
> 	interrupt functions are good examples of some very successful 
> 	reuseable software components.   If we agree on this, maybe 
> 	we should start analysis why these APIs succeed. 

They were all agressively "marketed" by an organization that was trusted
by the target market, and they had initially very little competition. In
general competition at the interface level is almost impossible to sustain
in the long run, unless you can divide the market up into mutually disjoint
subsets.
-- 
Peter da Silva / 77487-5012 USA / +1 713 274 5180
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
From: emery@Dr_No.mitre.org (David Emery)
Subject: Re: Standard SW Interfaces (Was: Reuse Discussion Topics)
Organization: The Mitre Corp., Bedford, MA.
Date: Thu, 5 Nov 1992 21:54:54 GMT

I think another characteristic of a good interface is how easy it is
to express that interface in different programming languages.  This
is because the 'abstraction' is a good match for the problem, and
therefore it is easy to express the 'abstraction' in an arbitrary
programming language.  Some examples taken from my recent experience
with POSIX.1 and Ada:

	-  each API operation should perform only 1 abstract function
		-- counter-example:  Unix fcntl()

	-  there should be a consistent use of types and values
		-- counter-example:  C functions that return 
		   a pointer, but return "-1" for an error

	-  error handling models should localize the effects of
	   errors
		-- the shared variable 'errno' causes problems in 
		   multi-threaded programs (both C and Ada)

I tend to be of the "it's best expressed in Ada" religion, but I've
found that it *is* possible to express good interfaces in C, FORTRAN
and even BASIC.  One thing the current move towards language
independence might do is help develop interfaces that can support
different software paradigms.

Right now I'm working on a binding to another system (defined in terms
of its C language API), and this system is much less easy to express
in Ada than the POSIX API was.  

				dave
Newsgroups: comp.sw.components
From: larry@tsd.arlut.utexas.edu (Larry Maturo)
Subject: Re: Reuse Discussion Topics (Was: Reuse and Software Components)
Organization: Applied Research Labs, The University of Texas at Austin
Date: Mon, 9 Nov 1992 14:48:35 GMT

In article <1992Nov6.175825.2978@ampex.com> leepeng@ampex.com (Peng Lee) writes:
>In article <ksand-051192155051@wintermute.apple.com> ksand@apple.com (Kent Sandvik ) writes:
>>
>>Well, as a former HW designer, and current OO programmer I have to make
>>the statement that HW engineers don't subclass ICs, they define glue 
>>electronics for combining the ICs for more functionality. If we find
>
>Here's other POV.
>
>	I think 80486 is sub(super)class of 8086.  There are also a lot
>	ICs that use the 8086 as core and add other functionalities.
>
>	In software, I believe X-window protocol, MS-Window API, DOS
>	interrupt functions are good examples of some very successful 
>	reuseable software components.   If we agree on this, maybe 
>	we should start analysis why these APIs succeed. 
>
>
>

They succeed because they are well defined (well at least fairly well
documented).  Also, they succeed because they are thin.  If you understand the
context, such as DOS, each DOS interrupt function can be easily understood.
Learning the context is the trick.  I suppose this means that they also have an
undertandable context also.

+-----------------------------------+----------------------------------------+
|                                   |                                        |
| Larry Maturo                      | Opinions expressed herein must be      |
| Tactical Simulation Division      | yours, neither I nor my employer have  |
| Applied Research Laboratories     | any.                                   |
| University of Texas at Austin     |                                        |
| P.O. Box 8029                     +----------------------------------------+
| Austin, Texas 78713-8029          |                                        |
|                                   | When you're as great as I am it's hard |
| larry@titan.tsd.arlut.utexas.edu  | to be modest, but I succeed where      |
|                                   | others fail.                           |
+-----------------------------------+----------------------------------------+
From: kuhn@swe.ncsl.nist.gov (Rick Kuhn)
Newsgroups: comp.sw.components
Subject: Re: SE and EE components
Date: 12 Nov 92 14:37:01 GMT
X-Newsreader: TIN [version 1.1 PL6]

Jason M Baragry (baragry@latcs1.lat.OZ.AU) wrote:
: 

..


: 
: 
: 	Also, the notion of predefined and understood functionality of components
: seems to be an important factor in engineering design. Are there plans for 
: standardizing the functionality of software components rather than the interfaces
: to them? 
: 

Yes, notably the POSIX standards, which standardize both the interface
and software component functionality.  Unfortunately the word
"interface" has different meanings.  Most of the writing about open
system standards, including my own, says that the standards simply
define "an interface rather than an implementation".  But in this case,
"interface" means both the function call syntax and a complete
behavioral description.  POSIX standards are now required to define a
language independent specification (LIS), which defines standard
functionality.  The LIS is then mapped to a call syntax for particular
programming languages (actually just C in almost all cases).

Any component that provides the specified behavior through the
specified call syntax meets the requirements of the standard.  This use
of the term interface is contrasted with a standard "implementation",
which would mean standardizing on a particular collection of source or
executable programs.  It is unfortunate that the word "interface" has
become overloaded in this way.

--

Rick Kuhn                                   Telephone: +1 301 975 3337       
Natl Institute of Standards & Technology    Fax:       +1 301 590 0932      
Technology Bldg. B266                       Internet: kuhn@nist.gov
Gaithersburg, Md.  20899  USA                       DRKuhn@dockmaster.ncsc.mil
Newsgroups: comp.sw.components
From: ksand@apple.com (Kent Sandvik )
Newsgroups: comp.sw.components
Subject: Re: Reuse Discussion Topics (Was: Reuse and Software Components)
Date: 5 Nov 92 23:54:23 GMT
Followup-To: comp.sw.components
Organization: Apple

In article <jubo.720960526@rwthi3>, jubo@rwthi3.informatik.rwth-aachen.de >
Right, if you assume inheritance=subtyping!
> In "designing" this way you will loose control over your "architecture",
> since most of the dependencies you introduce are not explicitely visible in
> your interfaces. Ok, there are a lot of tools that help (e.g. browsers), but
> to find the places of interest (i.e. which methods are executed) is a mess.

Well, as a former HW designer, and current OO programmer I have to make
the statement that HW engineers don't subclass ICs, they define glue 
electronics for combining the ICs for more functionality. If we find
something resembling inheritance it would be programmatic IC circuits,
but in this state we are really dealing with changing the internal
states of the components concerning functionality, and the effect
is very much limited to the black box (IC) itself.

I do think that one of the main issues is that we need to look at
objects and classes from a more purist and simplified view, instead
of building complex inheritance trees and speak about reuse of code
using inheritance. Maybe we should limit out efforts into writing 
reusable class components, and compromise concerning defining 
huge inheritance tree systems. And let the functionality (complexity)
appear from interaction between simple but powerful entities. Mixin
classes, for instance.

In other words, I applaude the current thinking of looking at
smaller, self-contained modules as the possible mean of designing
systems.

Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.
Newsgroups: comp.sw.components
From: johnson@cs.uiuc.edu (Ralph Johnson)
Subject: Re: Reuse Discussion Topics (Was: Reuse and Software Components)
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Fri, 6 Nov 1992 13:19:32 GMT


The problem is not just due to the implementation language.  Just because
our systems are iplemented in C does not mean they will work together.
After all, it seems that 90% of languages today are ultimately implemented
in C!  There was a nice paper at OOPSLA '90 called "When Objects Collide"
that described problems with combining CLOS libraries.  It is necessary
for interfaces to be the same, and this has only a little to do with what
the underlying languages are.

The OMG effort is providing a set of standard interfaces that programs
can use to talk to each other.  It explictly permits programs to be written
in any language.  Writing everything in one language helps make for
common interfaces when the code is all running in the same address space,
but I'm not sure it helps that much when you are talking about distributed
applictions.

Ralph Johnson -- University of Illinois at Urbana-Champaign
Newsgroups: comp.sw.components
From: mehlich@informatik.uni-muenchen.de (Michael Mehlich)
Subject: Re: Reuse Discussion Topics (Was: Reuse and Software Components)
Organization: Leibniz-Rechenzentrum, Muenchen (Germany)
Date: Mon, 9 Nov 1992 08:26:50 GMT

In article <BxAq2J.4Kv@cs.uiuc.edu> johnson@cs.uiuc.edu (Ralph Johnson)  
writes:
> [...]
> There are at least two levels of meaning to an interface like "American
> house current".  One is the meaning known to an EE.  The other is the
> meaning known to my mother.  My mother doesn't know anything about volts
> or frequency.   She just knows that she can connect a plug into a
> compatible socket.  EVERYBODY in the country knows what "you have to  
plug
> an applicance in before it will work", that was my point.  You don't
> have to know ANYTHING about the details of the interface to use it.
> 
Your mother do not know that she will get electricity when connecting a  
plug into a compatible socket? I cannot believe that. I am sure she uses  
this important property when combing plugs and sockets.
> What this means in a software system is that we shouldn't have to know
> anything about the details of an interface except its name.  We should
> only have to know that we need a FOO, not what operations are legal on
> a FOO.
You relly need more details of an interfact than only its name. The  
properties of an interface are the most important issue whereas the  
concrete names do not play any formal role. It is not important if i call  
a function called OpenWindow or a function called CupOfTea. It is only  
important what happens when calling the function!
> 
> 
> Ralph Johnson -- University of Illinois at Urbana-Champaign
Newsgroups: comp.sw.components
From: leepeng@ampex.com (Peng Lee)
Subject: Re: Reuse Discussion Topics (Was: Reuse and Software Components)
Organization: Ampex Corporation, Redwood City CA
Date: Fri, 6 Nov 1992 17:58:25 GMT

In article <ksand-051192155051@wintermute.apple.com> ksand@apple.com (Kent Sandvik ) writes:
>
>Well, as a former HW designer, and current OO programmer I have to make
>the statement that HW engineers don't subclass ICs, they define glue 
>electronics for combining the ICs for more functionality. If we find

Here's other POV.

	I think 80486 is sub(super)class of 8086.  There are also a lot
	ICs that use the 8086 as core and add other functionalities.

	In software, I believe X-window protocol, MS-Window API, DOS
	interrupt functions are good examples of some very successful 
	reuseable software components.   If we agree on this, maybe 
	we should start analysis why these APIs succeed.
From: chandran@comp.lancs.ac.uk (M. Ramchandran)
Newsgroups: comp.sw.components
Subject: Reusable data structure components in C++
Date: 10 Nov 92 14:42:15 GMT
Distribution: comp.sw.components
Organization: Department of Computing at Lancaster University, UK.


Could anyone give me information on how to get reusable data structure components such as
	Lists
	Stack
	Tree
	and any other tools for user interface using sunwindows and ms-dos windows.

	Thank you,
	Dr Rama Chandran
	Liverpool John Moores Univbersity
Newsgroups: comp.sw.components
From: bradcox@sitevax.gmu.edu (Dr. Brad Cox)
Subject: Re: Reuse Discussion Topics (Was: Reuse and Software Components)
Organization: George Mason Pgm on Social and Organizational Learning
Date: Sat, 7 Nov 1992 17:57:09 GMT

In article <EMERY.92Nov2124532@Dr_No.mitre.org> emery@Dr_No.mitre.org (David Emery) writes:
>One of the important topics in reuse, which the POSIX people have
>started to address, is conformance testing.  The current POSIX
>approach of hand-generating test assertions, which are then
>hand-transformed into a test suite, is a good start.  However, there's
>entirely too much hand-xxx in the process.  

I added an entirely new chapter to the last edition of my book (OOP; An 
Evolutionary Approach; Cox and Novabilsky; Addison Wesley) describing why 
conformance testing is so crucial to moving ahead.

But having gone through the experience of actually doing this for a large
library (Stepstone's ICpak101), I'm now convinced that further investment
in this direction is (overstating drastically for emphasis) a thorough waste
of time.

Software development is expensive. Conformance testing *at least* doubles
the expense (even small/cheap test cases easily approximate the size of the
original code). But the revenue from tested components is no greater than
for untested ones.

Conclusion: nothing much will come of either reuse or testing until we've
solved the revenue collection issues for information age goods, particularly
small-granularity software components.

See my article in the October Dr. Dobbs Journal and June Journal of OOP for
a promising approach the Japanese are exploring.

-- 

    Brad Cox bradcox@sitevax.gmu.edu 703 993 1142 work 703 968 8229 home
    Program on Social and Organizational Learning; George Mason University
Newsgroups: comp.sw.components