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

[Eric B. <er...@go...>]

Wolfgang Jansen wrote:
>>> 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.

I understand that. What I'm saying is that the false void check
is just the top of the iceberg. It is a particular case of a
more general issue that will also occur with dynamic binding,
even though you only saw it with void checking so far. This is
a known issue with the dynamic type set builder that also occurs
with 'external "C"' functions when the returned object has been
created in C. What I was trying to say is that the solution is
not to try to fix the Void checking, but the more general
problem with the dynamic type set builder. Otherwise there will
still be problems with the dynamic binding, even though you
didn't see it yet.

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

There was no misunderstanding. The "normal" compilation uses
ET_AST_FACTORY. It should be told to use ET_DECORATED_AST_FACTORY
when you want to use it as part of a debugging 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.

I'm currently looking at the possibilities to host the Gobo
repository under git.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com