jkjl@munnari.oz (John Lim) (09/15/88)
Dear Rich, heres a long critique of LSC. If you could forward it
to M. Kahl I would be grateful.
I have been using LSC 3.0 extensively for the past month, and have
written about 10 000 lines of code with it so far. It's a great
improvement over 2.15, but to me it seems that in taking two steps
forward, THINK has taken 1 step backwards...
What I mean by this is that in developing LSD (:-) they didnt implement
many of the features of their sister compiler LSP. LightsBug is much
superior when you are doing a stack crawl, or you want to view the
application heap. LightBug's memory dump is a lot better than the display
as Address feature of LSD when doing programs that involve large blocks of
memory which cant be described easily by structs/unions, like variable length
records or viewing text buffers.
The stack crawl feature is LightsBug is so much superior to LSD. I do a lot of
data hiding in my code, so the current context might not allow me to view
a variable that was used in the calling function.
For example :
/*========= In one file ===============*/
static int not_in_context;
f() { int not_in_context; a(); }
/*========= In another file ===========*/
a()
{
/* I want to view both values of 'not_in_context' here */
}
I know that you want to optimize the debugger so that it's fast, but couldnt you
make it optional to view it like you do with structs (i.e. display only
on double-click). Maybe you can have 3 data areas : 1 for auto, 1 for extern,
and 1 for static vars.
A minor bug i have noticed is that using cmd-D to write a variable to the
data window doesnt work if you have selected an identifier in the declaration
section, but selecting it from a stmt works.
LSP allows you to search for a missing file. LSC just tells you a file cant
be found. This is very irritating, as it often means i have to delete the
file from the project and copy it again. A minor quibble though.
The next feature LSP enjoys is the ability to alter options on a file by file
basis (i.e. range checking etc.). When writing code for multiple machines,
it would be really useful to be able to select 020 code for files that will
only be used on a Mac 2 while 000 code is used for the other files that will
run on SE's etc. Furthermore, if #define _68881_ and #define _68020_ were
automatically predefined if the 020 /881 options were turned on would help
improve code maintainence immensely. If we could simply do a
#Options -68020 -Debugger -DebugName
on a file by file basis like MacC (i dont believe it - i just complimented
one of the worse C compilers out there !).
All the above features that LSP has is lacking to some degree in LSC. Now
here comes the wish-list of future features that is specific to LSC 4.0
only.
1. asm for 68020/68881
2. opening TEXT files when no project is open. I.e. using LSC
as a plain-vanilla text editor.
3. multiple views of a file (i.e. split windows).
4. crc of project on request. Very useful as the project might
become corrupt, but you only find out after you deleted your
old backup and replaced it with a new 'corrupt' backup. Happened
to me. I couldnt even remove the offending file from the project
because it was corrupt. Recompiling the project sometimes doesnt
help either. Throwing it away and adding again is a pain when you
have 100+ source files ( i like data-hiding).
5. better use of address register variables in arrays:
i.e. p[i] = q[i] should generate asm { move.? 0(p,i),0(q,i) }
when p,q,i are all register vars.
6. Instead of making the user inform the stdio libs that the mac
initialization (initgraf etc.) has been done, put a check in your
Init_Stdio() code to check if (WWExist == 0) /* means Window Mgr
already inited */
7. LSD specific QuicKeys macros dont seem to work properly. Is
that my fault, or due to the caching scheme used by the INIT
provided ?
8. Saving of data window variables and contexts. I know that your
debugging tables could be changed by recompiles, but i dont mind
if the variables are displayed as undefined the next time i Run.
At least it saves me the trouble of retyping the vars again, as
all i have to do is reset the context.
9. Make LSC 4.0 a free upgrade :-)
I like the product. I just wish it were perfect.
john lim
jkjl@munnari.oz
jwhitnell@cup.portal.com (09/17/88)
jkjl@munnari.oz (John Lim) writes... | 7. LSD specific QuicKeys macros dont seem to work properly. Is | that my fault, or due to the caching scheme used by the INIT | provided ? Quickeys on LSD work fine for me (no pun intended :-). One possibility is that you have a corrupted QuicKeys file. When that happens, strange things will happen. For example, at one time I couldn't save any defintions for StuffIt but could to all other programs. The solution is simple, but painful. Save all your defintions with Quick Access, install a new copy of QuicKeys from your master disk and restore your definitions. This appears to fix most random problems of the sort you describe. BTW, I aggree with your other comments. 4.0 should be as significant as 3.0 if they implement even half of what they are talking about. Things that have been mentioned as possible include C+-, a subset of C++ sufficent to implement MacApp and a programable editor, either by macros (written in C and compiled!) or by allowing third parties to replace the editor with their own. But don't hold your breath, remember how long it took to get from 2.0 to 3.0. -- Jerry Whitnell jwhitnell@cup.portal.com ..!sun!cup.portal.com!jwhitnell
tim@hoptoad.uucp (Tim Maroney) (09/26/88)
My biggest objection is that the DA shell is useless. I spent two weeks
writing a DA under that shell, only to have practically everything break
when I converted it to a real DA. Some things simply couldn't be made to
work at all in the DA, though they could in the fake version -- for instance,
the Standard File Package in front of a DA window under MultiFinder, and
saving function pointers in a multi-segment DA. What a rip-off. Would
it be so hard to make the debugger smart enough to follow what a real DA
is doing? What is the point of debugging in a friendly environment if
the debugging only works for a mock-up?
And regardless of the environment, I'm pretty tired of bugs stepping on my
project files. The documentation is positively snide on this point, like
it's my fault if I write code that has bugs in it. Bugs are what programming
is all about; I challenge anyone to write a 75K+ program with no unforseen
bugs. Apparently we're supposed to back up the project file before every
test run. If there is some way on the Mac to ensure you never write to
other applications' memory during development, I sure would love to hear
about it, as would the validation theorists working on SDI. Saying "You've
got to be more careful with dangling pointers" is like saying "Be careful
whose car you hit." If you can help it, you won't hit anyone's. If you
can't, there isn't much opportunity for choice in the matter.
As development environments go, LSC 3.0 does have some unusual virtues.
But its flaws are brain-damaged, unavoidable, and extremely annoying.
(By the way, I had no problem whatsoever getting the List Manager to work with
a custom list definition, in either environment. In fact, except for A4
handling and the LDEF resource id, list code from an application worked just
fine the first time in a DA. I don't know what the problem could be.)
--
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"Because there is something in you that I respect, and that makes me desire
to have you for my enemy."
"Thats well said. On those terms, sir, I will accept your enmity or any
man's."
- Shaw, "The Devil's Disciple"sho@pur-phy (Sho Kuwamoto) (09/26/88)
In article <5453@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Apparently we're supposed to back up the project file before every >test run. I would like to have some sort of check box that would let you make automatic backups of your files when you run. The project files are kind of huge, but I would have been saved days of work if, say, three backups of my resource file had been automatically maintained. I know I could do it myself, but it's such a pain. By the time I realize my resource file has been trashed, either my last backup is also trashed, or it's been about a week since I made a backup, and I have to recreate a lot of work. And ResEdit being buggy as anything sure hasn't helped. -Sho
mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) (09/28/88)
In article <5453@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: ><gripes about stepping on project file deleted> > If there is some way on the Mac to ensure you never write to >other applications' memory during development, I sure would love to hear >about it, as would the validation theorists working on SDI. Saying "You've >got to be more careful with dangling pointers" is like saying "Be careful >whose car you hit." If you can help it, you won't hit anyone's. If you >can't, there isn't much opportunity for choice in the matter. > >As development environments go, LSC 3.0 does have some unusual virtues. >But its flaws are brain-damaged, unavoidable, and extremely annoying. >-- >Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim Yes, there is a way that you never write to other application's memory: It's called hardware memory protection. You don't think that a multi-user computer can afford to crash whenever people dangle their pointers? The bottom line is that each process gets its own virtual address space. The totality of all processes address spaces get mapped on to the physical memory space, or possibly, disk sectors on a paging volume. Any attempt to write to "unauthorized" memory locations generally causes an operating system trap. In such a system, a chip sits in between the CPU and the memory, translating "virtual addresses" (what the program running on the CPU sees) to actual physical addresses of real memory. Unfortunately, most Macintoshes dont' have such a beast. Only the Mac II can be so equipped (it does not come standard) with a PMMU (paged memory management unit). You need this to run A/UX. The 68030 has the equivalent of the 68851 PMMU built-in. Presumably, the MacOS will eventually modified to provide inter-process memory protection (there's then no reason not to add in true pre-emptive multitasking and virtual memory), but this could be a major headache considering it's very hard to retro-fit it in and still maintain compatibility. For example, I wager that many commercial programs twaddle with low memory globals in various evil ways. Presumably, ina protected memory system, these globals would be protected from writing by all processes except the operating system, because changing them accidentally can easily produce a system crash. Back to program development: I'm sure that, when implemented, hardware memory protection will catch _tons_ of bugs in many programs: whenever you dereference a bad pointer and trap, you could easily make the debugger point at the very instruction that got screwed up. (This is done on virtually all "large" systems--Unix, and VMS for example. I'm not sure about OS/2, but if OS/2 were written for a 80386 instead of the god-awful 286 it could easily do this.) But for now, there is no real practical way to prevent your program from trashing any part of memory. LSC could, however _detect_ that its internal structures and the project file have been corrupted by computing a CRC checksum on various segments, for example, and then automatically re-loading those that have been trashed. Matt Kennel mbkennel@phoenix.princeton.edu
tim@hoptoad.uucp (Tim Maroney) (09/29/88)
In article <3784@phoenix.Princeton.EDU> mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) writes: >In article <5453@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >> If there is some way on the Mac to ensure you never write to >>other applications' memory during development, I sure would love to hear >>about it, as would the validation theorists working on SDI. > >Yes, there is a way that you never write to other application's memory: >It's called hardware memory protection. You don't think that a >multi-user computer can afford to crash whenever people dangle their >pointers? Read my lips: I said "on the Mac". I learned to program on VAXen and I don't need a memory protection 101 lecture. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "In any religion or form of worship, followers should be allowed to think for themselves. In every religion that has a god other than Jesus Christ, adherents are not allowed to think for themselves." -- Lauren Stratford, "Satan's Underground"