by Jocelyn Fiat (modified: 2015 Oct 16)

From new libraries, functionalities, contributions , and events, check out the latest happenings within the Eiffel Community:

  • 2016, Dec 12
    The longest flight

    The Orbitz page for booking a flight itinerary has an interesting menu option: Longest duration? If you find that the direct route is too short, you can always add a stop in Vladivostok. Under a few basic assumptions it has to be a theorem that, given any itinerary from A to B, there exists a […]

    The post The longest flight appeared first on Bertrand Meyer's technology+ blog.

  • 2016, Nov 21
    From our “Problems you would like to have” department
  • 2016, Nov 14
    Ubu Roi
  • 2016, Sep 21
    AutoProof workshop: Verification As a Matter of Course

    The AutoProof technology pursues the goal of “Verification As a Matter Of Course”, integrated into the EVE development environment. (The AutoProof  project page here; see particularly the online interactive tutorial.) A one-day workshop devoted to the existing AutoProof and current development will take place on October 1 near Toulouse in France. It is an informal […]

    The post AutoProof workshop: Verification As a Matter of Course appeared first on Bertrand Meyer's technology+ blog.

  • 2016, Sep 01
    Agile MOOC starts this week

    In spite of all the interest in both agile methods and MOOCs (Massive Open Online Courses) there are few courses on agile methods; I know only of some specialized MOOCs focused on a particular language or method. I produced for EdX, with the help of Marco Piccioni, a new MOOC entitled Agile Software Development. It […]

    The post Agile MOOC starts this week appeared first on Bertrand Meyer's technology+ blog.

  • 2016, Aug 08
    A DJ tool written in Eiffel

    Hi all,

    one of my hobbies is dancing Argentine tango, and I also like to DJ for tango events. I compose my playlists using the Rhythmbox media player and then export them to an Android device to take to the event.

    Over the last 8 years or so I have been developing a DJ tool called "EL Rhythmbox". It is designed to be used as an adjunct to the Rhythmbox music player and has some features of particular interest to Tango DJs, creating cortinas for example. (Musical interludes between dance sets)

    However it is not a plugin and needs to be run separately to the media player. It is distributed as an example program for Eiffel-Loop. I have only recently gotten around to documenting it properly.

    An overview of the what the tool does can be found here:


    and the manual is here:


  • 2016, Jul 27
    Eiffel-Loop news 27th July 2016

    Version 1.4.1 release

    Eiffel-Loop on Github release 1.4.1

    Documentation Project

    New Module Descriptions

    There are now descriptions of 20 modules on the The plan is to contribute at least 5 new ones per week, as well as adding to the class notes.

    Evolicity Text Substitution Language

    An overview of the Evolicity language can found here.

    A short guide on how to use it can be found in the source page for class EVOLICITY_SERIALIZEABLE.


    The Eiffel-View publisher now automatically generates a library contents page in Github format. This content is referenced in

    el_toolkit 1.1.22

    The latest build of el_toolkit for Ubuntu 14.04 or Mint 17.x is available for download. This program includes the Eiffel-View repository publisher available using the command switch  

  • 2016, Jul 24
    PART II: Eiffel-View 1.1, the new Eiffel repository publishing tool


    This is a follow up article to the introduction of Eiffel-View 1.0, a tool for publishing Eiffel repositories on a website. It offers a superior browsing experience to either Github or Sourceforge.

    Version 1.1 has now been tried and tested on the Eiffel-Loop website. This article will explain the new features in ver. 1.1 with reference to as an example.

    Site-map Contents

    The site-map home page now has a hyperlinked contents of the major repository repository sections.

    Compacted Configuration

    Configuration file format has been changed where possible to use element attributes in preference to text elements. See example Eiffel-Loop/doc-config/config.pyx. The basic configuration is only 15 lines.

    Source Tree Descriptions

    It is now possible to add descriptions for each source tree that will appear in the site-map home page. Eiffel-View markdown formatting can use for formatting the text. The descriptions are specified in the publishing configuration file. As for example:   Python coders will recognize the triple-quote multi-line string manifest syntax. There is of course nothing wrong with the Eiffel syntax, but the Pyxis format was designed for a wider audience than the Eiffel community.

    Longer Descriptions

    Longer descriptions can be specified in a separate file with a   extension and referenced in the config file like this:   The .emd file is placed in the same directory as the config file.

    The description field can be omitted altogether if the name of the .emd file matches the last step of the dir path as in this case.

    Abbreviated Directory Contents

    Version 1.1 allows you to keep the amount of text in the directory contents to a minimum. Only the description is listed after the class name, and for extended descriptions, the developer is encouraged to split into several note fields which will then appear in the source code page. Also for library directories the list of client examples now only appears in the source page.

    Further Information Cue

    If a class source page contains other information besides the description, the reader is made aware of this in the directory contents page by the inclusion of a header Further Information which provides a list of other note fields and the existence of a client example listing. For example: class-index.html#EIFFEL_FEATURE_EDITOR_APP

    Note Field Parsing

    Version 1.1 has better note field parsing support.

    Selected Fields

    Version 1.0 could only read the description note field from the Eiffel source. But now it is possible to specify a list of note field names in the configuration file, and the entire Eiffel source code will be scanned looking for these fields. As for example:   However only the description field will appear in the source tree contents page. The other fields will be rendered as html in the source code pages. Take a look at class EIFFEL_FEATURE_EDITOR_APP as an example.

    Legacy String Syntax Support

    Eiffel-Viewer can now parse the split-line string syntax found in many ISE classes, as for example:  

    Enhanced Source Pages

    In version 1.1 source pages now have the description and selected notes rendered in html. There is also a handy link at the top of the page with will skip all the notes and show the start of the class definition source code. Take a look at class EIFFEL_FEATURE_EDITOR_APP as an example.

    The very first link in the page, is a way to bookmark the class where it appears in the source contents page.

    Eiffel-View Markdown

    Eiffel-View now has support for both ordered and unordered lists

    Unordered Lists

    The markdown for bullet points is an asterisk at the start of a line followed by a space. Nested list are not supported.  

    Ordered Lists

    The markdown for a numbered list is an natural number followed by a dot followed by a space. Nested lists are not supported.   Ordered list items are rendered with HTML as follows:   This allows the possibility of using CSS to make the numbers bold while keeping the item texts normal.  


    Double single quotes on either side of a  .


    Eiffel-view will automatically generate the contents of the site-map page translated into Github markdown. The file is named   and is output into the publisher output root directory. This file can be put into the github repository root and referenced in the


    Download the latest version of el_toolkit for Ubuntu 14.04 or Linux Mint 17.x here.

  • 2016, Jul 14
    Eiffel-Loop news (July 2016)

    About Eiffel-Loop

    First launched in 2003, Eiffel-Loop is a collection of Eiffel libraries, example programs and development tools consisting of over 435 thousand code words* in more than 1700 classes. It also includes a sophisticated build system written in Python.

    New release 1.4.0 on Github

    For this release a major effort has been made to make Eiffel-Loop more modular with fewer inter-dependencies between libraries. In particular, most modules no longer depend on the logging module, but only the class EL_MODULE_LIO which is merely an alternative to io output.

    Full release notes here:

    New website

    The Eiffel-Loop website has been completely redesigned to act as a repository browser. You can explore the full source code of Eiffel-Loop at

    New Respository Publisher

    This release includes a new tool for publishing repositories as HTML. See article: Eiffel-View, the new Eiffel repository publishing tool


    • Code words include keywords, identifier words and quoted strings, but excludes comments and indexing notes.
  • 2016, Jul 13
    Part I: Eiffel-View 1.0, the new Eiffel repository publishing tool

    Repository Publishing

    If you have published your Eiffel code in a source repository like Github or Source Forge you will know that this is not the most ideal way to browse and explore Eiffel source code. There are a number of problems:

    1. Browsing in github requires endless drilling down into a deep directory structure and there is a noticeable delay for pages to load. What is preferable is a less granular view of the directory structure that will eliminate a lot of drilling down.
    2. If a class contains useful note documentation, you won't know about it's existence unless you actually open the class. Most times you will open the class and will discover there is no useful documentation. A wasted page load! What is need is a way to present any useful class notes on the same page as the link to the source code. If only some of the classes in a directory have useful notes, these should be listed first.
    3. Class notes are viewable only in source code form. If they contain any useful formatting information, there is no possibility to see it rendered in HTML.
    4. Once you open the source view, you will find that in github the indentation tabs are too large, so often the code does not fit nicely into the available browser space. Three spaces per tab is a much better default.
    5. If you want to see an example of how a library class is used, be prepared to spend a lot of time looking for an example.
    6. If you are only interested to read the code, the line number margin is a waste of space.

    Introducing Eiffel-View

    Eiffel-View is a new repository publishing tool that provides a solution to the code browsing problems identified in the introduction. However it does not manage the code, so you still need github or similar. It has been used to publish all the source code for the Eiffel-Loop repository which you can see here:

    Part II to follow

    This article is in two parts. In a follow up article I will be outlining some further improvements that could be made to make the tool more universally useful.


    Repository Statistics

    A short summary of the repository contents is placed at the top of the home page. As for example:

    Repository Statistics
    1784 Eiffel classes containing 435288 words* of code. Total source code: 4.2 mb.
    * Code words include keywords, identifier words and quoted strings, but exclude comments and indexing notes.

    Dependency checking

    A CRC-32 digest of each source code file is placed as a meta-tag of the corresponding html page. Eiffel-View is smart enough to work out the dependencies of every generated html page. Only pages that need rewriting are rewritten on subsequent runs.


    Automatically synchronizes contents with the hosting site by ftp.

    Note field markdown rendering

    Eiffel-View renders as html markdown used in the class description field. The markdown used is similar to Github markdown but there are some differences.

    All relative paths

    All links to image files, style sheets etc, use relative paths. This means the website can be browsed locally in a directory folder.

    Source Bookmarking Link

    Each source code html page has a book mark link at the top. However it links to an anchor in the index page, not the source file itself.

    Prism Syntax Highlighting

    Eiffel-View makes use of the Prism js/css tool for syntax highlighting the Eiffel source code.

    Client Example Links

    Eiffel-View provides links to usage examples (maximum of 20) for any classes in the library folder. In Eiffel-Loop the usage examples are found in either the example, tool or test directories. For an example see class EL_MODULE_EVOLICITY_TEMPLATES

    Configuration file

    A configuration file allows you specify a list of named directories that will appear in the home page sitemap. This is a more granular approach then using ECF files to specify the repository contents.


    The file is written in Pyxis format. The ftp-site section is optional.

    Eiffel-View Markdown Summary

    Highlighted sections

    Words quoted with a grave accent ( ` ) to open and an apostrophe (') to close are  . This follows an established Eiffel convention used in source comments for quoting routine names. See class EL_REMOTE_ROUTINE_CALL_REQUEST_HANDLER for an example.

    Bold words

    This is the same as Github markdown. Use two asterisk on either side of the **words you** want to make bold

    Code blocks

    Consecutive lines in the description which have an indent of 3 or more tabs are highlighted as a quoted code block with a fixed size font. See class EIFFEL_FEATURE_EDITOR_APP for an example.

    Hyper links

    Hyper links use the same convention as mediawiki-formatting as for example:  

    Relative source links

    There is a specialized link that allows you reference other source code files in a class description. You write the link as though you were referencing the other Eiffel source file and then you change the .e extension to .html. For example:   See class EIFFEL_FEATURE_EDITOR_APP for an actual example.

    Note that if you want to reference a class in the same directory you need to precede the page name with   as in this example for class EL_C_CALLABLE.

    Tool Source Code

    The source code for Eiffel-view can be viewed in directory eiffel-dev/library/publish.

    Tool Download

    A binary for the tool is available on Github as part of the 1.4.0 release of Eiffel-Loop:


    The build is for Linux Mint 17 which is based on Ubuntu 14.04. It might work on other versions of Ubuntu but I haven't tested.

    Tool Usage

    The following script found in the Eiffel-Loop root directory shows how to use the tool  

    Source View Template

    The following is the Evolicity html template for the html source code pages. Evolicity is a text substitution language that can output Eiffel objects into text. It is part of Eiffel-Loop.  

    Main Template

    The following is the main Evolicity html template is for for all index pages and the home page sitemap.  

  • 2016, Jun 27
    Eiffel-Loop news (June 2016)

    About Eiffel-Loop

    First launched in 2003, Eiffel-Loop is a collection of Eiffel libraries, example programs and development tools consisting of over 435 thousand code words* in more than 1700 classes. It also includes a sophisticated build system written in Python.

    New release available

    Eiffel-Loop version 1.3.4 is now available on github

    New website in progress

    I am currently doing a complete redesign of the Eiffel-Loop website which will be unveiled shortly. The website is being repurposed as primarily a way to explore the Eiffel-Loop contents repository and will be integrated with github.

    This project is being carried out with the development of a general purpose Eiffel orientated repository publishing tool that might be of interest to other repository developers. It is described below.

    New Eiffel code repository publishing tool

    Work is in progress on a new repository publishing tool called 'Eiffel-View'. Eiffel-View will generate a website that will offer a superior Eiffel code repository browsing experience then that offered by github.

    I have outlined here the expected features that will be delivered with each new version. The goals of this project are realistic as most of the code can be taken from existing tools in Eiffel-Loop.

    Version 1.0

    • A Eiffel-View project will be configured from a single Pyxis configuration file. The config file allows you to define named modules (source trees) grouped by category. The category is derived from the relative Eiffel source path by propercasing the first path step. For example: Library, Example, Tool, Test etc.
    • The repository website is generated using two html templates that use the Evolicity template language (Part of Eiffel-Loop). The first template is for the module indexing pages and the second for the source code view pages.
    • It is recommended to use the Prism syntax highlighter for the source code files. Prism has good support for the Eiffel language. To facilitate the use of Prism, Eiffel-View will output a flattened form of the repository directory structure, so all the source code html files can be put into a single sub-directory. To do this the code files will be uniquely named using the following format:


    Here 'identifier' is a string composed of the first two letters of each path step between the initial and last step. 'category' has been defined above. 'classname' is the normal eiffel class file name minus the .e extension.
    • The home page will be a site map of all the modules organised by category: Library, Tool, Example, Test etc. Category names are determined by taking the first step of each source tree relative to the repository root.
    • Each page will have a contents consisting of relative cluster directory paths. Then follows a list of classes each hyperlinked to a syntax highlighted html source code file. The classes are grouped by directory path. Any class that has a description that is neither empty nor matching the default entry, is displayed below the class link. See screenshots below.
    • The display of the class description will follow some implicit formatting rules. If the text has an indent of 1 relative to the description field marker, then the text is displayed as a normal paragraph. However if the text is indented any deeper it will be assumed to be a code fragment or program output fragment and will be formatted as a highlighted block quote using a fixed-width font. See screenshots below.

    Version 1.1

    • The generator will have an optional automatic ftp upload facility
    • Some classes found in the library source tree will have a list of hyperlinked client classes found under any of the other source tree categories, which might be Tool, Test or Example programs. This allows you to instantly see an example of the usage of a library class if it is available somewhere.

    Version 1.2

    • Eiffel-View will be integrated with another tool that allows you use the Thunderbird email client to author module documentation. This assumes you have an email address associated with the repository website. You make a 'www' subfolder under the account and beneath that you have a directory structure that corresponds to the repository directory structure. You create emails containing the documentation and then move it into the appropriate account subfolder for the module. An export tool will then extract the html bodies and save them in the repository using the file extension 'body' and the email subject as the file name. These body files are then automatically incorporated into the output of Eiffel-View as per module documentation. (This tool is already being used to author the contents of the website)


    These screenshots are of hand crafted mockup using the output of an existing index generation tool.

    1. top of page

    2. mid-page


    • Code words include keywords, identifier words and quoted strings, but excludes comments and indexing notes.
  • 2016, Jun 27
    Goodbye to the cross-platform bridge


    Lately I have had a change of mind about using the bridge pattern to make cross-platform classes, like those used in the Vision2 GUI library for example. I now favor using either the object factory pattern, or the simpler explict creation type construct as for example:

      The _I and _IMP suffixes denote respectively, a deferred interface and current platform implementation.

    The Cross-platform Bridge

    This pattern can be expressed abstractly by the following two classes:



    The main advantage of this pattern is that it hides from the developer-user the fact that the class relies on different implementations for each development platform. However my experience of using this pattern over many years, is that it leads to unweildly code that is relatively difficult to maintain and extend. Using a deferred interface parent class with mutiple cross-platform direct descendants, genarally makes for cleaner code that is easier to maintain and extend.

    Object Factory Example

    Here is an example of an object factory class that is shared from the class EL_MODULE_AUDIO_COMMAND:

    A Command Factory


    Using the Command Factory


    Typical Platform Implemenation

    Note that all features of the interface are exported to NONE. This enforces the intent that the class be only useable through the interface.  

    A Code Comparison on Github

    Lately I have eliminated all uses of the CP bridge pattern from the Eiffel-Loop library. For posterity I preserved some of the obsolete classes used for wrapping OS commands in a separate directory. You can see the differences in the implemenation on github here:

    The new implemenation has an improved inheritance heirarchy. This is the EL_OS_COMMAND_I heirarchy found in the example program manage-mp3:  

  • 2016, Jun 03
    When parentheses matter

    Recently I've run into an issue that can be summarized by the following code snippet:


    Question 1. Will   and   have the same value? (Before reading the answer you may want to answer the question yourself.)

    Test. Let's add two lines of code   and look at the output:   Why so?

    Answer. The first syntax is used to access constant attributes, so the string is the value of the attribute   of class  . In the second case there is no immediate qualified call on   and it is considered as a reference to the type object for type   and has a type  . Accidentally class   declares a feature   that returns a run-time name of the associated type. (The exclamation mark in front of it indicates that the type is attached.)

    Are there other cases when enclosing types in braces affects code semantics? Yes: there are open arguments in agent declarations!

    Question 2. What would be result of the code above if assignment to   and   are changed into the following?  

    Test. The same print statements give us  

    Answer. The first syntactical construct corresponds to the declaration of an agent with an open target and produces an agent object of type  . The actual target is then passed as an argument to the feature  . In the second case the target is closed and the agent has type  . This explains the output we get.

    Final question for curious developers: what part in the second example is redundant and can be removed without affecting execution?

  • 2016, May 23
    Robotics and concurrency

    Many robotics applications are by nature concurrent; in his ongoing PhD work, Andrey Rusakov [1] is building a comprehensive concurrent robot programming framework, Roboscoop [2], based on the SCOOP model for simple concurrent object-oriented programming [3] and the Ros operating system. As part of this work it is important to know how much robotics applications […]

    The post Robotics and concurrency appeared first on Bertrand Meyer's technology+ blog.

  • 2016, Mar 18
    Quick benchmarks


    There are so programming situations where there are multiple methods of achieving the same result. Even for something as simple as summing the values of a list of integers, there are at least 5 different methods in Eiffel. Often times we don't go to the trouble of finding out which method is the most efficient and by how much? Creating benchmarks is a chore.

    To make benchmark creation and organization less of a chore I created a class in Eiffel-Loop that will allow you quickly compare arbitrary number of routines using an interactive command shell.


    The class EL_BENCHMARK_COMMAND_SHELL is an example with a selection of 2 benchmarks:

    1. Compares 5 different methods of summing an arrayed list of integers
    2. Compares 3 methods of concatenating an array of strings together

    By calling the routine 'execute' the shell enters a command loop by printing a menu of all benchmarks itemized in the 'new_command_table' list. Entering a number selects a benchmark to execute. Entering '0' quits the command loop.

    The 'make' initialization routine takes one argument 'number_of_runs' specifying the number of times to run each benchmark routine. The output figures are based on the average execution time.

    The routine {EL_BENCHMARK_COMMAND_SHELL}.compare_benchmarks, benchmarks each routine and prints the average execution time of the fastest. The other routine benchmarks figures are displayed as relative to this figure using a '+' or '-' percentage.


    Console Output

    Output of finalized executable

    Github Source Links





  • 2016, Mar 13
    ZSTRING released in Eiffel-Loop 1.3.1
  • 2016, Feb 24
    Software for Robotics: 2016 LASER summer school, 10-18 September, Elba

    The 2016 session of the LASER summer school, now in its 13th edition, has just been announced. The theme is new for the school, and timely: software for robotics. Below is the announcement. School site: here The 2016 LASER summer school will be devoted to Software for Robotics. It takes place from 10 to 18 […]

    The post Software for Robotics: 2016 LASER summer school, 10-18 September, Elba appeared first on Bertrand Meyer's technology+ blog.

  • 2015, Nov 17
    Some lazy data structures implemented in Eiffel - Part I - Iterating the Calkin-Wilf tree

    This is the first part of a series in which I intend to make some explorations of lazy, infinite data structures in Eiffel. If you want to compile the code in these articles, you will need EiffelStudio 15.11 or later.

    In this first article, I am going to iterate an infinite data structure - the strictly-positive rational numbers, represented by an infinite tree - The Calkin-Wilf tree. The easiest way to follow the code is to view it directly on GitHub. An alternative is to checkout the repository and compile it in EiffelStudio. To do the latter (instructions are for Linux from a bash terminal, but should be similar for other O/S I think):

    1. git clone
    2. git checkout V1
    3. cd lazy_eiffel/examples/calkin_wilf/src
    4. estudio calkin_wilf.ecf &
    5. Press OK

    The first class worth looking at briefly is  . This represents a single node in an infinite binary tree, together with a link to it's parent, and two  s to find the left and right children. Incidentally, you may be surprised at the syntax used for declaring these  s unless you have already read this thread. This is why 15.11 or later is needed to compile the code. I think it's worth showing one of those agents here:


    This syntax is starting to look lightweight. Looking quite comparable to Haskell, for example ( ), and none of that horrible camelCase.

    Then let's look at the   tree itself. The core of the class is a root node, two functions to navigate from any node in the tree to the left and right children (or to lazily build the tree structure, depending on how you want to look at it), and a creation procedure to initialize root to 1/1.


    However, I muddled this nice little picture by inheriting from  . So the class   has a lazy tree of rationals, and is a linear iteration of them. In the root class   we simply print the first 100 rational numbers (I could have made the program take an argument) using a  . However, the iteration is not in numerical order. In a future post we'll see other ways of iterating the rationals.

    The really interesting thing (to me) about the Calkin-Wilf tree is the way I did a breadth-first traversal of this infinite tree. It turns out that the index in the linear structure, when translated into binary, can be considered as a set of instructions to move through the tree. You ignore all leading zeros. At the first one, move to the root. Then every time you see a zero, you take the left child, and every time you see a one, you take the right child. Lovely!

  • 2015, Nov 14
    Introducing class ZSTRING


    I am currently working on new kind of string class: ZSTRING. Z-strings are essentially a compressed STRING_32 offering similar performance characteristics but with a much smaller memory footprint. Large strings composed mainly of characters found in the Latin-15 character-set use up to 75% less memory. Some preliminary benchmarks can be found here:

    The first benchmark set shows the best case scenario and the second the worst case. The letters A, B, C, D are codes for the test strings shown in a table at the bottom of the benchmark page. Each benchmark is the average of 100 runs with a full garbage collect at the end of each.

    Z-strings have a precursor called EL_ASTRING (alias ASTRING) which I wrote about some years ago in this article.

    However Z-strings use a very different kind of compression algorithm that removes one of the fundamental limitations of A-strings which is they were limited to a maximum of 26 unicode overflows per string. By overflow is meant characters which are not mappable to latin-15. With Z-string you can include an unlimited amount of Unicode overflow. The Z-string code is also a lot simpler.

    The Algorithm

    Z-string works by using a hybrid of Latin and Unicode character sets. This means that for languages which work well with 8 bit character-sets, the strings are stored as 8 bit character sequences. Z-strings are mainly initialized from Unicode or UTF-8 strings. Any character which is not translatable with the current system codec is put into an overflow array unencoded, which is composed of a sequence of substrings. Each substring is a start_index followed by an end_index followed by the unicode substring characters. By default unencoded is assigned the once singleton: Empty_unencoded.

      You can choose any Latin or Windows codec to be your system codec depending on the selected language locale of the user machine. Latin-15 is fine for most Western-European languages.

    Asian Languages

    However looking at the benchmarks it becomes obvious that Z-strings will inefficient for handling Asian text which is mostly composed of double byte characters. The solution I envisage for this is to have a second Z-string implemenation that is available as an ECF compile option. The Asian implemenation of ZSTRING will inherit from a class EL_ZSTRING_16 which operate on double byte character sequences. Any odd characters requiring more than 2 bytes can be stored in the unencoded overflow array. So even with Asian languages, I would expect to see a substantially smaller memory footprint compared to STRING_32.

    Test Suite

    I have been able to reuse an extensive set of tests developed for EL_ASTRING that prove equivalent results to STRING_32 routines.

    Extra Routines

    There are also a number of fancy routines in EL_ASTRING that are not found in the STRING_32. Later I will add these to ZSTRING. The code will be the same. The most useful of these is an operator which every Python programmer will miss if he switches to Eiffel.

      This is equivalent to the Python code   Program output:  

    There is also a useful routine translate, which is similar to the Python String translate routine. It is used to either substitute or delete selected characters from a string.

    There are about 10 other useful routines not found in STRING_32

    Code EL_ZSTRING (alias ZSTRING)

    EL_ZSTRING inherits from class EL_ZSTRING_8 which contains routines copied from STRING_8. EL_ZSTRING wouldn't work if I just inherited from STRING_8 due to various contract violations that are not possible to override. Since the class will be used a lot, it will be conveniently aliased as ZSTRING in the ECF.

    Note that this is work in progress and there are still many routines to be implemented.  



    Code EL_ZCODEC




  • 2015, Nov 05
    When using expanded classes is not always the best performance option

    Expanded class V 64 bit integer

    While working on my current project I discovered an interesting fact that for certain kinds of data, expanded classes don't provide the best performance. My project involves processing a lot of sub-strings and requires a representation of a sequential list of integer intervals. The obvious choice is to use an instance of ARRAYED_LIST [INTEGER_INTERVAL], but as performance is critical this would not be fast enough for this project. So instead I devised a class to represent integer intervals as 64 bit integers and use "bit twiddling" to get and set the upper and lower bounds. The design was intended to minimise garbage collection and array indexing.


    Although I was satisfied with it's performance, it occurred to me that I might be able to simplify the code without sacrificing anything by using an expanded class to represent the integer interval as follows:


    My expectation was that this would give similar performance to the ARRAYED_LIST [INTEGER_64] implementation, but I was completely wrong as the following benchmark shows. The first test takes almost double the time using the expanded class implementation.

    Benchmark INTEGER_64 implementation


    Benchmark expanded class implementation


    Each test is the average time of 100 repetitions in the finalised executable compiled with GCC. Inlining_size is set to 2. A full garbage collect is forced during each test iteration

    64 bit integer source listing


    Expanded class source listing


  • 2015, Oct 12
    Danke sehr!

    (A version of this article also appeared on the CACM blog.) Miracles happen! Many months ago I accepted, perhaps too fast, a kind invitation to talk at the European Computer Science Summit, the annual conference of Informatics Europe, this week in Vienna. It came with a catch: I was not to choose my own topic but to […]

    The post Danke sehr! appeared first on Bertrand Meyer's technology+ blog.

  • 2015, Sep 27
    Porting EiffelStudio to OpenBSD (again)

    Years ago, I made an effort to get EiffelStudio running on OpenBSD 4.8. After I managed to get it working, Manu from Eiffel software was very helpful by integrating OpenBSD as an automatic build target into the Eiffel software build farm. This ensured that new versions of EiffelStudio would always compile on OpenBSD. At least in the 64 bit version.

    Unfortunately, what was not done was upgrading OpenBSD itself. While EiffelStudio was still regularly built on (IIRC) 4.8, the development on OpenBSD continued.

    OpenBSD is known to many as a very secure operating system. While security might be what is mentioned in the media, it is actually the operating system of software quality. Quality and correctness in OpenBSD are paramount, even to the level of release schedule and documentation. Security sometimes seems to be just a byproduct of this approach.

    One result of this is that OpenBSD is rather flexible on maintaining backwards compatibility and old infrastructure. This has been very nicely summarised in a recent blog post by Ted Unangst ().

    Old binaries are not supported to work on newer versions of the operating system. Some backwards compatibility is provided, assuming that you still have the old version of libc lying around. But between 5.4 and 5.5, OpenBSD had a major kernel ABI change (moving from 32 to 64 bit time everywhere, to be ready for year 2038 - ). Old binaries do not work between these two versions, which made upgrading 'interesting'.


    PorterPackage considered useless

    Now, missing binary compatibility would not be a big issue for getting EiffelStudio to work: Eiffel software provides a great little thing called PorterPackages. These are tar-files that contain everything you need to build EiffelStudio on a target machine. And as an Eiffel compiler is not available to bootstrap, all Eiffel programs are already available as pre-compiled C code. A bunch of shell scripts is provided that will compile and assemble a nice little EiffelStudio deliverable.

    BUT, just between 5.4 and 5.5, the OpenBSD people removed 'libcompat' from the operating system. This library used to provide support for some old, deprecated APIs. One of these is 'ftime', a function that has been removed from POSIX since 2008. Instead 'time' and 'gettimeofday' are replacements for all platforms.

    Well, except one: Windows. Because of this, my change request to move to the new API which would have made the PorterPackage work again on current version of OpenBSD was rejected ().

    So, there is currently no way that PorterPackages can work without libcompat, thus with a version > 5.4. Time for plan B.

    It has to start somewhere

    Fortunately, version 5.4 (from 2013) of OpenBSD is still available on FTP servers. I fire up a VirtualBox and install OpenBSD 5.4. Then I download the PorterPackage, GTK and other required libraries, and run the build script. Soon, I have EiffelStudio 15.01 running.

    Next, I grab the actual EiffelStudio 15.01 source code. The goal is to get a version compiled on 5.4 that has all the source code changes for later version of OpenBSD. This has two parts: first, apply my patch from above to the checked-out tree. Next, remove all references to 'libcompat' from the platform specific configuration files. These are the 'openbsd-x86-64' and 'openbsd-x86' files in the 'C/CONFIGS' folder. Also '/usr/lib/crtbeginS.o /usr/lib/crtendS.o' needs to be added when linking shared libraries.

    Once this is done, and after making sure I have a current version of GOBO in my path (which I have compiled from source), I can start building a new delivery that should be the foundation of my future EiffelStudio package.

    The EiffelStudio tree has a nice set of build.eant files that supports you in doing all the work. 'geant check_setup' makes sure you have all tools and paths configured. 'geant make_delivery' builds a complete delivery tree.

    Once done, I have an EiffelStudio tree (EiffelXX) containing all the changes, it is just for the wrong version of OpenBSD.

    Migrating to current OpenBSD

    As a next step, I need to identify the parts of EiffelStudio that will require a replacement. The 'file' utility is very helpful to identify these files. What we are looking for are ELF binaries. So, the command line looks like this:

       find . -type f | xargs file | grep ELF | cut -d: -f1

    The resulting list happens to be pretty short:


    All the GOBO stuff can be easily replaced by binaries that are compiled using GEC, the GOBO Eiffel compiler. This is portable and works out-of-the-box with newer versions of OpenBSD.

    The run-time system libraries (lib[mt] and lib[mt] can be compiled by using the build.eant script in the C directory. This is also true for the other .so and .o files, where the source code is available in Clib directories. Just make sure that you have 'finish_finalize' (a shell script) in your path. For each dynamic library (.so), there is also a static library (.a) which you should also copy over, too.

    'x2c' and 'ecdbgd' are both written in C and built together with the run-time.

    Now the only binaries left are: ec, quick_finalize, ecb, estudio and esbuilder. I did not actually bother with esbuilder, because I am not using it.

    For all others, I have to build the source code, without C compiling it. This needs to be done on OpenBSD 5.4, before you upgrade to a higher version. For example, to create the quick_finalize source code, run:

       ec -config tools/quick_finalize/quick_finalize.ecf -finalize

    I do this with all four binaries and then copy everything from my virtual machine (on Linux) to my actual OpenBSD box. Once there, I build the non-Eiffel binaries above and copy them over into the target tree.

    Finally, I go into the EIFGENs directory and just run a 'finish_freezing' (perhaps after a 'make clobber') for each binary and copy the result as well. All done, and I have EiffelStudio for my current version of OpenBSD.

    EiffelStudio on OpenBSD: EiffelStudio on OpenBSDEiffelStudio on OpenBSD: EiffelStudio on OpenBSD

    The way forward

    Ok - I have EiffelStudio working again, but it took a lot of fiddling. I have to develop a version of C_DATE that is compatible with Windows and OpenBSD. Once that is in the main tree and Manu continues supplying PorterPackages, things will be much easier.

  • 2015, Sep 15
    Design by Contract: ACM Webinar this Thursday

    A third ACM webinar this year (after two on agile methods): I will be providing a general introduction to Design by Contract. The date is this coming Thursday, September 17, and the time is noon New York (18 Paris/Zurich, 17 London, 9 Los Angeles, see here for hours elsewhere). Please tune in! The event is […]

    The post Design by Contract: ACM Webinar this Thursday appeared first on Bertrand Meyer's technology+ blog.

  • 2015, Jul 28
    In English this time: a Marseillaise for our age

    Sometimes it is better not to know French. You will never quite get what Voltaire, Molière, Beauvoir, Zola, Hugo and Proust really mean and what Carmen and Faust really sing. But at least you will not find out what the Marseillaise really says. It is France’s national anthem and, according to a site dedicated to […]

    The post In English this time: a Marseillaise for our age appeared first on Bertrand Meyer's technology+ blog.

  • 2015, Jul 16
    A Marseillaise for our age

    [This blog is normally in English, but today’s article is particularly relevant to French speakers. The topic: freeing a national anthem of its hateful overtones.] Mardi dernier quatorze juillet, une fois de plus, la Marseillaise a retenti un peu partout. C’est le jour où les hommes politiques s’essayent à l’entonner, juste ou (plus souvent) faux. […]

    The post A Marseillaise for our age appeared first on Bertrand Meyer's technology+ blog.

  • See more ...