ldo@peace.waikato.ac.nz (Lawrence D'Oliveiro) (01/23/90)
Here's my list of what I'd like to see in future versions
of MPW.
* The ability to use the contents of a window (or the current
selection within a window) as both input and output in the *same*
command. That way, I can do nifty things like reformat code
(which I've transferred from another machine) with
Entab -d 8 -t 4 <"{Target}" >"{Target}"
without having to mess around with intermediate temporary
files. At the moment, if you try this, you immediately lose
the portion of text you were trying to operate on. I'd be quite
happy if this new feature were to work only with open windows,
not with arbitrary files.
* The ability to extend the selection by holding down the
shift key while pressing the arrow keys, as per Inside
Plusintosh, pages IV-5 to IV-6, which was published in
1986, remember. I was surprised (and disappointed) not
to see this feature in MPW 3.0.
* The ability for tools to invoke scripts and other tools,
and to generally multitask within the MPW environment. System 7
will provide the IPC infrastructure (or so we keep getting told),
will MPW 4.0 take advantage of it?
Wouldn't it be luverly...
Lawrence D'Oliveiro
PC/networking consultant and sometime programmer
Computer Services Dept
University of Waikato
Hamilton
New Zealand
ldo@waikato.ac.nzchewy@apple.com (Paul Snively) (01/24/90)
In article <1990Jan23.065751.29303@peace.waikato.ac.nz> ldo@peace.waikato.ac.nz (Lawrence D'Oliveiro) writes: > Here's my list of what I'd like to see in future versions > of MPW. > > * The ability to use the contents of a window (or the current > selection within a window) as both input and output in the *same* > command. That way, I can do nifty things like reformat code > (which I've transferred from another machine) with > > Entab -d 8 -t 4 <"{Target}" >"{Target}" > > without having to mess around with intermediate temporary > files. At the moment, if you try this, you immediately lose > the portion of text you were trying to operate on. I'd be quite > happy if this new feature were to work only with open windows, > not with arbitrary files. This doesn't work??? Hang on a sec... (going off to try MPW 3)... Sure enough; it doesn't work. I'll pass this one along to the MPW team. As for it working only for open windows and not with arbitrary files, relax; it's no easier to work with windows only than it is with files in general. MPW implements a sophisticated external file system that makes open windows essentially override the files that they were opened from, which is why you can open a file, make changes, NOT save them, compile/link, and the changes will be in effect (good for prototyping ideas, lousy as a production technique, obviously). Thanks for the input! In article <1990Jan23.065751.29303@peace.waikato.ac.nz> ldo@peace.waikato.ac.nz (Lawrence D'Oliveiro) writes: > * The ability to extend the selection by holding down the > shift key while pressing the arrow keys, as per Inside > Plusintosh, pages IV-5 to IV-6, which was published in > 1986, remember. I was surprised (and disappointed) not > to see this feature in MPW 3.0. I'd always wondered about this too. In particular, I like the way that Macintosh Allegro Common Lisp deals with selections and editing (MACL essentially uses EMACS, but it also knows about selections, command-key equivalents, and the like). I'll check to see if a) there's an alternative way to extend selections from the keyboard or b) whether MPW will conform to Human Interface guidelines better in a future release. In article <1990Jan23.065751.29303@peace.waikato.ac.nz> ldo@peace.waikato.ac.nz (Lawrence D'Oliveiro) writes: > * The ability for tools to invoke scripts and other tools, > and to generally multitask within the MPW environment. System 7 > will provide the IPC infrastructure (or so we keep getting told), > will MPW 4.0 take advantage of it? This'd be easy if tools and scripts were applications in their own right, but they aren't. Tools come pretty close, though, so if MPW were revved so that tools were apps that got launched into their own layers, perhaps as "background-only" apps, and the interactive environment stuff were rewritten... hmmmmm... but that leaves scripts sorta out in the cold. Maybe that would be ok. I think this one needs some serious kicking around in the MPW team, but it's still nothing that I can promise (then again, none of this is). All good ideas; let's see what we can do about them. __________________________________________________________________________ Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. __________________________________________________________________________ C++ -- The language in which only friends can access your private members. __________________________________________________________________________
bowman@reed.UUCP (Eric Bowman) (02/04/90)
Speaking of Entab, maybe who ever's listening at Apple would consider not trashing the 'MPSR' resource when they fix the > Entab -d 8 -t 4 <"{Target}" >"{Target}" problem. I envisioned a nice little menu item "Entab Active" which was to execute: derez "{active}" >__tempRez Entab "{Active}" | Catenate > "{Active}" rez __tempRez -append -o "{Active}" in hopes of not trashing all the Mark'ed items, but, alas, this doesn't work (I don't think there's anything wrong...) ^^^^^ ("And now, my trusty assistant Beaker, will turn up the Bunsen Burner") In response to an earlier flicker -- ok, I don't like heirarchical menus either, but customizable menus is hardly a *toy* feature, and adding this capability to MPW would not be that hard. The choice to use MPW is frequently motivated by, among other things, the degree to which the user can customize the environment. Isn't a certain level of graphic intuitiveness the whole idea? (Sheesh - wadayado, debug your shell scripts in MacsBug?) ("Thank you, Beaker. Beaker?") ============================================================================== | The Insidious Uncle BoBo | ------------------------------------------------------------------------------ | "As I see it, my friends can access my private | | members in a public class..." | ============================================================================== | Eric Bowman -> | | ShitNet: bowman@reed.bitnet | | FarFromFreeNet: (503)234-7158 (Like I'll Really Answer) | | Disclaimer: "If my employer ever found out my opinions, well..." | /=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=
shap@delrey.sgi.com (Jonathan Shapiro) (02/05/90)
One of the things that has always bothered me about MPW is that its editor is hardwired in. I have used other editors, most recently vi and emacs, for a long time, and I find that moving to the mouse every two seconds to correct typos in the line above really cuts into my throughput. Also, the mac editor isn't programmable, so the hacks I have put together to do sophisticated indenting, etc. can't be done there. I would be willing to write my own editor if the interface could be published or if I could get it from Apple by asking for it. Any chance of this happening? Jon Shapiro
omullarn@oracle.oracle.com (Oliver Mullarney) (02/05/90)
In article <14044@reed.UUCP> bowman@reed.UUCP (Eric Bowman) writes: > >("And now, my trusty assistant Beaker, will turn up the Bunsen Burner") > >In response to an earlier flicker -- ok, I don't like heirarchical menus >either, but customizable menus is hardly a *toy* feature, and adding this >capability to MPW would not be that hard. The choice to use MPW is >frequently motivated by, among other things, the degree to which the >user can customize the environment. Isn't a certain level of graphic >intuitiveness the whole idea? (Sheesh - wadayado, debug your shell scripts >in MacsBug?) > >("Thank you, Beaker. Beaker?") > Customizable menus, I agree, is not a toy feature. Everything you can do should be in menus, including the 'aliases' you create for frequently used commands. This may come as a surprise to you, but MPW already does have customisable menus. What I ridiculed as a toy feature was the wish for customisable, _hierarchical_ menus. I would prefer that the people working on MPW spent their time fixing the bugs in the compilers, making tools more co-operative, talking to the SADE people to see if they can further integrate these two companion tools, not farting around with hierarchical menus. I am glad to say that, to the best of my knowledge, the MPW people are talking to the SADE people, working on the compilers etc. Not a word yet about hierarchical menus... As for debugging tools in MacsBug, I have had to do that (not very often, though even once is too often...) - try debugging an MPW tool using SADE and you will realise that life is just too short. Oliver (How come nobody else had any complaints about the compilers etc.? I'm feeling lonely). | Oliver Mullarney | "I have knowledge of Digital Watches, and soon I | | Oracle Corporation | shall have knowledge of Video Cassette Recorders" | | omullarn@oracle.com | Time Bandits | --------------- "Universally acknowledged to work just fine" ----------------
omh@cs.brown.edu (Owen M. Hartnett) (02/05/90)
Here's one thing that amazed me wasn't in there: Extend the selection in the active window by one character with shift right arrow. I scoured the manuals looking for it, and maybe it's there, but I sure couldn't find it. (this is, if it is under a different key). This is really a useful feature, and I use it all the time with LSP. -Owen Owen Hartnett omh@cs.brown.edu.CSNET Brown University Computer Science omh@cs.brown.edu uunet!brunix!omh "Don't wait up for me tonight because I won't be home for a month."
bowman@reed.UUCP (Eric Bowman) (02/05/90)
In article <1990Feb5.004034.6097@oracle.com>, omullarn@oracle.oracle.com (Oliver Mullarney) writes: > In article <14044@reed.UUCP> bowman@reed.UUCP (Eric Bowman) writes: [stuff] > >either, but customizable menus is hardly a *toy* feature, and adding this > >capability to MPW would not be that hard. The choice to use MPW is Actually, I meant that adding heirarchical menus would not be that hard. ^^^^^^^^^^^ I know MPW has customizable menus. I use them daily. I still think heirarchical menus would be nice for certain things, such as on a build menu, i.e. Build -> Regular Debug You're right about the compilers, at least the C compiler, which is the only one I've used extensively. I keep finding instances in the compiled code like: @1 move (a7)+,d0 @2 beq @3 @3 move on... Come on, Apple, what's this garbage? But, thank god, at least it's close to ANSI. ============================================================================== | The Insidious Uncle BoBo | ------------------------------------------------------------------------------ | "As I see it, my friends can access my private | | members in a public class..." | ============================================================================== | Eric Bowman -> | | ShitNet: bowman@reed.bitnet | | FarFromFreeNet: (503)234-7158 (Like I'll Really Answer) | | Disclaimer: "If my employer ever found out my opinions, well..." | /=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=
tim@hoptoad.uucp (Tim Maroney) (02/05/90)
In article <3566@odin.SGI.COM> shap@delrey.sgi.com (Jonathan Shapiro) writes: >One of the things that has always bothered me about MPW is that its >editor is hardwired in. Not really. You can use whatever editor you want (except possibly for Projector -- I haven't used it ye, so I don't know). The makefiles just look at mod dates. Now, in LightSpeed C, you're in a lot of trouble if you want to use another editor, but with MPW C, it's perfectly easy under MultiFinder. >I have used other editors, most recently vi and emacs, for a long >time, and I find that moving to the mouse every two seconds to correct >typos in the line above really cuts into my throughput. So learn to use the arrow keys! This is exactly the same way you move around in vi and emacs, after all. >Also, the mac >editor isn't programmable, so the hacks I have put together to do >sophisticated indenting, etc. can't be done there. How so? You can run both tools and scripts in the editor, and add your own keyboard shortcuts to do them if you like. There's not as much direct control over the text as in MLisp, but there's far more than in vi (which isn't really programmable, unless you count the ! command). You can give editor commands from scripts, and run tools which do whatever you want to the text. >I would be willing to write my own editor if the interface could be >published or if I could get it from Apple by asking for it. You can do it now. What's the problem? All that you have to use the MPW Shell for is a command line interpreter. Any editor will work with your makefiles. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "He goes on about the wailing and gnashing of teeth. It comes in one verse after another, and it is quite manifest to the reader that there is a certain pleasure in contemplating the wailing and gnashing of teeth, or else it would not occur so often." -- Bertrand Russell, "Why I Am Not a Christian"
shap@delrey.sgi.com (Jonathan Shapiro) (02/06/90)
Since Tim Maroney either didn't think about my request or assumes I'm foolish, let me expand on the editor problem. The essential problems with the MPW editor are twofold. First, it constantly makes me remove my hands from the home position on the keyboard. I am a computer-style touch typist (I type quickly, but not always accurately), and this reduces my effective throughput by at least a factor of five. Why? because there is no way to move up/down a line or left/right a character without reaching for either the mouse or the arrow keys. The arrow keys don't help. It isn't the distance to the mouse that's the problem. It's the fact that I must lift a hand, move it someplace else, then bring it back, all of which takes time and a mental reorientation to figure out what the hell I was up to. Even 'vi', which is pretty old as editors go, doesn't have this problem. This is a case where modality is appropriate; for some people the modality of moving the hand is worse than the modality of a modal interface. Second, the editor isn't programmable, which means that things like the indentation technology might best be described as primative, and a lot of things I have grown used to in more sophisitcated environments I must once again live without. So Tim suggests I use JOVE. Setting aside the issue of whether JOVE is a reasonable editor (I like it a lot better than vi, but the last time I used it it sure wasn't EMACS yet), this doesn't address the problem of integration. One of the things that is very well done in the MPW environment is the fact that every window is a text editor window. I like the ability to compile a live file without the need to save it - it makes syntax errors cheap to fix, and it feels very good. Using JOVE I lose this capability. >>Also, the mac >>editor isn't programmable, so the hacks I have put together to do >>sophisticated indenting, etc. can't be done there. > >How so? You can run both tools and scripts in the editor, and add your >own keyboard shortcuts to do them if you like. I encourage you to attempt to add a keyboard shortcut for "backwards character" without the use of a macro facility (it can be done). I encourage you to then try "page down", which can't be done even with a keyboard macro, and certainly can't be done with a shortcut. How about "next-window"? Indenting is most effective when interactive. The ability to run a tool to indent things after the fact just doesn't give the right kind of support. The editor should, if MPW is designed right, be a separate code resource(s), and should have a well-defined interface taht could be implemented by an alternative. I would be happy to try and do this myself and might even consider giving the results away (depending on the complexity) if I can get some help from Apple on implementing it. Jonathan Shapiro
d6maca@dtek.chalmers.se. (Martin Carlberg) (02/06/90)
In article <1990Feb5.004034.6097@oracle.com> omullarn@oracle.com (Oliver Mullarney) writes: >As for debugging tools in MacsBug, I have had to do that (not very often, >though even once is too often...) - try debugging an MPW tool using SADE >and you will realise that life is just too short. What? I have never had any problems debugging MPW tools with SADE, I do that all the time. Should I have problems? - Martin Carlberg - Chalmers University of Technology, Gothenburg, Sweden
wilson@csli.Stanford.EDU (Nathan Wilson) (02/06/90)
shap@delrey.sgi.com (Jonathan Shapiro) writes: > The essential problems with the MPW editor are twofold. > First, it constantly makes me remove my hands from the home position > on the keyboard. I am a computer-style touch typist (I type quickly, > but not always accurately), and this reduces my effective throughput > by at least a factor of five. > ... Actually, I've found the MPW editor to be only slightly less programmable than Fred in Allegro Common Lisp or the gnuemacs editor. Granted it isn't truely programmable, but if you're willing to deal with a bit of gross syntax you can go a long way. > I encourage you to attempt to add a keyboard shortcut for "backwards > character" without the use of a macro facility (it can be done). I > encourage you to then try "page down", which can't be done even with a > keyboard macro, and certainly can't be done with a shortcut. In the MPW Shell it is trival: addmenu Extras 'Back One' 'find <option>-6<option>-!1 {active}' Adding a command equivalent for this is trivial. I personally use QuicKeys so I can bind the menu item to <control>-B. For this case I actually just bind <control>-B to left-arrow. Anyway, with this and a few similar hacks I can almost believe that I'm using emacs. It would be nice if I didn't have to use QuicKeys for changing the key bindings but I can live with it. If anybody's interested in my hacks I would be happy to post them. As for "page down", I haven't tried it but it shouldn't be all that hard let's try: addmenu Extras 'Next Page/<option>-v' <option>-d '(evaluate "`sizewindow {active}`" =~ <option>-d /<option>-x[0-9]+ ([0-9]+)<option>-r1<option>-x/) <option>-d > dev:null ; <option>-d (evaluate "`format {active}`" =~ <option>-d /<option>-x-s ([0-9]+)<option>-r2 <option>-x/) <option>-d > dev:null ; <option>-d find !`evaluate {<option>-r1} div ({<option>-r2} + 2)`<option>-j {active}' Hmm, seems to work pretty well for me. By way of explanation: The first line adds the menu, and menu item and gives it the command equivalent <command><option>-v. The second, third and fourth lines extract the horizontal window size from the result of SizeWindow. The fifth line uses the horizontal window size to compute the number of lines per page and then moves to the line on page below the current selection. You might be able to find a better way to compute the line height than just adding a fudge factor (in this case 2) to the {fontsize} but this is at least close. Also you probably would want to subtract the height scrollbar of the horizontal scrollbar from the window height. Actually this isn't 'true' next page since it goes from the current selection rather than what is currently visible in the window. On the other hand, gnuemacs doesn't even make this distinction to I think we can finesse it. I can't find anything that gives you the visible region rather than the selection region. It seems that these should be separately controllable from tools. > How about "next-window"? RTFM, unless you mean something other than RotateWindows. You can also get the back window to the front with: (evaluate {windows} =~ /([<option>-l,]+)<option>-r1,<option>-x/) <option>-d > dev:null ; <option>-d open {<option>-r1} > Indenting is most effective when interactive. The ability to run a > tool to indent things after the fact just doesn't give the right kind > of support. This seems more of a problem, but as I haven't needed anything weird in this regard it hasn't bothered me. I'm just thankful that it doesn't impose an indenting discipline like LSP and I presume LSC. > The editor should, if MPW is designed right, be a separate code > resource(s), and should have a well-defined interface that could be > implemented by an alternative. I haven't hacked any tools so I don't know whether this is already possible, but it seems that just some facility that allowed tools to catch events would be all you would need. Nathan Wilson Teleos Research nathan%teleos.com@ai.sri.com
ccc_ldo@waikato.ac.nz (02/06/90)
Subject: Re: MPW wish list
References: <1990Jan23.065751.29303@peace.waikato.ac.nz>, <1990Jan25.003918.2359@cs.UAlberta.CA>
In <1990Jan25.003918.2359@cs.UAlberta.CA>, simon@alberta.uucp (Simon Tortike)
suggests, as an alternative to the command sequence
Entab -d 8 -t 4 <"{Target}" >"{Target}"
that I use
Entab -d 8 -t 4 < "{Target}" | Catenate > "{Target}"
instead.
Fine, this works now. But it might not work under a future multitasking
version of MPW. I want a less kludgy way of doing it.bowman@reed.UUCP (Eric Bowman) (02/06/90)
I've never had any problems debugging Tools in SADE either. (Thank god for the instructions in the NewUser file...) ============================================================================== | The Insidious Uncle BoBo | ------------------------------------------------------------------------------ | "As I see it, my friends can access my private | | members in a public class..." | ============================================================================== | Eric Bowman -> | | ShitNet: bowman@reed.bitnet | | FarFromFreeNet: (503)234-7158 (Like I'll Really Answer) | | Disclaimer: "If my employer ever found out my opinions, well..." | /=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=\=/=
philip@Kermit.Stanford.EDU (Philip Machanick) (02/06/90)
I find this discussion a bit disturbing. There's a consistant thread that says, "Why isn't MPW more like unix?" My question is, "Why is it so much like unix?" I've used more programming environments than I care to remember, and the LS environments are by far the biggest step forward in my experience. MPW doesn't add anything to the state of the art; the LS environments do for personal computing programming what the Mac did for the user. What I would like to know is how an environment of the LS variety could best be extended to provide the functionality of unix, without losing its low learning threshold. My first thought is inspiration is to be found more in environments like Smalltalk and Interlisp, which are more obvious influences on the Mac style of computing. Philip Machanick philip@pescadero.stanford.edu
omullarn@oracle.oracle.com (Oliver Mullarney) (02/07/90)
In article <1990Feb5.204443.20878@mathrt0.math.chalmers.se> d6maca@dtek.chalmers.se (Martin Carlberg) writes: >In article <1990Feb5.004034.6097@oracle.com> omullarn@oracle.com (Oliver Mullarney) writes: >>As for debugging tools in MacsBug, I have had to do that (not very often, >>though even once is too often...) - try debugging an MPW tool using SADE >>and you will realise that life is just too short. > >What? I have never had any problems debugging MPW tools with SADE, I do that >all the time. Should I have problems? > I didn't say I had problems - I said life was too short. It just takes a goddamn age to step through your tools source when you are 'debugging' MPW. Sometimes I just convert my tool to an application with hardwired command line parameters so I can debug it as an application, and save my old age for sitting by the fire on a rocking chair, not waiting for SADE to return from a STEP command. BTW - has anyone else noticed the very strange selection behaviour when you start debugging a running MPW. OK - you have MPW running with the command line to launch your MPW tool sitting there in the WorkSheet. Start up SADE; do the usual: Directory.../Source.../Target 'MPW Shell' using 'MyTool.SYM' etc. Then: Launch 'MPW Shell' Now try to select the line with your tool's launch command on it by triple clicking. The results are ... interesting. Someone else said they would like to be able to split windows? Yup - that would be nice, and as far as I have heard, is scheduled for the next release. A decent 'lib' tool, however, is not. :-( Oliver | Oliver Mullarney | "I have knowledge of Digital Watches, and soon I | | Oracle Corporation | shall have knowledge of Video Cassette Recorders" | | omullarn@oracle.com | Time Bandits | --------------- "Universally acknowledged to work just fine" ----------------
macduff@cbnewse.ATT.COM (Roger R. Espinosa) (02/08/90)
In article <1990Feb6.065019.22828@Neon.Stanford.EDU>, philip@Kermit.Stanford.EDU (Philip Machanick) writes: > I find this discussion a bit disturbing. There's a consistant thread > that says, "Why isn't MPW more like unix?" > > My question is, "Why is it so much like unix?" Well, I grew up on UNIX, so I don't mind the UNIX-like nature of it. :-) > > I've used more programming environments than I care to remember, and the > LS environments are by far the biggest step forward in my experience. This is a really subjective matter. For me, I couldn't do a *thing* in the LSP environment. Don't ask me why. When I first booted up the thing (and I *was* *really* excited about using LSP, let me tell you...), I thought the editor was really nice, the way it automatically indented and high-lited everything. This, for some reason, started working against me: I found that (for *me*. I'm not sure if this is reproduceable, or why I kept getting it) if I kept doing a "semi-colon <return>", just like I'd do in vi, the editor would stop accepting input after 66 lines or so. > MPW doesn't add anything to the state of the art; the LS environments do On the contrary. I'm sitting here at work using UNIX and wishing that it was more like MPW in some ways. I really appreciate the MPW editor/windows, which is very similar to MacScheme's environment. > for personal computing programming what the Mac did for the user. What I > would like to know is how an environment of the LS variety could best be > extended to provide the functionality of unix, without losing its low > learning threshold. My first thought is inspiration is to be found more I'm using TML Pascal with MPW right now, and I haven't had to open the MPW manual beyond installing it, for most things. The TML project menu takes care of setting up the compilation lines for me, so there was no learning curve there. In many ways, I don't think using TML is any different than using LSP (no real interfact change via menus), except I like the editor more. NOTE: I'm not trying to trash LSP. My experiences with LSP were very frustrating to *me*, but I realize that a lot of the frustration was from me not being to mesh with the LSP environment. What makes MPW work for me, aside from the zillion and one times I"ve said "I like the editor better," is that you can make different types of tools (scripts, tools, and applications), so prototyping (seems to me) is easier, and the tools can interact with each other. It didn't seem that way (to me) in LSP; I've never seen LSC. I think that to get the power of UNIX, you have to accept some sort of learning threshold. Complex makefiles and the ilk don't translate well into menus, I don't think. The "only-menu" mode may not be acceptable, because it's too focused of an environment. Smalltalk, and MacScheme (I'd guess) differ from traditional languages, though, in that in these environments, there's no fine line between the environment and the language: in MacScheme, for instance, many of the menu items were merely calling MacScheme procedures. MPW (or LSP/C...) aren't calling Pascal/ C/whatever procedures when you do their menu items, or commands. > Philip Machanick > philip@pescadero.stanford.edu Roger rre@ihlpn.ATT.COM DISCLAIMER: Heck, I'm not trying to be an expert or anything on this subject. Obviously, the LSP/C environemnts *must* work for people, or else there couldn't be nice big ads in MacWorld about all the products made with them. Believe me, when I look at the price of MPW, I wish it would work for me, too :-(
cy@dbase.A-T.COM (Cy Shuster) (02/08/90)
In article <1990Jan25.191441.26280@oracle.com> omullarn@oracle.com (Oliver Mullarney) writes: >- Incremental linking would be nice. Waiting 15 minutes to relink after > a change of one object file is very boring. Hear, hear! Especially with virtual memory coming, applications are growing larger all the time... and the links, exponentially! --Cy--
pasek@ncrcce.StPaul.NCR.COM (Michael A. Pasek) (02/09/90)
In <1990Feb6.065019.22828@Neon.Stanford.EDU> Philip Machanick writes: >I find this discussion a bit disturbing. There's a consistant thread >that says, "Why isn't MPW more like unix?" >My question is, "Why is it so much like unix?" >[remainder deleted] Funny, I was about to ask the same question when Philip's article showed up. I can guess, though -- Apple hired a bunch of (then) recent CompSci grads to do programming for them about 4 or 5 years ago. M. A. Pasek Software Development NCR Comten, Inc. (612) 638-7668 MNI Development 2700 N. Snelling Ave. pasek@c10sd3.StPaul.NCR.COM Roseville, MN 55113
erics@eleazar.dartmouth.edu (Eric Schlegel) (02/09/90)
>In article <1990Jan25.191441.26280@oracle.com> omullarn@oracle.com (Oliver Mullarney) writes: >>- Incremental linking would be nice. Waiting 15 minutes to relink after >> a change of one object file is very boring. > Even better - incremental compilation. Forget to put a semicolon after one line in your 2000 line MacApp include file? No problem. The compiler recompiles _only that one line_ instead of compiling the entire program. This can be done, but it requires a significant amount of compiler rewrite. The basic idea is for the compiler to keep a record of all variable, type, function declarations, etc, where lines begin and end in the file, and what variables/functions are referenced by each statement in the program. Then by determining which source lines changed, you determine which references may have changed (sort of like recalcing a spreadsheet) and only recompile the affected lines. I read any article about a year ago saying that the MPW team was looking into incremental compilation. I've no idea if anything's coming, but it sure would be nice. -eric -- Eric Schlegel '90 | "Never underestimate the bandwidth of a eric.schlegel@dartmouth.edu | station wagon full of tapes."
drc@claris.com (Dennis Cohen) (02/09/90)
erics@eleazar.dartmouth.edu (Eric Schlegel) writes: >>In article <1990Jan25.191441.26280@oracle.com> omullarn@oracle.com (Oliver Mullarney) writes: >>>- Incremental linking would be nice. Waiting 15 minutes to relink after >>> a change of one object file is very boring. >> >Even better - incremental compilation. Forget to put a semicolon after one >line in your 2000 line MacApp include file? No problem. The compiler recompiles >_only that one line_ instead of compiling the entire program. I think that a better solution for such simple errors would be one that was in one of the first Pascal compilers I ever used (1979). The University of Wisconsin's Univac 1100 compiler gave a warning message with the context and continued to compile, treating the source as though the semicolon were there. If Fischer and LeBlanc could do that on a Univac 11 or 12 years ago, it seems that we should have compilers that do that now. Some errors were non- recoverable; however, I've missed that "friendliness" in every compiler I've used since then. Dennis Cohen Claris Corp. **************************************************** Disclaimer: Any opinions expressed above are _MINE_! ****************************************************
dorner@pequod.cso.uiuc.edu (Steve Dorner) (02/09/90)
In article <10865@claris.com> drc@claris.com (Dennis Cohen) writes: >The University of >Wisconsin's Univac 1100 compiler gave a warning message with the context and >continued to compile, treating the source as though the semicolon were there. The other way to look at that is, if a compiler knows there ought to be a semicolon at some point in your program, then the semicolon could be safely removed from the language definition, as not adding anything meaningful to the language. :-) Seriously, this really isn't an option in C, where just about anything is possible just about anywhere; there's very little a compiler could infer. Thus there are so few cases where the thing might be useful that it's not worth doing. (My very favorite C compiler inference was the way some UNIX compilers disambiguated declarations like: int i=-1; Since "=-" used to be how one wrote "-=", the compiler had a choice. What it did was: int i =- 1; # warning, old fashioned assignment operator # syntax error in initializer (illegal operator) I found this an amusingly wrongheaded thing to do in the name of backwards compatibility.) -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner
isr@rodan.acs.syr.edu ( ISR group account) (02/09/90)
In article <19240@dartvax.Dartmouth.EDU> erics@eleazar.dartmouth.edu (Eric Schlegel) writes: >>In article <1990Jan25.191441.26280@oracle.com> omullarn@oracle.com (Oliver Mullarney) writes: >>>- Incremental linking would be nice. Waiting 15 minutes to relink after >>> a change of one object file is very boring. > >Even better - incremental compilation. Forget to put a semicolon after one >line in your 2000 line MacApp include file? No problem. The compiler recompile >_only that one line_ instead of compiling the entire program. Maybe incremental compiling down to the line level would be a bit difficult, but certainly having it at the routine level would not be that difficult. That way as long as arguments, return values, and globals all had the same TYPE as before, all you have to update are the address's whereever they where referenced. (just stick the new routine after the last old one, update all addresses) Of course, you'd only want to do this a few times before you would do a real compile/link to prevent nightmares from ocurring. -- Mike Schechter, Computer Engineer,Institute Sensory Research, Syracuse Univ. InterNet: isr@rodan.acs.syr.edu Bitnet: SENSORY@SUNRISE
matthews@eleazar.dartmouth.edu (Jim Matthews) (02/10/90)
In article <10865@claris.com> drc@claris.com (Dennis Cohen) writes: >I think that a better solution for such simple errors would be one that was >in one of the first Pascal compilers I ever used (1979). The University of >Wisconsin's Univac 1100 compiler gave a warning message with the context and >continued to compile, treating the source as though the semicolon were there. Mac compilers could go a long way towards being more helpful in dealing with errors. My pet peeve is when Think C tells me that a function call is incompatible with a prototype, without telling me which parameter is wrong or what type it was expecting. The compiler has that information, and it could do much better than issue "wrong, guess again" error messages. Jim Matthews Dartmouth Software Development
erics@eleazar.dartmouth.edu (Eric Schlegel) (02/10/90)
In article <10865@claris.com> drc@claris.com (Dennis Cohen) writes: >erics@eleazar.dartmouth.edu (Eric Schlegel) writes: >>Even better - incremental compilation. Forget to put a semicolon after one >>line in your 2000 line MacApp include file? No problem. The compiler recompiles >>_only that one line_ instead of compiling the entire program. > >I think that a better solution for such simple errors would be one that was >in one of the first Pascal compilers I ever used (1979). The University of >Wisconsin's Univac 1100 compiler gave a warning message with the context and >continued to compile, treating the source as though the semicolon were there. That would also be a nice feature to have. Incremental compilation really gets nice, though, when you consider this: change the implementation of a function, and only the function is recompiled. Change the function interface, and the compiler is smart enough to recompile the function and every statement that calls the function - but nothing else. And another wish for MPW - I want a faster editor! The editor is very easy to type ahead of, even on a II-class machine. This is especially a problem when the text displayed in a window is wider than the window - this seems to slow down the editor drastically. -eric -- Eric Schlegel '90 | "Never underestimate the bandwidth of a eric.schlegel@dartmouth.edu | station wagon full of tapes."
omullarn@oracle.oracle.com (Oliver Mullarney) (02/10/90)
In article <10865@claris.com> drc@claris.com (Dennis Cohen) writes: > >I think that a better solution for such simple errors would be one that was >in one of the first Pascal compilers I ever used (1979). The University of >Wisconsin's Univac 1100 compiler gave a warning message with the context and >continued to compile, treating the source as though the semicolon were there. >If Fischer and LeBlanc could do that on a Univac 11 or 12 years ago, it seems >that we should have compilers that do that now. Some errors were non- >recoverable; however, I've missed that "friendliness" in every compiler I've >used since then. > This does lead to some questions - What counts as a 'simple' error? There are many cases where there are a number of possible corrections - forgetting a semi-colon may be simply that, or it may be that the remainder of a statement was forgotten or deleted by accident. Matching parenthesis in a logical condition can be done any number of ways, and semantic knowledge is necessary to do it right. That's why _we_ are still writing software, not Macs. :-) How should compilers react to such errors? Guess? Should the compiler modify the source file? If it does, then you will have to go back and undo the changes if the compiler screwed up. However, if you don't notice the warning, you will be left with a source file which compiles correctly, even though it does not do what you intended. If the compiler does not alter the source, then you will have to remember to go back and do that, thereby changing the modification date and making the newly produced application out of date with the source. Another recompile and link... As systems get more automated, one has to very careful what one allows these systems to do. Most of them are very stupid, especially compilers (or have I just been using MPW C for too long :-)). Just look at the error messages you get all the time - these machines are _really_ lost, and I for one am not going to trust them to get me out of the woods. Oliver | Oliver Mullarney | "Death wears a big hat, | | Oracle Corporation | 'cos he's a big bloke" | | omullarn@oracle.com | Tokyo Storm Warning, Elvis Costello | --------------- "Universally acknowledged to work just fine" ----------------
d88-jwa@nada.kth.se (Jon Watte) (02/13/90)
In article <19265@dartvax.Dartmouth.EDU> matthews@eleazar.dartmouth.edu (Jim Matthews) writes: >Mac compilers could go a long way towards being more helpful in dealing >with errors. My pet peeve is when Think C tells me that a function call >is incompatible with a prototype, without telling me which parameter is _My_ pet peeve is that THINK C halts at the first error encountered. It could give a list of errors, like the link error list, and have a "Next Error" menu item / key (Like EMACS !) h+ -- --- Stay alert ! - Trust no one ! - Keep your laser handy ! --- h+@nada.kth.se == h+@proxxi.se == Jon Watte longer .sig available on request
pepke@gw.scri.fsu.edu ("Eric Pepke") (02/13/90)
In article <2930@draken.nada.kth.se> d88-jwa@nada.kth.se (Jon Watte) writes: > _My_ pet peeve is that THINK C halts at the first error encountered. > It could give a list of errors, like the link error list, and have a > "Next Error" menu item / key (Like EMACS !) De gustibus non disputandum est. Personally, I like this feature. Except when I am converting a large code from some other source, I seldom get more than one or two errors in a file. Part of the reason for this is that Think C makes checking syntax quite painless, so I do it often. I have used boatloads of other, more traditional compilers, both C and Pascal, on a variety of computers. When I see a cascading list of error messages, nearly always there is only one real error, and the rest are artifacts of the compiler's error recovery algorithm. It is sometimes easy to see which ones are specious by comparing the descriptions, but I would rather not be bothered with the red herrings. Your mileage may vary. Now, if they would only improve the code generation... Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (02/15/90)
In article <2028@rodan.acs.syr.edu> isr@rodan.acs.syr.edu (Michael S. Schechter - ISR group account) writes: >In article <19240@dartvax.Dartmouth.EDU> erics@eleazar.dartmouth.edu (Eric Schlegel) writes: -->In article <1990Jan25.191441.26280@oracle.com> omullarn@oracle.com (Oliver Mullarney) writes: --->- Incremental linking would be nice. Waiting 15 minutes to relink after ---> a change of one object file is very boring. ->Even better - incremental compilation. Forget to put a semicolon after one ->line in your 2000 line MacApp include file? No problem. The compiler recompile ->_only that one line_ instead of compiling the entire program. >Maybe incremental compiling down to the line level would be a bit difficult, >but certainly having it at the routine level would not be that difficult. >That way as long as arguments, return values, and globals all had the >same TYPE as before, all you have to update are the address's whereever >they where referenced. Incremental (routine level) compilation, with insertion of the new routine INTO A RUNNING PROGRAM is available with Jasik's "The Debugger". The Incremental Build System lets you stop the program, do a side-door exit to MPW, recompile the offending routine, link it back into the program, and continue execution. Especially nice when it takes a long time to execute down to the problem area. All that and source level debugging too. Marc Kaufman (kaufman@Neon.stanford.edu) [a user of The Debugger and IBS]
peirce@claris.com (Michael Peirce) (02/16/90)
In article <1990Feb9.220233.4211@oracle.com> omullarn@oracle.com (Oliver Mullarney) writes: >In article <10865@claris.com> drc@claris.com (Dennis Cohen) writes: >> >>I think that a better solution for such simple errors would be one that was >>in one of the first Pascal compilers I ever used (1979). The University of >>Wisconsin's Univac 1100 compiler gave a warning message with the context and >>continued to compile, treating the source as though the semicolon were there. >>If Fischer and LeBlanc could do that on a Univac 11 or 12 years ago, it seems >>that we should have compilers that do that now. Some errors were non- >>recoverable; however, I've missed that "friendliness" in every compiler I've >>used since then. >> >This does lead to some questions - >What counts as a 'simple' error? There are many cases where there are a number >of possible corrections - forgetting a semi-colon may be simply that, or it >may be that the remainder of a statement was forgotten or deleted by accident. >Matching parenthesis in a logical condition can be done any number of ways, >and semantic knowledge is necessary to do it right. That's why _we_ are >still writing software, not Macs. :-) > >How should compilers react to such errors? Guess? > >Should the compiler modify the source file? If it does, then you will have to >go back and undo the changes if the compiler screwed up. However, if you >don't notice the warning, you will be left with a source file which compiles >correctly, even though it does not do what you intended. If the compiler >does not alter the source, then you will have to remember to go back and do >that, thereby changing the modification date and making the newly produced >application out of date with the source. Another recompile and link... > >As systems get more automated, one has to very careful what one allows these >systems to do. Most of them are very stupid, especially compilers (or have I >just been using MPW C for too long :-)). Just look at the error messages you >get all the time - these machines are _really_ lost, and I for one am not >going to trust them to get me out of the woods. Back in the old days (two years ago :-) ) back at DEC we used an Ada compiler that made these types of suggestions about fixing source code. When we were using DEC's Language Sensitive Editor (LSE) the compiler would tell LSE about the suggested change to the source. LSE would then show you the change and ask you if you wanted to keep it or dump it. Because of the tight coupling of the compiler and LSE it all worked out very nicely. I don't see why MPW couldn't be enhanced to provide this type of thing -- just a little more work by the developers! :-) Claris Corp. | Michael R. Peirce -------------+-------------------------------------- | 5201 Patrick Henry Drive MS-C4 | Box 58168 | Santa Clara, CA 95051-8168 | (408) 987-7319 | AppleLink: peirce1 | Internet: peirce@claris.com | uucp: {ames,decwrl,apple,sun}!claris!peirce