Team Eiffel

Irish programmer Finnian Reilly has set up eiffel-loop.com, a website that spotlights software development using Eiffel.
The site is still in its early days, but there are some interesting items including The Tao of Design By Contract and some quotes by Bertrand Meyer and Donald Knuth.

Finnian is developing some Eiffel software that he intends to release as open source after the next Eiffel Struggle competition.

Frank De prins reminded me about spec# from Microsoft Research, which extends the C# programming language to include contracts.

Preconditions ("requires") and postconditions ("ensures") will be familiar to Eiffelists, as will class invariants. Spec# also supports frame conditions ("modifies"), and explicit denotation of parts of code that may temporarily invalidate a class invariant ("expose").

There is also void-safety. Indeed, this might be the inspiration for the inclusion of void-safety in ECMA Eiffel, as Bertrand Meyer was closely involved with Microsoft's early work on the .NET platform.

Spec# checks contracts at runtime, and interfaces with the Simplify theorem prover for static verification.

Spec# integrates with VisualStudio, and can be downloaded for free.

A PDF document The Spec# Programming System: An Overview discusses contributions to systems with contracts (on pages 14-15). It mentions Gypsy, Alphard, Euclid and Clu as early influences, and lists Eiffel, SPARK and B as "modern systems with contracts that have had a direct effect on practical programs".

On the ISE Eiffel mailing list there has been a discussion amongst Chris Saunders, Steven Wurster and others about the behaviour of DOUBLE and other numeric classes when IEEE-754 NaNs are encountered.

Bertrand Meyer wrote:

The problem is that while there are well-established axioms for the underlying mathematical sets -- integers, rationals, reals... -- the modeling of their computer counterparts is much less well understood. NUMERIC ... models the mathematical notion of a commutative ring structure. This decision can be criticized but it is explicit and unambiguous.

In this context it doesn't particularly shock me that operations on NaN should cause invariant violations. After all, isn't NaN supposed to mean "not a number"? If it's not a number, it doesn't have to satisfy the properties of numbers.

Bertrand Meyer pointed out that there were two approaches to modeling objects of numeric types: one could either start from the mathematical sets, or start from the actual rules of computer arithmetic. He invited suggestions that took into account "all three aspects -- the mathematics, the software and the hardware".

Thomas Beale and Steven Wurster agreed that the original design was right in choosing mathematical abstraction for the modelling basis, but "what it lacked, as we are now finding out, was classes for concrete models of representation and processing. It seems that these are now being populated with all the INTEGER_16 etc classes". But is inheritance the correct relationship between the computer-math and theoretical-math classes?

Bertrand Meyer posited that...

one solution in this direction would be to have a notion of "normal" number, where NaN is not "normal", and rewrite some -- probably most -- postcondition and invariant clauses in the form

         (a.normal and b.normal) implies P

Incidentally, although IEEE-754 was accepted in 1985, it was not nearly so widely implemented when the Eiffel kernel classes were originally designed as it is now. IEEE-754 currently undergoing revision.

If you aren't au fait with IEEE-754 you may wish to read David Goldberg's article What Every Computer Scientist Should Know about Floating-Point Arithmetic or see the IEEE-754 FAQ.

Eric Bezault asked (on the Visual Eiffel mailing list) whether someone either at Object Tools or in the open source community was working on adding new Eiffel extensions to Visual Eiffel.

Eric mentioned constructs such as Tuples and Agents, and classes such as INTEGER_64 and NATURAL, as being extensions that would make it easier for Gobo to continue to support Visual Eiffel.

Frieder Monninger replied that Object Tools has at the moment no plans to implement these features themselves, but will support anyone outside who wants to do this.

A new configuration-file format is appearing in the development version of EiffelStudio. These platform-independent XML files are replacing ACE-files.

"ACE" stands for Assembly of Components in Eiffel, and has for about fifteen years been the way to specify the compilation of a system (or precompilation of a library) in ISE Eiffel.

ACE-files are suffixed ".ace", and are written in a language called LACE (Language for Assembly of Components in Eiffel). This is a fairly heavyweight language for its purpose, and as such it was not adopted by Eiffel/S, Visual Eiffel or SmartEiffel. However, SmartEiffel added ACE-file support in July 2001 for increased compatibility and functionality.

The Gobo Eiffel project already supports an XML form of project specification, in its "xace" files which can be preprocessed to produce ".ace" files for ISE Eiffel and SmartEiffel and ".esd" files for Visual Eiffel. Recent versions of Visual Eiffel can even consume ".xace" files directly.

ISE Eiffel's ".acex" files are broadly similar in purpose to Gobo's ".xace" files, but are quite different in detail.

Curious? Have a look at these examples, for Gobo and ISE Eiffel.

Unfortunately the elj-win with libraries installation had incorrect Gobo libraries. They were installed for SmartEiffel 2.2 instead of SmartEiffel 1.2 (don't you love #ifdef too?).

A corrected version is now available.

Or manually correct the older release with the following commands:

cd %GOBO%\library
geant clobber
geant install

Paul Crismer has released a new version of his ECLI library, which provides Relational Database Access on top of CLI/ODBC.
New with this version is:

• Blob/large data transfer
• Information on DBMS capabilities
• Session control and information
• Login strategies: simple (data source, user name, password) or
  through connection string
• Information about installed ODBC drivers
• Decimal/Numeric data using MA_DECIMAL class

Paul has also reworked the samples, documentation and tests.

ECLI is now licensed under the Eiffel Forum License v2. It requires Gobo 3.4 and has been tested with ISE Eiffel 5.6 and Visual Eiffel 5.0b.

The Numeric Eiffel Library (download) is a collection of scientific programming classes that implement complex numbers, matrices, and vectors, quaternions, random number generators, the singular value decomposition, simple statistics, and the Fast Fourier Transform.

It's from Greg Lee, who is already known to Eiffelists for wrap_jvm_class, a utility that generates Eiffel wrappers for Java classes, and (amongst other things) enables Java applets to be written using SmartEiffel 1.x.

Greg writes:

Eiffel is a great language for numerical computing, especially so with the new array operator "[]" and the "assign" keyword that allows traditional FORTRAN-style assignment statements:

   a: ARRAY[DOUBLE]

instead of

   a.put( 23.0, 4 )

now we can write

   a[4] := 23.0

Although the semantics of the two forms are identical, the second form looks more like mathematical notation.

A lot of work has been put into developing numerical routine libraries over the years, and the approach often taken to use these libraries in Eiffel has been to wrap existing FORTRAN or C numeric libraries in Eiffel. Eiffel Software's excellent EiffelMath product that wraps the NAG C scientific computing library takes this approach.

However, for less ambitious projects, there is an apparent lack of a standard Eiffel implementation of the usual numeric classes such as complex numbers, matrices, and vectors. This contest submission, the Numeric Eiffel Library (NEL), fills this gap with an Eiffel implementation of these fundamental scientific computing classes.

Greg's package supports EiffelStudio 5.6 and has been tested on Windows 2000 and Mac OS X 10.4. It is licensed under the Eiffel Forum License version 2.

The elj-win Windows installer releases are now available for public consumption. Let me know what you think:

1. Just SmartEiffel 1.2r7.


2. SmartEiffel 1.2r7 + lcc-win32.


3. SmartEiffel1.2r7 + lcc-win32 + Gobo 3.4 + eposix 2.3.2 beta.

I want to include more libraries. My personal ECLI copy is first on the list, put other suggestions as comments please.

There's a new eposix beta available for download. This should be the final beta before the next release.

Main new things in this beta are HTTP Server enhancements: support for persistent connections and chunked transfer encoding support. The list of changes:

New in 2.3.2 beta - 2006-04-14
* ./configure changes
  - Gobo Eiffel Compiler support added. Use --with-compiler=gec.
  - multi-threading support: Use --enable-threads.
* EPX_HTTP_SERVER
  - now supports persistent connections.
  - make: does not start listening anymore! Call listen_locally or
    listen_globally.
  - send_file: when serving a file it now includes an ETag
  - add_file_expires_date: new feature that adds an Expires header for
   image files in order to improve performance with IE. Without this
   IE will retrieve reused images on a page multiple times.
* EPX_MIME_PARSER
  - support for chunked Transfer-Encoding.
  - parse_body: does not take an argument anymore. Determining length
    of message body is now entirely based on the previously parsed
    header.
* ABSTRACT_FILE_DESCRIPTOR:
  - seek_XXXX features didn't reset eof, should always be False after
    a seek.
* EPX_EXTENSION_FILTER:
  - now accepts all directories and will recursive to any
    depth. Filenames must still match the filter though.
* ABSTRACT_DIRECTORY:
  - forth: when an extension filter was set, and recursive browsing
   was specified, directories were not recursived because they did
   not match the extension filter. Introduced the option
   validate_directory in ABSTRACT_PATH_FILTER to give a filter the
   option to accept directories, and not include them in the filter.
* EPX_FILE_SYSTEM
  - browse_directory: now returns an EPX_DIRECTORY.
* EPX_DIRECTORY:
  - class equal to ABSTRACT_DIRECTORY. Use this instead of
    ABSTRACT_DIRECTORY as ABSTRACT_XXXX classes should not be used
    directly by the client.
* EPX_CHARACTER_HELPER
  - class has become obsolete.

Ian Joyner has created Eiffel support for TextMate, a nifty editor for OS X.

Features include syntax highlighting, auto-indentation, and shortcut entry of Eiffel constructs. By typing two characters followed by a tab you can create an indexing clause, class definition, feature definition or instruction.

Ian writes: "All TextMate bundles are under Subversion control, so if anyone wants to take this effort further, please feel free".

Justin Finnerty created his Eiffel Struggle entry desync because he wanted to clean up duplicate files left behind by his replication of directories. Justin had been using rsync to replicate working directories and backups - but tools such as rsync use simple criteria (such as name and timestamp) to identify the files to manage, so over a period of time some cruft had accumulated. Desync helps to sort out this cruft.

It wasn't Justin's application itself that caught my interest (because I use subversion and darcs to replicate working directories, and rsync-backup to replicate backup directories, so I don't have the problems that desync fixes).

What caught my interest was the range of programming and packaging techniques that Justin had employed.

Installation is handled by the Gnu autoconf three-step: ./configure, make, sudo make install. The configure command checks to see which Eiffel compiler you have, where GOBO is located, etc, and builds the appropriate makefile. You then invoke make twice - once to build the system and once to install it. If you have more than one Eiffel compiler, you can tell configure which one to use.

Test cases are provided so that you can confirm that desync is working after you build it but before you install it.

The makefile is comprehensive, including targets for uninstall, clean, distclean, etc. There are also targets for building development versions, and for automating the process of switching the Eiffel compiler that you are using.

Desync uses the GOBO package in three different ways:

1. The GOBO libraries are used for their vendor-independence,
2. GOBO's xace files handle the Eiffel side of the build, and
3. GOBO's gepp preprocessor is used to workaround differences in the syntax accepted by different Eiffel compilers.

If you haven't seen gepp at work, it takes a file with suffix ".ge" and preprocesses it, leaving the result in a corresponding ".e" file. Preprocessor directives can be used to conditionally include code. For example, the following fragment includes the "insert" keyword only if SmartEiffel is the target:

inherit
 SYNCHRONISED_DIRECTORY
#ifdef SE
insert
#endif
 DT_SHARED_SYSTEM_CLOCK
 KL_SHARED_STANDARD_FILES
 KL_SHARED_FILE_SYSTEM

On the Eiffel side, Justin needed to provide some utility classes that support his application. There's a small cluster to implement "agent" functionality that is not available in Visual Eiffel. There's also a "collection" cluster with some interesting data structures including quadlinks - nodes that may be linked to other nodes that are above, below, to the left or to the right. A "configuration" cluster brings together command-line option handling, help messages and reading of the configuration file. A "file system objects" cluster takes care of filesystem properties (such as symbolic links). There are also some FACTORY classes, and a logging/reporting framework.

SmartEiffel's Observer classes did what Justin needed, so he modified them for use by other compilers.

For documentation, Justin has used Aurelio Jargas's txt2tags utility, which generates "man pages" and HTML pages from lightly-marked-up textfiles.

That adds up to a lot of interesting tools, techniques and technologies that Justin has used, above and beyond the Eiffel code of his core application.

I just received the detailed judging scores for my Eiffel Struggle competition entry. Those who didn't enter may be interested to see how the scoring works:

1. Installation documentation: 7/10
   
2. Usage documentation: 7/10
3. Construction documentation: 1/10
4. Innovation and community value: not seen before in Eiffel: 4/10
5. Innovation and community value: not seen before at all: 4/10
6. Portability among Eiffel compilers: 4/10
7. Portability among platforms: 2/10
8. How easy is it to install the application or library? 8/10
9. How well is the entry constructed? Did it use
   patterns for example? Was it complete? Did it not abstract away too
   much? 7/10
10. Source code readability: 6/7
11. Source code formatting: 3/3
12. Use of the Principles of Design by Contract: 6/10
13. How easy is it to use if the entry is an application? 7/10
14. How easy is it to use if the entry is a library? N/A
15. How much effort seems to have been put into it? 6/10

It must be incredibly hard for the judges to rank such dissimilar contest entries, so I have no complaints about the scores.

I deliberately chose to use formatting other than the struggle-sanctioned OOSC/Gobo style (I prefer three-character indentation so that I can see more code in a narrow window). Although I applied my style consistently, I was expecting to lose points for it and was pleased to be awarded the maximum three points available for source code formatting.

For what it's worth, if the results were up to me I would have awarded first prize to Andreas Leitner's AutoTest which is something quite amazing, and second to Daniel Moisset's Eiffel Windowing System which is a very practical, well-rounded package.

Recent development versions of SmartEiffel highlight the ability to embed scripting language interpreters. Embedded Perl is implemented, and there is a tutorial example using embedded Perl.

Perl? When they could have chosen Ruby or Python? Oh well.

Hello World, in embedded Perl, is as simple as this:

   perl.instruction(once "use strict;print(%"Hello!\n%");")

You can execute an expression and retrieve its value, without breaking command-query separation on the Eiffel side:

   perl.expression(once "2**10")
   io.put_integer(perl.last_integer)
   io.put_new_line

You can manipulate Perl variables, to test for their existence, test whether they are defined, set them and read them.

There's more to it than that, of course. For more details, see subversion checkins 7072, 7073 and 7074.

The reaction to the open-sourcing of EiffelStudio has generally been very positive, but one group of people has mentioned on comp.lang.eiffel that the move doesn't help them. They are the individual developers of commercial software who would like to use Eiffel for their products, but who neither need nor can afford an "Enterprise" package.

There is certainly a gap in the market for a comprehensive multi-platform commercial Eiffel product in the $500 to $1000 range. The customers are businesses such as Hubert Cater's Fury Software and Lothar Scholtz's Scriptolutions. It isn't a huge niche, and in any case there have been reports that special pricing has been negotiated for ISE Eiffel licensing by small commercial developers.

Lothar wrote in comp.lang.eiffel:

For me it looks like the VE deal - a last cry for help and a last try to get some more market shares. But i would really be surprised it this helps. What Eiffel needs is developer time to add additional stuff and that is something you don't get for free.

I don't think that's quite accurate or fair. Firstly, it's hardly a "last cry for help". A glance at the subversion commit logs for the last few days shows that there is a most impressive amount of ongoing product development by a wide range of developers including long-time Eiffel developers such as Emmanuel Stapf, Alexander Kogtenkov and Jocelyn Fiat.

Secondly, the open sourcing of EiffelStudio is going to make its use much more practical for those studying under Bertrand Meyer at ETH Zurich, and will bring in a huge amount of additional developer time. To get a feel for the constraints under which ISE Eiffel had been used at ETH, and the relief when those constraints were lifted, have a look at these two blog entries by Daniel Baumann, who was doing the Debian packaging for Eiffel projects such as EiffelMedia:

• Eiffel packaging considered painful
• EiffelStudio is Free Software

In time I expect Bertrand Meyer will reveal more about the motivations behind open-sourcing EiffelStudio. In the meantime, it's interesting to look again at what he wrote in 1999 for Software Development Magazine about The Ethics of Free Software.

In particular, Bertrand Meyer was keen to see more precise terms used than the "catch-all term of free software". He suggested that the following five categories "seem to exhaust the economic possibilities":

• donated
• taxpayer-funded
• privately funded
• taxpayer-sponsored
• privately-sponsored

Bertrand Meyer wrote:

For example the GNU Eiffel compiler was developed at the University of Nancy by employees of that university who (in contrast with commercial Eiffel vendors, who need paying customers to survive) get every month a salary from the State, whether the users are happy or not with the product. This is a typical case of taxpayer-funded software.

Well, there is now one more GPL Eiffel compiler to which that will apply, at least in some part.

The EiffelStudio wiki lists 72 tasks required to implement the full ECMA 367 specification of the Eiffel programming language.

The list is divided in two parts: "easy" and "complex" tasks, and provides a good summary of the changes that can be expected over the next few years. A couple of the changes are beyond what is in the current version of ECMA Eiffel.

I documented a small collection of Eiffel idioms in a corner of my wiki. I noted that they are frequent in Eiffel code from experienced programmers, but that newcomers to Eiffel usually don't know them, and tend to do the same things in suboptimal ways.

Some of them come from code I have read, others from examples in ETL2 and OOSC2, and others from recent posts to comp.lang.eiffel. The list is very short and I am sure I have missed a lot of commonplace idioms, but hopefully it will grow in the future.

"News for Nerds" site slashdot.org today carried the story EiffelStudio Goes Open:

"Bertrand Meyer, the creator of Eiffel the language and CTO of Eiffel Software in Santa Barbara, CA has announced in his Software Architecture course at ETH Zurich that the company's flagship product - EiffelStudio was released under the GPL today ... Eiffel is an object oriented programming language supporting contracts. Last year the international standard (ECMA) for Eiffel was released and now the initiative to go open has been taken."

Responses are varied, ranging from "ho hum" to enthusiasm. Many of the posters remember Eiffel from their University days, and some indicated that this release has motivated them to try it again.

Not surprisingly, there's considerable ignorance about the real advantages of Design By Contract (it is stated to be nothing more than assertions) and the shootout benchmarks are being quoted without making it clear that they apply to SmartEiffel rather than EiffelStudio.

But, as they say in advertising: Say anything you like, provided you spell the name right.

Hubert Cater of Fury Software has announced the release of Strategic Command 2 Blitzkrieg, the sequel to Strategic Command released in 2002. It is a strategy game set during WWII in the European Theater (screenshots).

Strategic Command 2 Blitzkrieg was written 100% in Eiffel and accesses DirectX via Eiffel Software's EiffelCOM wizard.

A 90MB demo is available, and you can download the full game manual (PDF).

The full game features sophisticated artifical intelligence, weather, "fog of war" effects, convoy routing, Lend-Lease, scorched earth tactics, Siberian troops, the Soviet winter, Urals industry, Malta effect and more.

The Eiffel landscape has changed forever, following this morning's announcement that EiffelStudio has moved to a dual-licensing model. ISE says:

Eiffel Software's Dual Licensing model is based on the principle of fair exchange. Users who write commercial proprietary software must purchase the corresponding licenses and may freely choose how to distribute their software. Users who donate their source code to the Open Source community can use the Open Source version and must distribute their software under the same license.

A quick browse of the sources shows that the compiler and C runtime are licensed under the GPL v2 whilst the Eiffel libraries (kernel and application) are licensed under the GPL-compatible Eiffel Forum License v2.

Here are some links of interest:

• Wiki main page
• Builds for Windows and Linux
• Source Code Repository (subversion)
• Source Code Repository browser (websvn)
• Compiling EiffelStudio
• Mailing lists

Hi all, this is my first post on this blog. As a start here are a couple of pictures from the ETH lecture room F3 from this morning:



http://www.eiffel.com/general/news/2006/2006_04_05_pr.html
http://eiffelsoftware.origo.ethz.ch/index.php/Main_Page
have fun,
Andreas

Usual disclaimer: limited sample size, only reflects successful search engine queries that landed at eiffelzone.com, not all searchers were seeking Eiffel content:

1. lua
2. webshort
3. gote
4. ewg
5. kinds of automata
6. hotbabe
7. goanna
8. wxeiffel
9. eiffel software
10. eiffelzone
11. bison
12. empathy
13. numeric
14. smarteiffel
15. eiffel zone
16. fenestra
17. lohan
18. matisse
19. eiffel gui
20. eiffel database

In many ways, the top 20 search queries are not the most interesting: the breadth of queries at the bottom of the list is quite revealing. So I've put the webserver statistics on the web where you can browse them at your leisure: http://eiffelzone.com/usage/

Daniel Moisset has announced the release of SmartEiffel 1.2r7 (transitional), a branch of the SmartEiffel compiler derived from SmartEiffel 1.1. It is 100% backwards compatible with 1.1, but with several 2.x extensions, to help with porting software to SmartEiffel 2.x.

SmartEiffel 1.2 seems to be gaining traction, being supported by Gobo and e-POSIX (which do not support the latest Loria version of SmartEiffel).

This release includes some minor bugfixes, some changes related to 2.2 compatibility, and some changes to allow use of MSVC++ 2005 as backend. Compaibility changes include:

• A warning is issued for calls Current.f, where f is not exported to the Current class. It is not considered an error for 1.1 compatibility (it is an error in 2.x)
• Some file handling features of GENERAL that were removed in 2.x are now obsolete. Other removed features from GENERAL/ANY, too
• INTEGER.even is obsolete, replaced by is_even
• A warning is emitted for code that does not conform to the stricter case-sensitivity rules of SE 2.2

Bugfixes include:

• Fixed an overflow when parsing ASCII codes in manifest strings
• Changed mangling of identifiers that prevented using MSVC 2005 as backend
• Warnings are no longer issued when doing a short or class_check of ANY, GENERAL and PLATFORM

Links:

• SmartEiffel 1.2 website
• Download (tar.gz)

Over on the ISE Eiffel mailing list there has been a lively discussion of naming conventions for local variables and formal arguments.

Andrew Lyall moved the discussion on to a linguistic convention for Eiffel comments. His post was so good that I think it deserves a wider audience:

Guys,

As there is so much interest in conventions for variable naming, I wonder if you would be interested in my ideas on a linguistic convention for Eiffel comments.

I an an ardent Francophile; I go to France for my holidays and every other time I can; French cuisine is the best, and who else knows how to make wine and cheese? (BTW, I am a great fan of new-world wines and promote them as hard as I can because it means that if other people drink them, there will be more French wine for me to drink!) To me Eiffel exudes, style, chic, lan, and all those other things that world admires France for. Java and C++ are burgers to Eiffels Boeuf-Bourguignon; they are coca-cola to Eiffels Hermitage!

As a committed acolyte of Eiffel and indeed all things French, I have thought long and hard about how to introduce Eiffel to the wider programming community, although I a am, of course, very aware of the risk of casting pearls before swine! It seems to me that a comment style that emphasizes the essential Gallic nature of Eiffel might be what is required.

It so happens, that, almost certainly because of my interest in all that is French, I am also a great fan of Peter Sellers as Inspector Clouseau, and by diligent study I have taught myself to speak Clouseauese. Now, it seems to me that if the Eiffel community were to adopt Clouseauese as the default `style' for comments it might help to promote Eiffel and the Eiffel method.

Below is a code fragment taken from a real production program of mine, which gives a feel for what I have in mind. I apologize in advance for the crass coding, but would crave your indulgence and instead ask you to concentrate on the comments.

When I read comments like this, I am taken immediately to a Parisian pavement caf on a warm summer evening, with a glass of an humble but well made vintage in my hand and an according playing in the background. Clouseau is sitting the opposite me at the other side of table, his conversation acting as a delightful counter-point to the accordion, but I am not listening to him, instead I am thinking about the menu and what I shall be having supper.

Anyhow, I would be interested to know what you guys think:

is_ok_massage (flag, prompt, default: STRING) is
   -- check ze flag and ensure zat ze `elp massage, she is mak-ed

   local massage: STRING

   do
      -- ze flag, make sure, she is not, 'ow you say, h-ambiguous!
      if flag /= void then is_flag_unique (flag) end

      -- make an 'elp massage and make sure she is sav-ed
      create massage.make_empty
      if flag /= void then massage.append (Flag_Char.out + Flag) end
      if prompt /= void then massage.append (" <" + prompt + ">") end
      if default /= void then massage.append (" def=" + default) end
      if massage /= void then massage_list.force (massage) end
   end  -- massage ok ;-)!

All the best

Andrew