gft_robert@gsbacd.uchicago.edu (opcode ranger) (02/13/91)
-- Yesterday there were some announcements made regarding new Apple development products (MacApp 3.0, etc). One of them caught my eye: I think it's called SourceBug. Does anyone know anything about it? How good is it? What does it do? Does it replace SADE? Is it now available from APDA? (Lotta questions!). Robert ============================================================================ = gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to = = * all my opinions are * compute" = = * mine * -Kraftwerk = ============================================================================
boerned@mist.CS.ORST.EDU (Dan Boerner) (02/13/91)
I was at the MADA Conference last week and saw a quick demo of SourceBug the new source level debugger from Apple. I can tell you that it was not developed at Apple but was acquired and is now being improved. The version they showed was a d19 release. My understanding is that it will replace SADE. It has a nice multiple views feature that will allow you to see the source and the assembly in two separate but synchronized windows. Single stepping at the source and assembly level is supported. I seem to remember some sort of a browser for examining variables. I can't give you any great details about its technical merits but at least from a usability standpoint it seems to be a step forward. I believe they will be shipping a Beta or Alpha version on the next ETO CD-ROM. Sorry I can't remember more, does someone from Apple want to do a better job (Keith?) --Dan P.S. SourceBug won the dubious distinction as the worst new product name of the conference.
ksand@Apple.COM (Kent Sandvik) (02/13/91)
In article <1991Feb13.010016.6901@lynx.CS.ORST.EDU> boerned@mist.CS.ORST.EDU (Dan Boerner) writes: >P.S. SourceBug won the dubious distinction as the worst new product name of >the conference. Yeah, MikesBug and LadyBug were quite cool as names... :-) Kent -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "C++ is a write-only language, I can write programs in C++ but I can't read any of them".
anders@verity.com (Anders Wallgren) (02/13/91)
In article <1991Feb13.010016.6901@lynx.CS.ORST.EDU>, boerned@mist (Dan Boerner) writes: >My understanding is that it will replace SADE. It has a nice multiple views >feature that will allow you to see the source and the assembly in two >separate but synchronized windows. Single stepping at the source and assembly >level is supported. I seem to remember some sort of a browser for examining >variables. I can't give you any great details about its technical merits but >at least from a usability standpoint it seems to be a step forward. No, it will not be replacing SADE. It is meant to be an everyday tool, but SADE will still stay around. The phrase I heard used was "80% solution..."
russotto@eng.umd.edu (Matthew T. Russotto) (02/13/91)
In article <1991Feb13.050326.24115@verity.com> anders@verity.com (Anders Wallgren) writes: > >No, it will not be replacing SADE. It is meant to be an everyday >tool, but SADE will still stay around. The phrase I heard used was >"80% solution..." Maybe they should have called it Standard Apple Debugging Incomplete SubseT -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
drc@claris.com (Dennis Cohen) (02/13/91)
> The version they showed was a d19 release. At Software Development '91, they are showing an Alpha1 version (1.0a1). The window still says LadyBug and you are still unable to see your source and assembly side-by-side or even simultaneously. I hope they fix that before it goes out on E.T.O. (the source/asm problem, I mean -- I like the name LadyBug). -- | Dennis Cohen drc@claris.com COHEN2 AFC DCohen 71076,1377 | Internet AppleLink AmerOnline CompuServe | Disclaimer: Any unattributed opinions expressed above are _MINE_!
dorner@pequod.cso.uiuc.edu (Steve Dorner) (02/14/91)
In article <1991Feb13.050326.24115@verity.com> anders@verity.com (Anders Wallgren) writes: >No, it will not be replacing SADE. It is meant to be an everyday >tool, but SADE will still stay around. The phrase I heard used was >"80% solution..." Could somebody describe the new debugger a bit more? How is it different from SADE? Apple is going to have TWO source-level debuggers, and one of them is going to be SADE? Isn't that kind of like having two lines of mid-sized cars, one of them being an Edsel? SADE is the worst source-level debugger I have ever used. It has a few nice ideas, but some of it is so bizarre that I can't imagine why anyone wants to do anything but trash it. I know it's programmable, and maybe I could fix it if I spent a few months writing SADE procedures, but I don't *WANT* to program my debugger, I want to debug my program! Anybody want to port gdb? -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
keith@Apple.COM (Keith Rollin) (02/14/91)
In article <141@claris.com> drc@claris.com (Dennis Cohen) writes: > >> The version they showed was a d19 release. > >At Software Development '91, they are showing an Alpha1 version (1.0a1). >The window still says LadyBug and you are still unable to see your source and >assembly side-by-side or even simultaneously. I hope they fix that before it >goes out on E.T.O. (the source/asm problem, I mean -- I like the name LadyBug). You _can_ see both source and assembly - simlutaneously and side by side. You just can't do it in the same window. Bring up two views on the same procedure. The easiest way to do this is to clone the source code view by option-clicking on the browser pane and dragging off a new view. Then select the menu option that shows it as assembly. Stepping with that new window in the front will single step by a single assembly instruction. Making the source window active will step by a single Pascal or C statement. In both cases, the inactive window will be kept in sync. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
mneerach@iiic.ethz.ch (Matthias Ulrich Neeracher) (02/14/91)
In article <1991Feb13.215508.20111@ux1.cso.uiuc.edu>, dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >SADE is the worst source-level debugger I have ever used. It has a few >nice ideas, but some of it is so bizarre that I can't imagine why >anyone wants to do anything but trash it. SADE is the *best* source-level debugger *I* haver ever used (and yes, I have used gdb quite a lot). The earlier versions were terribly slow, but this has improved a lot. Matthias -- Matthias Neeracher mneerach@iiic.ethz.ch "These days, though, you have to be pretty technical before you can even aspire to crudeness." -- William Gibson, _Johnny Mnemonic_
dorner@pequod.cso.uiuc.edu (Steve Dorner) (03/02/91)
In article <25022@neptune.inf.ethz.ch> mneerach@iiic.ethz.ch writes: >In article <1991Feb13.215508.20111@ux1.cso.uiuc.edu>, dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >SADE is the *best* source-level debugger *I* haver ever used (and yes, I >have used gdb quite a lot). The earlier versions were terribly slow, but >this has improved a lot. Please tell me how to do the following things: 1. Use arbitrary expressions in the 'watch variable' window. 2. See variable histories (like Watch Variable, but without erasing the old values). 3. Use C syntax for structures and casts (trivial cases work, not complicated ones). 4. Show me local variables UP the stack from the current context. (This is the A#1 defect of SADE. Or do you like "Sorry, that variable is in a register"?) 5. Show me argument lists on stack backtraces. 6. Let me decide what base I want numbers printed in. 7. Actually PRINT things in windows without doing a 'full stop': break foo.(1) begin bar end Doesn't print anything until a full break is encountered. Full breaks engender major switches, screwing up window contents no end. 8. set breaks by source line number (something I can ask my editor for) rather than by executable statement number (which FORCES me to open the file with SADE to discover). 9. Either save or don't save the 'junk' windows (worksheet, variable watch, values); quit bugging me about them. 10. sc7 I could probably fix 1 and 2, and maybe 9 and 10, if I wanted to spend a few days debugging SADE scripts. 3-8 are just plain out, so far as I can tell. (There may be more capabilities than I'm aware of, since the manual is pretty, but superficial.) These are the things off the top of my head that drive me NUTS about SADE. Even dbx (let alone gdb) can do most of them with a minimum of pain. Am I all alone in wanting these things? Am I all alone in thinking the SADE environment is kind of *weird*? Yes, SADE has gotten better in terms of speed; dramatically so. I still find it an extremely clumsy debugger. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
ksand@Apple.COM (Kent Sandvik) (03/02/91)
In article <25022@neptune.inf.ethz.ch> mneerach@iiic.ethz.ch writes: >In article <1991Feb13.215508.20111@ux1.cso.uiuc.edu>, dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >>SADE is the worst source-level debugger I have ever used. It has a few >>nice ideas, but some of it is so bizarre that I can't imagine why >>anyone wants to do anything but trash it. >SADE is the *best* source-level debugger *I* haver ever used (and yes, I >have used gdb quite a lot). The earlier versions were terribly slow, but >this has improved a lot. [now is my turn, boys and girls] SADE is the *most extended* source-level debugger available for MacOS development. Sure SourceBug, Think-Debugger and Steve Jasik are more userfriendly, but the possibility to extend the functionality is one of the main existense reasons for SADE. Sometimes it makes sense to write testing/debugging scripts - but sometimes it does not make sense at all. Kent -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "C++ was given to mankind, so that we might learn patience"
mneerach@iiic.ethz.ch (Matthias Ulrich Neeracher) (03/05/91)
In article <1991Mar2.015219.8298@ux1.cso.uiuc.edu>, dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >Please tell me how to do the following things: Of course you are right, I can't do most of these things adequately either, but I had the impression I got used to most of it. >1. Use arbitrary expressions in the 'watch variable' window. I circumvent this by manually selectiong and executing lines in the worksheet. >2. See variable histories (like Watch Variable, but without erasing the old >values). See #1. >3. Use C syntax for structures and casts (trivial cases work, not complicated >ones). >4. Show me local variables UP the stack from the current context. (This >is the A#1 defect of SADE. Or do you like "Sorry, that variable is in >a register"?) >5. Show me argument lists on stack backtraces. >6. Let me decide what base I want numbers printed in. >7. Actually PRINT things in windows without doing a 'full stop': > break foo.(1) begin > bar > end > Doesn't print anything until a full break is encountered. Full breaks > engender major switches, screwing up window contents no end. I don't have a fix for any of these. Especially #6 annoys me very much, too. >8. set breaks by source line number (something I can ask my editor for) > rather than by executable statement number (which FORCES me to open > the file with SADE to discover). I can't do this, but I've never needed it. >9. Either save or don't save the 'junk' windows (worksheet, variable watch, > values); quit bugging me about them. I think I fixed this at least for the worksheet. Involves just changing the Quit script. >10. sc7 I berlieve I have something like this, but rarely need it. >I could probably fix 1 and 2, and maybe 9 and 10, if I wanted to spend a >few days debugging SADE scripts. 3-8 are just plain out, so far >as I can tell. (There may be more capabilities than I'm aware of, >since the manual is pretty, but superficial.) The scripts could use some work. I'm quite sure that 1,2,9,10 and probably even 8 could be fixed if Apple would provide some decent scripts with SADE (Apple... are you listening ?). 3 seems almost impossible in a multi language debugger. 4 seems to be very hard to do (Actually, it should be possible, but Apple probably doesn't want to copyleft SADE :-). 5,6 and 7 should be possible. >These are the things off the top of my head that drive me NUTS >about SADE. Even dbx (let alone gdb) can do most of them with a minimum >of pain. Am I all alone in wanting these things? Am I all alone in >thinking the SADE environment is kind of *weird*? It's a pity SADE can't do the simple things well, as it's quite good at the complicated ones. What I like about SADE is the mouse support and the scripting language; in terms of standard scripts and menus, SADE would make the Marquis feel proud. >-- >Steve Dorner, U of Illinois Computing Services Office >Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner Matthias -- Matthias Neeracher mneerach@iiic.ethz.ch "These days, though, you have to be pretty technical before you can even aspire to crudeness." -- William Gibson, _Johnny Mnemonic_