Path: utzoo!attcan!uunet!cs.utexas.edu!rice!uw-beaver!ubc-cs!alberta!arcsun.arc.ab.ca!calgary!enme.UCalgary.CA!deraadt From: deraadt@enme.UCalgary.CA (Theo Deraadt) Newsgroups: comp.arch Subject: Re: Macintosh OS Message-ID: <1990Jun7.212351.20426@calgary.uucp> Date: 7 Jun 90 21:23:51 GMT Sender: news@calgary.uucp (Network News Manager) Reply-To: deraadt@enme.UCalgary.CA (Theo Deraadt) Organization: U. of Calgary, Calgary, Alberta, Canada Lines: 32 In article <1990Jun6.222126.2888@midway.uchicago.edu>, gft_robert@gsbacd.uchicago.edu writes >In article <:SY35CD@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes... >>How about the fact that programmers may have better things to do with their >>time than warp code to fit into the windowing universe? I realise that on >>the mac 90% of the programs are 90% user-interface, but that's not always >>the best way to do things. A compiler, for example, really has no business >>calling GetNextEvent *ever*. > >And if the user wants to interrupt the compilation mid-compile? You'd better >have some way of finding at least this out. GetNextEvent (or WaitNextEvent) >seems the proper way to do this to me. > >You may indeed have to change some of your code to run properly on the Mac. >Or put another way: you may have to change some of your code to put the user >incomplete control. The above example as a case in point. And why are signals (esp. unix type signals) not a correct way to handle this? Calling GetNextEvent() sounds like polling to me. So, if I wanted to do a large matrix add, I would have to call GetNextEvent() every couple of rows perhaps. And where do I put GetNextEvent() in my compiler? I guess I put it in the parser, and it calls GetNextEvent() every 100th token or something like that. For heavily recursive stuff, does this not seem to get overly messy?