HDTenEightyP/NetNews huggingface dataset:
From: bcohen@scherzo.mentorg.com (Speaker-to-Managers)
Subject: Re: Learning App Frameworks (was Re: THINK Class Library learning..)
Date: Wed, 30 Dec 1992 20:48:47 GMT
Organization: ElectroPolitical Engineering Enterprises
Keywords: 
Followup-To: 

In article <6606.2b41845f@hayes.com>, bcoleman@hayes.com (Bill Coleman) writes:
|> ...
|> Indeed. And, in the case of MacApp and the TCL, the developers of these
|> frameworks have only shipped half of the product. They have shipped the parts,
|> but when it comes to delivering the description -- what little they have
|> shipped is woefully inadequate. 

*SIGH*, all too true.  I've started using TCL recently, after several years
of using InterViews in the Unix world, and two projects (for my day job) devoted to
created object frameworks for other people.  So I can say that I have
sinned as much as been sinned against in this respect: the first time I
tried delivering a framework the documentation was inadequate.  But I'm
learning.

|> ...
|> Part of the problem is the character of the implementation languages used 
|> for these frameworks -- it isn't entirely the fault of the
|> developers.

And the culture which has arisen around the programming language:
there's an old tradition in old-line C shops of "there's nothing you
can't understand by reading the source code; the man pages are for
people with short memories."

|> 
|> Until documentation and languages appear that are conducive to producing
|> concise frameworks, we'll have to continue to struggle along with wading
|> through the source code.
|> 

And until there are generally available tools for easily producing and using
documentation (and no, I DON'T mean automatic man page generators!)
about programs, only the strongly motivated will produce or use it.
Problem with that is the users tend to be more motivated than the producers.

|> ...
|> Sounds like you are suggesting people build frameworks in Eiffel, which
|> has formal mechanisms for defining pre and post conditions for all routines.
|> 
|> Too bad there isn't such an Eiffel implementation for the Mac.

Eiffel is one way, though I'm not advocating it strongly.  There are ways to
annotate existing languages like C++ with assertions, documentation, and
so on.  See, for instance, A++, or some of Doug Lea's papers on
annotated c++.  (Another *SIGH*: If Doug didn't habitually load himself
down with 2-3 full-time jobs, or if some intelligent software company
were to give him a big salary just to work on the annotation project, he
might have gotten it done by now, and all this angst would be academic).

It's really amazing how much you can do with a preprocessor in front of
a language translator.  Annotations are one example; the addition of
signatures to clean up the C++ type system (Vince Russo, et. al. at
Purdue), the old COOL template front-end which gave us C++ parameterized
types back in the 2.0 days, are others.
------------------------------------------------------------------------
Bruce Cohen, Mentor Graphics Corpooration | email: Bruce_Cohen@mentorg.com
8005 SW Boeckman Road                     | phone: (503)685-1808
Wilsonville, OR 97070-7777                |
From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.oop.misc
Subject: Re: Learning App Frameworks (was Re: THINK Class Library learning..)
Date: 2 Jan 93 12:57:09 EDT
Followup-To: rmute.apple.com>

Organization: Hayes Microcomputer Products, Norcross, GA

In article <ksand-301292103135@wintermute.apple.com>, ksand@apple.com (Kent Sandvik ) writes:
> In article <6606.2b41845f@hayes.com>, bcoleman@hayes.com (Bill Coleman)
> wrote:
>> Sounds like you are suggesting people build frameworks in Eiffel, which
>> has formal mechanisms for defining pre and post conditions for all routines.
>> Too bad there isn't such an Eiffel implementation for the Mac.
> 
> It's not that hard to add pre- and post-conditions with methods using 
> assertions. I have my own ASSERT macro package that is conditionally
> compiled in during debug mode, and it certainly catches a lot of errors
> I would not be aware of otherwise. It's a matter of strict programming
> to add in an additional line after each error producing statement. And 
> yes indeed a language such as Eiffel helps, but it does not imply that
> you can't do the same thing using for instance macros in C/C++.

Kent,

Back on an old DOS product that since was developed by another team, I 
wrote up some C++ code that did exactly this. I found it had several limitations
that Eiffel did not.

First, the C++ macros were part of the implementation, not part of the
interface. Eiffel correctly places the pre- and post-conditions in the
interface -- since they are just as much of the specficiation of the
routines as anything else. I ended up having to move the implementation
assertions as comments in the header -- it was a lot of work to keep it up
to date and accurate.

Second, you have to rigorously add all  the macros to your code. If you 
forget one, even though you have a comment in the header -- it won't be
checked. (The assertions are more code, and hence more to debug)

Third, C++ doesn't have the recovery mechanism the Eiffel does, so
without a LOT of rigorous work in every routine, your application can only
bomb on an assertion error. (Which suffices for lots of simple conditions)

Last, it has all the appearance of a kludge. It is kinda hard to program
Eiffel in C++. It would be so much easier to program Eiffel in Eiffel.

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.
From: speno@clam.rutgers.edu (John P. Speno)
Newsgroups: comp.sys.mac.oop.misc
Subject: TCL questions
Date: 23 Dec 92 18:32:22 GMT
Distribution: comp.sys.mac.oop.misc
Organization: Rutgers University -- Camden, New Jersey.


Greetings! I'm about to start developing a TCL application, something
I've never done before, so I figured I'd start asking questions on how
to implement some of my ideas. The heart of the program allows the
user to drag and/or position several visual objects(panes) around in a
user defined area. When the objects change position, a graph which
uses their locations must be updated to reflect their new positions. 
Here are some questions:

1) How do I make an object dragable with a gray outline? CMouseTask
looks promising because I'd like to be able to use Undo.
2) Once an object is moved, how should this change be communicated to
the graph which must be updated? I suppose a broadcastChange is in
order. 
3) I'd like to put the graph and the dragging area in one window.
Should all the various pieces be separate panes?

I'd appreciate all help and suggestions greatly. Since this project is
what I'll be doing during winter break, I'll have plenty of questions
for the list. If you want more detailed information about the project,
please Email me directly, I'd love to discuss it. Thanks!

--
=A==l===================+==l===============ro=======a================d=====s= 
John P. Speno		| Disclaimer: Everything I say is my own propaganda.
Trumps R' Us		|  Rutgers Camden, Computer Science Club Secretary. 
speno@clam.rutgers.edu	|		Resistance Is Futile.
==le===========a=======d+=====t=o====Am=========b===========e============r=== 
Newsgroups: comp.sys.mac.oop.misc
From: lsr@taligent.com (Larry Rosenstein)
Subject: Re: Summary: I'm faint! I just saw the price for MPW!
Followup-To: comp.sys.mac.oop.misc,comp.sys.mac.programmer
Organization: Taligent, Inc.
Date: Tue, 22 Dec 1992 19:03:03 GMT

In article <1992Dec22.070755.13175@netcom.com>, nagle@netcom.com (John
Nagle) wrote:
> 
> and in order to protect them you may not decompile, reverse engineer, 
> disassemble, or otherwise reduce the Software to a human-perceivable form.

I don't have any CDs around to see what the situation is today.  I do know
that MacApp is not on the Developer CD.  And the versions of the MacApp
license that I've seen doesn't place any of those restrictions.

Also, all the Tech Notes and DTS Sample Code I've seen has carried an
explict statement that you can use this and distribute it, provided you do
not sell it.

Larry Rosenstein
Taligent, Inc.

lsr@taligent.com
From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.oop.misc
Subject: Re: Learning App Frameworks (was Re: THINK Class Library learning..)
Date: 30 Dec 92 11:13:35 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <1992Dec29.213057.14290@news.mentorg.com>, bcohen@scherzo.NoSubdomain.NoDomain (Bruce Cohen) writes:
> Damn! He hit one of my hot buttons!

You too!

> In fact, you can (or at least should be able to) understand a framework
> without knowing the details of the implementation, or even the syntax of
> the implementing language.  

You are correct. At least, in theory. Unfortunately....

> A framework is an organization of parts and
> a description of how they work together; 

Indeed. And, in the case of MacApp and the TCL, the developers of these
frameworks have only shipped half of the product. They have shipped the parts,
but when it comes to delivering the description -- what little they have
shipped is woefully inadequate. 

Take for example the TCL. The shipped a significant number of classes with
the TCL 1.1 for which there is next to no documentation. Sure, there's a
little read.me file that has a brief description of the classes. But no one
at Symantec has bothered to write a description equal to the other classes
that appear in the manual.

Part of the problem is the character of the implementation languages used 
for these frameworks -- it isn't entirely the fault of the developers.

Until documentation and languages appear that are conducive to producing
concise frameworks, we'll have to continue to struggle along with wading
through the source code.

> In many situations all
> you really *need* (as opoposed to what you might want to have) to write
> an overriding method in a subclass is the signature of the method and
> a set of assertions which describe the pre- and post-conditions for the
> method.  Sure it's easier if you have some code to look at and maybe
> reuse, but you could do without that.

Sounds like you are suggesting people build frameworks in Eiffel, which
has formal mechanisms for defining pre and post conditions for all routines.

Too bad there isn't such an Eiffel implementation for the Mac.

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.

Newsgroups: comp.sys.mac.oop.misc
From: soubyran@ERE.UMontreal.CA (Soubyran Richard)
Newsgroups: comp.sys.mac.oop.misc
Subject: Performance tests...
Date: 25 Dec 92 18:02:42 GMT
Organization: Universite de Montreal


Hello!

We are December 25th... and here I am on my computer... forgetting
about wife and kids... but I think it is important for me!!!

I have read in the THINK Pascal oop Manual (page 24) that oop is
not really suited for highly algorithmic applications... It is not
suited for computational programs... Is there anyone that could
post performance tests comparing oop pascal and procedural pascal
for a (moderated) highly computational program? What about C
compared to Pascal? What about oop C compared to oop Pascal?

I thank you all in advance for the answers and I wish you ALL a
Merry XMas and a great new Year with alll the best you want!

Richard Soubyran
soubyran@alize.ere.umontreal.ca
Xref: sparky comp.sys.mac:574 comp.sys.hp:14440
From: bt@irfu.se (Bo Thide')
Newsgroups: comp.sys.mac,comp.sys.hp
Subject: Re: Unix Xdump (xwd) to Mac Converter
Date: 30 Dec 92 14:43:42 GMT
Organization: Swedish Institute of Space Physics, Uppsala, Sweden

In article <1992Dec30.042832.7932@micor.ocunix.on.ca> pbrowne@micor.ocunix.on.ca (Pat Browne) writes:
>Greetings
>
>We require  a procedure (or program ) that will allow us to convert a file
>produced by an X-Window "xwd" command (on an HP-9000) platform to "pict"
>format such that it can be used by any Macintosh program. This is being used
>to prepare a user manual which requries snapshots of the various windows used
>by the application.
>Any code or information would be appreciated.
>Thanks in advance
>
>V. Adomaitis/P. Browne
>
>-----------------------------------------------------------------------------
>pbrowne (Pat Browne)
>pbrowne@micor.ocunix.on.ca
>
>Ottawa Ontario, Canada
>-- 
>-----------------------------------------------------------------------------
>pbrowne (Pat Browne)
>pbrowne@micor.ocunix.on.ca
>

Try 'xwdtopnm <filenam> | ppmtopict'.  From the pbmplus package
available at an archive near you.

Bo
-- 
   ^   Bo Thide'----------------------------------------------Science Director
  |I|        Swedish Institute of Space Physics, S-755 91 Uppsala, Sweden
  |R|    Phone: (+46) 18-303671.  Fax: (+46) 18-403100.  IP: 130.238.30.23
 /|F|\          INTERNET: bt@irfu.se      UUCP: ...!mcvax!sunic!irfu!bt  
 ~~U~~ ----------------------------------------------------------------sm5dfw-
From: Wayne_Wands@maccomw.uucp
Newsgroups: comp.sys.mac.hardware
Subject: Re: HELP!!!  Drive problems, System CRASHES!!
Date: 30 Dec 92 12:45:20 GMT

I had a very similar problem with a Quantum LPS120 in my SE/30. I had been
using 6.0.5 on the original 40MB and the new 120 had 7.0.1/TU on it so I
figured that it was time to upgrade to Sys 7. After installing the software
and running for about 30 min, Word crashed with a bad F line and it was
downhill after that. I rebuilt the desktop, reinstalled the system, ran
Norton, Mac Tools and Snooper which all said everything was ok but the crashes
continued. It was not an INIT problem since I could not keep it running long
enough to install any. I reformatted the drive with the ETC Utility (Mac&More)
which came with it, APS Power Tools and SilverLining and the crashes
continued. I booted from a Syquest, formatted the drive again and dragged a
known-to-be-working system folder to it and when I rebooted, the Finder
crashed with a bad F line!!!. I was sure that I had fried the Roms or
something but tried reformatting again and using 6.0.5 just to see what would
happen. It works perfectly???!!! I have no idea what can be causing this.
Perhaps it could be some bogus version of the Roms or something on the disk
which somehow survives the repeated formats. I dunno.
Good Luck and let me know if you find a solution.
DrueW@aol.com
***************************************************************************
This message was created on MCW BBS a jointly supported by
New Orleans Mac User Group & National Home & School User Group
user@maccomw.uucp        The views expressed in this posting those of the individual author only.
***************************************************************************
From: craparotta@frside.enet.dec.com (Joe Craparotta)
Newsgroups: comp.sys.mac.hardware
Subject: Quadra 800
Date: 24 Dec 92 19:07:38 GMT
Organization: Digital Equipment Corporation

Does anyone know if Apple is going to offer an upgrade path from a Q700 to 

new Q800??? I really hope so...

Joe Craparotta	Craparotta@level.dec.com
		--or-- ...!decwrl!level.dec.com!craparotta
		--or-- craparotta%level.dec@decwrl.dec.com

discalimer: The above are my Personal views and do NOT represent those of my 
EMPLOYER.. They don't listen to me anyway.. :-))
From: ray@netcom.com (Ray Fischer)
Newsgroups: comp.sys.mac.hardware
Subject: Re: Crystal Upgrades
Date: 2 Jan 93 23:01:40 GMT
Distribution: usa
Organization: Netcom. San Jose, California

vporguen@unlinfo.unl.edu (victor porguen) writes ...
>ray@netcom.com (Ray Fischer) writes:
>
>>jek5036@ultb.isc.rit.edu (J.E. King) writes ...
>>>Lastly: Can someone with a good working knowledge of the Classic II logic
>>>board explain why it has a 16-bit RAM bus path (effectively making it an SX)?
>
>>Simple.  Price.  The Classic II is a cheap computer for a reason.
>>Computer manufacturers don't just charge arbitrary amounts of money
>>for computers.  Generally, the faster a computer is, the more
>>expensive it is to design and manufacture.
>
>Computer manufacturers, like all vendors, generally try to charge 
>whatever the market will bear. THAT is the deciding factor.

Computers that cost more to make than they can be sold for don't last
on the market for very long.  Apple needed a cheap, entry-level
Macintosh for some parts of the market.  The Classic II is it.

>>2) No.  Going from a 16 bit bus to a 32 bit bus means adding
>>   components, traces, SIMM sockets, and other such hardware which
>>   means a) redesigning the computer, and b) rebuilding the computer.
>
>You might try explaining this philosophy to Intel, who makes a
>CPU called the 80386 (32-bit) and sells it for a (high) price.
>They then take this chip, subject it to an additional operation
>to burn out or disable half of its bus, convert it into what they
>call the "80386SX" and then sell this costlier-to-produce chip
>for a much lower price.

"Chips" are not "computers".  And I very much doubt your scenario.
Do you work for Intel?

-- 
Ray Fischer                   "Convictions are more dangerous enemies of truth
ray@netcom.com                 than lies."  -- Friedrich Nietszsche
Newsgroups: comp.sys.mac.hardware
From: gurman@umbra.gsfc.nasa.gov (Joseph B. Gurman)
Subject: Toasted Mac Portable?
Keywords: Portable, battery, boot problem
Organization: Goddard Space Flight Center
Date: Mon, 21 Dec 1992 14:49:19 GMT

    If anyone out there still has a Luggable, er, Portable, have you
seen this problem:

    Initial "ping" sounds after depressing space bar, cursor arrow
appears in upper left hand corner of screen, then, instead of happy (or
sad) Mac icon appearing, either (i) screen darkens, brightens, dims, and
nothing more happens, or (ii) screen darkens, three somber tones sound,
screen brightens a little, screen darkens again, then a brighter bar
about 15-20 pixels wide appears 2/3 of the way down and flickers. Once,
it even gave a sad Mac, but so briefly I couldn't take down the error
codes.
    Is this just the behavior to be expected from a battery so far gone
it won't recharge, or is there another likely explanation? (The Portable
was connected to AC power at the time.)
    Thanks for any ideas,
						Joe Gurman
--
J.B. Gurman / Solar Physics Branch / NASA Goddard Space Flight Center /
Greenbelt MD 20771 USA / gurman@uvsp.gsfc.nasa.gov
| Federal employees are prohibited from holding opinions under the Hatch Act.|
| Therefore, any opinions expressed herein are somebody else's.              |
From: Kirk.Jackson@f175.n2240.z1.ieee.org (Kirk Jackson)
Newsgroups: comp.sys.mac.hardware
Subject: Apple video boards
Date: 26 Dec 92 00:18:13 GMT
Organization: FidoNet node 1:2240/175 - The Associati, Grand Blanc MI

I need information on to Apple video boards I have.  The first board came with 
my IIfx and appears to be the standard 8bit color board.  What has me puzzled
though is that it has what appear to be to Simm memory holders on it.  What I
need to know is if this is a memory holder what goes in it and why?(additional
colors or more speed, etc.?)  The pictures that I have seen of other apple
display cards do not include these holders.  The second board was purchased
new if a 8.24 standard board.  My question regarding it is if the first board
is really expandable with additional memory is there a need to have the 8.24
board.  One last fly in the ointment is that a wholesalers catalog shows that
Apple list a 2meg upgrade for the 8.24 GC for about $300.  Is it possible that 
the 1st card is a 8.24 gc card with the 2megs of memory removed which is
making it display in 8bit mode.  I apologize for my lenght but I am new to the 
Apple computer and I have no local source of Apple wisdom.  Please either
reply here or via E-mail.  Thanks, Kirk Jackson.





--  
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 Kirk Jackson - Internet: Kirk.Jackson@f175.n2240.z1.ieee.org
Newsgroups: comp.sys.mac.hardware
From: thf28310@uxa.cso.uiuc.edu (Todd)
Subject: 14.4k modems--feedback needed
Organization: University of Illinois at Urbana
Date: Fri, 25 Dec 1992 07:59:00 GMT



I'm in the market for a 14.4K v.42bis modem.  I'm looking at
Zoom, Practical Peripherials, Logicode, and Supra.

Any one have any comments about any of these?  I want 14.4k data
transfer and fax would be a bonus.

Thanks,

-todd
thf28310@uxa.cso.uiuc.edu
From: gnelson@gandalf.rutgers.edu (Gregory J. Nelson)
Newsgroups: comp.sys.mac.hardware
Subject: power supply for SE
Keywords: SE, Power Supply
Date: 27 Dec 92 03:32:26 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

I've got a Macintosh SE with a very dead power supply.  I think the rest
of the analog board is fine, so I want to start by just replacing the main
supply itself.  Where is the best (read cheapest reliable) place to
purchase said power supply (the original was a Sony).  Are there third
party supplies available that are more durable?  It would be a bonus if
the supplier accepted purchase orders as this is for a university 
organization.  Thanks for any pointers.

Gregory J. Nelson
gnelson@gandalf.rutgers.edu
Newsgroups: comp.sys.mac.hardware
From: jmunkki@vipunen.hut.fi (Juri Munkki)
Subject: Re: Apple's product line: ideas for the future...
Reply-To: jmunkki@vipunen.hut.fi (Juri Munkki)
Organization: Helsinki University of Technology
Date: Mon, 21 Dec 1992 17:19:17 GMT

In article <1992Dec20.021634.9706@ac.dal.ca> seanmcd@ac.dal.ca writes:
>(4) Powerbook; option of passive b&w (low end); passive grey; active grey; 
>active colour; option for 16Mhz (low end, good for road machine); 25mhz;
>33mhz; 40Mhz 68030 (if they can do it) + FPU for each; video out options
>of: none; 13" 8 bit; 16" 16 bit

I don't see any point in offering a 1-bit LCD model. The video interface
for that machine is not significantly cheaper than the current 4 bit
interface. The VRAM needs to be bigger, but that's about it.

All PowerBook with video out support the 16" display. My PB160 does it
splendidly. The difference is that the Duo Dock (not the Duo itself) can
display 16 bit color on the 16" display. The power requirements of the 16"
display at 16 bit color is beyond the current PB power budget. Even at
8 bits per pixel, the PB should be kept running at 16Mhz to reduce heating
and conserve power. More VRAM would take more power and generate more heat.

A PB180 with a fast static RAM cache would probably run much faster than
a 40Mhz 68030. I seem to remember that the PB180 has at least 3 wait states
to RAM memory and more for ROM...

>(5) Duo: same as for (4); we need a 16Mhz duo w. a b&w screen! Why? Apple's
>talking about using these things in schools (students writing essays) and
>business (doing whatever business people do) and linking up to a central
>dock when needed. If you're trying to appeal to a market like this which is
>supposed to capitalize on price savings, a cheap (let's say $1200) duo like
>this is what is needed.

As I said, the 1 bit display is not really any cheaper than the 4 bit display.
A duo with a 16 bit data path and running at 16 or 25 Mhz would be more
interesting, although the savings are questionable there too... It's possible
that a 16Mhz duo with a 16 bit data path would be successful, but I doubt
Apple would have time to get the R&D money back before the machine was
obsolete.

Maybe you could strip out the SCSI from the cheap Duo, although since Apple
already has the serial/SCSI combo chip, they probably wouldn't gain much
from it. Mostly it would be troublesome to support.

I agree that the price has to go down a bit before students will really get
interested. Fortunately time will take care of that. There's no need to
design a lower cost version.

-- 
  Juri Munkki					       Windsurf: fast sailing
 jmunkki@hut.fi					      Macintosh: fast software
Newsgroups: comp.sys.mac.hardware