pnm@goanna.oz.au (Paul Big-Ears Menon) (03/15/90)
hi,
I am having a few problems with Eiffel, and as it appears - some of
them relate to the compiler/code generator (I won't bore you with MY probs).
Four problems...
**********************
Problem 1
Eiffel's behaviour changes dramatically when using the Garbage Collector.
ie, it bombs. For instance, using the default checking options & optimse, I
get the lex example working fine.
I add Garbage Collection into my .eiffel file and BAM! this results..
////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
godzilla 32% eiffel_scan.garbage eiffel_l^R
eiffel_scan.garbage eiffel_scan.e
Warning: some tokens can be recognized by "div" and by ~('a'..'z') *(~('a'..'z')
|'_'|'0'..'9').
The second one has priority.
Warning: some tokens can be recognized by "mod" and by ~('a'..'z') *(~('a'..'z')
|'_'|'0'..'9').
The second one has priority.
Scanning file `
System execution failed.
Below is the sequence of recorded exceptions:
--------------------------------------------------------------------------------
Object Class Routine Nature of exception Effect
--------------------------------------------------------------------------------
100C68A0 STD_FILES putstring External event:
Segmentation violation. Fail
100263F8 EIFFEL_SCAN create External event:
Segmentation violation. Fail
--------------------------------------------------------------------------------
100263F8 EIFFEL_SCAN create External event:
Segmentation violation. Fail
--------------------------------------------------------------------------------
4.6u 1.0s 0:08 65%
godzilla 33%
/////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Is the Garbage collector doing something crazy? Has someone got this to
work with Garbage Collection on? Can GC be trusted? Are the garbage
collectors on strike?
********************************
Problem 2.
I think it was to do with the lex example, I've had to change
string.e in the kernel lib, otherwise the program would go off the
deep end (of file), it wasn't picking up the EOF token.
//////////////////////\\\\\\\\\\\\\\\\\\\\\\\
item_code (i: INTEGER): INTEGER is
-- Ascii code of character at position i
require
index_large_enough: i > 0 ;
index_small_enough: i <= count
external
give_code: INTEGER language "C";
toc: INTEGER language "C"
do
Result := give_code (i, toc (area));
--
-- RMIT FIX (ok! hack) 19/12/89
--
if Result > 127 then
Result := -1
end -- if
end; -- item_code
//////////////////////\\\\\\\\\\\\\\\\\\\\\\\
My questions are,
* should the hack be here... (string.e) or in the C file (toc/give_code1)?
* Is the hack valid? ie what about the char codes twixt 128 and 254?
Note: the C external "toc" appears in problems 1 and 2.
******************
Problem 3
When trying to find the source of these errors (err.. and others), I used
the debugging (viewing) facilities provided. Please correct me if I'm
missing something, but do I have to recompile my program *everytime* I
insert a new "breakpoint", or delete an unwanted one? If so, this is not
a very productive tool, in fact it's quite painful!
******************
Problem 4
The tester - et. How do I "Create" an object which takes arguments?
Or will this disappear with "Create's" change of status in the near future?
***********************
We have Eiffel v 2.2B running on Personal Irises.
Note: We did have a few other probs with 2.2A - these were rectified in the
next version.
Any help will be treasured,
Thankyou,
Paul Menon,
Dept of Computer Science,
Royal Melbourne Institute of Technology,
124 Latrobe Street,
Melbourne 3001,
Victoria, Australia.
PH: +61 3 660 3209
pnm@goanna.cs.rmit.OZ.AUjos@cs.vu.nl (Jos Warmer) (03/15/90)
I can't help you, but you are not on your own.
Problem 1: I had identical problems with the garbage collector in version 2.1
and version 2.2A. With 2.2A the problem came forward in the
lexical library. The exact details were sent to ISE.
It seems that the garbage collector is not always working correct.
Problem 2: I don't know.
Problem 3: The viewer does not have the possibility to set and/or delete
breakpoints. It is indeed very limited and therefore almost useless.
I never use it.
Problem 4: I don't know.
Following problem 3, I have a question to eiffel users:
Does anyone out there actually USE the viewer for debugging ?
If not, how do they manage debugging.
Jos Warmer
jos@cs.vu.nl
--
Jos Warmer
jos@cs.vu.nl
...uunet!mcvax!cs.vu.nl!josmarcap@hercule.cs.concordia.ca (PAWLOWSKY marc) (03/16/90)
In article <5983@star.cs.vu.nl> jos@cs.vu.nl (Jos Warmer) writes: > Does anyone out there actually USE the viewer for debugging ? > If not, how do they manage debugging. > > Jos Warmer > jos@cs.vu.nl The old fashoned way with write statements everywhere in debug blocks. That is why I feel named debug blocks are necessary, so you can selectively turn them on and off. (Yes I could use global variables and if statements, but that defeats the purpose of a debug block.) Marc Pawlowsky Grad Student Concordia University
jp@eiffel.UUCP (Jean-Pierre Sarkis) (03/16/90)
The garbage collector problem encountered by Paul Menon and Jos Warmer apparently corresponds to a bug in the run-time system of 2.2B, which manifests itself when the garbage collector is run in certain conditions (having to do with string objects). The following fix, which should remove Professor Menon's problem, may be applied by all installations. Mail will be sent regarding the other problems mentioned in Professor Menon's message. -- Jean-Pierre Sarkis jp@eiffel.com (Reply address for this and any other customer support problem: eiffel@eiffel.com) ------------------------------------------------------------ The correction should be applied to routine get_arg in file _basic.c in directory INSTALLATION_DIRECTORY/Eiffel/files. How to proceed: 1. ``Change directory'' to the above directory. 2. Make a backup copy of file `_basic.c'. 3. Edit this file and change the definition of function get_arg () as indicated below in ``diff'' format. ................. BEGIN CHANGE ...................... 220,221c220,221 < DATUM strarg; < if(n >= argc) return(DATINT(0)); --- > DATPTR strarg; > if(n >= argc) return((DATUM)NULL); 238,240c238,241 < strarg = DATOBJ ( MakeStr(p+1)); < if (gac_option) ONCE(strarg); < return(strarg); --- > strarg = (DATPTR)malloc (sizeof(DATPTR)); > (*strarg) = DATOBJ ( MakeStr(p+1)); > if (gac_option) ONCE(*strarg); > return(*strarg); 260,262c261,264 < strarg = DATOBJ ( MakeStr(p)); < if (gac_option) ONCE(strarg); < return(strarg); --- > strarg = (DATPTR)malloc (sizeof(DATPTR)); > (*strarg) = DATOBJ ( MakeStr(p)); > if (gac_option) ONCE(*strarg); > return(*strarg); ................. END CHANGE ...................... 4. Re-generate the archive of the run-time system by running make -f _makeD 5. [Only on a BSD version of Unix]: Run ranlib _run_time.a This should correct the problem.
jp@eiffel.UUCP (Jean-Pierre Sarkis) (03/17/90)
As several people noted, in the bug fix posted earlier, the ``diff'' was taken with respect to a version of the file which is not the released version. Here is the proper one. Our apologies for the mixup. -- Jean-Pierre Sarkis jp@eiffel.com Reply to: eiffel@eiffel.com .............................. BEGIN CHANGE .................... 220c220,221 < if(n >= argc) return(DATINT(0)); --- > DATPTR strarg; > if(n >= argc) return((DATUM)NULL); 237c238,241 < return(DATOBJ ( MakeStr(p+1))); --- > strarg = (DATPTR)malloc (sizeof(DATPTR)); > (*strarg) = DATOBJ ( MakeStr(p+1)); > if (gac_option) ONCE(*strarg); > return(*strarg); 256,257c260,265 < else < return (DATOBJ ( MakeStr (p))); --- > else { > strarg = (DATPTR)malloc (sizeof(DATPTR)); > (*strarg) = DATOBJ ( MakeStr(p)); > if (gac_option) ONCE(*strarg); > return(*strarg); > } .............................. END CHANGE ....................
jp@eiffel.UUCP (Jean-Pierre Sarkis) (03/18/90)
April's fool is coming early this year. There was one typo in the previous correction to the correction to the garbage collector problem. Below is the correct (we hope) fix. We apologize for the confusion. Flamers have their work cut out for them. -- Jean-Pierre Sarkis jp@eiffel.com Reply to: eiffel@eiffel.com Diff between new and old versions of: Installation_directory/Eiffel/files/_utility.c .............................. BEGIN CHANGE .................... 2a3 > #include "_gac.h" 67c68 < int *c_option (index) --- > DATUM c_option (index) 70,71c71,77 < if ((*arg_strings) && (arg_strings [index])) < return ( (int *) MakeStr (arg_strings [index])); --- > DATPTR strarg; > if ((*arg_strings) && (arg_strings [index])) { > strarg = (DATPTR)malloc (sizeof(DATPTR)); > (*strarg) = (DATUM) (MakeStr (arg_strings [index])); /*****/ > if (gac_option) ONCE(*strarg); > return(*strarg); > } 73c79 < return ((int) NULL); --- > return ((DATUM) NULL); .............................. END CHANGE .................... The typo was on the line marked /*****/. Everything else was correct.
paj@mrcu (Paul Johnson) (03/26/90)
> Does anyone out there actually USE the viewer for debugging ? > If not, how do they manage debugging. > Jos Warmer > jos@cs.vu.nl > ...uunet!mcvax!cs.vu.nl!jos I use the viewer, but it is not satisfactory. The lack of breakpoints is a pain, but the inclusion of assertions largely makes up for it: the assertions trap a problem before it goes too far, and rather than putting in traditional breakpoints to try to track a problem back to its cause, I usually put in a group of extra assertions instead. These do not then need to be taken out (unless they are VERY slow to evaluate) until the software is delivered. The viewers inability to get at local variables is a major pain. I often wind up making things features of the outer class when they should be local to a particular routine, simply so that the viewer can access them. Inability to move up and down the call stack is a related problem. Can this be fixed? I would also like to get specific traces (eg trace STRING.equal) a la dbx. Also the viewer sometimes starts up before the backtrace has finished. This is a pain. Paul. -- Paul Johnson UUCP: <world>!mcvax!ukc!gec-mrc!paj --------------------------------!-------------------------|------------------- GEC-Marconi Research is not | Telex: 995016 GECRES G | Tel: +44 245 73331 responsible for my opinions. | Inet: paj@uk.co.gec-mrc | Fax: +44 245 75244
jwg1@gte.com (James W. Gish) (03/28/90)
>In article <476@argus.mrcu> paj@mrcu (Paul Johnson) writes: > I use the viewer, but it is not satisfactory. The lack of breakpoints > is a pain, but the inclusion of assertions largely makes up for it: > the assertions trap a problem before it goes too far, and rather than > putting in traditional breakpoints to try to track a problem back to > its cause, I usually put in a group of extra assertions instead. > These do not then need to be taken out (unless they are VERY slow to > evaluate) until the software is delivered. > I also use the viewer, heavily in fact. However, I don't feel that the inclusion of assertions makes up for the lack of breakpoints. This assumes that you can anticipate and provide coverage for a high percentage of potential bugs. If you could anticipate all bugs, you wouldn't need a debugger. However, I agree that assertions help. Of course, the other use for a debugger is as an aid in program understanding, as a dynamic analyzer. In this situation, you don't want to have to add assertions; you really need breakpoints, tracepoints and more control over execution than the viewer provides. The viewer is useful, but a good debugger is what is really needed. -- Jim Gish GTE Laboratories, Inc., Waltham, MA CSNET: jgish@gte.com UUCP: ..!harvard!bunny!jwg1
jwg1@gte.com (James W. Gish) (03/28/90)
In article <JWG1.90Mar27170928@bunny.gte.com> I write: > I also use the viewer, heavily in fact. However, I don't feel that > the inclusion of assertions makes up for the lack of > breakpoints. This assumes that you can anticipate and provide > coverage for a high percentage of potential bugs. I forgot to mention, that it also assumes that your assertions are correct. And of course, that is not always correct. So, you still need a debugger. And this brings up another point: how do you debug your assertions? One approach would be to set a breakpoint before assertion evaluation! -- Jim Gish GTE Laboratories, Inc., Waltham, MA CSNET: jgish@gte.com UUCP: ..!harvard!bunny!jwg1