HDTenEightyP/NetNews huggingface dataset:
From: mxmora@unix.SRI.COM (Matt Mora)
Newsgroups: comp.sys.mac.programmer
Subject: Re: incrementation differences/THINK C 4.0 vs. 5.0
Date: 25 Aug 92 16:26:29 GMT
Organization: SRI International, Menlo Park, California

In article <BtIJq6.3yw@taligent.com> keith@taligent.com (Keith Rollin) writes:
>
>I don't think that's a valid assumption. Although it might be disconcerting, I
>don't think there's anything preventing a compiler from evaluating your sample
>line one way during one compile, and the very same compiler evaluating it a
>different way during a subsequent compile. ANSI spec section 3.3.16 says "The
>order of evaluation of the operands is unspecified."

Don't you just love C! All the cool things that you can do are the very
same things you have to worry about. Pretty soon you'll be writing code like
this just to be safe. i = i + 1;  :-)

>On the other hand, if I ever _did_ run across a compiler like that, I'd worry
>about the brain of the guy who wrote it.

It might act like that if you turn on optimization. It could happen. Yeah and 
monkeys might fly out of my butt.

Why can't there be a smart compiler? Why can't it take a chunk of code
chew on it all night and in the morning report "After 276 optimitation
passes I found that moving this varible outside the loop and declaring it as a 
register variable, performance will improve by 56%." And show you the optimized
SOURCE code.

When a compiler doesn't know the best way to go why doesn't it just ask?

"not sure how you want the order of evaluation of this line:"
     lab[i] = temp[i++];  //****THIS IS THE PROBLEM

"Maybe you mean:"
     lab[i] = temp[i]; i++;  //****THIS IS THE PROBLEM

Also why can't the compiler say this when a ";" is missing.

Missing an ";" at the end of this line. Should I add one?"
"Add one and Continue" or "Cancel"

instead of

"Missing a ";" at the end of statement."

and stop compiling. 

Compilers have a long way to go yet. I can't believe that the Mac user
interface hasn't worked its magic on compiler designers yet.




Matt
-- 
___________________________________________________________
Matthew Mora                |   my Mac  Matt_Mora@sri.com
SRI International           |  my unix  mxmora@unix.sri.com
___________________________________________________________
Newsgroups: comp.sys.mac.programmer
From: petrus@stacken.kth.se (Lars Petrus)
Subject: Re: Can TCL project size be reduced using precompiled headers?
Organization: Stacken Computer Club, Stockholm, Sweden
Date: Thu, 3 Sep 1992 10:10:56 GMT

In article mkelly@sisters.cs.uoregon.edu (Michael A. Kelly) writes:
>In article de19@umail.umd.edu (Dan Emery) writes:
>>Is it possible to reduce the size of a TCP project file by using
>>the "precompiled header" feature?  If so, could some kind soul
>>email or post a description of the strategy one would use.
>>
>
>I'll add this to the next version of the FAQ.
>
>The answer is yes.  You just add your TCL headers to Mac #includes.c and
>Precompile.  Presumeably you would want to make a separate file, called
>something like "Traps+TCL Headers".


   There is a nasty trap in this. If you precompile your headers using
"Generate 68881 instructions", and then use them in a project which do
not use 68881 your program will work perfectly on your machine (which
has a 68881), but will crash on a machine without 68881.

   This caused our biggest panic to date (it was The Important Possible
Customer who had the FPU-less mac), and took two days and one night to
figure out.



   Precompiling headers is the first thing to do to reduce project size.
It chopped 75% of mine. If you are still not satisfied, you can turn of
debugging on files where you don't think you need it. That's the grey
dot to the left of file name.



  -  -  -  -
Wise Quote: "You want to know how to paint a perfect painting? It's easy. 
Make yourself perfect and then just paint naturally. That's the way all the 
experts do it." - Robert M Pirsig in ZATAOMM.

Lars Petrus, Solna, Sweden  -  petrus@stacken.kth.se
From: damurphy@wc.novell.com (Duane A Murphy)
Newsgroups: comp.sys.mac.programmer
Subject: Re: How to increase stack size ???
Date: 2 Sep 92 15:48:22 GMT
Organization: Novell, Inc. - Walnut Creek

In article <1992Sep1.145611.1@uwovax.uwo.ca> tschneid@uwovax.uwo.ca writes:
>
>I am working on a port of Gunplot 3.2 to the Mac. So far I have most
>of the basics working (only a few bugs left) ... however, I keep
>running out of stack space. I did some reading and found out that the
>Mac only provides 8k of stack space and that it can be changed by doing
>something like (in VERY rough C pseudo-code)
>
>        THz newapplimit;
>
>        newapplimit = 300*1024;    /* give app 300k */
>        SetApplLimit(ApplLimit()+newapplimit);
>        MaxApplLimit();
>
>Unfortunately, this does not work ...
>
>Can anyone enlighten me? I would like to set up a fixed stack size of
>32k (i.e. not dependent on the memory allotted by the user in the 
>applications info box). I am using Think C 5.02.
>
>Thanks,
>Todd Schneider

I also ran into a stack limitation problem.  Actually the stack is handled 
differently on different machines.  It is not consistent.  "Small" machines
have an 8K stack.  "Large" machines have a 24K stack.  There is a low memory
global "DefltStack" that determines the stack size at startup.  Dont mess 
with this, it affects everyone.

After a few days of trying to figure out how the stack space is managed; 
that is what pointers in the heap kept track of the stack to detect a
stack heap collision, we came up with the following very simple solution.

#define STACK_MIN 0x8000L
pascal Ptr StackPtr(void) = {0x2e8f};	/* MOVE A7, (A7) */

int main(void)
{
    SetApplLimit(StackPtr() - STACK_MIN);
...

The StackPtr() function came from the net (thanks to whomever suggested
this).  The stack has no direct pointers to set its limits.  It is actuall
controlled by heap limit pointers, namely ApplLimit.  This moves ApplLimit
the where the current stack is at down the size of the stack that you
want.

Hope this helps,
...Duane Murphy
Novell, Walnut Creek
Newsgroups: comp.sys.mac.programmer
From: alen@crash.cts.com (Alen Shapiro)
Subject: Getting the alias'd name from a drag-and-drop app?
Date: 27 Aug 92 15:22:05 GMT
Summary: Need to know fast how to do this
Keywords: alias drag drop help

Sorry to pester with this one, I know the info is in IMvol6 but
the soonest I can get one of those (from the 4 bookstores I've
tried here in San Diego is 6 weeks!!).

I need to take a selection of aliases from a folder and drag them onto
an application (that I am writing). The app must replace each aliased
files with a copy of the real file that the alias represents. I have
everything working EXCEPT one small thing. I can't discover the name/
location of the alias files that are dropped onto the app.

I'm using:

	CountAppFiles(&msg, &count);
	
	for(i=1 ; i <= count ; i++) {
		GetAppFiles((short)i, &thefile);
		
		if((err=FSMakeFSSpec(thefile.vRefNum, (long)NULL, thefile.fName, &spec)) != noErr) {
			fprintf(stderr, "FSMakeFSSpec error %hd\n", err);
			exit(err);
		}

		then a call to
		NewAliasMinimal to get a handle to the alias
		then a call to GetAliasInfo to find the name of the
			aliasing file
	}

Trouble is, by the time GetAppFiles sees the parmlist it seems to
contain references to dereferenced alias files.

Is there a toolbox call that I should use instead of GetAppFiles
that will stop it chaining down the alias chain and will cause
it to deliver me the name and vRefNum of the alias itself?

--alen
alen@crash.cts.com

ps I've put in an order for vol6 of IM but I'd like to continue
to work meanwhile!!
From: cnc@Apple.COM (Chris Christensen)
Newsgroups: comp.sys.mac.programmer
Subject: Re: out of memory in ThC 5 when dbugging
Date: 27 Aug 92 00:06:43 GMT
Organization: Apple Computer Inc., Cupertino, CA

> When I mark the 'Use debugger' menu item in the Project menu and then select
> Run (after marking the appropriate source files in the Project window) I get
> the following (debugger) message:
>
> 'out of memory'
>
> THINGS I HAVE TRIED:
> I have tried setting Think C to anything up to a 7Mb  partition and then I
> tried setting the debugger 'application' to 2Mb and also increasing the
> partition for the actual project to double what it should be (normally 750k).

increasing the memory taken by Think will make the problem WORSE.
You need to free up enough memory to run Think, the debugger and the program.
Can you change the size of the program being built using 
"Set Project Type..."?
From: fry@tara.harvard.edu (David Fry)
Newsgroups: comp.sys.mac.programmer
Subject: Re: How to save a PICT file?
Date: 30 Aug 92 04:22:14 GMT
Article-I.D.: husc3.1992Aug30.002216.15223
Distribution: usa
Organization: Harvard Math Department

In article <1992Aug29.003233.3802@desire.wright.edu> jmatthews@desire.wright.edu writes:
>In article <zben-280892151439@zben-mac-ii.umd.edu>, zben@ni.umd.edu (Charles B. Cranston) writes:
>> Ahem, wouldn't it be a good idea to lock the handle while writing
>> it out?  I wasn't aware _Write refrained from moving memory.  Please
>> correct me if I'm wrong about this...
>
>An excellent question. An expression such as Ptr(picHdl^) creates a
>copy of a master pointer; the original will change if the block to
>which it points gets moved. Fortunately, I haven't found _Write on
>any list of traps that move memory (IM vol I-VI; THINK Reference).
>
>I suppose that believing _Write will never move memory in the future
>is a shade optimistic. I hope the "lock everything" partisans don't
>don't wind up being too right:-)

I don't think there's any chance that _Write will ever move memory.
First, they didn't put it on that list so everybody is counting on it not
moving memory, and _Write is a VERY popular trap call - lots of
programs would break.  Second, if _Write did move memory, lots of
useful interrupt, VBL, and time manager tasks would break because they
couldn't communicate with the disk, serial port, or AppleTalk (I think
that last one is correct).  In fact, would AppleTalk work at all?

What are the chances that a future version of the MacOS, or an OS that
existing Mac programs run on like PowerOpen or Pink, will not have
relocatable blocks and all of this is moot?

David Fry                                  fry@math.harvard.edu
Division of Applied Sciences               fry@huma1.bitnet
Harvard University                      ...!harvard!huma1!fry
Cambridge, MA  02138            
Newsgroups: comp.sys.mac.programmer
From: sdorner@qualcom.qualcomm.com (Steve Dorner)
Subject: Re: dereferencing Handles( was Re: incrementation differences...)
Organization: Qualcomm, Inc., San Diego, CA
Date: Tue, 25 Aug 1992 18:27:50 GMT

k044477@hobbes.kzoo.edu (Jamie R. McCarthy) writes:
>Yes, that last sentence is true.  But unless you call Toolbox routines
>that move memory, the block will never move.  The above snippet doesn't
>do that, so there's nothing to worry about.

Two caveats:

1. Don't trust any list of toolbox routines that supposedly don't move
memory.  People patch stuff, and s**t happens.  Code defensively. The
only exception to this rule that *I* make is BlockMove; anybody who
patches BlockMove and makes it move memory is going to have his thumbs
broken.

2. Be aware that function calls to an unloaded segment may move memory,
and that some fairly innocuous operations can be implemented in
libraries (division of longs on 68000's is one such, I think; certainly
a lot of floating point operations fit here).  You can avoid this by making
sure that important libraries are in locked segments.
-- 
Steve Dorner, Qualcomm, Inc.
Yes, I'm still working on Eudora and it's still free.
From: peter@cujo.curtin.edu.au (Peter N Lewis)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Is "Programmers Online Companion" going to be updated?
Date: 26 Aug 92 02:06:46 GMT
Followup-To: comp.sys.mac.programmer
Organization: NCRPDA, Curtin University

In article <BtJzno.CrK@taligent.com>, keith@taligent.com (Keith Rollin)
wrote:
> 
> In article <peter-250892141421@134.7.50.3>, peter@cujo.curtin.edu.au (Peter N
> Lewis) writes:
> > 
> > Well, you could do this I guess.  Except that I've already done it, as well
> > as writeing my own clone of POLC, which I've been using for six months, and
> > which I would love to release free, but I have not been able to sort out
> > the required US$100 to license the PInterfacesHelp file, on which the
> > database is created (the database is created by running an automatic parser
> > over the PInterfacesHelp file, thus ensuring rapid updates as new systems
> > come out).

> Could you just send out you homebrew POLC along with the converter program 
> that creates the database file from PInterfaces? There shouldn't be any 
> problem with that.

Since several people have asked me this in mail, I'll state it in news,
yes, I could just do that, but since the PInterfacesHelp file is no longer
available on ftp.apple.com (or anywhere else to my knowledge), and since I
am one of the people who does not own a copy myself, I'd end up not being
able to legally use my own software :)

> I remember, ages ago, on the Apple II, Glen Bredon disassembled and commented
> the AppleSoft object code. He wasn't allowed to send out his results directly
> (because it included Apple copyrighted code converted to human readable form),
> but he was able to send out a little program that would _create_ a commented
> source file based on his file of comments. The program disassembled the
> AppleSoft ROMs and added his comments to each line.

Somehow I think it would be against my best interests to go out of my way
to annoy Apple :), also, I would have done exactly as you stated (releasing
the parser (which I will release anyway)) if the PInterfacesHelp file was
publicly available, but it isn't.

Hopefully I will be able to sort out licensing the file with some
assistance from various people in the states, and then everything will be
rosy (more or less :-)

Have fun all,
   Peter.

_______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University       peter@cujo.curtin.edu.au
GPO Box U1987, Perth WA 6001, AUSTRALIA             FAX: +61 9 367 8141
Newsgroups: comp.sys.mac.programmer
From: jhl@naif.jpl.nasa.gov (Jay Lieske)
Subject: Re: Fortran callable rountines in THINK C
Organization: Jet Propulsion Laboratory
Distribution: na
Date: Tue, 1 Sep 1992 21:14:01 GMT

In article <1992Sep1.113040.943@galaxy.gov.bc.ca> cconstantine@galaxy.gov.bc.ca
writes:
>I will be working on a program with a friend of mine that will interface some
>Fortran code (Language Systems) and would like my C libraries to be callable
>form Fortran.  Is there a specific way I need to do this?  I'm using THINK C
>5.0.2 on an LCII (now called a Perforama 400) and System 7.0.1 w/ tune-up.
>
>Thanks muchly!!!!
>-- 
>Carl B. Constantine
>CCONSTANTINE@galaxy.gov.bc.ca
>	"Opinions are mine only!!"
>

In principle, I think it can be done, but it's rather tough with Think
products.  Specifically, I tried this a few years ago using Think Pascal.
The basic problem is that Think compilers are case-sensitive and its
linker is case-insensitive whereas the MPW Pascal compiler is case
insensitive but the linker is case-sensitive.  For Pascal programs that
means that the ENTRY points must be all caps.  One interesting and
potentially useful side effect of all this is that Think and MPW libraries
may be intermixed--for example MPW's NEWPTR is "different" from
Think's NewPtr because of the capitalization.

At one time Rich Siegel mentioned that Think Pascal might look into
the problem, but I don't believe they have done anything up to now.  It's
much easier just to recompile things with MPW compilers (after using 
Think's excellent debugging tools) and link with Language Systems Fortran.


Jay H. Lieske                                            jhl@naif.jpl.nasa.gov

Newsgroups: comp.sys.mac.programmer
From: nagle@netcom.com (John Nagle)
Subject: Re: Zortech C++ - Comments? -
Date: Wed, 26 Aug 92 17:07:17 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Keywords: Zortech C++

back@itd.dsto.gov.au writes:
>Has anyone used the Zortech C++ compiler for the mac. I'm thinking of buying 
>it and would like to get a little user feedback.

      Don't.  You'll be sorry.  The Zortech C++ product for Intel CPUs is
good, but the 68000 code generator was botched, and the Mac product is
lousy.  I am a very unhappy owner of this product.  I finally had to buy
Apple's MPW C/C++ compiler.

      Symantek now owns Zortech, and hasn't done much with the Mac product,
although there are rumors of a Symantek C++/Bedrock product some time next
year.  

					John Nagle
From: chuck@gte.com (Chuck Hoffman)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Open file at launch time?
Date: 31 Aug 92 15:12:40 GMT
Followup-To: comp.sys.mac.programmer
Organization: GTE Laboratories

In article <5575@omphalos.bug.co.jp>, tague@omphalos.bug.co.jp (Tague
Griffith ) wrote:
> Under system 6.0.x you can use the CountAppFiles, GetAppFiles, and ClrAppFiles
> procedures to handle this.  Your application really should support both 
> methods, since system 6.0.x is still the latest version of the os in many
> languages.  The Apple Event stuff is documented in IM VI (including example
> code) and the *AppFiles routines in IM II.  Plus, I think the 
> comp.sys.mac.programmer 

This is also true under System 7.  I have a sample application which
happens to have this code in it.  It also has code for printing from the
Finder as well as opening.  If you are interested, I would be happy to mail
it to a postal address.

Chuck Hoffman
chuck@gte.com
GTE Laboratories, Waltham, Massachusetts, USA
(617) 466-2131
=====================================
I'm not sure why we're here, but I am sure that while we're here we're
supposed to help each other.
=====================================
From: pollansw@cse.fau.edu (Warren Pollans)
Newsgroups: comp.sys.mac.programmer
Subject: purdue compiler const. tools
Date: 28 Aug 92 01:06:10 GMT
Organization: Florida Atlantic University, Boca Raton, FL, USA

Does anyone know if the Purdue Compiler Construction Tools  
will compile with the thinkC compiler on a mac SE and run
correctly, producing the same results as on a unix system?
I would like to be able to use the Antlr tool at home?

Warren

(pollansw@cse.fau.edu)
From: gregt@function.mps.ohio-state.edu (Gregory M Ferrar)
Newsgroups: comp.sys.mac.programmer
Subject: Looping through all allocated blocks
Date: 25 Aug 1992 21:49:42 -0400
Organization: Department of Mathematics, The Ohio State University
NNTP-Posting-Host: function.mps.ohio-state.edu
Keywords: memory, handle, pointer

I'm writing a program in THINK C, and I would really like to know how to
examine each memory block in order.  In other words, I would like some sort
of loop which allows me to process all handles or pointers which have been
allocated since the start of the program.  How can this be done?

  -Greg Ferrar (gregt@function.mps.ohio-state.edu)
From: cconstantine@galaxy.gov.bc.ca
Newsgroups: comp.sys.mac.programmer
Subject: #pragma once whoes!!! Plea for help!
Date: 31 Aug 92 13:54:59 -0700
Organization: BC Systems Corporation

I have a rather interesting problem if I may impose on you THINK C 5 gurus out
there.  The problem seems to be with the #pragma once directive.  I have this
directive at the top of each of my header files (of which there are 5 or 6) an
d I have 4 source files, 3 of which #include "AppGlobals.h".  I am _STILL_
getting a Link Error of "Multiply defined: symbol (where symbol is my global
var)" I have even tried using the #ifndef ... #endif set of things and still
get this error.  I have trashed my project and recompiled, still the same
thing.

Is there something I'm missing here.  I shouldn't be getting this.  BTW, I
don't believe I've got this type of error before.

Any help would be _MUCHLY_ appreciated.

P.S. to Keith Rollin (a.k.a. the Phantom Programmer) I've bought your first
book with Scott Knaster and am enjoying it thouroghly (sp?)!!!

Carl B. Constantine
CCONSTANTINE@galaxy.gov.bc.ca
	"Opinions are my own and are not necessarily those of my employer"
Newsgroups: comp.sys.mac.programmer
From: mmarx@Csli.Stanford.EDU (Matthew Marx)
Subject: Re: incrementation differences/THINK C 4.0 vs. 5.0 -- thanks everyone!
Organization: Stanford University CSLI
Date: Tue, 25 Aug 1992 19:48:52 GMT

Thanks to all the helpful folks out there in NetLand who helped me out
with my problem. Making the change across the board fixed all the bugs
in the applicaton. Yahoo!

If only Symantec had mentioned this in the "What's New" section....
;-)

-- 
Matt Marx       mmarx@csli.stanford.edu           
"Too much time on my hands..." -- Styx  
"Too many hands on my time..." -- Rush
From: tschneid@uwovax.uwo.ca
Newsgroups: comp.sys.mac.programmer
Subject: How to increase stack size ???
Date: 1 Sep 92 18:56:11 GMT
Organization: University of Western Ont, London


I am working on a port of Gunplot 3.2 to the Mac. So far I have most
of the basics working (only a few bugs left) ... however, I keep
running out of stack space. I did some reading and found out that the
Mac only provides 8k of stack space and that it can be changed by doing
something like (in VERY rough C pseudo-code)

        THz newapplimit;

        newapplimit = 300*1024;    /* give app 300k */
        SetApplLimit(ApplLimit()+newapplimit);
        MaxApplLimit();

Unfortunately, this does not work ...

Can anyone enlighten me? I would like to set up a fixed stack size of
32k (i.e. not dependent on the memory allotted by the user in the 
applications info box). I am using Think C 5.02.

Thanks,
Todd Schneider
Newsgroups: comp.sys.mac.programmer
From: brunner@crchh447.bnr.ca (James Brunner)
Subject: Hacking Think_C Malloc, need big free!
Reply-To: brunner@crchh447.bnr.ca (James Brunner)
Organization: Bell-Northern Research, Richardson, Tx
Date: Mon, 31 Aug 1992 22:36:42 GMT

Howdy, I'm working on a kludge where I am combining several UNIX utilities.
Each of these allocates memory and it gets freed automatically at exit(0).
I would like to be able to free all malloc-allocated memory between calls
to these utils.  I've looked at alloc.c but it's all in asm and hard to read.

How can the library be modified to add a free_all routine?
-- 
---------------------------------------------------------------------------
Jim Brunner - (brunner@bnr.ca)
All opinions are my own and have nothing whatsoever to do with BNR, NT,
NTI, Bell Canada, or any of the BCE corporations or affiliates.
Newsgroups: comp.sys.mac.programmer
From: wolfmc@rtsg.mot.com (Michael Wolf)
Subject: How can I have my app place cicns in the menu bar...
Organization: Motorola Inc., Cellular Infrastructure Group
Date: Wed, 26 Aug 1992 17:46:50 GMT

I would like to place a small icon in the menubar, much like the help
menu is.  I want to have a pulldown menu with it as well.

I want to be able to do this from within my applications and to
change its appearance on the fly in the app.

Is this goingto be impossible....do I have to break a lot of things to
get this to work?

Thanks.

MJW
From: de19@umail.umd.edu (Dana S Emery)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Wysocki CPEditText
Date: 23 Aug 92 20:11:41 GMT
Followup-To: comp.sys.mac.programmer
Organization: Personal


I have corresponded with Cris Wysocki (author of CPEditText).  He is
embroiled in other work, and shouldnt be expected to be supportive,
although he did express an interest in bug reports.

A number of people have reported success useing it, so I would expect
problems to be few.

I am suspicious of its behaviour under complex or large scripts, and would
welcome comments from people on that subject.


BTW, there is a mail-based group for the Think Class Libraries, to sign on
just send mail asking to be signed on to:

  TCL-request@brown.edu

--

Dana S Emery <de19@umail.umd.edu> | "Novo, de Novo,
                                  |     de novo, de no-o-o-o-o---, 
                                  | Novemba come an' dey gonna go home."