headers
Chris Saunders | 4 Aug 2010 10:33

Installin EiffelStudio 6.7 on Windows

So far only a 7-zip file is available for EiffelStudio 6.7.  I have no idea 
how to install this and the instructions at 
http://docs.eiffel.com/book/eiffelstudio/software-installation-eiffelstudio 
only suggest using an msi file.  I'm hoping someone can give me instructions 
on how to install this on Windows 7.

Regards
Chris Saunders 

------------------------------------
Permalink | Reply | 3 comments |
headers
David Le Bansais | 4 Aug 2010 12:08
Picon

Re: Installin EiffelStudio 6.7 on Windows


If you go to http://sourceforge.net/projects/eiffelstudio/files/ and select the Eiffel 6.6 folder,
the msi installer for Windows 32-bit release 83873 is available. Apparently, it's also available
directly from the big download button if you default to Windows like me.

I assume release 83873 is the build you're trying to download?

Regards
David Le Bansais

--- In eiffel_software@..., "Chris Saunders" <evas <at> ...> wrote:
>
> So far only a 7-zip file is available for EiffelStudio 6.7.  I have no idea 
> how to install this and the instructions at 
> http://docs.eiffel.com/book/eiffelstudio/software-installation-eiffelstudio 
> only suggest using an msi file.  I'm hoping someone can give me instructions 
> on how to install this on Windows 7.
> 
> Regards
> Chris Saunders
>

------------------------------------
Permalink | Reply | 0 comments |
headers
Chris Saunders | 5 Aug 2010 01:42

Re: Installin EiffelStudio 6.7 on Windows

I got a reply from Manu that describes the steps I would need to follow to install EiffelStudio 6.7 on
Windows.  I would prefer not to have to do these things so I would like to ask if a Windows installer will be
available for version 6.7 anytime soon?

Regards
Chris Saunders

[Non-text portions of this message have been removed]

------------------------------------
Permalink | Reply | 1 comment |
headers
Emmanuel Stapf [ES] | 5 Aug 2010 01:55
Favicon

Re: Installin EiffelStudio 6.7 on Windows

The next release will have one included. To follow the development
release of 6.7 I recommend using the .7z package which is faster to
download, install and uninstall.

Manu

On Wed, 2010-08-04 at 19:42 -0400, Chris Saunders wrote:
> I got a reply from Manu that describes the steps I would need to follow to install EiffelStudio 6.7 on
Windows.  I would prefer not to have to do these things so I would like to ask if a Windows installer will be
available for version 6.7 anytime soon?
> 
> Regards
> Chris Saunders
> 
> [Non-text portions of this message have been removed]
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 
> 

------------------------------------
Permalink | Reply | 0 comments |
headers
Robert Jurjevic | 5 Aug 2010 12:55

"Design by contract" revisited

Dear OO colleagues,

I am a great supported of "design by contract" approach and find it very
useful in commercial real life programming practice (I don't use Eiffel
commercially, but do emulate "design by contract" assertions in other
programming languages such as C, C++, C#).

But!

Let us assume that you are responsible for a delicate program people
lives may depend on, say a medical software for life support. Let us now
assume that there is a logical mistake in using LOG class of a medical
software for life support and that the program would be able to continue
operating providing basic essential functionality after a logically
programming mistake has been hit in usage of LOG class if the logging
was switched off. I guess in such a circumstance one would rather
continue operating without logging rather than close the program and put
the people at risk. 

I guess in practice one may use two computers with two computer programs
(each of which was written by a different team of programmers with no
custom common software components shared between the two teams) and if
one computer or program fails the other takes over.

Nevertheless, I wonder if there is a possibility to 'extend' "design by
contract" mechanism in order to be able to cope with such situations.
Say, if a precondition in LOG class is violated the exception is not
risen but rather the logging functionality switched off (I guess one
would need to specify somehow that that particular precondition in LOG
is of that special type and what means to switch off the logging
(Continue reading)

Permalink | Reply | 5 comments |
headers
dwilliams | 5 Aug 2010 13:31
Favicon

Re: "Design by contract" revisited

Hello Robert

If you need that level of integrity you should be considering: spark Ada.
You can learn more http://www.praxis-his.com/

The spark Ada form of Design by Contract is Correct by Construction. In
contrast to Eiffel, spark Ada code is verified to be correct before it is
compiled. It is not easy or quick to write. Only a limited set of the Ada
instructions can be used and a deep understanding of software
specification, eg: Z, is essential. You really need to be of first class
honours calibre. The effort is justified, indeed essential, for
safety-critical systems, eg: flying an aeroplane or driving a train, but is
more than can be justified for systems that are unlikely to kill or injure
people - yet.

That said, I am sure that, just as the wisdom of Eiffel is beginning to
dawn on the producers of other languages, so the influence of spark will,
one day, affect Eiffel.

Regards
Dave.
David Williams
Software Team Leader & Intellectual Property Manager
email: dwilliams@...
tel: +44 1305 208341

                                                                                                                                    
  From:       "Robert Jurjevic" <Robert.Jurjevic@...>                                                            

  To:         <eiffel_software@...>
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Le Bansais | 5 Aug 2010 13:38
Picon

Re: "Design by contract" revisited


You could use an intermediate class FAILSAFE_LOG that redefines all features to call the precursor by default.

In each feature, you can catch exceptions, and if an exception occurs you turn some is_logging attribute to off.

Then, if at the beginning of a feature you test is_logging, in case it's turned off you just do nothing.

class
FAILSAFE_LOG

inherit
LOG
redefine
make,
log_information
end

create
make

feature {NONE}

make
do
precursor
is_logging := True
failure_reason := 0 -- No failure
end

feature -- Reason why information is no longer logged.
(Continue reading)

Permalink | Reply | 0 comments |
headers
rfo | 5 Aug 2010 19:48

RE: [eiffel_software] "Design by contract" revisited

Hi Robert

Writing good contracts can go a long way to addressing your concerns,
but ultimately, there will be failures of some sort.  The goal is the
reduce the likelihood and the impact of those failures (as you suggest).

The example you cite might treat logging as being as critical as the
life-support aspect of the system. They are not equivalent. Design by
Contract is a lot more than just putting a condom on a routine (though
that is a good idea in many cases).  Inherent to the contract is the
notion of obligation.  The caller has the obligation to satisfy the
precondition of the called routine.  Relaxing that precondition opens
Pandora's box.
Your logger must give its clients a fighting chance to satisfy the
precondition, and so must provide a means by which to check whether or
not a precondition will be satisfied, rather than just hoping so and
waiting for an exception.  Exceptions are not meant as control flow, we
all know, but sometimes we're less disciplined about it than we should
be.
Another common issue is using only literal preconditions that reflect
the implementation.  It is often better to have preconditions that
reflect the intended purpose. For example, rather than having a
precondition on a string argument that demands it be non-void and
non-empty, it might be better to define a function in the supplier's
class named is_valid_something that the client can call before calling
the routine with that precondition.

Replace this:

dosomething (v: STRING)
(Continue reading)

Permalink | Reply | 1 comment |
headers
discs94 | 5 Aug 2010 23:29
Picon

Errors/Warnings in compilation of Bertrand Meyer 'Touch of Class' examples

Dear Eiffel community,

Firstly, thank you for Eiffel Studio and for this forum; also thank you
for the Eiffel language.  I have been doing a lot of research on the
programming language to learn and focus upon.  Eiffel does really seem
the best one!  For me, it most captures the truth of the realities of
the world we deal with, and is thorough in its approach.

I am a student, studying Eiffel at home from the Eiffel textbook
recommended on the Eiffel Studio site: 'Touch of Class' by Bertrand
Meyer. The book uses examples from a file  - traffic_ev 3.3.1_1104 -
which I have downloaded from http://traffic.origo.ethz.ch/wiki/traffic 
<http://traffic.origo.ethz.ch/wiki/traffic>

My problem is that I cannot successfully compile the examples (.ecf
files) in the examples.  My installation of EiffelStudio,  to which I am
new,  successfully works with other EiffelStudio's examples - including
Eiffel Vision examples - that are  included in C:\Program Files\Eiffel
Software\EiffelStudio 6.6 GPL\examples; these compile and execute
successfully.

When I compile the 'traffic' examples (I have tried 3 example .ecf
files) from the Bertrand Meyer course I always get the following 2
(types of) Errors:
  <http://traffic.origo.ethz.ch/wiki/traffic>

------------------------------------------------------------------------\
------------------------------------------------------------------------\
-----------------
1) Error code: VD00 General configuration parsing error.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Berend de Boer | 5 Aug 2010 23:40
Picon
Favicon
Gravatar

Re: "Design by contract" revisited

>>>>> "Robert" == Robert Jurjevic
<Robert.Jurjevic@...> writes:
    Robert> Let us assume that you are responsible for a delicate
    Robert> program people lives may depend on, say a medical software
    Robert> for life support. Let us now assume that there is a
    Robert> logical mistake in using LOG class of a medical software
    Robert> for life support and that the program would be able to
    Robert> continue operating providing basic essential functionality
    Robert> after a logically programming mistake has been hit in
    Robert> usage of LOG class if the logging was switched off. I
    Robert> guess in such a circumstance one would rather continue
    Robert> operating without logging rather than close the program
    Robert> and put the people at risk.

Let us assume that the program would kill the patient if a logical
programming error occurred :-)

But DbC and continue to operate are two entirely different classes of
design. DbC is about structuring your program, continue to function is
a separate concern. DbC can and will support that case as well.

For example I have a program for which it is better to function
partially than not at all. So the program is written using separate
daemons so that if one fails, not all are affected. Moreover, the
failing program can be restarted. It also supports retrying its last
operation (if that's possible) etc.

There are numerous cases like that. You just write your software to
support it. If you are concerned about logging, make sure it's an
optional piece of your software, so you can continue to function even
(Continue reading)

Permalink | Reply | 2 comments |

Gmane