gf0c+@andrew.cmu.edu (Gregory S. Fox) (12/14/88)
It is probably foolish to post this message without the actual source code in front of me, but... I needed a dialog box with a scrolling list field for an MPW C program. Due to some initial difficulty, I quickly decided that I needed a debugger before things became too frustrating. So, with few additional obstacles, I did just this- in LSC 3.0, using the list manager, all very spiffy. And then I tried to port the whole business back to MPW. I'll leave the image of twisted, screaming, flaming code, replete with bus and address errors, to your own experience. Well, my first conclusion was that there was some discrepancy between the way LSC and MPW C dealt with function parameters. Regrettably, my C skills are such that I required a source level debugger in the first place, so I have not progressed beyond this diagnosis. Perhaps this topic has come up in the past; if so, your collective pardon for the redundancy. Regardless, whatever illumination anyone might shed upon the darkness of this ignorance would meet with gratitude in proportion to my enlightenment. -greg "If you have to hurry, it's already too late" fox
emb1354@uxf.cso.uiuc.edu (12/18/88)
A possible problem which immediately springs to mind is the old issue in MPW of differences between LNew() and LNEW(), LSetCell() and LSETCELL(), etc. Be sure you are using the correct call. Also, I have found errors (that's right, errors) in the <lists.h> file with MPW C 2.0.2 (or maybe it was in 2.0 and was corrected in 2.0.2). Anyways, that gives you something to shoot at. Hope it helps. ***************************************************************** * Eric M. Berdahl * "Y'know, there's alot of air" * * PsiWare Software, not inc. * -Robert Miller * * emb1354@uxf.cso.uiuc.edu * * *****************************************************************
beard@ux1.lbl.gov (Patrick C Beard) (12/19/88)
In article <8XdRTFJ38k-046a0QN@andrew.cmu.edu> gf0c+@andrew.cmu.edu (Gregory S. Fox) writes: >It is probably foolish to post this message without the actual source >code in front of me, but... > >I needed a dialog box with a scrolling list field for an MPW C program. >Due to some initial difficulty, I quickly decided that I needed a debugger >before things became too frustrating. So, with few additional obstacles, >I did just this- in LSC 3.0, using the list manager, all very spiffy. > Uh-oh. LSC and MPW V2.0.2 are incredibly incompatible. However, having just received MPW C 3.0B1, the incompatiblities seem to have shrunken considerably. >And then I tried to port the whole business back to MPW. > >I'll leave the image of twisted, screaming, flaming code, replete with >bus and address errors, to your own experience. Well, my first >conclusion was that there was some discrepancy between the way >LSC and MPW C dealt with function parameters. Regrettably, >my C skills are such that I required a source level debugger >in the first place, so I have not progressed beyond this >diagnosis. > LSC does everything consistently with the way Pascal does it. Points are passed by value, when appropriate, to the ROM. Pascal strings are used. The routines are spelled as is documented in Inside Macintosh. MPW C (2.0.2) has this silly habit of passing points by address, and if one uses the same routine spelling (same case) as Inside Macintosh, the routines assume they are getting C strings! The nice thing about LSC is that if you know that a ROM routine, when called from Pascal, has a VAR parameter then in C you should pass it by address, otherwise if sizeof(Parameter) <= sizeof(Point), you will pass it by value. >Perhaps this topic has come up in the past; if so, your collective >pardon for the redundancy. Regardless, whatever illumination anyone >might shed upon the darkness of this ignorance would meet with gratitude >in proportion to my enlightenment. > I don't mind. It lets me get some of this off of my chest. Now, some comments about MPW C 3.0B1: 1. ANSI prototypes; if present in your code, the compiler does some nice checking of the parameters. So far, so good. There is even a -r switch that makes the compiler nag you if you call a function before prototyping. 2. Sensible calling conventions, Str255's are now typedef'd as unsigned char arrays, no more structure! That one was a nightmare for porting from/to MPW C. So many changes! Points are now passed by value. 3. Larger than 32k, data AND code. Though it can be inefficient to use on a 68000, it can be done! Function size is only limited by available memory. Question Apple: Why don't you use temporary files to dump symbol information to as memory runs short? C compilers for (horror of horrors) 80xxx processors, forced to by hardware limitations do that, so why not give people with 1-2 meg machines the option to wait EVEN LONGER for the compiler to finish, but at least be able to compile unlimited size functions? It can't be that hard. 4. Now here is a weird wrinkle. I have been zapped by it quite a few times so far. Guess what they've done to our '\n' and '\r'? They've switched them! '\n' = 13, and '\r' = 10 in ASCII. WHY??? I like to use these to make my code a little more readable. Now I can't test for '\r' to see if the return key was hit. I have to check for 13! CHANGE THIS BACK. 5. Now here is an annoyance about the basic architecture of MPW C. Why must one use an #include file to get the definitions of traps? I like the fact that ALL ROM routines are now prototyped, but why don't you provide a binary file to link with (similar to MacTraps in LSC) that contains these definitions? MPW C 3.0B1 has #pragma's for load'ing and dump'ing symbols to files. Will this greatly decrease compile times? I wonder, I tried the #pragma dump "symbols" and it produced a symbol file ~300K after I #included 10 or so files. And it wouldn't link, so there must be some kind of bug there. >-greg "If you have to hurry, it's already too late" > fox So, conclusions: MPW C 3.0B1 is closer than before to LSC, but it's still pretty slow (1000 line program takes about 1 minute to compile and link, just one file and standard interface libraries). Patrick Beard Lawrence Berkeley Laboratory