HDTenEightyP/NetNews huggingface dataset:
From: V0645@AppleLink.Apple.COM (Tandem, Gary Campbell,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: RAM cache /Rapid Track
Date: 6 Jan 93 04:57:00 GMT
Organization: AppleLink Gateway

Hi David,
 
I have been experimenting with Insigna Solution's Rapid Trak
ram cache/disk driver for the last two weeks to compile my large
C++ MacApp 3.0.1 appilcation.
 
It is a combination disk driver and ram cache, it must be installed
by reformatting your hard disk with their driver to operate.
 
It costs about $99 LIST, $66 mailorder US.
 
My Application takes 20 minutes to compile and link on a 20 mb
50mh 60030 Daystar.
 
The CPlus dump file is 2.8 mb,
the .SYM file is       1.7 mb, and
the application is      .8 mb
 
The size of these files have been a problem trying to use RAMDISKs and
this ram cache because they are larger than the amount of ram I have
left over in my 20mb system( LINK uses ~8-9 MB ).
 
What I used to do was use every trick in Kent's tech note and then the
following,
 
    I modified MA's build rules and dependencies move MacApp.lib to
    my RAMDISK before the LINK, and build the application's object
    on the ram disk.
 
    Also on the ramdisk were the CPlusScratch, MABUILD.temp files.
 
    After the LINK was over I duplicated the Application back to disk
    and purged MacApp.lib.
 
    I was basically trying to get the "hotest" files on a 6mb ram disk since
    I didn't have enough room to put every thing there.
 
The compile and link time for 1 file( not the entire set ) was:
 
   230 secs ( includes use a CPLUS -load file and duplicating the
              files between ram disk ).
 
With Rapid Trak set to 3.5 mb, ( which my sources just barely fit in )
and using a .5mb ram disk for the CPlusScratch file, and not running the
2.8 mb CPlus load file through Rapid Trak,
 
    the compile and link time is the same,
 
    230 secs,
 
This isn't a elapsed time improvement, but becomes an improvement when
I rebuild more than one file because they use common ".h" files and the
hit rate becomes 80-90% during the compiles.
 
But it is an overall improvement because,
 
    o   I get an improvement on more than one file rebuilt
    o   Object Master's search function ( cmd L ) runs like a bat out of hhhh
 
The drawbacks to RapidTrak are minor so far,
 
    1   It works well with my SyQuest 88
    2   And MPW
    3   And MacApp
    4   And The Debugger
 
The drawback is,
 
    1   It only allows a 4 mb ram cache ( fine with me but maybe not
            for 32 mb machines )
 
    2   I haven't tested the formatters capability to reformat
        bad tracks which non-sealed SyQuest cartidges encounter from
        time to time.
 
    I can live with those
 
    3   I had a couple of flakes with a 3 mb Rapid Track setting and doing
        a CPlus -loadc on my 2.8 mb dump file.  I finally moved the
        dump file to a drive not with a Rapid trak cache.
 
cheers,
Gary Campbell
Tandem Computers
From: LANGFORD@AppleLink.Apple.COM (Paradigm Publishing, B Langford,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Link Error with RunTime.o
Date: 11 Jan 93 06:05:00 GMT
Organization: AppleLink Gateway

Hi, my name is Jungho.
Thank you for the help on "Errors in Linking" the other day.
 
Now I have another error that I can not understand.
Please, help me.
 
Note: Currently MPW from E.T.O. 9 is employed.
 
 
   MABuildTool - v. 3.0.1 Release 6/10/92          Start: 10:38:17 PM 1/10/93
 
   Copyright Apple Computer, Inc. 1986-1992
   All Rights Reserved.
 
   AutoSaving...
   Target Folder: "RAM Disk:Keystone:.S7NmDbDmUnPeRaTeSmfCfD:"
   Making:        Skeleton.MAMake
   Compiling:     MSkeleton.cp
   warning: -d or -u option(s) will not affect code saved in dump file
   Linking:       Skeleton
   ### While reading file "Sun:MPW:Libraries:Libraries:RunTime.o"
   ### Sun:MPW:Tools:Link: Error: PC-relative edit, offset out of range. (Error
48) %__MAIN (260)
     Reference to: main in file: RAM
Disk:Keystone:.S7NmDbDmUnPeRaTeSmfCfD:MSkeleton.cp.o
   ### Sun:MPW:Tools:Link: Error: PC-relative edit, offset out of range. (Error
48) %__MAIN (260)
     Reference to: %__MAIN in file: ### Sun:MPW:Tools:Link: Bad file name or
volume name (perhaps zero-length) (OS error -37)
   ### Sun:MPW:Tools:Link: Error: Resource I/O error, # (Error 6) getting file
modification date.
   ### Sun:MPW:Tools:Link: Errors prevented normal completion.
   ### MPW Shell - Command " " was not found.
   ### MPW Shell - Execution of RAM
Disk:Keystone:.S7NmDbDmUnPeRaTeSmfCfD:Skeleton.MakeIt terminated.
   ### MPW Shell - Execution of MABuild terminated.
 
Thank you.
From: B.HABLUTZEL@AppleLink.Apple.COM (Hablutzel, Bob,CST)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re4: Takeover - QA
Date: 5 Jan 93 02:41:00 GMT
Organization: AppleLink Gateway

Dave -
 
  I agree - the problem is one that can be readily fixed by the application
developer. My point wasn't that there was really a problem with the patch, but
rather I was trying to point out that _any_ change to code could have side
effects.
 
Bob
From: B.HABLUTZEL@AppleLink.Apple.COM (Hablutzel, Bob,CST)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: Takeover - QA
Date: 4 Jan 93 15:35:00 GMT
Organization: AppleLink Gateway

Dave -
 
  To echo what Jesse has said, I can think of a scenario that might cause
problems with changing the fPrefersOutline setting of the TTEView for some
applications. Consider an application that uses a dialog box with an edit text,
initially empty, that uses Times 12 font. Times is not used anywhere else in
the application. The TEditText is set to prefer the outline font. The user
enters text in the edit text, and clicks the OK button to exit. There are no
other edit texts in the dialog; for that matter there are no other
target-eligible views in the dialog.
 
  As the application currently stands, the text for the edit text is imaged
using bitmap Times 12. However, with the change, the text will be imaged using
TrueType Times, scaled to 12 point.
  The difference is one of memory usage in the system heap. Remember, Times is
not used anywhere else in the application (and assume for argument that it is
used in no other applications). Before the patch, the memory usage in the
system heap was 7K (for the Time 12 bitmap); after the patch, it is 67K (for
the Times TrueType definition).
  It is important to note that, since the edit text is initially empty, the
TrueType font is not loaded until the user starts to enter text in the dialog.
(Check the code).
 
  Could this cause problems? Possibly. Frankly, I doubt it. The memory
difference (60K) is too small to really be a problem. The problem could easily
be fixed in this instance. Is it really an error with the patch? I would argue
that it isn't, but, and this is the important part, it is a change in the side
effects of using a TEditText.
 
  Granted, this is stretching it. But this is just off the top of my head.
Maybe it will happen, maybe not. Do you know of any way of checking without
testing the code?
 
Bob
 
 
Bob Hablutzel
Hablutzel Consulting
ALink: B.HABLUTZEL
Phone: 708 328 0130
From: PHILMONT@AppleLink.Apple.COM (Philmont SW Mill, Jesse Feiler,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Takeover - QA
Date: 4 Jan 93 14:05:00 GMT
Organization: AppleLink Gateway

Dave,
 
I beg to differ with your approach to QA. Bernadette is right in that a full
set of QA is needed for every bug fix (or set thereof).
 
You discuss a bug-fix and use phrases like "guaranteed" and "cannot possibly
cause..." Don't tempt fate.
 
Without discussing this particular bug, I can easily conjure up a number of
scenarios where this type of bug fix could cause problems. E.g., pushing the
size of a code segment up by a few bytes - just enough to cause overflows in an
application that links user code into that segment.
 
I participated in a "harmless bug fix" that inserted an extra blank in a title
string in order to correct a slight off-centering. Because the gods of software
were playful that day, this insertion of ONE BLANK (" ") in the format string
led directly to the total collapse of the major financial data entry system at
a very sensitive institution. Data entry workers who should have started keying
at 8 AM started at 2:30 PM.
 
I periodicially look at the official bug list, and -- as most people do -- I
file away MacApp.Tech$ links that look as if they may touch on bugs/solutions
that we may need in the future. We apply bug fixes if we need them (and we
usually can do them in subclasses of our own) and rely on MacApp which has been
thoroughly QA'd to remain imperfect but stable.
 
Finally, you write, "[why do all of these discussions insist that all bug work
and QA needs to be done in a vacuum???]". The answer is because the greater the
degree of separation between the coder and the tester, the more likely the
testing is to be thorough. I know of one case in which the testing staff isn't
even told what specific bug fixes are to be tested: they are to insure the
complete integrity of the new code; on a second pass, they test the specific
fixes.
 
Jesse
From: RSD@AppleLink.Apple.COM (Research SW Design, D Goldman,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Another one! (Part 2)
Date: 5 Jan 93 09:58:00 GMT
Organization: AppleLink Gateway

Just to be safe, I just checked the Bug Doc. What do you know -- the TTabber
bug is listed, with the same fix as I proposed.
 
So because I do not routinely review the Bug Doc every single time my app does
something I didn't expect, I have just reinvented a wheel.
 
This also confirms that the Bug Doc (which turns out to be MUCH shorter than I
had recalled) does indeed contain bug fixes which are officially "suggested" by
Apple, but which Apple is not making.
 
-- Dave
From: COMPONENT@AppleLink.Apple.COM (Component Software, S Ballard,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: COMPONENT SOFTWARE intos
Date: 4 Jan 93 16:22:00 GMT
Organization: AppleLink Gateway

Attn:
Attn:
SentBy: Jennifer Johnson
 
Regarding:                    COMPONENT SOFTWARE intos Component Proponent_
Component Software Corporation introduces the
 Component Proponent Program
 
We are looking for a few good Mac programmers to join our new Component
Proponent Program. Use the fastest development environment available to drive
new business for your consulting company and help us create add-on components,
tools, and sample code. We'll even help you sell your Components to other
Component Workshop(tm) developers worldwide so you can earn some money. After
all, your success is our success.
 
Here's how it works. You get
 
o a single-user license for Component Workshop at a greatly reduced price -
$495 (that's 80% off the list price of $2,495) and unlimited access to our
Bulletin Board System for technical tips, threads with other developers and
file-in's for minor bug fixes.
 
o 120 days of FREE maintenance and significant discounts off annual
maintenance contracts, training, add-on products and upgrades. (You need to
build either sample code or a Component for the BBS within 120 days to qualify
for further discounts).
 
o special access to our Bulletin Board for marketing your Components.
 
Component Workshop is the first "OBJECTS ONLY" dynamic development environment
based on C++. We take the definition of object-oriented programming seriously
and deliver maintainable, easily ported, easy to extend applications which are
built out of reusable parts. Incremental compilation, garbage collection, and
an application framwork ensure that you will develop applications faster than
ever before.
 
Component Workshop is based on C++ and uses a subset of the AT&T's 2.1 C++
standard. You may give up some C++ syntax, but you get back your weekends and
will earn a reputation as someone who delivers NEW APPLICATIONS early -
instead of promises for next year.
 
If you'd like to rapidly grow your business and make a little cash building
reusable Components, join us NOW and start using the most talked about new
development environment available. Call us today at 617/862-9700 and say "I
want to be a Component Proponent!" three times fast.
 
Please note:  COMPONENT WORKSHOP requires a Macintosh IIci or better with a
MC68030 or x040 processor running at 33MHz, System 7, a M68881 floating point
coprocessor, at least 25 Mbytes of hard disk space and 16 Mbytes of physical
memory (20 Mbytes are recommended) and MPW C(tm) for development.
 
These prices are valid in the U.S. only and do not include shipping charges.
From: MARX.PETER@AppleLink.Apple.COM (Marx, Peter,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: ETO-expensive,toothless,obsele
Date: 10 Jan 93 19:06:00 GMT
Organization: AppleLink Gateway

ETO - Expensive, Toothless, and Obselete?
 
I'm a big fan of ETO, but I must agree with Craig Steele from down the street.
Why bother renewing?
 
I can't figure out what's on disc no. 10 - there certainly seems to have been
no progress with MacApp (after all, known to be dead), with C++ (it is being
replaced), or with MPW (dying.) Maybe I need an update to SADE, a product I've
never used? not!
 
If anyone knows of something on ETO that is worth re-subscribing to, please let
me know. I haven't seen much in the way of wonderful development tools coming
out for the Mac in quite a while. I don't have a lot of faith in Bedrock and
don't see why the Macintosh community would at this point. I would love for
Symantec and Apple to prove me wrong, but it seems that their attentions are
being directed at other things (fonts, pc exchange cdevs, etc.)
 
Peter Marx
UCLA Medicine
From: GER.XSE0158@AppleLink.Apple.COM (Bergmann+Partner,DE,IDV)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Draw (double)????
Date: 11 Jan 93 17:13:00 GMT
Organization: AppleLink Gateway

Hello Bill,
 
You wrote:
 
>     I'm tring to write a (double) into a view for display. Since NumToString
> does only Integer conversion, I've tried the C function ecvt() which crashes
> hard.
 
Unless I can see your code, I will not be able to tell why your code crashes.
But it can be done easily:
 
I do not know in what view you wanted to draw the double. In a simple case I
would use sprintf() to print it in a c-string and the put it into a TStaticText
(which works fine with the CStr255-Constructors):
 
char    buffer [32];    // should be enough
sprintf (buffer,"%Lf",myDouble);
aStaticText -> SetText(buffer,kRedraw);
 
If you want to care about international numbering you should use FormatX2Str().
I Implemented a class TExtendedText which works quite similar to TNumberText
(but has been used only once until now). Mail me if you are interested in
the sources.
 
    Klaus Heck
From: PHILMONT@AppleLink.Apple.COM (Philmont SW Mill, Jesse Feiler,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: more ETO griping...
Date: 11 Jan 93 14:36:00 GMT
Organization: AppleLink Gateway

Peter,
 
You've hit the nail on the head ("why doesn't Apple put EVERYTHING..."). Our
particular fear is that Apple will announce that Bedrock and/or new compilers
and the rumored new linker are part of a different development suite and will
be sold separately or will be distributed in a different ETO package requiring
a separate subscription.
 
Although we know Apple doesn't want to pre-announce products, a little
arithmetic indicates that the original and most loyal ETO subscribers either
have just had their subscriptions lapse (or renew) or are about to with #10. We
need some information from Apple on this. (Hello out there?) Many of us are
actually trying to work within budgets. If ETO will not bring us Bedrock, then
we at PSM are going to keep the cash aside either for a direct purchase of
Bedrock or for Component Workshop. Surely we aren't the only people trying to
make this choice?
 
Jesse
Newsgroups: comp.sys.mac.oop.misc
Distribution: world
From: ksand@apple.com (Kent Sandvik)
Organization: Odyssey Ultraware, Inc
Date: Thu, 31 Dec 1992 04:45:56 CDT
Subject: Re: Learning App Frameworks (was Re: THINK Class Library learning..)

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

Cheers,
Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.		
"Don't just do something!  Stand there!"  -- Mystery Science Theater 3000


------ Internet Message Header Follows ------
Path:
wupost!csus.edu!netcom.com!netcomsv!apple!goofy!mumbo.apple.com!gallant.apple.com!wintermute.apple.com!user
From: ksand@apple.com (Kent Sandvik )
Newsgroups: comp.sys.mac.oop.misc
Subject: Re: Learning App Frameworks (was Re: THINK Class Library learning..)
Date: 30 Dec 92 18:35:35 GMT
<1992Dec3.064131.23364@reed.edu>
<Dec.3.13.57.31.1992.18090@gandalf.rutgers.edu>
<1992Dec4.081456.13906@reed.edu> <1992Dec29.213057.14290@news.mentorg.com>
<6606.2b41845f@hayes.com>
Followup-To: comp.sys.mac.oop.misc
Organization: (Evil Eye Creature from Mars, Inc.)


Xref: sparky comp.sys.mac.oop.misc:156 comp.sys.mac.programmer:20597
Newsgroups: comp.sys.mac.oop.misc,comp.sys.mac.programmer
Distribution: world
From: ksand@apple.com (Kent Sandvik)
Organization: Odyssey Ultraware, Inc
Date: Tue, 22 Dec 1992 05:33:27 CDT
Subject: Re: Summary: I'm faint! I just saw the price for MPW!

In article <lsr-181292192918@lsr.taligent.com>, lsr@taligent.com (Larry
Rosenstein) wrote:
> My point was that even if the FSF wasn't boycotting Apple, they would not
> be doing ports to the Mac.  The FSF doesn't actively support all platforms;
> some are only "passively supported".

This is my own opinion -- not Apple's (!) -- but I'm personally quite
skeptical about software moral values, copylefts and selection of some
companies
that are somewhat 'better' than others. As a good example look what 
Sun tried to do by providing money to a small company so this smaller
one could sue OSF. Double moral, dear Watson, double moral. In other
words we should not be so naive concerning company politics, even better
just leave that out from the personal 'change the world' attitude.

Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.		
"Don't just do something!  Stand there!"  -- Mystery Science Theater 3000


------ Internet Message Header Follows ------
Newsgroups: comp.sys.mac.oop.misc,comp.sys.mac.programmer
From: ksand@apple.com (Kent Sandvik )
Subject: Re: Summary: I'm faint! I just saw the price for MPW!
Date: Sat, 19 Dec 1992 22:25:17 GMT
<1992Dec11.155851.14862@walter.cray.com> <1gb6n9INNpmk@terminator.rs.itd.umich.edu>
<1992Dec16.132756.20642@gssec.bt.co.uk> <lsr-181292122440@lsr.taligent.com>
<1992Dec19.000239.11451@dcs.qmw.ac.uk> <lsr-181292192918@lsr.taligent.com>
Organization: (Evil Eye Creature from Mars, Inc.)
Followup-To: comp.sys.mac.oop.misc,comp.sys.mac.programmer
From: sashhr@graves.unx.sas.com (Heman Robinson)
Newsgroups: comp.sys.mac.oop.misc
Subject: Which C++ is best on Mac?
Date: 9 Jan 93 19:01:18 GMT
Organization: SAS Institute Inc.
Originator: sashhr@graves.unx.sas.com


I'm looking for a C++ compiler/debugger to run on my Mac II.
So far I have heard:

   Zortech's compiler is buggy, and they have been bought out
   by Symantec.

   Symantec's ThinkC is a subset of C++, but now they have 
   bought out Zortech perhaps there will be a ThinkC++ soon.

   Apple's MPW costs $600, and may or may not include C++.

Can anyone enlighten me further?  Thanks much...




-- 
Heman Robinson        sashhr@unx.sas.com        SAS/INSIGHT(r) Software
       "One must stop before one is finished." -- Barbara Tuchman
Xref: sparky comp.sys.mac.oop.misc:173 comp.sys.mac.programmer:20604
Newsgroups: comp.sys.mac.oop.misc,comp.sys.mac.programmer
Distribution: world
From: jsuker@orion.oac.uci.edu (Johnathon Suker)
Organization: Odyssey Ultraware, Inc
Date: Wed, 23 Dec 1992 12:08:59 CDT
Subject: Re: Summary: I'm faint! I just saw the price for MPW!

ksand@apple.com (Kent Sandvik ) writes:

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

>statement does not clearly state that the snippets also belong to this 
>category, but this is the case as well. So I will talk with the people
>downstairs making sure that this is also included to the license in 
>future.

Kent,

	I came onto this thread rather late, but I am writing a program
that uses some code from one of the TechNotes (it is a generic socket
listener) also from TechNote 18.  When done I wanted to release this 
program as shareware/freeware (I havent decided yet).  Am I to assume
I now cannot?  I am modifying the code for my purposes but you can only
write an event loop so many ways and so I used the TechNote code.  Do
I now have to re-write all of it or just give Apple credit (which I 
was going to do anyway)?

				Thanks for the information in advance,
						Johnathon

--
Johnathon Suker                   | If I were human I believe the proper
University of California, Irvine  | response would be, 'Go To Hell'. If I 
Univeristy Library                | were human.
jlsuker@UCI.EDU                   |             Spock - ST:TUC


------ Internet Message Header Follows ------
From: jsuker@orion.oac.uci.edu (Johnathon Suker)
Subject: Re: Summary: I'm faint! I just saw the price for MPW!
Newsgroups: comp.sys.mac.oop.misc,comp.sys.mac.programmer
<1992Dec11.155851.14862@walter.cray.com>  
<1gb6n9INNpmk@terminator.rs.itd.umich.edu>  
<1992Dec16.132756.20642@gssec.bt.co.uk> <lsr-181292122440@lsr.taligent.com>  
<1992Dec19.000239.1145 <ksand-221292163512@wintermute.apple.com>
Date: 23 Dec 92 17:25:45 GMT
Newsgroups: comp.sys.mac.oop.misc
Distribution: world
From: howard@netcom.com (Howard Berkey)
Organization: Odyssey Ultraware, Inc
Date: Tue, 22 Dec 1992 05:39:57 CDT
Subject: Re: I'm faint! I just saw the price for MPW!

In article <wallich.724643856@pepper> wallich@ncd.com (Ken Wallich) writes:
>edw@distant.uucp (Ed Watkeys) writes:
>
>At least the prices aren't up their with the NeXT box (yet)...

Actually, it is pretty damn close.  Plus you get a hell of a lot more
with the NeXT.  And the development environment pretty much kicks butt
on MPW.

Used prices for mono NeXTstations (25 MHz 68040) w/ 8MB RAM and 105 MB
HD with the 17" 4-bit megapixel monitor are averaging about $2700.
This comes with a better development environment than you can currently buy
for the macintosh. 

That's a much better deal than a quadra (even a used one).

New prices run a little higher than a quadra w/ monitor.

(as a side note, Sun is offering SPARC classics now for $4000 new [but
you have to buy 12 ;-) ] or I believe around $8000 new.  It wouldn't
be too hard to dump $8-10k into a Quadra system and it would be very 
S L O W compared to the SPARC.  Plus there's better compilers
available etc...)

Of course I can't afford any of these so this is all just machine-envy
:)

-Howard

-- 
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Howard Berkey                       			   howard@netcom.com
			  WARNING: Intel Inside
... .. ...   ... .. ...   ... .. ...    ... .. ...   ... .. ...   ... .. ...


------ Internet Message Header Follows ------
Newsgroups: comp.sys.mac.oop.misc
From: howard@netcom.com (Howard Berkey)
Subject: Re: I'm faint! I just saw the price for MPW!
Organization: Netcom Online Communications Services (408-241-9760 login:
guest)
Date: Fri, 18 Dec 1992 20:04:19 GMT