cole@sas.UUCP (Tom Cole) (04/21/89)
Okay, I am moderately knowlegeable about the Macintosh, but utterly ignorant
of MPW and MacApp. Here's the setup:
o About a year and a half ago, I purchased MPW 2.0, since
it seemed like the environment that everyone was using
to build production software, although I did (and still
do) prefer the interactivity of the Lightspeed (now THINK)
software environments, and the debugger was closer to my
idea of fun.
o I fiddled around with MPW, and decided that MacApp would
be fun, so I got MacApp 1.0 or thereabouts. Compiled the
sample programs, started to write a trivial program myself,
and got sidetracked by the demon god of employment.
o Recently, I hear that 1) MPW is really cool in 3.0, 2) if
you don't known object programming you will be left in the
dust, and 3) MPW now has symbolic debugging. So I bought
the MacApp 2.0 "interim" upgrade and the MPW 3.0 upgrade
bundled with Assembler, SADE, and Pascal. So I figure I
have the most current stuff.
Okay, you can derive from the above history that I think I have all the
tools, but have next to zero experience using them. That's what I want
to get.
So the other night I decided to resurrect all this stuff and build a hard
disk with MPW et. al. on it. MPW installs okay, and I drag the MacAPP stuff
over as per the instructions. I then attempt to build one of the samples,
the "Calc" program. Several things happen:
I get messages indicating unsafe use of object data or > 4 byte values when
compiling UMacAPP.p and its children. So I opened up MABuild (never before
seen this) and guessed that I could add Pascal options to the Pascal3Options
shell variable. So I add a -h to supress these warnings so MABuild can
continue.
Next I get messages from within a TEView module for a function(method?) named
IdentifyPoint indicating illegal function call usage (not enough parameters).
It looks like the code is trying to use the function result as a value on the
right side of the := after it has been set into the function result pseudo-
variable. So I make a new variable and always set it to the desired function
result instead of IdentifyPoint itself, and at the end set the function
result to my variable. So far so good. I can now MABuild the CALC example,
with DEBUG selected. It seems to work, though not well - I can't tell if
my changes screwed it up or there are problems with the example. I realize
here that I have lots to learn.
Finally, I tried to MABUILD with OPT and NODEBUG to make a "clean" version
of the application, just to see what the differences are. Now I get even
more of the pascal warnings about unsafe object usage, etc. At this point
I can't figure out where to suppress the warning, if indeed it is desirable
to do so.
HELP! Conclusion: I don't really know what is going on, but it sure feels
like either my software isn't as up-to-date as I think (obvious problem is
the MacApp 2.0.2 stuff) or I am confused about what I am doing. Any
suggestions? RTFM is an acceptable response, but it sure with help if
you would supply a chapter/page number in the FM to R.
Thanks for any help you can offer...
Tom Cole
SAS Institute
{anywhere}|mcnc|rti-sel|sas|colerick@Jessica.stanford.edu (Rick Wong) (04/22/89)
In article <1004@sas.UUCP> cole@sas.UUCP (Tom Cole) writes: >Okay, I am moderately knowlegeable about the Macintosh, but utterly ignorant >of MPW and MacApp. > > [several problems building MacApp deleted] > >HELP! Conclusion: I don't really know what is going on, but it sure feels >like either my software isn't as up-to-date as I think (obvious problem is >the MacApp 2.0.2 stuff) or I am confused about what I am doing. The problem is that some of your software is TOO up-to-date. It sounds like you're using MacApp 2.0b5, which was designed for MPW 3.0b1 (not 3.0) Unfortunately, 2.0b5 is the latest version available from APDA. I know the MacApp team must be really busy these days, but now that MPW 3.0 is finally making its way into the world, someone should make sure that all of Apple's other development tools are reasonably in synch with it. Come on, guys. MacApp 2.0 is going to be a great product, but you can't expect people to take you seriously when you're distributing out-of-date stuff like 2.0b5. > . . . RTFM is an acceptable response, but it sure with help if >you would supply a chapter/page number in the FM to R. Except for the introductory sections, the manual supplied with 2.0b5 is hopelessly out of date (most of it seems lifted from the 1.0 manual). >Tom Cole >SAS Institute >{anywhere}|mcnc|rti-sel|sas|cole Rick Wong Courseware Authoring Tools Project, Stanford University rick@jessica.stanford.edu
keith@Apple.COM (Keith Rollin) (04/23/89)
In article <1004@sas.UUCP> cole@sas.UUCP (Tom Cole) writes: >Okay, I am moderately knowlegeable about the Macintosh, but utterly ignorant >of MPW and MacApp. Here's the setup: > > [ List of trials and tribulations deleted ] > >HELP! Conclusion: I don't really know what is going on, but it sure feels >like either my software isn't as up-to-date as I think (obvious problem is >the MacApp 2.0.2 stuff) or I am confused about what I am doing. Any >suggestions? RTFM is an acceptable response, but it sure with help if >you would supply a chapter/page number in the FM to R. > I know that Rick Wong replied to this, but he didn't give you the page number that you asked for. Check out page 15 of the MPW Shell release notes. Note to Rick: You mentioned in your followup to the original question that Apple should be more responsible about making sure that products like MPW and MacApp stay more in sync with each other. With this I whole-heartedly agree! Especially since I work in Apple Tech Support, where we get this question once a week, despite the fact that the problem is mentioned in the release notes. Regardless, this appears to anyone outside of Apple as flagrant irresponsibil- ity on our part. Unfortunately, there is only one programmer working on MacApp right now. Just one! Saddled with the awesome responsibility of maintaining over 4 meg of source code, he can't crank out new versions MacApp just like that (despite the fact that he's almost as fast a programmer as you are). The reason why there is only one programmer on MacApp is that we haven't been able to find any programmer's who are willing to come to Apple to work on it. We'd love to have more people working on MacApp, but haven't seen anyone beating down the doors to help us out. ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions