gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Introspection, persistence, debugger

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

Hi Wolfgang,

Wolfgang Jansen wrote:
> I would like to contribute the following
> features/parts to the GEC compiler:
> - introspection (in particular, class INTERNAL)
>  and persistence closure (in particular, class STORABLE),
>  see persist.pdf
> - debugger, see debug.pdf
> 
> In the course of recent years I implemented those parts
> for the SE-1.* compiler (not integrated into the
> official release), and the last version is almost
> completely written in Eiffel. Thus, it should be
> possible to integrate the stuff into the GEC as well.
> The integration of introspection and persistence closure
> (at least the core parts) seems to be straight forward
> whereas integrating the debugger is much more involved.
> 
> Most of the development still to be done will be my work
> (help about the meaning of existing compiler classes
> and their features may be necessary from time to time).
> Moreover, the development is rather separated from
> the main lines of the development of the compiler,
> therefore, conflicts should be rare. On the other hand,
> things may take some time since it's not my main work.
> 
> What do you think about the topic?

I just finished reading your documents, and here are my
remarks:


INTERNAL
--------

In order to take full advantage of the dynamic type set
mechanism implemented in gec, my plan was to implement
class TYPE first (introduced in ECMA), and then add to
class TYPE the features currently available in INTERNAL.
The features of INTERNAL could be implemented using those
from TYPE in order to allow backward compatibility for
applications currently compiled with ISE. Let's consider
that we have in ANY:

    generating_type: TYPE [like Current]

and in class TYPE:

    attribute_count: INTEGER
         external
              "built_in"

we could implement `field_count' in INTERNAL as follows:

    Result := object.generating_type.attribute_count

and likewise for the other features in INTERNAL. In your
document you mentioned a class INTRO_TYPES. Is it similar
to class TYPE above? In the generated C code there is
already an array 'getypes' whose purpose will be to return
a TYPE object indexed by type-id.


STORABLE
--------

It would indeed be interesting to plug your implementation
of STORABLE in gec. I have two concerns though. First, are
you aware that ISE also implemented a version of Storable
in Eiffel:

http://dev.eiffel.com/cgi-bin/viewvc.cgi/trunk/Src/library/base/ise/serialization/

As far as I understood, they only use INTERNAL. So I wonder
whether you should try to use the experience you gained when
developing your Storable for SmartEiffel and try to improve
ISE's SED library rather than providing a competing library.

The other concern that I have is interoperability. It would
be nice if gec could at least have a way to read and write
the file formats produced by the old ISE's STORABLE mechanism
(at least independent_store). And why not also the file format
produced by SE 2.*, although I'm less interested in this one ;-)
It may be sound odd to try to be interoperable with ISE's old
STORABLE, but that's something I will need at work (we have a
lot of Storable files like that). And probably others currently
using ISE Eiffel will have the same need. So this will have
to be implemented at some stage.


deep_twin
---------

You didn't mention it in your message, but it is mentioned
in your document. None of the deep features are implemented
yet in gec. Even though I don't like to use deep_twin myself
(I prefer to control the level of duplication I want by
redefining `copy'), one of the programs I currently try to
compile with gec at work uses it. So it will need to be
implemented soon.


Debugger
--------

This topic is something that I'm not very good at. So I really need
to rely on others to implement a good debugging mechanism for gec.
I have not really thought about it. My only requirement is that
it should be user-friendly and should do what people expect from
a debugger. So people who want to contribute in this area will
be free to do pretty much what they want, also I will be interested
in following their progress.

But gec is not as advanced as SmartEiffel with respect to
debugging. There is currently only one compilation mode, with
no stack trace, no assertion monitoring, no exception. So
everything needs to be done in this area. If this is not
frightening you, then that would be great.



You spoke about your availability to work on this project.
INTERNAL/TYPE and deep_twin are something that I will need
relatively soon. So I guess I should start implementing
them myself. Of course it does not mean that you cannot
help or that I won't need your help. For STORABLE,
what I will need will be something similar to ISE's
independent store. I don't think that any of us can
implement that in short amount of time. I guess that
you would prefer to work on your own Storable format (which
looks interesting just by reading you document), although it
would be nice if you could have a look at ISE's SED and see
if/how it could be improved. The part of your contribution
offer that I would be the most interested in, considering
my need and your availability, would be the debugger part.
Indeed, this is not something that I need in the short term,
so you have plenty of time to work on it without too much
constraints. There is not that much conflicting parts with
what I currently work on in the compiler. And this is something
that I don't think I will be able to implement myself anyway.
And everything needs to be done from scratch. So if you are
not frightened by that, this could be an interesting experience.

Now I should mention that people contributing to the Gobo
project need to follow some programming rules. It is difficult
to follow them at first because most of them are not explicitly
stated. Some are here:

    http://www.gobosoft.com/eiffel/gobo/guidelines/

Some are just implicit (just look at how the other classes
in Gobo look like). The idea is to have a Gobo package where
all classes follow the same programming style so that we have
some sort of uniformity, instead of being a set of independently
developed parts.

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

[gobo-eiffel-develop] Introspection, persistence, debugger

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

Hi Eric,

I would like to contribute the following
features/parts to the GEC compiler:
- introspection (in particular, class INTERNAL)
 and persistence closure (in particular, class STORABLE),
 see persist.pdf
- debugger, see debug.pdf

In the course of recent years I implemented those parts
for the SE-1.* compiler (not integrated into the
official release), and the last version is almost
completely written in Eiffel. Thus, it should be
possible to integrate the stuff into the GEC as well.
The integration of introspection and persistence closure
(at least the core parts) seems to be straight forward
whereas integrating the debugger is much more involved.

Most of the development still to be done will be my work
(help about the meaning of existing compiler classes
and their features may be necessary from time to time).
Moreover, the development is rather separated from
the main lines of the development of the compiler,
therefore, conflicts should be rare. On the other hand,
things may take some time since it's not my main work.

What do you think about the topic?

PS:
I tried to add descriptions of the stuff in PDF format
but the mail got too large (about 270kB needed for
gzipped file but only 65 kB allowed).

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

Re: [gobo-eiffel-develop] Expanded types cause error in generated C code

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

Hi Wolfgang,

Wolfgang Jansen wrote:
> when experimenting with the "gec" it happened
> that C compilation failed if the Eiffel code contains
> entities of expanded types.
> There are two kinds or errors:
> - wrong arrangement of type definitions in the *.h file
> - bad initializer of local variables
> (0 when a struct is expected)

I fixed both problems. Well, at least the example you
sent me now compiles. But be prepared for other glitches
with expanded types. For example not all validity rules for
expanded types are checked, `default_create' is not called
on new objects and `copy' is not called in assignments
(which might be OK as long as `default_create' and `copy'
have not been redefined). Arrays of expanded items might
have problems as well.

If you want to try the new version, you will have to get
it from SVN. I don't know if you're familiar with the bootstrap
mechanism of Gobo. You first have to get a fresh copy from SVN, and
then follow the instructions in $GOBO/work/bootstrap/Readme.txt.
For your convenience I've added 'cc' to the list of supported
C compiler here as well.

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

Re: [gobo-eiffel-develop] Expanded types cause error in generated C code

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

Eric Bezault wrote:
> Hi Wolfgang,
>
> Wolfgang Jansen wrote:
>> when experimenting with the "gec" it happened
>> that C compilation failed if the Eiffel code contains
>> entities of expanded types.
>> There are two kinds or errors:
>> - wrong arrangement of type definitions in the *.h file
>> - bad initializer of local variables
>> (0 when a struct is expected)
>>
>> I tried several modifications of routine
>> `ET_C_GENERATOR.print_types' to rearrange type definitions
>> and achieved improvements but no satisfying solution.
>
> Unfortunately expanded types are not supported yet:
>
>    http://www.gobosoft.com/eiffel/gobo/gec/limitations.html
>
> Even after modifying ET_C_GENERATOR.print_types to make it
> work, I'm pretty sure that there would be other glitches
> when there are special Eiffel validity rules or semantics
> for expanded types.
>
>> Probably, the routine must follow the graph of client
>> relations (at least the subgraph of attribute relations)
>> such that the "typedef" declarations are written
>> in the pre-processing phase (to have the corresponding
>> _pointer_ types defined in case of a cyclic dependency)
>> whereas the "struct ..." definitions are written in
>> the post-processing phase (when all attribute types
>> have been processed).
>
> Isn't it what ET_C_GENERATOR.print_types already does?
>
Not yet. The routine does not follow the client relations
but traverses the types by increasing type numbers.
In case of the first written "typedef"s the effect is the
same as what I inteded by "pre-processing".
The bug is that the "struct" of the expanded attribute
is written after the "struct" of its enclosing class
(the post-processing rule would reverse them).
This is caused by the type numbers which have been
associated somewhere else during compilation.
To be precise, I conjecture that the type numbers are
associated in pre-processing manner (and then increasing
type numbers reflect the pre-processing) when the compiler
follows the client relations during program analysis.
If this is so then the actual routine "print_types"
makes pre-processing, not post-processing.

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

Re: [gobo-eiffel-develop] Expanded types cause error in generated C code

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

Hi Wolfgang,

Wolfgang Jansen wrote:
> when experimenting with the "gec" it happened
> that C compilation failed if the Eiffel code contains
> entities of expanded types.
> There are two kinds or errors:
> - wrong arrangement of type definitions in the *.h file
> - bad initializer of local variables
> (0 when a struct is expected)
> 
> I tried several modifications of routine
> `ET_C_GENERATOR.print_types' to rearrange type definitions
> and achieved improvements but no satisfying solution.

Unfortunately expanded types are not supported yet:

    http://www.gobosoft.com/eiffel/gobo/gec/limitations.html

Even after modifying ET_C_GENERATOR.print_types to make it
work, I'm pretty sure that there would be other glitches
when there are special Eiffel validity rules or semantics
for expanded types.

> Probably, the routine must follow the graph of client
> relations (at least the subgraph of attribute relations)
> such that the "typedef" declarations are written
> in the pre-processing phase (to have the corresponding
> _pointer_ types defined in case of a cyclic dependency)
> whereas the "struct ..." definitions are written in
> the post-processing phase (when all attribute types
> have been processed).

Isn't it what ET_C_GENERATOR.print_types already does?

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

[gobo-eiffel-develop] Expanded types cause error in generated C code

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

Hi,

when experimenting with the "gec" it happened
that C compilation failed if the Eiffel code contains
entities of expanded types.
There are two kinds or errors:
- wrong arrangement of type definitions in the *.h file
- bad initializer of local variables
 (0 when a struct is expected)

I tried several modifications of routine
`ET_C_GENERATOR.print_types' to rearrange type definitions
and achieved improvements but no satisfying solution.
Probably, the routine must follow the graph of client
relations (at least the subgraph of attribute relations)
such that the "typedef" declarations are written
in the pre-processing phase (to have the corresponding
_pointer_ types defined in case of a cyclic dependency)
whereas the "struct ..." definitions are written in
the post-processing phase (when all attribute types
have been processed).

PS:
The attachment contains the Eiffel classes of an example,
an ACE file, and the compiler messages (for both, "cc" and "gcc").

PPS:
Maybe you got this message a second time: I sent it a second time
since the mail server told me that the original message had not been 
delivered.

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

Re: [gobo-eiffel-develop] check if ET_CLASS_TYPE can be used as actual parameter

[Thomas D. <th...@de...>]

Thanks a lot! (again).

Kind Regards

Thomas

On 7/19/07, Eric Bezault <er...@go...> wrote:
> Thomas Delaet wrote:
> > Hi,
> >
> > I have two ET_CLASS objects: a and b.
> > Assume that the first object (A) has one generic parameter. If that
> > parameter is constrainted, I want to check if another object (B)
> > conforms to the generic constraint.
> >
> > Based on my current knowledge, I guess I should use the
> > conforms_to_type feature of ET_CLASS, but I don't know how to use this
> > feature correctly in this case.
> >
> > The signature of conforms_to_type is:
> >
> > conforms_to_type (other: ET_TYPE; other_context: ET_TYPE_CONTEXT;
> > a_context: ET_TYPE_CONTEXT; a_universe: ET_UNIVERSE): BOOLEAN
> >
> > So, I guess I should call this feature on object a.
>
> You meant object b, not a.
>
> > The question is
> > then: what values do I have to fill in for the other arguments, except
> > for a_universe?
> >
> > It think the value of other should be
> > a.formal_parameters.item(1).constraint, so that leaves other_context
> > and a_context to be filled in ...
>
> The context is where your type comes from. For example the type
> 'like Current' has different meanings depending on whether it
> appears in class STRING or in class ARRAY. If the context is
> class STRING, then we can say that 'like Current' conforms to
> COMPARABLE, which is not the case if the context was ARRAY.
> Furthermore, in the context of 'LINKED_LIST [STRING]' type G
> conforms to STRING.
>
> So if your types appears in class C, for example:
>
> class A [G -> LIST [H], H] ...
> class B inherit LINKED_LIST [STRING] ...
>
> class C
> feature
>      a: A [B, COMPARABLE]
>
> what we need to prove is that in the context of C
> the type B conforms LIST [H] in the context of
> A [B, COMPARABLE]. Which is indeed the case because
> B in the context of C is B itself, and 'LIST [H]'
> in the context of A [B, COMPARABLE] is nothing else
> but LIST [COMPARABLE], and B conforms to LIST [COMPARABLE].
>
> As an example, have a look at ET_TYPE_CHECKER.check_class_type_validity.
>
> --
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
>


-- 
Thomas

Re: [gobo-eiffel-develop] check if ET_CLASS_TYPE can be used as actual parameter

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

Thomas Delaet wrote:
> Hi,
> 
> I have two ET_CLASS objects: a and b.
> Assume that the first object (A) has one generic parameter. If that
> parameter is constrainted, I want to check if another object (B)
> conforms to the generic constraint.
> 
> Based on my current knowledge, I guess I should use the
> conforms_to_type feature of ET_CLASS, but I don't know how to use this
> feature correctly in this case.
> 
> The signature of conforms_to_type is:
> 
> conforms_to_type (other: ET_TYPE; other_context: ET_TYPE_CONTEXT;
> a_context: ET_TYPE_CONTEXT; a_universe: ET_UNIVERSE): BOOLEAN
> 
> So, I guess I should call this feature on object a.

You meant object b, not a.

> The question is
> then: what values do I have to fill in for the other arguments, except
> for a_universe?
> 
> It think the value of other should be
> a.formal_parameters.item(1).constraint, so that leaves other_context
> and a_context to be filled in ...

The context is where your type comes from. For example the type
'like Current' has different meanings depending on whether it
appears in class STRING or in class ARRAY. If the context is
class STRING, then we can say that 'like Current' conforms to
COMPARABLE, which is not the case if the context was ARRAY.
Furthermore, in the context of 'LINKED_LIST [STRING]' type G
conforms to STRING.

So if your types appears in class C, for example:

class A [G -> LIST [H], H] ...
class B inherit LINKED_LIST [STRING] ...

class C
feature
     a: A [B, COMPARABLE]

what we need to prove is that in the context of C
the type B conforms LIST [H] in the context of
A [B, COMPARABLE]. Which is indeed the case because
B in the context of C is B itself, and 'LIST [H]'
in the context of A [B, COMPARABLE] is nothing else
but LIST [COMPARABLE], and B conforms to LIST [COMPARABLE].

As an example, have a look at ET_TYPE_CHECKER.check_class_type_validity.

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

[gobo-eiffel-develop] check if ET_CLASS_TYPE can be used as actual parameter

[Thomas D. <th...@de...>]

Hi,

I have two ET_CLASS objects: a and b.
Assume that the first object (A) has one generic parameter. If that
parameter is constrainted, I want to check if another object (B)
conforms to the generic constraint.

Based on my current knowledge, I guess I should use the
conforms_to_type feature of ET_CLASS, but I don't know how to use this
feature correctly in this case.

The signature of conforms_to_type is:

conforms_to_type (other: ET_TYPE; other_context: ET_TYPE_CONTEXT;
a_context: ET_TYPE_CONTEXT; a_universe: ET_UNIVERSE): BOOLEAN

So, I guess I should call this feature on object a. The question is
then: what values do I have to fill in for the other arguments, except
for a_universe?

It think the value of other should be
a.formal_parameters.item(1).constraint, so that leaves other_context
and a_context to be filled in ...

Thanks a lot in advance

Kind Regards
-- 
Thomas

Re: [gobo-eiffel-develop] Problems when installing GEC

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

Wolfgang Jansen wrote:
> Wolfgang Jansen wrote:
>> The attachment contains the binaries of "gec", ... to be added to
>> http://www.gobosoft.com/eiffel/gobo/gec/platforms.html
>> Except for "gec", I did not test staff.
>>
>> Computer: alpha
>> OS: OSF1 V5.1
>> CC: Compaq C V6.4
>> others: 64 bit, little endian, Tru64
>>
>>   
> Sorry, first I forgot the attachment, second it turns out
> the the zipped binaries are too large for my web-browser.

Your binaries (except gexslt which was too big) have now been
uploaded to SourceForge.
Thanks.

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

Re: [gobo-eiffel-develop] Problems when installing GEC

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

Wolfgang Jansen wrote:
> The attachment contains the binaries of "gec", ...

You should probably not send it to the mailing list.
Either send it direclty to me or make it temporarily
available somewhere so that I can download it.

> to be added to
> http://www.gobosoft.com/eiffel/gobo/gec/platforms.html
> Except for "gec", I did not test staff.
> 
> Computer: alpha
> OS: OSF1 V5.1
> CC: Compaq C V6.4
> others: 64 bit, little endian, Tru64

I updated my version of the file (to be soon committed to SVN).

Thanks.

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

Re: [gobo-eiffel-develop] Problems when installing GEC

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

Wolfgang Jansen wrote:
>
> The attachment contains the binaries of "gec", ... to be added to
> http://www.gobosoft.com/eiffel/gobo/gec/platforms.html
> Except for "gec", I did not test staff.
>
> Computer: alpha
> OS: OSF1 V5.1
> CC: Compaq C V6.4
> others: 64 bit, little endian, Tru64
>
>   
Sorry, first I forgot the attachment, second it turns out
the the zipped binaries are too large for my web-browser.

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

Re: [gobo-eiffel-develop] Problems when installing GEC

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

Eric Bezault wrote:
> I don't like warnings when the code is valid.
> But I agree that sometimes it will be useful to have this
> information as warning when the Eiffel code is really at fault.
>
This was my intension. I did not expect that the compiler looks
across routine boundaries. I agree that in this case
a warning in one class because of a void reference in another
class is very misleading.

>
> BTW, what is 'icc'? Is it the same as what I found on wikipedia:
>
>   http://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler
>
Yes. Sometimes a friend gives me the access to a platform
where "icc" runs. My impression is that the compiler is
better that "cc" which in turn is much better than "gcc".
In other words, if a user of "gec" works on a platform
supporting "icc" then it is highly probable that he wants
to use the "icc" in connection with "gec".

PS
The attachment contains the binaries of "gec", ... to be added to
http://www.gobosoft.com/eiffel/gobo/gec/platforms.html
Except for "gec", I did not test staff.

Computer: alpha
OS: OSF1 V5.1
CC: Compaq C V6.4
others: 64 bit, little endian, Tru64

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

Re: [gobo-eiffel-develop] Problems when installing GEC

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

Wolfgang Jansen wrote:
> Eric Bezault wrote:
>> 'gevoid' is the result of the code optimizer.
>> corresponding Eiffel code, no matter what, this call will result in
>> a call on Void target. For example:
>>
>>      local
>>         s: STRING
>>      do
>>         s.append_string ("gobo")
>>
>> 'gevoid' is then emitted instead of the call.
> Now, I understand. What about issuing a compiler warning
> stimulating the programmer to eleminate the awkward construct?

I don't like warnings when the code is valid. For example if
in a third-party library class we have:


    f (s: STRING) is
       do
           if s /= Void then
                print (s.as_upper)
           else
                print ("Void string")
           end
       end

and then in my application I have:

   x.f (Void)

the dynamic type set mechanism used by the Gobo optimizer will
tell me that `s' will always be Void in `f', therefore there is
no need to generate the code for `as_upper' and 'gevoid' will
used in the call instead. But there is nothing to be fixed because
the code will not be called anyway. The optimizer has no flow
analysis to determine that we are in an if-branch that can
never be entered. And there is nothing wrong with `f'
because as soon as we add the line:

   x.f ("gobo")

in our application 'gevoid' will not be emitted in the generated
C code anymore.

But I agree that sometimes it will be useful to have this
information as warning when the Eiffel code is really at fault.

> The attachments contain the configuration file for use
> of the "cc" on alpha platforms and the adapted "install.sh".

Thank you. I will add them to Gobo SVN.
BTW, what is 'icc'? Is it the same as what I found on wikipedia:

   http://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler

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

Re: [gobo-eiffel-develop] Problems when installing GEC

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

Eric Bezault wrote:
>
> BTW, what platform are you using?
It's an (formerly DEC) alpha under OSF1. OK, it is a rare platform nowadays.
Anyway, the best C compiler there I'm aware of is the "cc".
>
>>
>> Just for curiosity, what is "gevoid" good for? Its definition seems
>>
> 'gevoid' is the result of the code optimizer.
> corresponding Eiffel code, no matter what, this call will result in
> a call on Void target. For example:
>
>      local
>         s: STRING
>      do
>         s.append_string ("gobo")
>
> 'gevoid' is then emitted instead of the call.
Now, I understand. What about issuing a compiler warning
stimulating the programmer to eleminate the awkward construct?
>
> You will have to configure gec to use cc as C compiler. See
> section "Back-end C compiler" in:
>
>    http://www.gobosoft.com/eiffel/gobo/gec/usage.html
>
I did so and compilation was successful.

The attachments contain the configuration file for use
of the "cc" on alpha platforms and the adapted "install.sh".

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

Re: [gobo-eiffel-develop] gobo ecf

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

>>>>> "Martin" == Martin Seiler <se...@et...> writes:

    Martin> Dear Eric,

    Martin> I just want to express that I feel very unhappy about how
    Martin> you acted in the ECF discussion over the past year.

I on the contrary fully support Eric's stance. 

    Martin> I personaly hated Ace since I had to deal with it in my
    Martin> first year at ETH.  I _like_ ECF. I do not force you to
    Martin> like it...

I don't like ACE either - but that's because I am quite unfamiliar with
it, having always used Gobo's XACE format - which is simple, and
portable across all known Eiffel compilers.

    Martin> I respect your opinion.  But you do not respect
    Martin> mine.

How can you make such an assertion?

    Martin> I want ECF. I want ECF support in _all_ gobo tools.
    Martin> This is the need of your users. And I think it is time for
    Martin> pragmatism.

It is not the need of Gobo users. Gobo is for portable Eiffel
tools. ECF is not a portable tool.
It has previously been suggested that the syntax of a configuration
file does not matter - using the configuration library is all that is
needed, and it could be made to support ACE. But no such support has
been offered.
Eric has put a lot of work into writing support for parsing ACE files,
and also for the XACE tool, which provides a portable configuration
file format, and is easily extended.

    Martin> Not having support for it caused me and others already
    Martin> enough pain.

Which is quite predictable, and entirely the fault of Eiffel
software. We already had a portable XML configuration file format (I
entirely agree with Franck Arnaud that XML is highly suitable as a
syntax for such tools), which could easily have been extended to meet
Eiffel Software's needs, but they chose to ignore this possibility,
and developed their own format, without public consultation.
You are shooting at the wrong target.

    Martin> And now you tell me that actually code
    Martin> exists but you don't release it?  This is a punch in the
    Martin> face of your users...

Hardly. The code concerned is copyright by Eric's employer, and is
not eligible to be included in any open source project, unless the
employer should decide to do so.

But I have used this code (I work for the same firm as Eric). While it
allows parsing an ECF file, it doesn't overcome the problems with ECF
- I know - I have suffered from them.

    Martin> You act very much
    Martin> against the way open source projects work.  I simply feel
    Martin> that gobo is _not_ open enough.  There was more than one
    Martin> attempt of people to add this support to gobo, but you
    Martin> blocked it.  And now you did it again.

This is not true. No-one has offered to donate any software that would
generate ace or xace files from an ecf file, which is the only "pragmatic"
response to the mess that Eiffel Software have got us into. 
But even that action (which Eiffel Software has a moral responsibility
to do as an interim measure) won't overcome the problems with ECF.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] gobo ecf

[Martin S. <se...@et...>]

Dear Eric,

I just want to express that I feel very unhappy about how you acted in the ECF discussion over the past year.

I personaly hated Ace since I had to deal with it in my first year at ETH.
I _like_ ECF. I do not force you to like it... I respect your opinion.
But you do not respect mine.

I want ECF. I want ECF support in _all_ gobo tools.

This is the need of your users. And I think it is time for pragmatism.

Not having support for it caused me and others already enough pain.
And now you tell me that actually code exists but you don't release it?
This is a punch in the face of your users...

You are the BDFL (http://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life) and abuse your position
by refusing to incorporate patches by others into the repository which were a first step
into the direction to support ECF in gobo.
You act very much against the way open source projects work.
I simply feel that gobo is _not_ open enough.
There was more than one attempt of people to add this support to gobo, but you blocked it.
And now you did it again.

How do others think about it? I think it is definitly time to make progress.

regards,

  Martin


On Sat, 14 Jul 2007 18:02:10 +0200
Eric Bezault <er...@go...> wrote:

> Hi Thomas,
> 
> Thomas Delaet wrote:
> > I'm interested in completing ECF support in Gobo. The main reason is 
> > that it would be nice to have for my phd project which uses erl-g (which 
> > in turn relies on gobo for parsing system control files).
> > 
> > Based on the code, I understand that the only thing left for ECF support 
> > is implementing a parser that populates the ET_ECF_UNIVERSE class. Is 
> > this correct? Do you have any hints on this process? I looked at the 
> > framework/configuration/parser directory in estudio svn and I guess I 
> > could reuse most of it. That leaves only the process of converting the 
> > created data-structures in ET_* datastructures ...
> 
> If you followed the discussions on the gobo-eiffel-develop mailing
> list during the past year or so, you would know that I was very much
> against the introduction of ECF as a replacement of Ace. Therefore
> I'm not ready to let people waste their time trying to make Gobo
> support ECF. I don't say that Gobo will never support ECF, just that
> I'm not ready for the idea yet. The only reason why there are ECF
> skeleton classes in Gobo is because my employer paid me to do so.
> I know how to plug ISE's ECF parser to populate ET_ECF_UNIVERSE.
> I was paid to do so. But I'm very sorry, I'm not ready to show people
> how to do it, neither to integrate that code into Gobo.
> 
> Also note that having full support for ECF in Gobo is not just
> about using an ECF parser to populate ET_ECF_UNIVERSE. There are
> functionalities which have changed between Ace and ECF. For example
> the introduction of libraries and the way class name clashes are
> handled (or ignored).
> 
> -- 
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

-- 
/*
 * martin seiler
 * se...@et...
 */
-- 
/*
 * martin seiler
 * se...@et...
 */

Re: [gobo-eiffel-develop] gobo ecf

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

Hi Thomas,

Thomas Delaet wrote:
> I'm interested in completing ECF support in Gobo. The main reason is 
> that it would be nice to have for my phd project which uses erl-g (which 
> in turn relies on gobo for parsing system control files).
> 
> Based on the code, I understand that the only thing left for ECF support 
> is implementing a parser that populates the ET_ECF_UNIVERSE class. Is 
> this correct? Do you have any hints on this process? I looked at the 
> framework/configuration/parser directory in estudio svn and I guess I 
> could reuse most of it. That leaves only the process of converting the 
> created data-structures in ET_* datastructures ...

If you followed the discussions on the gobo-eiffel-develop mailing
list during the past year or so, you would know that I was very much
against the introduction of ECF as a replacement of Ace. Therefore
I'm not ready to let people waste their time trying to make Gobo
support ECF. I don't say that Gobo will never support ECF, just that
I'm not ready for the idea yet. The only reason why there are ECF
skeleton classes in Gobo is because my employer paid me to do so.
I know how to plug ISE's ECF parser to populate ET_ECF_UNIVERSE.
I was paid to do so. But I'm very sorry, I'm not ready to show people
how to do it, neither to integrate that code into Gobo.

Also note that having full support for ECF in Gobo is not just
about using an ECF parser to populate ET_ECF_UNIVERSE. There are
functionalities which have changed between Ace and ECF. For example
the introduction of libraries and the way class name clashes are
handled (or ignored).

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

Re: [gobo-eiffel-develop] Problems when installing GEC

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

Hi Wolfgang,

Wolfgang Jansen wrote:
> I tried to install the new GOBO (5.6) release and ran
> immediately into trouble: my preferred C compiler is "cc"
> but command "$GOBO/install.sh cc" stopped with the message
> 
>   Unknown C compiler: cc
> 
> It is really surprising that the native C compiler of many platforms
> is not supported.

The problem is that I only have access to Windows platform.
So I can only work and test on this platform. At some point
SourceForge made available other platforms through their
compile farm:

    http://en.wikipedia.org/wiki/Compiler_farm

But they don't provide this service anymore ;-( The reason
why only gcc was made available is because that's the only
C compiler that was available on SourceForge's compile farm
platforms as far as I know. But people are free to test gec
on other platforms and with other C compilers and give me
some feedbacks.

    http://www.gobosoft.com/eiffel/gobo/gec/platforms.html

BTW, what platform are you using?

> When trying the same with "gcc" then many warnings like the following
> were issued:
> 
>   gec.c: In function `T202f63':
>   gec.c:82734: warning: cast to pointer from integer of different size
> 
> Line 82734 in C code reads
> 
>   t2 = ((T0*)gevoid(((T202*)(C))->a20, l2));
> 
> whereas "gevoid" is declared as
> 
>   extern int gevoid(T0* C, ...);
> 
> Thus, the bad cast is from "int" to "T0*", i.e. from 4 to 8 bytes
> on a Tru64 platform (as I'm working on). I think, the solution is
> to redefine "gevoid" like "T0* gevoid(T0* C, ...)".
> Just for curiosity, what is "gevoid" good for? Its definition seems
> to indicate that it is the check for void targets, but there is no test
> (neither in the routine nor around its call), merely printing an error
> message and aborting the program. And if aborting in any case has been
> planned, why then a return value?

'gevoid' is the result of the code optimizer. It means that in the
corresponding Eiffel code, no matter what, this call will result in
a call on Void target. For example:

      local
         s: STRING
      do
         s.append_string ("gobo")

'gevoid' is then emitted instead of the call. I think that the problem
above is that I tried to use the same 'gevoid' function to replace all
kinds of calls, be them procedures or functions with expanded or
reference result. I was hoping that explicit type cast would make the
C compiler happy, which it did with the compilers I tried. Apparently
I will have to rethink about it and find a better implementation.

> After the warnings an error message follows:
> 
>   as1: Error: /usr/tmp/cciOAHCE.s, line 5: gp-relative segments together 
> exceed 64k bytes
> 
> Probably, the generated object file is too large.
> (I had the same effect also earlier when bootstrapping the SE compiler
> from a single C file instead from a split one.)

Hmmm, I asked someone to test on Linux (Ubuntu 7.04) with gcc and
everything worked OK. It was not my intention to work on C file
splitting in the near future. I will probably have to reconsider.

> Then many errors of the form
>   /usr/users13/wolfgang/eiffel/gobo/install.sh: 
> /usr/users13/wolfgang/eiffel/gobo/bin/gec: not found
>   /usr/users13/wolfgang/eiffel/gobo/install.sh: geant: not found
> 
> occurred, probably a consequence of the previous error.

Yes.

> PS:
> After adding the "cc" compiler to "install.sh" the outcome was
> as follows:
> 
>   cc: Warning: gec.c, line 479288: Non-void function "gevoid" does not 
> contain a return statement. (missingreturn)
>   int gevoid(T0* C, ...)
> 
> The bad cast is not rejected and the compilation of "gec"
> is successful. Then most of "geant", ... are compiled successfully
> where C compilation is again done by "gcc" (to be seen by
> the warnings concerning bad casts). Why "gcc"?

You will have to configure gec to use cc as C compiler. See
section "Back-end C compiler" in:

    http://www.gobosoft.com/eiffel/gobo/gec/usage.html


What this install script does is just generate the binary files
in $GOBO/bin. For those of you who don't want to have to generate
them by themselves, I made available the binaries for Windows in:

   https://sourceforge.net/project/showfiles.php?group_id=24591

Anyone is welcome to provide the binaries for his platform so
that I can make them available on SourceForge as well.

Wolfgang, thank you for your feedback, and don't hesitate to
send me a cc.cfg file if you manage to make one working on
your platform.

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

[gobo-eiffel-develop] Problems when installing GEC

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

Hello the GOBO team,

I tried to install the new GOBO (5.6) release and ran
immediately into trouble: my preferred C compiler is "cc"
but command "$GOBO/install.sh cc" stopped with the message

  Unknown C compiler: cc

It is really surprising that the native C compiler of many platforms
is not supported.

When trying the same with "gcc" then many warnings like the following
were issued:

  gec.c: In function `T202f63':
  gec.c:82734: warning: cast to pointer from integer of different size

Line 82734 in C code reads

  t2 = ((T0*)gevoid(((T202*)(C))->a20, l2));

whereas "gevoid" is declared as

  extern int gevoid(T0* C, ...);

Thus, the bad cast is from "int" to "T0*", i.e. from 4 to 8 bytes
on a Tru64 platform (as I'm working on). I think, the solution is
to redefine "gevoid" like "T0* gevoid(T0* C, ...)".
Just for curiosity, what is "gevoid" good for? Its definition seems
to indicate that it is the check for void targets, but there is no test
(neither in the routine nor around its call), merely printing an error
message and aborting the program. And if aborting in any case has been
planned, why then a return value?

After the warnings an error message follows:

  as1: Error: /usr/tmp/cciOAHCE.s, line 5: gp-relative segments together 
exceed 64k bytes

Probably, the generated object file is too large.
(I had the same effect also earlier when bootstrapping the SE compiler
from a single C file instead from a split one.)

Then many errors of the form
  /usr/users13/wolfgang/eiffel/gobo/install.sh: 
/usr/users13/wolfgang/eiffel/gobo/bin/gec: not found
  /usr/users13/wolfgang/eiffel/gobo/install.sh: geant: not found

occurred, probably a consequence of the previous error.


Wolfgang


PS:
After adding the "cc" compiler to "install.sh" the outcome was
as follows:

  cc: Warning: gec.c, line 479288: Non-void function "gevoid" does not 
contain a return statement. (missingreturn)
  int gevoid(T0* C, ...)

The bad cast is not rejected and the compilation of "gec"
is successful. Then most of "geant", ... are compiled successfully
where C compilation is again done by "gcc" (to be seen by
the warnings concerning bad casts). Why "gcc"?
Compilation of "gelint" and "gexslt" fail because of large size.


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

Re: [gobo-eiffel-develop] SVN properties for new files

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

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> Colin Paul Adams wrote:
    >>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
    Eric> I know that you don't know why this is happening, but I
    Eric> would rather prefer that you check and fix these properties
    Eric> in your new added files yourself, rather than doing it
    Eric> myself.
    >> I've made a note of this, for next time.

By googling, I finally found a syntax that works.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Cost of Unicode strings for ASCII data

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

>From: Eric Bezault <er...@go...>

>Colin Adams wrote:
>>In a test Eiffel program, I read the entire file into a STRING_8, and I 
>>then created a new string from that data. The elapsed time of the program 
>>depends upon the dynamic type of the resulting string. Here are my 
>>timings:
>>
>>STRING_8: 7 seconds
>>STRING_32: 13 seconds
>>UC_UTF8_STRING: 14 seconds.
>
>Which compiler did you use?

ISE 5.7

>Out of curiosity, did you try with gec?

No.

_________________________________________________________________
The next generation of Hotmail is here! http://www.newhotmail.co.uk/

Re: [gobo-eiffel-develop] Cost of Unicode strings for ASCII data

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

Colin Adams wrote:
> In a test Eiffel program, I read the entire file into a STRING_8, and I then 
> created a new string from that data. The elapsed time of the program depends 
> upon the dynamic type of the resulting string. Here are my timings:
> 
> STRING_8: 7 seconds
> STRING_32: 13 seconds
> UC_UTF8_STRING: 14 seconds.

Which compiler did you use?
Out of curiosity, did you try with gec?

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

Re: [gobo-eiffel-develop] Cost of Unicode strings for ASCII data

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

Colin Adams wrote:
> Note that the STRING_8 was created by a call:
> 
> create {STRING_8} l_text.make_from_string (l_text). Is this doing a copy?

Yes: it looks like it's cloning the `area'.

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

[gobo-eiffel-develop] XM_FILE_ EXTERNAL_RESOLVER returns text streams

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

The URI resolvers in the XML library return a KI_CHARACTER_INPUT_STREAM 
according to the interface, which is fine, but the concrete descendant for 
file: returns a KI_TEXT_INPUT_FILE, which is not so good if the resource 
happens to be a binary file.

_________________________________________________________________
The next generation of Hotmail is here! http://www.newhotmail.co.uk/