gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Git development

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

Jocelyn wrote:
> In a previous post, Eric said the git tools for Windows were not very
> attractive.
> And I agree they are not yet at the same level as TortoiseSVN.
> 
> However, personally I am using on Windows
>     - msysGit  http://code.google.com/p/msysgit/downloads/list
>     - for the gui ... either git gui, or gitk which come with any git setup
>        but most often, I use Git Extensions
> (http://sourceforge.net/projects/gitextensions/) which is good enough
> for my need.
>     - I tried to use TortoiseGIT (http://code.google.com/p/tortoisegit/)
> but I was unable to make it work on my Win XP Pro 64bits (too bad, since
> I am a TortoiseSVN user, and I really like it)

I tried TortoiseGIT (on Win XP Pro 32bits), and although not as
full-fledged as TortoiseSVN, it works for me. I use it in combination
with git gui, gitk and msysGit.

I have currently disabled the write access to the SVN repository of
Gobo while I'm converting it to Git. The more I play with it, the
more I like the decentralized property of Git. I think that it makes
it easier for people to contribute to projects. They can experiement
on their own copy of the repository, and when they have something
interesting to share, their whole file history can be merged into
the official repository. Using decentralized SCM implies a new way
of working, but I like it. I already see how I can take advantage of
it for my own development.

I'm also considering splitting the Gobo repository into smaller
repositories, one per library and tool. That way people would not
have to download everything if they are only interested in one or
two libraries. The whole Gobo delivery would still gather everything
using Git submodules (the equivalent of svn:external). But I will
keep one big repository as a first step.

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

Re: [gobo-eiffel-develop] Patch for XML pretty printer

[Colin A. <col...@go...>]

2009/9/3 Jann Röder <roe...@et...>:

>
> PS: Can anyone comment on the XML declaration issue?
>


I discussed it with Franck yesterday.
The issue is with the encoding. I was claiming that as he is writing
STRINGs, then the XML declaration is required, because the encoding
will be iso8859-1, but he said the actual serialization depends upon
what XM_OUTPUT does down the line. Therefore the problem is difficult.

The best way is not to use this pretty printer for serializing XML -
really it's only a debug tool. The XSLT serializer should be used for
serializing output (note this does not mean you have to run XSLT).
-- 
Colin Adams
Preston,
Lancashire,
ENGLAND

Re: [gobo-eiffel-develop] Patch for XML pretty printer

[Jann R. <roe...@et...>]

Ok,
I updated my patch with better feature names and comments and I made the 
use of "empty element tags" optional, disabled by default.

Jann

PS: Can anyone comment on the XML declaration issue?

Eric Bezault schrieb:
> Jocelyn wrote:
>> I haven't looked at the patch, but it might be easy to support both behavior
>> with short tag <foo/>  and <foo></foo> using a boolean attribute, or 
>> flag for the executable.
>>
>> This way, this won't break existing programs
> 
> Either that, or write a descendant of the pretty-printer class
> and let dynamic binding use one or the other form.
> 

Re: [gobo-eiffel-develop] Patch for XML pretty printer

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

Jocelyn wrote:
> I haven't looked at the patch, but it might be easy to support both behavior
> with short tag <foo/>  and <foo></foo> using a boolean attribute, or 
> flag for the executable.
> 
> This way, this won't break existing programs

Either that, or write a descendant of the pretty-printer class
and let dynamic binding use one or the other form.

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

Re: [gobo-eiffel-develop] Patch for XML pretty printer

[Jocelyn <ei...@dj...>]

I haven't looked at the patch, but it might be easy to support both behavior
with short tag <foo/>  and <foo></foo> using a boolean attribute, or 
flag for the executable.

This way, this won't break existing programs


Colin Adams wrote:
> I would say this might break existing programs (if anyone is using
> this to write legacy xhtml, for instance, for sending to old
> browsers). Perhaps consult on gobo-users list first?
>
> 2009/9/3 Jann Röder <roe...@et...>:
>   
>> Hi,
>> I wrote a patch for the XML pretty printer to make it use the short form for
>> tags that don't have content or children, i.e. <tag/> instead of <tag></tag>
>> .
>> See attachment.
>>
>> I also noticed, that the pretty printer does not output the XML descriptor
>> (this: <?xml version="1.0" ?>). I'm not sure what's the best way to fix
>> this. Simply adding code in the on_xml_descriptor feature doesn't work
>> because it is never called, or I don't know what to do to have it called.
>>
>> Anyway in the meantime I'd be glad about some feedback regarding my patch.
>>
>> Jann
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> gobo-eiffel-develop mailing list
>> gob...@li...
>> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>>
>>
>>     
>
>
>
>   

Re: [gobo-eiffel-develop] Patch for XML pretty printer

[Colin A. <col...@go...>]

I would say this might break existing programs (if anyone is using
this to write legacy xhtml, for instance, for sending to old
browsers). Perhaps consult on gobo-users list first?

2009/9/3 Jann Röder <roe...@et...>:
> Hi,
> I wrote a patch for the XML pretty printer to make it use the short form for
> tags that don't have content or children, i.e. <tag/> instead of <tag></tag>
> .
> See attachment.
>
> I also noticed, that the pretty printer does not output the XML descriptor
> (this: <?xml version="1.0" ?>). I'm not sure what's the best way to fix
> this. Simply adding code in the on_xml_descriptor feature doesn't work
> because it is never called, or I don't know what to do to have it called.
>
> Anyway in the meantime I'd be glad about some feedback regarding my patch.
>
> Jann
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>
>



-- 
Colin Adams
Preston,
Lancashire,
ENGLAND

Re: [gobo-eiffel-develop] Patch for XML pretty printer

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

Hi Jann,

Jann Röder wrote:
> I wrote a patch for the XML pretty printer to make it use the short form 
> for tags that don't have content or children, i.e. <tag/> instead of 
> <tag></tag> .
> See attachment.
> 
> I also noticed, that the pretty printer does not output the XML 
> descriptor (this: <?xml version="1.0" ?>). I'm not sure what's the best 
> way to fix this. Simply adding code in the on_xml_descriptor feature 
> doesn't work because it is never called, or I don't know what to do to 
> have it called.
> 
> Anyway in the meantime I'd be glad about some feedback regarding my patch.

It may take a few days before your patch makes it way in the
repository because I'm currently converting the repository to
Git.

I'll let XML experts give feedback on your patch if they have something
to say. But in the meantime, can you please add header comments to the
features `last_call_was_start_tag_finish' and `close_tag_buffered'?
Thanks.

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

[gobo-eiffel-develop] Patch for XML pretty printer

[Jann R. <roe...@et...>]

Hi,
I wrote a patch for the XML pretty printer to make it use the short form 
for tags that don't have content or children, i.e. <tag/> instead of 
<tag></tag> .
See attachment.

I also noticed, that the pretty printer does not output the XML 
descriptor (this: <?xml version="1.0" ?>). I'm not sure what's the best 
way to fix this. Simply adding code in the on_xml_descriptor feature 
doesn't work because it is never called, or I don't know what to do to 
have it called.

Anyway in the meantime I'd be glad about some feedback regarding my patch.

Jann

Re: [gobo-eiffel-develop] XML generator

[Jann R. <roe...@et...>]

Colin Paul Adams schrieb:
>>>>>> "Jann" == Jann Röder <roe...@et...> writes:
> 
>     Jann> For example I'd like it not to add the prefix to
>     Jann> every tag and attribute.
> 
>     Jann> <tag id="2"> instead of <prefix:tag prefix:id="2">
> 
> The two are not equivalent, as attributes are never in the default
> namespace. Instead they are in the per-element namespace. I.e. in the
> first case, id is in a different namespace from tag (assuming you have
> a default namespace declaration in scope). In the second case, they
> are both in the same namespace.

Ok got it. I just put everything in the same namespace, since the 
namespace argument must not be Void. Now I put everything except the 
root node in the default namespace and the prefixes disappeared. It 
would be nice if you could pass Void as the namespace argument if you 
want to put the element into the default namespace.

Jann

Re: [gobo-eiffel-develop] XML generator

[Colin P. A. <co...@co...>]

>>>>> "Jann" == Jann Röder <roe...@et...> writes:

    Jann> For example I'd like it not to add the prefix to
    Jann> every tag and attribute.

    Jann> <tag id="2"> instead of <prefix:tag prefix:id="2">

The two are not equivalent, as attributes are never in the default
namespace. Instead they are in the per-element namespace. I.e. in the
first case, id is in a different namespace from tag (assuming you have
a default namespace declaration in scope). In the second case, they
are both in the same namespace.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] XML generator

[Colin P. A. <co...@co...>]

>>>>> "Jann" == Jann Röder <roe...@et...> writes:

    Jann> Hello, I have two problems with the gobo XML library:
    Jann> 1. {XM_NAMESPACE}.make seems to miss the precondition
    Jann> a_prefix /= Void , or there is a bug in
    Jann> {XM_XMLNS_GENERATOR}.on_attribute line "elseif is_implicit
    Jann> (a_prefix)" since if a_prefix is Void a Void call will occur
    Jann> in is_implicit

I'll leave that for Franck to answer.

    Jann> 2. How can I influence the output generated by the pretty
    Jann> printer? For example I'd like it not to add the prefix to
    Jann> every tag and attribute.

    Jann> <tag id="2"> instead of <prefix:tag prefix:id="2">

    Jann> Also I'd like it to use the short form for tags when
    Jann> possible:

    Jann> <tag id="2"/> instead of <tag id="2"></tag>

    Jann> Is this possible somehow or will I have to write my own
    Jann> pretty printer?

There is an XSLT-inspired (*) serializer that you can use if you want full
control over the output. See
http://www.gobosoft.com/eiffel/gobo/xml/xslt/xslt_serializer.html .

It's actually the serializer used by the Gobo XSLT library, but you do
not need to run an XSLT transformation to use it.
-- 
Colin Adams
Preston Lancashire

[gobo-eiffel-develop] XML generator

[Jann R. <roe...@et...>]

Hello,
I have two problems with the gobo XML library:
1. {XM_NAMESPACE}.make seems to miss the precondition a_prefix /= Void , 
or there is a bug in {XM_XMLNS_GENERATOR}.on_attribute line "elseif 
is_implicit (a_prefix)" since if a_prefix is Void a Void call will occur 
in is_implicit

2. How can I influence the output generated by the pretty printer? For 
example I'd like it not to add the prefix to every tag and  attribute.

<tag id="2"> instead of <prefix:tag prefix:id="2">

Also I'd like it to use the short form for tags when possible:

<tag id="2"/> instead of <tag id="2"></tag>

Is this possible somehow or will I have to write my own pretty printer?

Thanks,
Jann

Re: [gobo-eiffel-develop] Git development

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

Hi Howard,

> Hi Wolfgang,
>
> On Saturday 15 August 2009, you wrote:
>
> > May it help you to re-use my introspection code?
>
> > It sees all references on stack, all global references (i.e. values of
>
> > once functions)
>
> > and, starting on these references, all references on heap.
>
> Yes, it would be useful [necessary ...] to ensure that there is one 
> way to make
>
> available, to both the GC and debugger, all relevant info.
>
> The specific code generation case that I was referring to is where C 
> code is generated
>
> with two or more arguments to a routine [excluding Current], each of 
> which is a memory-allocating
>
> funtion that returns a reference [where the return value is the only 
> extant reference], and therefore
>
> the GC needs to have access to a value that is not a declared C variable.
>
> In C terms:
>
> void * f_allocate() {
>
> /* This routine allocates memory [create ...] and may instigate a GC 
> collection */
>
> return(GC_alloc_memory(...));
>
> }
>
> void called_routine(void *a_Current, void *a1, void *a2) {
>
> /* do something [not relevant] with arguments */
>
> xxx = a1;
>
> yyy = a2;
>
> }
>
> If the routine call:
>
> called_routine(Current, f_allocate(), f_allocate());
>
> occurs in the generated C code then the GC, if invoked from the 
> f_allocate call that occurs second, then
>
> the one and only reference to the memory returned by the first 
> f_allocate call is only accessible via a
>
> C compiler unnamed temporary.
>
> Does your stack tracing code track, precisely, i.e. not 
> conservatively, such compiler temporaries ?
>
No yet. Printing arguments and local variables does not need this
and checkpointing not either since the call to the debugger 
happens, currently, always before an instruction, in particular
before the temporaries are set to new values. In other words, in case of

   x := f(g(y))

there is one break at the beginning of the line but not before
the calls to functions `f' and `g'.
Things will be different if the debugger is called also before
function calls (planned in future). The function arguments are often
temporaries and need to be stored by checkpointing
(or checkpointing must be allowed in front of instructions only).

Anyway, I will think about the problem how to extract the information
about temporaries from the compiler classes (putting the information
to introspection classes and making it available during runtime is easy).
>
> Do you develop on Windows or Linux ?
>
On Sun Solaris, a Unix variant.
>
> If you want to look at [an earlier version of] my code, it is 
> available at:
>
> www.ashford-ht.vm.bytemark.co.uk as a compressed tar download, 
> admittedly more suitable for Linux developers ...
>
>
Thanks, I got the sources and the Linux version.

WJ

PS:
Below is the (slightly simplified) initial part of C code of STRING_8.append
as generated for debugging.

     1    void T17f42(GE_ZS* ac, T0* C, T0* a1)
     2    {
     3        GE_ZS tc = {0,0,ac};
     4        T1 t1;
     5        T6 t2;
     6        T0* t3;
     7        T6 l1 = 0;
     8        T6 l2 = 0;
     9        T6 l3 = 0;
    10        static T0* f = (T0*)0;
    11        if (!f) {
    12            T82f77(&tc, (T0*)GE_zrts, 17, 1)
    13            T82f99(&tc, (T0*)GE_zrts, f, (size_t)&C-(size_t)&tc, 0)
    14            T82f99(&tc, (T0*)GE_zrts, f, (size_t)&a1-(size_t)&tc, 1)
    15            T82f99(&tc, (T0*)GE_zrts, f, (size_t)&l3-(size_t)&tc, 3)
    16            T82f99(&tc, (T0*)GE_zrts, f, (size_t)&l2-(size_t)&tc, 4)
    17            T82f99(&tc, (T0*)GE_zrts, f, (size_t)&l1-(size_t)&tc, 5)
    18        }
    19        tc.routine = f;
    20        GE_zpos(&tc, 655, 0);
    21        l2 = (((T17*)(GE_void(a1)))->a2);
    22        ....
    23    }

Line 1 : `ac' is the stack descriptor of the caller;
  type GE_ZS is a C struct, not Eiffel
Line 3 : `tc' is the stack descriptor of the current routine
  (`ac', `tc' are re-used from GOBO's code tracing)
Line 10:  `f' is a pointer to an IN_ROUTINE object
Line 12: `f' is set by the object describing the current routine;
  GE_zrts is the root introspection object (global variable)
Line 13 .. 17: offsets of the local variables relative to `tc' are set 
in `f';
   more lines are needed if temporary variables are of interest.
Line 19: set `f' in stack descriptor
Line 20: call debugger with stack descriptor, source line number 655
  and reason of break
 
Other uses of routine descriptors (say by GC) will need the additional code
of lines 1, 3, 10, 12, 13 .. 17 (as many as needed), 19.
After that `tc' is ready and detailed information may be extracted
(as done by the debugger in line 20).

Instead of the additional argument `ac' a global pointer
to the top most stack descriptor might be used.

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

Re: [gobo-eiffel-develop] Git development

[Howard T. <how...@di...>]

Hi Wolfgang,

On Saturday 15 August 2009, you wrote:

> May it help you to re-use my introspection code?
> It sees all references on stack, all global references (i.e. values of 
> once functions)
> and, starting on these references, all references on heap.

Yes, it would be useful [necessary ...] to ensure that there is one way to make
available, to both the GC and debugger, all relevant info.

The specific code generation case that I was referring to is where C code is generated
with two or more arguments to a routine [excluding Current], each of which is a memory-allocating
funtion that returns a reference [where the return value is the only extant reference], and therefore
the GC needs to have access to a value that is not a declared C variable.

In C terms:

void * f_allocate() {
	/* This routine allocates memory [create ...] and may instigate a GC collection */
	return(GC_alloc_memory(...));
}

void called_routine(void *a_Current, void *a1, void *a2) {
	/* do something [not relevant] with arguments */
	xxx = a1;
	yyy = a2;
}

If the routine call:

	called_routine(Current, f_allocate(), f_allocate());

occurs in the generated C code then the GC, if invoked from the f_allocate call that occurs second, then
the one and only reference to the memory returned by the first f_allocate call is only accessible via a
C compiler unnamed temporary.

Does your stack tracing code track, precisely, i.e. not conservatively, such compiler temporaries ?

Do you develop on Windows or Linux ?

If you want to look at [an earlier version of] my code, it is available at:
www.ashford-ht.vm.bytemark.co.uk as a compressed tar download, admittedly more suitable for Linux developers ...

Regards,

Howard

> The debugger uses this for checkpointing.
> A critical point in the GC case may be to make the things on stack
> visible. In case of the debugger, making stack variables visible
> is necessary for printing the variables, using their visibility
> for checkpointing is a by-product. But additional code is needed
> (run at most once per routine) to get the addresses. The additional code
> may be considered too heavy for every days work.
> 


-- 
Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein 

Re: [gobo-eiffel-develop] Git development

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

Howard Thomson wrote:
>
> Hi Wolfgang,
>
> On Friday 14 August 2009, you wrote:
>
> >
>
> > The approach to implement the persistence closure etc.
>
> > may be emphasized as follows:
>
> > The Eiffel compiler is written in Eiffel.
>
> > So, why not also implementing the Eiffel runtime system in Eiffel?
>
> >
>
> I considered writing the Eiffel GC substantially in Eiffel, and I may 
> well transliterate much
>
> of the new GC code into Eiffel at some point, once we have [or I 
> understand ... !] some means
>
> of either separately generating library code [with Gobo], or some 
> means of ensuring that all
>
> of the GC classes are 'in' the system; actually not too difficult ...
>
> I think Gobo's ability to inline code needs to be enhanced before it 
> makes sense to do that.
>
May it help you to re-use my introspection code?
It sees all references on stack, all global references (i.e. values of 
once functions)
and, starting on these references, all references on heap.
The debugger uses this for checkpointing.
A critical point in the GC case may be to make the things on stack
visible. In case of the debugger, making stack variables visible
is necessary for printing the variables, using their visibility
for checkpointing is a by-product. But additional code is needed
(run at most once per routine) to get the addresses. The additional code
may be considered too heavy for every days work.

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

Re: [gobo-eiffel-develop] Git development

[Howard T. <how...@di...>]

Hi Wolfgang,

On Friday 14 August 2009, you wrote:
> 
> The approach to implement the persistence closure etc.
> may be emphasized as follows:
> The Eiffel compiler is written in Eiffel.
> So, why not also implementing the Eiffel runtime system in Eiffel?  
>

I considered writing the Eiffel GC substantially in Eiffel, and I may well transliterate much
of the new GC code into Eiffel at some point, once we have [or I understand ... !] some means
of either separately generating library code [with Gobo], or some means of ensuring that all
of the GC classes are 'in' the system; actually not too difficult ...

I think Gobo's ability to inline code needs to be enhanced before it makes sense to do that.

> BTW, does your GC mark/seep or move/compress? In the former case,
> object marking may also be interesting when building the persistence 
> closure.
> Currently, the already seen objects are registered
> in a DS_HASH_TABLE[INTEGER,POINTER]. This is inconvenient
> because of the POINTER keys. Marking like the GC would be an
> interesting alternative.

It is currently a simple mark/sweep, non-moving, but precise collector, so
the ability to move / compact could be added later. Correctness is much
more important, and there are still some code generation changes that
need to be made to ensure that all references are visible to the GC at
any point where it may be invoked.

> 
> > One of the areas of the code generator that I intend to alter is the 
> > polymorphic
> >
> > dispatch implementation, for two reasons:
> >
> > Firstly for rapid re-compilation, I want to be able to generate an 
> > initial code package as
> >
> > an executable stub with dynamic library, where libraries register 
> > their routine addresses
> >
> > with the runtime, with subsequent partial re-compilation code 
> > generated as an additional
> >
> > dynamic library whose routines override the registered routines of the 
> > initial library. This
> >
> > requires that routine dispatch be done using a tree data structure, of 
> > some sort ...
> >
> > Secondly, I envisage that it should be possible, as with Java and 
> > other languages [mostly interpreted ..],
> >
> > to dynamically add class libraries to an executable system, where such 
> > libraries have been packaged,
> >
> > [compiled or otherwise verified against] to be compatible with classes 
> > already in the current system.
> >
> > That would also require that the dispatch to reachable routines be 
> > dynamically extendable.
> >
> This sounds very interesting. Extendibility of a program, dynamic 
> linking etc. seems to be
> necessary for contemporary software (otherwise, Eiffel will never have a 
> chance).
> >

I think it is essential ...


Regards

Howard

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein 

Re: [gobo-eiffel-develop] Git development

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

Hi Howard,

Howard Thomson wrote:
>
> Hi Eric & Wolfgang,
>
> I would welcome a move to using Git as the SCM system for Gobo.
>
> I see that there is a useful page on wikipedia about git, with 
> reference to Windows implementations:
>
> http://en.wikipedia.org/wiki/Git_(software)#Implementation
>
> There is also an excellent website detailing how to use git ...
>
> http://progit.org/
>
> Regarding my own project:
>
> I have recently, I think [famous last words], reached stability with my
>
> GC when compiling with my modified 'gec', albeit that I have only so
>
> far tested it on Linux. A Win32 version should be a fairly trivial 
> adaptation,
>
> as it should be no more than adaptation of a single, smallish, routine.
>
> I am also thinking of renaming my project as 'guide',
>
> the Gobo-eiffel Users' Integrated Development Environment,
>
> from 'edp', the Eiffel Developers' Project. Although there a few
>
> classes [from other sources] that are LGPL, nearly all code that does
>
> not already derive from gobo, is EFFLv2 or MIT.
>
> I am very interested to hear about the introspection and debugger code, as
>
> I need such facilities for my intended future coding.
>
Description of introspection and debugger code may be really large.
Here, a short outline.
Descendant classes of ET_C_GENERATOR (extending the work of that class)
generate a description of the system to be compiled for use during runtime:
they extract information from objects of types
ET_DYNAMIC_SYSTEM, ET_DYNAMIC_TYPE etc. and puts
the information into objects of types ET_IN_SYSTEM, ET_IN_TYPE etc.
The resulting description is put onto C code (additional to the usual code)
using a special output mode of the persistence closure classes.
This code is C compiled, and the system description is available
during runtime (after a few adaptations at startup) as Eiffel objects.
More precisely, the root object of the description is provided by an 
external
routine that fetches the object's address from C code, the other objects
are then recursively available by Eiffel calls on the root object.
The attachment contains the interface of an example class
to show what kind of information is available during runtime.

Introspection for persistence closure and debugging differs in the amount
of information in the system description. For example, the debugger needs
information about routines but the persistence closure does not.
Moreover, in case of debugging many calls to the debugger have been 
inserted
into the "normal" code. The debugger then decides whether switching
into interactive mode (say a breakpoint has been reached)
or returning immediately to the caller.

Historically, the work started with the persistence closure.
I soon realized the introspection is a necessary prerequisite.
Then, having introspection, the idea was to utilize it also
for other purposes, e.g. for the "print" command of a debugger.
So, the debugger has been developed.

The approach to implement the persistence closure etc.
may be emphasized as follows:
The Eiffel compiler is written in Eiffel.
So, why not also implementing the Eiffel runtime system in Eiffel?  

BTW, does your GC mark/seep or move/compress? In the former case,
object marking may also be interesting when building the persistence 
closure.
Currently, the already seen objects are registered
in a DS_HASH_TABLE[INTEGER,POINTER]. This is inconvenient
because of the POINTER keys. Marking like the GC would be an
interesting alternative.

> One of the areas of the code generator that I intend to alter is the 
> polymorphic
>
> dispatch implementation, for two reasons:
>
> Firstly for rapid re-compilation, I want to be able to generate an 
> initial code package as
>
> an executable stub with dynamic library, where libraries register 
> their routine addresses
>
> with the runtime, with subsequent partial re-compilation code 
> generated as an additional
>
> dynamic library whose routines override the registered routines of the 
> initial library. This
>
> requires that routine dispatch be done using a tree data structure, of 
> some sort ...
>
> Secondly, I envisage that it should be possible, as with Java and 
> other languages [mostly interpreted ..],
>
> to dynamically add class libraries to an executable system, where such 
> libraries have been packaged,
>
> [compiled or otherwise verified against] to be compatible with classes 
> already in the current system.
>
> That would also require that the dispatch to reachable routines be 
> dynamically extendable.
>
This sounds very interesting. Extendibility of a program, dynamic 
linking etc. seems to be
necessary for contemporary software (otherwise, Eiffel will never have a 
chance).
>
> I am adapting my work on the Eiffel GUI toolkit derived from the 
> Fox-toolkit to use the Vision2 interface,
>
> providing an X11/Win32 all Eiffel GUI Toolkit, which has its 
> advantages ...
>
> I am working toward using LLVM as the basis for code generation for 
> native Eiffel routines, initially to emit
>
> LLVM assembler with llvm-as invocation, and with the possibility 
> [much] later of emitting machine code directly.
>
> I think using Git would assist in cooperation between myself and other 
> gobo-eiffel contributors and developers.
>
> Regards,
>
> Howard Thomson
>
> --
>
> "Only two things are infinite, the universe and human stupidity,
>
> and I'm not sure about the former." -- Albert Einstein
>


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

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

Re: [gobo-eiffel-develop] Git development

[Jocelyn <ei...@dj...>]

This message is a side note about what Eric said about me, Jocelyn,
using git for void-safe version of Gobo.
This message has nothing to do with Gobo, and is focused on special
usage of git and subversion.

So yes, I am using git for void-safe version of Gobo
(http://github.com/jocelyn/void-safe-gobo-eiffel/tree/master), but my
use of git for this is unusual.

I use it to have a double SCM control on gobo's and ise's classes
related to Gobo.
To be short, I use git AND svn on the same files to be able to local
commit on the git repository (hosted on github), and also being able to
diff using svn diff on the ise and gobo's svn repository.

Indeed, when you svn checkout
https://svn.eiffel.com/eiffelstudio/trunk/Src/library/gobo
you end up with
gobo/many files
gobo/override
gobo/src
gobo/svn

and gobo/* are parts of eiffelstudio's svn repository
while gobo/svn/* are part of the gobo's svn repository  (we use
svn:externals for that purpose).

And my git repository covers gobo/* AND gobo/svn/* files
This can be seens as a little trick, but it is really nice to have local
commits, and still be able to diff easily with gobo's subversion repository.

However, this is possible, but this is not that convenient when there
are big commits on the gobo's trunk. Since there are many conflict to
resolve in order to keep synchronized with gobo's trunk@HEAD

(probably, I could have used git svn, and git sub modules, but at that
time, I was using git for the very first time)

-- Jocelyn

Jocelyn wrote:
> In a previous post, Eric said the git tools for Windows were not very
> attractive.
> And I agree they are not yet at the same level as TortoiseSVN.
>
> However, personally I am using on Windows
>     - msysGit  http://code.google.com/p/msysgit/downloads/list
>     - for the gui ... either git gui, or gitk which come with any git setup
>        but most often, I use Git Extensions
> (http://sourceforge.net/projects/gitextensions/) which is good enough
> for my need.
>     - I tried to use TortoiseGIT (http://code.google.com/p/tortoisegit/)
> but I was unable to make it work on my Win XP Pro 64bits (too bad, since
> I am a TortoiseSVN user, and I really like it)
>
> For my usage, the Git Extensions GUI is good enough, and when I need to
> do complicated operation (or even simple) I use (very often) git in
> command line (as I do with svn)
> Indeed git is much more powerful than svn, but it is also more
> complicated (in addition the command name are not always very
> intuitive), thus I find it often easier to use command line to do
> exactly what I want.
> Also the branching is great, but you have to get used to it, otherwise
> you waste time figuring out how to best deal with it (in final, I learnt
> that the best solution is to ALWAYS work on its own branch, and merge
> with the master/trunk when ready to commit)
>
> And at the end, I agree that git on Windows is much slower than git on
> linux (especially git svn), but it is ok
>
> There are other alternative to git, such as mercurial, but I don't
> really know them. It seems like git is the most popular (due to linux
> repo I guess).
> I heard there is a native client for Windows in development, but I don't
> know where to find it ...
>
> Maybe before going for git, Gobo's dev could use git-svn as following
>     >    mkdir gobo.git
>     >    cd gobo.git
> Initialize your local repository based on the gobo's subversion  repo
>     >    git svn init
> https://gobo-eiffel.svn.sourceforge.net/svnroot/gobo-eiffel/gobo/trunk
> fetch the commits from revision 6555  (for instance this one which is
> the gobo 3.9 release)
> note, you can also git clone the entire gobo's repository .. but it is
> longer
>     >    git fetch -r6555
> now, get sync with trunk@HEAD
>     >    git svn rebase
>
> If you want, to do some modification, I would recommend to work on your
> own branch  (I use my login for that "jfiat")
>     >   git checkout -b jfiat
>
> Then you can work on your own branch ... as with any git repo, so check
> the git tutorials to know how to use git. This includes locally commits
> (that's such a great feature, I wish subversion implement it some day).
>
> And when ever you are ready to commit and "push" to the official gobo's
> svn repository, you switch back to the master (which represent the trunk
> in subversion)
>     >    git checkout master
> Eventually sync with head with:  git svn rebase
>
> Merge the changes from your branch
>     >    git merge --squash jfiat
> The --squash is used to merge your branch to the master .. BUT without
> doing any commit, then you can commit your change in only one commit.
> I tried without the "--squash", and it re-creates all the commits done
> in my branch into the master. This could be useful, if you want to
> "replay" your work in the master for history...
>
> You can then commit your change
>     >    git commit -a -m "Merge jfiat's branch into the master branch
> to implement feature X"
>
> And finally, you push/send your changes to the svn repo
>     >   git svn dcommit
>
> Check the following links for use cases:
>     - http://techbase.kde.org/Development/Tutorials/Git
>     - http://live.gnome.org/GitForGnomeDevelopers
>
> So this way to do, can be a temporary solution to use git with Gobo.
> Then decide with gobo's developers, if git is the right tool for gobo's
> repo.
>
> (Note that using git with real git repositories, is easier and more fun,
> but .. git-svn is a solution to try, and even work)
>
> -- Jocelyn
>
> Howard Thomson wrote:
>
>   
>>> Hi Eric & Wolfgang,
>>>
>>> I would welcome a move to using Git as the SCM system for Gobo.
>>>
>>> I see that there is a useful page on wikipedia about git, with
>>> reference to Windows implementations:
>>>
>>> http://en.wikipedia.org/wiki/Git_(software)#Implementation
>>>
>>> There is also an excellent website detailing how to use git ...
>>>
>>> http://progit.org/
>>>
>>> <snip>....</snip>
>>>
>>> I think using Git would assist in cooperation between myself and other
>>> gobo-eiffel contributors and developers.
>>>
>>> Regards,
>>>
>>> Howard Thomson
>>>
>>>       
>>   
>>     
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>
>
>   

Re: [gobo-eiffel-develop] Git development

[Jocelyn <ei...@dj...>]

In a previous post, Eric said the git tools for Windows were not very
attractive.
And I agree they are not yet at the same level as TortoiseSVN.

However, personally I am using on Windows
    - msysGit  http://code.google.com/p/msysgit/downloads/list
    - for the gui ... either git gui, or gitk which come with any git setup
       but most often, I use Git Extensions
(http://sourceforge.net/projects/gitextensions/) which is good enough
for my need.
    - I tried to use TortoiseGIT (http://code.google.com/p/tortoisegit/)
but I was unable to make it work on my Win XP Pro 64bits (too bad, since
I am a TortoiseSVN user, and I really like it)

For my usage, the Git Extensions GUI is good enough, and when I need to
do complicated operation (or even simple) I use (very often) git in
command line (as I do with svn)
Indeed git is much more powerful than svn, but it is also more
complicated (in addition the command name are not always very
intuitive), thus I find it often easier to use command line to do
exactly what I want.
Also the branching is great, but you have to get used to it, otherwise
you waste time figuring out how to best deal with it (in final, I learnt
that the best solution is to ALWAYS work on its own branch, and merge
with the master/trunk when ready to commit)

And at the end, I agree that git on Windows is much slower than git on
linux (especially git svn), but it is ok

There are other alternative to git, such as mercurial, but I don't
really know them. It seems like git is the most popular (due to linux
repo I guess).
I heard there is a native client for Windows in development, but I don't
know where to find it ...

Maybe before going for git, Gobo's dev could use git-svn as following
    >    mkdir gobo.git
    >    cd gobo.git
Initialize your local repository based on the gobo's subversion  repo
    >    git svn init
https://gobo-eiffel.svn.sourceforge.net/svnroot/gobo-eiffel/gobo/trunk
fetch the commits from revision 6555  (for instance this one which is
the gobo 3.9 release)
note, you can also git clone the entire gobo's repository .. but it is
longer
    >    git fetch -r6555
now, get sync with trunk@HEAD
    >    git svn rebase

If you want, to do some modification, I would recommend to work on your
own branch  (I use my login for that "jfiat")
    >   git checkout -b jfiat

Then you can work on your own branch ... as with any git repo, so check
the git tutorials to know how to use git. This includes locally commits
(that's such a great feature, I wish subversion implement it some day).

And when ever you are ready to commit and "push" to the official gobo's
svn repository, you switch back to the master (which represent the trunk
in subversion)
    >    git checkout master
Eventually sync with head with:  git svn rebase

Merge the changes from your branch
    >    git merge --squash jfiat
The --squash is used to merge your branch to the master .. BUT without
doing any commit, then you can commit your change in only one commit.
I tried without the "--squash", and it re-creates all the commits done
in my branch into the master. This could be useful, if you want to
"replay" your work in the master for history...

You can then commit your change
    >    git commit -a -m "Merge jfiat's branch into the master branch
to implement feature X"

And finally, you push/send your changes to the svn repo
    >   git svn dcommit

Check the following links for use cases:
    - http://techbase.kde.org/Development/Tutorials/Git
    - http://live.gnome.org/GitForGnomeDevelopers

So this way to do, can be a temporary solution to use git with Gobo.
Then decide with gobo's developers, if git is the right tool for gobo's
repo.

(Note that using git with real git repositories, is easier and more fun,
but .. git-svn is a solution to try, and even work)

-- Jocelyn

Howard Thomson wrote:

> >
> > Hi Eric & Wolfgang,
> >
> > I would welcome a move to using Git as the SCM system for Gobo.
> >
> > I see that there is a useful page on wikipedia about git, with
> > reference to Windows implementations:
> >
> > http://en.wikipedia.org/wiki/Git_(software)#Implementation
> >
> > There is also an excellent website detailing how to use git ...
> >
> > http://progit.org/
> >
> > <snip>....</snip>
> >
> > I think using Git would assist in cooperation between myself and other
> > gobo-eiffel contributors and developers.
> >
> > Regards,
> >
> > Howard Thomson
> >
>   

Re: [gobo-eiffel-develop] Git development

[Jocelyn <ei...@dj...>]

Note that, I first learn about git with this document:
   
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
Then for svn user, this doc can help
    http://git.or.cz/course/svn.html
And of course the official git web site, with all its links
    http://git-scm.com/
including:
    http://book.git-scm.com/  


-- Jocelyn

[gobo-eiffel-develop] Git development

[Howard T. <how...@di...>]

Hi Eric & Wolfgang,

I would welcome a move to using Git as the SCM system for Gobo.

I see that there is a useful page on wikipedia about git, with reference to Windows implementations:

http://en.wikipedia.org/wiki/Git_(software)#Implementation

There is also an excellent website detailing how to use git ...

http://progit.org/

Regarding my own project:

I have recently, I think [famous last words], reached stability with my
GC when compiling with my modified 'gec', albeit that I have only so
far tested it on Linux. A Win32 version should be a fairly trivial adaptation,
as it should be no more than adaptation of a single, smallish, routine.

I am also thinking of renaming my project as 'guide',
the Gobo-eiffel Users' Integrated Development Environment,
from 'edp', the Eiffel Developers' Project. Although there a few
classes [from other sources] that are LGPL, nearly all code that does
not already derive from gobo, is EFFLv2 or MIT.

I am very interested to hear about the introspection and debugger code, as
I need such facilities for my intended future coding.

One of the areas of the code generator that I intend to alter is the polymorphic
dispatch implementation, for two reasons:

Firstly for rapid re-compilation, I want to be able to generate an initial code package as
an executable stub with dynamic library, where libraries register their routine addresses
with the runtime, with subsequent partial re-compilation code generated as an additional
dynamic library whose routines override the registered routines of the initial library. This
requires that routine dispatch be done using a tree data structure, of some sort ...

Secondly, I envisage that it should be possible, as with Java and other languages [mostly interpreted ..],
to dynamically add class libraries to an executable system, where such libraries have been packaged,
[compiled or otherwise verified against] to be compatible with classes already in the current system.
That would also require that the dispatch to reachable routines be dynamically extendable.

I am adapting my work on the Eiffel GUI toolkit derived from the Fox-toolkit to use the Vision2 interface,
providing an X11/Win32 all Eiffel GUI Toolkit, which has its advantages ...

I am working toward using LLVM as the basis for code generation for native Eiffel routines, initially to emit
LLVM assembler with llvm-as invocation, and with the possibility [much] later of emitting machine code directly.

I think using Git would assist in cooperation between myself and other gobo-eiffel contributors and developers.

Regards,

Howard Thomson

--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former." -- Albert Einstein 

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