gobo-eiffel-develop

[gobo-eiffel-develop] (no subject)

[Greg C <gm...@ya...>]

Eric Bezault wrote:
> But we don't really need it since:
>
>  !! my_string.make_from_string ("foo")
>
> can be replaced by:
>
>  my_string := "foo"
>
> or:
>
>  my_string := clone ("foo")
>
> depending on whether we plan to alter this string or
> not in the next instructions.

Say for some reason my_string is a descendent of STRING; will the
assignment and/or clone still work? Or is this not an issue here?

(I vaguely recall the NICE standardization committee wrestling with this
issue a while back.)

Also, the good news about the STRING interface is that NICE is extremely
close to releasing a new, thorough specification for STRING, and some of
the compiler vendors are right behind them. Hopefully the kind of
deviation we saw with the ELKS '95 spec will someday be a thing of the
past.

Greg

=====
http://www.geocities.com/gmc444/gregs.html
Apologies for the stupid Yahoo ad below.

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

[gobo-eiffel-develop] (no subject)

[Julien G. [ES] <ju...@ei...>]

An other parsing error:
	l_att ?= feature {MY_CLASS}.my_function (a, b)

Some other parsing errors related to dotnet files.
	keywords `attribute' and `interface_attribute' to define custom
attributes on a class are not recognised.

> 
> "Julien Goussard [ES]" wrote:
> >
> > Unfotunately, I found three other parsing errors.
> >
> > External class MY_CLASS  ->  fails
> > Frozen external class MY_CLASS  ->  fails
> 
> These are ISE Eiffel for .NET specific. I will try to make
> the parser accept them tonight or tomorrow.

Thank you, I am not in a hurry...

 
> > My_character := '''  ->  fails
> 
> This is not valid Eiffel. It should be:
>  My_character := '%''
Ok.

> In $GOBO/library/tools/eiffel/parser, the error is reported
> (see ET_EIFFEL_SCANNER.process_c1_character_constant), but 
> this is not a fatal error. Did you get incorrect result 
> because of this syntax error?
I don't know as I don't try to process the AST if I have a syntax error.
I use a modified version of bang2create with geant to parse a set of
files, and geant keeps runing even if there is a syntax error in one of
the files.
 

Re: [gobo-eiffel-develop] (no subject)

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

"Julien Goussard [ES]" wrote:
> 
> > > My_character := '''  ->  fails
> >
> > This is not valid Eiffel. It should be:
> >  My_character := '%''
> Ok.
> 
> > In $GOBO/library/tools/eiffel/parser, the error is reported
> > (see ET_EIFFEL_SCANNER.process_c1_character_constant), but
> > this is not a fatal error. Did you get incorrect result
> > because of this syntax error?
> I don't know as I don't try to process the AST if I have a syntax error.
> I use a modified version of bang2create with geant to parse a set of
> files, and geant keeps runing even if there is a syntax error in one of
> the files.

You can comment out the body of ET_ERROR_HANDLER.report_SCTQ_error
to keep it quiet on this error for the time being.

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

[gobo-eiffel-develop] (no subject)

[Franck A. <fr...@ne...>]

--
fr...@ne...

Re: [gobo-eiffel-develop] (no subject)

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

Greg C wrote:
> 
> Eric Bezault wrote:
> > But we don't really need it since:
> >
> >  !! my_string.make_from_string ("foo")
> >
> > can be replaced by:
> >
> >  my_string := "foo"
> >
> > or:
> >
> >  my_string := clone ("foo")
> >
> > depending on whether we plan to alter this string or
> > not in the next instructions.
> 
> Say for some reason my_string is a descendent of STRING; will the
> assignment and/or clone still work?

No, it won't work. But in class UC_STRING 'my_string'
was a STRING, not a descendant. Therefore, also I agree
that it a shame that although `make_from_string' was 
in ELKS'95 it was not supported by some Eiffel compilers,
I think that it's a little bit twisted-mind to create a
STRING (I'm not speaking about proper descendants of
STRING) with `make_from_string' when a simple assignment
or clone will work.

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

[gobo-eiffel-develop] Eiffel Class Struggle 2001

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

Dear Gobo Project enthusiasts,

Like every year since 1997, NICE will organize the Eiffel
Class Struggle 2001. It was suggested in a recent discussion
in the Board of NICE that a Gobo theme for the contest this
year would be a good idea. Here is an excerpt:

> Whats about the following:
> 
> 1. Nice will organize the ECS 2001
> 2. ECS 2001 will ask for Libraries or tools supporting or extending the new
> Gobo library
> 3. The detailled specifications will be set by the Gobo Group within the
> next Month (End of August)
> 4. The Gobo Group will be asked to decide who will get the prices
> 5. Nice will donate 3 prices - 1000, 600 and 400 US$
> 6. OT will sponsor the contest with licenses
> 7. we will ask other companies  to sponsor also
> 8. The Gobo goup will be asked to help to formalise this announcement

I would like to know what's your opinion about this
proposal. Apart from the following kind of answers:
"Yeah, that's great!", what I'm really interested in
is whether there are people in this group who will be
ready to spend time as a judge in order to achieve
point 4. when it will be time to do so. Although I
appreciate NICE's suggestion, I'm indeed not willing
(and won't have time) to do all the judging of the
Eiffel Struggle alone. I think that the criteria used
to judge the entries will be more or less the same
as the previous years, but they will have a new
category assessing whether the tool or library follows
the Gobo developer guidelines and how easily it can
be integrated into the overall Gobo package.

PS: I'm sorry I still didn't have time to work on
the Gobo developer guildelines document, but I promise
I will do it as soon as time permits.

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

RE: [gobo-eiffel-develop] Eiffel Class Struggle 2001

[Glenn M. <gle...@op...>]

Hello Eric,

I think it is to early to restrict the Eiffel Struggle contest to particular
environments such as GOBO. The Eiffel Struggle contest has been very
successful in increasing interest in Eiffel library development without
having to be portable across Eiffel compilers.

I haven't been following the NICE mailing lists for a while so I don't know
the complete history behind this suggestion.

I have found, as I believe you have, that developing libraries that are
compatible across compilers is extremely difficult. Libraries such as GOBO
help a great deal. However, the compiler compatible facilities tend to be
'mixin' classes that are not strictly object oriented. For example, I would
consider all of the classes in GOBO that end in '_ROUTINES' not to be object
oriented, rather they are "function libraries" and stop-gap measures that
provide an interface to different classes/routines in different compiler
libraries that should be replaced, in the future, with compatible classes.

I believe the long term solution to compiler independence is not 'mixin'
classes but rather compatible concrete interfaces. I have often wondered why
the porting of EiffelBase has not yet succeeded. Did the "porters"
concentrate on supporting the entire library or just the concrete
interfaces. All I need, as an application developer, are the concrete
interfaces. I don't care that FILE inherits from UNBOUNDED or SEQUENCE, just
that is supports all of the file operations with standard names and
signatures.

Java has the advantage that no matter what the interfaces are, the byte code
will be compatible across compilers. We, as Eiffel developers, do not have
that advantage -- to use a different compiler we must have compatible class
interfaces.

I have digressed a little. I think the suggestion for Eiffel Struggle
libraries to meet GOBO standards has merit but I also believe it is
premature. I, for one, have a library that I would submit to Eiffel Struggle
that is not GOBO compatible. I could not, at this time, make it fully GOBO
compatible because of its use of Agents and ISE specific interfaces that do
not exist in other compiler environments.

I have, throughout the development of this library, attempted to make it
compiler independent, but it has proven impossible time and time again. Even
with GOBO, the different vendor environments do not support cross-compiler
development. I am continually implementing mixin function libraries that do
not comply with standard Eiffel object oriented design.

I'd would personally like to keep the Eiffel Struggle open. Any library
added to the Eiffel community improves its position even if it supports only
one of the vendor's compilers and doesn't conform to GOBO standards.

Perhaps I should have posted this (longish) comment to the NICE mailing
list. You are welcome to forward it if appropriate.

Best Regards.
Glenn.

> -----Original Message-----
> From: gob...@li...
> [mailto:gob...@li...]On Behalf Of
> Eric Bezault
> Sent: Thursday, 26 July 2001 1:44 AM
> To: gob...@li...
> Subject: [gobo-eiffel-develop] Eiffel Class Struggle 2001
>
>
> Dear Gobo Project enthusiasts,
>
> Like every year since 1997, NICE will organize the Eiffel
> Class Struggle 2001. It was suggested in a recent discussion
> in the Board of NICE that a Gobo theme for the contest this
> year would be a good idea. Here is an excerpt:
>
> > Whats about the following:
> >
> > 1. Nice will organize the ECS 2001
> > 2. ECS 2001 will ask for Libraries or tools supporting or
> extending the new
> > Gobo library
> > 3. The detailled specifications will be set by the Gobo Group within the
> > next Month (End of August)
> > 4. The Gobo Group will be asked to decide who will get the prices
> > 5. Nice will donate 3 prices - 1000, 600 and 400 US$
> > 6. OT will sponsor the contest with licenses
> > 7. we will ask other companies  to sponsor also
> > 8. The Gobo goup will be asked to help to formalise this announcement
>
> I would like to know what's your opinion about this
> proposal. Apart from the following kind of answers:
> "Yeah, that's great!", what I'm really interested in
> is whether there are people in this group who will be
> ready to spend time as a judge in order to achieve
> point 4. when it will be time to do so. Although I
> appreciate NICE's suggestion, I'm indeed not willing
> (and won't have time) to do all the judging of the
> Eiffel Struggle alone. I think that the criteria used
> to judge the entries will be more or less the same
> as the previous years, but they will have a new
> category assessing whether the tool or library follows
> the Gobo developer guidelines and how easily it can
> be integrated into the overall Gobo package.
>
> PS: I'm sorry I still didn't have time to work on
> the Gobo developer guildelines document, but I promise
> I will do it as soon as time permits.
>
> --
> Eric Bezault
> mailto:er...@go...
> http://www.gobosoft.com
>
>
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> http://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop

Re: [gobo-eiffel-develop] Eiffel Class Struggle 2001

[Berend de B. <be...@po...>]

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

> I would like to know what's your opinion about this
> proposal. 

Isn't it too early? We still need the Gobo guidelines, review them,
and for example eposix isn't `ported' at all.

I think the basic idea might be a good thing for Gobo (awareness), but
let's wait another year.

-- 
Groetjes,

Berend. (-: