HDTenEightyP/NetNews huggingface dataset:
From: fyoung@gssec.bt.co.uk (Fraser Young)
Newsgroups: comp.lang.eiffel
Subject: Re: Eiffel for 386BSD (and other freebie unix-a-likes)
Date: 8 Jan 93 13:15:49 GMT
Organization: BT Glasgow Systems and Software Engineering Centre, Scotland.

In article <1993Jan4.003214.19930@nrao.edu> cflatter@nrao.edu (Chris Flatters) writes:

|>    I'm just wondering if ISE or SIG Computing would be willing to produce a
|>    cut-price Eiffel package for 386BSD.  386BSD is Bill Jolitz' freely distributable
|>    implementation of BSD Unix for Intel 80386-based PC/AT clones (I suspect that
|>    porting ISE Eiffel 2.3 would require little more than a recompile).
|> 
|>    I think I would be willing to pay in the range of $300-$400 (or less, of
|>    course) for a full Eiffel development system on my home machine and I think
|>    that there is a chance that others would too.  Any takers?

I would like to know if there is a version available for Linux?
the cheaper the better |:|

BTW I'm v. sad to hear the GNU project is not looking at Eiffel.


--
.----------------------------------------------------------------------------.
| Fraser Young                                         fyoung@gssec.bt.co.uk |.
| BT Glasgow Engineering Centre                                              ||
`----------------------------------------------------------------------------'|
 `----------------------------------------------------------------------------'
Newsgroups: comp.lang.eiffel
From: mb108@cs.city.ac.uk (omo ADELAKUN T K)
Subject: Re random number generator: Thanx
Organization: City University, London
Date: Tue, 12 Jan 93 21:15:04 GMT

Hello,
Just a brief acknowledgement to all respondents to my earlier posting. For
the record, my solution was to craft my own random(), as it were, much along
the lines suggested by David Quarrie - I simply wrote an Eiffel wrapper
around C's drand48(). Finger trouble lost me all the other responses, so I
can't name all names: Thank you, all.

Sincere regards,
Toyin.
Newsgroups: comp.lang.eiffel
From: quarrie@cds001.cebaf.gov (David Quarrie)
Subject: Re: Need a random number generator
Reply-To: quarrie@cds001.cebaf.gov (David Quarrie)
Organization: CEBAF (Continuous Electron Beam Accelerator Facility)
Date: Thu, 7 Jan 1993 13:42:55 GMT

--
In article <1993Jan7.082202.7901@city.cs>, mb108@cs.city.ac.uk (omo
ADELAKUN T K) writes:
|>Hi folks,
|>I need a (pseudo-)random number generator for use in a tester program
|>for a queuing system. The Eiffel libraries don't appear to have such
|>a class - that is, according to grep. I can't see anything that looks
|>like a library of binaries against I can run nm. (I'm working
|>remotely
|>from the labs and have no access to manuals.) 
|>
|>If there _is_ one I'd like to know where to find it, and if there
|>isn't
|>one I'd appreciate pointers to public-domain sources (FTP?) of such
|>classes. (I'm being a pedant for software reuse... 8-)
|>
|>
|>Thanx++,			-- Oh, dear..! That syntax!
|>Toyin.
|>

I assume you want something that's uniform in the range 0.0-1.0. What I did
was the following:

Create a class (I called it MORE_MATH since it contained some functions
missing from the MATH) class (Eiffel 2.3.4 syntax):

class MORE_MATH export

	arctangent, exp, random

feature

	exp (x: REAL): REAL is
			-- Exponential function of x.
	    external
		c_exp:REAL language "C"
	    do			
		Result := c_exp (x)
	    end; -- exp

	arctangent (x: REAL): REAL is
			-- Arctangent of x.
	    external
		c_atan:REAL language "C"
	    do			
		Result := c_atan (x)
	    end; -- arctangent

	random: REAL is
			-- Random Number generator in range 0.0-1.0.
	    external
		c_rndm: REAL language "C"
	    do			
		Result := c_rndm
	    end; -- random

end -- class MORE_MATH

Alongside of this I created a more_math.c file containing:

#include <math.h>
#include <values.h>

float c_atan();
float c_exp(), c_rndm();

float c_atan(x)
float x;
{
	return ((float) atan ((double) x));
}

float c_rndm()
{
	float f1, f2;

	f1 = random();
	f2 = MAXINT;
	return (f1/f2);
}

float c_exp(x)
float x;
{
	return (exp(x));
}

Compile the more_math.c file and create an archive file from it and add that
to the EXTERNALS section of your SDF (.eiffel) file. I'm not sure whether
the C random() function is generic Unix, but I'm fairly sure that rand() is
so you could use that instead.

		David

-------------------------------------------------------------------------------
	David Quarrie					CEBAF MS 12H
							12000 Jefferson Ave
Internet: quarrie@cebaf.gov				Newport News VA 23606
DECnet  : cebaf::quarrie				Tel: (804) 249-7562
BITNET  : quarrie@cebaf					Fax: (804) 249-5800
From: gregor@oit.itd.umich.edu (Gregor Purdy)
Newsgroups: comp.lang.eiffel
Subject: Re: Eiffel for 386BSD
Date: 4 Jan 1993 16:11:26 GMT
Organization: University of Michigan
NNTP-Posting-Host: fredrik.oit.itd.umich.edu

In article <1993Jan4.134435.26594@netcom.com> rickc@netcom.com (Ricky A.  
Coldwell) writes:
> I believe there is a gnu project going to make a free eiffel.  There
> is also a lang called Sather avail that is a subset of eiffel 

Richard Stallman told me the GNU project will NOT be getting into Eiffel. Sad,  
but true.

--Gregor N. Purdy
Contemporary Design Studios
From: hajisan@rsk.ricoh.co.jp (Makoto Hajimesawa)
Newsgroups: comp.lang.eiffel
Subject: WANTED!!
Date: 12 Jan 93 00:59:50 GMT
Distribution: fj
Organization: Ricoh System Kaihastu Co.,LTD. , Tokyo , Japan

$@;O$a$^$7$F(J	$@;OBt(J@RSK   (hajimesawa@RSK) $@$G$9!#(J

$@AaB.$G$9$,!"$"$kK\$rFI$s$G$$$^$7$F(JEiffel$@$K6=L#$r;}$A$^$7$?!#(J
$@$=$3$GF~<j$r$7$?$$$N$G$9$,!"K\$NCf$K$OF~<jJ}K!$K$D$$$F(J
$@=q$+$l$F$$$^$;$s!#(J

$@$I$J$?$+F~<jJ}K!$r$4B8CN$NJ}$,$$$^$7$?$i!"65$($F2<$5$$!#(J

$@$h$m$7$/$*4j$$$7$^$9!#(J_o_


-- 
###################################################################
$B%j%3!<%7%9%F%`3+H/(B($B3t(B)$BBh#23+H/<<(B $B#2#0#1#G(B
Phone :03-3238-0511 Fax:03-3264-0507
E-Mail:hajisan@rsk.ricoh.co.jp          $B;OBt(B  $B?.(B(Hajimesawa Makoto)
Newsgroups: comp.lang.eiffel
From: rickc@netcom.com (Ricky A. Coldwell)
Subject: Re: Eiffel for 386BSD
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Mon, 4 Jan 1993 13:44:35 GMT

I believe there is a gnu project going to make a free eiffel.  There
is also a lang called Sather avail that is a subset of eiffel 

Sather is located at  icsi-ftp.berkeley.edu

rick


Newsgroups: comp.lang.eiffel
From: mb108@cs.city.ac.uk (omo ADELAKUN T K)
Subject: Need a random number generator
Organization: City University, London
Date: Thu, 7 Jan 93 08:22:02 GMT

Hi folks,
I need a (pseudo-)random number generator for use in a tester program
for a queuing system. The Eiffel libraries don't appear to have such
a class - that is, according to grep. I can't see anything that looks
like a library of binaries against I can run nm. (I'm working remotely
from the labs and have no access to manuals.) 

If there _is_ one I'd like to know where to find it, and if there isn't
one I'd appreciate pointers to public-domain sources (FTP?) of such
classes. (I'm being a pedant for software reuse... 8-)


Thanx++,			-- Oh, dear..! That syntax!
Toyin.
Newsgroups: comp.lang.eiffel,comp.lang.c++,comp.lang.smalltalk,comp.object,comp.lang.objective-c
From: mwette@csi.jpl.nasa.gov (Matt Wette)
Subject: how to handle binary operators
Originator: mwette@mr-ed
Organization: Jet Propulsion Laboratory
Date: Tue, 12 Jan 1993 16:19:40 GMT


I haven't programmed in Eiffel, but have read the OOSC book.  One
thing I haven't been able to figure out is how to construct overloaded
operators for mixed classes.  For example, say I want to construct a
class REGEMAT for real general matrices (real coefficients, no special
structure).  Then I can define (don't have my book here so syntax may
be off a bit)

  feature 
    "*"(b: REGEMAT):REGEMAT is ... -- code for REGEMAT*REGEMAT
    "*"(b: REAL): REGEMAT is ...   -- code for REGEMAT*REAL
  
But how do I handle the case for REAL*REGEMAT where REAL is a
previously defined class?  It seems this sort of thing is not possible
in Eiffel, or is it? 

Matt
-- 
mwette@csi.jpl.nasa.gov
From: gregor@oit.itd.umich.edu (Gregor Purdy)
Newsgroups: comp.lang.eiffel
Subject: Papers About Eiffel
Date: 5 Jan 1993 20:07:24 GMT
Organization: University of Michigan
NNTP-Posting-Host: fredrik.oit.itd.umich.edu

Friends--

Is there an archive of papers in electronic form about Eiffel? Where is it?
Is there a list of papers/publications about Eiffel? Where is it?

I want to write a paper for TOOLS, but want to be sure I have read and  
considered any related work.

Email responses preferred. Any pointers appreciated.

--Gregor N. Purdy
Contemporary Design Studios
gregor@umich.edu
Newsgroups: comp.lang.eiffel
From: cflatter@nrao.edu (Chris Flatters)
Subject: Re: Eiffel for 386BSD (and other freebie un
Reply-To: cflatter@nrao.edu
Organization: NRAO
Date: Sun, 10 Jan 93 22:08:39 GMT

In article 93Jan8141550@hendrix.gssec.bt.co.uk, fyoung@gssec.bt.co.uk (Fraser Young) writes:
>In article <1993Jan4.003214.19930@nrao.edu> cflatter@nrao.edu (Chris Flatters) writes:
>
>|>    I'm just wondering if ISE or SIG Computing would be willing to produce a
>|>    cut-price Eiffel package for 386BSD.  386BSD is Bill Jolitz' freely distributable
>|>    implementation of BSD Unix for Intel 80386-based PC/AT clones (I suspect that
>|>    porting ISE Eiffel 2.3 would require little more than a recompile).
>|> 
>|>    I think I would be willing to pay in the range of $300-$400 (or less, of
>|>    course) for a full Eiffel development system on my home machine and I think
>|>    that there is a chance that others would too.  Any takers?
>
>I would like to know if there is a version available for Linux?
>the cheaper the better |:|
>
>BTW I'm v. sad to hear the GNU project is not looking at Eiffel.

This actually means that no one has volunteered to write a Eiffel compiler
and release it under the GPL (well, actually, 2 or 3 people have volunteered
but they all seem to have fallen by the wayside for one reason or another).

	Chris Flatters
	cflatter@nrao.edu


Newsgroups: comp.lang.eiffel
From: ctaylor@cs.uiuc.edu (Conrad Taylor)
Subject: Help with Simula program...???
Organization: University of Illinois at Urbana-Champaign
Date: Mon, 11 Jan 1993 19:49:43 GMT

         Yes, I was wondering if anyone would be so kind to assist me in the
conversion of a very small program to Eiffel or Pascal or C?  I don't have
any backround in Simula and there's not a Simula system on the machines that
I'm working.  Thanks in advance to all that reply to this post.

-Conrad

ps:  My e-mail is ctaylor@silver.lcs.mit.edu or
     taylor1@wse.eecs.uic.edu.
From: Ari.Huttunen@hut.fi (Ari Huttunen)
Newsgroups: comp.lang.eiffel
Subject: Re: Eiffel for 386BSD
Date: 5 Jan 93 00:54:04 GMT
	<1993Jan4.134435.26594@netcom.com>
Distribution: inet
Organization: Helsinki University of Technology, Finland
NNTP-Posting-Host: cardhu.cs.hut.fi
In-reply-to: rickc@netcom.com's message of Mon, 4 Jan 1993 13:44:35 GMT

In article <1993Jan4.134435.26594@netcom.com> rickc@netcom.com (Ricky A. Coldwell) writes:

! I believe there is a gnu project going to make a free eiffel.  There
! is also a lang called Sather avail that is a subset of eiffel 

Sather is not a subset of Eiffel. I don't know what Eiffel 3.0
added to the earlier Eiffel, but I'm quite sure it didn't add
iterators and bound routines.

...............................................................................
Ari Huttunen		Whenever you find that you are on the side of 
			  the majority, it is time to reform.
Newsgroups: comp.lang.forth
From: ahenden@magnus.acs.ohio-state.edu (Arne A Henden)
Subject: Re: uniforth pro
Organization: The Ohio State University
Distribution: comp
Date: Tue, 5 Jan 1993 15:24:50 GMT

"elliott chapin" <elliott.chapin@canrem.com> writes:
>
>Would you tell me a little about the pro package (especially the
>libraries).
>
>It has been good to hear recent Uniforth news.
>
>Elliott Chapin

Thanks for the Uniforth comment.  I tend to listen rather than
expound so you won't see many postings from me.
  Pro package (special offer until the current supply of manuals
runs out = $40 postpaid) has kernels for integer, software floating
point, and 80x87 support.  Libraries include:  microsoft mouse,
crude windows, menu generation, decompiler, games, multitasking,
sorting, strings, crude spreadsheet, 2D graphics, hardware support
(full BIOS, RTC, parallel port, etc.), utilities for data storage
in: lower 1Mb; Extended (AT BIOS style); Extended (386 linear address
style); Expanded memory.  Probably a few I've forgotten as the
system has been stable for a number of years.
  Unified Software Systems
  1288 Nantucket Ave.
  Columbus, OH 43235
  (614) 459-7735
Arne
Newsgroups: comp.lang.forth
From: uucp@memco.fidonet.org (Bruce Casner)
Newsgroups: comp.lang.forth
Subject: Re: Documenting
Date: Wed, 06 Jan 93 09:05:51 CST
Organization: MILLER Electric, Appleton, WI

In a message of <Jan 01 -7:00>, Nick Janow (Nick_Janow@mindlink.bc.ca ) writes: 

 >Some potential Forth'ers might be turned off by seeing heated "screens vs
 >files" composing half the net traffic.  :(

As one of those potential Forthers, I know I am.  :( 

--  
Bruce Casner - via FidoNet node 1:139/610
UUCP: spool.mu.edu!cserver!edsi!memco!uucp
INTERNET: uucp@memco.fidonet.org
From: landman@hal.COM (Howard Landman)
Newsgroups: comp.lang.forth
Subject: Re: Forth Standard Debate
Date: 8 Jan 93 20:16:57 GMT
Organization: HaL Computer Systems, Inc.
NNTP-Posting-Host: bang.hal.com

In article <1993Jan4.234621.12186@news.uakron.edu> r3btg@vax1.cc.uakron.edu (Ben T Galehouse) writes:
>on 16-bit machines and on 32-bit machines (size of stack? if the stack
>is 32 bits, how to work with 16-bit arrays?).  If somebody wants to
>devise a graphic standard (variable names that contain the screen size?)
>that is also fine.  Not all 32-bit machines have graphic interfaces.
>Not all people want floating point support.  The standard should be
>modular.  There should be a 16-bit standard.  There should be a 32-bit
>standard.  There should be a floating point standard.

I find it curious that "16 or 32" bits is still such an item of discussion
here.  In most other languages, the question is beginning to be "what to
do about 64 bit machines"?  In this sense, Forth is mired 10 to 15 years
in the past, which is when most hardware, and other languages, made the
16->32 transition (or in some cases, the 24->32 transition).

Currently, applications are growing by about 1 bit of address space every
3 years.  32 bits is already too small for large commercial apps, not to
mention large scientific apps.  16 bits is a joke, except in the extreme
low-end like video games and the cheaper PCs.  (Even there, it leads to
abominations like segments.  Programs deserve uniform address spaces.
Segments are for worms.)  The transition from 32->64 bits can be expected
to provide adequate address space for most of the 21st century.  Then we'll
probably have to go to 128 (sometime between 2070 and 2120 most likely).
The starship Enterprise's computers probably use a 256-bit word. :-)

This long period of word-size stability will be an entirely new thing in
the computer industry.  We've never had that before.  Maybe we can finally
get our act together and write software that can be useful for decades
without vast amounts of maintenance.  Or maybe not; we (as a profession)
have not demonstrated any such ability to date.

There already ARE graphics standards.  The nice thing about standards is that
you have so many to choose from. :-)  Postscript is Forth-like, so perhaps
NeWS or NeXTStep would be easy to interface.  But they don't run on every
architecture, or even most, and probably won't for a long time.

For floating point, could there POSSIBLY be any reason not to support the
IEEE floating point standard (sometimes known as "The Wrath of Kahan")?
Not only has it been carefully designed from a numerical analysis viewpoint
(which 99% of Forth (or any other language) programmers would be incapable
of doing), an increasing number of machines have it built into the hardware.
This choice would still leave some issues unresolved, but would go a long
way toward getting a reliable, portable, robust standard.

	Howard A. Landman
Newsgroups: comp.lang.forth
From: mikeh@starnine.com (Mike Haas)
Subject: Re: Forth for Amiga
Date: Tue, 5 Jan 1993 00:49:23 GMT
Organization: StarNine Technologies, Inc.

In article <4227.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes:
>Category 7,  Topic 3
>Message 80        Fri Jan 01, 1993
>G.CHIU2                      at 13:45 EST
> 
>I would like to open several windows, and have a task look after each one.  Is
>it possible to do this in JForth V2?  I have seen  'C' code examples that use
>createTask(), but I don't think that this has been implemented yet in JForth (
>it is part of Amiga.lib).

You're right.  I'll try to post the source for CreateTask() soon.

BTW, You should contact Delta Research for the upgrade to JForth 3.1.
Mucho added.  If anyone's interested, letme know.
Newsgroups: comp.lang.forth
From: mikeh@starnine.com (Mike Haas)
Subject: Re: Documenting
Date: Wed, 13 Jan 1993 04:26:49 GMT
Organization: StarNine Technologies, Inc.

In article <19368@mindlink.bc.ca> Nick_Janow@mindlink.bc.ca (Nick Janow) writes:
>mikeh@starnine.com (Mike Haas) writes:
>
>>+ Some potential Forth'ers might be turned off by seeing heated "screens vs
>>+ files" composing half the net traffic.  :(
>>
>> Ah... that must be the reason Forth is not very popular...
>>
>> because we discuss it's rough edges on the net.
>>
>> Sorry.  So what would you like us to talk about, Nick?
>
>Hey, I'm just voicing the complaints I've seen from lots of people.  They're
>really tired of the endless "screens vs files" arguing.
>
>It's an argument between two factions of established Forth'ers.  I can't see
>it being helpful in attracting newcomers.
>
>Maybe it's something that should be left to e-mail?

And maybe it's not.

From what I see, the discussion has generated a bit of discussion, and
that's what this damn newsgroup is for.

Use your kill file, ignore these messages, join in... whatever.

But don't suggest that any ongoing discussion that is directly related
to Forth that others are interested and taking part in... don't suggest
that it has any less place here than any other.

Besides... I repeat... what the hell do you want to discuss here?

From what I see, this group tends to stay in the realm of bashing ansi
and how to add features to e-forth (what kind of forth has no DOES>???).

Maybe a discussion of screens vs. files will attract engineers if
they think... hey maybe this language is coming out of the dark ages?
I know the concept intrigues me intensely.

Maybe we shouldn't be wasting time suggesting that certain discussions
belong here and others don't.
From: Interface!b0b@under.mind.ORG
Newsgroups: comp.lang.forth
Subject: ForthNet Information
Date: 09 Jan 93 14:49:00 -0500
Organization: Interface BBS, 707-544-9661
X-newsreader: Fortress v1f-75

    Some participants in comp.lang.forth don't seem to be aware of 
the limits of the Forthnet virtual network.  Messages from this 
newsgroup are cross-posted to the Forth RoundTable on GEnie, and 
from there they are picked up by several other smaller BBS networks.
 
    Without manual intervention, messages longer than 100 lines will 
be truncated by the network process.  Also, messages wider than 78 
characters cause weird formatting problems on the BBS side of 
things. 
   
    The ideal message for ForthNet has a body of less than 90 lines, 
and a width of less than 76 characters.  If you adhere to these 
parameters (using multiple consecutive messages where excess length 
is required), your message will be formatted correctly and appear 
exactly as you wrote it on all ForthNet systems. 
   
    We now return you to your regular argu.. er, discussions. 
   
 --- 
    b0b@interface.via.mind.ORG          Interface BBS: 707-544-9661 
   "Forth is beautiful.  Forth is pure." 

--
via Fortress Gateway at uumind.mind.ORG
Newsgroups: comp.lang.forth
From: dwp+@cs.cmu.edu (Doug Philips)
Subject: Re: Documenting
Summary: something salient, shortly stated, sadly seldom satoric
Organization: EIEI-U
Date: Fri, 8 Jan 1993 22:28:05 GMT

In article <peterd.726243633@pjd.dev.cdx.mot.com> peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
+dwp+@cs.cmu.edu (Doug Philips) writes:
+>Whoa a minute here.  Most OS's (those that have EOL characters), also have
+>file systems with allocations in units of sectors (or multiple-sector
+>unitss), and bunches of tiny files will waste a lot of space.  If this is
+>really an issue, then let's be clear about it.
+
+On most UNIX machines, the smallest fragment that can be allocated is
+between 1/2K and 2K. (1/8 to 1/4 of a block, with block size 4K or 8K)
+In addition, some Unix file systems can store tiny files (e.g. <60
+bytes) in the directory entry - i.e. for free. [see the recent
+discussion in comp.os.linux.]
+
+Screens are *not* more efficient with regards to storage than file
+systems. 

One of the assumptions made by various participants in this discussion
is the size of the "code" to be stored (either in blocks or files).  In
addition, I was not comparing blocks in a Forth system to any
particular implementation of a Unix file system.  Without getting down to
nitty gritties, the claim that screens are/aren't more efficient is
vacuous at best and disingenuous at worst.  The original claim, that lots
of tiny files is more efficient than blocks in more likely than not to be
false.  Perhaps on an experimental Linux system it would be true, but not
over most of the DOS/Amiga/Unix implementations out there.  

-Dou:
-- 
---
email to: dwp@willett.pgh.pa.us is preferred to From: address but both work.
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Forth and Novell Netware, etc.
Date: 6 Jan 93 12:20:58 GMT
Organization: EIEI-U

Category 2,  Topic 27
Message 6         Tue Jan 05, 1993
ELLIOTT.C                    at 14:41 EST
 
 -----via CRS Premium Bulletin Board -
  USR Dual Standard 16.8K  (416) 629-7000

 Date: 01-04-93 (00:24)
   To: ALL
 From: RAY DUNCAN
 Subj: FORTH DEVELOPERS GUIDE

   TO: MARK VENDETTA

   >I am currently looking to develop a 32-bit DPMI-based Forth

 If your time is worth ANYTHING, you might want to consider buying
 a proven commercial product instead, then adapt it (if necessary)
 to meet your needs.  Implementing and optimizing a full Forth
 development environment for the 386/486 32-bit protected mode
 along with all the necessary tools & utilities is not the work of
 a few evenings.

 LMI has been selling a 32-bit protected mode 80386 Forth since
 1987. The current version is compatible with XMS, VCPI, and DPMI
 and comes with a 500 page language reference manual and a 500
 page tutorial.  Full source code is available.  You can get more
 information by calling 310-306-3530.

 FORTH Inc. also has a 32-bit DPMI-compatible 80386 FORTH and of
 course source code and extensive documentation is available. ---
  * The GrapeVine/Ferret Face BBS * NLR,ARK * 501-753-8121 DS *
  * PostLink(tm) v1.04  GRAPEVINE (#318) : RelayNet(tm) Hub



-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us