Tuesday, September 26, 2006

 

Bay Area Friends of Eiffel Meeting

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.

Monday, September 25, 2006

 

Limitations of SCOOP

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?

 

EiffelBase ugliness

EiffelBase is a nice library for the beginner. But when you start working with it, you will see more and more of its ugly faces. I have recently stumbled over a feature in the FILE class that captures two of the major deficiencies at the same time:


Please note that we are not talking about a minor, unimportant feature in an seldomly used class.

The first deficiency is easily visible: we are trying a strengthen a precondition by using require else, something that just does not work in DbC. It is just wrong. It shows that inheritance was used inapproprately (Why is a FILE a SEQUENCE? Why does SEQUENCE not offer an opaque precondition for append? We are talking about two classes from the same library!).

But the second problem is even more irritating: why do we need to pass two closed files? Normally we append to already open files. In my case, I wanted to write some output to a file, append another one, then continue writing, perhaps appending a second one and then close the final result. Instead, I have to write to a file, close it only for append, directly open it afterwards, and so on. EiffelBase does too much for the user, and by this limits the reusablity of the library.

Labels:


Sunday, September 24, 2006

 

Slashdot considers DbC for C++

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:
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.

Friday, September 22, 2006

 

AutoTest presentation at Google conference

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.


 

The right tool for the job

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):


Thursday, September 21, 2006

 

Do users need a truly open Eiffel compiler?

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...

Wednesday, September 20, 2006

 

$200 prize for someone familiar with gcc


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.

Monday, September 18, 2006

 

Whither SmartEiffel?

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:


 

Eiffel repositories and svk version control

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.

Friday, September 15, 2006

 

The Power of DBC

I hadn't changed any code since my last successful test run so I wasn't expecting an error. I was puzzled when the debugger reported a stack overflow. Within minutes I realized the problem. In an object like:

MY_CONTENT

parent: MY_CONTENT

the reference to parent was set to Current. Obviously, some of my new content was being imported improperly. I felt panic rise in my stomach. My content import code is complex and hadn't changed in a while; I had no idea where to look for the problem. The panic quickly gave way to relief when I realized it was just a missing invariant. I added:

invariant

valid_parent: parent /= Void implies not parent = Current

and re-ran my content import program.

Bingo

Thursday, September 14, 2006

 

Rumours of Bertrand Meyer's death were exaggerated

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).

This page is powered by Blogger. Isn't yours?