Team Eiffel

The Windows Eiffel Library (part of EiffelStudio) is migrating to Unicode. Here's a summary of the migration strategy:

• Starting from the 5.7.0826 development release, WEL has switched from being ASCII based to Unicode.
• All WEL routines that used to have an argument of STRING have been changed to STRING_GENERAL, which is a common ancestor to STRING and STRING_32 (the Unicode version of STRING).
• All WEL queries whose return type was STRING now return a STRING_32.
• For the 5.7 release, STRING_32 will convert to STRING.
• In the 5.8 release, this conversion will be made obsolete and in 5.9 it will be gone.
• This gives users some time to migrate their code.
• The migration strategy page at the EiffelStudio wiki gives more details, and describes handling for cases where STRING was used as an actual generic parameter

Although I'm not currently running Windows, back in the day I did use WEL and found it to be the most solid Eiffel Windows library that I had encountered.

The ISE website contains a puff piece listing a whole bunch of cool ways to use Eiffel.

Some of the bullet points will be familiar to most of us ("Easily add contracts to classes for robust, unbreakable code"). Some of them may be new to some people ("Do multiple and repeated inheritance from .NET classes, just as if they were Eiffel classes", "Contain WinForms components in EiffelVision2 and vice-versa", "Use DBC transparently across COM servers"). Some of them might stretch the imagination a little ("Easily track down bugs at execution without debugging and almost without cost", "Create your business model and then use it directly to implement").

But amongst the 38 "Cool Things" there are sure to be some nifty ways of using Eiffel that you haven't yet explored.

David Hollenberg noticed that EiffelStudio 5.7 is accepting the following code fragment. Although the compiler emits two VWEQ warnings, the fragment compiles and runs (printing "False" twice):

local
   a: INTEGER
   b: BOOLEAN
do
   print (3 = True)
   print (a = b)
end

David asked (on the EiffelStudio Developers mailing list):

Is this really allowed by ECMA-367 or does the compiler have a problem? If ECMA-367 allows this, should it?

Bertrand Meyer replied:

This is permitted by the ECMA language definition. The matter was discussed at length in the committee over several meetings; the deciding point was that it's not quite realistic to enforce the earlier rule that the type of either of the arguments should conform to the other. This prevents comparing objects of types C and D, both of which conform to both of A and B, but not to each other. Then variables of these types can actually be attached to the same object.

The definition of x = y for reference semantics (see 8.21.3 in the standard) is that x and y are attached to the same object. For expanded semantics as in your example, it's that they are attached to equal objects, where equal objects must have both the same type and the same value.

In the end it was felt that one should be able to ask a question, without first asking the question of whether one may ask the question.

I must admit that I did a double-take at the above sentence: isn't that what static typing is all about?

Bertrand continues:

There could have been a special rule for the expanded case -- since we know in advance that there is no conformance and that the result will always be False -- but this seemed to complicate the rules too much.

As a general rule I am wary of relying on warnings but this seems to be a valid use for them: an indication by the compiler that things are not necessarily wrong but that the construction is unusual and needs to be checked.

(this is a copy of the mail sent to the SmartEiffel user list)

It begins to work!

A first tool already exists, which will be used to build other ESE tools - but you can use it too.

It is called ESEB (ESE Binder); it takes a DTD file and produces a bunch of classes that parse the corresponding XML files and build the corresponding tree.

I also wrote the ESE installer. It is quite rough still but uses the most recent SmartEiffel configuration handling which uses directories instead of a single plain file. This feature will also be very convenient for packagers (Debian and such).

Everything happens there: http://ese.sourceforge.net

Happy hacking,

Cyril

For some months, a command completion utility for SmartEiffel has been available. Now EiffelStudio users have a similar tool, thanks to Patrick Ruckstuhl.

Command completion works with the ec command-line compiler under the bash shell, and enables you to type in just the first few letters of options such as -quick_melt and -precompile.

Patrick's bash autocompletion script can be found in the EiffelStudio subversion repository.

Till G Bay has announced the release of version 0.9.0 ("kingfisher") of his EiffelMedia package.

EiffelMedia wraps the SDL graphics library to allow Eiffel to be used to develop multimedia applications that use video, audio, mouse, keyboard, joystick, CD-ROM etc.

New in this version is support for procedural texture generation, and an improved 3D API. There are new examples, and EM_SURFACE can now save to PNG files. The EiffelMedia Vision2 widget no longer requires a patched SDL on Windows. Code changes have been made for EiffelStudio 5.7 compatibility.

(EiffelMedia entry at EiffelZone.com)

Yesterday my co-worker and I were struggling to get data into and out of our embedded system because of a lack of PC software. We have several Linux boxes but they all have some security software that prevents us from accessing the serial port unless the administrator sets up a configuration file. The Windows boxes come installed with Hyper Terminal which is great for displaying data received from a serial port, but not so good at sending data into a serial port. Our options were:

1. Call the administrator to have him set up a mini-com configuration file
2. Call the administrator to have him install Procomm assuming we have a license.
3. Code it in Eiffel!

I told my co-worker I was going to code it in Eiffel and I'd be back in 10 minutes. 15 minutes later I arrived with a full duplex terminal I developed using secom. The program was fully tested and came equipped with proper error and exception handling. It was fully configurable via command line parameters. And it almost worked the first time (the embedded system wanted CR/LF when I was only sending it LF).

In all fairness most of what I needed (command line parsing and error handling) was already coded in a secom example. I just modified this example to get what I wanted. It's possible I could have modified some C++ program I had that did most of what I needed. But for some reason, more often than not, I just don't get this kind of reuse from my C++ code. Chances are something would have snagged me if I was re-writing a C++ program. And it's not that I haven't tried to write good C++ code, I have! Anyway, the best part of this story is my co-worker's response to seeing the code: "This is Eiffel code? Are those comments?" To which I responded, "No man, that's code." "Woa."

The component model of software is a necessity for the advancement of software development. Without it we are doomed to make the same mistakes over and over. Eiffel supports the component model very well (or at least it lays a rock solid foundation). The advantage of the Eiffel language and style is that they support a truly open approach. Joe Coder can quickly get reuse from Eiffel code because it is designed to be so reusable, to anyone. So keep those reusable components coming!

Since the open sourcing of EiffelStudio everybody has now also access to all those exciting interim releases of EiffelStudio via http://eiffelsoftware.origo.ethz.ch/downloads/builds/.

With the ability to have a peak at the very latest features also comes the burden of constantly installing and switching between all those versions. Bernd and I hacked together a little script that simplifies both installing and switching between the various versions. The script is called estudio_tools.sh . Just safe it somewhere on your (Unix) machine and source it in your .bashrc. This will give you two new commands:

# install_estudio [version]
#   
#      Installs the given version of Eiffel Studio. It first
#      downloads the version and then unpacks it into ${LOCAL_ROOT}
#      (see configuration section below). When no version is given the
#      function lists the installable versions. When the version "default"
#      is given it installs the latest version. Note that this function
#      does not set any environment variables neccessary to run
#      EiffelStudio. To accomplish this have a look at the function
#      `activate_estudio'.
#    
# activate_estudio [version]
#
#      Activates the given version of Eiffel Studio. It sets/changes
#      the environment variables ${ISE_EIFFEL}, ${ISE_LIBRARY}, and
#      ${PATH}. When no version is given the function lists the installed
#      version of EiffelStudio. When the version "default" is given the latest
#      version will be activated.

I have the following in my .bashrc:

source /usr/local/bin/estudio_tools.sh
activate_estudio default

The above first loads the function definitions and then activates the default EiffelStudio version. But let's see what the commands do on an clean and empty system. After sourcing estudio_tools.sh on a clean system invoking install_estudio yields the following (today):

$ install_estudio
57_gpl_62110

This means that the only installable version is 57_gpl_62110. I can then install this version via:

$ install_estudio default
Downloading EiffelStudio version 57_gpl_62110 ...
Finished download.
Unpacking EiffelStudio version 57_gpl_62110 ...
Finished unpacking.

Now the requested version of EiffelStudio is installed but not ready to use. We still have to set a few environment variables. But first lets use activate_estudio to verify this version is installed:

$ activate_estudio
57_gpl_62110

And indeed the version is installed. What is left now is to activate this version. Note that you will have to activate for every shell-session a new.

$ activate_estudio default
aleitner@bruck:~$ ec -version
ISE EiffelStudio version 5.7.62110 GPL Edition

The tool is very unintrusive. It simply installs all versions into a common directory. This directory (and some other details) can be changed by editing the the top part of the script. Chances are that if you already have such a directory where you store the various versions you can just reuse this directory. The script will probably recognize your old installations and offer you to install new ones too.

have fun,
Andreas

I've been in contact with OSI legal affairs and told them we in the Eiffel community considered switching to MIT. I asked them for any ramifications. Their response:

The only substantial legal difference I would ask you about is that the MIT license says "free of charge" and the EFLv2 doesn't mention this at all. Is the "free of charge" verbiage OK with the community? I don't think it precludes people from charging for software if they offer something more such as support, etc.

EFLv2 also suggests things that the MIT license doesn't (it suggests distributing changed software needed by a program that is distributed) but since it doesn't REQUIRE that people do this, and people can still do it if they want, I see no legal difference there.

I don't see any issues with combining the licenses. Is there something specific that you're concerned about?

So basically combining MIT with EFLv2 libraries isn't an issue. She mentions two other issues we might want to think about.