HDTenEightyP/NetNews huggingface dataset:
From: rupertb@is.morgan.com (Rupert Brown)
Subject: Smalltalk on Windows NT
Organization: Morgan Stanley - IS
Date: Thu, 23 Jul 1992 06:36:19 GMT

Has anyone else tried running either Digitalk's V/Win 2.0 or ParcPlace
r4.1 for Windows on the recently "pre-released" WinNT SDK ?
I get a GP fault in KRNL286.EXE running V/Win 2.0 and a "Cannot find Mouse.DLL"
when trying to run ParcPlace r4.1 for Windows.
From: eliot@dcs.qmw.ac.uk (Eliot Miranda;W211)
Newsgroups: comp.lang.smalltalk
Subject: Immutable Literals (was Classic Smalltalk bugs)
Date: 30 Jul 92 11:19:25 GMT
Organization: Computer Science Dept, QMW, University of London

In <1992Jul22.111208@is.morgan.com> amir@is.morgan.com (Amir Bakhtiar) writes:

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

I've replaced literal strings, byte arrays & arrays in my system with
ImmutableString, ImmutableByteArray & ImmutableArray.  Further, with a bit
of constant folding you also get ImutablePoint.  These are easy to implement
providing you have a changeClassTo:, or changeClassToThatOf: primitive.
If you don't, until private is enforced there will always be holes.
Changes to the compiler are simple, basically identifying when to send a
newly constructed literal becomeImmutable.

The next step is to make the identity of such immutables depend on their
value, so we have immutable values, rather than immutable objects.
The advantages of immutable values include the ability to copy them freely in
a distributed context.

Another (IMHO) sensible thing to do is to introduce a new root to the class
hierarchy called PrimitiveObject that defines the execution machinery's
interface to objects.  PrimitiveObject is the superclass of both Object and
Encapsulator (pascoe OOPSLA '86).  PrimitiveObject's protocol is

accessing		POat: POat:put: POsize
comparing		POeqeq: POneqneq:
class membership	POclass
message handling	POperform:inClass:withArguments: POperform:withArguments:
error handling		doesNotUnderstand: POprimitiveFailed
user interface		POinspect
system primitives	POinstVarAt: POinstVarAt:put: POisReadable POisWritable)
system simulation	tryPrimitive0 .. tryPrimitive6:with:with:with:with:with:

which are either alternative versions of the usual primitive methods, or
error notifications.  All uses of the usual primiitves in the debugger and
execution simulation classes (Context et al) are replaced by the primitives
defined in PrimitiveObject.  The upshot of all this is that you can debug
encapsulators, which is very useful if you're developing a distributed smalltalk
:-).


Now what I need are some decent design/implementation ideas for private.



If people are interested in this stuff I can submit a 2.3 compatible version
to the manchester goodies library.

--
Eliot Miranda			email:	eliot@dcs.qmw.ac.uk
Department of Computer Science	ARPA:	eliot%dcs.qmw.ac.uk@nsf.ac.uk
Queen Mary Westfield College	UUCP:	eliot@qmw-dcs.uucp
Mile End Road, LONDON E1 4NS	Tel:	071 975 5229 (+44 71 975 5229)
				Fax:	081 980 6533 (+44 81 980 6533)
Newsgroups: comp.lang.smalltalk
From: jon@iti.gov.sg (Jonathan Priddey)
Subject: Smalltalk/V DLL call for char**
Reply-To: jon@iti.gov.sg
Organization: Information Technology Institute, National Computer Board, S'pore
Date: Fri, 24 Jul 1992 00:49:04 GMT

I'm trying to wrap a commercial DLL from Smalltalk/V 1.1 for MS Windows.
Most calls convert ok using the <api ...> syntax, but whereas struct
works for char*, ie String, I need an array of pointers to Strings for char**.
How can I get addresses of a String to be stored in a ByteArray? I can't find
any address methods.

Has anyone done this?

Regards, Jon.


Xref: sparky comp.lang.smalltalk:1490 comp.lang.c++:11392
From: mlanett@Apple.COM (Mark Lanett)
Newsgroups: comp.lang.smalltalk,comp.lang.c++
Subject: Re: Classic Smalltalk bugs
Date: 23 Jul 92 04:18:16 GMT
Distribution: comp
Organization: Apple Computer Inc., Cupertino, CA

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

>In article <70340@apple.Apple.COM> mlanett@Apple.COM (Mark Lanett) writes:

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

>   No, the constructors/destructors do the job. Each List maintains a linked list

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

Wait a second. Something's not clear here. How does stack-allocation not
solve it? The destructor always gets called for stack-based objects. Maybe
you mean if an exception is thrown? Hey, MacApp may not have "real" exceptions,
but its form of exception handling can still handle this situation. So the
answer is "yes", the iterators need to inform the Lists, but it's not a problem
or flaw in the design. In MacApp, Lists are always heap-based and iterators
are always stack based. One point of interest: to delete a list, you call
Free on it rather than delete; it will delete itself when all iterators are
done with it.

[some points about hash tables]

Agreed. Hash tables are a problem (which MacApp ignores). In this case I guess
you are forced to copy the list before iterating over it.
-- 
/*      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 */
From: support@heeg.de (Support)
Newsgroups: comp.lang.smalltalk
Subject: Objectworks\Smalltalk for OS/2
Date: 29 Jul 92 14:53:59 GMT
Organization: Georg Heeg Objektorientierte Systeme, Dortmund, FRG

There have been several requests for Objectworks\Smalltalk for OS/2. So here's
the official info:

Objectworks\Smalltalk Rel. 4.0 for OS/2 _is_ _available_.

It is fully compatible with all other Objectworks\Smalltalk Rel. 4.0 versions
and includes a FREE upgrade to Rel. 4.1 for OS/2 as soon as it is available.

Contact info@parcplace.com for orders/information. If they can't help you,
contact support@heeg.de for information. (We ported the software.)

Bye, Hasko
-- 
+--------------------------------------------------------+
| Hasko Heinecke @ Georg Heeg Orbjektorientierte Systeme |
| I _never_ mean what I say - and noboy else does...     |
+--------------------------------------------------------+
Newsgroups: comp.lang.smalltalk
From: irvine@ntmtv.UUCP (Chuck Irvine)
Subject: wanted: hypertext widget(s)	
Keywords: hypertext, widget, window
Organization: Northern Telecom Inc, Mountain View, CA
Date: Mon, 27 Jul 1992 19:23:15 GMT

I'd like to get my hands on some general purpose hypertext
widgets for SmalltalkV for Windows. Actually, some classes
that encapsulate the functionality of the standard windows
help facility might serve the purpose quite well. Can anyone 
help me out here? I hope I'm not posting to the wrong group;
please tell me if I am. Thanks.

Chuck Irvine
ames!ntmtv!irvine

Newsgroups: comp.lang.smalltalk
From: andrzej@bnr.ca (Andrzej Bieszczad)
Subject: Re: Objectworks\Smalltalk for OS/2
Organization: Bell-Northern Research Ltd.,
Date: Wed, 29 Jul 1992 20:12:31 GMT

In article <1992Jul29.145359.28804@heeg.de> support@heeg.de (Support) writes:

   There have been several requests for Objectworks\Smalltalk for OS/2. So here's
   the official info:

   Objectworks\Smalltalk Rel. 4.0 for OS/2 _is_ _available_.

   It is fully compatible with all other Objectworks\Smalltalk Rel. 4.0 versions
   and includes a FREE upgrade to Rel. 4.1 for OS/2 as soon as it is available.

   Contact info@parcplace.com for orders/information. If they can't help you,
   contact support@heeg.de for information. (We ported the software.)

   Bye, Hasko
   -- 
   +--------------------------------------------------------+
   | Hasko Heinecke @ Georg Heeg Orbjektorientierte Systeme |
   | I _never_ mean what I say - and noboy else does...     |
   +--------------------------------------------------------+

I heard that, although it is a 32-bit application, it is very slow
(much slower than a Windows version). Could you comment?

Thanks a lot,
--
========================================================================
Andrzej Bieszczad                     | Phone:  (613) 763-2259
Bell-Northern Research, Ltd.          | Fax:    (613) 763-3283
Dept. 9K12, P.O. Box 3511, Station C, | USENET: uunet!bnrgate!eh!andrzej
Ottawa, Ontario, Canada, K1Y 4H7      | BitNet: andrzej@BNR.CA
========================================================================

Xref: sparky comp.lang.smalltalk:1469 comp.lang.c++:11264
From: mlanett@Apple.COM (Mark Lanett)
Newsgroups: comp.lang.smalltalk,comp.lang.c++
Subject: Re: Classic Smalltalk bugs
Date: 21 Jul 92 20:49:03 GMT
Organization: Apple Computer Inc., Cupertino, CA

nagle@netcom.com (John Nagle) writes:

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

>       Yes, this is a problem.  It's also a problem with C++ iterators,
>and it tends to be worse in C++, because one can end up referencing
>deallocated objects.

>       I've found this a serious problem in a Mac class library for
>a GUI, where some sequences of events result in deletions from a list
>being iterated over.

How interesting... which class library? MacApp 3.0 iterators are entirely
capable of handling insertions/deletions in their list, with any 
number of iterators on them. I've come to depend on it; it makes life much
easier not having to worry about the side effects of functions called within
the iteration loop.
-- 
Have a bajillion brilliant Jobsian lithium licks.
Mark Lanett, NOT speaking for apple. Personal opinion only.
From: sbb@laplace.eng.sun.com (Steve Byrne)
Newsgroups: comp.lang.smalltalk
Subject: Re: Smalltalk compiler suggestions?
Date: 28 Jul 92 00:56:48 GMT
Organization: FSF hackers, Smalltalk division
NNTP-Posting-Host: laplace
In-reply-to: john@spectre.unm.edu's message of Mon, 20 Jul 92 21:03:40 GMT

In article <z7cmmmf@lynx.unm.edu> john@spectre.unm.edu (John Prentice) writes:

   I posted this same question last week, but to my astonishment, I haven't
   received one response.  So here goes again :-) .  I am new to smalltalk and
   OOPS.  I am looking for a interpreter/compiler to play with the language on.
   I am interested in running it on a 286 laptop most likely, though I also
   could run it on either my 386 system or my Sparc 2.  Since I am just playing
   with the language and not trying to do serious work with it, I would prefer
   to keep the cost of the interpreter/compiler low, but I would consider anything
   up to a thousand or so.  Any suggestions on where to look would be much
   appreciated!

GNU Smalltalk is available and works on Sparc2's (and 386's running Unix).  It
includes support for all of the base classes described in the Smaltalk-80 blue
(now purple) book.  It has a number of extensions to make users more able to
"system" level programming.  It does not have a GUI-based class browser/editor,
but it does have some GNU Emacs based editing and browser-like capabilities.

You can FTP GNU Smalltalk from a number of different hosts around the world,
but prep.ai.mit.edu:/pub/gnu/smalltalk-1.1.1.tar.Z  is it's home.  

Steve
Xref: sparky comp.lang.smalltalk:1518 comp.object:3026
From: vimal@wang.com (Vimal Goel)
Newsgroups: comp.lang.smalltalk,comp.object
Subject: Smalltalk courses, Boston area.  Are there any offered???
Date: 27 Jul 92 20:55:43 GMT
Distribution: na
Organization: Wang Labs, Lowell MA, USA

Hello:  I am interested in finding out whether any Smalltalk courses are
being offered in the Boston area?
Please email to vimal@wang.com
Thanks
Newsgroups: comp.lang.smalltalk
From: Kurt Piersol <Piersol@Apple.com>
Subject: Re: Classic Smalltalk bugs
X-Useragent: Nuntius v1.1
Date: Fri, 24 Jul 1992 01:25:25 GMT
     <70363@apple.Apple.COM> <20176@sbsvax.cs.uni-sb.de>
     <2610026@otter.hpl.hp.com>
Organization: Apple Computer

One of my favorite common bugs in Smalltalk-80 involves the infinite
variations on:

    a := 5.
    b := nil.
    a become: b.


Since Smalltalk-80 traditionally swaps the pointers in the object table,
the result is that the distinguished nil object has been replaced by
something else. Needless to say, things tend to grind to a halt rapidly
after that. There are plenty of variations on this theme, few of which
are as obviously stupid as the code shown above. Typically, one simply
does become: with an undefined variable, hosing nil in the process.
Swapping the other distinguished objects this way, such as true, false,
and the Smalltalk global dictionary are amusing variations.

Another class of favorite bug involves the operation of blocks which
refer to temporary variables of their originating context. The fact that
these blocks are non-reentrant is not particularly obvious at first, and
thus a whole class of errors are spawned.

Of course, the whole class of errors produced by the lack of operator
precedence among binary operators gives even experiences programmers fits
from time to time. I made these errors even after seven years of
Smalltalk programming.

Lastly, altering literal arrays when passing them as parameters is a
classic subtle bug. Reminds me of passing constants as arguments in
Fortran.
From: riks@ogicse.ogi.edu (Rik Fischer Smoody)
Newsgroups: comp.lang.smalltalk
Subject: Re: where to put the meta?
Date: 23 Jul 92 19:48:14 GMT
Article-I.D.: ogicse.40455
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR

Tom Lanning wrote:
>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.
Try making a (big) dictionary, with keys being the objects you want to keep
extra info about, and values being the extra info.
You certainly do not want to add that information to all of Smalltalk's
objects: you would likely get into an infinite regress of storing
the creationTime of the creationTime of the creationTime of the creationTime...

Another possibility (hard to tell from your statement of the problem)
is to make one (or even several) abstract super-classes such as
Object subclass: #OurObject
	instanceVariableNames: 'creationTime simStats confidence'
and subclass from there for the things for which you wanna store baggage.

BTW: I fear we are losing (have lost?) the discriminating power of the
    term "meta".  Ah, well: language evolves.

Rik Fischer Smoody
smOOdynamics	 Systems Made Outa Objects
	2400 NE 25th Suite 800
	Portland, OR 97212
riks@cse.ogi.edu
503-249-8300
Newsgroups: comp.lang.smalltalk
From: dmm@aristotle.ils.nwu.edu (donald)
Subject: Re: Classic Smalltalk bugs
Organization: The Institute for the Learning Sciences
X-Newsreader: Tin 1.1 PL4
Date: Tue, 21 Jul 1992 15:54:12 GMT

eliot@dcs.qmw.ac.uk (Eliot Miranda;W211) 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.

It should come as no surprise that this kills st\vWin 1.1 at a similar
level (no explicit VM).

donald
From: mario@cs.man.ac.uk (Mario Wolczko)
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bugs
Date: 30 Jul 92 12:51:14 GMT
Organization: Dept Computer Science, University of Manchester, U.K.

In article <78mm1rh.peterg@netcom.com>, peterg@netcom.com (Peter Goodall) writes:
> 'scuse me, but with left-to-right evaluation, it is very easy to accurately
> determine what is happening. 

True, but many Smalltalk novices, especially those from the
C/Pascal/Fortran world, easily slip into old habits and forget that
Smalltalk is strictly left-to-right.  I have no objections to
left-to-right, but was merely pointing out that it's the cause of many
mistakes (even by experienced Smalltalkers).

Peter Deutsch writes:
> And I could be talked into making a special case for
> considering + and -, and * and /, the "same".
I hope it wasn't you who wrote the code I quoted from 
the 4.0 image, which was of the form "a + b*c".  :-)  
It took me the best part of an hour to track down why it was claiming
the methods in image occupied 2Gb!

Mario

   ______      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: peterg@netcom.com (Peter Goodall)
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bugs
Date: 29 Jul 92 21:39:14 GMT
Distribution: comp
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

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

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

Now my memory works! What you describe is exactly what is required
in Occam.

Peter Goodall.
peterg@netcom.com
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bugs
From: kjx@comp.vuw.ac.nz (R James Noble)
Date: Wed, 29 Jul 1992 03:54:03 GMT
 rh.peterg@netcom.com><DEUTSCH.92Jul28161656@luxembourg.SMLI.Eng.Sun.COM>
Distribution: comp
Organization: Victoria University of Wellington, Wellington, New Zealand

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.

Coincidently, Self does just this. I haven't missed arbitrary
unparenthesized binary expressions.

(of course, Self then allows one to omit the "self" keyword, and write
methods like (^(%2)=0.) But that's incidental to this question).

kjx
--
R James Noble, Graduate Student, Computer Science Department
Victoria University, Box 600, Wellington 1, New Zealand
kjx@comp.vuw.ac.nz
From: stickler@klaava.Helsinki.FI (Patric M Stickler)
Newsgroups: comp.lang.smalltalk
Subject: Need info on Objectkit Parser Generator
Date: 27 Jul 92 12:13:35 GMT
Organization: University of Helsinki

Could someone "in the know" please tell me a little bit about the parser
generator avaliable with Objectkit for Objectworks/Smalltalk?

Is it simply yacc & lex for Smalltalk?
Does it support EBNF or RRPG constructions?
Is the generator itself written in Smalltalk?

Any info would be greatly appreciated.



//////////////////////////////////////////////////////////////////////////
  Patrick M. Stickler (pms@wsoy.fi)       The comments contained herein
  WSOY, Information Systems Division      do not necessarily reflect the
  Bulevardi 12, 00121 Helsinki Finland    official views of my employer.
//////////////////////////////////////////////////////////////////////////
From: mario@cs.man.ac.uk (Mario Wolczko)
Newsgroups: comp.lang.smalltalk
Subject: Re: Classic Smalltalk bugs
Date: 24 Jul 92 19:47:16 GMT
Organization: Dept of Computer Science, University of Manchester, U.K.

As nobody has mentioned it yet, I submit the following line as an
example of another common bug (taken from
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
   ______      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: jonathan@cs.yorku.ca (Jonathan Ostroff)
Newsgroups: comp.lang.smalltalk
Subject: TIGRE experience
Keywords: smalltalk, graphics
Date: 30 Jul 92 01:43:32 GMT
Article-I.D.: yetti.1372
Distribution: na
Organization: York University, Dept. of Computer Science

I apologize if this is a FAQ, but I am new to the group. 

I am contemplating purchasing TIGRE to speed up our user interfaces
in some software that we are designing for analyzing systems with
diagrammatic notations.

I would very much appreciate hearing about your experience with TIGRE.
In particular, I am interested in the following:

1. Does it do the same type of thing as the NEXT application builder.
Can one click and drag and resize widgets.

2. Would TIGRE be useful for designing a MacDraw like interface for
say flowcharting?

3. Does it work with Objectworks 4.0 and 4.1. 

4. Does it come as a .st file. Once you build an application, can you
distribute the application easily to other computing platforms. 

5. If some user interfaces have already been developed using MVC, can
these be retrofitted with TIGRE?

6. what are the perhaps hidden deficiencies in the product?

7. Are there any better products? Is ParcPlace developing this kind of
thing?



I would very much appreciate your help and feedback on this product.
-- 
Jonathan Ostroff

Dep. of Computer Science,
York University,
Xref: sparky comp.lang.smalltalk:1471 comp.lang.c++:11277