siegel@endor.uucp (Rich Siegel) (11/15/90)
In article <25759@dartvax.Dartmouth.EDU> Jim.Matthews@dartmouth.edu (Jim Matthews) writes: >In article <1990Nov13.223209.16268@midway.uchicago.edu>, >gft_robert@gsbacd.uchicago.edu writes: >work. Part of that has to do with the kludgy way TP runs programs in its >own heap, Actually, it's one of the more elegant pieces of work that I've seen: a context switch that predates MultiFinder... > >to select them and type Cmd-D. Think Pascal shows all variables >automatically, but that hides the few I care about among the many I don't. >The numerous icons and subpanes in the LightsBug window are an additional >distraction. The Observe window is pretty handy for those (like you) with a minimalist philosophy; you can type expressions into the Observe window, and unlike the THINK C debugger, the expressions will be evaluated in the current context, rather than the context in which they were entered. R. Rich Siegel Software Engineer Symantec Languages Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel If you have telekinetic powers, raise my hand.
leonardr@svc.portal.com (11/16/90)
In article <4716@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >In article <25759@dartvax.Dartmouth.EDU> Jim.Matthews@dartmouth.edu (Jim Matthews) writes: >>In article <1990Nov13.223209.16268@midway.uchicago.edu>, >>gft_robert@gsbacd.uchicago.edu writes: > >>work. Part of that has to do with the kludgy way TP runs programs in its >>own heap, > > Actually, it's one of the more elegant pieces of work that I've >seen: a context switch that predates MultiFinder... I am split on this issue...I like the concept and some of the implementation of the Think Pascal 'debugging environment'. It was a neat idea back before MF, and even today is not so bad - BUT given the concurrent application world of MF, not to mention the unrealisticness of it (bugs which don't occur in the environment, but do in the real world - and vice versa), it's about time to follow in Think C's footsteps! >> >>to select them and type Cmd-D. Think Pascal shows all variables >>automatically, but that hides the few I care about among the many I don't. >>The numerous icons and subpanes in the LightsBug window are an additional >>distraction. > > The Observe window is pretty handy for those (like you) with a >minimalist philosophy; you can type expressions into the Observe window, >and unlike the THINK C debugger, the expressions will be evaluated in the >current context, rather than the context in which they were entered. > Only one problem with the Observe Window (which does serve admirably for normal uses) is that you can view entire records, which is a VERY common thing to do when debugging! I also agree with Jim that Lightsbug is a bit too cluttered. I like the multiple panes, at least the bottom two (the data view and raw hex views are WONDERFUL (wish Think C had one!)), but I NEVER use the icons and they are distracting. I think a lot of this stuff is historical. What we now call Think Pascal (what started life as QuickSilver), was designed originally as a basically 'MacPascal w/Compiler'. It was (and still is) used in many educational institutions as the Pascal environment for their students - even, I teach a class using it (try that with MPW)! Given this, many of the features and choices of implementation lead towards this 'introductory' product, and not for the professionial programmer - that doesn't mean that you can not write a commercial or professional level product using it (I, and others, have certainly done so) but does not make it easy - at least not as easy as Think C! -- ---------------------------------------------------------------------- + Leonard Rosenthol | Internet: leonardr@sv.portal.com + + Software Ventures | GEnie: MACgician + + MicroPhone II Development Team | AOL: MACgician1 +
philip@pescadero.Stanford.EDU (Philip Machanick) (11/16/90)
In article <1990Nov15.210134.7758@svc.portal.com>, leonardr@svc.portal.com writes: |> Only one problem with the Observe Window (which does serve admirably |> for normal uses) is that you can view entire records, which is a VERY common |> thing to do when debugging! I also agree with Jim that Lightsbug is a bit |> too cluttered. I like the multiple panes, at least the bottom two (the data |> view and raw hex views are WONDERFUL (wish Think C had one!)), but I NEVER |> use the icons and they are distracting. |> |> I think a lot of this stuff is historical. What we now call Think |> Pascal (what started life as QuickSilver), was designed originally as a |> basically 'MacPascal w/Compiler'. It was (and still is) used in many |> educational institutions as the Pascal environment for their students - even, |> I teach a class using it (try that with MPW)! Given this, many of the features |> and choices of implementation lead towards this 'introductory' product, and |> not for the professionial programmer - that doesn't mean that you can not |> write a commercial or professional level product using it (I, and others, have |> certainly done so) but does not make it easy - at least not as easy as Think |> C! Some of this is a matter of opinion. You can resize the panes and make the ones you don't want disappear. Also, I find the simplicity of using the debugger makes for a different programming style. If I'm in a hurry, I just do a rough approximation to the program, then stop it at critical points and examine the data. Amazingly enough, this really can be faster than thinking about how to write the program (since you have to debug it anyway, and it's no big disadvantage to start out _expecting_ to find bugs). -- Philip Machanick philip@pescadero.stanford.edu
mxmora@unix.SRI.COM (Matt Mora) (11/17/90)
In article <1990Nov16.012356.20536@Neon.Stanford.EDU> philip@pescadero.stanford.edu writes: >Some of this is a matter of opinion. You can resize the panes and make the ones >you don't want disappear. Also, I find the simplicity of using the debugger I wish Think Pascal had a preference setting for Lightsbug. I hate having to adjust each pane every time I start a new project. If the project crashes the window goes back to some default behavior. Why can't I set the default so that when I start a new project or the project dies, Lightsbug will open up with the pane settings and window size _I_ want. This is a Mac application after all. :-) Otherwise I think its a great debugger. I even used it to debug an INIT I wrote. Another feature I wish it had was conditional breakpoints. Can you imagine how frustrating and time consuming it is trying to debug the list manager (which returns no errors grrrr! but thats another story) after the list starts filling up? -- ___________________________________________________________ Matthew Mora | my Mac Matt_Mora@sri.com SRI International | my unix mxmora@unix.sri.com ___________________________________________________________
siegel@endor.uucp (Rich Siegel) (11/17/90)
In article <1990Nov15.210134.7758@svc.portal.com> leonardr@svc.portal.com writes: > I am split on this issue...I like the concept and some of the >implementation of the Think Pascal 'debugging environment'. It was a neat >idea back before MF, and even today is not so bad - BUT given the concurrent >application world of MF, not to mention the unrealisticness of it (bugs which >don't occur in the environment, but do in the real world - and vice versa), >it's about time to follow in Think C's footsteps! > I will concede that the nature of the THINK Pascal debugger makes it difficult to debug programs in the background under MultiFinder; part of this is because MultiFinder forces applications to be suspended, whether they like it or not. Also, your assertion about the "unrealisticness" is irrelevant. In some circumstances, THINK Pascal does mask bugs; in particular, if the user fails to set up his current grafPort before drawing, THINK Pascal will draw into the Drawing window in the environment, and the built application will crash, because there is no drawing window. This is the only condition of which we're aware of different behavior between debug program and built application. I might also add that the "it works fine in the debugger but crashes as a built application" complaint is equally common for THINK C users, and indeed for programmers in general. It's hardly a reflection on the debugger. How many times have you tried to nail a bug which only happens some of the time? >for normal uses) is that you can view entire records, which is a VERY common >thing to do when debugging! I also agree with Jim that Lightsbug is a bit One might argue that to view an entire record would tend to obscure the one or two fields you're interested in amongst the structure of the whole records. How useful is it to be able to see all elements of an HParamBlockRec, when all you're interested in is the ioActCount field? In Observe, you can type in "hpb.ioActCount", and there you have it. The THINK C approach to viewing structures does have its advantages, but so does the THINK Pascal approach. > I think a lot of this stuff is historical. What we now call Think >Pascal (what started life as QuickSilver), was designed originally as a >basically 'MacPascal w/Compiler'. It was (and still is) used in many >educational institutions as the Pascal environment for their students - even, >I teach a class using it (try that with MPW)! Given this, many of the features >and choices of implementation lead towards this 'introductory' product, and >not for the professionial programmer - that doesn't mean that you can not >write a commercial or professional level product using it (I, and others, have >certainly done so) but does not make it easy - at least not as easy as Think >C! I question the historical accuracy of your statement, and I take exception to your assertion that THINK Pascal is "[an] 'introductory' product and not for the professional programmer" (to use your own words). THINK Pascal began life as THINK Pascal, and not as anything else. It was designed from the ground up to be fast, powerful, and easy to use. The designers did NOT say, "Let's take Mac Pascal and glue a compiler onto it and call it something else. The name has changed over the years, but the product remains the same. Also, while THINK Pascal does inherit many UI characteristics and some technology from Macintosh Pascal, LightsBug (the core of the source-level debugger) is not one of those elements. It first existed in form in version 1.0 of THINK Pascal, and over time it has been extended in order to fill the needs of our users. Also, THINK Pascal is most certainly suited to the needs of the professional developer. Its turnaround time and ease of use are generally accepted to be the best of the currently available Macintosh-based Pascal compilers, and the compactness and efficiency of the generated code is on a par with MPW Pascal - MPW is stronger in some areas, THINK Pascal is stronger in others; they both balance out. THINK Pascal is the only Pascal environment to support automatic dependency tracking and total integration of editor, compiler, linker, and debugger in a single environment. THINK Pascal comes with a fully-functional object class library for people who prefer to use one, and supports Apple Computer's standard class library. Finally, THINK Pascal is used to develop itself. To bootstrap a compiler requires a well-designed set of development tools, and THINK Pascal is an integral part of the development process. It is complemented by THINK C, MPW, and several special-purpose tools, all of which were developed with THINK C or THINK Pascal. Finally, I question your assertion that THINK C makes it easier to write applications than THINK Pascal. Each environment presents a distinct set of strengths and weaknesses. I consider some of THINK C's behavior to be less than desirable, but I would not generalize that to mean that THINK Pascal is a better environment to write applications. I believe that you've expressed a personal opinion, and that you might have done well to explicitly position it as such. Anyway, this thread has gotten far afield from the original poster's article, in which he opined that the THINK C debugger was unsuitable for debugging his applications, but he didn't elaborate. Nevertheless, I couldn't let this one go by. :-) R. Rich Siegel Symantec Languages Group Internet: siegel@endor.harvard.edu "...she's dressed in yellow, she says 'Hello, come sit next to me, you fine fellow..."
d88-jwa@byse.nada.kth.se (Jon W{tte) (11/18/90)
In article <4743@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >In Observe, you can type in "hpb.ioActCount", and there you have it. >The THINK C approach to viewing structures does have its advantages, >but so does the THINK Pascal approach. Well, in _my_ THINK C 4.0 I can type (for instance) "(**hTE).selStart", and get it... Is this a bug ? Am I entitled to a refund ? ;-) #define _FLAME_ The THINK C environment would be a dream if the DARNED DEBUGGER WOULD KEEP BREAKPOINTS AND WATCHED VARIABLES, D*MMIT !!!!! #endif /* _FLAME_ */ Better support for external editors (like, say, Alpha (Yes, Pete, I'm on my way to the exchange office)) would be nice, as would compilation in the background and a list of encounbtered errors, not just a halt after the first error. (ACtually, I think this is what Saddam is _really_ after ;-) h+ h+@nada.kth.se "Moof!(tm)"
smoke@well.sf.ca.us (Nicholas Jackiw) (11/20/90)
In article <4743@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: > If the user >fails to set up his current grafPort before drawing, THINK Pascal will draw >into the Drawing window in the environment, and the built application will >crash, because there is no drawing window. This is the only condition of which >we're aware of different behavior between debug program and built application. Really, Rich? Let me add a few then: your app, under the environment, won't see suspend and resume events, so any behavior it takes "in the background" can't be tested. What about all those source-file windows sitting in the windowList which vanish when I build? Also, sometimes it seems like THINK gives me out-of-memory errors before my growZone is ever invoked. (Might be wrong on this last one.) Plus, the [D] option (frequently used under the environment) causes <with> statements to be compiled differently than in a built-application, hiding some dereference problems. Under the environment, segments can (and do, if you display by build-order instead of segment order) get larger than, which'll crash under unifinder on an SE when built. > Also, THINK Pascal is most certainly suited to the needs of the >professional developer. Well ah doan' know if ah'm a perfessional, but in that my project just exceeded 40K lines of code (can't fit backups on a 1.4M floppy anymore), and in that THINK still whizzes through it like a hot knife through butter (a *big* piece of butter), I certainly agree it's suited to professional development. Wish it compiled in the background, though, so I could read news on office time... -- --- * --- Nicholas Jackiw Smoke@well.sf.ca.us | Jackiw@cs.swarthmore.edu Key Curriculum Press, Inc. Applelink: D3970 | (415) 548-2304 --- * ---
francis@daisy.uchicago.edu (Francis Stracke) (11/20/90)
In article <4743@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: > One might argue that to view an entire record would tend to obscure >the one or two fields you're interested in amongst the structure of the >whole records. How useful is it to be able to see all elements of an >HParamBlockRec, when all you're interested in is the ioActCount field? >In Observe, you can type in "hpb.ioActCount", and there you have it. >The THINK C approach to viewing structures does have its advantages, >but so does the THINK Pascal approach. But, once you've got the record open, you can just find the field you want & double-click, so that it will be the only thing in the window. The thing that would really be nice would be if you could go back-- i.e., from a field back to the record. (Is this possible in 3.0? I haven't used that yet.) | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Non sequiturs make me eat lampshades | | francis@zaphod.uchicago.edu | |
Chris.Gehlker@p12.f56.n114.z1.fidonet.org (Chris Gehlker) (11/20/90)
siegel@endor.uucp (Rich Siegel) writes: > Finally, I question your assertion that THINK C makes it easier > to write applications than THINK Pascal. Each environment presents a distinct > set of strengths and weaknesses. I consider some of THINK C's behavior to > be less than desirable, but I would not generalize that to mean that THINK > Pascal is a better environment to write applications. I believe that you've > expressed a personal opinion, and that you might have done well to explicitly > position it as such. I can't miss the opportunity to voice my pet peeve. I't really bugs me that the editing keyboard shortcuts, option-up arrow etc., are different in each environment. Seems like I'm always hitting the wrong combination for the environment that I'm in. -- Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!56.12!Chris.Gehlker Internet: Chris.Gehlker@p12.f56.n114.z1.fidonet.org
phils@chaos.cs.brandeis.edu (Phil Shapiro) (11/20/90)
In article <1990Nov19.203823.8973@midway.uchicago.edu> francis@daisy.uchicago.edu (Francis Stracke) writes:
The thing that would really be nice would be if you could go back--
i.e., from a field back to the record. (Is this possible in 3.0?
I haven't used that yet.)
You can use the '>' and '<' keys to go up and down any structure
traversal in the expanded view pane (of LightsBug). That is, if you
expand a field in a structure by double-clicking it, you can get back
to the original structure by using '<'. At that point, you can use
'>' to go back down to that field. This works in both 3.0 and 2.0.
Look at p. 166 in the 2.0 manual, and p. 181 in the 3.0 manual.
-phil
--
Phil Shapiro Technical Support Analyst
Language Products Group Symantec Corporation
Internet: phils@chaos.cs.brandeis.edu