ADVERTISEMENT

Parse Table Correction

By Kirk Chase, Editor, MacTutor

Parse Table Correction

Kirk Chase

Unfortunately, Clifford Story’s second part in his Language Translation Series was missing the parse table. Here it is for you now:

Dialogs, the easy way

Neil Ticktin

I was glad to see that dialogs are now getting some press. I wanted to make sure, though, that your readers connect dialogs with Extender DialogHandler™ by Invention Software. First, there is a review by David Kelly on DialogHandler in the January, 1990 issue of MacTutor.

In the April, 1990 article on extending modal dialogs, Paul Potts talks about default bold outlining, key equivalents and default items.

DialogHandler takes care of all of these things automatically for you. In your article on Messenger, you speak about placing dialogs, icons, multiple buttons, character equivalents, and adding filters. Again, DialogHandler takes care of all of these things as well -- all automatically. In short, DialogHandler handles push buttons, multiple sets of radio buttons, check boxes, counter items, icons and pictures with animation, display text items, pop-up menus, pull down menus, “pick lists” (list manager style), and string, integer, long integer, and real “flavors” of edit and static text. All number conversion, on-the-fly character filtering, cut/copy/paste support, and key equivalents are taken care of automatically.

DialogHandler now supports modeless dialogs. In addition, almost every item can have a “user hook” associated with it. In other words, if you want a push button to do something special, you can write a procedure to do that and pass a pointer to that procedure to DialogHandler. DialogHandler, in turn, will call your routine when the item is hit.

For example, take a simple dialog that asks for an integer between -100 and 100, has a bold outlined OK button, a Cancel button, on-the-fly character filtering (the user can’t enter a bad character), full cut/copy/paste support, range checking with alert and handling of the ok and cancel buttons. Using DialogHandler, you can write the support code for this dialog with 6 lines of code.

In summary, if you are doing dialogs, modal or modeless, you can do them in 5-10% of the time using Extender DialogHandler™ from Invention Software at 313-996-8108. It will pay for itself on the first dialog. As you already may know, MacTutor is also selling DialogHandler in the mail order store.

MultiFinder Detection

Ajay Nath

Daniel Allens excellent book, “On Macintosh Programming: Advanced Techniques”, shows a quick way (on p. 160) to find out if MultiFinder is running. Simply examine the long word at $B7C which is called “Twitcher2”, if its less than 0 then MultiFinder isn’t running. I have a feeling that somebody at Apple didn’t read his book too carefully since I don’t think they’d want us to know this.

cdevShell

Charles Dyer

I am writing about that cdevShell.p article in February, 1990 MacTutor. I finally got it all entered and tried to test it out, but then I found drumroll, please BUGS. Some of them were typos, but those were easily fixed. However, I still get the ever-popular ID=2 and ID=28 bombs even after I had corrected all of my spelling errors. So I used TMLPascal’s TMLPasRef utility to try to track who did what/where, and guess what: a lot of items are initialized but never used. In particular, the variables totalItems, p, c, tempD, and r in the procedure startupCdev are never used anywhere. It appears that a line or two may have been left off. And those were only the more obvious and easier to find examples. After I found them, I went through the source checking every case where PasRef said that a variable had been used once, and found several others. I also checked the .r file, and noted that there doesn’t seem to be a DLOG or an ALRT for DITL -15999.

Tracking would have been easier if only Mr. Hoddie hadn’t used so many cryptic variable names. I mean, in startupCdev the variable c is of type ControlHandle. A little further on, there is another c which is an INTEGER. Would it have been so difficult to use theControl and counter, respectively? The whole programme is peppered with single-character variables: e, i, j, p, r I haven’t seen so many single-character variables in one place since I stopped using BASIC on an Apple II. Variable names like dP, tempD, and rH don’t help either. It’s not so bad if the thing works right the first time, but

In the past, if I had a problem, when I translated a program over from Pascal to Modula-2 and things didn’t work, I wouldn’t know if it was because so obscure difference between Pascal and Modula-2 or if it was just that I did something wrong. Thanks to TML, if it doesn’t work and I can’t find any difference between my code and what’s in the magazine, I’d say something is wrong with the published code. In any case, I’ve gone through my code several times and cannot see where I’ve gone wrong. It might still be something I did, so I’ll try again, but in the meantime, I’d like to know if anyone else has had any problems with cdevShell.p.

I now use TML Pascal II, as SemperSoft seems to have bitten the dust. I would like to get another Modula-2 package, but no-one else seemed to have an MPW Modula-2 package available. Having shelled out all that cash for MPW in the first place, I am not going to give up on it without a fight. I’ll even get C-ugh-if I have to. Actually, what with UNITs and some of the other extensions, TML Pascal is almost Modula-2 anyway. The .o and executable files that TML makes are a little bigger than those made by SemperSoft Modula-2, but TML is faster and doesn’t give weird problems when you’re trying to build cdevs and INITs. The biggest problem so far has been the Show Icons LDEF demo program from the TML Source Code Library crashes and burns under MultiFinder. I haven’t gotten around to writing them about that yet.

[I have check the printed code against the original source code, and I could not see a line missing in startupCdev. I have had no complaints, other than yours, about cdevShell.p. I ask if anyone else has to write a letter to MacTutor. On the good side, Metrowerks has Modula-2 for MPW at $150. Their phone number in the USA is 514-458-2018; their FAX number is 514-458-2010.-ed]

MPW Pascal Compiler

Richard H. Winkler

We have discovered a bug in the MPW Pascal compiler which has remained constant from version 2.02 through version 3.1. The bug arises when the stack frame in a procedure exceeds 32k bytes in size. Two Pascal programs used to test this bug differ only in stack frame size, the program ‘lgstkfrmst’ had added to it a second array, z2: ARRAY[1..7000] OF REAL, which caused the stack frame to grow beyond 32k. As one would expect, the addressing strategy for all stack frame variables which are normally addressed indirect through A6 is altered such that A6 is moved to A0, the variable offset is added to A0, and the variable is then addressed indirect through A0. The assembly code produced from ‘lgstkfrmst’ produces an instruction:

;1

PEA$252A(A6)

which should in fact be the set of instructions:

;2

MOVEA.L A6,A0
ADDA.L  $FFFF252A, A0
PEA(A0)

This is a particularly unusual error in that the lower half of the address is correct. Had the compiler used proper (A6) addressing one would have expected something other than $252A. In particular one would have expected -$6D6C as in the assembly listing of ‘smstkfrmtstcd’, the smaller stack frame test code. This error is believed to occur following calls to transcendental function other than _LN.

As a historical note, let me add the following. I suspect that what is now the MPW Pascal compiler was originally developed by Silicon Valley Software for earlier 68000 based machines. In particular, I believe that this was the same Pascal compiler used for the ill fated IBM 9000 computers. I have worked extensively with 9000’s and base this conclusion on the fact that the manual included with version 2.02 of the MPW complier was word for word identical, down to the page breaks, with the Pascal manual supplied with the IBM 9000. With the 9000 compiler, we also had a compiler bug associated with the stack frame growing beyond 32k bytes. In particular there was a range of stack frame sizes from 32000 bytes to somewhere greater than 32768 bytes where the stack frame pointer, A6, was set point to the load point of the system library rather than to the stack frame when a subroutine was entered. This bug was fixed by IBM (Silicon Valley Software?) in version 2.0 of the compiler, but I find it an interesting coincidence that the MPW compiler has a bug which arises under similar circumstances surrounding the stack frame.