HDTenEightyP/NetNews huggingface dataset:
From: wgi@aplcomm.jhuapl.edu (W. G. Innanen)
Subject: Re: "MABuild -autobuild" with C/C++
Organization: JHU/APL
Date: Thu, 28 Jan 1993 01:20:37 GMT

In article <C1J2y5.558@netnews.jhuapl.edu>, I wrote:
> 
> I'm having difficulty in figuring out how to go about doing a 
> "MABuild -autobuild" on a system that has only C and C++ compilers.  
> I have the CD-ROM C/C++ MPW bundle (v3.2.3) with the floppy update 
> to v3.2.4, and the MacApp 3.0.1 CD-ROM bundle.  
> 
[...]

Thanks to Scott Lasley <lasleyse@wam.umd.edu> I have my answer.  It's 
all covered in the dts/mac/tools/macapp-3-0-1-bug-doc.hqx file at 
ftp.apple.com.  The bottom line is that some MAMake files have to 
be modified.  The above file gives all the details.

Thanks Scott!

Bill
--
Bill Innanen             (Internet) wgi@aplcomm.jhuapl.edu
Johns Hopkins University        Applied Physics Laboratory
#include <stdDisclaimers.h>   /* Unless otherwise noted */
From: D0989@AppleLink.Apple.COM (G-Bar Partnership, R Myers,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: When no printer is selecte
Date: 26 Jan 93 23:04:00 GMT
Organization: AppleLink Gateway

Jim et al,
 
I'd like to make a little clarification/correction to the replies about the
printer detection issue.  The 'STR ' -8192 resource doesn't contain the name of
the printer, it contains the name of the selected printer driver.  However, I
think that that is all MacApp cares about.
 
Bob
From: GILLAM.R@AppleLink.Apple.COM (Richard Gillam,GEIS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Record -> Struct
Date: 21 Jan 93 14:52:00 GMT
Organization: AppleLink Gateway

Paul--
 
Your problem here is using arrays of characters.  You probably should be able
to assign string literals to it, but you'll get C strings (null-terminated)
rather than Pascal strings.
 
What you probably want to try is creating subclasses of CString of the
appropriate sizes and using those instead.
 
Take this with a grain of salt.  I'm not really sure I can claim to know what
I'm doing.
 
--Rich Gillam
GE Information Services
From: MADA@AppleLink.Apple.COM (MADA Admin, Steve Mann,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: MacApp Job Listing
Date: 21 Jan 93 20:53:00 GMT
Organization: AppleLink Gateway

*******************************************************************************
MADA IS PROVIDING THIS LISTING STRICTLY FOR THE BENEFIT OF THE MACAPP
COMMUNITY. WE MAKE NO CLAIMS OR WARRANTIES ABOUT THE LISTING OR THE RECRUITER.
*******************************************************************************
Software engineer position in Atlanta, Georgia available immediately. Requires
at least one year experience with new systems development using MacApp. Please
contact Robert Bruner at 404/870-2300 and fax your resume to 404/870-2314.
From: BARBOSE@AppleLink.Apple.COM (Amoco Technology, Jeff Barbose,VAR)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: Defections from BedRock?
Date: 22 Jan 93 22:59:00 GMT
Organization: AppleLink Gateway

>the Mac wasn't that useful until Macs
>appeared with Lisa-level hardware: 512K and a hard drive).
 
Excuse me?
 
I bought a Mac a few weeks after their introduction (I was an undergrad at CMU,
which was an Apple Consortium school and so we got 'em early :) and could do
more with MacWrite and MacPaint in 10 minutes than I could accomplish in a
whole hour with EMACS/MINCE-plus-Scribe.
 
There WERE plusses to the fact that the original machine was a closed 128K
machine:  since resources were tight, early developers were forced to use the
toolbox whenever possible.  This set the important early precedent for the
Mac's later success:  developers played by the rules and the users came to
demand inter-app consistency.
 
Just imagine if, say, Microsoft had a relatively large application space to
play with.  Yikes! look at the Windows-like crud they're passing as Macintosh
apps now!  They practically reinvent the toolbox, not to mention the Human
Interface at every turn (if you don't believe me, try and see what percentage
of the time Word uses the Macintosh Window Manager vs. the times it rolls its
own)
 
Don't forget, Joe Average User isn't gonna wanna cope with something as baroque
(read: powerful?) as UNIX or NT.
 
Jeff
From: D4161@AppleLink.Apple.COM (Adept, John DiBiasi,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Problem Reading ETO #9
Date: 26 Jan 93 11:54:00 GMT
Organization: AppleLink Gateway

>I'm having problems reading ETO #9.  I get frequent I/O errors (-36)
>and my machine sometimes crashes when trying to read the CD.  I don't
>have any problem reading earlier ETO disks.  I'm using version 4.0.2
>of Apple's CD ROM software.
 
I've been experiencing the same problem with System 7.1
 
I recently installed ETO 9 onto a Quadra 700. It was unable to read a couple of
files which I manually copied later. The problem was that other files were not
copied to the hard drive correctly (which I found out when I compiled an
error-free program).
 
I have also experienced problems when using MPW 411 files from ETO 9 from
within MPW. Is it possible that E.T.O. 9 included a bumch of bad CD's?
From: D4161@AppleLink.Apple.COM (Adept, John DiBiasi,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: E.T.O. #9 media problem?
Date: 27 Jan 93 12:07:00 GMT
Organization: AppleLink Gateway

>I'm the E.T.O. Product Manager and I've seen your recent links regarding
>possible defective media. I have not had other reports of problems, but I do
>want to get to the bottom of this.
 
>I have experienced reading CDs before, but it's always been the fault of a
>misaligned or dirty CD-ROM drive. (Apple's original drive is particularly
>susceptible.)
 
There may be truth in the fact that the CD Drive is the culprit. However, I
also use the drive frequently with the Developer CD's without a problem. In
fact, I often interchange the ETO and the latest developer CD (developer notes)
and have only experienced a problem with ETO 9. Never any earlier CD's.
 
Once ETO 10 has shipped in a few weeks, I would like to see how that CD
responds. If there's still a problem then it's probably the drive, if not...
 
Any other developers experiencing problems with ETO9?
From: D4887@AppleLink.Apple.COM (Advanced Comm Eng, G G Apple,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Re:software and jets
Date: 25 Jan 93 20:21:00 GMT
Organization: AppleLink Gateway


 
----------------------------------------------------------------------------
> Perhaps the better analogy for a large software
>system would be the space shuttle, which could only rely on a relatively
>_much_
>smaller set of existing components (Remember the Challenger?).
 
    I was the systems engineer on Shuttle's NSP (Network Signal Processor)
which, inspite of its name, was entirely dedicated hardware.  Like most space
qualified systems, the Shuttle's systems were deliberately kept as simple and
non-exotic as possible, using as few component types as they could get away
with.  It is presently flying on mostly 20-year-old hardware.
    The shuttle flies with 5 main computers, any three of which must be
operational.  They only recently replaced the core storage with semiconductor
memory.  One of the five computers runs on software that was written by a
totally different company that was kept isolated from the company writing the
primary software.  That was their ultimate insurance against software bugs.
All the hardware redundancy in the world won't help if all the software says to
land off the coast of Florida or in southern California's San Gabriels instead
of on the runway.
    The key to reliable subsystems is the use of standardized, well tested,
reliable components, and then thorough testing of the subsystem itself.  The
key to system reliability is to use only such sybsystems, do system analysis,
and provide system monitoring, redundancy, and thorough testing through the
most extreme conditions possible.
 
    Frankly, I personally don't like low-level programming (although I don't
denegrate those who love it).  I don't deal with the Mac Toolboxes any more
than I have to.  Sometimes there's no choice.  We need people working at all
levels.  However, I would like to see us move into providing reliable
subsystems that can be easily configured into powerful systems.  And many new
systems do not fit the classical (if the last decade can be called "classical")
concept of applications.
    We've escaped the shackles of the main-frame hardware, but we still have
ties to the "program" or "application" mentality.  IMHO, MacApp was a great
advancement but still was a remanent of that era.  As communications systems
and personal, portable computers become increasingly intertwined, standardized
reliable subsystems are going to become increasingly important.
 
G. Gordon Apple   D4887
Advanced Communications Engineering, Inc.
Redondo Beach, CA
 
Newsgroups: comp.sys.mac.oop.macapp3
From: pnsf01dw@UMASSD.EDU (Dennis J. Wilkinson)
Subject: Re: Problem Reading ETO #9
Reply-To: pnsf01dw@UMASSD.EDU
Organization: UMASS DARTMOUTH, NO. DARTMOUTH, MA.
Date: Wed, 27 Jan 1993 17:47:19 GMT

In article <728050058.2999261@AppleLink.Apple.COM>, D4161@AppleLink.Apple.COM (Adept, John DiBiasi,PAS) writes:
>>I'm having problems reading ETO #9.  I get frequent I/O errors (-36)
>>and my machine sometimes crashes when trying to read the CD.  I don't
>>have any problem reading earlier ETO disks.  I'm using version 4.0.2
>>of Apple's CD ROM software.
> 
>I've been experiencing the same problem with System 7.1
> 

We're using the most up-to-date CDROM drivers we have, and our copy of
ETO #9 gives us repeated I/O errors (-36) as well. We first noticed the 
problem when we attempted to create masters from the 7.0 disk images on
the disk. All of the system images on our copy were unreadable by
both DiskCopy and MountImage. 

--Dennis
----------------------------------------------------
Dennis J. Wilkinson, II  (pnsf01dw@umassd.edu)
University of Massachusetts Dartmouth - Design/CS Project

The opinions reflected in this post are MINE!!!! ALL MINE!!!!!
Newsgroups: comp.sys.mac.oop.macapp3
From: Anders Wallgren <anders@verity.com>
Subject: Re: Problem Reading ETO #9
Organization: Verity
Date: Thu, 28 Jan 93 01:44:46 GMT
X-Xxmessage-Id: <A78C7AD3FD018F97@pokey.verity.com>
X-Useragent: Nuntius v1.1.1d17
X-Xxdate: Wed, 27 Jan 93 01:45:55 GMT

In article <1993Jan28.002812.15078@netcom.com> Dan King,
dank@netcom.com writes:
>When we first received it, we'd either get read errors or hang
whenever we
>accessed it...A phone call to APDA brought us a replacement within
a few days,
>but it has the same problems.

I had problems, as well, and new copies of ETO showed up here
yesterday, unsolicited.  I haven't checked them out yet.

anders
From: SEADOG@AppleLink.Apple.COM (Pharos Tech, Rick Armstrong,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Opportunities with Pharos
Date: 21 Jan 93 19:17:00 GMT
Organization: AppleLink Gateway

GROW WITH PHAROS!
 
Pharos Technologies, a leader in the customized development of Macintosh-based
software systems, continues its strong growth!  We are seeking several skilled
professionals to join Pharos' award-winning team in its Cincinnati Engineering
Centers.
 
Pharos offers:
 
o  attractive salary/benefits
o  flexible scheduling
o  participation with highly visible projects
o  involvement with progressive technologies
o  opportunity for advancement and growth
 
If you are looking to be challenged in a positive, creative environment, you
should talk to us!
 
Software Engineers-Cincinnati
APPLICATION DEVELOPERS
The successful candidates will have strong experience with C, C++ and object
programming environments for the Macintosh.  Emphasis is placed on human
interface design and object programming methods.  MacApp experience is highly
valued.  Experience with networking & connectivity, and/or client/server
environments is a big plus.
 
If you have the right skills, we should talk!  Please respond in strict
confidence with resume and salary history to:
 
Rick Armstrong
Director of Engineering
Applelink: SEADOG
 
or write
 
Human Resources
Dept: MWEN
Pharos Technologies, Inc.
4243 Hunt Road
Cincinnati, OH 45242
 
Pharos is an Equal Opportunity Employer
From: THOR@VIVALDI.PSU.EDU
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Is the _MacApp_Class_&_Met
Date: 21 Jan 93 05:01:00 GMT
Organization: AppleLink Gateway

From: Thomas Moertel <thor@vivaldi.psu.edu>
    <727584329.0052389@AppleLink.Apple.COM>
To: HARRIS.BILL@applelink.apple.com
Cc: MACAPP3TECH$@applelink.apple.com
 
Thanks for the info.  I'll call APDA and get mine in the mail right away.
Happy, happy.  Joy, joy.
 
======================================================================
Tom Moertel                 Pennsylvania State University
thor@vivaldi.psu.edu       "Them bats is smart. They use radar!"
Newsgroups: comp.sys.mac.oop.macapp3
From: pdsaffer@ing.puc.cl (pdsaffer)
Subject: How can I detect overlapping Views??
Organization: Pontificia Universidad Catolica de Chile
X-Newsreader: TIN [version 1.1 PL8]
Date: Fri, 22 Jan 1993 17:27:44 GMT

Hi,

    I'm working on an annimation application. In the main content view
of my scenario window I want to have several cast members that move
arround the screen. I need to detect collisions between these actors.
I wonder if the best solution would be to draw each of them on an independent 
subview of the main content part of my window? 
If this is so, could someone tell me if:

[1] MacApp makes it possible to change from the program
    the relative position of a view from its superView using?

[2] Can I detect from my program if two views are just about to start
    overlapping (they share an edge or a corner)?

    My application is very similar to a video-game. When you shoot a
space invader the program must somehow detect if the bullet has hit the
martian. How would the authors of "Space Invaders" have implemented this 
feature using MacApp?

				Thanks in advance,

					Paul.

P.S. Please kindly send your answers to: 

	pdsaffer@malloco.ing.puc.cl 

------------------------------------------------
Pontificia Universidad Catolica de Chile
Escuela de Ingenieria
Departamento de Ciencia de la Computacion
Centro de Informatica Educativa
------------------------------------------------
Newsgroups: comp.sys.mac.oop.macapp3
From: knee@netcom.com (Mark Lanett)
Subject: Re: Re2: C++ (was re: bedrock defe
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Thu, 28 Jan 1993 01:32:14 GMT

ALANDAIL@AppleLink.Apple.COM (Personal Software, Alan Dail,PRT) writes:

>You wouldn't have to remove features, just design them to coexist better.  For
>example, if you overload a function and then override one instance of it, all
>of the other instances get hidden.  Why not allow these featues to coexist
>instead of conflict.

The "hiding" *is* a feature, provided so C++ can warn you about covariant
relationships, on the theory that overriding one function but not its
siblings is more likely to be a logical error. You are free to provide
pass-through overrides of the siblings if it applies to your situation.

>Changing the default would improve reliability without having to impact
>performance.  All a programmer would have to do to get the performance would be
>to explicitly declare critical methods as nonvirtual.

Or use an intelligent DevEnv like Component Workshop. A lot of C++ stupidities
have more to do with the need to parse it as text and compile it without knowing
what context it's going to be used in. As we climb out of the text-based
DevEnv hole, the language will be able to evolve to take advantage of
information provided by the development environment.

>I agree that stack-based objects are usefull.  However, I don't think they are
>quite the same thing as a class and could be restricted to structs.  Doing this
>would allow class to be changed to have virtual for its default (or even
>better, have no default).

Heh, never tried resource acquisition? If MacApp had real exception handling
you'd see a LOT of stack-based classes for that purpose. It would do away
with almost all FailInfo clauses that exist in your code today. That's a
real plus.

>I don't think any of these changes would this would impact the power of C++,
>but would make it less error prone and easier to learn.

How do stack-based objects make C++ harder to learn? The only situation I
can think of is declaring one with the parenthesis for a default
constuction (i.e. "CFoo f();") which instead declares a function returning
such an object. It results in a compile-time error anyway, so all you need
is a compiler that provides an intelligent error message in that case.
From: FRED.FORSMAN@AppleLink.Apple.COM (Forsman, Fred)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Segment woes
Date: 21 Jan 93 21:30:00 GMT
Organization: AppleLink Gateway

Peter,
  Mike Lockwood's suggestion (in his "Re: Segment woes" link) could be the
source of your problem.  A simpler problem is that one of your segments has
simply gotten so big that one of its entry points (.READFROM according to the
linker error message) is more than 32K from the beginning of the segment, and
thus can't be represented in the jump table.  Going to model far would solve
the problem, but may be overkill.  If you can move some of the stuff you have
in the segment which is too big to another (or new) segment, your problem will
go away.
 
Fred Forsman
Apple Computer Inc.
From: SIGMUND@NORA.HD.UIB.NO
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: TPicture, no mPictureHit?
Date: 22 Jan 93 13:59:00 GMT
Organization: AppleLink Gateway

From: sigmund@nora.hd.uib.no
To: MACAPP3TECH$@applelink.apple.com
 
Jeff,
 
Perhaps fEnabled is FALSE?
 
        Sigmund Tveit
        Humanistisk Datasenter,
        Norway
From: ASTRO.SPUD@AppleLink.Apple.COM (Lockwood, Mike)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re3: Segment woes
Date: 26 Jan 93 17:10:00 GMT
Organization: AppleLink Gateway

Hi Nick,
 
Under model near, all routines that are referenced from other segments must be
within the first 32K.  However, the segment itself can be bigger, as long as
all routines past 32K are only referenced from that segment.  If I remember
correctly, the %_MethTables segment has all entry points for polymorphic
methods at the beginning of the segment, followed by the actual method
dispatching function.  After that, I think there are various data structures
that control how each method is dispatched.  These data structures are only
referenced by the method dispatching function on the %_Methtables segment.
Given that, it seems perfectly reasonable that your %_Methtables segment would
be bigger than 32K.  If it actually was a problem, you wouldn't be able to link
your program.
 
By the way, the reason I suspected the %_Methtables segment in the original
message was because the ".READFROM" symbol sounds like a symbol for the method
dispatching entrypoint for TObject::ReadFrom().  The actual implementation of
the method would look like "TOBJECT_READFROM".  Since you can't resegment the
%_Methtables segment, you have no choice but to go Model Far if it goes too big
(unless you want to cut down on polymorphism in your application :-).
 
However, as Fred pointed out, better segmentation should allow you to avoid
Model Far in most cases.
 
Mike Lockwood
MPW Linker Trivia Buff
From: STRATA3D@AppleLink.Apple.COM (StrataVision, Gary Bringhurst,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: MacApp Castaways & Prograp
Date: 26 Jan 93 21:48:00 GMT
Organization: AppleLink Gateway

My take on Prograph (after having used it sparingly) is that it's an incredibly
fun and stimulating environment, but that the lack of a cross platform strategy
makes it a poor choice for implementing real world applications.  I understand
that the folks at TGS are developing a strategy, which will hopefully include a
schedule and list of target platforms.  Also support for DLL's and SLM will be
very important as a mechanism for extending the environment.  Any thoughts?
 
Gary Bringhurst
Strata Inc.
 
 
P.S.  If TGS one day implements their dataflow architecture to allow
transparent support of multiple CPU's (such as multiple Radius Rockets?) we'll
have a beautiful multi-processing solution.
From: JWBAXTER@HALCYON.HALCYON.COM
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: MacApp Reference (R0195LL/
Date: 24 Jan 93 07:55:00 GMT
Organization: AppleLink Gateway

From: jwbaxter@halcyon.halcyon.com
Subject: Re: MacApp Reference (R0195LL/A)
To: CENT@U.WASHINGTON.EDU
Cc: MACAPP3TECH$@applelink.apple.com
 
>I have heard that the APDA MacApp Reference (R0195LL/A) is a very useful
>book.  Unless I'm mistaken, I believe that the book is a reference for
>MacApp 3.0;  I am using MacApp 2.01.  Would this book be of any value to
>me?
 
Bob,
   No...the MacApp 3.x reference will only confuse you if you work with
MacApp 2.0.1.  MADA published a spiral bound reference for MacApp 2.x (I
forget which x).  If you can't find it another way, let me know and I'll
send you (or, perhaps, bring it across the Sound in person...one of these
days I wouldn't mind saying "hello" in person) my copy (I don't expect to
do anything more with MA 2.x).  [I really shouldn't make promises like that
without the book in hand, but it HAS to be here somewhere.]
 
   Aside to all.  The nontechical flames recently are driving me off the
group address.  Send mail directly if you want to yell at me.  Thanks.
   --John
 
--------------
John W. Baxter   jwbaxter@halcyon.com   [BAXTER.JOHN on AppleLink, from
AppleLink only.]
From: DIGIMATCH@AppleLink.Apple.COM (3M, Ran Bedekar,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Record -> Struct
Date: 21 Jan 93 14:48:00 GMT
Organization: AppleLink Gateway

Paul,
> The problem comes when I want to write the function to return an empty one. I
> can't figure out how to make each field an empty Pascal string.
 
There are a couple ways you can deal with string assignments.  The most
"C-like" is to use strcpy or its Pascal string counterpart.  It amounts to a
call to BlockMove:
unsigned char *str = "\pSome String";
BlockMove((Ptr) str, (Ptr) (myRec)->HNo, *str + 1);
 
I've also had fair luck casting these things to CStr255 references:
(CStr255 &) *(myRec)->HNo = (const CStr255 &) "\pSome String";
 
It may not be a problem, but you'll want to be careful about the byte alignment
of items in your structure between Pascal and C.  Since you're following an odd
sized byte array with an enum, you may have problems with pad bytes, etc.
 
Regards,
Nick Nallick
From: UK0034@AppleLink.Apple.COM (Baum Peter, Uk Dev London,GB,IDV)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: EHelp with Macapp?
Date: 24 Jan 93 00:03:00 GMT
Organization: AppleLink Gateway

I recently purchased EHelp/Mac from Foundation Solutions, and am just about to
attempt to integrate into my MacApp 3.0.01 application. Can anybody give me the
benefit of their experience of doing this?
 
Peter Baum
Lateral Thoughts Ltd
 
Newsgroups: comp.sys.mac.oop.macapp3
From: ASTRO.SPUD@AppleLink.Apple.COM (Lockwood, Mike)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Segment woes
Date: 21 Jan 93 18:19:00 GMT
Organization: AppleLink Gateway

Hi Pete,
 
It could be that the segment that contains all the PascalObject method
dispatching info (the %_MethTables segment) has grown beyond 32K.  You might
check your last successful build with ResEdit to see if this segment is almost
32K.  If this is the case, you probably have no choice but to turn on Model
Far.
 
Mike Lockwood
From: RSD@AppleLink.Apple.COM (Research SW Design, D Goldman,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re3: Flame of the Week
Date: 25 Jan 93 23:50:00 GMT
Organization: AppleLink Gateway

G. Gordon --
 
My impression is that the PowerPC machines will still be called Macintoshes (at
least one line of them). In any case, even if some developers have the luxury
of migrating to a new machine, can you say "installed customer base"?
 
But if the new machines are going to be called something else, then I would be
willing to replace my request for keeping "M"="Macintosh" with making
"A"="Apple". And to not add "W" or "U" or "X" any time soon.
 
-- Dave