gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] kernel/io

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

On Wed, Aug 08, 2001 at 04:47:49AM +0200, Eric Bezault wrote:
> Majkel,
> 
> Eric Bezault wrote:
> >  
> > As for files on Mac, I never worked on this platform, but
> > I've been told that new-lines are not represented by a
> > single '%R' character but by the two characters '%L%R'.
> > Do your files have a '%L' before the '%R'?
> 
> I just managed to see a file generated on Mac and it
> seems that you were right: new-lines are represented
> by a single '%R' character. I must say that this is
> making my life much harder since when I read a '%R'
> I will have to read the next character to check whether
> it's a '%N' or not. If it's not then what should I
> do with this character? Not all Eiffel compilers support
> puting back a character to the file, so I will have to
> simulate it, but it will make the other operations
> on files slower since I will have to check whether
> there is a character memorized from the previous
> operation before reading new (chunk of) characters
> from the file.
> 
> I'd like to know what the others think: should
> `read_line' also recoganize '%R' as line separator?
> 
How about making users decide it when compiling gobo?

- Einar Karttunen

Re: [gobo-eiffel-develop] kernel/io

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

Majkel,

Eric Bezault wrote:
>  
> As for files on Mac, I never worked on this platform, but
> I've been told that new-lines are not represented by a
> single '%R' character but by the two characters '%L%R'.
> Do your files have a '%L' before the '%R'?

I just managed to see a file generated on Mac and it
seems that you were right: new-lines are represented
by a single '%R' character. I must say that this is
making my life much harder since when I read a '%R'
I will have to read the next character to check whether
it's a '%N' or not. If it's not then what should I
do with this character? Not all Eiffel compilers support
puting back a character to the file, so I will have to
simulate it, but it will make the other operations
on files slower since I will have to check whether
there is a character memorized from the previous
operation before reading new (chunk of) characters
from the file.

I'd like to know what the others think: should
`read_line' also recoganize '%R' as line separator?

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

Re: [gobo-eiffel-develop] where to place tools ...

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

Majkel,

Sorry again for not answering earlier.

> my unicode classes also use the unicode database
> (ftp://ftp.unicode.org/Public/3.1-Update/UnicodeData-3.1.0.txt) to
> generate the tables containing information about the character's
> category, its mapping to lowercase, uppercase, titlecase, its bidi etc.
> from time to time some properties change and new characters are added.
> 
> currently, the tool is able to generate the 5 class UC_CTYPE_*.e. the
> tool i have written in eiffel (currently it's called uc_table_maker)
> could go to a tool directory to allow users to generate the tables
> itself. it does not belong into the $GOBO/library/kernel/unicode
> directory.

I'm not sure whether we should put the source code of
your tool in $GOBO/src/ or in a new directory in 
$GOBO/work. So far the $GOBO/work directory contains
files/scripts which are used to build a development
or delivery package of Gobo. On the other hand 
$GOBO/src currently contains the source code of tools
which can be useful for Eiffel programmers other than
those who are members of the Gobo development team.
So since your 'uc_table_maker' tool is used to generate
files within the Gobo library and are not meant to
be used outside of the Gobo package, $GOBO/work is
probably the way to go. What about:

   $GOBO/work/tool/uc_table_maker/*

? But I'm not too sure about the name of your tool.
Since it is supposed to generate UC_CTYPE_* classes,
what about renaming it as 'uc_ctype_maker' (this
name was suggested to me by Franck Arnaud) and puting
it into $GOBO/work/tool/uc_ctype_maker/ ?

Does anyone have a better idea for the name of this
tool and where to put it in the Gobo CVS repository?

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

Re: [gobo-eiffel-develop] kernel/io

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

majkel kretschmar wrote:
> 
> as far as i can see, these classes (KL_INPUT_FILE) support reading files
> line by line. you are assuming, that lines are terminated by '%N' or
> '%R%N'. this are the line endings for unix and ms-windows. but
> mac-generated files end with '%R' i think. (i don't have access to or
> work with the Mac, but some pdf-files i read had the line ending '%R').
> so you should change the code to accept '%N', '%R%N', or '%R' as line
> endings.

I thought that PDF files were binary files and not text files.
Was I mistaken?

As for files on Mac, I never worked on this platform, but
I've been told that new-lines are not represented by a
single '%R' character but by the two characters '%L%R'.
Do your files have a '%L' before the '%R'?

By the way, I read in comp.lang.eiffel that you had
trouble with `end_of_file' when reading lines. I don't
think that there is anything new with the KL_INPUT_FILE.
Here is how it works to read a file line by line and
put the lines in a linked list:

  a_file: KL_INPUT_FILE
  a_list: DS_LINKED_LIST [STRING]
  done: BOOLEAN
  ...
  !! a_list.make
  !! a_file.make ("filename")
  a_file.open_read
  if a_file.is_open_read then
     from until done loop
        a_file.read_line
        if a_file.end_of_file then
            if a_file.last_string.count > 0 then
                   -- There was a line with no end-of-line
                   -- separator at the end of the file.
                a_list.put_last (clone (a_file.last_string))
            end
            done := True
        else
            a_list.put_last (clone (a_file.last_string))
        end
     end
     a_file.close
  else
     std.error.put_string ("Could not open file")
  end

There is another example of reading files line by line
in $GOBO/library/test/harness/ts_assertion_routines.e
in routine `assert_files_equal' where two files are
compared line by line. It looks more complicated at
first because of the error messages, but the traversal
is actually simpler.
               
-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

[gobo-eiffel-develop] kernel/io

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

Eric Bezault wrote:
> Eric Bezault wrote:
> >
> > I'm currently working on the following additions to
> > Gobo: KL_INPUT_STREAM, KL_INPUT_FILE, KL_OUTPUT_STREAM,
> > KL_OUTPUT_FILE, KL_FILE_SYSTEM, KL_DIRECTORY, ...
> > I hope that this will address your needs.
> 
> These classes (and more) are now available from the Gobo
> CVS repository. For details, see my message at:

Eric,

as far as i can see, these classes (KL_INPUT_FILE) support reading files
line by line. you are assuming, that lines are terminated by '%N' or
'%R%N'. this are the line endings for unix and ms-windows. but
mac-generated files end with '%R' i think. (i don't have access to or
work with the Mac, but some pdf-files i read had the line ending '%R').
so you should change the code to accept '%N', '%R%N', or '%R' as line
endings.

--
maj...@ep...

Re: [gobo-eiffel-develop] Cross compiler compatibility of libraries (was Eiffel Class Struggle 2001)

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

Eric Bezault wrote:
> 
> I'm currently working on the following additions to
> Gobo: KL_INPUT_STREAM, KL_INPUT_FILE, KL_OUTPUT_STREAM,
> KL_OUTPUT_FILE, KL_FILE_SYSTEM, KL_DIRECTORY, ...
> I hope that this will address your needs.

These classes (and more) are now available from the Gobo
CVS repository. For details, see my message at:

  http://groups.yahoo.com/group/gobo-eiffel/message/300

I'm still in Santa Barbara after TOOLS USA last week,
so I was only able to test these classes on my laptop
under Windows NT. But I see no reason why they wouldn't
work on other platforms.

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

RE: [elj-win32-dev] RE: [gobo-eiffel-develop] Gobo-izing the Clas s Struggle

[Monks, P. <pm...@vi...>]

G'day!

I don't know who wrote this (Sven didn't mention it when he on-posted
it to the ELJ developers list):

> I think it's a good idea for the Class Struggle to encourage the Open
> Source model, but some people might object to hanging their code onto
> sourceforge or other CVS repository. 
> 
> For example, if I have low-grade access to the Internet (slow-dem
> dialup or even better, public library kiosks) this could completely 
> eliminate my participation.

...but I thought I'd reassure them about CVS over dial-up.

I access the ELJ SourceForge repository via dial-up all the time, and
it works fine for me.  Typical CVS update operations for the entire
repository take no more than five minutes or so on a 46.6Kb dialup
(and I'm located in Australia, not the US).  Commits are usually much
faster, although that's probably because I'm only working on a limited
set of files.

I'm also acccessing SourceForge via an SSH client (which is noticably
slower than pserver access), and the ELJ repository now contains over
1000 files!

I should mention that I initially populated my local workspace while
on a corporate network, so YMMV if you attempt to do a full population
via dial-up.

Anyway this is just my $0.02 worth - I initially didn't think
SourceForge access via dial-up would be practical either, but I've
been very pleasantly surprised.  Being able to develop on any Internet
connected machine is also great - no more floppy disk shuffling.

Cheers,
Peter

----------------------------------------------------------------------
Peter Monks                             http://www.sydneyclimbing.com/
pm...@sy...      http://www.geocities.com/yosemite/4455/
----------------------------------------------------------------------

RE: [gobo-eiffel-develop] Gobo-izing the Class Struggle

[Sven E. <sve...@we...>]

> I think it's a good idea for the Class Struggle to encourage the Open
> Source model, but some people might object to hanging their code onto
> sourceforge or other CVS repository. 
> 
> For example, if I have low-grade access to the Internet 
> (slow-dem dialup
> or even better, public library kiosks) this could completely 
> eliminate my
> participation.

It would definitely be the wrong way if the proposed criteria would make
participation impossible for certain projects. That's why I said in another
mail today that it could be seen as a 'Plus' and not as a criteria (maybe someone
can find a better term).

> Or if my project is relatively small, I may not want to
> take on all of the administrative overhead of a Sourceforge 
> project (or
> subproject).

That's absolutely true.
Those people could (if they want to) send source snapshots 
to the administrator of such an overall project hosting these subprojects.
To reduce administration labor those would just be available for download
and not through cvs.

> 
> There's something else I've been wondering about; right now I 
> know of two
> major library efforts going on in the Eiffel world; Gobo and 
> ELJ. While
> the projects have different goals and requirements, there may be some
> opportunities for synergy. In particular, if the two groups adopted
> similar coding standards, it could be of great benefit. It could allow
> easy sharing of low-level clusters and such.

As I already mentioned in another mail today goanna and gobo already benefit
from each other. Since I am partly involved in gobo and elj development I am
currently trying to let elj profit from GOBO as much as possible.

- Sven Ehrke


______________________________________________________________________________
Jetzt und nur hier Ihr original PREMIERE WORLD SportPaket 
plus 100 Euro ExtraPramie: http://premiere.web.de

Re: [gobo-eiffel-develop] Cross compiler compatibility of libraries (was Eiffel Class Struggle 2001)

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

Cheng-Chang Wu wrote:
> 
> Wonderfull. When can we have it ^_^

I hope that the CVS version of Gobo (no plan for official
release yet) will be able to provide these classes before
the end of the month (even earlier if everything goes well).

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

[gobo-eiffel-develop] open source / eiffel struggle

[Sven E. <sve...@we...>]

> -----Original Message-----
> From: franck [mailto:fr...@ne...]
> Sent: Thursday, August 02, 2001 10:37 PM
> To: gobo-eiffel-develop
> Cc: franck
> Subject: [gobo-eiffel-develop] open source / eiffel struggle


> I reckon being open source has always been a condition of entry. 
> The condition applied to entries when they are submitted, so 
> it does not prevent people for developing on their own 
> before submitting.

This is true, but it is quite late in a process, worst
case: one year after the last struggle. If people are developing
'general useful functionality' it would be great if that would be
known earlier.
Eiffel libraries should profit from each other and this should
not happen in yearly steps but continuous.
Fortunately it already happens today: look at goanna, exml and
gobo for example.

> 
> I don't know if it is possible or desirable to push to 
> being open before submitting. In any case, I don't think 
> it's enforcable (if you put code in a public CVS repository, 

It's not enforcable of course and I do not want to enforce
anything. It would just help. So if most people think having it
as a criteria would be strong it could be called a 'plus' for example.

> I don't think anybody is going to look at it anyway unless the 
> project is otherwise publicised and organised).

I do not agree here. ELJ-daily for example does a very good job in
providing news for the Eiffel community and I look at new
Eiffel software if it is interesting for me. It could
contain functionality which is useful for me.
If that's the case I try to get parts of it into other libraries. This just happens with a
goanna library which will find its way into the gobo library soon.
And this happens before class struggle ;-)

- Sven Ehrke

______________________________________________________________________________
Sie surfen im Internet statt im Meer? Selbst schuld!
Auf zum Strand: http://lastminute.de/?PP=1-0-100-105-1

Re: [gobo-eiffel-develop] Cross compiler compatibility of libraries (was Eiffel Class Struggle 2001)

[Cheng-Chang W. <che...@ya...>]

Wonderfull. When can we have it ^_^

Cheng-Chang Wu

> I'm currently working on the following additions to
> Gobo: KL_INPUT_STREAM, KL_INPUT_FILE, KL_OUTPUT_STREAM,
> KL_OUTPUT_FILE, KL_FILE_SYSTEM, KL_DIRECTORY, ...
> I hope that this will address your needs.
> 
> -- 
> 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


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [gobo-eiffel-develop] Cross compiler compatibility of libraries (was Eiffel Class Struggle 2001)

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

Glenn Maughan wrote:
> 
> They sound perfect! Where do you find the time?

During the night ;-)

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

Re: [gobo-eiffel-develop] Cross compiler compatibility of libraries (was Eiffel Class Struggle 2001)

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

Dear Eric,

>
>I'm currently working on the following additions to
>Gobo: KL_INPUT_STREAM, KL_INPUT_FILE, KL_OUTPUT_STREAM,
>KL_OUTPUT_FILE, KL_FILE_SYSTEM, KL_DIRECTORY, ...
>I hope that this will address your needs.

They sound perfect! Where do you find the time?

I have had to revert to ISE specific classes for some of the log4e 
functionality such as rolling log files and the NT event log. It should be 
easy to port to your classes once they are available.

Thanks.
Glenn.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

[gobo-eiffel-develop] Gobo-izing the Class Struggle

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

sve...@ub... wrote:

[...]
 
> So I suggest that software for the cluss struggle should be written
> right from the beginning as open source, available from sourceforge
> for example or any other server preferrably accessible through cvs.
> It does not mean that every entry for the class struggle has to create
> it's own sourceforge project. It could be one project and each entry
> could go in it's own module.
[...]

I think it's a good idea for the Class Struggle to encourage the Open
Source model, but some people might object to hanging their code onto
sourceforge or other CVS repository. 

For example, if I have low-grade access to the Internet (slow-dem dialup
or even better, public library kiosks) this could completely eliminate my
participation. Or if my project is relatively small, I may not want to
take on all of the administrative overhead of a Sourceforge project (or
subproject).

There's something else I've been wondering about; right now I know of two
major library efforts going on in the Eiffel world; Gobo and ELJ. While
the projects have different goals and requirements, there may be some
opportunities for synergy. In particular, if the two groups adopted
similar coding standards, it could be of great benefit. It could allow
easy sharing of low-level clusters and such.

Greg


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

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

[gobo-eiffel-develop] open source / eiffel struggle

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

>These are the criteria to the '98 class struggle (I'm not sure
>if it changed since):

These are the criteria to judge (to be able to rank entries). 
I reckon being open source has always been a condition of entry. 
The condition applied to entries when they are submitted, so 
it does not prevent people for developing on their own 
before submitting.

I don't know if it is possible or desirable to push to 
being open before submitting. In any case, I don't think 
it's enforcable (if you put code in a public CVS repository, 
I don't think anybody is going to look at it anyway unless the 
project is otherwise publicised and organised).

Also I think it's relatively rare to get overlapping entries.
Well, last year they got three entries of fractals but that's 
very much the exception. The other duplicates I can think of 
were evolutions from course assignments from students from the 
same class, so were meant to be duplicates.

-- 
Franck Arnaud ~ email: fr...@ne...

Re: [gobo-eiffel-develop] Cross compiler compatibility of libraries (was Eiffel Class Struggle 2001)

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

Glenn,

I'm currently working on the following additions to
Gobo: KL_INPUT_STREAM, KL_INPUT_FILE, KL_OUTPUT_STREAM,
KL_OUTPUT_FILE, KL_FILE_SYSTEM, KL_DIRECTORY, ...
I hope that this will address your needs.

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

Re: [gobo-eiffel-develop] where to place tools ...

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

Majkel,

Sorry for not answering earlier: I'm currently
attending TOOLS USA.

> last weekend i did update my classes which are responsible for creating
> the eiffel-unicode-properties (case mapping, category, bidi etc.) from
> the unicode database (version 3.1). where can i place it in cvs? in the
> src tree?

I'm not sure I understand. Are you talking about the
source code of a tool which helps you to generate
some classes in $GOBO/library/kernel/unicode? If so,
is this tool written in Eiffel? What's its name?

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

[gobo-eiffel-develop] Eiffel Class Struggle 2001

[<sve...@ub...>]

Some days ago Frieder wrote:

> I started the class struggle some years ago .. and I see that 
> it is scaling 
> down - the

I always liked the eiffel class struggle because it was one of the
three things (the other ones are elj-daily and the eiffel-forum)
that brought eiffel developers closer to each other.
So I think the class struggle is still important.

But I'd like to see some modifications:

Today I think it is not appropriate anymore that people are
developing software for a year and nobody knows about it until
it appears in the class struggle (BTW: it might not appear at
all since people could think their software is not mature enough
or they were not able to do it all without help).
It could be the case that other people have been working on exactly
the same topic for that year or could have used the code of the other
developer for his own stuff.

So I suggest that software for the cluss struggle should be written
right from the beginning as open source, available from sourceforge
for example or any other server preferrably accessible through cvs.
It does not mean that every entry for the class struggle has to create
it's own sourceforge project. It could be one project and each entry
could go in it's own module.

These are the criteria to the '98 class struggle (I'm not sure
if it changed since):

- How useful is the application or library? 
- How well has it been designed? 
- How attractive is the style? 
- Have object-oriented design principles been applied? 
- How readable is the software? 
- How portable is the software? 
- How much effort has been invested? 

So the open source criteria could be added to this list.


As already suggested another one I would add is

- How much 'GOBO complient' is the software ? 

This way we would support the GOBO project already and
do not have to wait for next year.

- Sven

RE: [gobo-eiffel-develop] Cross compiler compatibility of libraries (was Eiffel Class Struggle 2001)

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

> From: gob...@li...
> [mailto:gob...@li...]On Behalf Of
> Hamish Harvey
> RE: Eiffel Class Struggle 2001 (Glenn Maughan)
>
> > 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
>
> But if I have an application which makes use of polymorphism in these
> classes, I do need the inheritance structure to be correct. In a strongly
> typed language, the inheritance structure is surely an important part of
> compatibility.
>

Yes, you are of course, correct.

I should put my comment in context: In an earlier message I mentioned that I
need
routines for renaming and deleting files to support a rolling log file.
There is
currently no way to do this portable without writing mixin classes.

The interfaces that ISE provides for FILE and IO_MEDIUM are perfect for my
needs.
They are also in the public domain. All I need at this point is the concrete
interface to build my library portably.

Granted it would be nice to have the entire IO_MEDIUM hierarchy available so
that
I can take advantage of polymorphism.

See you.
Glenn.

[gobo-eiffel-develop] where to place tools ...

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

eric,

last weekend i did update my classes which are responsible for creating
the eiffel-unicode-properties (case mapping, category, bidi etc.) from
the unicode database (version 3.1). where can i place it in cvs? in the
src tree?

--
maj...@ep...

[gobo-eiffel-develop] Cross compiler compatibility of libraries (was Eiffel Class Struggle 2001)

[Hamish H. <ha...@ef...>]

RE: Eiffel Class Struggle 2001 (Glenn Maughan)

> 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

But if I have an application which makes use of polymorphism in these
classes, I do need the inheritance structure to be correct. In a strongly
typed language, the inheritance structure is surely an important part of
compatibility.

> that is supports all of the file operations with standard names and
> signatures.

And that it allows me to attach an instance of it to any variable that I can
do with another compiler.

Cheers,
Hamish

[gobo-eiffel-develop] Cross compiler compatibility of libraries (was Eiffel Class Struggle 2001)

[Hamish H. <ha...@ef...>]

RE: Eiffel Class Struggle 2001 (Glenn Maughan)

> 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

But if I have an application which makes use of polymorphism in these
classes, I do need the inheritance structure to be correct. In a strongly
typed language, the inheritance structure is surely an important part of
compatibility.

> that is supports all of the file operations with standard names and
> signatures.

And that it allows me to attach an instance of it to any variable that I can
do with another compiler.

Cheers,
Hamish

[gobo-eiffel-develop] Cross compiler compatibility of libraries (was Eiffel Class Struggle 2001)

[Hamish H. <ha...@ef...>]

RE: Eiffel Class Struggle 2001 (Glenn Maughan)

> 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

But if I have an application which makes use of polymorphism in these
classes, I do need the inheritance structure to be correct. In a strongly
typed language, the inheritance structure is surely an important part of
compatibility.

> that is supports all of the file operations with standard names and
> signatures.

And that it allows me to attach an instance of it to any variable that I can
do with another compiler.

Cheers,
Hamish

[gobo-eiffel-develop] Cross compiler compatibility of libraries (was Eiffel Class Struggle 2001)

[Hamish H. <ha...@ef...>]

RE: Eiffel Class Struggle 2001 (Glenn Maughan)

> 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

But if I have an application which makes use of polymorphism in these
classes, I do need the inheritance structure to be correct. In a strongly
typed language, the inheritance structure is surely an important part of
compatibility.

> that is supports all of the file operations with standard names and
> signatures.

And that it allows me to attach an instance of it to any variable that I can
do with another compiler.

Cheers,
Hamish

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

[Joseph R. K. <ki...@ac...>]

Hi all,

--On Sunday, July 29, 2001 12:26:04 PM +0200 Frieder Monninger 
<fm...@ob...> wrote:

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

You are correct - it was and is still an excellent idea.  After we batted 
it around at NICE we said "let's see how the Gobo folks like this and take 
it from there".  The feedback from the people working very hard on the UEL 
are telling us that perhaps this year is a bit too early to use the 
Struggle to extend a (currently non-existent) UEL.  I don't see this as a 
bad thing, I see it as an opportunity for next year.

> 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 guess I'm not so worried about Eiffel's "last chance".  I see ISE's entry 
into the .Net area as helping out the language more than Struggle ever 
could or UEL will for the next year.

I'm a serious supporter of Eiffel, the idea and execution of a UEL and the 
Struggle.  I'll not only volunteer to judge for the Struggle this year, 
I'll even volunteer to run it if necessary!

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

I didn't know about this tradition.  I'm unsure if recent winners knew 
either.  I had always figured it was a matter of coincidence and passion.

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

If our primary concern is library coverage, then shouldn't we, in the short 
term, focus on providing Eiffel interfaces to popular, multi-platform 
libraries written in arbitrary languages a la EPOSIX?

On a related note, after I finish my current research project(*), I'm going 
to turn to one of the other areas that I mentioned when I ran for the NICE 
board.  I need community feedback to determine which direction to go.

I'm capable and willing to provide a high-quality, complete Eiffel library 
for either (a) distributed systems, (b) 3D graphics, or (c) concurrency.  I 
have performed research in, and written libraries for, all three areas in a 
variety of other languages over the past ten years.  Eiffel needs complete, 
supported versions of all three, so I'm going to help get this done.  If 
anyone has opinions or suggestions, please contact me privately.  BTW, I 
have already done the research to determine what is currently out there in 
Eiffel that supports each of these areas.

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

Rather than those big private NICE beer-bashes? :)

All puns aside, I agree with you here Frieder.  I just am not completely 
convinced that a Struggle+UEL is the right way to go this year.  If the 
people doing the hard work on the UEL were strongly behind the idea, I'd 
stand with them.  If they are less than enthusiastic right now, then we 
just need to find another option.

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

As I mentioned above, I'm ready and willing to participate however the 
community needs me in Struggle this year.  Luckily I'm finishing my 
dissertation in the next few weeks, so the timing is good.

Best,
Joe Kiniry
--
Joseph R. Kiniry                    http://www.cs.caltech.edu/~kiniry/
California Institute of Technology        ID 78860581      ICQ 4344804

(*) A BON+ design model checker for Eiffel that will be submitted to 
Struggle this year whether I run or judge it myself.  I'll be speaking 
about this project briefly at the Eiffel Summit on the morning of the 31st.