siegel@endor.uucp (Rich Siegel) (09/25/90)
Does anyone have any wishes for THINK Pascal? Editor, Compiler, Debugger feature requests? Annoyances? Any sort of commentary? 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.
weesh@grymoire.crd.ge.com (Darweesh) (09/25/90)
Let me just say that Lights...er...Think Pascal is the most wonderful programming environment I've ever used...Unix or Mac. I have no bug reports or major problems with it, but if you are looking for feature ideas, here is a large feature that could be added (but could also be done manually). Version Management as in RCS type stuff in unix. Make it possible to create/recreate any of the versions of a project that ever were. If you're not familiar with Unix RCS, then let me know, and I'll elaborate. -Mike Darweesh
philip@pescadero.Stanford.EDU (Philip Machanick) (09/25/90)
In article <4251@husc6.harvard.edu>, siegel@endor.uucp (Rich Siegel) writes: > Does anyone have any wishes for THINK Pascal? Editor, Compiler, Debugger > feature requests? Annoyances? Any sort of commentary? Since you ask, here's a list. Sorry I don't have time to think of more. Environment / general o support for including external tools in project, e.g., run Rez if resource source changed - i.e., should be as powerful as Make, without losing current ease of use o support for more than 1 resource file o apropos - LISP environment style: a search for a string supplies a list of names, and you select the one you want and jump to its definition (see Mac Allegro Common Lisp for a good example) o extend the current name menus (lists of uses files, procedure names etc.) to the project window (OPTION or COMMAND click on name in Project) Compiler o support for arrays larger than 32K _at least_ on the heap, preferably more than 32K global data (my BIGGEST priority)********************** o assembly language output o assembler for inlines (relatively low priority for me; real programmers like hex) Debugger o programmable breakpoints - like assertions: cause a drop into the debugger only if the condition they check is true and debugging mode is on - should _not_ be part of source code to keep it portable (at least within Mac) o allow offsets of more than 32K o disassembler, with pointers back to source (e.g., double-click on line of assembly code, get editor window, finger at source line) Editor o more levels of undo o multiple views/panes (see how MS Word allows you to split the screen, or to have more than 1 window open at once for the same document - a good special case of this is to be able to see declarations and the place the declared items are used at the same time o folding (based on occam editor): allow sections of code to be collapsed as in an outliner o pretty printing - I'm one of the fans of this feature, except I find it irritating that I can't always break a long line. Sometimes I can do it by inserting a comment, sometimes I can't. Generally more parametrization and control in general will make pretty printing more useful o option to output pretty printing in MacWrite or MS Word (could be a problem because original MacWrite only supported a small number of tabs) - or even PICT - format. Philip Machanick philip@pescadero.stanford.edu
252u3129@fergvax.unl.edu (Mike Gleason) (09/25/90)
I'm very impressed that a company would actually go out and ask for suggestions! Apple, Microsoft, ... take note! I've got version 2.0, so I don't know if any of my suggestions are already in there. (It was between upgrading to TP v3 or Tuition...) Something I think is pretty important is that you should be able to choose to save a compiled resource directly into another file. It's a ROYAL pain having to go into ResEdit zillions of times to try out a new XCMD, etc. This goes for Think C too! An excellent example of this can be found in Farallon's SoundEdit. Very slick, uses Standard File, uh, slickly. Another thing I hate is having to open a non-pascal text file and having the pretty-printer try and format it and making it un-readable. Howz about having a 'Open plain text file' command? And, is an inline assembler possible? I guess you've got the inline keyword where you could enter in machine-language gibberish, but it would be cool if you could put in asm junk like you can in Think C. Oh, uh, lowering the upgrade price would be nice too... $75 is kinda steep on a student's income ;-) Thanks for listening, -- mike gleason _____________________________________________________________________________ * Mike Gleason 252u3129@fergvax.unl.edu * "Don't you f*ckin' look at me!" -- D. Hopper cosc006@unlcdc2.unl.edu
gix%mdi.com (Brian Gix) (09/25/90)
In article <4251@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >Does anyone have any wishes for THINK Pascal? Editor, Compiler, Debugger >feature requests? Annoyances? Any sort of commentary? How about the ability to use Think C Librarys w/ Think Pascal and Think Pascal Libs w/ Think C.... Sure would save some translation time... :-) >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. --Brian Gix -- ================================================================================ || Brian Gix || gix@mdi.com gixb@prism.cs.orst.edu || || MDI - Motorola || gix@nwnexus.wa.com ...!uunet!mdisea!gix || || Bothell, WA 98011 USA|| AmOnline: GIX Phone: (206) 487-5894 ||
252u3129@fergvax.unl.edu (Mike Gleason) (09/25/90)
quote:
How about the ability to use Think C Librarys w/ Think Pascal
and Think Pascal Libs w/ Think C.... Sure would save some
translation time... :-)
enquote.
It says how in the Think Pascal manual how you can use Think C
libraries. However, I couldn't find a place in either manual saying how
you could use a Think Pascal library in Think C. I wonder if you could
just declare functions as extern pascal MyType foo() that exist in
a Pascal library?
_____________________________________________________________________________
* Mike Gleason 252u3129@fergvax.unl.edu
* "Don't you f*ckin' look at me!" -- D. Hopper cosc006@unlcdc2.unl.edupillera@etd4260a.erim.org (Joe Pillera) (09/25/90)
How about injecting some of the superior features of LS Pascal (i.e.
Lightsbug) into THINK C? THINK Pascal is such of a superior product,
it's really left it's younger brother (C) in the dust; it's
unfortunate that THINK C isn't as user-friendly...
-joe
--
-----
Joe Pillera ERIM
Research Scientist Image Processing Systems Division
pillera@etd4260a.erim.org P.O. Box 8618
(313) 994-1200 x2754 Ann Arbor, Michigan 48107-8618
Disclaimer: The opinions expressed here are solely those of Joe Pillera,
and not of ERIM or its affiliates.jem@sm.luth.se (Jan Erik Mostr|m) (09/25/90)
pillera@etd4260a.erim.org (Joe Pillera) writes:
# How about injecting some of the superior features of LS Pascal (i.e.
# Lightsbug) into THINK C? THINK Pascal is such of a superior product,
# it's really left it's younger brother (C) in the dust; it's
# unfortunate that THINK C isn't as user-friendly...
Hear Hearemerson@uvm-gen.UUCP (Tree,,,) (09/25/90)
From article <4251@husc6.harvard.edu>, by siegel@endor.uucp (Rich Siegel): > Does anyone have any wishes for THINK Pascal? Editor, Compiler, Debugger > feature requests? Annoyances? Any sort of commentary? I would find bracket matching a real plus in the editor. I know there is an INIT that gives this capability to THINK C, but there is nothing out there for THINK Pascal. Also, like the others, RCS-like capability would be wonderful. Tom E. -- +----------------------------------------------------------------------+ | The three most dangerous things in the | | | world are a programmer with a soldering | Tom Emerson | | iron, a hardware guy with a software | emerson@griffin.uvm.edu | | patch, and a user with an idea. | | +----------------------------------------------------------------------+
pete@tone.rice.edu (Pete Keleher) (09/25/90)
> How about injecting some of the superior features of LS Pascal (i.e. > Lightsbug) into THINK C? THINK Pascal is such of a superior product, > it's really left it's younger brother (C) in the dust; it's > unfortunate that THINK C isn't as user-friendly... Not being a Pascal type, I haven't ever seen THINK Pascal. What superior features are you thinking of? pete -- ============================================================================= Pete Keleher pete@titan.rice.edu =============================================================================
samalone@athena.mit.edu (Stuart A. Malone) (09/25/90)
Thank you for asking for our suggestions. I'm not going to list every feature
I can imagine for THINK Pascal; I'd rather concentrate on the ones that I
believe are practical to implement and immediately useful. Roughly in order of
increasing difficulty:
* Enable the "Save" command on untitled documents. Sure, it will behave just
like "Save As...", but at least it will have a command-key equivalent.
* Wrap long lines in the editor. Preferably, this would be done automatically
to fit the window. Once this is done, you can eliminate the horizontal
scrollbar to make room for one more line of code. (Oh, for a large screen!)
I realize that this wouldn't leave room for the stop sign at the bottom of the
window in "Stops In" mode, but I'd rather have the lines wrap than have a cute
icon, and perhaps your designers can come up with some other way to indicate
that the left column is special.
An inferior solution would be to allow the programmer to insert explicit
newlines.
* Make the option double-click trick work with more symbols. Right now it only
works with procedure and function names, but it should also work with types and
constant names, and maybe even variables (though perhaps it's only practical
with global variables). My wife was using Just Enough Pascal to refresh her
memory of Pascal and learn about the Macintosh, and was frustrated that most of
the time option double-click failed.
Along the same lines, if the symbol is defined in a library, it would be nice
to indicate which library contains the symbol by hilighting the library in the
Project window.
* Make the debugging environment more like the actual Macintosh environment.
Suspend, resume, and mouseMoved events should be passed through (or emulated)
to the application being debugged, and the mouseRegion and maxSleep arguments
to WaitNextEvent should be handled properly. As things stand, there are
certain parts of my project that I can only check by building a standalone
application and guessing at the problem when something goes wrong.
* Provide a way (other than inline hexadecimal codes) to call ProcPtrs. This
would eliminate nearly all the places where I use inline hexadecimal now. I
think that the best way to accomplish this is to extend Pascal to allow the
programmer to declare procedure and function types, and pointers to these
types. The procedure and function types would become a legal shorthand for
defining a procedure or function of that type, but could not be used as the
type of a variable or expression. Types naming pointers to procedures and
functions could be used as variable and expression types, and could also be
used to coerce ProcPtrs to callable procedures. Here's an example of what I
have in mind:
TYPE
{ Note that the name "MyFilter" serves only as a placeholder. }
{ It's presence should be optional. }
FilterProc = FUNCTION MyFilter(theDialog: DialogPtr;
VAR theEvent: EventRecord; VAR itemHit: integer): boolean;
FilterProcPtr = ^FilterProc;
{ Here we define a FilterProc function using the previous type declaration. }
FilterProc FancyFilter;
VAR
i, j: integer;
BEGIN
i := itemHit;
...
END;
{ Here we declare an argument of type FilterProcPtr, and proceed to call }
{ the function. }
FUNCTION TestFilter(filter: FilterProcPtr):boolean;
BEGIN
...
TestFilter := filter^(dialog, event, item);
END;
* Yes, I would also like to see a source-code control system built into THINK
Pascal. I use one of these (RCS) on my UNIX machine at work, and it is a
tremendous programming aid. As far as I can tell, Apple's Projector is only
available as part of MPW, which I use THINK Pascal to avoid. Also, a built-in
system would undoubtedly be far more convenient to use than a separate
application, and ease-of-use is crucial to the success of a revision-control
system. I would be satisfied even if it worked only on source files stored in
your proprietary format, which would probably make your job easier. (After
solving the procedure-level segmentation problem so elegantly in THINK Pascal
3.0, I'm sure your engineers are up to the task of designing the interface to
the revision control system. I really must praise your team for doing an
excellent job on such a tricky problem.)
I hope that these suggestions are helpful, and I hope they can be implemented.
I would certainly be willing to pay for an update containing these features.
If you have any questions, feel free to send me email.
--Stuart A. Malone
samalone@athena.mit.eduweesh@grymoire.crd.ge.com (Darweesh) (09/25/90)
It would be nice if Think Pascal and Think C could share object code. -Mike Darweesh weesh@crd.ge.com
252u3129@fergvax.unl.edu (Mike Gleason) (09/26/90)
I thought of another needed addition: being able to have static arrays
(I guess what I'm going to call them for now). In MSDOS Turbo Pascal
you can have something like this:
const
myTable[10] = {1, 1, 2, 3, 5, 8, 13, 21, 44, 65};
It's something like that, I can't remember, I don't use anything but the
best pascal compiler in the world ;-) When porting from inferior
compilers, it sucks having to type in myTable[1] := 1, myTable[2] := 1,
etc.
_____________________________________________________________________________
* Mike Gleason 252u3129@fergvax.unl.edu
* "Don't you f*ckin' look at me!" -- D. Hopper cosc006@unlcdc2.unl.eduphils@chaos.cs.brandeis.edu (Phil Shapiro) (09/26/90)
In article <12142@crdgw1.crd.ge.com> weesh@grymoire.crd.ge.com (Darweesh) writes: > It would be nice if Think Pascal and Think C could share object code. > > -Mike Darweesh > weesh@crd.ge.com They can, albeit in a limited fashion. Libraries built in Think C can be added directly to Think Pascal projects. Also, libraries built from Think Pascal can be converted with oConv into projects. You have to convince oConv that the library is really a MPW .o file, though, so you'll have to change the file's creator and its name. -phil shapiro, symantec tech support -- Phil Shapiro phils@chaos.cs.brandeis.edu
KOFOID@cc.utah.edu (09/26/90)
I would also like to complement Symantec on the decision to solicit
advice directly from users.
I am in substantial agreement with most of the suggestions thus far made.
I would also like Symantec to add hooks to foreign editors. I would far
prefer an Emacs-like editor, such as Alpha or a highly customizable
editor, such as QUED to the THINK editor, which I find brain-damaged. In
every other respect, THINK Pascal is an utter joy to use compared to
other systems. However, I want
{1} to format my code *exactly* the way *I* wish;
{2} to do regular-expression search and replace, forwards and backwards;
{3} to write macros;
{4} to block comment code;
{5} to treat the alternate comment braces ("(* *)") as "error braces"
to comment already partially commented text;
{6} to read or write text files without the stupid pretty-printer futzing
them up;
{7} to comment-number code at the beginning of each line, these lines
being an example;
{8} etc.
Cheers,
Eric
__________________________________________________________________
| Eric Kofoid; Dept. Biology, U. of Utah; SLC, UT 84112 |
| (801) 581-3592 |
| kofoid@bioscience.utah.edu |
| |
| -- The University of Utah is blameless for anything I've said -- |
|__________________________________________________________________|paulr@syma.sussex.ac.uk (Paul T Russell) (09/26/90)
In article <4251@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >Does anyone have any wishes for THINK Pascal? Editor, Compiler, Debugger >feature requests? Annoyances? Any sort of commentary? It would be nice to extend the option/command-click-on-title-bar stuff. I was thinking of something along the following lines: 1) Press option key - cursor changes into something appropriate (like a fish ?) 2) Click on any word in a text editing window. 3) A pop-up menu appears. The first item reads "Defined in: xyz.p"; the second item reads "Referenced by: " and has a submenu with all the references to the symbol (file name/unit name/procedure); and then there are other items but I can't quite read what's on them. ;-) 4) Selecting any of the menu items opens up the relevant text window and highlights the reference. Sort of a magical hyper cross reference facility. How about it ? It would things like MPW's XRef tools and Aranda look a bit silly... //Paul -- Paul Russell, Department of Experimental Psychology University of Sussex, Falmer, Brighton BN1 9QG, England Janet: paulr@uk.ac.sussex.syma Nsfnet: paulr@syma.sussex.ac.uk Bitnet: paulr%sussex.syma@ukacrl.bitnet Usenet: ...ukc!syma!paulr
rad@genco.uucp (Bob Daniel) (09/26/90)
It would be nice to compile a code resource into an existing file rather than creating a new one every time (as an option). _________ moof moof
homeier@aerospace.aero.org (Peter Homeier) (09/26/90)
In article <4251@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >Does anyone have any wishes for THINK Pascal? Editor, Compiler, Debugger >feature requests? Annoyances? Any sort of commentary? > > Rich Siegel Software Engineer Symantec Languages Group > Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel I am so glad you asked! I absolutely *LOVE* THINK Pascal. It has, I think, the finest debugging environment I have ever used. Nevertheless, there *is* one feature that I would dearly love to see included, that does exists in many other "Mainframe" debuggers, but for some reason was overlooked in creating THINK Pascal's debugger. This feature is the "procedure traceback". The procedure traceback appears as a window that has two panes. The top pane is a list of the procedure call stack, as a scrollable text field with a line (in order) for each procedure (or function) called but not yet returned from. This line contains the name of the procedure or function. Clicking on the name of a function causes the list of formal parameter names and also local variables to appear in the lower pane, along with their current values (if printable). At the same time the code window resets itself to the code for that procedure or function, with the actual point of the call in progress highlighted. The values listed in the lower pane are editable, and any new value is assigned to the parameter or variable. (Actually, only *variable* parameters would be editable, not value, procedure, or function parameters.) All this should be made clearer with an example. Take the following code: 1. program test; 2. 3. var m, n: integer; 4. 5. procedure p(x: integer; var y,z: integer); 6. var a: integer; 7. begin a := z-1; 8. if x>0 then q(y,a) 9. end; 10. 11. procedure q(u: integer; var v: integer); 12. var d: integer; 13. begin d := u-1; 14. if u>0 then p(v,d,v) else STOP 15. end; 16. 17. begin 18. m := 2; 19. n := 3; 20. p(3,m,n) 21. end. If I have this figured out correctly, the above program should break at line 14 at the STOP. Then the code and traceback windows would reflect the current scope, as follows: +=============== TEST CODE ================+ +===== TRACEBACK =======+ | 11. procedure q(u: integer; var v: inte | |=>q(0,0) | | 12. var d: integer; | | p(1,0,1) | | 13. begin d := u-1; | | q(1,1) | | 14. if u>0 then p(v,d,v) else STOP | | p(2,1,2) | | 15. end; ^^^^ | | q(2,2) | | 16. | | p(3,2,3) | | 17. begin | | test() | | 18. m := 2; | +-----------------------+ | 19. n := 3; | | u: 0 | | 20. p(3,m,n) | | v: 0 | | 21. end. | | d: -1 | | | | | | | | | | | | | | | | | +------------------------------------------+ +-----------------------+ The "^^^^" is my attempt to show highlighting on the code screen. Then clicking, say, on the "p(2,1,2)" entry would result in the screen changing to +=============== TEST CODE ================+ +===== TRACEBACK =======+ | 5. procedure p(x: integer; var y,z: in | | q(0,0) | | 6. var a: integer; | | p(1,0,1) | | 7. begin a := z-1; | | q(1,1) | | 8. if x>0 then q(y,a) | |=>p(2,1,2) | | 9. end; ^^^^^^ | | q(2,2) | | 10. | | p(3,2,3) | | 11. procedure q(u: integer; var v: inte | | test() | | 12. var d: integer; | +-----------------------+ | 13. begin d := u-1; | | x: 2 | | 14. if u>0 then p(v,d,v) else STOP | | y: 1 | | 15. end; | | z: 2 | | 16. | | a: 1 | | 17. begin | | | | 18. m := 2; | | | | 19. n := 3; | | | +------------------------------------------+ +-----------------------+ Finally, if the user clicked on the name of the program, "test()", he would get the point in the main program where the first call was made, and see listed all global variables: +=============== TEST CODE ================+ +===== TRACEBACK =======+ | 17. begin | | q(0,0) | | 18. m := 2; | | p(1,0,1) | | 19. n := 3; | | q(1,1) | | 20. p(3,m,n) | | p(2,1,2) | | 21. end^^^^^^^^ | | q(2,2) | | | | p(3,2,3) | | | |=>test() | | | +-----------------------+ | | | m: 2 | | | | n: 3 | | | | | | | | | | | | | | | | | | | | | +------------------------------------------+ +-----------------------+ So much of this is already present in pieces in the THINK Pascal debugger! Already, when the program hits a breakpoint, the code window is updated to show the current location of the program counter. All that would need to be added here is the capability to pull the appropriate return address off the stack, and display the source code at THAT location. Already, the Observe window allows the interactive display of variables, updated at every break. To create the lower pane of the traceback window, all that would need to be added is the ability retrieve the variable names in the selected scope, evaluate them in THAT scope, and to edit their values. This traceback feature would immediately increase the programmer's vision into his program's state during debugging. So often the problem is not in the current scope where the error finally forced a break, but prior, in a higher scope than the current call. It is highly valuable to be able to go back to previous scopes and first, see the location where the call came from, and second, to examine the local parameters and variables there. I want to thank Rich Siegel at the Symantec Languages Group, and all the others at THINK, for their excellent implementation of Pascal. I hope the above suggestions were clear, and of value. It's not often you get the opportunity to comment like this; I hope Symantec finds it worthwhile. Peter V. Homeier homeier@aerospace.aero.org
wayne@helix.nih.gov (Wayne Rasband) (09/27/90)
More than anything else, I would like to see better code optimization. I think it's crime that, with the possible exception of Absoft's new FORTRAN compiler, there aren't any highly optimizing compilers available for the Mac. -wayne rasband (wayne@helix.nih.gov)
rcook@eagle.wesleyan.edu (09/27/90)
First of all I think it's fabulous that you are asking us what changes we would like. I just hope you have the time and energy to implement all the great suggestions I have read so far. Here's my list: 1. I often use assembly language in my programs, and even with MultiFinder it is a pain to have to switch to the Editor, then to the Assembler, then to the Library converter (I'm using MDS), and back into THINK Pascal. I would really appreciate an integrated assembler in the TP environment. Ideally we could have an Assemble... command in a menu which would assemble the code in an editor window, depositing the object code in your project, and the option for inline assembly code as in C. 2. I put a lot of effort into the appearance or my programs on the screen, so I fain myself going into ResEdit all the time to adjust icons, windows, dialogs, cursors, etc. Again, MultiFinder is good, but an integrated resource editor would be better, I think. I am not talking about putting all of ResEdit into TP, but just some basic stuff, like string/string list, icon, pattern, cursor, dialog, alert, DITL, and window editors into THINK Pascal. I often find myself hard coding strings into my programs because it is such a pain to have to go into ResEdit everytime I think to include a new string into my program. An integrated resource editor would make this a snap. Just too reiterate some other good suggestions I have heard, I like the ideas of a version control system, a way to wrap long lines of code, an option to not pretty print a file, and a way to save a pretty printed file in a word processor's format. That's about it. I anxiously await the arrival of THINK Pascal version 4... -- Randall Cook rcook@eagle.wesleyan.edu --
francis@arthur.uchicago.edu (Francis Stracke) (09/27/90)
In article <4251@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >Does anyone have any wishes for THINK Pascal? Editor, Compiler, Debugger >feature requests? Annoyances? Any sort of commentary? About pretty-printing: mostly I like it. But the horizontal/vertical dichotomy in listing variables (and unit names?) has got to go. I prefer to have a horizontal list, for the most part; but, when it gets over one line, it gets to be a pain. (Especially with the TCL--everybody's going to be having HUGE unit lists, no?) I'd like to be able to do something to say "hey, break the list here." I haven't seen 3.0 yet (don't blame me, blame my bank...), so ignore this if it's been addressed already. >If you have telekinetic powers, raise my hand. I just did. I also have hypnotic powers, so you didn't notice.
francis@arthur.uchicago.edu (Francis Stracke) (09/27/90)
In article <12126@crdgw1.crd.ge.com> weesh@crd.ge.com (Darweesh) writes: > >Let me just say that Lights...er...Think Pascal is the most wonderful >programming environment I've ever used...Unix or Mac. Agreed! >I have no bug reports or major problems with it, but if you are looking for >feature ideas, here is a large feature that could be added (but could also >be done manually). Version Management as in RCS type stuff in unix. PLEASE make it extremely optional! Good Lord, can you imagine trying to keep that much stuff around if you're just on an ordinary 20M HD? (Actually, I'm still using 2.0, primarily because I can't afford an upgrade, but also because I can fit it on 2 floppies.)
philip@pescadero.Stanford.EDU (Philip Machanick) (09/27/90)
Another thing I've wanted for a long time, which would include some of the other requests: Integrate THINK C and THINK Pascal into 1 environment - ideally with some generalization so this could be done with other tools, like Rez and ResEdit. Do this in such a way as to maintain the ease of use of THINK. Now that doesn't sound so easy ... -- Philip Machanick philip@pescadero.stanford.edu
francis@arthur.uchicago.edu (Francis Stracke) (09/27/90)
In article <1667@uvm-gen.UUCP> emerson@uvm-gen.UUCP (Tree,,,) writes: >From article <4251@husc6.harvard.edu>, by siegel@endor.uucp (Rich Siegel): >> Does anyone have any wishes for THINK Pascal? Editor, Compiler, Debugger >> feature requests? Annoyances? Any sort of commentary? > >I would find bracket matching a real plus in the editor. I know there is >an INIT that gives this capability to THINK C, but there is nothing out there >for THINK Pascal. Just what do you mean by brackets? begin/end? It's got it; the indentation works out automatically. Pascal's brackets, the comments, would be much nicer if they didn't have to be one line apiece!
boerned@mist.CS.ORST.EDU (Dan Boerner) (09/27/90)
Wish List: Allow adding of multiple files to the project file. This is a big one when you have to recreate a project file that has been corrupted during development. Allow selecting and dragging of multiple files in the project window. (I had to integrate a project with over 100 units and adding new units in the correct place took forever, Add to project...Drag with autoscroll....Add to project...Drag with autoscroll...) SPEEDING UP BUG CATCHING Precompiled "uses" similar to the precompiled headers option in THC Catching one syntax bug at a time for a large file with many uses means watching the compiler load the uses over and over and over again. Is there a way to eliminate this? RSRC EDITING FROM WITHIN THP I have to disagree with an earlier suggestion to include some rsrc editing features to the environment for the following reasons: 1. A few is never enough. The small set of rsrcs will never be adequate and cause frustration when after editing STR#s in the environment you need to edit MENUs and have to leave it. 2. Resource editors are nortoriously hard to write, we had to write one for a project I was on and it ended up being a bad idea. Apple is always adding new rsrc types and you end up just reinventing the wheel. Look at how long it has taken apple to get ResEdit 2.0 out. 3. Under MF I have no trouble quickly switching back and forth between THP and ResEdit. 4. Do what your good at. Since were moving toward smaller programs that work together (mini-apps) and away from swiss-army knife programs I think it makes more sense to move toward a day when a program like THP can use AppleEvents to send a msg to ResEdit saying "Hey, edit this rsrc". Another vote for: Exporting with styles (bolding) intact. Split Screen Editor window. Line wrapping option Debugger Conditional breakpoints That's all for now, thanks for asking... Dan Boerner PhD Student @ Oregon State University boerned@mist.cs.orst.edu
czychi@ethz.UUCP (Gary Czychi) (09/27/90)
In article <4251@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >Does anyone have any wishes for THINK Pascal? Editor, Compiler, Debugger >feature requests? Annoyances? Any sort of commentary? > > Rich Siegel Software Engineer Symantec Languages Group > Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel Great! The best programming environment in the world will even get better! Thanks a lot for the superb TP and your devotion, Rich. My favorites would be: 1) #> Pascal's brackets, the comments, would be much nicer if they didn't #> have to be one line apiece! I'll second that. It's quite difficult to write (and adjust) several lines of comment. And I write lots of comments. 2) Is it somehow possible to have several statements on one line? In my current project I have hundreds of short assignments in several units. And it's quite annoying to scroll to the code I want, because only one small column of code takes up several pages. Don't get me wrong, I like the one-statement-per-line approach, *but* there should be an exception to that rule. 3) Can you somehow save the the window locations of all units? And the Text and Drawing windows as well? I, for instance have all the 'help' windows on my small SE screen and the code windows on my 13" screen. 4) Please, please enhance the Object Oriented Programming Manual. It's not bad, it's only far to short! I have more questions now than I had before I read it (very carefully). And please give us a list of books which deal with the TCL. I want to learn it, but not by trial and error... Last but not least, why don't you bring out a tutorial like JEP for the TCL? This is what I really need. And I would love to be a tester for it... That's my $0.02. Thank's a lot for the opportunity. Gary Gary T. Czychi University of St.Gallen, Switzerland czychi@csghsg52.BITNET (preferred) czychi@bernina.ethz.ch.UUCP (CZYCHI@ETHZ.uucp) Tel.: --41 / 71 / 57 17 22
sund@tde.lth.se (Lars Sundstr|m) (09/27/90)
In article <PHILS.90Sep25181555@chaos.cs.brandeis.edu> phils@chaos.cs.brandeis.edu (Phil Shapiro) writes: They can, albeit in a limited fashion. Libraries built in Think C can be added directly to Think Pascal projects. Also, libraries built from Think Pascal can be converted with oConv into projects. You have to convince oConv that the library is really a MPW .o file, though, so you'll have to change the file's creator and its name. -phil shapiro, symantec tech support -- Phil Shapiro phils@chaos.cs.brandeis.edu Try using db_Vista object code from RAIMA in Think Pascal. They seem to have used some strange options in THINK C which makes THINK Pascal to complain about some unknown resources. /Lars Sundstroem -- +---------------------------------------------------------------------+ | Lars Sundstrom, Lund University, Department of Applied Electronics, | | Box 118, S-221 00 Lund, Sweden Phone: +46-46121598 Fax:+46-46129948 | | Internet: sund@tde.lth.se | +---------------------------------------------------------------------+
rcb@ccpv1.cc.ncsu.edu (Randy Buckland) (09/27/90)
francis@arthur.uchicago.edu (Francis Stracke) writes: >About pretty-printing: mostly I like it. But the horizontal/vertical >dichotomy in listing variables (and unit names?) has got to go. I prefer >to have a horizontal list, for the most part; but, when it gets over one >line, it gets to be a pain. (Especially with the TCL--everybody's going to >be having HUGE unit lists, no?) I'd like to be able to do something to >say "hey, break the list here." This can be done, it's just not pretty. Just insert a comment in the long list. This will cause a line break. -- Randy Buckland North Carolina State University randy@ncsu.edu (919) 737-2517
liberte@yoyodyne.ncsa.uiuc.edu (09/28/90)
Here is a suggestion that may satisfy all camps regarding pretty-printing. And it may be easy to implement, guessing at what TP is doing internally. There is already an option to not pretty-print, but then you have to do *all* the formatting yourself. How about a little help from the environment, but not too much. With pretty-printing turned off, one additional key command (cmd-i?) would indent just the current line relative to previous lines. So the editor would go through all the same contortions it does now to pretty-print, but nothing else would be changed - only the current line would be indented. Another command (enter?) would start a new line (like return), and indent to the right column. This would allow you to easily combine multiple statements per line, or break lists where you want. Highlighting erroneous text should be an independent option whether or not pretty-printing is active. I dont recall whether it is now. I am currently using MPW C, and am not a happy camper. In addition to importing more THINK Pascal features to THINK C, more compatibility with MPW languages and libraries, and MacApp is always needed. Someone mentioned using Pascal libraries with C and C libraries with Pascal. Years ago, there were problems with *incompatible* entry points (with the same names) between Pascal and C libraries. I hope the situation will improve, but I imagine it is a lower priority since how many people mix languages? Dan LaLiberte National Center for Supercomputing Applications liberte@ncsa.uiuc.edu
rcbaem@rw6.urc.tue.nl (pooh 'Ernst' Mulder) (09/28/90)
ANOTHER (oops capslock!) another feature I would like to see in the debugger (It isn't in the 2.0 version debugger) is to be able to stop execution when a certain variable reaches a certain _value_. This would save a lot of code I write every time to stop my program when a variable reaches the value with which I want to start debugging. pooh
finnegan@dhw68k.cts.com (Greg Finnegan) (09/30/90)
Minor (nit-picky) things I'd like:
Don't clobber the filename in the status box when compiling (the
phrase "Updating Dorfus.proj..."). Why don't you use the second
line of the status box to indicate that the project is being updated?
I'd like an option in the Project type dialog that sets what I can
do to the project - build, go, build as application (I keep two
projects, or more, around for each application. I use one in the
environment and the others for various stand alone applications. I
really hate it when I'm in one of me 'build' projects and I
absent-mindedly hit cmd-b and it proceeds to rebuild my entire
project while I'm eating lunch. Arghh!)
Greg.
--
uucp: ...{spsd,zardoz,felix}!dhw68k!finnegan
InterNet: finnegan@dhw68k.cts.com
--------------------------------------------tim@hoptoad.uucp (Tim Maroney) (10/01/90)
In article <4251@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >Does anyone have any wishes for THINK Pascal? Editor, Compiler, Debugger >feature requests? Annoyances? Any sort of commentary? Thanks for asking. I find myself wrestling for all too many hours a week with environmental issues that have nothing to do with our code. Most of my suggestions bear on the issues of reliability and general programmer-friendliness rather than new features. THINK Pascal is friendly in some ways. In other ways it expresses a false economy which focuses too heavily on raw compile-link-run turnaround time. If it takes a programmer an hour to remedy a glitch in the environment which results from the high-speed turnaround, then things are actually much slower. If it takes a programmer four hours to find a bug which a more error-checking compiler would have turned up at compile time, then once again, the gain in actual programming speed is negative. (1) Incorruptible project files. Completely refresh the heap from the project file after every run. Make sure the resource map and all other data structures are never written back to the file after having been open concurrently with software execution. Checksum or CRC all critical resources and data structures to allow an algorithmic check for corruption if it creeps through. (2) Compatibility with 32-bit Quickdraw. Breakpoints crash into the machine debugger (MacsBug) with 32-bit Quickdraw in 32-bit mode if the FPU code generation is activted. Crashes are less frequent with the FPU code generation disabled, but clicking on a LightsBug variable in 32-bit mode causes a psychedelic monochrome animation sequence, followed about thirty seconds later by the realization that nothing else happened in all that time -- the variable did not open. (3) MacApp compatibility. Any change to TWindow.IRes will cause a fairly reliable crash and project file corruption when run under the environment. I reported this months ago and nothing has been done. now it not only causes my floating windows code to crash when run under the debugging environment, it does the same with the new official MacApp floating windows code. Later, I attempted to add a flag telling TWindow not to EraseRect on a DrawContents, a very minimal change, and I got a permanently trashed project file every time I ran it. (By "permanently trashed" I mean Remove Objects did not suffice to undo the corruption.) The symptoms were very similar to those under both versions of the floating windows code, and the only common factor was that a (clearly harmless, flag-setting) change was made to TWindow.IRes. (4) Syntax compatibility with MPW Pascal. This will eliminate most of the problems with MacApp. Recently an automatic bug fix correction script was made available by Apple; it could not be applied to THINK Pascal MacApp because of the laborious code conversion process. Add the $I directive, compatible assumptions about type residency in units and unit dependencies, and any other syntactic features which exist in MPW Pascal. (5) Speed up the debugger. I'm sure part of the blame rests on the MacApp debugger, but using both LightsBug and the MacApp debugger, code execution time is excruciatingly long -- sometimes an order of magnitude slower. This is another false economy. (6) Add an optional optimizer phase. MPW Pascal produces register optimized code that is both significantly faster (10%+) and smaller (because all the stack-relative offsets disappear from most code). Making it optional means it need not slow down the ordinary compile- link-run cycle. Note: If the system becomes compatible with MPW Pascal, then this is less important, since MPW can be used as a production code building phase. (7) Improve RAM usage. Run the code either as a separate MultiFinder process or using MultiFinder temporary memory. Having to allocate RAM permanently to the application when megabytes of it are only useful during execution of the user code has a severely negative impact on the usefulness of MultiFinder. It becomes difficult to use THINK Pascal together with other programmer tools such as ResEdit, HyperCard (for documentation) and MPW (for resource and/or project management). (8) Check for unsafe VAR parameters, unsafe WITH statements, and uninitialized variable accesses. A few seconds per file are well worth the hours of debugging time it sometimes takes to find these errors. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Satanic is merely the name they give to the behavior of those who would disrupt the orderly way in which men want to live." -- Gabrielle, THE VAMPIRE LESTAT, Anne Rice
emerson@uvm-gen.UUCP (Tree,,,) (10/01/90)
From article <1990Sep26.233518.18704@midway.uchicago.edu>, by francis@arthur.uchicago.edu (Francis Stracke): > Just what do you mean by brackets? begin/end? It's got it; the indentation > works out automatically. > > Pascal's brackets, the comments, would be much nicer if they didn't have to > be one line apiece! Sorry, perhaps I should have said paren matching. While not as neccessary in Pascal as it is in C, it would be a welcome (at least for me) addition to the editor. Tree +----------------------------------------------------------------------+ | The three most dangerous things in the | | | world are a programmer with a soldering | Tom Emerson | | iron, a hardware guy with a software | emerson@hal.uvm.edu | | patch, and a user with an idea. | | +----------------------------------------------------------------------+
tim@efi.com (Tim Maroney) (10/02/90)
In article <12142@crdgw1.crd.ge.com> weesh@grymoire.crd.ge.com (Darweesh) writes: >> It would be nice if Think Pascal and Think C could share object code. In article <PHILS.90Sep25181555@chaos.cs.brandeis.edu> phils@chaos.cs.brandeis.edu (Phil Shapiro) writes: >They can, albeit in a limited fashion. Libraries built in Think C can >be added directly to Think Pascal projects. However, it requires source code changes in the THINK code. It is not possible to include unmodified libraries from THINK C.
b_murphy@fennel.cc.uwa.oz.au (10/02/90)
> since how many people mix languages?
I do, I do... Try: C + Pascal + Modula-2. What do you get?
Something someone wrote sometime for somebody. (What is documentation? :-)
--
-o (short for On-no)
()/)/)() can be r e a c h e d at B_MURPHY@VAXA.UWA.OZ.AU
_____________________________________________________________________
The net never sleeps, come to think of it, do I ever?
----> Thinking is dangerous, subversive and leads you astray. <----Lewis_P@cc.curtin.edu.au (Peter Lewis) (10/02/90)
Hi All,
Here is my 5c (Australia no longer produces 2c coins!) on THINK Pascal
bugs and wishes -
BUGS:
If (from the finder) you select project fred.proj and its file fred.p,
and then double-click them, TP may open fred.p twice (if re-open
windows is selected, and fred.p was open the last time you used fred.proj),
allowing both files to be edited and independantly saved leading to
lost changes.
If a const string s is defined, then s[i] is undefined if range
checking is on, ie -
{$R+}
const
s='Hello'
begin
for i:=1 to 5 do
writeln(s[i]) { this will not in general print an H e l l o }
end.
WISHES:
Command-Option-W & S should work (should Close All and Save All resp)
(and they should work irrespective of the CAPS lock key unlike
the finders treatment of command-option-W!)
Option-double-click on internal (local) procedures should bring up
there definition, and Option-double-click on a unit name in a uses
list should open (or bring to the front) the unit
The project file should be automatically overwritten when the
Build Application menu item is chosen (this could be an option like
Auto Save). That is, it should not even ask you for the name. The
output application name (and folder) could be set in the Set Project
Type dialog box.
Have Build (or a seperate command) optionally generate a window of
possible errors, including but not limitted to -
Functions that do not assign return values,
Variables, constants, types that are not used within their context
(Note: both of these can be done by having a boolean in the symbol
table, at little cost in compile speed)
Stops Out should cause the editor to actually use the left centimetre of
the window
REITERATION:
THINK Pascal is a wonderful environment. If it could read Net News,
send & receive Email, and edit resources, I could live there!
You can add my vote for at least half of the other suggestions!
See ya,
Peter.
Disclaimer:Curtin & I have an agreement:Neither of us listen to either of us.
*-------+---------+---------+---------+---------+---------+---------+-------*
Internet: Lewis_P@cc.curtin.edu.au I Peter Lewis
ACSnet: Lewis_P@cc.cut.oz.au I NCRPDA, Curtin University
Bitnet: Lewis_P%cc.curtin.edu.au@cunyvm.bitnet I GPO Box U1987
UUCP: uunet!munnari.oz!cc.curtin.edu.au!Lewis_P I Perth, WA, 6001, AUSTRALIAdw2x+@andrew.cmu.edu (Duane T. Williams) (10/06/90)
Faster processing of Uses, i.e., precompiled headers. Currently, THINK Pascal is SLOW, and it's primarily due to the long time it takes to load TCL. If THINK Pascal were to look for and load TCL.fast if it existed and was newer than TCL.p then things would be much faster.
monching@quiche.cs.mcgill.ca (Patrick WONG) (10/07/90)
I wouldn't mind having a way of getting the names of the functions and
procedures into the clip board or into a text file. Is there any way
I can do it now?
--
patrick wong | McGill University
monching@quiche.cs.mcgill.ca | School of Computer Science
| Montreal, Quebec