gobo-eiffel-develop

[gobo-eiffel-develop] GEC introspection & debugger

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

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.

2) Persistence classes have prefix "PC_" and are located
in cluster $GOBO/library/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

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

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.

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?

Best regards
WJ

PS:
- The attachment contains the user's guide of the debugger.
- GOBO version used: GOBO39, SVN 6656

-- 
Dr. Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...

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

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

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

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

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

Eric Bezault wrote:
> Wolfgang Jansen wrote:
>
>> 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.
I was already concerned with the problem of creating Eiffel objects in C.
I hoped that dynamic binding is not a problem:
if an XYZ object is accepted as such (i.e. no false void check)
then the dynamic dispatch on the object will work as if the object
had been created in Eiffel (i.e. calling the same T123x456 functions).
Isn't so? The objects created in C or read from a store file do not
introduce new inheritance relations. (If they were created before storing
by a system having different inheritance relations then these relations
are not part of the store file, and after retrieval the objects have
to be treated as objects of the retrieving system.)

> 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.
>
OK, so I will modify the parsing or analysis part of the compiler
(I tried to avoid those modifications to maintain compiler consistence).

On hour later: I changed the type of ET_TOKEN_CONSTANTS.default_ast_factory
from ET_AST_FACTORY to ET_DECORATED_AST_FACTORY
but the position of some ET_KEYWORDs is still zero
(I had a look only on the `rescue' keyword).
>
> I'm currently looking at the possibilities to host the Gobo
> repository under git.
>
I did not yet use git, I just read the manual.
It looks promising but I do not see the big step forward.

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

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

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

Wolfgang Jansen wrote:
> Eric Bezault wrote:
>> Wolfgang Jansen wrote:
>>
>>> 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.
> I was already concerned with the problem of creating Eiffel objects in C.
> I hoped that dynamic binding is not a problem:
> if an XYZ object is accepted as such (i.e. no false void check)
> then the dynamic dispatch on the object will work as if the object
> had been created in Eiffel (i.e. calling the same T123x456 functions).
> Isn't so? 

I don't think so. I think that when the dynamic type set of the
call contains only one or two types, T123x456 is not called.
If there is only one type, the feature corresponding to that
type is called directly. If there are two types, we test whether
the type id is one or the other to avoid spending time in
T123x456.

> The objects created in C or read from a store file do not
> introduce new inheritance relations. (If they were created before storing
> by a system having different inheritance relations then these relations
> are not part of the store file, and after retrieval the objects have
> to be treated as objects of the retrieving system.)
> 
>> 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.
>>
> OK, so I will modify the parsing or analysis part of the compiler
> (I tried to avoid those modifications to maintain compiler consistence).
> 
> On hour later: I changed the type of ET_TOKEN_CONSTANTS.default_ast_factory
> from ET_AST_FACTORY to ET_DECORATED_AST_FACTORY
> but the position of some ET_KEYWORDs is still zero
> (I had a look only on the `rescue' keyword).

I forgot to mention that you need to call:

    ET_DECORATED_AST_FACTORY.set_keep_all_breaks (True)

Also, you should not modify ET_TOKEN_CONSTANTS.default_ast_factory.
In class GEC, you should check whether you are compiling for the
debug mode or not. If so, you should call ET_SYSTEM.set_ast_factory
at the beginning of `process_system' with a locally created
ET_DECORATED_AST_FACTORY.

>> I'm currently looking at the possibilities to host the Gobo
>> repository under git.
>>
> I did not yet use git, I just read the manual.
> It looks promising but I do not see the big step forward.

The step forward is exactly what we are facing here. Because
git is a distributed SCM, people can work on their experimental
version of the code. Only when the code is ready and stable
can it be, along with its whole SCM history, integrated into
the main repository.

Note that I never used git yet either. So I'm not sure whether
this is the right way to go. But I have the feeling that it's
really what we want in order to let people work on their own
experimental version of the code and still get the full history
of their changes when their work is ready to be integrated.
I have the feeling that it is better than SVN's branches because
with SVN would have to create branches before really knowing
whether an experimental development will succeed or not. With
git only successful experimental developments will appear in the
main repository. That being said, the git tools on Windows
don't look very attractive. I guess they look more attractive
for Linux users under Linux.

Apart from the manual, there are some good videos about git.
Here is one of them:

    http://excess.org/article/2008/07/ogre-git-tutorial/

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

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

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

Eric Bezault wrote:
> Wolfgang Jansen wrote:
>> Eric Bezault wrote:
>>> Wolfgang Jansen wrote:
>>>
>> I was already concerned with the problem of creating Eiffel objects 
>> in C.
>> I hoped that dynamic binding is not a problem:
>> if an XYZ object is accepted as such (i.e. no false void check)
>> then the dynamic dispatch on the object will work as if the object
>> had been created in Eiffel (i.e. calling the same T123x456 functions).
>> Isn't so? 
>
> I don't think so. I think that when the dynamic type set of the
> call contains only one or two types, T123x456 is not called.
> If there is only one type, the feature corresponding to that
> type is called directly. If there are two types, we test whether
> the type id is one or the other to avoid spending time in
> T123x456.
I consider this as a (welcome!) code optimization.
Calling T123x456 in every case is probably not wrong
but may often be inefficient. So, what about calling
the dispatch routine in all cases where the typeset
could not be built, in particular if the object was created in C?
In these cases the inefficiency should be acceptable.

> I forgot to mention that you need to call:
>
>    ET_DECORATED_AST_FACTORY.set_keep_all_breaks (True)
>
> Also, you should not modify ET_TOKEN_CONSTANTS.default_ast_factory.
> In class GEC, you should check whether you are compiling for the
> debug mode or not. If so, you should call ET_SYSTEM.set_ast_factory
> at the beginning of `process_system' with a locally created
> ET_DECORATED_AST_FACTORY.
>
Thanks, this works!

>>> I'm currently looking at the possibilities to host the Gobo
>>> repository under git.
>>>
>> I did not yet use git, I just read the manual.
>> It looks promising but I do not see the big step forward.
>
> The step forward is exactly what we are facing here. Because
> git is a distributed SCM, people can work on their experimental
> version of the code. Only when the code is ready and stable
> can it be, along with its whole SCM history, integrated into
> the main repository.
>
> Note that I never used git yet either. So I'm not sure whether
> this is the right way to go. But I have the feeling that it's
> really what we want in order to let people work on their own
> experimental version of the code and still get the full history
> of their changes when their work is ready to be integrated.
> I have the feeling that it is better than SVN's branches because
> with SVN would have to create branches before really knowing
> whether an experimental development will succeed or not. With
> git only successful experimental developments will appear in the
> main repository. That being said, the git tools on Windows
> don't look very attractive. I guess they look more attractive
> for Linux users under Linux.
>
> Apart from the manual, there are some good videos about git.
> Here is one of them:
>
>    http://excess.org/article/2008/07/ogre-git-tutorial/
>
Thanks to you and all others who sent hints on GIT.
Now, I fetched the point and I would like to move
my GOBO stuff to GIT.

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