Eiffel Problems, Problems, Problems 
Author Message
 Eiffel Problems, Problems, Problems

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



Mon, 31 Aug 1992 06:47:55 GMT  
 Eiffel Problems, Problems, Problems
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 Warmer

                                 ...uunet!mcvax!cs.vu.nl!jos



Mon, 31 Aug 1992 16:52:16 GMT  
 Eiffel Problems, Problems, Problems

Quote:

>       Does anyone out there actually USE the viewer for debugging ?
>       If not, how do they manage debugging.

>                                 Jos Warmer


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



Tue, 01 Sep 1992 03:44:18 GMT  
 Eiffel Problems, Problems, Problems
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

(Reply address for this and any other customer support problem:

------------------------------------------------------------

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));
---

Quote:
>       DATPTR strarg;
>       if(n >= argc) return((DATUM)NULL);

238,240c238,241
<               strarg = DATOBJ ( MakeStr(p+1));
<               if (gac_option) ONCE(strarg);
<               return(strarg);
---
Quote:
>               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);
---
Quote:
>             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.



Tue, 01 Sep 1992 05:41:02 GMT  
 Eiffel Problems, Problems, Problems
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



.............................. BEGIN CHANGE ....................
220c220,221
<    if(n >= argc) return(DATINT(0));
---

Quote:
>    DATPTR strarg;
>    if(n >= argc) return((DATUM)NULL);

237c238,241
<            return(DATOBJ ( MakeStr(p+1)));
---
Quote:
>            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)));
---
Quote:
>             else {
>                strarg = (DATPTR)malloc (sizeof(DATPTR));
>                (*strarg) = DATOBJ ( MakeStr(p));
>                if (gac_option) ONCE(*strarg);
>                return(*strarg);
>             }

.............................. END   CHANGE ....................


Wed, 02 Sep 1992 07:10:38 GMT  
 Eiffel Problems, Problems, Problems
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



Diff between new and old versions of:
   Installation_directory/Eiffel/files/_utility.c

.............................. BEGIN CHANGE ....................
2a3

Quote:
> #include "_gac.h"

67c68
< int *c_option (index)
---
Quote:
> DATUM c_option (index)

70,71c71,77
<    if ((*arg_strings) && (arg_strings [index]))
<       return ( (int *) MakeStr (arg_strings [index]));
---
Quote:
>    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);
---
Quote:
>       return ((DATUM) NULL);

.............................. END   CHANGE ....................

The typo was on the line marked /*****/. Everything else was correct.



Thu, 03 Sep 1992 04:11:17 GMT  
 Eiffel Problems, Problems, Problems

Quote:
>       Does anyone out there actually USE the viewer for debugging ?
>       If not, how do they manage debugging.
>                                 Jos Warmer

>                             ...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



Fri, 11 Sep 1992 18:03:02 GMT  
 Eiffel Problems, Problems, Problems
Quote:

>    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 de{*filter*}.  However, I agree
that assertions help.

Of course, the other use for a de{*filter*} 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 de{*filter*} is what is really needed.
--
Jim Gish
GTE Laboratories, Inc., Waltham, MA



Sun, 13 Sep 1992 06:09:28 GMT  
 Eiffel Problems, Problems, Problems

Quote:
>    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 de{*filter*}.  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



Sun, 13 Sep 1992 23:39:01 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Problems, problems, problems

2. Finn Idiom problems and Re: {rho} problem

3. Combinatorial Problem [ & a new Combinatorial Problem ]

4. Database problem/Memory problem??

5. CW 2003 - Focus problem & a select problem

6. 32bit problem - one problem solved & another found

7. GForth problem or my problem?

8. REXX DLL problems solved (was Re: Problems getting C subcommand to work)

9. HTTP-Access2 problem (was Ruby Google problem)

10. Problem with this excercise problem.

11. RSX problems and texture problems

12. Problem with Problem 1

 

 
Powered by phpBB® Forum Software