|
From: Eric B. <er...@go...> - 2009-08-13 18:46:48
|
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
|