[comp.sys.mac.programmer] Problems with Think Pascal 2.0

lipa@POLYA.STANFORD.EDU (William Lipa) (12/05/88)

Well, here we go again. I haven't had any luck getting a response out of the
Think technical support account (singer@harvard.harvard.edu), so I thought I'd
post to the net in the hope that Rich might see my posting. I'd like to
summarize all the problems I've found with version 2.0 of their compiler.

1. Can't print to a LaserWriter SC in any font other than Monaco 12.
2. Occasionally when you Build Code Resource or Build Application, the linker
   will produce an error message "Duplicate File Name", even though you've
   specifically OK'd the overwrite of the previous version in the dialog.
3. The Build Code Resource and Build Application dialogs intermittently set
   the default folder to the root directory of the disk, not the directory
   of your project (which it should be if you double-clicked on the project
   to start the compiler).
4. You can't use the tab key to get from item to item in the Set Project Type
   dialog.
5. The editor still has the problem with leaving little bits of outlined text
   behind when you delete in front of them. For example, if the line looked
   like "normal OUTLINED" and you start backspacing though normal, parts of
   OUTLINED will not move left like they should. LSP 1.0 had this bug!
6. If you ever open LightsBug, whenever you open the project again LightsBug
   will appear, even if you had closed it before closing the project.
7. I had a very strange problem with a simple sorting program I wrote. Any
   attempt to access or change the variables of the program caused a Bus
   Error. The problem did not go away even when I created a whole new project
   to replace the old one. The program didn't access the Toolbox at all.
   However, now the program works fine. Very strange.

I experienced all these problems on a 4 meg Mac II with 8-bit color,
MultiFinder, System 6.0.2, and an internal Apple drive. I hope these problems
can be fixed because they detract from an otherwise great programming
environment!

Bill Lipa

kateley@Apple.COM (Jim Kateley) (12/05/88)

In article <CMM.0.87.597293634.lipa@polya.stanford.edu> lipa@POLYA.STANFORD.EDU (William Lipa) writes:
>   
>6. If you ever open LightsBug, whenever you open the project again LightsBug
>   will appear, even if you had closed it before closing the project.

Well, I figured this one out at least....Either close the LightsBug window
from the file menu, or hold down the command key when you click in the 
close box.  If you close a window with its close box, it just "hides" it.  
Option-close box "Hides" all windows, and command-close box will actually
close the window.

Jim Kateley          UUCP: {sun, voder, nsc, mtxinu, dual}!apple!kateley
S,P,HnS!             DOMAIN: kateley@apple.COM  Applelink: kateley1
Disclaimer:   What I say, think, or smell does not reflect any policy or
	      stray thought by Apple Computer, Inc.    (Die or Free Live)

lipa@polya.Stanford.EDU (William J. Lipa) (12/05/88)

In article <21659@apple.Apple.COM> kateley@Apple.COM (Jim Kateley) writes:
>In article <CMM.0.87.597293634> lipa@POLYA.STANFORD.EDU (William Lipa) writes:
>>6. If you ever open LightsBug, whenever you open the project again LightsBug
>>   will appear, even if you had closed it before closing the project.
>Well, I figured this one out at least....Either close the LightsBug window
>from the file menu, or hold down the command key when you click in the 
>close box.

Ah, you're right. Previous versions of LSP didn't have the concept of hiding
things like LightsBug and the Observe Window, so I was confused.
By the way, I dislike this feature of LSP. I wish clicking in the close box
did the normal "complete" close, and command-clicking did the hide. It's
one of the hardest things about LSP to explain to novice users.

Bill Lipa
Bitnet: lipa%polya@stanford

siegel@endor.harvard.edu (Rich Siegel) (12/05/88)

In article <CMM.0.87.597293634.lipa@polya.stanford.edu> lipa@POLYA.STANFORD.EDU (William Lipa) writes:
>Well, here we go again. I haven't had any luck getting a response out of the
>Think technical support account (singer@harvard.harvard.edu), so I thought I'd

	That's right, why don't you smear my reputation?! Just make it sound
as though I'm ignoring you. :-)

	The account is no longer "singer", it's "siegel". Since Andrew Singer
doesn't work here anymore,  and I'm the only one who uses the account,  it was
a sensible move. Sorry for the confusion.

>1. Can't print to a LaserWriter SC in any font other than Monaco 12.

	This, as I understand, is not a Lightspeed Pascal problem. You shoud
double-check the installation of your LaserWriter SC drivers and fonts.
(This is coming to me second-hand; sorry I can't be more specific.)

>2. Occasionally when you Build Code Resource or Build Application, the linker
>   will produce an error message "Duplicate File Name", even though you've
>   specifically OK'd the overwrite of the previous version in the dialog.

	This has never happened to me, and I overwrite old programs all th
time, and I've not heard any other reports of it. You might try various
disk and directory diagnostics (Disk First Aid, HD SC Setup's disk test) to
check out the hard disk.

>3. The Build Code Resource and Build Application dialogs intermittently set
>   the default folder to the root directory of the disk, not the directory
>   of your project (which it should be if you double-clicked on the project
>   to start the compiler).

	Is there any correlation between this problem and (2)? 

>4. You can't use the tab key to get from item to item in the Set Project Type
>   dialog.

	This one we know about, but didn't get fixed for release.

>5. The editor still has the problem with leaving little bits of outlined text
>   behind when you delete in front of them. For example, if the line looked
>   like "normal OUTLINED" and you start backspacing though normal, parts of
>   OUTLINED will not move left like they should. LSP 1.0 had this bug!

	What usually gets left behind is the bottom part of the text; forcing
an incrcomp (pressing the Enter key, in other words) after you type should 
clear it up.

>6. If you ever open LightsBug, whenever you open the project again LightsBug
>   will appear, even if you had closed it before closing the project.

	This annoys me too, if that's any consolation. :-) 

>7. I had a very strange problem with a simple sorting program I wrote. Any
>   attempt to access or change the variables of the program caused a Bus
>   Error. The problem did not go away even when I created a whole new project
>   to replace the old one. The program didn't access the Toolbox at all.
>   However, now the program works fine. Very strange.

	There's no relationship between having bus errors and using the
Toolbox. I haven't the faintest idea what happened to your program...

		--Rich



Rich Siegel
Staff Software Developer
THINK Technologies Division, Symantec Corp.
Internet: siegel@endor.harvard.edu
UUCP: ..harvard!endor!siegel
Phone: (617) 275-4800 x305

Any opinions stated in this article do not necessarily reflect the views
or policies of Symantec Corporation or its employees.

siegel@endor.harvard.edu (Rich Siegel) (12/05/88)

In article <5482@polya.Stanford.EDU> lipa@polya.Stanford.EDU (William J. Lipa) writes:

>By the way, I dislike this feature of LSP. I wish clicking in the close box
>did the normal "complete" close, and command-clicking did the hide. It's
>one of the hardest things about LSP to explain to novice users.

	The concept of "hide" versus "close" is a holdover from old
versions of Lightspeed Pascal, when the initial incremental compilation
took a long time, and loading a source file was a lot slower. For 2.0, it
was decided to generalize the concept and add this to code that was being
newly written, rather than muck around in extremely old code (and risk
breaking it).

	All this mishegoss will probably go away in the future.

		--Rich



Rich Siegel
Staff Software Developer
THINK Technologies Division, Symantec Corp.
Internet: siegel@endor.harvard.edu
UUCP: ..harvard!endor!siegel
Phone: (617) 275-4800 x305

Any opinions stated in this article do not necessarily reflect the views
or policies of Symantec Corporation or its employees.

billkatt@caen.engin.umich.edu (Steve Bollinger) (12/06/88)

In article <CMM.0.87.597293634.lipa@polya.stanford.edu> lipa@POLYA.STANFORD.EDU (William Lipa) writes:
>Well, here we go again. I haven't had any luck getting a response out of the
>Think technical support account (singer@harvard.harvard.edu), so I thought I'd
>post to the net in the hope that Rich might see my posting. I'd like to
>summarize all the problems I've found with version 2.0 of their compiler.
>
>2. Occasionally when you Build Code Resource or Build Application, the linker
>   will produce an error message "Duplicate File Name", even though you've
>   specifically OK'd the overwrite of the previous version in the dialog.

No, it isn't occasionally, it is always.  This is the same 'feature' as
LSP 1.0.  It only happens when you you try to build a file with the same
name as any file in the system folder.  It happens like this...
Lightspeed looks in the current folder for a file with the same name as the
one you wish to build, and since the System Folder is in the Poor Man's
Search Path (PMSP) it finds the file in your system folder.  Now, LSP somehow
ignores or forgets the fact that the file was found in the search path, not the
current folder.  Next, LSP tries to delete the found file, but it tries to
delete it from the current folder, this doesn't work.  Now LSP tries to create
a new file with that name, the the system returns an error because one with
that name already exists, the error you saw.
The moral of the story is that if you are building an INIT, RDEV, or cdev, then
build it directly into the system folder or onto another disk.

+----------------------+----------------------------------------------------+
| Steve Bollinger      | Internet: billkatt@caen.engin.umich.edu            |
| 4297 Sulgrave Dr.    +------+---------------------------------------------+
| Swartz Creek, Mi. 48473     | "My employer doesn't take my opinion any    |
+-----------------------------+  more seriously than you do."               |
| "You remember the IIe, it   +---------------------------------------------+
| was the machine Apple made before they decided people didn't need         |
| machines with big screens, color, or slots."                              |
|                                 - Harry Anderson (from NBC's Night Court) |
+---------------------------------------------------------------------------+

lipa@polya.Stanford.EDU (William J. Lipa) (12/06/88)

In article <762@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes:
>In article <CMM.0.87.597293634.lipa@polya.stanford.edu> lipa@POLYA.STANFORD.EDU (William Lipa) writes:
>>1. Can't print to a LaserWriter SC in any font other than Monaco 12.
>	This, as I understand, is not a Lightspeed Pascal problem. You shoud
>double-check the installation of your LaserWriter SC drivers and fonts.
>(This is coming to me second-hand; sorry I can't be more specific.)

I have checked; they appear to be installed correctly. All my other programs
can print to the SC successfully.

>>2. Occasionally when you Build Code Resource or Build Application, the linker
>>   will produce an error message "Duplicate File Name", even though you've
>>   specifically OK'd the overwrite of the previous version in the dialog.
>
>	This has never happened to me, and I overwrite old programs all th
>time, and I've not heard any other reports of it. You might try various
>disk and directory diagnostics (Disk First Aid, HD SC Setup's disk test) to
>check out the hard disk.

I tried this; no problems were found. And this error has happened to me on
two completely separate machines.

>>7. I had a very strange problem with a simple sorting program I wrote. Any
>>   attempt to access or change the variables of the program caused a Bus
>>   Error. The problem did not go away even when I created a whole new project
>>   to replace the old one. The program didn't access the Toolbox at all.
>>   However, now the program works fine. Very strange.
>
>	There's no relationship between having bus errors and using the
>Toolbox. I haven't the faintest idea what happened to your program...

The relationship is: if I get a bus error without using the Toolbox, then it
is much more likely that the problem is in the compiler, because I can't have
messed up the Toolbox/System by some mistake of my own.

I realize that it's possible that my Mac II or its hard disk is somehow
responsible for these errors. However, this seems unlikely because I've
gotten them on different machines (one another Mac II, and one a Plus).
Other applications aren't giving me unusual problems.

Bill Lipa
Bitnet: lipa%polya@stanford