Re: [gobo-eiffel-develop] GEC introspection & debugger

[Wolfgang J. <wj...@so...>]

Hi Eric,

Eric Bezault wrote:
> Hi Wolfgang,
>
> Wolfgang Jansen wrote:
>>
>>
>> The following naming convention has been applied:
>>
>> 1) Introspection classes have prefix "IN_" and are located
>> in cluster $GOBO/library/intro.
>
> As an Eiffelist, I try to avoid abbreviation. So I would prefer
> introspection rather than just intro.
>
>> 2) Persistence classes have prefix "PC_" and are located
>> in cluster $GOBO/library/persist
>
> Same remark, persistence instead of persist.
>
>> 3) Debugger classes have prefix "DG_" and are located
>> in cluster $GOBO/library/tools/eiffel/debugger
>>
>> 4) Special versions of introspection classes used
>> during compilation have prefix "ET_IN_" and are located
>> in cluster $GOBO/library/tools/eiffel/generation/intro
>
> introspection rather than intro.
Done.
>
>>
>> Some problems and open questions remain:
>>
>> 2) The compiler generates test for Void targets like
>>      return ((T1)(((T0*)(GE_void(a1)))->id==66));
>>      l6 = ((GE_void(l5), (T0*)0));
>> In most cases this is welcome but is counter-productive
>> in case of introspection, ... which generate references
>> from C pointers: the compiler is not aware of the objects
>> and often generates code where the references are
>> erroneously treated as `Void'.
>> For example, when restoring an object from file in independent
>> store mode its contents (i.e. whether attributes are void or not)
>> is beyond the scope of the actual system's compilation.
>> This means that objects and their attributes (recursively to any
>> depth) obtained from C pointers must be treated as potentially
>> void (i.e. generate Void-tests like the 1st example above)
>> but must also be treated as potentially not-void
>> (i.e. *not* code like the 2nd example).
>
> I don't think that the problem is with void checking. The
> problem is with the dynamic type set builder. It is not aware
> that entities can have some given types at runtime because
> they will be attached to objects retrieved from storable
> files. Here you see the problem with the void checking. But
> the problem will be similar with dynamic binding. The
> compiler might think that an entity will have only to
> possible types at runtime and will generate the code for
> the dynamic binding accordingly. But if, after retrieving
> objects from storable files that entity can have a third
> type at runtime, then the dynamic binding will be buggy.
Of course, the reason is the typesets, but the effect is the false void 
check.
Anyway, we need the possibility that the following code

   read_xyz(s: STORABLE): XYZ
      do
         Result ?= s.retrieve_by_name("file_name")
      end

does not return Void (as is currently the case) if the object in question
is actually of type XYZ. Currently, the only way is misleading
the compiler like:

   read_xyz(s: STORABLE): XYZ
      local
          xyz: XYZ
      do
         if xyz /= Void then
            -- The following code is never run but ensures
            -- that XYZ belongs to the typeset of `s'.
            create xyz
            s := xyz
         end
         Result ?= s.retrieve_by_name("file_name")
      end

(Well, class STORABLE is not yet implemented.
Imagine that it had been implemented by forwarding its tasks
to the classes handling the persistence closure.
Then the result would be Void in the first example).
>
>> 3) To display more informative debuggee status the compiler
>> should collect more information. For example, some compiler
>> related classes have queries like `keyword: ET_KEYWORD'
>> which potentially provide a keyword's position in class text.
>> Unfortunately, the position is not always set.
>
> In order for the position to be always available, you have
> to use ET_DECORATED_AST_FACTORY instead of ET_AST_FACTORY.
>
There seems to be a misunderstanding: I don't use both.
I extract the information needed from the result of normal compilation
(i.e. from `ET_C_GENERATOR.current_dynamic_system')
after parsing and analysis but before code generation.
At this point the ET_KEYWORDs are ready with or without position.
So, I am interested in filling the ET_KEYWORDs during
normal compilation.

>> So, if you are interested, how should the new stuff be integrated
>> into the GOBO project?
>> Simply by updating via SVN? By a new SNV path (probably better
>> since the new stuff still in experimental state)? Another way?
>
> Another way would be to move the Gobo repository to git.
> Jocelyn Fiat already uses git to work and maintain a void-safe
> version of Gobo. It would be easier I think if the master
> repository would be under git. I guess having to go back and
> forth between SVN and git is not very practical.
>
> If we make the decision to move to git, then what I'm not sure
> yet is whether we should host the git repository at SourceForge,
> or use github.com. What I like with github (I'm not sure whether
> this is available in other git hosts like SourceForge) is that
> from the Gobo master git repository we could see who is working
> on his own version of Gobo in github. My feeling is that it makes
> things easier to follow when we want to merge/integrate
> development into the main/master Gobo repository.
I am open for many solutions.

WJ

-- 
Dr. Wolfgang Jansen
University of Potsdam, Germany
Institute of Computer Science
Tel: +49 331 / 977 3047
mailto: wj...@so...