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

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

Hi Wolfgang,

Wolfgang Jansen wrote:
> Hi,
> 
> long time ago I offered to provide code for introspection and
> persistence closure to the GOBO library as well as a debugger
> for then GEC. Work took more time than expected but now an
> experimental version is available.
> 
> 
> 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.

> 5) The generated C code contains additional
> #defines, typedefs and global variables.
> They all have the prefix "GE_Z" or "GE_z".
> Of course, names and clusters may be changed.
> 
> 
> Changes of existing classes and C code:
> 
> The additional C code necessary for introspection
> and debugging (the persistence closure is a pure library
> and does not need additional C code) is generated
> in descendant classes of ET_C_GENERATOR which
> belong to cluster $GOBO/library/tools/eiffel/generation.
> There are just two changes in existing code:
> 
> 1) Class GEC, lines 199... and 234...:
> some local variables have been added and
>      create l_generator.make (l_system)
> is replaced by code that creates an object of the appropriate
> descendant class.
> 
> 2) Class ET_C_GENERATION:
> - No-operation routine "print_extension" has been added
> and is called near the end of routine "generate_c_code" (line 719).
> - Code flushing has been moved from line 13162 to line 894.
> - Line 1298 has been removed.
> 
> 3) Class ET_DYNAMIC_SYSTEM:
> - Second half of routine `compile_system' has been
> separated as routine `compile_more' (called from
> `compile_system' and new code).
> - Attributes `added_type' and `added_procedure'
> have been added (set by `compile_more').
> 
> 4) Classes ET_AGENT and ET_DYNAMIC_FEATURE
> have been made HASHABLE.
> 
> 5) $GOBO/gec/runtime/c/ge_exception.[hc]:
> A `typedef' has been added as well as code
> to jump to the debugger in case of an exception
> before unwinding the stack.
> 
> Other properties:
> 
> 1) The implementation of the new classes follows the command/query
> separation principle.
> 
> 2) Accessing of the additional generated C code is done
> by `external "C inline"' functions.
> The C code has almost everywhere one effective line only.
> But there may be more physical lines like:
> #ifdef SOME_CONSTANT
>  good_C_code
> #else
>  dummy_C_code
> #endif
> 
> 3) The implementation does not (not yet?) follow
> all GOBO's style guidelines.
> 
> 
> Some problems and open questions remain:
> 
> 1) I detected a few errors in the compiler or the
> generated C code. I will report them in a separate mail.
> 
> 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.

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

> 4) There is one inconvenience when installing the new stuff.
> Previously, installation of GEC consists of two compilations:
> first by use of ISE, SE or an old GEC, second, by the GEC
> just obtained. The inconvenience is that one more iteration
> is necessary: compile GEC once more by itself.
> Forthcoming installations do not need the extra compilation
> as long as the structure of store files is not changed.
> 
> 5) How can a user force the compiler to generate code for debugging?
> Currently I apply the SE style: if option "trace(yes)" is set in
> the ACE file then debugging code is generated (but no tracing code).
> Another solution may be in order.
> 
> 6) The most severe problem is how the debugger can be integrated
> into a system. The problem is as follows. The debugger is written
> in Eiffel (classes DG_DEBUGGER etc.) but the classes of the
> debuggee are not aware of that class and DG_DEBUGGER would not
> be compiled. The current solution is that after compiling the
> debuggee a seemingly second system of root class DG_DEBUGGER
> is compiled (therefore, the routine `compile_more')
> and all is put into *one* C code.
> The solution is rather tricky. How can this be managed better?
> 
> 
> 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.


> Best regards
> WJ
> 
> PS:
> - The attachment contains the user's guide of the debugger.

Thanks. I will read it.

> - GOBO version used: GOBO39, SVN 6656

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