HDTenEightyP/NetNews huggingface dataset:
From: John Maunsell <maunsell@bcm.tmc.edu>
Newsgroups: comp.sys.mac.programmer
Subject: GWorlds, CopyBits & Printing: QuickDraw Rgns Fail
Date: 13 Oct 1992 14:24:33 GMT
Organization: Baylor College of Medicine
Distribution: na
NNTP-Posting-Host: ca.neusc.bcm.tmc.edu
X-UserAgent: Nuntius v1.1.1d11
X-XXDate: Tue, 13 Oct 92 15:24:33 GMT

I need to print some graphics that include operations on regions. 
Because PostScript 
won't support regions, I've been creating an offscreen graphics world,
composing the 
graphics, and then using CopyBits to copy the whole result to the printer
port.  


It works, but only when open the printer port at the last possible
moment.   Depending 
on the order of opening the graphics world, the printer document, etc, it
sometimes 
appears that region operations fail in the offscreen graphics world.  I
assume that 
when that happens the offscreen graphics world has inherited some of the
attributes of 
the printer port, but I haven't been able to find out which or how.  IM6
has some clues, 
but it's taking me a lot of time (and paper) to sort this out.  


Can somebody tell me what makes an offscreen graphics world decide
whether it

will recognize region operations?  Thanks.
Newsgroups: comp.sys.mac.programmer
From: Jeff E Mandel <mandel@tmc.tulane.edu>
Subject: Re: Deferred Tasks - What can I do?
X-Xxmessage-Id: <A6FA2A0725013009@mandel.anes.tulane.edu>
X-Xxdate: Thu, 8 Oct 92 00:10:15 GMT
Organization: Tulane University School of Medicine
X-Useragent: Nuntius v1.1.1d12
Date: Thu, 8 Oct 1992 23:10:12 GMT
Nntp-Posting-Host-[nntpd-12804]: mandel.anes.tulane.edu

In article <REEKES-081092123045@90.10.20.67> Jim Reekes,
REEKES@applelink.apple.com writes:
>Both a VBL and a Deferred Task are considered interrupt code.  Neither
>can make calls to the toolbox, allocate memory, etc.
>

While I understand what you mean, this is not what you are saying. You
cannot call anything which isn't reentrant, or which presumes that an
unlocked block is where the handle says it is, etc., but that doesn't
mean you can't call anything in the toolbox, or even allocate memory.
There exist techniques whereby you can preallocate a private heap, for
which you write all of the HeapZone functions, which can be made to
function within the constraints of interrupt-driven code. Now, most folks
don't need this, because usually interrupt-driven code does the same
thing over and over again, and you can get by with just allocating a
suitably large number of queue elements and managing a free list (like
the nonpaged dynamic pool, for you VMS folks).  You can also do a a
number of things which lead up to screen output from interrupt-driven
code, but since it is a major pain to keep track of where things are,
it's not worth the trouble (I know, I once wrote a preemptive
dual-tasking executive which allowed me to simulataneously run a
real-time controller and the user interface, except it bothered the users
that it would draw graphs through the menus, and they'd subsequently be
sucked back up into the menubar! (the graphs, not the users)).

Since I probably planted the idea in Pete's head about Deferred Tasks,
the best thing I can suggest is to decide whether the blocks you need at
interrupt time can be of a fixed size, or not. If not, you've got to
write something that manages the memory you preallocate, and probably
guard the code with a spinlock, as it may get reenterred. Plan on long
sessions in MacsBug. If it can be of fixed size, then create two OS
queues, one which contains a list of free blocks, and the other is used
as your private event queue. It is possible to do this with only one
queue (this is how the event queue works, but it doesn't permit you as
much flexibility in priority handling).

Hope this helps,

Jeff E Mandel MD MS
Associate Professor of Anesthesiology
Tulane University School of Medicine
New Orleans, LA

mandel@tmc.tulane.edu
Newsgroups: comp.sys.mac.programmer
From: stud08@cc4.kuleuven.ac.be (Karl Pottie)
Distribution: world
Date: Wednesday, 14 Oct 1992 18:36:38 +01
Organization: K.U.Leuven - Academic Computing Center
Subject: Think C/A4/Quickdraw



I'm a bit confused about using the Think C A4 world when writing an init
using quickdraw.

I had a look at some sources and found several approaches:

(1) public blanket:
-------------------

  void main()					
  {
	  Handle		myHandle;

	  RememberA0();			
	  SetUpA4();					

	  asm
	  {
		  movem.l	a0-a3/d0-d2,-(sp)		/* save registers a0-a3 and d0-d2 */
		  _RecoverHandle					/* get a handle to ourselves */
		  move.l		a0,myHandle			/* put it in the Handle variable */
	  }
	  DetachResource(myHandle);			/* let the Resource Mangler forget about us */
	  HLock(myHandle);						/* lock ourselves down */

	  InitGraf(&thePort);						/* set up my QuickDraw globals */
  ....
  }

The programmer seems to simply use InitGraf(&thePort). Does this work ?
Does Think C and the A4 world handle QuickDraw ? Doesn't QuickDraw expect
A5 to be set to our QuickDraw globals ?


(2) showinit:
-------------

  typedef struct QuickDraw {       /* struct to hold QuickDraw globals */
	char private[76];
	long randSeed;
	BitMap screenBits;
	Cursor arrow;
	Pattern dkGray;
	Pattern ltGray;
	Pattern gray;
	Pattern black;
	Pattern white;
	GrafPtr thePort;
  } QuickDraw;

  pascal void ShowInit(iconID, moveX)
  short iconID, moveX;
  {
	QuickDraw qdGlobals;        /* our own personal QD globals... */
	Ptr localA5;                /* pointer to qdGlobals.thePort */
	Ptr	savedA5;				/* storage for saved contents of A5 */

	asm {
	  move.l  A5,savedA5		/* save "real" QD globals ptr */
	  lea  		localA5,A5		/* set up A5 to point to our globals */
	  move.l  A5,CurrentA5
	}
	InitGraf(&qdGlobals.thePort);	/* initialize our qdGlobals structure */
  ...
  }

In this example, the programmer sets up his own A5 world.
Is this the correct way to proceed ? I suppose some QD toolbox
calls expect A5 to be set to my Quickdraw globals. Does this mean
the first method is incorrect ?


(3) No initialization:
----------------------

Suppose my init patches a trap, and needs to put up an Alert or Dialog
Box during the time applications are already running (i.e. after system
startup, not during init-time).
Can I simply "borrow" or use the current (application's) A5 world,
whatever this might happen to be ? Or do I need to call InitGraf,
InitFonts(), InitWindows(),TEInit() and InitDialogs(nil) and
construct my own A5 QD globals world ?

If I call InitGraf,InitFonts(), InitWindows(),TEInit() and
InitDialogs(nil) at init-time,the StartUpScreen will be cleared.
Can I prevent this from happening ?

Generally: I'd like to know how to handle Quickdraw using Think C
and an A4 world.
From: veloso@husc9.harvard.edu (Manuel Veloso)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Need advice: talking to LaserWriter
Date: 13 Oct 92 14:06:03 GMT
Article-I.D.: husc3.1992Oct13.100604.16325
Distribution: world
Organization: Harvard University
X-UserAgent: Nuntius v1.1.1d11
X-XXMessage-ID: <A700506E56011817@humcr3.harvard.edu>
X-XXDate: Tue, 13 Oct 92 15:07:42 GMT

In article <de19-101092055029@mac19-pg2.umd.edu> Dana S Emery,
de19@umail.umd.edu writes:
>> (b) if this is a LaserWriter, I need to get it to report its status...
>>     whether it is ready or busy doing another job (and if so, for whom
and
>>     what the name of the document is).
>
>You want to read 
>   "learning to drive"
>   "print record spy"
>
>available on better CD's, or at  ftp.apple.com/dts/mac/docs/printing/
>

Actually, you need a couple of back-issues of MacTutor, or the book titled
"Programming the LaserWriter" (or something like that). These document
calls to PAP (Printer Access Protocol), which lets you talk to appletalk
printers.

Manuel
From: mxmora@unix.sri.com (Matthew Xavier Mora)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MPW Question
Date: 16 Oct 92 20:18:15 GMT
Followup-To: comp.sys.mac.programmer
Organization: SRI International

In article <absurd-151092144034@seuss.apple.com>,
absurd@applelink.apple.com (Tim Dierks, software saboteur) wrote:
> By the way, for you Think folk, this is why I use MPW (No, not because
> we have to unmangle function names); because all I have to do is click
> on a header file name and hit command-option-d to open the file out
> of the CIncludes folder.  I can look up function prototypes with one
> key-click or menu selection.  I can get whole paragraphs of text from
> Inside Mac with one command key.  The whole system is so customizable
> and powerful compared to Think's editing environment; I couldn't live
> without it. (OK, that's an exaggeration).

Yea, Yea, Yea. But what kind of mac do you have? Amount of memory?
Hard Disk Space? Radius Rocket perhaps?


Matt






--
----------------------------------------------------------------------
Matthew Xavier Mora                                mxmora@unix.sri.com
SRI International                                       (415) 859-5011
----------------------------------------------------------------------
From: de19@umail.umd.edu (Dana S Emery)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Event Manager Too Slow or izzit just me?
Date: 15 Oct 92 11:15:51 GMT
Followup-To: comp.sys.mac.programmer
Organization: Personal

In article <REEKES-131092125541@90.10.20.67>, REEKES@applelink.apple.com
(Jim Reekes) wrote:
> 
> In article <D88-JWA.92Oct13105012@byse.nada.kth.se>,
> d88-jwa@byse.nada.kth.se (Jon Wtte) wrote:
> > [ some stuff deleted ]
> > 
> > 1) System 6 way:
> > 	Call GetOSEvent instead of WaitNextEvent. This will totally
> > 	freeze up all background tasks, but will yield snappy
> > 	performance for you. Update events and other such unimportant
> > 	stuff won't get in your way, and clicks outside your window
> > 	won't switch you out.
> > 2) System 7 way:
> > 	Ask the user "Would you like jerky motion and living processes,
> > 	or should I kill the f*cking cycle-stealers ?"
> > 	Then, if the user opts for violence, use the process manager
> > 	to kill off all tasks except yourself. WaitNextEvent should
> > 	be snappy enough after that.
> 

How about the Miss Manners way?  check for ongoing processes, and refuse to
torpedo the user untill the machine is clean (7), or is prounced clean (6,
- ).  This will force the user to recognize what the machine state really
*is*, rather than what she *thinks* it is, and will allow an orderly USER
CONTROLLED shutdown of possibly interdependant processes.
--

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."
From: joseph@joebloe.maple-shade.nj.us (Joseph Nathan Hall)
Newsgroups: comp.sys.mac.programmer
Subject: Amateur Programming? [Re: Is IM going to be repackaged?]
Date: Thu, 8 Oct 92 22:02:41 EDT
Organization: 5 Sigma Software
Reply-To: joseph@joebloe.maple-shade.nj.us
X-Mailer: uAccess - Macintosh Release: 1.5v5


In article <ksand-061092195012@wintermute.apple.com> (comp.sys.mac.programmer), ksand@apple.com (Kent Sandvik) writes:
) 
) In article <dq+pmjh.nagle@netcom.com>, nagle@netcom.com (John Nagle) wrote:
) > 
) >       It doesn't really matter, though, because 75% of software sold at
) > retail comes from the top 11 firms.  The era of amateur programming is
) > drawing to a close.
) 
) Don't forget the GNU offerings on the UNIX platform.
) 
Many sophisticated and useful programs can be written in 50,000-100,000 
lines, sometimes much less.  In the case of the Mac, using TCL or MacApp 
will remove many, many lines of potential lines of source from a program,
even if they don't necessarily make writing for a GUI "easy."

That said, there are many hobbyists out there capable of generating
50-100K lines of clean, robust source in a year if the conditions
are right.  (This author counts himself among them.)  Single individuals
and teams of two or three have produced MANY major, complex, sophisticated 
pieces of software.  To wit, text editors (Emacs), compilers (GNU and
THINK C), GUI apps (HyperCard), etc. 

There are plenty of interesting ideas out there still waiting to be
implemented.  For the talented hobbyist who reports only to himself
and/or one or two teammates, the sky is *still* the limit.

Word processors are done pretty well by the big companies these days.
So are drawing apps.  But the development of something like THINK
C 5.0 is well within the reach of two or three talented and informed
folks with a year or two of evenings and weekends to spend.  And the
end result could well be better.

uunet!joebloe!joseph   (609) 273-8200 day   joseph%joebloe@uunet.uu.net
2102 Ryan's Run East        Rt 38 & 41             Maple Shade NJ 80852
-----My employer isn't paying for this, and my opinions are my own-----
From: Eric.J.Baumgartner@dartmouth.edu (Eric J. Baumgartner)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Sharing THINK C objects between XCMDs?
Date: 8 Oct 92 13:47:23 GMT
Organization: Dartmouth College, Hanover, NH
X-Posted-From: InterNews1.0a5@newshost.dartmouth.edu

In article <10548@uqcspe.cs.uq.oz.au>
tonyg@cs.uq.oz.au (Tony Gedge) writes:

> Is it possible to share THINK C 5.0 objects between XCMDs?  That is, I'd like
> to allocate an object in one XCMD and return an string representing it's
> handle or ptr address, and then pass the string to another XCMD which recovers
> the object and uses it.

I think you're right; each different project that uses objects has its
own id numbering scheme and you probably won't be able to resolve them.
Don't know if MPW will help you.

Couple suggestions. Make a multifunction XCMD. Do allocation and
recovery/use in the same XCMD. In this case, there's no ID conflict,
you shouldn't have any problems. (You can hide the fact that it's only
one XCMD from the HyperTalk programmer via a HyperTalk layer.)

Add WriteToHandle() and GetFromHandle() methods to your object.
WriteToHandle() copies all the data from your object into a plain old
handle. GetFromHandle() reverses this. This way, your second XCMD can
create a new object of the right class, then fill it with the proper
data. Sort of ignores the reasons for using oop in the first place,
but...

Eric Baumgartner                   *  ebaum@dartmouth.edu
Interactive Media Lab              *  - When in danger or in doubt,
Dartmouth Medical School           *      run in circles, scream and
shout.
Newsgroups: comp.sys.mac.programmer
From: tom@dtint.uucp (Thomas R. Kimpton)
Subject: Re: MacsBug.  How to use to discover causes of crashes
Organization: Digital Technology, International
Date: Thu, 8 Oct 92 16:54:44 GMT

In article <1992Oct8.003630.8951@alw.nih.gov> fixer@faxcsl.dcrt.nih.gov writes:
>In article <kevin.718501310@crash>, kevin@crash.cts.com (Kevin Hill) writes:
>>
>>  I recently dropped macbug into my macs system folder. 
>>  However, all it has been used for as of yet, is to rs the machine.
>>Could someone give me some hints on where to look for info on how to 
>>use it so that I can actually find out why I crashed?
>
>Addison-Wesley has a very good book out on MacsBug.  It comes with a disk,
>and covers quite a lot of ground in a fairly straightforward manner.  It
>also has some tips on general programming practice, designed to help you
>make your programs easier to debug.
>
[deleted]
>------------------------------------------------------------------------------
>Christopher Tate             | The Leadfoot Collection, Continued:
>Management System Designers  |        * Barracuda (Heart)
>                             |        * Summer of '69 (Bryan Adams)
>fixer@faxcsl.dcrt.nih.gov    | Because driving fast is a cathartic experience.

"MacsBug Reference and Debugging Guide For MacsBug version 6.2"
Addison-Wesley Publishing Company, Inc.
ISBN 0-201-56767-9
$22.95

A very good book, with detailed descriptions for each built-in
command, explanations on how to build templates and macros, and
help on how to build external commands (dcmd's), though I think
they can only be built in MPW.

To get a copy of the online help:

	log diskname:filename
	help
	...
	log

"log" will take all of Macsbug's output and put it in the file you name,
e.g. HD160:macsbug.help.  Type "help" and then keep hitting return
until it starts repeating itself, then type "log" to close the file.

Tom.

-- 
---
Tom Kimpton                            tom@dtint.dtint.com
Digital Technology Int.                (801)226-2984	
500 W. 1200 South, Orem UT, 84057      FAX (801) 226-8438
Newsgroups: comp.sys.mac.programmer
From: rtgrc@rc.rit.edu (Rob Gayvert)
Subject: Temporary memory & PictCompressor
Followup-To: comp.sys.mac.programmer
Organization: RIT Research
Date: Mon, 12 Oct 1992 15:22:30 GMT

I'm interested in finding out how people make use of temporary memory.
Apple is somewhat vague about what "temporary" means, and I'm looking
for some guidelines. The PictCompressor application that is part of the
QuickTime Starter Kit is particularly interesting. When loading a large
image, it creates a GWorld in temporary memory if there is enough; 
otherwise, it spools the image in, probably with DrawTrimmedPictureFile.
The trick is this: PictCompressor doesn't release the "temporary" memory
until you try to launch another application which requires more memory
than is available. Any guesses how they do this? A patch to
LaunchApplication,
perhaps?

Rob Gayvert
RIT Research
rtgrc@rc.rit.edu
From: Daryl_Spitzer@mindlink.bc.ca (Daryl Spitzer)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MacsBug. How to use to discover causes of crashes
Date: 9 Oct 92 02:03:08 GMT
Organization: MIND LINK! - British Columbia, Canada
Distribution: world


Kevin Hill (kevin@crash.cts.com) writes:

>   I recently dropped macbug into my macs system folder.
>   However, all it has been used for as of yet, is to rs the machine.
> Could someone give me some hints on where to look for info on how to
> use it so that I can actually find out why I crashed?
>   Also, I do have 4 of the 6 IM books, so feel free to reference anything
> in
> them.  I'l scream if you reference the 2 that I don't have! :)
>   thanks.

Will you scream if I refer you to two completely different books?  :-)

I would highly recommend Scott Knaster's _How to Write Macintosh Software_,
(which should actually be called How to DEBUG Macintosh Software) and
Konstantin Othmer & Jim Straus's _Debugging Macintosh Software with MacsBug_.

--
-------------------------------------------------------------------
 Daryl_Spitzer@mindlink.bc.ca     "Life isn't just, life just is."
         a2251@mindlink.bc.ca              -- Me  (I think.)
-------------------------------------------------------------------
From: chuck@gte.com (Chuck Hoffman)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MPW C / MPW C Bundle
Date: 8 Oct 92 18:08:26 GMT
Followup-To: comp.sys.mac.programmer,comp.sys.mac.apps,comp.sys.mac.wanted
Organization: GTE Laboratories

In article <92282.135612SPIT@EVALUN11.BITNET>, SPIT@EVALUN11.BITNET
(Werenfried Spit) wrote:
> 
> Hello,
> 
> In the APDA price list I found `MPW C v3.2.3' for $150 and `MPW C Bundle v3.2.3
> for $450. Could anyone explain me the difference. What is in the `bundle' that
> is not in the other thing? What do I need?

I just bought one of the MPW bundles, and this is my understanding of it. 
I don't work for APDA or Apple.

MPW C standalone product is just that.  The C compiler.  My catalog also
says $150, as yours does.  I have been using THINK C up to this point, with
ResEdit and MacsBug.

MPW C Bundle is the Compiler, the Assembler, MacsBug, ResEdit, SourceBug,
the "MPW Development Environment" which is the platform all this stuff runs
on, and the Toolbox Interfaces and Libraries.  My catalog says $425 (U.S.
prices).  In my opinion, you really need all of these things except the
assembler to develop a simple application (I have not seen SourceBug yet,
but since SADE is not included, you probably need SourceBug).

You also can get MacsBug and ResEdit free from a variety of public sources,
and you can order just the user manuals through APDA.

If you ordered standalone for just starting out, you would need:
- MPW Development Environment ($150)
- MPW C ($150)
- MPW Toolbox and Libraries	($40)
- MacsBug Manual only ($23), software free from FTP site
- ResEdit Manual only ($15), software free from FTP site
- SourceBug ($100)

This comes to $478.  It's cheaper to order the bundle, even with a free
ResEdit and MacsBug, and you'll get the Assembler as well.

I ordered a bundle because I also needed the Assembler and C++.

You would buy MPW C standalone if, for instance, you already had been doing
MPW Pascal work, and now wanted to add C into your MPW environment.

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: bmor@kimbark.uchicago.edu (Brad Morris)
Newsgroups: comp.sys.mac.programmer
Subject: Small bug in Think C
Date: 14 Oct 92 04:28:52 GMT
Reply-To: bmor@midway.uchicago.edu
Organization: University of Chicago Computing Organizations

I found an interesting little bug/feature in Think C the other day.

If you copy the memcpy function out of mem.c and include that function
in your source code (must do this because I am writing an init), funny
things happen with prototypes.

If you define the routine as it is defined in the file:
void *
memcpy(/* void *s1, const void *s2, size_t n */)

The parameters are not defined.  And as it says in the Think C Reference, a
procedure containing no variables and only inline assembly has no LINK
instruction.  Fine.  Memcpy has no link instruction.

But, if you have it in the same file as the rest of your code, infered
prototyping can catch you.  If you explicitly prototype, you also get
into trouble.  The only solution is to turn off strict prototyping.

What I think they should do is have a pragma for LINK.  That way you
can decide if you want LINK for a particular subroutine.

Brad Morris
b-morris@uchicago.edu
Newsgroups: comp.sys.mac.programmer
Subject: Bug in Mac ROMs
From: michael@otago.ac.nz
Date: 14 Oct 92 09:19:13 +1300
Organization: University of Otago, Dunedin, New Zealand


Argh!

I have just found this little gem being executed in the ROM of my IIsi (System
7.0.1, TuneUp 1.1)

408177A6:  MOVE.L A0,-(A7)
           _LoadResource
           _HLock

Unless I'm hallucinating again, this is a bug. It relies on A0 being preserved
across the _LoadResource call, something it has no right to do. It only works
because it so happens that the present _LoadResource does preserve A0. Or it
did until I patched it...

I want new ROMs. Immediately :-).


Michael(tm) Hamel, Computing Services Centre, University of Otago, New Zealand

NOAK HOAK (n.)                     
A driver who indicates left and turns right.