kdmoen@watcgl.UUCP (08/25/87)
Lots of Amiga-types have been pointing out the benefits of performing
compilations in the background while doing other stuff.
I'd like the answers to 2 questions:
1) Will MPW (Macintosh Programmers Workshop) be compatible with MultiFinder?
2) Will the necessary calls to GetNextEvent (or whatever) be inserted
into the MPW C compiler so that it can run as a background task under
MultiFinder?
Since the dance notation editor that I am working on takes an hour and
40 minutes to recompile under MPW, it would be *really nice* if I could
use the Macintosh for other purposes while the compile is running.
--
Doug Moen
University of Waterloo Computer Graphics Lab
UUCP: {ihnp4,watmath}!watcgl!kdmoen
INTERNET: kdmoen@cgl.waterloo.edujww@sdcsvax.UCSD.EDU (Joel West) (08/26/87)
Actually, there was a very good article about GetNextEvent, etc. on Bix that will be in Byte. Since MultiFinder steals the time if it sees two nullEvt's in a row, it's even possible to work with GetNextEvent-compiled programs, as Tom Thompson of Byte demonstrated.
lsr@apple.UUCP (Larry Rosenstein) (08/27/87)
In article <1639@watcgl.waterloo.edu> kdmoen@watcgl.UUCP (Doug Moen) writes: > >1) Will MPW (Macintosh Programmers Workshop) be compatible with MultiFinder? MPW 2.0 is Multifinder aware; not only does it work with Multifinder, but it takes vantage of the Multifinder environment. For example, if you are running Multifinder and launch an application from MPW, the MPW shell does not run its normal suspend script. It simply uses sublaunching to have Multifinder run the application in a separate area of memory (exactly as if you had launched the app from the Finder). Since MPW does not exit, there is no reason to save the state of variables, aliases, etc. >2) Will the necessary calls to GetNextEvent (or whatever) be inserted > into the MPW C compiler so that it can run as a background task under > MultiFinder? This was not done for MPW 2.0, so you can't run the compilers in the background under Multifinder. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
gustav@swanee.OZ (Gustav) (09/05/87)
In article <3344@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes: > MPW 2.0 is Multifinder aware; not only does it work with Multifinder, but it > takes vantage of the Multifinder environment. > For example, if you are running Multifinder and launch an application from > MPW, the MPW shell does not run its normal suspend script. It simply uses > sublaunching to have Multifinder run the application in a separate area of > memory (exactly as if you had launched the app from the Finder). Since MPW > does not exit, there is no reason to save the state of variables, aliases, > etc. [...] [but] you can't run the compilers in the background under > Multifinder. Well, that's not good enough. Multitasking is of greatest value exactly in those areas where you don't do things interactively and compilations are some of them. Lengthy mathematics (it's quite commmon that some Monte Carlo simmulations would run for DAYS!) is another area. And basically MPW should be able to do all that. In fact one really wonders, Apple at this stage seems to support three different operating environments, which does lead to some questions. You have MultiFinder (or Finder in its older version), MPW, which really stands on its own and A/UX. MPW has some features in common with UNIX, and probably MPW shell or its derivative could be implemented under UNIX, but basically it's a different thing. Now, to support three different environments is a rather costly exercise, not to mention a great potential for confusion amongst programmers and users. Is Apple really going to do that? A word of advice about the future plans in this respect would certainly help. In my opinion the best solution would be to amalgamate somehow all three of them, which would perhaps provide a sort of an "ideal" OS for a microcomputer. On the other hand, for a common user, which does not program him/her-self, that might be an overkill (and over-cost). Also, such an amalgamated system may require much more memory and disk space than many users at this stage would be prepared to pay for. Hmm... Have I just answered my own question?
mrh@Shasta.STANFORD.EDU (Marc Hannah) (09/10/87)
In article <359@swanee.OZ>, gustav@swanee.OZ (Gustav) writes: > In article <3344@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes: > > > MPW 2.0 is Multifinder aware; not only does it work with Multifinder, but it > > takes vantage of the Multifinder environment. I would argue that MPW 2.0 fails at least 2 ways in terms of being the best type of MultiFinder companion. I think compiling in background would be a big win and it loses there, AND it also is pretty wimpy about giving time to background tasks during compilation. Both would be nice but it should at least let through some time. (This was done with MPW C 2.0 and it may be better with other tools, I don't know). David Gelphman daveg%slacvm.bitnet@forsythe.stanford.edu