schorsch@oxy.edu (Brent William Schorsch) (06/23/91)
Lawrence D'Oliveiro says > *I should point out that I have nothing against THINK users. Some of my > best friends are THINK users. Honest. Hmmm... *I* should point out that I have nothing again people who *don't* THINK. Some of my best friends dont THINK. Honest. Ando
ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (06/25/91)
I received ETO #4 this morning. My delivery schedule is improving--it's been only two months since I got ETO #3. ETO 4 contains the complete release of MPW 3.2 final. That was useful, but it wasn't the most interesting thing--what I was after was the update to MPW 3.3 alpha. For those who haven't heard, the neatest new feature in MPW 3.3 is ToolServer. This is a slightly cut-down version of the MPW Shell, which lets you run tools and scripts in the background. The main thing you can't do in these scripts (that you can do normally in the MPW Shell) is invoke editing and window functions. ToolServer communicates with the foreground Shell using AppleEvents, so you need to be running System 7 to take advantage of it. You can, of course, send AppleEvents to ToolServer from an application other than the MPW Shell. The AppleEvents that ToolServer understands are documented in the release notes. I first saw a version of MPW 3.3 and ToolServer on ETO 3. The latest release is noticeably nicer--I can scroll and switch windows, and make selections from the Apple menu, while the Shell is executing a script! I don't recall being able to do that before. Also, 3.3a2 is just as fast in its text entry as the release version of 3.2. You may have been following the discussion in this newsgroup about altering the default key bindings in the editor. What happened is that the release notes for MPW 3.3 document the "SetKey" command, which allows you to specify that a keystroke will invoke either one of the standard editing commands, or a complete shell script. There is a corresponding "UnsetKey" command for removing these bindings. It turns out that MPW 3.2 also has this same facility, though for some reason, in this version the command is called "SetKeys" (note the plural) *and* "BindKey" (both names work), with corresponding "UnsetKeys" and "UnbindKey" commands. By the way, thanks to those Apple people who told us about this feature in MPW 3.2. If anybody is going to beat the lot of you up for revealing this secret, I'd say they may be biting off more than they can chew... The editing commands are identified by names like "DeleteCharRight" and "MoveLineUp". In MPW 3.2 and 3.3a1c1 (the ETO #3 version), you cannot use these commands directly in scripts; they only work as key bindings. It's interesting that the ETO #4 release notes still say that "it is, however, the long-range intent to make the editor primitives scriptable." It turns out that, in 3.3a2, they have in fact done so! In short, with all the work that's being invested in this key binding feature, I don't think it's likely to disappear all of a sudden. Let the THINK users* worry about whether you could have an environment that's too powerful to use; but if you want to be able to explore anywhere, build anything, without your environment ever holding you back, MPW remains the ultimate. Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 Any opinions the author has expressed in this posting are sacred to Epimetheus, the Greek god of hindsight. *I should point out that I have nothing against THINK users. Some of my best friends are THINK users. Honest.
keith@Apple.COM (Keith Rollin) (06/25/91)
In article <1991Jun24.184048.4050@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > >I first saw a version of MPW 3.3 and ToolServer on ETO 3. The latest >release is noticeably nicer--I can scroll and switch windows, and make >selections from the Apple menu, while the Shell is executing a script! >I don't recall being able to do that before. You can do this with MPW 3.2, as well. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "But where the senses fail us, reason must step in." - Galileo
ml27192@uxa.cso.uiuc.edu (Mark Lanett) (06/25/91)
ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >In short, with all the work that's being invested in this key binding >feature, I don't think it's likely to disappear all of a sudden. Let >the THINK users* worry about whether you could have an environment that's >too powerful to use; but if you want to be able to explore anywhere, build >anything, without your environment ever holding you back, MPW remains >the ultimate. Gee, just what I want, the ability to program my editor to do what THINK already does correctly. MPW's scripting ability would be a nice addition to a working compiler. The MPW team, however, seems to think that what I want is more features, rather than fewer bugs. It would be nice if I could spend less time working on MPW and more on my program. Some things I would like to see in MPW are: * An integrated linker. It's obscene that THINK's is both faster _and_ uses less memory. * A linker that either works or gives decent messages as to what's wrong. Here a message I just love: ### Link: Error: Module/EntryPoint has previous (conflicting) type: (Error 14) GELAPPLICATION_OPENOLD (5) <Bad object file or compiler error.> ### Link: Error: Internal problem (or bad object file): (Error 91) a scope ID (5) referred to a non-scope object It would be asking too much, I suppose, for these numbers to be documented anywhere. Lawrence would probly say that it's great that I have the dumpobj tool so I can examine the output code to see what's gone wrong. I've in fact never used that tool for anything _but_ debugging the compiler and linker. If they worked I wouldn't need it, would I? * For the people working on the linker to talk to those working on the C++ compiler, because CFront quite often fails to generate all the Object Pascal strcture the linker needs. Then when the linker fails you have no clue as to which direction to proceed to solve the problem. What do you do about a "module _CLIVEEDIT missing" error? * For C to generate correct symbolic debugging symbols when I have lots of #include of other code. On of the ways to get decent performance from the C++ compiler is to #include all your .cp files into your one main .cp file, creating one huge compiler. Given the normal C++ overhead this is in fact faster than two little compiles. However, the symbolic info generated will be completely wrong. This problem seems to be caused by using load/dump, another way to try to speed up compiles. load/dump by itself doesn't work well either (it's the cause of the error printed above). I'm not aware of any problems with THINK's Precompiled Headers. When THINK releases a C++ compiler we are dumping MPW. We don't have the time or funds to debug Apple's tools. For the moment we're getting ETO. It's also ridiculous to have to pay to get beta software (we're Partners), but it seems to be the only way to get updates, in the hope that one might solve some problems. >Lawrence D'Oliveiro fone: +64-71-562-889 >Computer Services Dept fax: +64-71-384-066 >University of Waikato electric mail: ldo@waikato.ac.nz >Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 >Any opinions the author has expressed in this posting are sacred to >Epimetheus, the Greek god of hindsight. >*I should point out that I have nothing against THINK users. Some of my >best friends are THINK users. Honest. -- //----------------------------------------------------------------------------- Mark Lanett mlanett@uiuc.edu Software Tools Group, NCSA
anders@verity.com (Anders Wallgren) (06/25/91)
In article <1991Jun24.190210.15044@ux1.cso.uiuc.edu>, ml27192@uxa (Mark Lanett) writes: >* For the people working on the linker to talk to those working on the >C++ compiler, because CFront quite often fails to generate all the Object >Pascal strcture the linker needs. Then when the linker fails you have no clue >as to which direction to proceed to solve the problem. What do you do about a >"module _CLIVEEDIT missing" error? > Could you be more specific? I've never seen the problem you mention. Perhaps you are not using compatible versions of the Linker and CFront? >When THINK releases a C++ compiler we are dumping MPW. We don't have the time >or funds to debug Apple's tools. For the moment we're getting ETO. It's also >ridiculous to have to pay to get beta software (we're Partners), but it seems >to be the only way to get updates, in the hope that one might solve some >problems. God how I love statements like these! Not only is it self-contradictory, but also wrong! "We don't want buggy software, we don't want to pay for beta code, we want the pristine released version yesterday." It seems to me like you are being just a little bit too demanding - if you don't want buggy code, don't get the beta versions. If you don't want to pay for beta code, wait for the release. Besides, what you're paying for is to get the early versions _and_ the released versions, since they are included on the CD as soon as the product is released. I for one am pleased as punch about Apple's willingness to provide early versions of their development products. Doing it on a demand basis (as opposed to a select few) _and_ supporting it isn't cheap and that probably has a lot to do with why they charge money for it (along with the fact that you get the released versions as well). It seems to me that your real beef is with THINK since they are behind the market by not providing tools like C++ to their customers. anders
jess@gn.ecn.purdue.edu (Jess M Holle) (06/25/91)
Is MPW 3.2 final being shipped by APDA yet? To the REST of us that is, ie. those without ETO, but rather just in need of an update to 3.1. Jess Holle
peirce@outpost.UUCP (Michael Peirce) (06/25/91)
In article <1991Jun24.190210.15044@ux1.cso.uiuc.edu>, ml27192@uxa.cso.uiuc.edu (Mark Lanett) writes: > ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > > ... > > Gee, just what I want, the ability to program my editor to do what THINK > already does correctly. MPW's scripting ability would be a nice addition > to a working compiler. The MPW team, however, seems to think that what I > want is more features, rather than fewer bugs. I think you're being a little to rough on the MPW people. I've used many compilers in my day (no, I'm not *that* old :-), and the MPW compilers are above average. They're not the best in the world or the most bug free, but do compare favorably with much of what is available on other platforms. I rarely have to fight the compiler as I have on other systems. Many of the features they add to the compilers and linkers are *not* frills, but very helpful in removing limitations found in the earlier versions. Personally I find the MPW environment to be one of the most productive programming environments I've ever worked in. Far from perfect, but definitely making progress in the right direction. -- michael peirce -- Michael Peirce -- outpost!peirce@claris.com -- Peirce Software -- Suite 301, 719 Hibiscus Place -- Macintosh Programming -- San Jose, California 95117 -- & Consulting -- (408) 244-6554, AppleLink: PEIRCE
jordan@Apple.COM (Jordan Mattson) (06/26/91)
In article <1991Jun24.233856.11623@gn.ecn.purdue.edu> jess@gn.ecn.purdue.edu (Jess M Holle) writes: >Is MPW 3.2 final being shipped by APDA yet? To the REST of us that is, ie. >those without ETO, but rather just in need of an update to 3.1. > >Jess Holle Dear Jess - APDA is currently taking orders for MPW 3.2 final. MPW 3.2 is currently in manufacturing and should be shipping from APDA within two weeks (ie. end of the first week of July). -- Jordan Mattson UUCP: jordan@apple.apple.com Apple Computer, Inc. CSNET: jordan@apple.CSNET Development Tools Product Management AppleLink: Mattson1 20400 Stevens Creek Blvd, MS 75-8X Cupertino, CA 95014 408-974-4601 "Joy is the serious business of heaven." C.S. Lewis
keith@Apple.COM (Keith Rollin) (06/26/91)
In article <1991Jun24.233856.11623@gn.ecn.purdue.edu> jess@gn.ecn.purdue.edu (Jess M Holle) writes: >Is MPW 3.2 final being shipped by APDA yet? To the REST of us that is, ie. >those without ETO, but rather just in need of an update to 3.1. Jordan already answered this, but I did want to point out asking questions like this of the net is probably not a Good Idea. If you want to know what APDA is up to, why don't you ask APDA? They have an 800 number: 1-800-282-2732 -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "But where the senses fail us, reason must step in." - Galileo
nagle@well.sf.ca.us (John Nagle) (06/27/91)
MPW, unfortunately, is little more than a 1976-vintage UNIX
Programmer's Workbench with some graphics. There has been considerable
progress since then, and MPW doesn't reflect it.
Program management is still at the SCCS/Make level. You
must describe the structure of the program separately to Projector,
Make, Browse, and Link. This is silly. There should be one database which
describes how all the pieces fit together, and all the tools should
use it. It's suprising that Apple picked such a old model to emulate.
Programming environments need a "pull" model, based on dependencies,
not a "push" model, based on commands. "Make" works this way, but it's old
technology. For example, when "make" can't find something, it just quits.
You don't get a standard file dialog asking "Where is XXX?", leading to
a proper database update, so you don't have to tell it again next time.
That would be the Macintosh way.
The MPW way is to provide a Commando hack to generate makefiles
the first time using a dialogue box, but to require the user to manually
edit Make's database when adding a new file to the build. Tacky.
John Nagle