gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

[Christian C. <chc...@cl...>]

Eric Bezault wrote:
> 
> Christian Couder wrote:
> >
> > I would rather have a base class using error variables and a derived
> > class (inheriting the base class) with exceptions.
> > Or something like this. I think it's far better than two set of routines
> > (doing essentialy the same thing) in the same class.
> 
> Why not. What do you think about that Berend?
> 
> On the other hand with the first solution that I suggested
> (deciding at creation time of the object if it will raise
> exceptions or if it only uses an error variable) we can have
> only one set of routines which call a `set_last_error'
> routine when an error occur:
> 
>   set_last_error (...) is
>           -- ...
>       do
>           last_error := ....
>           if exeptions_enabled then
>               raise (...)
>           end
>       end

Yes, but every object will have an exeptions_enabled attribute, this
means the size of each object will increase.

Perhaps there should be a global error manager object (a once object)
using an error handler, like this:

class ERROR_MANAGER

feature

   current_error_handler: ERROR_HANDLER;
   default_error_handler: ERROR_HANDLER;

creation make

feature

	 make(error_handler: ERROR_HANDLER) is
		do
			 default_error_handler := error_handler
			 current_error_handler := default_error_handler
		end

	 set_new_error_handler(error_handler: ERROR_HANDLER) is
		do
			 current_error_handler := error_handler
		end

	 reset_error_handler is
		do
			 current_error_handler := default_error_handler
		end
			
	set_last_error(error: INTEGER; error_creator: ERROR_CREATOR) is
		do
			 ...
			 current_error_handler.handle_error(error, error_creator) 
		end
end


The error handler objects could all inherit from the same base class and
do what should be done in case of an error (nothing or raise an exeption
or send a mail or trace the error, ...)

Also the error manager could have a dictionary to save the last error
for each object that had an error. It would save space in each object
since hopefully very few objects will have errors.

Regards,
Christian.

Re: [gobo-eiffel-develop] Introduction: Franck de Bruijn

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

Dear Franck,

> Let me introduce myself. I am Franck and I am completely
> new at Eiffel.

Welcome to the Eiffel community.

> When I saw Eric's posting in the newsgroup that he is
> opening up the Gobo project for others and making it open
> source, I thought that this is a very interesting and very
> good move. I also saw that already one other Eiffel developer
> is willing to stop his work and contribute to this project.
> 
> I have a couple of questions that somebody might be willing
> to answer:

First, I must say that the project is only 3 days old,
so please forgive its lack of maturity.

> * What is the mission of this project?
>   What would you like to accomplish?

The goal of the project is to end up with an open source,
high-quality, compiler-independent and full-fledged Eiffel
library. That's what I always dreamt about when I started
developing Gobo Eiffel 6 years ago. However it is clear 
that I cannot achieve that alone. So when I was pushed
by some fellow Eiffelists to share the "fame" of Gobo
and open its development and include progressively the
Eiffel libraries written by others in order to create
a full-fledged and compiler-portable Eiffel library, I 
thought it was the good time to do it. So with this new
initiative I hope that we will reach this goal in a
reasonable amount of time, while keeping the quality of
the library to a high level.

>   What is the strategy?

First, before opening Gobo to too many libraries at once,
we need to define the "rules". Therefore we are currently
trying to specify some developer guidelines, installation
and build procedures, etc. The first step will be to use
the Unicode library from Majkel Kretschmar, the XML library
from Andreas Leitner and the Posix library from Berend de Boer
as guinea pigs while we are specifying all the guidelines
and try to merge them with the existing Gobo package. 
Reaching this stage will be a proof of feasability, and
to reuse Andreas Leitner's saying, it will be land no
Eiffelist has touched ever before. Hopefully we will be
able to reach this stage in a reasonable amount of time.
Then it will be easy (hopefully) to extend Gobo with many
other contributions with a greater pace since all the
guidelines, frameworks, procedures, etc. will already have
been discussed and put into place.

> * How many people are contributing to this project?
>   I see currently postings from 3 people.

Discussions about the guidelines etc. is open to everyone
interested in taking part into it. Building the first release
of this new Gobo package is currently limited to 4 people
since it is merely the merging of 4 already existing 
packages. When we reach this stage then it will be open
to many more people, but before having too many people
I think it is understandable that we need to specify the
guidelines.

> * Are there any "decision"-structures?
>   I am reading a lot of discussions (it takes me already
>   1 hour to read all the e-mails .... I am also not
>   understanding everything!) and of course I cannot value
>   the importance of these discussions. But it appears to me
>   that there maybe should be some decision-control, saying:
>   "Ok, stop the discussion: these are the options, let's
>   vote" or something like that. 

If we can avoid votes, I think that people would prefer.

>   I get the impression that
>   there is a lot of work ahead and if you start losing your
>   time with endless discussions not much will be realised
>   in the end ...

I agree, but hey, don't say that we are losing our time when
the project is only 3 days old! ;-) Furthermore I prefer that
we take our time to specify good foundations to the project
rather than we go too fast and then have to stop and redo
things later on.

> * What is currently going on in the Gobo project?
>   Which libraries are being taken into account? 

I think that you can have found that out by now if you
read this message until here. Things currently being
discussed: developer guidelines and a portable format
to specify Eiffel system (XACE by Andreas). Berend also
said that he was working on a tool to automatically
generate C compiler specific Makefiles (to compile C
code called from Eiffel external routines).

> Is there
>   any documentation available that I could look at?

The first draft of the developer guidelines can be found in
the mailing list archive.

> I have read some complaints about the (lack of) documentation
> of the libraries being developed by the Eiffel-community. One
> response was to one of these postings, that it was preferred
> to write code instead of documentation.

I prefer to write Eiffel code as well, but from time
to time I think it is important to hurt ourselves and
write some docs, examples and tests.

> I know that OOSC2 proposes the short form for documenting
> classes. I personally think it is just a part of documentation
> that you can cover with that. IMO, I think that you need things
> like "introductions", "user's guides", "installation guides"
> and stuff like that, before a library really gets mature. Of
> course, also a good web page and on-line help with examples
> and stuff are desirable.

Did you have a look at http://www.gobosoft.com and more
precisely at http://www.gobosoft.com/eiffel/gobo ? Is
that what you would expect from a doc or do you need
more? If yes, what? This doc is currently written in
HTML, but in the first draft of the guidelines I suggested
using the DocBook XML format to write docs. It has the
advantage of being able to generate many different output
(HTML, pdf, PostScript, etc.) out of these XML files, and
there are already many tools supporting this format since
it is used to write Linux docs.

You are of course welcome to take part into the discussions
in this mailing list and to contribute Eiffel software
as soon as we reach step 2, or even try to write some
test cases or examples if you think it's a good way to
learn about a given Eiffel library and about Eiffel in
general.

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

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

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

Christian Couder wrote:
> 
> I would rather have a base class using error variables and a derived
> class (inheriting the base class) with exceptions.

The more I think about it, the more I like this solution.
In the parent class the postconditions do not state that
the operation succeeded and the error variable is set on
error, and in the heir class the postcondtions are
strengthened to state that the operation succeeded and
an exception is raised on error.

Berend, what's your opinion about this design? At least
it has the advantage of providing both programming
styles to the clients of this library. I didn't look
at the implementation of your library so I don't know
whether this may cause implementation problems or
involve too much work for you to modify your classes.

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

Re: [gobo-eiffel-develop] Proposal ..

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

Frieder Monninger wrote:
>  
> So its important for them NOT to be supported by Nice. Ok, Nice
> has to accept this. But, will it really kill or even only delay if this
> activity
> is suppoted by Nice ? This will point out that something is wrong with Nice -
> and I want to know, what is wrong.

I don't think that there is a problem being supported by
NICE. What may make people uneasy about NICE though is that,
despite Roger's huge effort (thank you Roger), its process
is horribly slow. In people's mind NICE may mean having to
vote on every single detail...

>  There are as Roger pointed
> out only Nice-supported library project. When such a library project
> is stable (and well equipped with assertions :-) then maybe Nice will
> make a standard from it. 

Yes, why not? So may be we should make a difference between
a library project supported by NICE and a library project
managed by NICE.

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

[gobo-eiffel-develop] Re: [eiffel-nice-board] Proposal ..

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

At 19:57 29.05.2001 +0200, Eric wrote:
>Dear Frieder,
>
>As a member of the Board of NICE I think that you should
>read comp.lang.eiffel from time to time ;-)


thats what I do .. but unfortunately I apparently miss information :-(
>I spoke about our discussion from last week to some
>Eiffelists, and they were not very enthiusastic (to
>say the least) about a library project officially
>hosted and/or sponsored by NICE.


Why ? Of course any one can do what he/she wants ... but whay they
want no contact to nice ? Are there any rational arguments against
some sponsoring from Nice - and against a link in the Nice home page ?

>Between a messy
>bazaar style open source library project


I read the book (you know, which one :-) and I did not have the impression
that this type of projects are messy. I think what this Eric [Raymond] has done
in his project is not the worst way you can do - well controlled, but 
nevertheless
open source and with many contributors.

You (and some others, of course - I would be pleased to cooperate) will set the
rules and standards and control the growing activities.

>It was said that having an open
>library project as you suggested won't work whereas
>having something more controlled and growing
>progressively with new additions has a chance to
>work.

Did they inform themself what open source means ?

>  And if it is works it will be a so great
>achievement in the Eiffel community that it will
>become a defacto standard without having to be
>sponsored by NICE.

So its important for them NOT to be supported by Nice. Ok, Nice
has to accept this. But, will it really kill or even only delay if this 
activity
is suppoted by Nice ? This will point out that something is wrong with Nice -
and I want to know, what is wrong.


>developer guidelines, some way to have a portable
>installation and build procedure with XACE, etc.
>Everyone interested is invited to join the discussion
>at:
>
>   http://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>
>This mailing list is public.

so, it may be legal to put a link to the Nice WEB page ? !!
(I have subscribed this mailing list .. just now)


>PS: Andreas, please feel free to explain your point of
>view with respect to having a semi-controlled progressively
>growing Gobo Eiffel library rather than an official
>NICE library project.

Maybe Andreas did not understand what an official NICE library
project is - in fact such thing does not exist. There are as Roger pointed
out only Nice-supported library project. When such a library project
is stable (and well equipped with assertions :-) then maybe Nice will
make a standard from it. But thats another story.

--
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] Graphviz, Licensing, Tabs

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

Roger Browne wrote:
> 
> > LICENSE
> 
> Perhaps you could consider using the Eiffel Forum License rather than the
> Eiffel Forum Freeware License.

OK. I didn't realize that there were two different licenses.
Perhaps there should have been version 1 and version 2 instead
of both being version 1 in order to make it clearer.

> In the meantime, you can use Franck Arnaud's little utility to:
> 
>    1. Check that lines are indented with tabs, not spaces
>    2. Check that tabs do not appear other than at the start of a line
>    3. Check that double-spaces do not appear within Eiffel text

Sounds great. I didn't remember that Franck already wrote
such checker utility.

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

[gobo-eiffel-develop] Graphviz, Licensing, Tabs

[Roger B. <ro...@ei...>]

> LICENSE
> 
> The files in the Gobo Eiffel package are released under
> the Eiffel Forum Freeware License.

Perhaps you could consider using the Eiffel Forum License rather than the
Eiffel Forum Freeware License.

The EFL arose out of discussions on the "forum-discuss" list last year,
to rework the EFFL so that it could be submitted to OSI for certification
as an "OSI-certified Open Source" license.

The changes are small. Here is the EFL:

   Eiffel Forum License, version 1
   
   Permission is hereby granted to use, copy, modify and/or distribute
   this package, provided that:
   
     - copyright notices are retained unchanged
   
     - any distribution of this package, whether modified or not,
       includes this file
   
   Permission is hereby also granted to distribute binary programs which
   depend on this package, provided that:
   
     - if the binary program depends on a modified version of this
       package, you must publicly release the modified version of this
       package
   
   THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT WARRANTY. ANY EXPRESS OR
   IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
   WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   DISCLAIMED. IN NO EVENT SHALL THE AUTHORS BE LIABLE TO ANY PARTY FOR
   ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
   DAMAGES ARISING IN ANY WAY OUT OF THE USE OF THIS PACKAGE.

Sadly, OSI gives priority to discussing corporate licenses (such as those
from Sun and IBM), and the Eiffel Forum License is still on the waiting
list more than a year after submission. But there is no doubt that the
EFL meets the requirements for OSI certification.

> Graphviz could probably be used to generate class inheritance
> graphs. Graphiz is an open source graph drawing software...

At first I was surprised that you were not suggesting GraVis, which is
more powerful and more elegant than Graphviz, and is written in Eiffel.

Then, I checked the GraVis website again. When Tower dropped their Eiffel
customers, the authors rewrote GraVis in Java. Sad but true.

When it was released in 1977, GraVis was ahead of its time. It we'd had
Gobo cross-vendor libraries back then, it could have been switched to one
of the other Eiffel compilers and we would now have a famous Eiffel
application.

> > And perhaps a sed script to convert existing code to tab format.
> 
> ... I think the
> ! best choice for platform independent language in
> ! the context of the development of Gobo Eiffel
> ! package is ... Eiffel. What do you think?
> 
> If you want to write such tool, please do.

In the meantime, you can use Franck Arnaud's little utility to:

   1. Check that lines are indented with tabs, not spaces
   2. Check that tabs do not appear other than at the start of a line
   3. Check that double-spaces do not appear within Eiffel text

It's released to the public domain, and it's so short that I've just
pasted it in here.

Personally, I prefer indents of 3-spaces, because I've not yet found a
way to tell Netscape that tabs are less than 8 characters (to avoid
line-wrapping). Sure, you can tell emacs that tabls are 3 characters, but
much software is not configurable and assumes 8 characters.

Regards,
Roger

===

-- chktab: Check correct usage of spaces and tabs (in Eiffel)
-- Public Domain (may be copied, modified and sold freely)
--
-- Detected errors:
-- * Tab(s) not at the beginning of line: tabs in the middle of the text 
--   are dependent on user setup and not necessary in Eiffel.
-- * Double spaces are redundant too (spaces at the beginning of lines
are 
--   tabs). Double spaces are ignored inside comments.
--
-- FA 1996-09-24

indexing
        description: "Simple program to check correct usage of tabs and
spaces"
        licence: public_domain
        version: "1996-09"

class CHECK_TAB inherit ARGUMENTS end

creation make
        
feature { NONE }
        
        Usage : STRING is "usage: chktab <in"

feature
        
        make is
                        -- Root procedure.
                do
                        if argument_count > 0 then
                                io.put_string(Usage)
                                io.put_new_line
                        else
                                -- process stdin
                                from
                                        line := 1
                                until
                                        io.end_of_file -- portability
issue
                                loop
                                        io.read_line
                                        check_line(io.last_string)
                                        line := line + 1
                                end
                        end

                end
                
feature { NONE } -- Attribute(s)

        line,column : INTEGER

feature { NONE }
        
        check_line(str : STRING) is
                        -- Check one line.
                require
                        valid_str: str /= Void
                local
                        in_comment : BOOLEAN
                do
                        from
                                column := 1
                        variant
                                str.count + 1 - column
                        until
                                column > str.count
                        loop
                                -- misplaced tabs
                                if column > 1 then
                                        -- detect comment
                                        if str.item(column) = '-' and
str.item(column-1) = '-' then
                                                in_comment := true
                                        end
                                        
                                        -- tabs
                                        if str.item(column) = '%T' and
str.item(column-1) /= '%T' then
                                                error("tab(s) not at the
beginning of line")
                                        end

                                        -- double spaces
                                        if not in_comment then
                                                if str.item(column) = ' '
and str.item(column-1) = ' ' then
                                                        error("double
spaces")
                                                end
                                        end
                                end

                                column := column + 1
                        end
                end

        error(msg : STRING) is
                        -- Print error message.
                require
                        ok: msg /= Void
                do
                        io.put_string("-:")
                        io.put_integer(line)
                        io.put_character(':')
                        io.put_integer(column)
                        io.put_character(':')
                        io.put_string(msg)
                        io.put_new_line
                end

end -- class CHECK_TAB

===

-- 
Roger Browne - ro...@ei... - Everything Eiffel
19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428

[gobo-eiffel-develop] Developer Guidelines (first draft)

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

The mailing list archive seems to have been fixed now.
So for the record here is again the first draft of the
developer guidelines. Since I first sent it to the list
we agreed on Berend's suggestions to follow more strictly
OOSC2 guidelines, and to state clearly that 'gepp' should
almost never be used (only for generating the classes in
spec/[ise|se|ve|hact] for example) and that using deferred
classes was a preferred solution.

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

[gobo-eiffel-develop] Introduction: Franck de Bruijn

[Franck de B. (EDB) <fr...@ed...>]

Hello everybody,


Let me introduce myself. I am Franck and I am completely 
new at Eiffel.

In my struggle to find the "perfect" software product
development approach, I came across the OOSC2. Believe me, I
am already searching for a long time! Although it
is a pretty heavy book to read, I really like the way
Bertrand Meyer is putting "software construction".
The more I read, the more I start to believe in the Eiffel 
language, its potential and its future.

I have been browsing the web and newsgroups quite a lot for
more Eiffel information. To see what the Eiffel community 
is about and how the Eiffel language is more or less 
positioned at this moment.

First of all, I think it is a shame that a good language
like Eiffel has such a small exposure (Why did I never here
about it before???). Browsing the web I very much get the
(to use a real Dutch expression) house-garden-and-kitchen
feeling.

Second, I am (probably like you as well) quite struck that 
there are (hardly) no common libraries available and that 
every vendor is implementing their own. 
Where is the reusability!???

When I saw Eric's posting in the newsgroup that he is 
opening up the Gobo project for others and making it open 
source, I thought that this is a very interesting and very 
good move. I also saw that already one other Eiffel developer 
is willing to stop his work and contribute to this project.

I have a couple of questions that somebody might be willing 
to answer:
* What is the mission of this project? 
  What would you like to accomplish?
  What is the strategy?
* How many people are contributing to this project? 
  I see currently postings from 3 people.
* Are there any "decision"-structures? 
  I am reading a lot of discussions (it takes me already 
  1 hour to read all the e-mails .... I am also not 
  understanding everything!) and of course I cannot value 
  the importance of these discussions. But it appears to me 
  that there maybe should be some decision-control, saying: 
  "Ok, stop the discussion: these are the options, let's 
  vote" or something like that. I get the impression that 
  there is a lot of work ahead and if you start losing your 
  time with endless discussions not much will be realised 
  in the end ...
* What is currently going on in the Gobo project?
  Which libraries are being taken into account? Is there
  any documentation available that I could look at?

Since I am new at Eiffel programming and do not know much 
about making standard libraries anyway, I wonder in which 
way I could contribute to this project. I have some ideas 
below, but I leave it up to the Gobo community what to do 
with me, ok? If you tell me to sodd off (no place for
rookies), I will.... Being a rookie and not having much
experience with the Eiffel language, Eiffel IDEs, open
source and standard libraries, I don't think it is a good 
idea yet to put my fingers into code.... :)

But, dependent on what the mission of this project is and I
personally hope that you put some high ambitions I might be
useful in documenting the project.

I have read some complaints about the (lack of) documentation
of the libraries being developed by the Eiffel-community. One
response was to one of these postings, that it was preferred
to write code instead of documentation.

I know that OOSC2 proposes the short form for documenting 
classes. I personally think it is just a part of documentation
that you can cover with that. IMO, I think that you need things
like "introductions", "user's guides", "installation guides"
and stuff like that, before a library really gets mature. Of
course, also a good web page and on-line help with examples
and stuff are desirable.

I am not sure (due to time limitations) if I can take that
whole responsibility alone, but at least I can give it a start
and discuss some setups with you.

Let me stop here. Let me know what you think, ok?

Have a nice day,
Cheers,
Franck

Re: [gobo-eiffel-develop] Class name prefixes

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

Berend de Boer wrote:
> 
> 1. Are two letter prefixes not too short?

As you might know by now, I'm for consistency.
I would be OK to use three-letter prefixes, but there are already
some other (commercial) libraries using three-letter prefixes and
it may lead to name clashes, and this is exactly what prefixes
try to avoid.

Futhermore I don't really see prefixes as being part of the
name fo the class, but rather as a (library) code to prevent
name clashes between libraries. Having long library codes
(i.e. prefixes) would end up polluting the Eiffel code with
long class names where many letters are not relevant for the
understanding of the Eiffel code.

> 2. What if I specify PX_STANDARDC_TEXT_FILE and PX_POSIX_DIRECTORY?
>    What do you think about this?

Why not. It's fine to me. Perhaps PX_STANDARDC_TEXT_FILE
is a big long and could be renamed as PX_STDC_TEXT_FILE
provided that STD is a well accepted and understood
abbreviation of STANDARD.

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

Re: [gobo-eiffel-develop] eposix error handling

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

Berend de Boer wrote:
> 
> One error variable per object or a more global one, so you only have
> the last error?

I would rather say one error variable per object.
The last error per object seems enough.

> Most of the code I write is middleware and there's usually no user
> looking at the server screen :-)

That's the most difficult part when rewriting _reusable_
libraries: it should not only work for the author of the
library but should also address the needs of the other
potential users.

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

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

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

Christian Couder wrote:
> 
> I would rather have a base class using error variables and a derived
> class (inheriting the base class) with exceptions.
> Or something like this. I think it's far better than two set of routines
> (doing essentialy the same thing) in the same class.

Why not. What do you think about that Berend?

On the other hand with the first solution that I suggested
(deciding at creation time of the object if it will raise
exceptions or if it only uses an error variable) we can have
only one set of routines which call a `set_last_error'
routine when an error occur:

  set_last_error (...) is
          -- ...
      do
          last_error := ....
          if exeptions_enabled then
              raise (...)
          end
      end

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

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

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

Berend de Boer wrote:
> 
> It is the mix of tabs and spaces that causes problems. Just add this
> line
> 
>         set tabstop=2
> 
> in your .vimrc and browse a few files, not of your own, and you see
> the problems (take lib_std/collection3.e for example).

Yes, I'm well aware of this problem. That's why I suggested in
the guideline to use only tabs.

> And perhaps a sed script to convert existing code to tab format.

I already suggested that at the beginning of the discussion
but apparently to didn't read it. I even suggested to write
this tool in Eiffel because some 'sed' may not be installed
on all platforms:

! OK, I'll try to put together such little scripts
! and let you know when they are ready. I'll try to
! make them configurable so that we can specify the
! size of the tabs, and have two modes to convert
! tabs back and forth. Hmmm, we need something 
! OS-independent to write these scripts. I think the
! best choice for platform independent language in
! the context of the development of Gobo Eiffel
! package is ... Eiffel. What do you think?

If you want to write such tool, please do.

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

Re: [gobo-eiffel-develop] Class name prefixes

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

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

> Yes, I thought about that two days ago as well. What about
> possibly allowing several prefixes for some libraries. It
> is actually already the case for the Lexical library with
> LX_ and YY_ (for skeleton classes) and for the Parse library
> with PR_ and YY_ (again for skeleton classes). And if we
> integrate the Unicode cluster into the Kernel library we
> would also have KL_ and UC_ for this library. So provided
> that these prefixes are well documented (i.e. have a page
> listing all the libraries with their prefixes used) so that
> we can avoid clashes, I don't think that there is any problem.
> So what about SC_, PX_, SU_, etc. for the different layers?
> Of course you (and any other developer) are free to choose
> the prefixes you want provided that there are not used yet.

Two questions:

1. Are two letter prefixes not too short?

2. What if I specify PX_STANDARDC_TEXT_FILE and PX_POSIX_DIRECTORY?
   What do you think about this?

Groetjes,

Berend. (-:

[gobo-eiffel-develop] Re: [eposix] eposix error handling

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

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

>> The only other option I see is a global errno variable, like C.

> Global? Or just an attribute of class PX_DIRECTORY (or
> whatever its name is in epoix) in the example of
> directory creation?

One error variable per object or a more global one, so you only have
the last error?


> If I cannot create a directory, it's not exceptional.
> I just ask the user to enter an another directory
> name in the popup window.

Most of the code I write is middleware and there's usually no user
looking at the server screen :-)

Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

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

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

> I know, it is not an editor problem, unless proven otherwise ;-)

It is the mix of tabs and spaces that causes problems. Just add this
line

        set tabstop=2

in your .vimrc and browse a few files, not of your own, and you see
the problems (take lib_std/collection3.e for example).


> > But whatever we decide, what are our options to guarantee it is done
> > consistently?
> 
> That's what guidelines are for, and that's why I explicitly
> put this rule in the first draft of the guidelines. 

Not enough. People are not good at tiny details as programming prooves
again and again.

So at least there should be support for commonly used editors that
automagically make the code correct. As Emacs is infinitely extensible
it appears to be the candidate for this job...

If I find time today (might well be saturday), I'll experiment with
the various Emacs Eiffel hooks and the eiffel-mode to see what can be
done. And perhaps a sed script to convert existing code to tab format.


Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] Class name prefixes

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

On 29 May 2001 06:43:57 +0200, Christian Couder wrote:
> Eric Bezault wrote :
> > 
> > 
> > > 5. The name: I think the Gobo name is quite usefull as it is
> > >    well-known. But what about a somewhat more catchy name like Unified
> > >    Gobo? "The Unified Open Source Eiffel Library" is to formal, but
> > >    Unified Gobo sounds as somewhat more important for this large
> > >    undertaking.
> > >    But I'm also just fine with Gobo.
> > 
> > I would say the shorter the better. For example the full
> > name is actually Gobo Eiffel, but everybody just calls it
> > Gobo because it's shorter. So I would rather stick to
> > Gobo as a name, even if the documentation will clearly
> > state that it's a multi-developer multi-library project.
> 
> How about acronyms ?
> We could call it the GE for Gobo Environment or GEE for Gobo Eiffel
> Environment or even GEEK for Gobo Eiffel Environment Kernel :-)

I am not for a renaming. Let's get things done that help develop Eiffel
applications, not waste our time on renaming classes.


regards,
Andreas

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

[Christian C. <chc...@cl...>]

Eric Bezault wrote :
> 
> Berend de Boer wrote:
> >
> > Have you other solutions or suggestions? As exception raising is done
> > in just one place it's easy to change into an option or something
> > elese.
> 
> Could the use of exceptions or error variables be parameterized,
> for example use different creation routines if I want operations
> applied to this object to raise exceptions or set a boolean
> attribute when an error occurs? Well, an other solution could
> be to have two sets of routines, one with exceptions and one
> with an error status boolean to be set on error. This latter
> solution has the advantage of possibly providing slightly
> different postconditions for the two sets of routines.

I would rather have a base class using error variables and a derived
class (inheriting the base class) with exceptions.
Or something like this. I think it's far better than two set of routines
(doing essentialy the same thing) in the same class.

Regards,
Christian.

Re: [gobo-eiffel-develop] Class name prefixes

[Christian C. <chc...@cl...>]

Eric Bezault wrote :
> 
> 
> > 5. The name: I think the Gobo name is quite usefull as it is
> >    well-known. But what about a somewhat more catchy name like Unified
> >    Gobo? "The Unified Open Source Eiffel Library" is to formal, but
> >    Unified Gobo sounds as somewhat more important for this large
> >    undertaking.
> >    But I'm also just fine with Gobo.
> 
> I would say the shorter the better. For example the full
> name is actually Gobo Eiffel, but everybody just calls it
> Gobo because it's shorter. So I would rather stick to
> Gobo as a name, even if the documentation will clearly
> state that it's a multi-developer multi-library project.

How about acronyms ?
We could call it the GE for Gobo Environment or GEE for Gobo Eiffel
Environment or even GEEK for Gobo Eiffel Environment Kernel :-)

Regards,
Christian.

Re: [gobo-eiffel-develop] First XACE draft

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

On Mon, 28 May 2001, Eric Bezault wrote:

> Why not, but I'm a little bit skeptical about having
> several definitions in the same --define option.

I know, but do you have a better idea? Using the variable name as option
brings troubles with reserved option names. How does the parser
distinguish between --ise (which is an option) and --ise="foo" (which is
a variable definition).

> Furthermore, if  --define=FOO   is the long option
> usage, isn't there a short option usage as well such
> as  -d FOO  ?

IIRC the GNU standards (and thus get-opt) prohibit values on
short-name-options. You can say --foo=bar, but not -f bar.

regards,
Andreas

Re: [gobo-eiffel-develop] First XACE draft

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

Andreas Leitner wrote:
> 
> Btw, I think I will extend condition variables to include values. just
> like environment variables. Therefor I was looking for a new command
> line syntax and came up with that:

What does the C preprocessor do in that case? Is it something
like that:  -DFOO=BAR  ?

> variable-definitions: --define="VAR_NAME[=VALUE]( VAR_NAME[=VALUE])*"
> 
> examples:
> --define="FOO=BAR"
> --define="FOO=bar ISE VE PLATFORM=linux"
> 
> this new form has the advantage that it is get-opt conform. Now this is
> not GOBO conform, but I think in this case we should consider changing
> the ge-tools to conform to get-opt instead. What do you think?

Why not, but I'm a little bit skeptical about having
several definitions in the same --define option.
Furthermore, if  --define=FOO   is the long option
usage, isn't there a short option usage as well such
as  -d FOO  ?

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

[gobo-eiffel-develop] Class name prefixes

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

Berend,

> Is the two letter prefix already decided? Have I missed that part? I
> also send a msg to Eric that POSIX had a few other prefixes, and two
> letters is quite short.

Here is what I suggested when you raised the problem of POSIX
having several prefixes.

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

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

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

Berend de Boer wrote:
> 
> But I'm not really keen on this one, I just thought it was good to be
> 100% OOSC2 so people shouldn't have to rewrite, and we can't expect
> that if people follow OOSC2. Make it optional at least.

OK, let's make our life easier and follow OOSC2 instead of
reinventing the wheel. I think that in that case if there
is something optional, it should be the form not present in
OOSC2 guidelines.

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

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

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

Berend de Boer wrote:
> 
> Eric Bezault <er...@go...> writes:
> 
> >   The comb structure uses indentation, achieved through tab
> >   characters (*not* spaces, which are messy, error-prone, and
> >   not reader-parameterizable).
> 
> they're not parameterizable with every reader, so they look strange in
> certain cases. And perhaps they are in ISE's IDE, but haven't detected
> that option...
> 
> > From what I can see, it seems that the size of tabs used in
> > examples in OOSC2 is 4.
> 
> Hmm, I think it's 6 or perhaps just some xx em, not really clear.
> 
> > Then I don't see where the problem is. You can convert
> > tabs to 3 spaces when you load the Eiffel class into Emacs,
> > and convert them back to tabs when you save the file.
> 
> Then I don't see where the problem is. You can convert 3 spaces to
> tabs when you load the Eiffel class into vim, and convert them back to
> tabs when you save the file :-))

I don't understand: on one hand you say that we should follow
OOSC2 guidelines and not reinvent the wheel, and on the other
hand you reject it when it does not fit your liking.

> The point is that sometimes you have tabs in the file, sometimes
> not. Not all editors handle tabs great, so just do away with them.
> 
> I agree that your source code works fine with tabs, but most others
> don't. Take the SmallEiffel code,

Written using Emacs...

> take EXML, 

Written using Emacs...

> take whatever source file you might lay your hands upon.

I don't know about this one ;-)

I know, it is not an editor problem, unless proven otherwise ;-)

> But whatever we decide, what are our options to guarantee it is done
> consistently?

That's what guidelines are for, and that's why I explicitly
put this rule in the first draft of the guidelines. I was
hoping that people would follow the guidelines without me
having to play the cop. What are the options to guarantee that
people will use spaces consistently if we decide to go with
spaces? What are the options to guarantee that all the other
rules specified in the guidelines are followed consistently?
To be honest I would prefer people to care by themselves
about writing consistent code (that's why I started to write
some guidelines) rather than to waste my time writing tools
and scripts to check that nobody violates the rules. But if you
think that such tools and scripts should be written because
we cannot trust Eiffel programmers, well... sadly let's do it.

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

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

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

Berend de Boer wrote:
> 
> The only other option I see is a global errno variable, like C.

Global? Or just an attribute of class PX_DIRECTORY (or
whatever its name is in epoix) in the example of
directory creation?

> History learns that programmers do not check errors in such
> cases. This can lead to security breaches and/or corrupt data.

Crashing the program may lead to corrupted data as well.

> I also prefer not to think about errors: if there is an error, it is
> exceptional, so just quit.

If I cannot create a directory, it's not exceptional.
I just ask the user to enter an another directory
name in the popup window.

You prefer not to think about errors, but for people
who do care about writing robust code having to deal
with exceptions makes life much more complicated than
testing for errors.

> Have you other solutions or suggestions? As exception raising is done
> in just one place it's easy to change into an option or something
> elese.

Could the use of exceptions or error variables be parameterized,
for example use different creation routines if I want operations
applied to this object to raise exceptions or set a boolean 
attribute when an error occurs? Well, an other solution could
be to have two sets of routines, one with exceptions and one
with an error status boolean to be set on error. This latter
solution has the advantage of possibly providing slightly
different postconditions for the two sets of routines.

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