HDTenEightyP/NetNews huggingface dataset:
From: mlanett@Apple.COM (Mark Lanett)
Newsgroups: comp.lang.smalltalk,comp.lang.c++
Subject: Re: Classic Smalltalk bugs
Date: 22 Jul 92 19:58:42 GMT
Distribution: comp
Organization: Apple Computer Inc., Cupertino, CA

deutsch@SMLI.Eng.Sun.COM (L. Peter Deutsch) writes:

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

No, the constructors/destructors do the job. Each List maintains a linked list
of its iterators. When a List is changed, it notifies all of them and their
indices get "bent" to compensate.

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

The only List structure is a dynamically sized array, easily implemented on the
Mac thanks to handles. You get all the advantages/disadvantage of arrays:
easy random lookup, expensive insert/delete as it grows. The base dynamic array
class is not ordered. I believe that the first release of MacApp used linked
lists, but large numbers of objects on a Mac become expensive. There are no
hash table classes. What do you mean that it's "awkward to provide
guarantees"? If Insert, Delete and any other List modiers notify their iterators
than you (as an iterator author) should be able to cope with it.

I disagree about iterating over a copied list. I *want* to iterate over things
inserted since I started, and not to iterate over things that some other
function (or thread) gets rid of. There's the problem of things being inserted
ahead of where the iterator is so you don't see it, however.
-- 
/*      Well, you wanted a command line interface, you got one, and now you
can't figure out how to use it without the manual.  What were you expecting?
That's how command line interfaces work. - John Nagle */
Newsgroups: comp.lang.smalltalk
From: amir@is.morgan.com (Amir Bakhtiar)
Subject: Re: Classic Smalltalk bugs
Organization: Morgan Stanley - IS
Date: Wed, 22 Jul 1992 15:12:08 GMT

A dastardly little problem is related to the use of literals in method definitions.

Imagine an instance method:

	initialize
		someVar := #(1 2 3)

and assume that the new method is:
	
	new
		^super new initialize

Now if an instance of this class is created and at some point during its lifetime the following bit of code is executed:

	someVar at: 2 put: 'Two'

The next new object of this class will be created with someVar initialized to
#(1 'Two' 3). This is because all instances of this class are being given a pointer to the same array (which was created at compile time). What's more, looking at the source code doesn't shed much light on the problem since the code looks exactly the same!

--Amir
Newsgroups: comp.lang.smalltalk
From: terry@zoe.network23.com (Terry)
Subject: Re: encapsulated postscript from st80 4.1 ?
Organization: Mystech Associates
Date: Wed, 29 Jul 1992 16:07:32 GMT

From article <Jul.28.12.11.17.1992.20626@caip.rutgers.edu>, by ghazi@caip.rutgers.edu (Kaveh R. Ghazi):
> 
> 	Does anyone know how to get encapsulated postscript pictures out of
> the Printing.st fileIn code that comes with st80 v4.1?  I asked PP support
> and they responded along the lines of, we tried and couldn't get it to work.
> I need to include smalltalk pictures in other documents.  Any help would be
> appreciated.
> 		Thanks,
> 		--Kaveh
> -- 
> Kaveh R. Ghazi			CAIP Center, Rutgers University.
> ghazi@caip.rutgers.edu		rutgers!caip.rutgers.edu!ghazi

Probably the most expedient way to get a Smalltalk picture into another
document is to produce a screen dump and then use your favorite tool
to import the dump into the document.  If the quality of the image of
a screen dump is too poor then you have two alternatives.

  1. Make an object, probably a subclass of GraphicsContext, that acts
     like a graphics context but produces Postscript code.  I inquired about
     this about a month ago and someone suggested that Xerox may have done
     this for one of their products.

  2. Make a pixmap or mask of sufficient size to contain your image at
     the desired resolution.  Then scale your points to that resolution
     and display your picture on the pixmap.  Next dump the pixmap to
     a file in a format that 'some other tool' can export to your document.

Good Luck

Terry
-- 
terry@zoe.network23.com
{rayssd,xanth,mirror,att}!galaxia!zoe!terry
Newsgroups: comp.lang.smalltalk
From: robert@metropolis.com (Robert Munyer)
Subject: How to prevent subclasses from overriding a method call?
Organization: Metropolis Software, Inc.
Date: Mon, 20 Jul 1992 23:51:39 GMT


Hi.  I am a Smalltalk beginner, and I have come up with an interesting
question.  (At least, *I* think it's interesting).  This could be either

          (1) A "dumb beginner" question,
          (2) A fundamental issue concerning inheritance, or
          (3) Anything between (1) and (2).

Here goes:

Let's say I want to create a class called ClickableThing, each instance of
which occupies a rectangular area on the screen.  I always want to specify the
rectangle when an instance is created:

          ClickableThing new: (200 @ 100 corner: 300 @ 124)

Since a class method can't set instance variables, I have to add an instance
method, and call it from the class method that creates instances:

     class name:              ClickableThing
     superclass:              Object
     instance variable names: frame
     class methods:
          new: box
               ^ super new init: box
     instance methods:
          init: box
               frame := box

So far, so good.  Now suppose I want a subclass of ClickableThing called
NamedButton.  A NamedButton is a ClickableThing which shows its name in the
rectangle.  I want to be able to create NamedButtons like this:

          NamedButton new: 'Do It' at: (200 @ 100 corner: 300 @ 124)

Let's try the same technique:

     class name:              NamedButton
     superclass:              ClickableThing
     instance variable names: name
     class methods:
          new: title at: box
               ^ (super new: box) init: title
     instance methods:
          init: title
               name := title

I'm sure you can see what is wrong here.  NamedButton's "init" method overrides
ClickableThing's "init" method, which breaks ClickableThings's "new:" method.
What I need is some way to specify that ClickableThing's call to "init:" will
call its OWN "init:", and will NOT be overridden by any subclasses.

Is there any way to do this?

Yes, I know, I could give every class's "init:" method a unique name, like
"initNamedButton:".  But it just seems that there ought to be a better way.

So, how about it?  Is there any way to keep a call from being overridden?  Or
should I be doing something different that would avoid this issue altogether?

          Thanks,
______________________________________________________________________
Robert Munyer            |   "I may be synthetic, but I'm not stupid."
robert@metropolis.com    |      -- Bishop, _Aliens_

Newsgroups: comp.lang.smalltalk
From: robert@metropolis.com (Robert Munyer)
Subject: Re: Problems with Dictionary-Class
Organization: Metropolis Software, Inc.
Date: Mon, 20 Jul 1992 23:58:37 GMT


In article <43.24472@rick.infoserv.com> rick@rick.infoserv.com (Rick Klement)
writes:

> In article <1992Jul17.190203.9993@m.cs.uiuc.edu>, johnson@m.cs.uiuc.edu
(Ralph Johnson) writes:

> > One way to solve this problem is to make is possible to grow a collection
> > without copying it.  The solution is to have Set, ORderedCollection, etc
> > have an instance variable that is an Array, *not* to have the indexable
> > instance variable be a part of the Collection object itself. [...]

> Double your objects, double your run time, halve your fun...

Would this also imply that instead of having an instance variable that is a
Rectangle, you should always have four variables that are Integers?

Or is the compiler able to do that kind of optimization automatically?

______________________________________________________________________
Robert Munyer            |   "I may be synthetic, but I'm not stupid."
robert@metropolis.com    |      -- Bishop, _Aliens_
From: georg@heeg.de (Georg Heeg)
Newsgroups: comp.lang.smalltalk
Subject: Re: Objectworks\Smalltalk for OS/2
Date: 30 Jul 92 22:30:18 GMT
Organization: Georg Heeg Objektorientierte Systeme, Dortmund, FRG

In article <ANDRZEJ.92Jul29151231@bcars268.bnr.ca> andrzej@bnr.ca (Andrzej Bieszczad) writes:
>
>I heard that, although it is a 32-bit application, it is very slow
>(much slower than a Windows version). Could you comment?
>
This was true during alpha and beta1 phases: At this time OS/2 was
prerelease (with a lot of DEBUG and ASSERT flags) so was Objectworks, then.

The product version runs actually faster then the Windows version:

Same image, same computer. We benchmarked 399.5 % Dorado on an 80486 33 MHz.

Georg Heeg
Newsgroups: comp.lang.smalltalk
From: prasad@cis.ksu.edu (Baba C Prasad)
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bugs
Date: 24 Jul 92 17:19:29 GMT
Organization: Kansas State University, Dept. of Computing and Information Sciences
NNTP-Posting-Host: altair.cis.ksu.edu



Hi:
	We've seen a lot of 'classic bugs' showing up in
this newsgroup since the original message was posted. Is
there some way we can store all these and make them 
available to people who may join this newsgroup later also?

--baba
From: DAV@VTMSL.BITNET (Daniel Viglione)
Newsgroups: comp.lang.smalltalk
Subject: No Subject
Date: 28 Jul 92 21:31:12 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Comments:     Converted from PROFS to RFC822 format by PUMP V2.0

From:  Daniel Viglione

    Ben,   files with the .Z extension in Unix can be uncompressed with the
(standard?!) Unix uncompress utility.

Try:
% uncompress -v ircjul92.txt.Z

This should work.   Do a % man uncompress       for more info on it.

There are also other compress\uncompress utilities for the Mac that can
decipher unix .Z extensioned files.  I'm sure there are some around for PCs,
but I can't think of the names.

Hope this helps.... Dan.
Newsgroups: comp.lang.smalltalk
From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Subject: Re: FYI: Jy irc meeting transcript
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Sun, 26 Jul 1992 02:47:23 GMT

I moved the irc transcript to /pub/irc.
Newsgroups: comp.lang.smalltalk
From: robert@metropolis.com (Robert Munyer)
Subject: Difference between ST's "[]" and Lisp's "lambda"
Organization: Metropolis Software, Inc.
Date: Tue, 21 Jul 1992 01:03:07 GMT


Difference between Blocks in Smalltalk and Lambda's in Lisp

A little while ago, somebody hinted obliquely in this group that
one of these two constructs was more powerful than the other.

It seems to me that they are pretty much identical.

Anybody know what the difference is?

                                        Thanks,

                                        Robert Munyer
                                        robert@metropolis.com

Newsgroups: comp.lang.smalltalk
From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Subject: Re: Where can I find an Actor smiulator in Smalltalk?
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Thu, 23 Jul 1992 16:40:53 GMT

There is an Actor simulator in the Smalltalk archive that is
mirrored at U. Illinois at Urbana-Champaign and at U. Manchester.
I don't remember the address of the U. Manchester archive, but
you can ftp to the UIUC one at st.cs.uiuc.edu or can access an
e-mail archive server by sending e-mail to archive-server@st.cs.uiuc.edu.
To learn how it works, send the message

  path  your-email-address
  help

Of course, replace your-email-address with an address that we could
use to get mail to you.  It is amusing how many people don't do this.

There is lots and lots of software here.  I only know a fraction of it.
It would be useful to get "consumer reports" on what is in the archive.
Also, we are very happy to get contributions, so please remember us
if you have something that is even half-way useful.  

-Ralph Johnson

Xref: sparky comp.lang.smalltalk:1482 comp.lang.c++:11350
From: deutsch@SMLI.Eng.Sun.COM (L. Peter Deutsch)
Newsgroups: comp.lang.smalltalk,comp.lang.c++
Subject: Re: Classic Smalltalk bugs
Date: 22 Jul 92 19:50:25 GMT
	<STEINMAN.92Jul18192431@hawk.is.morgan.com> <knight.711600639@cunews>
	<k4dmhdd.nagle@netcom.com> <70298@apple.Apple.COM>
	<DEUTSCH.92Jul21153319@luxembourg.SMLI.Eng.Sun.COM>
	<70340@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 22 Jul 92 19:58:42 GMT

In article <70340@apple.Apple.COM> mlanett@Apple.COM (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).

   No, the constructors/destructors do the job. Each List maintains a linked list
   of its iterators. When a List is changed, it notifies all of them and their
   indices get "bent" to compensate.

I don't think you understood my question.  The answer to my question
appears to be "yes": if you don't explicitly delete / finalize the
iterator, the list will hang onto it forever, and its space will never be
reclaimed.  If the iterator was allocated on the stack rather than the
heap, you will get a dangling reference and random data clobbering.  Even a
garbage collecting system will not solve this problem unless you have very
smart weak references.  So from my point of view, this is a major
reliability bug in the design.

C++ destructors do not solve this problem.  If you stack-allocate the
iterator, you still have the dangling pointer problem.  If you
heap-allocate the iterator, you have to 'delete' it explicitly.

   I disagree about iterating over a copied list. I *want* to iterate over things
   inserted since I started, and not to iterate over things that some other
   function (or thread) gets rid of. There's the problem of things being inserted
   ahead of where the iterator is so you don't see it, however.

Right.  In other words, you wind up iterating over a set of elements that
you can't predict on the basis of the interface specification.  I think
this will produce confusing, inconsistent, and problematic results.  The
situation is much worse for random-access structures like hash tables,
where there is no natural sequential ordering of the elements, so whether
or not you see an element inserted during iteration is completely random.
Newsgroups: comp.lang.smalltalk
From: steinman@is.morgan.com (Jan Steinman)
Subject: Re: Classic Smalltalk bugs
Organization: Morgan Stanley & Company
Date: Tue, 21 Jul 1992 14:49:31 GMT

In article <2610025@otter.hpl.hp.com> scrl@otter.hpl.hp.com (Simon Lewis) writes:
   Jan Steinman contributes :

   > done := False.
   > [done = True] whileFalse:
   > [...
   > exitCondition ifTrue: [done := True].
   > ...]

   Interesting.  What did you have in mind?... no doubt this code does
   do what the programmer intended.

Serendipitously, at that! Doubly-lucky, since the performance hit in
this particular bit of shotgun code isn't all that bad.

All in favor of randomly changing code until it works, raise your
hands! Okay, those who raised your hands are condemned to maintain
each other's code.
--
: : Jan Steinman	   steinman@is.morgan.com		 Bytesmiths : :
: : 2002 Parkside Court				   West Linn, OR 97068-2767 : :
: : 503/657-7703					       212/956-8722 : :
From: Tom Lanning
Newsgroups: comp.lang.smalltalk
Subject: where to put the meta?
Summary: add instance variables to object
Date: 21 Jul 92 19:29:28 GMT
Article-I.D.: ceylon.588
Reply-To: tlanning@gte.com
Organization: GTE Laboratories Incorporated

This is probably an old problem, but here it goes again

We are developing a modeling system based on PPS 4.1.  We want to use the
native Smalltalk object and class system.  We want to add "meta-information" to
each object, (e.g., time created, simulation statistics, certainity ratings,
etc.).  It is simple to add methods to Object, however it seems impossible to
add instance variables that we need due to several different types of objects
(byte-type, indexed-type, etc.).

We have explored the option of creating another object system residing above
the Smalltalk system.  We do not like this option since we loose simple access
to the Smalltalk libaries and development tools.

Any advice?  (Jumping off a bridge is not the type of advice we are looking for
.... unless there is a bungee cord attached!)
From: juha.veijalainen@compart.fi (Juha Veijalainen) 
Newsgroups: comp.lang.smalltalk
Subject: Installation programs
Date: 20 Jul 92 01:16: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) 

Can Smalltalk/V Windows 2.0 Installation program be modified for you own 
application? (or more precisely its data files)  Has anyone experimented 
with this?

It seems to me that it might be possible, if the program is driven from 
the installation data files.

If it's possible to use the program, is it possible to use it under the 
runtime license terms?  Runtime license allows you to copy Smalltalk 
files, except the ones containing development classes.  It's not clear to 
me whether this includes the installation files.

---
 . WinQwk 2.0 #152 . Mielipiteet omiani/Opinions personal/Facts suspect
From: deutsch@SMLI.Eng.Sun.COM (L. Peter Deutsch)
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bugs
Date: 28 Jul 92 21:16:56 GMT
	<1992Jul25.213849.4810@zoe.network23.com> <78mm1rh.peterg@netcom.com>
Distribution: comp
Organization: Sun Microsystems Laboratories Inc.
NNTP-Posting-Host: luxembourg.eng.sun.com
In-reply-to: peterg@netcom.com's message of 28 Jul 92 22:20:18 GMT

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

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.
From: john@ahuriri.gen.nz (John McCombs)
Newsgroups: comp.lang.smalltalk
Subject: Re: STV for Win runtime?
Date: 23 Jul 92 08:45:59 GMT
Organization: Organisation? Where?


  > > The problem is as follows.  When I crank up the app with a DoIt in the
  > > Transcript it all works fine.  If I run it as a standalone by running
  > > v.exe it gets most of the way through the initialisation code before
  > > croaking with either 'do: does not understand' or
  > > 'open: does not understand'.
  >
  > I experienced the same kind of problems when turning my code into run time app.  > I got for example a window that says 'Run time error, new : does not
  > understand'
  > I have not found the origin of the problem so far. So if you get any answer
  > please post it on the net.

Philippe,

I can't give you a definitive answer, but I added 4MB of RAM and upgraded
to ST/V 2.0 and the problem seems to have disappeared.  My best guess is
that the problem was related to a lack of memory.

Someone pointed out that since the compiler is part of the development
classes you can't file stuff in from the runtime environment

cheers, John


--------------------------------------
John McCombs       john@ahuriri.gen.nz
ph +64-3-665-234     fax +64-3-655-755
Christchurch,              New Zealand
--------------------------------------
From: mjb@netcom.com (Martin Brown)
Newsgroups: comp.lang.smalltalk
Subject: ** ANNOUNCEMENT **  August ST meeting on irc
Date: 30 Jul 92 02:46:48 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)


***************************

ANNOUNCING

Meeting of Smalltalk Users

------

When: Wednesday, August 5, 1992      

Time: 10:00am PDT, (Pacific **DAYLIGHT** Time, U.S.A.)  

Where: on the Internet Relay Chat (irc)

IRC Channel: #programST        

Channel Topic: programming in Smalltalk 

***************************

This time should allow greater participation from European ST users.

-- 

                                   - mjb -

                                mjb@netcom.com
From: Hubert.Baumeister@mpi-sb.mpg.de (Hubert Baumeister)
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bugs
Date: 21 Jul 92 13:22:27 GMT
Organization: Max-Planck-Institut f"ur Informatik

In article <1992Jul20.180043.7996@den.mmc.com>, randy@tigercat.den.mmc.com (Randy Stafford) writes:
|> Here's one of my favorites, which may have more to do with design than with
|> the Smalltalk system.
|> 
|> Suppose you have a fairly deeply nested hierarchy of classes, in which most
|> or all of the classes implement instance creating methods that invoke the
|> superclass's instance creating method, and that send initialize to the
|> created instance (e.g., ^super new initialize).  If you want to create an
|> instance of a "leaf" class, the result is that the created instance's
|> initialize method will be invoked multiple times.

Why do you have to redefine new in each subclass anew? I suffices if one
superclass defines new as ^super new initialize or ^self basicNew
initialize. ^super new initialize instead of ^self basicNew initialize is
only necessary if the object is initialized in the new method of the
superclass by explicit sending of methods that set the state of the object
instead of sending initialize. 

So, if the new method of a superclass sends initialize to the newly created
object there is no need to redefine new in a subclass.

It is true that when writing a class hierarchy you have to redefine new in
your root classes to include an initialization method, since it is not the
default behaviour of most classes to send initialize in the new method.

Hubert

-- 
Hubert Baumeister
MPI Informatik, Im Stadtwald, W-6600 Saarbr"ucken, Germany
Phone: (x49-681)302-5432
e-mail: Hubert.Baumeister@mpi-sb.mpg.de