HDTenEightyP/NetNews huggingface dataset:
From: jax@well.sf.ca.us (Jack J. Woehr)
Subject: Re: ST/VWin 2.0 upgrade - OVERPRICED???
Summary: No, it's not!
Organization: Whole Earth 'Lectronic Link
Date: Wed, 30 Sep 1992 03:05:13 GMT


	I disagree with the general tenor of this thread.

	STVWin 2.0 is great for $195.00

	My personal hunch is that telephone support was killing Digi
and this has to do with their price increases and regressive customer
support policy (overpriced online service, when they could do it cheaper
on GEnie and make a profit, too)

	But they put out a devil of a fine system for the price. ANd
their documentation is excellent, I might add ... especially since
they stopped printing doublequote " as `` and singlequotes ' ' as ` '

	:-) :-)

		=jax=
-- 
 # jax@well.{UUCP,sf.ca.us}  # #  Member  # # Vice President,       #
 # du!isis!koscej!jax        # # X3J14 TC # #  Forth Interest Group #
 # JAX on GEnie              # # for ANS  # #   P.O. Box 8231       #
 # SYSOP RCFB (303) 278-0364 # #  Forth   # #    San Jose CA 95155  #
Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
From: nagle@netcom.com (John Nagle)
Subject: Re: comparing object-oriented platforms
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Mon, 5 Oct 1992 17:23:08 GMT

dsr@bnr.co.uk (D.S.Riches) writes:
>There have been a number of Real time systems produced using
>Smalltalk for instance.  Real time does not imply no garbage
>collection but if you actually mean safety critical then that might
>be a different issue.

       I saw a review of a protocol analyzer (a standalone hardware test
instrument) which used a Smalltalk implementation inside.  The reviewer
found the notion of a test instrument which periodically stalled for
garbage collection very strange, and probably unacceptable.  One didn't
lose data during garbage collection, but the keyboard and screen went dead.

					John Nagle
Newsgroups: comp.lang.smalltalk
From: mjb@netcom.com (Martin Brown)
Subject: Reminder: ST meeting THIS Wednesday on irc
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Tue, 6 Oct 1992 07:46:55 GMT


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

ANNOUNCING

Meeting of Smalltalk Users

------

When: Wednesday, October 7, 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

Newsgroups: comp.lang.smalltalk
From: nadja@jetsun.weitek.COM (Nadja Adolf)
Subject: Re: comparing object-oriented platforms
Organization: WEITEK Corporation, Sunnyvale CA
Date: Tue, 6 Oct 92 23:28:08 GMT

In article <9210052021.AA06756@data.src.honeywell.com> bergstro@src.honeywell.com (Pete Bergstrom) writes:
>nadja@jetsun.weitek.COM (Nadja Adolf) wrote:
>>
>>In article <ken8Xe_00awRQ5OHYd@andrew.cmu.edu> osoelgaultier+@CMU.EDU (Stefan Monnier) writes:
>>>Static type checking makes it harder to develop code in limited
>>>time (prototype doesn't have to be bug free, nor fast, nor complete)

>>I thought about this over the weekend, and realized that one thing really
>>bothers me here. It is amazing how little of a smalltalk program has to
>>be present for it to appear to 'work.'

>>One gets the demo up, it appears to work, and the managers/moneyfolk don't
>>realize that one is nowhere near a product yet... and anticipate a totally
>>unrealistic schedule...

>Do you mean to say that you don't use prototypes to explore
>requirements and design tradeoffs?  I'm currently working on a
>prototype (it happens that I switched from C to Smalltalk) for the
>express purpose of figuring out how to write an interactive financial
>modeling application.  

I said DEMO, not prototype. Do you mean to say that you don't understand
the difference between a demo and a prototype?

>If your requirements have been fully explored and you have a set of
>constraints cast in iron, then I agree that you might want to use some
>language optimized for the machine.

I really don't see what any of this has to do with demos. 

>As far as the misperceptions of "managers/moneyfolk" go, you have to
>keep some sense of credibility.  If it's not even close to being done,
>you shouldn't allow them the impression that it is.  (Once you've said
>so, it's beyond your control what they do.)

That is my point. I have seen people show off demos as if they had real
product hidden somewhere underneath. In fact, I heard a joke based on the
theme.


-- 
The Earth Pig Bourne....

nadja@node.com (prefered email address)
nadja@weitek.com
From: tcm@moscom.com (Tom Maszerowski)
Newsgroups: comp.lang.smalltalk
Subject: Little Smalltalk - Mac version?
Summary: Is it available anymore?
Keywords: Little Smalltalk Budd Mac
Date: 28 Sep 92 13:10:10 GMT
Followup-To: tcm@moscom.com
Organization: Moscom Corp., Pittsford NY


Background:

   I am taking an object-oriented programming course and we are currently
using Little Smalltalk v3 from Tim Budd. We are using the UNIX version.
The documentation states that it will compile on the Mac as well, but the
version I have available doesn't seem to have that in it.

Question:

   Is Little Smalltalk available anymore and does it still support the
Mac, even minimally? I have THINK C 5 and can owrk from source code if
need be.


Thanks in advance.

Tom

-- 
Tom Maszerowski    tcm@moscom.com   
                   {rit,tropix,ur-valhalla}!moscom!tcm
                   DoD #1957 (1987 BMW K75s) BMWMOA #59113
Newsgroups: comp.lang.smalltalk
From: mbehrens@barqs.amd.com (Mikael Behrens)
Subject: ListAndSelection and SelectionInList
Keywords: class duplicate
Reply-To: mbehrens@ausun1.amd.com
Organization: Advanced Micro Devices, Inc.; Austin, Texas
Distribution: usa
Date: Thu, 1 Oct 92 22:03:42 GMT

I'm using ParcPlace's Smalltalk 4.1 and I just found two classes that seem to  
be almost identical: ListAndSelection, and SelectionInList.  Would someone  
please explain the differences to me?  Email would be fine.

Thanks

Mikael Behrens
mbehrens@ausun1.amd.com (NeXT mail okay)
Xref: sparky comp.lang.smalltalk:1912 comp.lang.eiffel:1162 comp.object:3717
From: osoelgaultier+@CMU.EDU (Stefan Monnier)
Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
Subject: Re: comparing object-oriented platforms
Date: 26 Sep 92 12:17:23 GMT
Article-I.D.: andrew.welAJHa00Vor81pWA6
	<-t!p#_a.nagle@netcom.com>
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.lang.eiffel: 26-Sep-92 Re: comparing
object-orient.. John Nagle@netcom.com (1174)

> mwu@orion.oac.uci.edu (Matt Wu) writes:
> >I'm currently evaluating several object-oriented development platforms
> >and I was wondering if any of you would like to share your opinions on
> >platforms that you prefer or know about.  It'd be especially useful to hear
> >comparisons between different platforms (for instance, Eiffel v. Smalltalk).

>       The language situation is roughly as follows:

> 	Ada		Big, no inheritance, some tools expensive but do
> 			exist.  Many books on language available.  Many
> 			free libraries available.  DoD standard.
> 	C++		Big, multiple versions of language, unsafe.
> 			Tools widely available.  Many books available.
> 			Most popular choice.
> 	Modula-2	No classes or inheritance.  Many books.
> 			Many implementations.  Solid, but limited.
> 	Modula-3	Limited interest - one free compiler, one book.
> 			Adds classes to Modula-2.  Less used than
> 			Modula-2.  
> 	Eiffel		Limited interest - one or two compilers, one book.
> 			Less used than Smalltalk, C++, Ada, or Modula-2.
> 	Smalltalk	Slow execution, good tools.  Multiple books
> 			available.  Clean language.  Good for experimental
> 			work.  Avoid pure-interpreted versions if speed
> 			at all important.


I didn't know that Ada and Modula-2 were object-oriented !
Then from the remaining:

C++: very successfull but unsafe, that's true, lacks a
	garbage collector. But very good environements available!
Modula-3: much less success: lacks a bit of consistency, I think
	limited interest in general (don't realy know for the
	available environment)
Smalltalk: not always that slow, excellent environment !
Eiffel: not that uninteresting: clean, powerful, I would say
	it is state of the art in strongly typed OOL. The ISE
	environment is quite decent (I heard the version 3.0 is
	even good)


Personnally, I don't like C++ much (mainly cause of it's lack of GC)
Between smalltalk and eiffel, it's a question of taste: do you like
strong static typing or prefer dynamic typing ?
I really think the smalltalk environment is excellent, much better
than what I know for eiffel, but the strictness of eiffel makes it
really nice to debug !

I prefer Eiffel, cause it's faster and I much more used to it !

The rest is question of taste !
Maybe you prefer other OOL, like Self, simula, CLOS or...
CLOS may be a good choice, but I just don't know it yet !

	Stefan Monnier

-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------
Newsgroups: comp.lang.smalltalk
From: nadja@jetsun.weitek.COM (Nadja Adolf)
Subject: Re: Is Smalltalk the language for us?
Organization: WEITEK Corporation, Sunnyvale CA
Date: Mon, 28 Sep 92 22:35:19 GMT

In article <1992Sep25.130934.186@csghsg5a.bitnet> 88600044s@csghsg5a.bitnet writes:
>
>In a topic somewhere up from here somebody said that Smalltalk is 
>not suitable for modular development (several people working on one
>project). The opposite is true: there is no tool with which you
>can do this that easily as with Smalltalk if you get Envy/Developper.

I take it you haven't seen the SGI development platform.
	
>The Envy/Developper let's several programmers work on the same image.
>To do this Envy/Developper links all the participating developpers
>over a LAN to one central repository (which is the Smalltalk image).

Yes, but one can do this very easily, and with easier version control
in almost every other language.

>I bet you won't find that for C++. There even isn't one only
>C++ implementation that has a somewhat sophisticated class hierarchy
>browser. Calling Smalltalk no better OOP language than C++ shows in
>my eyes a lack of reality. Yes, Smalltalk is slower than C/C++ but
>if you do not absolutely need that much speed Smalltalk has no
>competitor.

In other words, smalltalk works best for small, simple programs, not
complex development projects. (If it isn't small, speed does become
important...) 


Thank you for granting my point.

-- 
The Earth Pig Bourne....

nadja@node.com (prefered email address)
nadja@weitek.com
From: 871323o@dragon.acadiau.ca (Oliver Oey)
Newsgroups: comp.lang.smalltalk
Subject: SteppingOut II with Smalltalk80/Mac
Summary: Viability of running Objectworks/Smalltalk Rel.4 for Mac with SteppingO
Keywords: ppst Mac SteppingOut
Date: 1 Oct 92 05:25:14 GMT
Organization: Acadia University

Has anyone used Objectworks\Smalltalk Release 4.0 (or 4.1) for Macintosh
with SteppingOut II?

I am running ParcPlace Smalltalk on a Mac SE/30 with only the built-in
little screen and am considering investing in the package SteppingOut
II.  I am wondering if the two softwares are compatible.

If they are compatible, what is the memory requirement?  Would virtual
memory on System 7 still work?

Any comments would be appreciated.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Oliver Oey                              email: oliver.oey@acadiau.ca
Jodrey School of Computer Science
Wolfville, Nova Scotia, Canada
From: pnm@goanna.cs.rmit.oz.au (Paul Big Ears Menon)
Newsgroups: comp.lang.smalltalk
Subject: Re: Is Smalltalk the language for us?
Date: 30 Sep 92 07:31:13 GMT
Organization: RMIT Computer Science

In article <1992Sep25.231021.16406@m.cs.uiuc.edu>, johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
..
> Yes, you usually have to make a couple of design iterations to get
> good speed.  Perhaps you already made a few iterations.  I assume
> that you spend a couple of weeks spying on everything, eliminating
> bottlenecks, etc.  This is never fun, but it is what you have to do
> to make things fast.  Even so, Smalltalk on a vanilla Mac II (which is
> what I run it on) isn't very fast.  I come to the department and run
> it on a SPARC and am amazed!  Sometimes I get the feeling that
> ParcPlace doesn't care much about Macs.

I too do most of my work on a Mac (fx with heaps o' memory), but
occasionally go to the Sparc.  There is a big difference.  I'd
love to have a Sparc 2 (or even a 10!) on my desk.  Trouble
is - about 50 graduate students would lynch me!!  There's also
a big difference in price, and, once you have 50 students clamouring
away on GemStone, Smalltalk, nexpert, prolog, lisp & scheme, you're
no better off.  I also prefer to be in full control of resources
I depend upon (ie, my work platform).

Of course, if you can afford a Sparc 2 or 10 on your desk...
Where do you work???   :-)


    Paul Menon,
    Dept of Computer Science,
    Royal Melbourne Institute of Technology, 
    124 Latrobe Street,
    Melbourne 3001, 
    Victoria, Australia.

email:  pnm@goanna.cs.rmit.oz.au
PH:     +61 3 660 3209
FAX:    +61 3 662 1617
From: marten@feki.toppoint.de (Marten Feldtmann)
Newsgroups: comp.lang.smalltalk
Subject: Re: comparing object-oriented platforms
Distribution: world
Date: Sat, 03 Oct 92 20:52:05 GMT
Organization: Private OS/2 System

khaw@parcplace.com writes in article <khaw.717868356@parcplace.com>:

> >  So you can use Smalltalk for industrial applications but you are taking
> >  very big risks. Most businesses like to minimise their exposure to risk
> >  if they want to stay in business. Of course , this is an individual
> >  judgement.
> 
> Gee, I guess ParcPlace's customers, which includes large corporations,
> either are big risk takers or else they find Smalltalk to be adequately
> safe.
> 

 Indeed - very strange. Using ST is a big risk!!??? I agree with the
person from ParcPlace, that this can't be true. ParcPlace and Digitalk
are good facts against this statement.

 MF


--
Marten Feldtmann,     Kieler Str. 29,       2300 Kiel 14,    Germany
E-Mail: marten@tpki.toppoint.de, FAX possible
Xref: sparky comp.lang.smalltalk:2038 comp.object:3849 comp.lang.c++:14539
From: Ted.W.Lawson@cm.cf.ac.uk (Ted Lawson)
Newsgroups: comp.lang.smalltalk,comp.object,comp.lang.c++
Subject: Re: comparing object-oriented platforms - Please don't cross-post
Date: 5 Oct 92 17:07:18 GMT
Organization: University of Wales College of Cardiff

Please don't cross-post to comp.lang.eiffel unless you think your contribution
is relevant to that group. ( Postings on comp.lang.eiffel get mailed
automatically to user-group members and irrelevant cross-posting clutters
their mailboxes).

Many Thanks
Ted
Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
From: maniattb@cs.rpi.edu (Bill Maniatty)
Subject: Re: comparing object-oriented platforms
Date: Tue, 29 Sep 1992 02:52:35 GMT

In article <1992Sep29.011914.10172@actrix.gen.nz>, Des.Kenny@bbs.actrix.gen.nz writes:
|> In article <+s_p3w=.nagle@netcom.com> nagle@netcom.com (John Nagle) writes:
|> > Bob Hathaway <objsys@netcom.com> writes:
|> > >In article <8mgztqf@rpi.edu> maniattb@cs.rpi.edu (Bill Maniatty) writes:
|> > >>On the flip side, I'm under the impression that real time programming cannot be
|> > >>done with a Garbage Collecting language, as the garbage collection could
|> > >>happen at an arbitrary time, and cause a violation of the timing constraints.
	[Stuff Deleted]
|> Since 1976 when the first Eiffel compiler was released it has had tuneable 
|> garbage collection. The version from ISE ( the original ) allows you to turn
|> garbage collection off for time critical classes. The garbage collector in
|> ISE's version of Eiffel operates as a coroutine anyway. It is an incremental
|> garbage collector operating in small bursts rather than taking over the whole
|> system to clean the mess. The class MEMORY has features to control the
|> interval of collection. You can turn collection on or off and do partial 
|> garbage collection.
|> 
|> So you can tune the collection for real time
|> applications to when the resources are available for collection and not impact
|> time critical method operations. This is not new. It has always been there in
|> Eiffel since the first release.

This does not seem safe, (I wish this weren't true).  The whole point of garbage
collection is that when the system is out of memory, it can check the allocated
memory to see which parts of the heap are allocated but unreferenced (and
therefore garbage).

Consider the following scenario:
	Suppose that there are real time constraints and the
		user wants to control when garbage collection can and cannot
		occur.
	Now the application programmer needs to determine if and when the set of
		active jobs will use all available memory.
	This seems unreasonable, as Eiffel does its own allocation/deallocation
		stuff under the hood (that is transparently to the user).
	In that case the only alternative is for the system to detect and handle
		the exception (that is interrupt when the ``out of memory''
		condition occurs).
	This could occur at a time not anticipated by the user.
	The user has disabled the garbage collector from running at this time
		however and the system locks up.

|> Des Kenny
|> Objective Methods

Bill Maniatty
-- 
|
|	maniattb@cs.rpi.edu - in real life Bill Maniatty
|
Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
From: nadja@jetsun.weitek.COM (Nadja Adolf)
Subject: Re: comparing object-oriented platforms
Organization: WEITEK Corporation, Sunnyvale CA
Date: Sat, 3 Oct 92 01:55:35 GMT

In article <ken8Xe_00awRQ5OHYd@andrew.cmu.edu> osoelgaultier+@CMU.EDU (Stefan Monnier) writes:
>Excerpts from netnews.comp.lang.eiffel: 2-Oct-92 Re: comparing
>object-orient.. Des.Kenny@bbs.actrix.gen (2292)

>>   In ISE Eiffel 3 we still have static type checking even with an 
>>   interpreter/compiler mix. This may be more important for the quality
>>   of a system in the longer term. Rapid development of modules with
>>   no static type checking may risk type failure in production. So what
>>   is really rapid about having to fix type errors at the production stage?
>>   I am sure there are some Smalltalk developers who rarely allow type
>>   errors into production. But is it not better to let these errors be
>>   eliminated by the development tool before production? I prefer the
>>   environment to help me as much as possible with quality assurance
>>   as early as possible in the lifecycle.

>Static type checking makes it harder to develop code in limited
>time (prototype doesn't have to be bug free, nor fast, nor complete)

The prototype should at least be stable and predictable. In my experience
code that does not have strict type checking can be prototyped very
quickly. Then one can spend years trying to stabilize it, since 'free
code' bugs can be hard to isolate.

IMNHAAO, the absence of type checking does not lead to faster product 
development. The time saved in getting the prototype up is more than
counterbalanced by the time required to stabilize the product.

>What is needed is a language that permits you to write 'free code'
>(without too much verification done by the language) to start 
>fast and get a working prototype in very short time. And then
>add type constraints (etc...) to get to a 'bug-free' (grin) stable
>application.

A stable application is far from a bug free application. Unless you
have exhaustively designed regressions from the moment you began to
code, the process of debugging and correcting the program is going
to be very time consuming. If one intends to set type constraints later,
one should consider setting them initially. If one does not, then both
the regression code and the product must essentially be rewritten.

>Sure debugging is easier with static type checking, but this help
>sometimes turns out to be a hassle: it should be possible to turn
>it off (completely or partly)
>
>I'm sure this kind of Smallfel (or is it Eifftalk ?) is coming
>and will be very nice (I like to dream, you know)
>
>	Stefan
>
>-----------------------------------------------------
>-- On the average, people seem to be acting normal --
>-----------------------------------------------------


-- 
The Earth Pig Bourne....

nadja@node.com (prefered email address)
nadja@weitek.com
Newsgroups: comp.lang.smalltalk
From: peterg@netcom.com (Peter Goodall)
Subject: Re: Lex & Yacc for Smalltalk V Language 
Date: Sat, 26 Sep 92 17:02:02 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Keywords: Lex, Yacc 

ang@macsun (John Ang) writes:

>Is there a 'lex & yacc' -like tool for Smalltalk V.
>I know there is the T-gen for Objectworks but is there one for Smalltalk V.

...


Hal Hildebrand has ported T-gen to Smalltalk/VWIN 2.0. Included is 
an exception handler for Smalltalk/VWIN which is a fine thing in its own right.

I got the code from Digitalk's bulletin board. I don't know if it is
on any Internet archive.

If someone could suggest a good site, I will put it there.

As a spare-time project I am going to port these goodies to /VPM 1.4,
then 2.0 (when I can afford it).

Is anyone interested in code in ENVY Application format? Would someone from
OTI like to comment on their response to a version of the Kernel Application
being available publicly? Not forgetting that it would only be of use to 
people with ENVY licenses.

Peter Goodall -- peterg@netcom.com

P.S. -- Thomas Muhr posted some time ago, that he had proted T-gen to /VWIN
From: ken@gunshy.ocunix.on.ca (Ken Walker)
Newsgroups: comp.lang.smalltalk
Distribution: world
Subject: RE: ST/VWin 2.0 upgrade - OVERPRICED???
Organization: OTI Ottawa
Date: Tue, 29 Sep 92 22:22:33 EST


In article <2tz-AGB@engin.umich.edu>
jwh@citi.umich.edu (Jim Howe) writes:

>
> In article <1992Sep16.210551.5658@nstn.ns.ca>, bushell@fox.nstn.ns.ca (Tom Bushe
> |>
> |> Am I the only one who thinks this upgrade is grossly overpriced?  Did any
> |> of you have the same reaction I did, or are my expectations too high?
> |>
>
> I write that I would like to have run under both Windows and OS/2.
etc..
> may be better, I don't know because I haven't seen it.  With its
> new pricing, Digitalk seems to be freezing out small developers.

Why, I remember when, Smalltalk/V could be purchased for $100 at Carleton
University.  I hope their (Digitalk) student/educational discounts remove a large
chunk of the pricing scheme.

---
NewsBrowser (v0.2)
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



Newsgroups: comp.lang.smalltalk
From: andrewb@lynx.cs.washington.edu (Andrew Berg)
Subject: Re: C&P WindowsBuilder Help please!
Organization: Computer Science & Engineering Dept., Univ. of Washington, Seattle
X-Newsreader: Tin 1.1 PL5
Date: Sun, 27 Sep 92 04:54:25 GMT

Gil W. Lau (bp652@cleveland.Freenet.Edu) wrote:
: 
: The second problem isn't really a WB problem per se.  In the dialog box
: I have a TextPane.  It works fine and dandy except if you use the 
: keyboard to navigate around (*shudder*).  You can tab into the text pane
: and enter what you want, but then you can't tab out!  I've also tried
: using a TextEdit as well, but to no avail.  Anyone have any ideas?
: Thanks in advance.
: 
:   -- Gil

I don't know if this is part of the CUA standard or not.  However, some
applications which are roughly CUA complient use [CTRL+TAB] to get out
of text edit panes that would catch that keysroke.  You might try that.

The user interface structure in Windows and PM is actually rather objective.
Think of it as a [TAB] message being sent to whatever control window.  If it
doesn't do anything with it, it sends the message to it's parent.  In the
window default library, that message moves the input focus.  The text edit
control window (I think...don't quote me :)) takes a [CTRL+TAB] message and
sends its parent a [TAB] message.  At least that's how it *should* work.

IMHO.

andrew
Newsgroups: comp.lang.smalltalk