Monday, July 31, 2006

 

ECMA Eiffel 2nd Edition


A second edition of ECMA Eiffel, dated June 2006, has been published (PDF). It has been adopted by the General Assembly of ECMA as ECMA-367, and by ISO as ISO standard 25436.

From the document:
The First Edition was completed in April of 2005 and approved by the General Assembly of ECMA in June of 2005. As a result, authors of major Eiffel compilers and tools have committed to supporting the language as described in the Standard; compilers are quickly progressing towards full compliance. The present Second Edition introduces no major change of substance but clarifies and corrects a number of points arising from the experience of using the First Edition and from the feedback of compiler writers and the user community
...
To produce this Standard, TC39-TG4 conducted: 18 face-to-face meetings (15 up to the First Edition), most of them over three full days; numerous phone meetings; and extensive technical correspondence (about 1500 email messages by June 2006).
I cannot find any list of changes between the first and second editions.

 

Coffee: blessing or curse?

I could not sleep this night, for having swallowed way too much coffee last evening. So I coded instead.

My mind found the solution for simply integrating forthcoming SE extensions (esp. ESE) without having to re-parse and re-write SE's main config file.
Well, in fact, I did not invent the solution. Others did, Debian in particular.

The principle is to replace a simple configuration file with a configuration directory, with a priority system (of course, configuration files are still supported). I coded it all this night.

Now, SmartEiffel users will be able to:
And it will help distro package maintainers too. All I have left to do is to fix the installer to take that into account.

Eiffel is cool. SE 2.3 will be cooler yet :-)

Friday, July 28, 2006

 

Open Source Survey

Till G Bay, from ETH Zurich, has asked me to post this survey request on behalf of Professor Brian Fitzgerald. The survey explores the interaction between a "company" such as Eiffel Software (ISE) or, I suppose, Loria and an open source community (such as the community of ISE Eiffel or SmartEiffel users/developers).

The survey took me less than five minutes to complete. If you choose to supply your name and email address you are entered into the draw for a Nokia internet tablet.

Professor Fitzgerald writes:
Free/Libre/Open Source Software (FLOSS) has in many ways revolutionised software development. We have recently seen a new mode of outsourcing, what we term 'open-sourcing', whereby companies seek to grow a community of open source developers around what has typically (but not always) been a proprietary product previously. Both the company and the developer community have mutual expectations of each other, and if these are not fulfilled, the initiative may not be successful.
We have derived a set of expectations for successful open-sourcing and would like your feedback on these at http://www.calibre.ie/survey/index.php

Wednesday, July 26, 2006

 

Eiffel Shared Libraries and Incremental Compilation

As a previous C user, and now addicted Eiffel user, I have been thinking about and working on improvements in Eiffel tools and libraries, and I think that there are some aspects of C program building that Eiffel should adopt.

I wish Eiffel to be seen as a possible primary language choice, not just for single, isolated, projects but for all-encompassing packages like KDE/Gnome etc, and there is one major roadblock in the way of that choice.

Some 20 years ago, it was recognized that with all programs being statically linked, the file system and RAM/Swap have needless duplication of identical code for each of thousands of distinct programs. This is a performance issue, in that for most programs the library code is most of the application, say 80%, so that a given size of RAM can support 4-5 times the number of processes (not swapping) with shared libraries than it could without.

There is a performance loss, for a single program, in using shared library technology, but the gain in loading from disk only the 20% of code not in the library is substantial.

Once multiple shared libraries are available, then the following is feasible:

Load library L1, containing classes A, B, C etc
Load library L2, containing (updated) class B
Register classes from library L1
Register classes from library L2, overriding/hiding class B in L1
For each registered class, allocate class IDs and register routines and attribute offsets etc
Proceed through creation of root class instance ...

The above provides for incremental compilation during program development, enables libraries to be shared by distinct programs, and makes possible the dynamic loading at run-time of additional libraries containing classes that inherit from classes present in the base library class set, making possible what is now possible in Java but not in Eiffel.

I think there are lessons to learn from what has been achieved with C/C++/Java infrastructure, if not from their syntax and semantics! Let the discussion commence...

Monday, July 24, 2006

 

Which SmartEiffel release do you use?

Cyril Adrian (from the SmartEiffel team) is planning to package SmartEiffel and started an online poll to know which version of SmartEiffel people are using most.
I find this an interesting question, beyond the issue of packaging; Berend and I had a recent discussion about usage trends of SmartEiffel versions on #eiffel.

The poll is at http://cadrian.freepolls.com/cgi-bin/polls/001/poll_center.htm

Friday, July 21, 2006

 

OSI and the Eiffel Forum License

The Open Source Initiative is "a non-profit corporation dedicated to managing and promoting the Open Source Definition". One of the things they do is to certify software licenses as open-source, which means that the license complies with OSI's Open Source Definition.

OSI certification became important for getting software accepted into open source software distributions such as Debian Linux. Although the Eiffel Forum Freeware License pre-dated OSI by a few years, it became desirable to get them to certify the EFFL as an open-source license. This took a few years of bureaucratic haggling with OSI, but we got there in the end.

Later, the Eiffel Forum License version 2 was created. It was more liberal than the EFFL, so that EFL2-licensed software could be incorporated into GPL-licensed projects. Unlike the EFFL, the EFL2 is pretty similar to the liberal MIT and BSD licenses. The Free Software Foundation confirmed that the EFL2 was GPL-compatible, and OSI certified it as "open source".

For the last year or so, OSI has been pondering the proliferation of open source software licenses. One downside of having so many licenses is that it can hinder software re-use. There are two reasons for this. The first reason is that licenses sometimes have incompatible terms, and software covered by them cannot be legally combined.

The second problem hindering re-use of software covered by many difference licenses is that many organizations are cautious by nature and feel unable to use software under a new license until their lawyers have checked it out at great expense. Clearly, this problem is compounded by the sheer volume of open source licenses that now exist.

It's no surprise that OSI has concluded that the ELF2 license is redundant. This doesn't mean that the EFL2 will lose its open-source certification, it just means that OSI thinks the license is not a useful alternative to other more popular licenses.

Berend de Boer has opened a discussion about this on the NICE-Discuss mailing list. He writes:
Minimising licenses is obviously a good goal and it helps code sharing. On the other hand everyone knows the Eiffel Forum License and many in the Eiffel community use it.
You may wish to hop over there to post your comments.

Wednesday, July 19, 2006

 

Even spammers now mention Eiffel

As the actual operation of my spam filter can best be described as: if it's not on your white list it is spam (although I'm sure the design requirements are entirely different), I regularly go through my spam to check if there's something I've unintentionally discarded. And occasionally I search the subjects for particular keywords to make sure I haven't missed anything.

One of the keywords I use is Eiffel. That turned up two hits today. I can now buy a patch that will make a certain body organ bigger than the Eiffel Tower. Boy, will my wife be "happily" surprised...

 

EJAX HTML controls

I'm a big fan of the approach of using progressive enhancement to build websites. In short this approach builds websites that begin with content/markup (HTML), use CSS to change the style and presentation, and use JavaScript to add behaviour. If you have to support IE with its limited support for CSS you might have to twist your content a bit, but with a decent browser this approach works very well. It will lead to websites that work everywhere and even work when JavaScript is disabled. It will give you quite a bit of guidenance in building robust websites, believe me.

This is also the approach that one should take with HTML controls and capabilities like auto complete support that are possible with AJAX techniques. Make sure the control works when JavaScript is disabled. Use CSS to make it look nice. Use JavaScript to make it work better.

The question is how to add these additional capabilities to HTML. Because in the end, the browser reads and interprets HTML. It uses CSS for the styling and JavaScript for the behaviour. That's how this environment works. And programmers should not be shielded from that. That is how the web really works. Having some magic to make it appear that this isn't the case is very detrimental to any programmer's internal model of how web applications work.

I've occassion these days to do a lot of work with Visual Studio 2005, C#, ASP.NET and Atlas. And the result is horrible. Microsoft's behaviour can be best explained if you believe that they want lock-in. It explains why they will try to shield you from HTML, CSS and JavaScript. They allow absolute positioning of controls. A favorite technique in examples. Because drag/drop of controls works better that way. Woo the programmer who tries such a website on anything else than a pair of perfect eyes, perfect color perception, IE and the screen size of the original programmer. The web isn't a Win32 Visual Basic app. Making it appear so, will only lead people to build an internal model of web programming that is fundamentally untrue.

The same is true for Microsoft's postback approach. How many websites work somewhat fine on intranet and then fundamentally fail on the internet? Again, Microsoft Visual Studio's approach is to give the programmer the idea he is building a Win32 form. He isn't.

And then the controls. You have all those Microsoft controls like asp:Button. What's that? Is it an HTML button? Something else? You set its properties using background color and such. And that doesn't end up in some CSS style sheet let me tell you that. Programmer doesn't need to know CSS because this is just a win32 form.

And then the Atlas toolkit. Exactly how one shouldn't design a toolkit unless you want to shield programmers even more. For example you can extend an existing control with auto complete support. It's supposedly declarative (another rant, I promise). The good thing is that you can extend a normal HTML input. The bad thing is that you have to write that support in some declarative JavaScript, called XMLScript (good luck finding any documentation on that) or with using an atlas:AutoCompleteExtender element in your source. Copy and paste some sample code and things work. That's cool. But how does it all work? The last thing Microsoft wants you to learn is HTML and JavaScript. You have to be shielded from that you know. Instead of JavaScript you write XMLScript. And when ignorance is bliss I suppose this will do.

But sometimes you get paid to take the red pill. And you will need to dynamically, at the client, create an input control and it should get AutoComplete behaviour. And while the mirror starts dissolving you have to take the plunge into how stuff really works.

No need for pills and ignorance does get you nowhere. That summarises EJAX's fundamental approach to HTML controls. It is an explicit design goal to not shield the programmer from the underlying mechanisms. Controls should work such that they guide the programmer into building the proper internal model. This to allow the programmer to easily use the control outside the presented toy example. Create some dynamic HTML? Even if the toy example presented static HTML it should be intuitively clear how to apply that knowledge for that scenario as well. And for returning HTML by some AJAX call, etc. So the control is HTML. The behaviour is applied with a JavaScript call.

Tuesday, July 18, 2006

 

SCons Builder for EiffelStudio 5.6

SCons is an alternative to make. It's cross-platform and, because it's scripted in a general-purpose programming language (Python), it's extremely flexible.

I've written a SCons tool to automate EiffelStudio 5.6 builds. It probably also works with 5.5, 5.4, etc., but I've only tested it with 5.6 on Windows and on Mac OS X 10.4.7.

It definitely won't work with EiffelStudio 5.7, which replaces the venerable .ace file with the shiny new .ecf file. I'll also have to update my SCons tool when I upgrade to 5.7.

If you're frustrated with make files, give SCons a go.

Saturday, July 15, 2006

 

Enterprise SmartEiffel (ESE) project news

Cyril Adrian writes, on the SmartEiffel mailing list:
Thanks to some fixes in SmartEiffel the XML backend of EDC now fully works (storage and retrieval of relational data in an XML database).
The ARG cluster has been improved and now works in most normal cases. This cluster is used to parse a command line.
The ESEB tool is not yet functional but code writing is hot those days. ESEB is the ESE Binder that builds classes that represent the tree of a provided DTD file (something like JAXB for java people) and an XML parser for such files. This tool will be useful to build other tools that will use XML files.
http://ese.sourceforge.net - see you there!

Friday, July 14, 2006

 

EJAX parameter validation

A verb operating on a resource can take zero or more parameters. EJAX has three levels of parameter validation. The first level is entirely browser based and fires if JavaScript is active. The EJAX frameworks spits out a JSON description of the parameters. This looks like this:
var my_form_parameters_text = {
system_id:
{type: "positiveInteger"},
company_name:
{type: "string", maxLength: 256, whiteSpace: "collapse"},
contact_name:
{type: "string", maxLength: 256, whiteSpace: "collapse"},
email:
{type: "string", minLength: 1, maxLength: 256, whiteSpace: "collapse"},
password:
{type: "string", minLength: 1, maxLength: 32, whiteSpace: "collapse"},
password2:
{type: "string", maxLength: 32, whiteSpace: "collapse"},
address1:
{type: "string", maxLength: 256, whiteSpace: "collapse"},
address2:
{type: "string", maxLength: 256, whiteSpace: "collapse"},
city:
{type: "string", maxLength: 256, whiteSpace: "collapse"},
state:
{type: "string", maxLength: 256, whiteSpace: "collapse"},
zip:
{type: "string", maxLength: 16, whiteSpace: "collapse"},
country:
{type: "string", maxLength: 256, whiteSpace: "collapse"},
...
It's pretty equal to the parameter description for the resource. The EJAX.FORM.validate routine in ejax.js can take such a description and validate the controls, match the id in the parameters description against the contents of the controls. If an error occurs, the control is focused and an error message is displayed near it.

This validation isn't always enough. For example password validation cannot be done in this manner. So there is a second level validation as well. This is a collaboration between the browser and the client, again, only if JavaScript is enabled. It takes the contents of all form controls using prototype.js' Form.serialize() and sends it to the action specified in the form. But with one twist: it adds the ejax:validate parameter. When this input is found by the EJAX generated resource classes they will only validate the control and just return a response code such as 200 OK or 400 Form invalid. The error response contains a detailed description of what control had the wrong input and what the user should do to fix it.

If JavaScript is disabled, or if the form is still submitted, or if some malicous program tries to send bad data to an EJAX resource the third level of validation comes into play. This is the final defense and takes place at the server. It simply validates the given user input against the specified parameter data types, before any other action will take place.

Monday, July 10, 2006

 

BAFOE Meeting Minutes for July

Minutes of the 27 June 2006 Gathering of the Bay Area Friends of Eiffel

Attendance was good, especially given the very short notice given for the meeting. Again I apologize, I'd recently returned from Asia, and several of the people who wanted to attend were leaving the US at the end of that week.

Emmanuel Bouyer gave a very nice presentation on concurrent processing and Eiffel. Emmanuel began with a discussion of the limitations the current SCOOP specification. He explained in particular why SCOOP could not be used to implement Eiflex.

He then presented an overview of the Eiflex distributed object framework. The Eiflex framework provides a reliable platform-independent, multithreaded client/server architecture and is the basis of the Chicago Board of Trade's PRICE system.

Emmanuel then ran a "Dining Philosophers" demonstration that involved a GUI client and two server processes. One important aspect of the demo was the fault tolerance. You can kill the servers, but when they are restarted they will carry on where they left off, having preserved their state. Eiflex is highly also scalable. At CBOT, Windows clients connect to over one hundred Solaris servers, with each server running two hundred or more threads.

After Emmanuel's presentation, the gatherers congratulated Eric and Karine on their wedding, spent a little time surfing the Team Eiffel blog for interesting tidbits, and talked about what is going on with the various Open Source Eiffel projects around the world.

The next meeting will be held in September (too many people are traveling in August). I promise to give earlier advance notice.

Future meetings will be every other month, with a special effort to overlap with visits by Eric and Karine.

Emmanuel's presentations were based on those made by Gordon Jones (Emmanuel's partner at Eiflex) for a conference at York University in the UK.
http://www.artist-embedded.org/FP6/ARTIST2Events/Events/Cordie06/

More information about Eiflex can be found here:
http://www.eiflex.com/

The Team Eiffel blog is here:
http://teameiffel.blogspot.com/

A good starting point for more information about Eiffel is at Cetus Links:
http://www.cetus-links.org/oo_eiffel.html

Don't miss future announcements! You can subscribe to the BAFOEiffel mailing list,
http://groups.yahoo.com/group/BAFOEiffel/

by sending an email to BAFOEiffel-subscribe@yahoogroups.com


Sunday, July 09, 2006

 

Seeking Eiffel and VB.net programmer

Brother Bill is seeking an additional programmer for a project in Lilburn Georgia (Northeast Atlanta), between Lake Lanier and Stone Mountain.

The project uses Visual Basic.net for the front end, and EiffelStudio for the database end.

The candidate will have experience in VB.net and an interest in Eiffel. Brother Bill writes:
The project is challenging. There is a lot of code to grind out, and this may be a good opportunity for an unemployed developer.
The pay will be low, but on completion, will most likely get some kind of real profit sharing.

Saturday, July 08, 2006

 

EiffelStudio Precompiled Libraries

Day-to-day compiling in EiffelStudio (known as melting) is very quick, but doing a full rebuild of a project (a freeze or a finalize) is very slow compared with a lot of other programming languages.

If the project uses a lot of big libraries like gobo or vision2, then it's unbearably slow.

Some months after I started using EiffelStudio 5.5, I discovered that I could speed up my builds by making my own precompiled libraries. I had been using the precompiled libraries (base, wel and vision2) that are part of the EiffelStudio installation. Making my own precompiled library that included many of the gobo clusters sped the builds up significantly. This remained true when I upgraded to EiffelStudio 5.6.

Back then, I was building .NET Eiffel projects. These days I'm building classic Eiffel projects on Windows. Naturally, having learned the benefits of precompiled libraries, I did the same as I had done on the earlier project.

I was disappointed, though, to find that my eleven projects continued taking about thirty minutes to build, despite using proecompiled libraries. As well as adding gobo, I added some of our own more stable clusters to a precompiled library. It didn't help.

So I did some timings, with different sets of precompiled libraries, of how long it took to finalize and then finish freezing the eleven projects.
The builds were all done at the command line with EiffelStudio 5.6.1218 and Microsoft C/C++ 14.00.50727.42 32-bit for 80x86:


ec -batch -ace file -project_path path -finalize -keep -c_compile
finish_freezing -silent














ProjectBuild ABuild BBuild C
precompiled libs4m 23s4m 16snil
app 14m 06s4m 23s4m 49s
app 23m 59s4m 50s3m 52s
app 31m 57s2m 00s1m 57s
app 42m 25s2m 32s2m 56s
app 53m 03s1m 36s2m 03s
app 62m 38s2m 29s2m 52s
app 72m 53s2m 37s2m 58s
app 82m 37s2m 12s2m 41s
app 92m 32s2m 14s2m 48s
app 102m 43s2m 19s2m 50s
app 112m 46s2m 19s2m 47s
TOTAL for apps30m 39s29m 31s32m 33s

So precompiling my classic EiffelStudio projects on Windows saved me 3 minutes (about 10%). Build B (the precompiled base+time+gobo+wel) performed best. I would have to re-run these tests to be sure that there wasn't some other factor coming into play, but I was careful to leave the computer alone whilst it ran each build.

Not using precompiled libraries adds a lot to the time spent doing C compilation and linking. There must be a big saving in the earlier Eiffel compilation stages to compensate for this, especially considering that the C compilation is being done twice (once to finalize, and again to finish freezing).

Also note that, if you take into account that building the precompiled libraries took more than 4 minutes in both cases, not precompiling is actually 1 or 2 minutes faster! The fallacy in this argument is that precompiling is done only once, of course.

Based on these timings, I would be happy not to use precompiled libraries at all if there is a compelling reason not to.

Is executable size a compelling reason? I don't care about exe size these days -- we can afford to waste a few megabytes, and 10 Mb exes seem to load instantly -- but it's interesting to note that the exes from Build C (without precompiled libraries) add up to 58,744,832 bytes; whereas Build B adds up to 66,150,400 bytes. For now, we're sticking with Build B.

Thursday, July 06, 2006

 

Indexing clauses and syntax errors

EiffelStudio supports an extension that allows multiple indexing clauses within an Eiffel class. You can have one at the top of the class, plus one at the bottom of the class, and you can also write an indexing clause for any feature of the class.

This can lead to a syntax error, which has become a "Frequently Asked Question" over on the es-devel mailing list. Consider the following code:
class A
...
feature -- Test
test: ANY
-- Test
indexing
...
end -- class A
How does the compiler know whether this indexing clause is the "end-of-class" indexing clause, or the one associated with the attribute 'test'?

The compiler can't tell, and it throws a syntax error. You can fix this with a judiciously-placed semicolon, for example:
class A
...
feature -- Test
test: ANY;
-- Test
indexing
...
end -- class A
Now, the indexing clause is taken to be the "end-of-class" indexing clause.

ECMA Eiffel does not have this ambiguity, because it does not support the "indexing" clause. Instead, it supports the "Notes" construct, which uses the "note" keyword. This construct can appear at the top or bottom of a class, but not with a feature.

Tuesday, July 04, 2006

 

The Zen of Python - Part II

This is a followup to a previous post titled The Zen of Python - Part I. If you are lazy to read that introduction, this is about some Python design principles analyzed from an Eiffel perspective and comparing it with other languages (specially python itself).

Beautiful is better than ugly

I will not write much about this one. It is about a very subjective idea (beauty) and the assertion is mostly tautological in nature: who would say that ugliness is better? Eiffel users think that Eiffel is beautiful, but most advocates of any language think that of their language.

Anyway, even when almost anyone would agree with "beautiful is better than ugly", a lot of language communities consider beauty as a secondary feature, and one of the first things being traded for other valued attributes (efficiency, compactness, sheer number of features).

Eiffel and Python were designed to be beautiful. At least beauty in the sense of elegant (simple problems should have simple solutions), simple (a term that in engineering, and software engineering in particular, is almost a synonym of beautiful), readable. Most of these will be covered later in this article or in later ones.

Explicit is better than implicit

This rule describes Eiffel more faithfully than Python. After all, static typing, Design by Contract are language features which provide a way to describe more explicitly the semantic interface of routines. Which one do you find more explicit,


def get_prefix(size):

or


prefix (size: INTEGER): STRING is
require
size >= 0
ensure
Result /= Void
Result.count = size.min (count)

?

Other examples of explicitness are having to indicate when redefining a feature (which could be done automatically, but could let slip some obscure bugs), or when a contract is being redefined (the "require else" and "ensure then" clauses). In this aspect perhaps Eiffel is more pythonic than Python.

Python is very clean in the sense that, despite not forcing too much explicitness, it requires a minimum of it in every place. I can not imagine now a Python example where an operation is done without being requested.

Eiffel is mostly that way, but in some places it has had some historical ambiguities that have context dependent semantics. The main one is the different expanded/reference attachment semantics; an a := b statement sometimes creates an object, sometimes overwrites the contents of one, and sometimes reattaches a reference to an existing object. The SmartEiffel dialect have solved this at the cost of making some abstractions difficult (because of breaking the inheritance tree). This has always been a tricky side of Eiffel.

Implicit rules of conversion is another weak point that has had recent changes. Basic predefined types (integer, floating point values) had certain "magic" behind providing type conversion behind the scenes that was something that no user defined type could do, and was not explicit watching the interfaces of classes like INTEGER or REAL. The ISE proposal (included at ECMA) of removing magic convertions and allowing the class to explicitly add conversion routines seems a much better way to do it.

In conclusion... Eiffel has been very pythonic (much more than Python) but with some design issues that are being addressed.


Monday, July 03, 2006

 

Inline Agents implemented for EiffelStudio

The July 2nd 2006 Interim Release of EiffelStudio 5.7 (Build 5.7.60907) supports the much-anticipated "inline agents". An inline agent is a deferred call that can be coded "inline" without needing to create a new routine. (I implemented inline agents in the Amber Scripting Language and found them very satisfying to use - they were very easy to use and delivered a high "bang per line of code".)

Inline agents are pretty much like unnamed features. They can have all the trappings of a feature such as preconditions and postconditions. If you're not familiar with them, you can find out more in section 8.27 of the ECMA Eiffel specification.

There are a few limitations to the current EiffelStudio implementation of inline agents:
In addition, regular "call agents" have been enhanced - they can now be attributes or externals.

Also in release 5.7.60907 is wild card support for code completion.

Sunday, July 02, 2006

 

EJAX: GET on a resource

EJAX recognises two kinds of resources: static ones, for example an HTML page but also anything made available outside the EJAX frame. A static resource looks like this:
<resource name="quote">
<url>/quote/car.html</url>
<get>
<representation content-type="text/html">
<static-page>
<filename>car.html</filename>
</static-page>
</representation>
</get>
</resource>
Note the representation option. Clients can request a resource in various formats, for example HTML for people and XML for machines.

The opposite of a static resource is a dynamic resource. Such representations are created dynamically. Example:
<resource name="quote">
<url>/quote/car.html</url>
<get>
<representation content-type="text/html">
<dynamic-page>
<html-template>car.html</html-template>
<response-collection>
<response-name>car-detail</response-name>
<response-name>options</response-name>
</response-collection>
</dynamic-page>
</representation>
</get>
</resource>
Not a lot is going on here, and that is on purpose. The real work happens in the creation of the individual response. In EJAX a page resource is just replacing elements in an HTML file with parts received elsewhere.

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