gobo-eiffel-develop — Development discussions

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

[Frieder M. <fm...@ob...>]

At 12:47 28.07.2001 -0700, Joseph wrote:
>I actually kind of like this idea as well.
>
>This relates to my concern about libraries vs. applications.  Applications
>have always been a big part of the EiffelStruggle entries and if we

.. I wonder why you start to discuss these things now, not 2-3 month ago, when
I suggested the "Gobo centration".  At this time there was no reaction at 
all - and
I understood this as "silence acceptance"

Ok, lets start to discuss:

I think that

1. a useful library is the last chance Eiffel has.
2. it still has this chance
3. the extended Gobo is the only serious attempt which may (with much luck 
and much support)
    I can see to be this library.

I started the class struggle some years ago .. and I see that it is scaling 
down - the
quality of the entries becomes .. (ok, no comment). And the last years winner
has made no attempt to continue the "tradition" to organize the next one. 
So, to
some extent "Class Struggle" is death.

The idea behind the class struggle was to support Eiffel.To tell the truth,
how specialized and isolated applications (and even libraries) support 
Eiffel in these days ?

I am firmly convinced that Nice should signal the future direction - and 
that Nice should
spend money only in activities supporting Eiffel and Eiffel usage.

Thats the reason I ask Nice to "revive" the Class Struggle with new Rules - 
and a new target:
not more and not less as to "help Gobo to grow and to save Eiffel".






--
Frieder Monninger
Object Tools GmbH

fm...@ob...  ---  http://www.object-tools.com
Nordstr. 5 - D 35619 Braunfels - fon +49 6472 911 030 fax 031

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

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

[Andreas L. <no...@sb...>]

On Wed, 25 Jul 2001, Ian Elliott wrote:

> Andreas
> 
> Thanks for agreeing to test Fresco. I have tried to email you but my
> message bounced. Please get in touch direct to let me know where to send
> you details.

Hmmm, Eric had the same problem. I am going to look into it. For now you
can use ale...@ma.... 

Sorry for the inconvenience,
Andreas

[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

[gobo-eiffel-develop] Fresco

[Ian E. <ia...@no...>]

Andreas

Thanks for agreeing to test Fresco. I have tried to email you but my
message bounced. Please get in touch direct to let me know where to send
you details.

Regards, Ian Elliott

[gobo-eiffel-develop] Fresco

[Ian E. <ia...@no...>]

Last month I talked about Fresco Formatter - a source code formatter for
Eiffel that runs on Windows. I made the offer of a free user license to
Gobo team members if they'd beta test Fresco. Fresco is ready for
testing. Would those interested team members email me and I'll send them
details. I am going to be unavailable from 27th July for two weeks, so
let me know as soon as you can.

In my last email on the subject I mentioned a goboesque style spec in
the package that the formatter uses to format very closely to the layout
guidelines given in the Gobo guidelines. I have made some additions to
this to bring its formatting closer in line with existing gobo sources.
I have also developed a gobo_check style speck which checks for
adherence to a common syntax subset across the 4 Eiffel compilers. This
may not be total but covers such things as use !! (and not "create"), do
not use language extensions such as tuples, active expressions etc,
terminate class with class comment, include ";" to separate items in an
export list (to satisfy SmallEiffel). It also flags violations of some
of the additional Gobo style guidelines - such as whether indexing is in
correct format, feature clauses are commented and a few others.

Regards Ian Elliott

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] (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/

Re: [gobo-eiffel-develop] UC_CHARACTER_REF compilable with all Eiffelcompilers

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

majkel kretschmar wrote:
> 
> you can add all the changes to the CVS, so it will be working for all
> tested compilers.

Done.

> btw, yesterday i have got a copy of "Unicode: A primer". i'll study it
> and will see, which features should be implemented to be an useful
> unicode library. at the first, the following things should be modified:
> - UC_STRING should only deal with UC_CHARACTERs, not longer with STRINGs
> and   CHARACTERs. these depend on an encoding, and assuming it to be
> ISO-8859-1 is bad   design.

Hmmm, what about adding a precondition `is_ascii' to the
routines which return a CHARACTER or STRING? For characters
with code greater than 127 then indeed:

> - instead, i'll create some encoders/decoders, doing the job of
> translation from an 

might be a solution.

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

Re: [gobo-eiffel-develop] UC_CHARACTER_REF compilable with all Eiffelcompilers

[majkel k. <maj...@ep...>]

Eric Bezault wrote:
> Majkel,
> 
> I noticed that UC_CHARACTER_REF could not be compiled with
> some Eiffel compilers. When I first tried to compile it with
> ISE Eiffel, `Maximum_character_code' and `Minimum_character_code'
> are not in class PLATFORM. We have to use KL_PLATFORM instead.
looking at the elks95 specification, it should be contained in platform.
(http://www.gobosoft.com/eiffel/nice/elks95/platform.html) the problem
for me seemed to be that some compilers have ANY (directly or
indirectly) inherit from PLATFORM and others not.

> Furthermore, STRING.insert_character is not in ISE Eiffel.
but it is in ELKS95. also STRING.make_from_string.

> It was used to implement `as_hexadecimal'. So I decided to
> implement a similar routine in KL_INTEGER_ROUTINES (although
> I didn't try yet if it works as expected) so that
> `as_hexadecimal' could call this new (portable) routine
> instead. Then when I compiled with Halstenbach 3.0 I also
> noticed that STRING.make_from_string was not a creation
> routine. 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.
> 
> My modified version of UC_CHARACTER_REF now compiles with
> all Eiffel compilers. Can I commit it to CVS?

thank you for testing UC_STRING and co on other compilers. writing the
classes, i had a printed out copy of the ELKS 95 at my site. it's a
pitty that you even can't expect the different compilers to be
implementing basic features.

you can add all the changes to the CVS, so it will be working for all
tested compilers. i think, at least the interface of UC_* classes should
follow the ELKS standards; if we can't follow the ELKS in the features
definitions, we have to find other ways to do so.

btw, yesterday i have got a copy of "Unicode: A primer". i'll study it
and will see, which features should be implemented to be an useful
unicode library. at the first, the following things should be modified:
- UC_STRING should only deal with UC_CHARACTERs, not longer with STRINGs
and   CHARACTERs. these depend on an encoding, and assuming it to be
ISO-8859-1 is bad   design.
- instead, i'll create some encoders/decoders, doing the job of
translation from an 
  encoding to unicode and vice versa.
- implement more features from the upcoming ELKS 2001. as you have seen,
it is   located in a separate directory and should be put before the
unicode cluster. this   will work for SE and is thought at the moment
for testing purposes only.

any further suggestions? i'll post my suggestions about future
directions of UC_STRING later this week to the newsgroup


--
maj...@ep...

[gobo-eiffel-develop] UC_CHARACTER_REF compilable with all Eiffel compilers

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

Majkel,

I noticed that UC_CHARACTER_REF could not be compiled with
some Eiffel compilers. When I first tried to compile it with
ISE Eiffel, `Maximum_character_code' and `Minimum_character_code'
are not in class PLATFORM. We have to use KL_PLATFORM instead.
Furthermore, STRING.insert_character is not in ISE Eiffel.
It was used to implement `as_hexadecimal'. So I decided to
implement a similar routine in KL_INTEGER_ROUTINES (although
I didn't try yet if it works as expected) so that
`as_hexadecimal' could call this new (portable) routine
instead. Then when I compiled with Halstenbach 3.0 I also
noticed that STRING.make_from_string was not a creation
routine. 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.

My modified version of UC_CHARACTER_REF now compiles with
all Eiffel compilers. Can I commit it to CVS?

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

Re: [gobo-eiffel-develop] Adding tree support to gobo

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

Einar Karttunen wrote:
> 
> > > I changed the naming to a more eiffelish format. Hope you like
> > > DS_LINKED_BINARY_SEARCH_TREE instead of DS_LBST.
> >
> > I sounds better indeed.
> But is not so nice to write...

Remember that you are writing reusable library classes:
"write once, read many times..."

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

Re: [gobo-eiffel-develop] Adding tree support to gobo

[Einar K. <eka...@cs...>]

On Tue, 10 Jul 2001, Eric Bezault wrote:

> Einar Karttunen wrote:
> >
> > I changed the naming to a more eiffelish format. Hope you like
> > DS_LINKED_BINARY_SEARCH_TREE instead of DS_LBST.
>
> I sounds better indeed.
But is not so nice to write...

>
> > > There is a 'end' missing after `set_parent'. BTW, the name
> > Small eiffel doesn't complain for this,
>
> There was no warnings or anything like that?
none. It complains that copy is deferred in DS_SPLAY_TREE but nothing
else.

> PS: Don't be put off by my remarks about programming styles.
> I'm from a school of thoughts where it is considered that
> cosmetics matters as much as functionality in reusable
> library classes (see OOSC2 page 875). Sven Ehrke is already
> one of my martyrs ;-)
>
No problem. Ny backround is in C++ and perl, which I think both are very
cosmetic indeed. However I have noticed that the eiffel(ish|que) way of
doing things has many advantages.

I will probably next work on implementing pre/postorder cursors.

- Einar Karttunen

Re: [gobo-eiffel-develop] Adding tree support to gobo

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

Einar Karttunen wrote:
>
> I changed the naming to a more eiffelish format. Hope you like
> DS_LINKED_BINARY_SEARCH_TREE instead of DS_LBST.

I sounds better indeed.

> > There is a 'end' missing after `set_parent'. BTW, the name
> Small eiffel doesn't complain for this,

There was no warnings or anything like that?

> There is a new version in the same place, with hopefully better naming
> convention and a few bugs less. There are also short forms of the classes
> available.

I'll try to have a look at it.
Thank you for your effort.

PS: Don't be put off by my remarks about programming styles.
I'm from a school of thoughts where it is considered that
cosmetics matters as much as functionality in reusable
library classes (see OOSC2 page 875). Sven Ehrke is already
one of my martyrs ;-)

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

Re: [gobo-eiffel-develop] Adding tree support to gobo

[Einar K. <eka...@cs...>]

> > Cursor validity is also a problem, when a tree is rotated then all/none
> > of the cursors are must be invalidated because keeping track of cursors
> > any other way would result in a very slow container.
> > If someone has time please check the alpha out
> > (http://beeblebrox.edu.hel.fi/~einar/tree). It needs much
> > refining, but should have some of the basic functionality.
>
> I didn't look at the functionality yet, but from what I
> saw it looks like you don't like routine header comments.
> Also your class text is indented with a mix of tabs and
> spaces. Are you using Emacs? (Berend: no pin intended, well
> just a bit ;-))
Yes I am using emacs. There are few routine header comments because I
except the code to change and this is an alpha version.

> There is definitely a problem with the names you chose
> for your classes and features. In Eiffel it is good
> practice to avoid abbreviations, so BT and LBST don't
> sound very Eiffelish. I think that `delete' is better
> than `del' as a feature name. What does `p_t' mean (well,
> I found out by reading the implementation, but with such
> a cryptic feature name, with no header comments and no
> assertions, hmmm...)? Also `get' as a feature name should
> be prohibited.
I changed the naming to a more eiffelish format. Hope you like
DS_LINKED_BINARY_SEARCH_TREE instead of DS_LBST. The cryptic
feature names, were internal features (inside feature {NONE})
which will probably change in future.

> There is a 'end' missing after `set_parent'. BTW, the name
Small eiffel doesn't complain for this, so I accidentally missed it.

There is a new version in the same place, with hopefully better naming
convention and a few bugs less. There are also short forms of the classes
available.

ps. sorry for the bad english.

- Einar Karttunen

Re: [gobo-eiffel-develop] Adding tree support to gobo

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

Einar Karttunen wrote:
> 
> Currently have minimal alpha implementations of binary search trees and
> splay trees. There are small problems with cursors however. The library
> doesn't seem to like a structute supporting multiple cursor (it results
> in problems with next_cursor etc). Does anyone know a solution to this.

What's wrong with the solution I suggested to you in
this mailing list 2 weeks ago?

> Cursor validity is also a problem, when a tree is rotated then all/none
> of the cursors are must be invalidated because keeping track of cursors
> any other way would result in a very slow container.
> If someone has time please check the alpha out
> (http://beeblebrox.edu.hel.fi/~einar/tree). It needs much
> refining, but should have some of the basic functionality.

I didn't look at the functionality yet, but from what I
saw it looks like you don't like routine header comments.
Also your class text is indented with a mix of tabs and
spaces. Are you using Emacs? (Berend: no pin intended, well
just a bit ;-))

There is definitely a problem with the names you chose
for your classes and features. In Eiffel it is good
practice to avoid abbreviations, so BT and LBST don't
sound very Eiffelish. I think that `delete' is better
than `del' as a feature name. What does `p_t' mean (well,
I found out by reading the implementation, but with such
a cryptic feature name, with no header comments and no
assertions, hmmm...)? Also `get' as a feature name should
be prohibited.

In addition to header comments, it is also good pratice
to put tags to assertions.

Class DS_BT_NODE_SPLAY is not syntactically correct:

------------------
inherit
   DS_BT_NODE[G]
      redefine set_parent
creation
------------------

There is a 'end' missing after `set_parent'. BTW, the name
of this class sounds weird. Are instances of this class
nodes or splays? From the inheritance clause it seems that
they are nodes, so the name should be DS_BT_SPLAY_NODE.

Class DS_BT_NODE: when possible use `make' as the name of
the creation routine, even if it means having two routines
which apparently have the same implementation. For example:

  make (v: G) is
           -- Create a new node.
     require
          v_not_void: v /= Void
     do
          set (v)
     ensure
         item_set: item = v
     end

`find_leftmost_child' is not a good name for a function.
Verbal names should be used from procedures or boolean
queries. I suggest `leftmost_child' instead.

Invariant:
  valid_item: item /= Void
A better tag is:
  item_not_void: item /= Void

Class DS_BT, there is a syntax error:

------------------
inherit
   DS_LINEAR [G]
      rename new_cursor as new_inorder_cursor
feature -- traversal cursors
------------------

There is a 'end' missing after `new_inorder_cursor'.

PS: If you are looking for a good book to read this
summer, I would suggest OOSC2 by B. Meyer.

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

Re: [gobo-eiffel-develop] Adding tree support to gobo

[Einar K. <eka...@cs...>]

Hello

Currently have minimal alpha implementations of binary search trees and
splay trees. There are small problems with cursors however. The library
doesn't seem to like a structute supporting multiple cursor (it results
in problems with next_cursor etc). Does anyone know a solution to this.
Cursor validity is also a problem, when a tree is rotated then all/none
of the cursors are must be invalidated because keeping track of cursors
any other way would result in a very slow container.
If someone has time please check the alpha out
(http://beeblebrox.edu.hel.fi/~einar/tree). It needs much
refining, but should have some of the basic functionality. I will be
completing these classes and adding red-black trees in a couple of weeks.
When you notice something to correct please send me email.

- Einar Karttunen

Re: [gobo-eiffel-develop] Progress report

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

Eric Bezault wrote:
> 
> I can get DocBook compliant XML files, which then converted to
> PostScript look like that:
> 
>    http://gobo-eiffel.sourceforge.net/book.ps
> 
> (I guess you'll need to download this file and view it
> with Ghostview for example.)

Geoff has converted this PostScript file to PDF (which
is much smaller for downloading):

   http://gobo-eiffel.sourceforge.net/book.pdf

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

[gobo-eiffel-develop] Progress report

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

Here is a small report of where we are now in the
Gobo project:

* Unicode
---------

As you may already know, Majkel has ready committed his
UC_STRING and UC_CHARACTER classes to CVS. We still need
to finish the "Gobo-nization" of these classes and add
some getest testcases and docs.

>From the log activity I could see in CVS, it seems that Majkel
is currently trying to convert UC_STRING in order to support
the forthcoming ELKS 2001 STRING interface. Is that correct
Majkel?

* Gobo Eiffel Ant (geant)
-------------------------

'geant' is a build tool similar to Jakarta's 'ant'. It is
developed by Sven. The current state of 'geant' has already
been committed in CVS (in gobo/src/geant). 'geant' is still
under development and the technical discussions are 
hosted in eXML mailing list:

   http://groups.yahoo.com/group/exml/

I already helped Sven "Gobo-nizing" his classes (added
assertions, added header comments, changed class and
feature names, improved Eiffel portability, class
layout, etc.).

* XACE and eXML
---------------

XACE is an XML language currently designed by Andreas which
can be considered as the next generation Ace file language.
It is a portable way to describe Eiffel systems and clusters
from which we can generate Eiffel compiler native Ace files
or ESD files using the companion tool 'gexace'.

Andreas is also Gobo-nizing his eXML library in order to 
commit it to Gobo's CVS. We are currently extracting
general purpose classes from eXML and putting them in
more general libraries/clusters in Gobo. For example
we already extracted from abstract classes describing
the Bridge Pattern. For that we created a new Gobo Eiffel
library (the Gobo Eiffel Pattern Library) and we added
the cluster gobo/library/pattern/bridge to CVS. I also
plan to move my 'command' cluster from gobo/library/utility
into this Pattern library as well. Other cluster candidates
for this new library are Singleton (often discussed in
comp.lang.eiffel), Subject/Observer pattern, etc.
Berend also got the authorization from JM Jezequel to
borrow some of pattern classes from his book "Design Patterns
and Contracts" (we can possibly add some missing assertions
as already stated by Roger when the book was published).

Another Gobo library that we want to create in order to
extrat general classes from eXML is a Gobo Eiffel String
Library. We already found four main categories of routines:
splitting strings, concatenating strings, string substitutions
and string conversions (from C to Eiffel strings for example).
I may ask native English speaking people for help in the 
next few weeks in order to find good names for these classes.
Stay tuned.

Andreas is currently on vacation, but you can read about
XACE and eXML in the eXML mailing list archive:

   http://groups.yahoo.com/group/exml/

* GoboDoc
---------

I managed to convert 4 pages from the Gobo Data Structure
doc to XML. Following Frieder's advice, I learnt about
XML, XSL, Schema, etc. and I wrote an XML Schema which is
a very small subset of DocBook with some Gobo specific
extensions (to handle Eiffel classnames, featurenames
for example). This Schema is not complete. I just put
in there constructs that I needed so far. I wrote two
XSLT files: one to convert the XML GoboDoc files to HTML
and another to convert to DocBook format. These files
can be found in CVS at:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gobo-eiffel/gobo/doc/misc/

The four files that I already converted to XML GoboDoc
are those with a .xml extension in:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gobo-eiffel/gobo/doc/structure/

Following Berend's and Alexander's advice, I used Xalan
to process these files. Here are the command-lines to
convert to HTML:

-----------------------------------------------
TestXSLT -IN %GOBO%\doc\structure\index.xml
     -XSL %GOBO%\doc\misc\gobo2html.xsl
     -OUT index.html
     -PARAM previous '../license.html'
     -PARAM next '../time/index.html'
     -PARAM toc '../index.html'
TestXSLT -IN %GOBO%\doc\structure\terminology.xml
     -XSL %GOBO%\doc\misc\gobo2html.xsl
     -OUT terminology.html
     -PARAM previous 'index.html'
     -PARAM next 'container.html'
     -PARAM toc 'index.html'
TestXSLT -IN %GOBO%\doc\structure\container.xml
     -XSL %GOBO%\doc\misc\gobo2html.xsl
     -OUT container.html
     -PARAM previous 'terminology.html'
     -PARAM next 'traversal.html'
     -PARAM toc 'index.html'
TestXSLT -IN %GOBO%\doc\structure\traversal.xml
     -XSL %GOBO%\doc\misc\gobo2html.xsl
     -OUT traversal.html
     -PARAM previous 'container.html'
     -PARAM next 'sort.html'
     -PARAM toc 'index.html'
-----------------------------------------------

The resulting HTML files can be found in:

http://gobo-eiffel.sourceforge.net/structure/index.html
http://gobo-eiffel.sourceforge.net/structure/terminology.html
http://gobo-eiffel.sourceforge.net/structure/container.html
http://gobo-eiffel.sourceforge.net/structure/traversal.html

As you can see they look pretty much the same as before.
But now the big advantage is that the files are in XML,
so now when I use the following commands:

-----------------------------------------------
TestXSLT -IN %GOBO%\doc\structure\index.xml
     -XSL %GOBO%\doc\misc\gobo2db.xsl
     -OUT xml\index.xml
TestXSLT -IN %GOBO%\doc\structure\terminology.xml
     -XSL %GOBO%\doc\misc\gobo2db.xsl
     -OUT xml\terminology.xml
TestXSLT -IN %GOBO%\doc\structure\container.xml
     -XSL %GOBO%\doc\misc\gobo2db.xsl
     -OUT xml\container.xml
TestXSLT -IN %GOBO%\doc\structure\traversal.xml
     -XSL %GOBO%\doc\misc\gobo2db.xsl
     -OUT xml\traversal.xml
-----------------------------------------------

I can get DocBook compliant XML files, which then converted to
PostScript look like that:

   http://gobo-eiffel.sourceforge.net/book.ps

(I guess you'll need to download this file and view it
with Ghostview for example.)

I think that this proof of concept is encouraging and I will
continue converting the remaining HTML files of the Gobo
doc to XML GoboDoc.

* Gobo Developer Guidelines
---------------------------

I'm sorry I didn't take time to update the first draft of this
document yet. Actually I wanted to see how far I could go with
converting the Gobo doc to XML before proceeding with the
guidelines because I will try to write it with the GoboDoc format.
Also, these guidelines will depend on how far we can go with
the development of the 'geant' and 'gexace' tools, so we'll
need to wait a little bit for that.

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

Re: [gobo-eiffel-develop] UC_STRING.is_empty

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

majkel kretschmar wrote:
> 
> how long will it take nice to decide? will it be some weeks or months?

It looks like ELKS2001 class STRING is almost ready, but I
don't know how long it will take to finish it.

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

Re: [gobo-eiffel-develop] UC_STRING.is_empty

[majkel k. <maj...@ep...>]

Eric, 

looking for the latest draft, i found that there was a final draft
written for ELKS2001 STRING. what about the nice decision? it is not
stated on the official nice pages.

starting the project in 1999, i wanted to base my uc_string code upon
the new nice standard, but i had to wait years for it becoming
available. so i decided to wait until the new standard will be accepted
by nice. 

how long will it take nice to decide? will it be some weeks or months?
if it is accepted, i'll change the code to be ELKS2001 conformant (first
checking whether SE, ISE, and Visual Eiffel will follow the proposal).
if it will take more time, i'll add some additional feature names (eg.
is_empty), and will mark the old ones later as obsolete.

if you now about nice accepting ELKS2001-STRING, please send me the
reference.

Eric Bezault wrote:

> Majkel,
> 
> NICE has decided to have the feature `is_empty' instead of
> `empty' is class STRING. Sven Ehrke has suggested that it
> would be nice if UC_STRING also had a feature named `is_empty'.
> Therefore, would it be possible to add this routine to  UC_STRING,
> and possibly make the old routine `empty' obsolete (do you know
> about the 'obsolete' Eiffel keyword?)?

--
maj...@ep...

[gobo-eiffel-develop] UC_STRING.is_empty

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

Majkel,

NICE has decided to have the feature `is_empty' instead of
`empty' is class STRING. Sven Ehrke has suggested that it
would be nice if UC_STRING also had a feature named `is_empty'.
Therefore, would it be possible to add this routine to  UC_STRING,
and possibly make the old routine `empty' obsolete (do you know
about the 'obsolete' Eiffel keyword?)?

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

Re: [gobo-eiffel-develop] Suggestion for getest

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

>   -g for testcase generation only
>   -c for testcase compilation only
>   -e for testcase execution only
>

Perfect. Thanks Eric.

>PS: This is only the first version of 'getest', therefore there
>are probably things to be improved. In particular new assertion
>checks could be added to TS_ASSERTION_ROUTINES. Suggestions
>welcome.
>

As a first version, it is very good and very useful. I look forward to any 
enhancements.

I did find it difficult to get it working with ISE Eiffel under Win2K, even 
with Cygwin. The problems involved getting the multiple steps of compilation 
going. In the end I had to write a shell script to do the ec and 
finish_freezing steps and copy the resulting executable out of EIFGEN. I'll 
send more details when I have settled it down.

Glenn.

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Re: [gobo-eiffel-develop] Suggestion for getest

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

Dear Glenn,

> Would it make sense to add a command line option to getest to just execute
> the "Preparing Test Cases" step rather than all of the steps at once? In
> fact, an option to run each of the steps selectively would be useful.
> 
> This would make is easier to develop test harnesses using an IDE, such as
> EiffelBench. I could then develop the test harness code in the IDE, generate
> the test harnesses using getest and execute the test harness in the IDE.

As I said in the doc of 'getest', I borrowed almost everything
from Jim Weirich's 'eunit' tool. In 'eunit' there are such
command-line options but when I wrote 'getest' I was not sure
whether they were really useful. Well, your message tends to
prove that they are. Therefore I just added the following command
line options to 'getest':

  -g for testcase generation only
  -c for testcase compilation only
  -e for testcase execution only

You can also combine these options, for example '-g -c' will
generate and compile the testcase classes, but not execute it.
Furthermore if none of these new options are specified, it will
be equivalent to '-g -c -e' for backward compatibility purposes.
(Please note that my command-line parser in 'getest' is very
rudimentary and therefore the shortcut '-gc' instead of '-g -c'
or '-gce' instead of '-g -c -e' is not recognized yet.)

In order to take advantage of these new command-line options
you will need to checkout the following class:

  gobo/src/getest/getest.e

from CVS at:

  https://sourceforge.net/cvs/?group_id=24591

and then recompile 'getest' using the Ace files in the directory:

  $GOBO/src/getest

PS: This is only the first version of 'getest', therefore there
are probably things to be improved. In particular new assertion
checks could be added to TS_ASSERTION_ROUTINES. Suggestions
welcome.

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