Think Pascal Wishes...?
Rich Siegel
feature requests? Annoyances? Any sort of commentary?
R.
Rich Siegel Software Engineer Symantec Languages Group
Internet: sie...@endor.harvard.edu UUCP: ..harvard!endor!siegel
If you have telekinetic powers, raise my hand.
Darweesh
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
Mike Gleason
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 252u...@fergvax.unl.edu
* "Don't you f*ckin' look at me!" -- D. Hopper cos...@unlcdc2.unl.edu
Philip Machanick
> 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
phi...@pescadero.stanford.edu
James T. Tanis
>..........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.
>-Mike Darweesh
Yeah! and give it to think C users too!
the lightspeed/Think/Symantec environment is just great - I prefer it even
to cc, but it _really_ does need something like RCS.
Source formatting like emacs and think Pascal would be nice to see in C
as well... If you use something like f/lex for parsing it
shouldn't be too hard. :-)
All in all, though, great product.
-JT
gix@mdivax1
>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: sie...@endor.harvard.edu UUCP: ..harvard!endor!siegel
>
>If you have telekinetic powers, raise my hand.
--Brian Gix
--
================================================================================
|| Brian Gix || g...@mdi.com gi...@prism.cs.orst.edu ||
|| MDI - Motorola || g...@nwnexus.wa.com ...!uunet!mdisea!gix ||
|| Bothell, WA 98011 USA|| AmOnline: GIX Phone: (206) 487-5894 ||
Mike Gleason
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... :-)
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?
Phil Shapiro
> It would be nice if Think Pascal and Think C could share object code.
>
> -Mike Darweesh
> we...@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
ph...@chaos.cs.brandeis.edu
Joe Pillera
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
pil...@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.
Jan Erik Mostr|m
# 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 Hear
Tree,,,
> 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 | eme...@griffin.uvm.edu |
| patch, and a user with an idea. | |
+----------------------------------------------------------------------+
Stuart A. Malone
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
sama...@athena.mit.edu
Pete Keleher
> 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 pe...@titan.rice.edu
=============================================================================
Darweesh
Mike Gleason
(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.
Wayne Rasband
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 (wa...@helix.nih.gov)
rc...@eagle.wesleyan.edu
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
rc...@eagle.wesleyan.edu
--
Bob Daniel
than creating a new one every time (as an option).
_________
moof moof
Paul T Russell
>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: pa...@uk.ac.sussex.syma Nsfnet: pa...@syma.sussex.ac.uk
Bitnet: paulr%susse...@ukacrl.bitnet Usenet: ...ukc!syma!paulr
Philip Machanick
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
phi...@pescadero.stanford.edu
Francis Stracke
>From article <42...@husc6.harvard.edu>, by sie...@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!
Peter Homeier
>feature requests? Annoyances? Any sort of commentary?
>
> Internet: sie...@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
hom...@aerospace.aero.org
Francis Stracke
>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 Stracke
>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.
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.)
Dan Boerner
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
boe...@mist.cs.orst.edu
Gary Czychi
>feature requests? Annoyances? Any sort of commentary?
>
> Internet: sie...@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
czy...@csghsg52.BITNET (preferred)
czy...@bernina.ethz.ch.UUCP (CZY...@ETHZ.uucp)
Tel.: --41 / 71 / 57 17 22
Lars Sundstr|m
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
ph...@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: su...@tde.lth.se |
+---------------------------------------------------------------------+
KOF...@cc.utah.edu
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 |
| kof...@bioscience.utah.edu |
| |
| -- The University of Utah is blameless for anything I've said -- |
|__________________________________________________________________|
Randy Buckland
>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
ra...@ncsu.edu (919) 737-2517
pooh 'Ernst' Mulder
(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
lib...@yoyodyne.ncsa.uiuc.edu
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
lib...@ncsa.uiuc.edu
Greg Finnegan
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: finn...@dhw68k.cts.com
--------------------------------------------
Tim Maroney
>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, t...@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
Tree,,,
by fra...@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!
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 | eme...@hal.uvm.edu |
Tim Maroney
writes:
>> It would be nice if Think Pascal and Think C could share object code.
In article <PHILS.90S...@chaos.cs.brandeis.edu>
ph...@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_mu...@fennel.cc.uwa.oz.au
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_MU...@VAXA.UWA.OZ.AU
_____________________________________________________________________
The net never sleeps, come to think of it, do I ever?
----> Thinking is dangerous, subversive and leads you astray. <----
Peter Lewis
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: Lew...@cc.curtin.edu.au I Peter Lewis
ACSnet: Lew...@cc.cut.oz.au I NCRPDA, Curtin University
Bitnet: Lewis_P%cc.curti...@cunyvm.bitnet I GPO Box U1987
UUCP: uunet!munnari.oz!cc.curtin.edu.au!Lewis_P I Perth, WA, 6001, AUSTRALIA
Dave Smith
1) the ability to get the address of a string constant or literal so I
can pass them as VAR or stringPtr parameters - for efficiency
2) the ability to search backwards
3) a cross reference tool - to display all uses of a symbol
4) the ability to see the name of the procedure I'm editting (for
large procedures) - useful after a search