Team Eiffel

Greg C has posted an open invitation to a gathering of the Bay Area Friends of Eiffel, for everyone interested in the Eiffel programming language.

The meeting is September 27, 2006 and will start at 6:30 PM, and will be held at the offices of AXA Rosenberg in Orinda CA.

Mark Howard will give an overview of important new ECMA features, especially those that will be available in the upcoming release of EiffelStudio 5.7 such as inline agents.

For further information, contact Greg C at gmc444@yahoo.com.

Bertrand Meyer has posted a new article on the EiffelWorld Column called The Challenge of Concurrency. I currently work on a project that is highly distributed. The project has about 15 processes, each with about 8 threads. We are constantly running into bugs caused by some concurrency issue we failed to foresee.

The normal developer action taken to handle concurrency is to wrap every function with a mutex. There is of course no substitute for careful design when it comes to concurrency, so the everything-gets-a-mutex solution inevitably results in hard-to-fix deadlock.

One time a developer was locking a mutex in a signal handler (yeah, we told her it was a bad idea). It would intermittently result in deadlock. Since the signal handler was running in kernel space (I think) it would bring the processor to a halt! We had a very difficult time debugging that, an effort that took an entire week. So, my team and I are very interested in an elegant solution to this complex problem.

I've struggled through the examples at the ETH SCOOP web site. I kind of understand them (although I wish there were examples without the GUI). What I have been unable to find anywhere is an explanation of the limitations of SCOOP. I don't mean limitations due to lack of implementation or support. I mean theoretical limitations. I've read that SCOOP can not support the active object model; I understand this. What I don't understand is what this means for me. Does this rule out SCOOP for my project? Can all concurrent problems be solved using SCOOP?

One thing I've learned with Eiffel is that it sometimes takes a brain retraining. I've seen many people, including myself, stating that something is impossible in Eiffel, only to find that their paradigm was the limiting factor. I'm afraid I might have a limited paradigm (packed with semaphores and mutexes) when it comes to solving concurrent problems. Fully using SCOOP might require a dramatic shift in the way multiple processors are utilized to solve problems, but I don't know. Do any of you?

A recent "Ask Slashdot" post starts with an anonymous reader looking for ways to use Design By Contract in C++. He wrote:

...I can imagine that a lot of the ideas from Eiffel can be applied there. I have looked around on the net and found a few articles talking about different ways of applying design by contract using assert statements and the like. I also found the dlib C++ library on SourceForge which, among other things, puts a design by contract face on a lot of API calls. So, there are obviously people doing it. What is everyone's experience with Design by Contract in C++? What tools are there that help make it a workable system? Lastly, are there any pitfalls to taking this approach in C++?

The discussion that followed contained plenty of suggestions (some informed, some misinformed, some humorous - this is Slashdot after all).

Brian Heilig pointed out five ways in which Eiffel's "genuine" DbC worked better than simulations in C++. Briefly, these were:

• Contract inheritance is not properly supported in C++
• You don't get fine-grained control of runtime checking in C++
• You can't use "old" in C++ assertions
• Class invariant checking should be suppressed during unqualified calls
• It's hard to support loop variants in C++

Coryoth agreed, concluding that

Eiffel is actually an extremely elegant language with powerful DbC built into at the core. If DbC is something that's important to you Eiffel probably is your best choice.

AutoTest (by Andreas Leitner and Ilinca Ciupa) is a fully-automatic testing tool for Eiffel software, based on Design by Contract. AutoTest analyses the contracts then generates and runs test cases. It tries to satisfy the preconditions whilst seeing if it can break the postconditions. Well, it does more than that, but that's the basics.

Andreas Leitner was accepted to present "AutoTest: Push Button Testing using Contracts" at Google's recent Test Automation Conference in London, and a video of his presentation can be viewed at Google Video.

SmartEiffel includes an embedded debugger. You compile your application with the -sedb option, and run it. You can then step through and inspect it by using a command-line interface.

Damian Dobroczyński wanted to wrap the SmartEiffel debugger in a GUI. Not wanting to hack the SmartEiffel source code, he looked around for the right tools for the job.

The "expect" utility is designed to talk to command-line applications: it feeds them input, and captures and analyses the output. The Tk widgets provide a quick way to knock up a graphical user interface, and the whole lot can be tied together with the TCL scripting language. And so was born the Sedbov project - the SmartEiffel Embedded Debugger Output Visualiser - a human interface to the SmartEiffel debugger.

Damian writes:

This is one of the weirdest projects I've made in my short life. I tried to make human interface to SmartEiffel embedded debugger and I proved that it is possible

The fruits of Damian's labour are a 1238-line TCL script, which produces the interface shown below (click for an enlargement):

The recent SmartEiffel fracas highlighted a situation that's been developing for more than a decade. The Eiffel community has several open source compilers, but does not yet have an open compiler.

The open-sourcing of EiffelStudio has provided an abundance of goodies to Eiffel developers, but the product directions of EiffelStudio are not set by the users of the open source edition. Naturally, the product directions are set by the need of ISE to service their commercial customers, and by the needs imposed by the use of EiffelStudio at ETH.

Similarly, the development of SmartEiffel is driven by the goals of Dominique and his team, and it's pretty clear that those goals often differ from those of the SmartEiffel users.

Visual Eiffel has been open source for a while too, yet it has a provision that patches cannot be accepted into the trunk unless they are also suitable for the proprietary edition.

A truly open Eiffel compiler, with an open development process controlled by its users, would offer many advantages. Foremost of these is that users would discover that it's actually worth their time to contribute - patches will be accepted if considered useful by the users as a whole. This creates a positive feedback loop whereby more people contribute, the product gets better, more people use the product, and even more people contribute.

Another advantage is that open projects tend to emphasize interoperability. To paraphrase something I found at rosegardenmusic.com:

Because of the spirit of openness and co-operation, there's an incentive for people working on quite different applications, libraries and tools to make them work together so as to strengthen all of the pieces.

This is quite unlike the situation we have now where each compiler has its own language and tools, and refuses to support the others.

Stay tuned...

Are you (even a little bit) familiar with the inner workings of gcc?

If so, the Visual Eiffel community would appreciate your help in making Visual Eiffel work with recent versions of gcc (4.x) under Linux. Currently, if you want to bootstrap Visual Eiffel you need to use gcc 2.95, although you don't need it just to run Visual Eiffel (or even to build Visual Eiffel if you are not bootstrapping the code generation part).

Eugene Melekhov wrote:

"the VE runtime at the moment can be compiled only by gcc 2.95 due to dependecy on gcc code generation - function prologue/epilogue, stack allocation etc."

I am offering a $200 prize to anyone who can remove the dependency on gcc 2.95 before the end of 2006.

A few fairly innocent questions by Phil Taylor on the SmartEiffel mailing list led to an extraordinary amount of vitriol from main SmartEiffel contributors. In the end, one of the main SmartEiffel users outside the inner SmartEiffel circules decided to leave as well. Roger Browne, main contributor to this blog wrote:

That creates an atmosphere in which I can't contribute usefully to SmartEiffel. Bye.

Strange how the one compiler that opened up Eiffel to the open source community is led by people who have a talent and willingness to plant the boot into the face of everyone actually using their product. Very sad.

Outside the core SmartEiffel contributors we now only have Daniel F. Moisset, the guy behind the SmartEiffel Transitional release and Cyril Adrian, who wrote in the same thread:

Note that ESE will be my last attempt to do something viable with SmartEiffel. I'm quite fed up with hearing that the project is not open enough when we have been doing all we could to open up, KNOWING THAT SmartEiffel is not easily "openable" itself since it is primarily a research project (and the lab is a bit lukewarm in that respect).

Kinda vague. Greg C., another Eiffelist who has been around, wrote:

Over two hundred messages on this one lame topic?

That's it. I'm done.

Let's just hope that the Gobo Eiffel compiler will be ready soon. Although ISE Eiffel is open source, compiling a simple program with ISE Eiffel isn't simple. And although with my new laptop compilation is fast, it wasn't with my old Pentium III 650. And ISE takes up a huge amount of disk space. The story changes of course for large programs, where ISE Eiffel is a must. Recompilation speed with ISE is blindingly fast in such cases, and painful with the SmartEiffel approach.

Labels: smarteiffel

Most open-source Eiffel projects use Subversion ("svn") for version control. Typically, the server is configured to allow anyone with an internet connection and a svn client to access the entire version control history (logs, revisions, etc).

Instead of the svn client, you can use the svk client. This enhahces the functionality of the svn client by allowing you to mirror the entire repository on your local system (and keep the two in sync). Furthermore, svk supports distributed version control - you can maintain different patched versions, and synchronise with other svk users without needing to go through the project's central Subversion server.

Svk can be used on any Subversion-hosted project; no special server settings are needed. But beware of trying to mirror the entire history of the project on your local machine. For a large or long-running project this sucks up huge amounts of bandwidth, and takes up huge amounts of space on your local machine, for data that you are unlikely to ever need.

Better is to use svk to synchronise with the latest version of the project "trunk", then to mirror forward from that point.

If you must have the entire history, it's much more efficient if you start from a history dump that has been prepared on the project server.

The level of interest in svk has been growing, and the SmartEiffel project has recognised this by offering an svk history dump for those who want it.

Instructions on using svk with the SmartEiffel repository are provided, whether you wish to use it for the trunk going forward, or for the entire project history.

My only claim to Wikipedia fame is that I wrote the oldest edit still to survive on Wikipedia, a minor edit which I made on the second day of its existence.

But some people are famous enough to have an article about them at Wikipedia, and Bertrand Meyer, inventor of Eiffel, is justifiably one of those people. In fact, there is also an article about him on the German version of Wikipedia. And something went wrong there last December...

A prankster (possibly a student) added the German translation of the following text to the entry about Bertrand Meyer:

According to the latest reports, Bertrand Meyer died on 24.12.2005 in Zurich. On 23.12.2005, exam results were published; links between that publication and his death couldn't be confirmed.

According to Wikipedia:

The hoax was reported five days later by the Heise News Ticker and the article was immediately corrected. Many major news media in Germany and Switzerland picked up on the story, creating the German Wikipedia's version of a Seigenthaler affair. Meyer went on to publish a positive evaluation of Wikipedia, concluding "The system succumbed to one of its potential flaws, and quickly healed itself. This doesn't affect the big picture. Just like those about me, rumors about Wikipedia's downfall have been grossly exaggerated."

Bertrand wrote at length about this in his January 2006 column "Defense and illustration of Wikipedia".

I chuckled at the part where Meyer writes:

McHenry ... dismisses the entry overall as a paper that "might be expected of a high school student, and at that [...] a C paper at best" (a reference to the grade, not the programming language).