[comp.sys.mac.programmer] new interface files makes MPW pascal go -108

sinteur@ooc.uva.nl (John Sinteur) (06/08/91)

When I received the Golden Master system 7 CD-ROM, I happily copied
the MPW Pascal interface files from it - the docs said it contained
the new 7.0 info and stuff, which was what I've been waiting for.
 
My sources have stopped compiling however, and pascal aborts with
a -108 error (which is a 'not enough room in heap zone' or some such).
 
I found it very strange that changing interface files made pascal
ask for that much memory - and even a non-multifinder, init-clean
4 Mb LC was not enough, so I guess there's something else going on.
 
I was able to find out that the {$IFC ...} clauses that precede
every *.p file was part of the cause, since they somehow influenced
from which files symbol tables were read from resource. I also
found out that compiling the same file (like this: program test;
uses types; begin writeline('blah!'); end.) did not always get the
same behaviour with respect to loading these symbol tables. I never
bothered to look at this before, so I am quite out of my depth here.
 
Can somebody tell me what is going on? Or give me a manual reference?
Do I have to go back to older interface files?

-John
(PS I also copied MPW 3.2 from that CD, but that can't be it, right?)

.

ml27192@uxa.cso.uiuc.edu (Mark Lanett) (06/09/91)

sinteur@ooc.uva.nl (John Sinteur) writes:


>My sources have stopped compiling however, and pascal aborts with
>a -108 error (which is a 'not enough room in heap zone' or some such).
> 
>-John
>(PS I also copied MPW 3.2 from that CD, but that can't be it, right?)


That can't be it? Remember, this is an Apple product you're talking about,
where the beta testing is done after it's declared Final.

MPW 3.2 *beta* has no problem with the Pascal compiler -- it's MPW 3.2 Final
that kills it.
--
//-----------------------------------------------------------------------------
Mark Lanett						mlanett@uiuc.edu
Software Tools Group, NCSA

sinteur@ooc.uva.nl (John Sinteur) (06/09/91)

A big thank you goes to  Scott E. Lasley <lasleyse@wam.umd.edu> since
he told me the -clean compiler option solves this!

-John

newbery@rata.vuw.ac.nz (Michael Newbery) (06/10/91)

In article <20687@slice.ooc.uva.nl> sinteur@ooc.uva.nl (John Sinteur) writes:
>
>A big thank you goes to  Scott E. Lasley <lasleyse@wam.umd.edu> since
>he told me the -clean compiler option solves this!

But it doesn't exactly speed up the compile! -clean says "erase all symbol
table resources" which means (I presume) that it throws the header
information away. The newly created resources are not 'clean' enough to
enable the compile to proceed the second time around.

Anyone got a more permanent fix NOT involving ETO?

--
Michael.Newbery@vuw.ac.nz
She learnt to stab her food with a silver fork.
   "Pavanne", Richard Thompson.

lsr@Apple.COM (Larry Rosenstein) (06/13/91)

In article <1991Jun10.052704.13068@rata.vuw.ac.nz> newbery@rata.vuw.ac.nz (Michael Newbery) writes:
>
>But it doesn't exactly speed up the compile! -clean says "erase all symbol
>table resources" which means (I presume) that it throws the header
>information away. The newly created resources are not 'clean' enough to
>enable the compile to proceed the second time around.

-clean should only have to be used once.  The symbol information is stored
in the resource fork, and it's possible that the resource fork has been
damaged.  -clean would ignore it, but wouldn't be able to recreate it.

(I had a similar problem where MPW wouldn't save my window size and
location.  The problem turned out to be a bad resource fork.)

You can try using RezDet to see if the resource fork is damaged, or use
dupliacte -d to duplicate only the data fork to another file and then
replace the bad header.

-- 
Larry Rosenstein, Apple Computer, Inc.

lsr@apple.com
(or AppleLink: Rosenstein1)

lasleyse@wam.umd.edu (Scott E. Lasley) (06/14/91)

In article <14041@goofy.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes:
>
>-clean should only have to be used once.  The symbol information is stored
>in the resource fork, and it's possible that the resource fork has been
>damaged.  -clean would ignore it, but wouldn't be able to recreate it.
>

This has not been my experience.  I can compile a program with -clean or
-noload, but I cannot compile with no symbol table options, nor with the
-rebuild option.  I tried duplicating the program with duplicate -d and
was unable to compile the duplicate unless -clean or -noload were specified.
even tried removing the MPSR resources from the source file, but it did
not help.  The 3.2 upgrades should ship in a couple of weeks.

newbery@rata.vuw.ac.nz (Michael Newbery) (06/14/91)

In article <14041@goofy.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes:
>You can try using RezDet to see if the resource fork is damaged, or use

RezDet can't find anything wrong with any of my header files, including
all the system PInterface files.

--
Michael.Newbery@vuw.ac.nz
Aequam memento rebus in arduis servare mentem
   Horace Od. II iii 1