HDTenEightyP/NetNews huggingface dataset:
From: deutsch@SMLI.Eng.Sun.COM (L. Peter Deutsch)
Newsgroups: comp.lang.smalltalk,comp.lang.c++
Subject: Re: Classic Smalltalk bugs
Date: 21 Jul 92 20:33:19 GMT
	<STEINMAN.92Jul18192431@hawk.is.morgan.com> <knight.711600639@cunews>
	<k4dmhdd.nagle@netcom.com> <70298@apple.Apple.COM>
Distribution: comp
Organization: Sun Microsystems Laboratories Inc.
NNTP-Posting-Host: luxembourg.eng.sun.com
In-reply-to: mlanett@Apple.COM's message of 21 Jul 92 20:49:03 GMT

Mark Lanett writes:

> MacApp 3.0 iterators are entirely capable of handling
> insertions/deletions in their list, with any number of iterators on them.

1. In MacApp, do you have to finalize iterators, i.e., take specific action
to say that you are through with an iteration?  If you do, this is a
significant price to pay in terms of the programmer "having to be careful"
(my #1 pet peeve for how not to design systems).

2. Do these iterators take a point of view about whether or not they "see"
elements inserted or deleted during iteration?  If the only structure
MacApp provides is an ordered list, it isn't too hard to specify this based
on the most obvious implementation, but Smalltalk and C++ (and other richer
class libraries) provide structures like hash tables where it's awkward to
provide guarantees.  In this respect, Xanadu's in-house C++ class libraries
take what I consider to be the best position, namely, that at the time you
start iterating over a collection, the iterator acquires a (virtual) copy,
unaffected by any insertions or deletions made during the iteration.
From: dugerdil@uni2a.unige.ch
Newsgroups: comp.lang.smalltalk
Date: 18 Jul 92 09:49 MDT
Subject: Re: ESUG email address
Nf-ID: #N:1992Jul17.121000.1479@uni2a.unig:1560818049:001:298
Nf-From: uni2a.unige.ch!dugerdil    Jul 18 09:49:00 1992


In article <2836@media03.UUCP>, pkr@media03.UUCP (Peter Kriens) writes:
> I need an email address for the European Smalltalk User Group.
> Especially from Isabelle Borne.
> Thanks
> Peter Kriens

Try to contact Annick Fron at: fron@mirsa.inria.fr
or Jean Bezivin at: bezivin@geocub.uucp

Philippe
From: ken@gunshy.ocunix.on.ca
Newsgroups: comp.lang.smalltalk
Date: 17 Jul 92 23:12 MDT
Subject: RE: ENVY for SmallTalk-80
Nf-ID: #N:gunshy.ocunix.on.ca:1703255550:001:707
Nf-From: gunshy.ocunix.on.ca!ken    Jul 17 23:12:00 1992



In article <1992Jul10.185240.17224@prodigy.bc.ca>
Adi Sumantri writes:

>
> We just bought an ENVY software for our system, we are developing a utility
> software in smalltalk-80. Has somebody know about this ENVY product? We like to
> hear how stable this application. Please send me email if somebody know more
> detail for this product.
>

A little more specific and I'll forward your request to the correct people.  Which
application do you mean, Envy, ST-80, your application?

--
NewsBrowser (v0.1)
Ken Walker, Software Engineer, Object Technology Int'l Inc.
EMAIL: ken@gunshy.ocunix.on.ca | ken@oti.on.ca
Phone: (613) 820-1200 Fax: (613) 820-1202
[self contents apply: Disclaimers standard] fork
From: mario@cs.man.ac.uk (Mario Wolczko)
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bugs
Date: 24 Jul 92 18:13:07 GMT
Organization: Dept Computer Science,University of Manchester,U.K.

In article <knight.711600639@cunews>, knight@mrco.carleton.ca (Alan Knight) writes:
> With collections, there is also the classic error of iterating over a
> collection which the iteration loop somehow modifies. In some cases
> the modification can be quite indirect and the effects difficult to
> locate.

I used to break into a cold sweat just thinking of how many hours I
spent tracking down this type of bug.  But no longer!

I now have a solution that catches these problems the instant they
occur (at some performance penalty of course):

I wrap the core of each iteration method within a block, and pass as
it as an arg to the lockIterator: method.  This enters that collection
into a set of collections being iterated over (IteratedCollections),
executes the block, then removes the collection from the set.
Collections are usually (only?) modified using at:put: or
basicAt:put:, so these are overriden to check that the collection is
not in IteratedCollections.  If it is, an error is signalled.  This
has saved me a lot of debugging effort on numerous occasions.

I've cleaned it up and put it into a goodie, Iterator-check, which
should be available on the Manchester and Illinois servers by the time
you read this.

Mario Wolczko

   ______      Dept. of Computer Science   Internet:      mario@cs.man.ac.uk
 /~      ~\    The University              uucp:    mcsun!uknet!man.cs!mario
(    __    )   Manchester M13 9PL          JANET:         mario@uk.ac.man.cs
 `-':  :`-'    U.K.                        Tel: +44-61-275 6146  (FAX: 6236)
____;  ;_____________the mushroom project___________________________________
From: ssriniva@Teknowledge.COM (Shankar Srinivasan)
Newsgroups: comp.lang.smalltalk
Subject: Record-and-playback
Keywords: utility wanted, ParcPlace Smalltalk
Date: 29 Jul 92 17:24:47 GMT
Organization: Cimflex Teknowledge Corporation, Knowledge Systems Division

I'm looking for an ST80 (ParcPlace) utility that can 
record and play back sequences of keystrokes and mouse 
clicks. I'd like to use it to develop self-running demos
and regression tests. Anybody know of such a beast?

Any pointers to relevant archives would be welcome. Public
domain would be nice, but I wouldn't be averse to paying for 
this, if needed.
Thanks - Shankar
--------------------------------------------------------------
Shankar Srinivasan			shankar@Teknowledge.Com
Cimflex Teknowledge Corp.		(415) 424-0500

Newsgroups: comp.lang.smalltalk
From: brent@uwovax.uwo.ca (Brent Sterner)
Subject: Dictionary usage: beginner's questions
Organization: University of Western Ont, London
Date: Wed, 29 Jul 1992 20:22:05 GMT

   I've just got back to st after a 3 month hiatus.  (I wasn't very far
   in before I left. :-)  I'm exploring a dictionary of dictionaries.

   Q1:	Is there any way to "remove" a key (and it's association) from
	a dictionary?  (I had a quick look at declare:from: (the closest
	I could locate to this concept.  Was/am I close?
   Q2:	Has anyone done anything with nested dictionaries in general?
	Perhaps you could save me some effort.

   Thanks for your help.  b.
--
Brent Sterner                       Manager, Academic Technical Support
Fast:       <BRENT@uwo.ca>          <129.100.2.13>
Telephone:  (519)661-2151 x 6036    Fax:   (519)661-3486
Slow:  Computing & Communications Services, Natural Sciences Building
       The University of Western Ontario, London, Ontario, Canada  N6A 5B7
Newsgroups: comp.lang.smalltalk
From: steinman@is.morgan.com (Jan Steinman)
Subject: Re: Classic Smalltalk bugs (explicit precedence is good!)
Organization: Morgan Stanley & Company
Date: Mon, 27 Jul 1992 13:56:22 GMT

In article <1992Jul24.204716@cs.man.ac.uk> mario@cs.man.ac.uk (Mario Wolczko) writes:
   ...
   Yup, (lack of) precedence strikes again!

Hey, I kinda like explicit precedence. By taking a careful look at the code
only, I can always figure out *exactly* what it will do.

Even after several years of C hacking, I'd be looking up which happens first
for some oddball case. I think most C programmers just avoid using things that
might cause precedence problems, or they simply parenthesize the hell out of
them. It isn't that I couldn't memorize that famous page (42?) in K&R if I put
my mind to it, it's that I have more important things to do with my wetware.

I've noticed many ex-C Smalltalkers also seem to suffer from "Excessive
Parenthesitis", a debilitating disease that makes Smalltalk code less readable
and more difficult to maintain.
--
: : Jan Steinman	   steinman@is.morgan.com		 Bytesmiths : :
: : 2002 Parkside Court				   West Linn, OR 97068-2767 : :
: : 503/657-7703					       212/956-8722 : :
From: hasko@heeg.de (Hasko Heinecke)
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bugs
Date: 30 Jul 92 10:08:30 GMT
Distribution: comp
Organization: Georg Heeg Objektorientierte Systeme, Dortmund, FRG

In article <DEUTSCH.92Jul28161656@luxembourg.SMLI.Eng.Sun.COM> deutsch@SMLI.Eng.Sun.COM (L. Peter Deutsch) writes:
>Having done a very large amount of programming in Smalltalk and in C, I
>think my personal preference would be to *require* parentheses in any
>expression where two infix operators came into contact.  I would make one
>exception: if the operators were the same, I would use left-to-right
>evaluation.  And I could be talked into making a special case for
>considering + and -, and * and /, the "same".  But that's where I would
>stop.  Even after writing well over 10,000 lines of C code, I still can't
>remember the relative precedences of +, &, and <<, so I always parenthesize
>them.

Well, I don't know what people have against operator precedence. I know the
relative precedenes of +, -, *, and /, and the relative precedences of &, !,
and ~. If you have any examples where you want to mix these two groups of
operators, please tell me. And I don't mean examples like: "My compiler is too
dumb to substitute x := x / 4 with x asl 2 or whatever, so I have to do it
myself."

Personally, I think the missing operator precedence is a lack in ST-80, but
then I think elegance and homogenous behavior are good enough reasons to drop
it.

Hasko

-- 
+-------------------------------------------------------+
| Hasko Heinecke @ Georg Heeg Objektorientierte Systeme |
| I _never_ mean what I say - and nobody else does...   |
+-------------------------------------------------------+
From: juha.veijalainen@compart.fi (Juha Veijalainen) 
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bug
Date: 22 Jul 92 02:22:00 GMT
Distribution: world
Organization: ComPart BBS, Helsinki-Finland, +358 0 506 3329 (14 lines V.32bis)
Reply-To: juha.veijalainen@compart.fi (Juha Veijalainen) 

MS>I have found the following problem a number of times:
MS>class A
MS>    new
MS>       ^super new initialize
MS>A subclass: #B
MS>    new
MS>       ^super new initialize

Just a note - whatever the Smalltalk bug, they have been easier to solve 
than the ones I've got in other (3 GL) languages.  I'd even go as far as 
admit that I've been using (Digitalk's) Smalltalk for two years without 
knowing some very basic things about the environment - and - everything I 
program usually works as I intend it to work!  Try to replicate that in C 
or C++ (or whatever!)

I mean that I keep learning new surprising things about Smalltalk all the 
time - but these things I have not known have not kept me from writing 
very professional, working(!), applications.


---
 . WinQwk 2.0 #152 . Mielipiteet omiani/Opinions personal/Facts suspect
From: peterg@netcom.com (Peter Goodall)
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bugs
Date: 28 Jul 92 22:20:18 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

terry@zoe.network23.com (Terry) writes:

>From article <1992Jul24.204716@cs.man.ac.uk>, by mario@cs.man.ac.uk (Mario Wolczko):
>> CompiledCode>methodSizeAvoiding: in 4.0):
>> 	space := space + lit class instSize * 4.
>> Spot anything fishy?
>> 
>> How about if I rewrite it to be correct? 
>> 	space := space + (lit class instSize * 4).
>> 
>> Yup, (lack of) precedence strikes again!
>> 
>> Mario Wolczko

>Here is another classical precedence bug

>point := x @ height * n.

>The correct expression would be:

>point := x @ (height * n).

>Terry
>-- 
>terry@zoe.network23.com
>{rayssd,xanth,mirror,att}!galaxia!zoe!terry

'scuse me, but with left-to-right evaluation, it is very easy to accurately
determine what is happening. It's much better than having to remember lots 
of precedence rules. 

Occam, which was designed to be provable, also has left-right evaluation only.

Peter Goodall
peterg@netcom.com
From: prasad@cis.ksu.edu (Baba C Prasad)
Newsgroups: comp.lang.smalltalk
Subject: Asynchronous socket-based I/O in SmallTalk
Date: 24 Jul 1992 18:32:13 GMT
Organization: Kansas State University, Dept. of Computing and Information Sciences
Distribution: world
NNTP-Posting-Host: altair.cis.ksu.edu

Hi:

  I need some help with socket-based communication in Unix
using st80. I run st80 v 4.1 on a Sun4 (Sparc 1+) machine, 
and I've been trying to get SmallTalk to communicate with
the outside world using unix sockets. Things work fine
as far as synchronous messaging goes (i.e. SmallTalk waits
on a socket for the external process to write the message)
both with UDP and TCP communication. I have even been able
to write C-routines for synchronous communication, and link 
them into SmallTalk methods (I have ParcPlace's CPOK library
which facilitates integration of C-routines into SmallTalk).

  However,as you'll quickly realize, this is not enough. 
It is more practical for SmallTalk to set up an asynchronous 
socket--when the outside world writes a message to this
socket, ST grabs it and processes it. But until then (and 
after that also) ST should be doing other work. Ideally I'm 
thinking in terms of a signal that raises an
exception upon receipt of a message on a socket. The
signal handler that is associated with the signal gets
the message, and processes it (say updates a display 
field). But the question is : How do I create this signal
in the first place, and second, how can I use it in 
socket-based I/O? (Incidentally, for socket I/O, I am
using the UnixSocketAccessor Class).

  Unfortunately, I have not had the same success with
writing either SmallTalk methods or integrating C-programs
for this asynchronous UDP or TCP communication as I have had
with synchronous messaging. 

  I'd be glad if somebody could provide pointers/suggestions. 
I'd appreciate it even more if I could get some sample code.
While general advice is very welcome, I'd also like specific
information on how to create a new Signal, and how I would
use it in asynchronous communication. Thanks in advance for
any help. I'll gladly post a summary on the net.

--baba prasad

Newsgroups: comp.lang.smalltalk
From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Subject: Re: Not again static type checking (was: Classic Smalltalk bugs)
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Mon, 27 Jul 1992 05:18:08 GMT

hasko@heeg.de (Hasko Heinecke) writes:

>In article <1992Jul18.113941.30839@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
>>This is a bug that would be caught by static type-checking.

>Would it? What about

>| c x y |
>c := OrderedCollection new: 10.
>x := OrderedCollection new: 10.
>y := 17.
>(c add: x) add: y.
>c add: x; add: y.

The type of y is <SmallInteger>.
The type of x is probably <OrderedCollection of: SmallInteger>.  It could
also be <OrderedCollection of: T> for some type T that includes <SmallInteger>.
The type of c probably was supposed to be <OrderedCollection of:
(OrderedCollection of: SmallInteger)>, but needs to be
<OrderedCollection of: (SmallInteger + (OrderedCollection of: SmallInteger))>
in order to type-check.

A type-inference system would find the more complicated type and would
not say that anything was wrong with this code.  However, if later code
used c and assumed that it contained only OrderedCollections (e.g. if there 
were code of the form (c at: 1) at: 1) then it would detect the type-error.

Ralph Johnson -- University of Illinois at Urbana-Champaign
From: msmith@volcano.ma30.bull.com (Mike Smith)
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bugs
Date: 21 Jul 92 12:23:06 GMT
Article-I.D.: volcano.MSMITH.92Jul21082306
	<MSMITH.92Jul20115326@volcano.ma30.bull.com>
	<1992Jul20.202018.17314@den.mmc.com>
Organization: Bull HN, Worldwide Information Systems, Billerica, Mass., USA


In article <1992Jul20.202018.17314@den.mmc.com> randy@tigercat.den.mmc.com (Randy Stafford) writes:
Path: mips2!news.bbn.com!olivea!uunet!darwin.sura.net!mips!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!news.den.mmc.com!randy
   From: randy@tigercat.den.mmc.com (Randy Stafford)
   Newsgroups: comp.lang.smalltalk
   Date: 20 Jul 92 20:20:18 GMT
   References: <1992Jul18.113941.30839@m.cs.uiuc.edu> <MSMITH.92Jul20115326@volcano.ma30.bull.com>
   Sender: randy@tigercat (Randy Stafford)
   Organization: Martin Marietta Astronautics Group
   Lines: 42
   Nntp-Posting-Host: tigercat.den.mmc.com

   In article <MSMITH.92Jul20115326@volcano.ma30.bull.com>, msmith@volcano.ma30.bull.com (Mike Smith) writes:
   |> 
   |> I have found the following problem a number of times:
   |> 
   |> class A
   |>     new
   |>        ^super new initialize
   |> 
   |> A subclass: #B
   |>     new
   |>        ^super new initialize
   |> 
   |> what happens is that the initialize method for A is never executed,
   |> but the initialize method for B is executed twice.
   |> 
   |> --
   |> -----------------------------------------------------------------------
   |> 
   |>     Mike Smith                       Bull HN Information Systems Inc.
   |>     (508) 294-2049                   300 Concord Road  MA30 826A
   |>     M.Smith@bull.com                 Billerica, MA 01821  USA
   |> 
   |> -----------------------------------------------------------------------

   This is not a bug.  I assume you are trying to instantiate class B, in which
   case the pseudo-variable "super" would refer to B class.  If you want A's
   initialize method to be invoked when instantiating B, you need a "super
   initialize." in B's initialize method.

   However, you are right that B's initialize will be invoked twice when
   instantiating B.  I just posted about this.

I didn't mean to imply that it was a Smalltalk bug, but rather a bug
that I often find in people's code.  As for your post, I guess my news
feed is a little slow, oh well...


   -- 
  |===========================================================================|
  | from:  Randy Stafford               |  Martin Marietta Astronautics Group |
  | mail:  randy@tigercat.den.mmc.com   |  Denver, Colorado                   |
  | voice: (303) 977-1069               |  The foregoing opinions are mine    |
  | fax:   (303) 977-2326               |  and not necessarily my employer's. |
  |---------------------------------------------------------------------------|
  | Words dissemble, words be quick, words resemble walking sticks.           |
  | Plant them and they will grow; watch them waver so.                       |
  | I'll always be a word man - better than a bird man.        --Jim Morrison |
  |===========================================================================|

--
-----------------------------------------------------------------------

    Mike Smith                       Bull HN Information Systems Inc.
    (508) 294-2049                   300 Concord Road  MA30 826A
    M.Smith@bull.com                 Billerica, MA 01821  USA

-----------------------------------------------------------------------
Newsgroups: comp.lang.smalltalk
From: marcs@slc.com (Marc San Soucie)
Subject: Re: Classic Smalltalk bugs
Organization: Servio Corp, Beaverton Oregon, US
Distribution: na
Date: Tue, 21 Jul 1992 19:40:02 GMT

Eliot Miranda (eliot@dcs.qmw.ac.uk) writes:

> This isn't a 'classic bug' but its my favorite Smalltalk implementation bug,
> invented by me whilst in a very devilish mood:

> 	| array |
> 	array := Array with: #perform:withArguments: with: nil.
> 	array at: 2 put: array.
> 	array perform: array first withArguments: array

> Ralph, Eliot (Moss), Allan (Wirfs-Brock), & Mario, does this kill your VM?
> It certainly USED to kill mine, & kills ParcPlace VMs 2.1 through 2.5 & R4.

In GemStone 3.0 it produces a runtime error (after the requisite number of 
descents):

    The execution stack has grown past the stack limit 600.

... 600 being a configurable number, of course.

    Marc San Soucie
    Servio Corporation
    Beaverton, Oregon
    marcs@slc.com
Newsgroups: comp.lang.smalltalk
From: davidm@slc.com (David Monnie)
Subject: Re: Blocks are BAD!!!
Organization: Servio Corp, Beaverton Oregon, US
Date: Tue, 21 Jul 1992 15:46:36 GMT

In article <1992Jul17.213649.22730@zoe.network23.com> terry@zoe.network23.com (Terry) writes:

>From article <1992Jul16.155259.24874@slc.com>, by davidm@slc.com (David Monnie):
>> In article <1992Jul13.155759.16282@zoe.network23.com> terry@zoe.network23.com (Terry) writes:
>>>Problem:
>>>Blocks cause considerable difficulty when attempting to make objects
>>>persistent and these objects refer to blocks.
>> 
>> If you were using a pure OO database to store the blocks -- one
>> which stores behavior, including blocks -- then this shouldn't be
>> terribly difficult.
>
>In general you are correct, but I am saving a complex visual object
>where one of its subcomponents contains a block.  These are normal
>Smalltalk objects.  If your OODB can make 'any' Smalltalk object
>persistent please send me a description.

Servio's GemStone-Smalltalk interface can make blocks persistent,
with some restrictions.  The block cannot reference any temps,
instance variables, or self, and it cannot return from the method.
(These restrictions can all be worked around, though not very pretty,
using block args).  The next release should remove most of these
restrictions.

Also, the block is a real block in GemStone.  You can execute it in
the database, or in Smalltalk.

>Terry
>-- 
>terry@zoe.network23.com
>{rayssd,xanth,mirror,att}!galaxia!zoe!terry

David Monnie
Servio Corp
Beaverton, OR
davidm@slc.com
From: atoenne@mpii02000.cs.uni-sb.de (Andreas Toenne)
Newsgroups: comp.lang.smalltalk
Subject: Re: Not again static type checking (was: Classic Smalltalk bugs)
Date: 23 Jul 92 07:15:21 GMT
Organization: Max-Planck-Institut f"ur Informatik

In article <1992Jul21.140338.12114@heeg.de>, hasko@heeg.de (Hasko Heinecke) writes:
|> In article <1992Jul18.113941.30839@m.cs.uiuc.edu> johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
|> >Another bug that I see nearly everyone make is that add: returns its
|> >argument, not the receiver, and people usually assume that it returns
|> >its receiver.  Thus, they write "(c add: x) add: y" when they should
|> >really write "c add: x; add: y" or else "c add: x. c add: y".  This
|> >is a bug that would be caught by static type-checking.

|> | c x y |
|> c := OrderedCollection new: 10.
|> x := OrderedCollection new: 10.
|> y := 17.
|> (c add: x) add: y.
|> c add: x; add: y.
|> 
|> How should static type checking help?

Very simple. You HAVE TO declare which elements go into c and x. Assume you
have a type inference system that finds these things for you.
After (c add: x) you know that c holds objects of the type of x (which
is not known yet). The whole expression returns x so after
(c add: x) add: y we know that x holds integers.
The next statement introduces an error then:
c add: x; add: y is wrong because c does not store elements of type integer.

Of course one might add to c any instance of a subclass of OrderedCollection.
But OrderedCollection and SmallInteger are only related through Object.
Once you declare c and x to store any object static type-checking cannot detect
that error.

	Andreas
-- 

	Andreas Toenne			Voice: 	x49 681 5846272
	Max-Planck-Institut		Office:	x49 681 302 5363
	fuer Informatik			e-mail:	atoenne@mpi-sb.mpg.de

	Im Stadtwald
	6600 Saarbruecken, Germany
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Subject: (no subject given)
X-Envelope-to: smalk@finhutc
X-VMS-To: BITNET%"smalk@finhutc"
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Newsgroups: comp.lang.smalltalk
Date:         Tue, 28 Jul 1992 11:40:34 +0000
From:         "benot marchal" <INFSTDMARCH@BNANDP51.BITNET>

Dear smalltalkers,

In a previous article, Martin Brown wrote :
> I have uploaded to the smalltalk archive (st.cs.uiuc.edu) the transcript
> of the July 8, 1992 smalltalk irc meeting. The file is "ircjul92.txt.Z"
> and as you see is compressed. It is in the directory pub/tmp.

I'd like to read this article but although I know how to download it,
I can't find how to decompress the file.
Which program should I use ?

I must confess that I'm a PC user, ill-at-ease in UNIX.

Regards, ben