EiffelStudio

A few weeks ago, we had our 29th ECMA meeting. While we were reviewing the standard, we went over the special characters and their codes (Section 8.32.23). Special characters are %N, %R, %T, %(, .... and they all have a specific meaning. For ... [More] example, %N means the ASCII character 0x0A, %R 0x0D, etc... While I was looking at our code to verify that we handle special characters properly I was surprised to see that our lexer was doing something like: if input.item (1) = '%%' then   inspect input.item (2)   when 'N' then output.append_character ('%N')   when 'R' then output.append_character ('%R')   .... end which is quite surprising since we are saying here that if you read %N, interpret it as %N. But what does %N actually means? It is either what the standard says or something completely different. Luckily, the first Eiffel compiler that compiled this code did a good job and it does what the standard says! And today, we rely on that first Eiffel compiler since there is nothing in the code that tells how the mapping is done. But maybe we should not be that trusting and simply put the actual mapping which is not that much more complicated and certainly less troubling. [Less]

A few weeks ago, we had our 29th ECMA meeting. While we were reviewing the standard, we went over the special characters and their codes (Section 8.32.23). Special characters are %N, %R, %T, %(, .... and they all have a specific meaning. For ... [More] example, %N means the ASCII character 0x0A, %R 0x0D, etc... While I was looking at our code to verify that we handle special characters properly I was surprised to see that our lexer was doing something like:   which is quite surprising since we are saying here that if you read %N, interpret it as %N. But what does %N actually means? It is either what the standard says or something completely different. Luckily, the first Eiffel compiler that compiled this code did a good job and it does what the standard says! And today, we rely on that first Eiffel compiler since there is nothing in the code that tells how the mapping is done. But maybe we should not be that trusting and simply put the actual mapping which is not that much more complicated and certainly less troubling. [Less]

We are pleased to announce the availability of EiffelStudio 14.05. It can be downloaded at . The release notes are available at The major two highlights of this release are: Eiffel Inspector Automatic Fixing We are quite excited about the ... [More] Eiffel Inspector. It is a static analysis tool that will analyze your code to detect potential programming mistake or provide some recommendations. To give you an idea of what it is capable of, here is an example. Assume that you write the following code:   From the Eiffel compiler's point of view, everything is ok. From the Eiffel Inspector's point of view this is a CA001 warning. In this particular case, it is obvious that the original author meant:   The second new major addition is Automatic Fixing. As its name indicates it will automatically fix some compiler warnings or errors. At the moment, only two fixes are available: Unused local warning Untyped local For unused locals, select all the warnings reported by EiffelStudio and simply press the Fix button. All the unused locals are now gone. For untyped local, the compiler will actually try to figure out the proper type and suggest it as a fix. Have a look at the video from Alexander Kogtenkov on the Eiffel channel on YouTube to see it in action. Finally, we are expanding our platforms by adding support for the Raspberry Pi board. Happy Eiffeling! On behalf of the Eiffel Software Team Manu [Less]

We are pleased to announce the availability of EiffelStudio 14.05. It can be downloaded at http://www.eiffel.com/downloads. The release notes are available at https://docs.eiffel.com/book/eiffelstudio/release-notes-eiffelstudio-1405 The major two ... [More] highlights of this release are: Eiffel Inspector Automatic Fixing We are quite excited about the Eiffel Inspector. It is a static analysis tool that will analyze your code to detect potential programming mistake or provide some recommendations. To give you an idea of what it is capable of, here is an example. Assume that you write the following code: set_x (a_x: INTEGER)         do                 x := x         end From the Eiffel compiler's point of view, everything is ok. From the Eiffel Inspector's point of view this is a CA001 warning. In this particular case, it is obvious that the original author meant: set_x (a_x: INTEGER)         do                 x := a_x         end The second new major addition is Automatic Fixing. As its name indicates it will automatically fix some compiler warnings or errors. At the moment, only two fixes are available: Unused local warning Untyped local For unused locals, select all the warnings reported by EiffelStudio and simply press the Fix button. All the unused locals are now gone. For untyped local, the compiler will actually try to figure out the proper type and suggest it as a fix. Have a look at the video from Alexander Kogtenkov on the Eiffel channel on YouTube to see it in action. Finally, we are expanding our platforms by adding support for the Raspberry Pi board. Happy Eiffeling! On behalf of the Eiffel Software Team Manu [Less]

We are pleased to announce the availability of EiffelStudio 14.05. It can be downloaded at http://www.eiffel.com/downloads. The release notes are available at https://docs.eiffel.com/book/eiffelstudio/release-notes-eiffelstudio-1405 The major two ... [More] highlights of this release are: Eiffel Inspector Automatic Fixing We are quite excited about the Eiffel Inspector. It is a static analysis tool that will analyze your code to detect potential programming mistake or provide some recommendations. To give you an idea of what it is capable of, here is an example. Assume that you write the following code: set_x (a_x: INTEGER)     do         x := x     end From the Eiffel compiler's point of view, everything is ok. From the Eiffel Inspector's point of view this is a CA001 warning. In this particular case, it is obvious that the original author meant: set_x (a_x: INTEGER)     do         x := a_x     end The second new major addition is Automatic Fixing. As its name indicates it will automatically fix some compiler warnings or errors. At the moment, only two fixes are available: Unused local warning Untyped local For unused locals, select all the warnings reported by EiffelStudio and simply press the Fix button. All the unused locals are now gone. For untyped local, the compiler will actually try to figure out the proper type and suggest it as a fix. Have a look at the video from Alexander Kogtenkov on the Eiffel channel on YouTube to see it in action. Finally, we are expanding our platforms by adding support for the Raspberry Pi board. Happy Eiffeling! On behalf of the Eiffel Software Team Manu [Less]

Once again, one can only be disappointed by the state of things in the world of software development. Apple just announced a new programming language called Swift. The worst of worst, they are not ashamed to take the name of an already existing ... [More] programming language (check out http://www.swift-lang.org developed by the University of Chicago). I've quickly look at the documentation they are providing with their new language and the syntax is slightly better but still it is not a nice one. The documentation starts by teaching you 2 things: println ("Hello World!") how to define a constant and a variable As if this is what makes a programming language, this is lame. Apple should have thought about looking around before creating yet another language. They should have chosen Eiffel of course, or the many other existing languages that are nicer to use than Ojective-C. It shows that they do not care much about reuse which you can see everywhere in their products since every 2 or 3 years they do not hesitate to make things obsolete forcing you to update. As I see it, it seems that in a few years from now, developers who haven't updated their code to Swift might be suffering. Too bad, it doesn't have to be this way. [Less]

Once again, one can only be disappointed by the state of things in the world of software development. Apple just announced a new programming language called Swift. The worst of worst, they are not ashamed to take the name of an already existing ... [More] programming language (check out developed by the University of Chicago). I've quickly look at the documentation they are providing with their new language and the syntax is slightly better but still it is not a nice one. The documentation starts by teaching you 2 things: println ("Hello World!") how to define a constant and a variable As if this is what makes a programming language, this is lame. Apple should have thought about looking around before creating yet another language. They should have chosen Eiffel of course, or the many other existing languages that are nicer to use than Ojective-C. It shows that they do not care much about reuse which you can see everywhere in their products since every 2 or 3 years they do not hesitate to make things obsolete forcing you to update. As I see it, it seems that in a few years from now, developers who haven't updated their code to Swift might be suffering. Too bad, it doesn't have to be this way. [Less]

Once again, one can only be disappointed by the state of things in the world of software development. Apple just announced a new programming language called Swift. The worst of worst, they are not ashamed to take the name of an already existing ... [More] programming language (check out http://www.swift-lang.org developed by the University of Chicago). I've quickly look at the documentation they are providing with their new language and the syntax is slightly better but still it is not a nice one. The documentation starts by teaching you 2 things: println ("Hello World!") how to define a constant and a variable As if this is what makes a programming language, this is lame. Apple should have thought about looking around before creating yet another language. They should have chosen Eiffel of course, or the many other existing languages that are nicer to use than Ojective-C. It shows that they do not care much about reuse which you can see everywhere in their products since every 2 or 3 years they do not hesitate to make things obsolete forcing you to update. As I see it, it seems that in a few years from now, developers who haven't updated their code to Swift might be suffering. Too bad, it doesn't have to be this way. [Less]

Below we will see how the main options that control our code generation may impact your code. We will review the following: exception trace (only has an impact in finalized mode, this option is always enabled in workbench mode) multithreading ... [More] workbench vs. finalized The results below are the time it took to compile the Eiffel compiler using the various code generation options on a 4+ years old computer using an Intel Xeon CPU E5420 at 2.50GHz: Compilation mode Execution Time   Ratio finalized, no exception trace, no multithreading 129s 1.0 finalized, exception trace, no multithreading 184s 1.42 slower finalized, exception trace, multithreading 234s 1.81 slower The same benchmark but this time compiling EiffelStudio: Compilation mode Execution Time   Ratio finalized, no exception trace, no multithreading 399s 1.0 finalized, exception trace, no multithreading 531s 1.33 slower finalized, exception trace, multithreading 865s 2.04 slower Finally we compare finalized vs workbench code generation against the compilation of EiffelStudio: Compilation mode Execution Time   Ratio finalized 865s 1.0 workbench 4944s 5.71 slower new workbench code generation 4502s 5.02 slower Note that in the workbench case, we have a new code generation we have been experimenting with and which gives us a good performance gain (about 5 to 9% on average in our own benchmarks). This optimization will be available in the next release of EiffelStudio 14.05. As you can see keeping exception trace in finalized mode has an impact. Even if it makes things slower, EiffelStudio is compiled using this option so that whenever something bad happens, the automatic error reporting of EiffelStudio can send us as much details as possible on the failure. Needless to say, that we will be working in the future to make those numbers look better by improving the overall performance when either or both of exception trace and multithreading (including SCOOP) are enabled. There are other options that also have an impact on performance and that are not mentioned above: Check for Void target: this option only makes sense in non-void-safe system and is enabled by default. If you disable it gain about 1-2% in performance. Inlining and Inlinig Size: I definitely recommend enabling Inlining all the time. If you set the inlining size to 0, it will inline all empty routines and low level array access (features item and put of the SPECIAL class) without much impact on compilation time and some visible impact in execution time. If you set it to a larger number, then compilation time increases. On the Eiffel compiler, setting it to 8 slows down the compiler by 8% , but improve performance by about the same ration 8% and increase the executable size by about 7% . [Less]

Below we will see how the main options that control our code generation may impact your code. We will review the following: exception trace (only has an impact in finalized mode, this option is always enabled in workbench mode) multithreading ... [More] workbench vs. finalized The results below are from compiling just the Eiffel compiler on a 4+ years old computer using an Intel Xeon CPU E5420 at 2.50GHz: Compilation mode Compilation Time   Ratio finalized, no exception trace, no multithreading 129s 1.0 finalized, exception trace, no multithreading 184s 1.42 slower finalized, exception trace, multithreading 234s 1.81 slower The same benchmark but this time compiling EiffelStudio: Compilation mode Compilation Time   Ratio finalized, no exception trace, no multithreading 399s 1.0 finalized, exception trace, no multithreading 531s 1.33 slower finalized, exception trace, multithreading 865s 2.04 slower Finally we compare finalized vs workbench of compiling EiffelStudio: Compilation mode Compilation Time   Ratio finalized 865s 1.0 workbench 4944s 5.71 slower new workbench code generation 4502s 5.02 slower Note that in the workbench case, we have a new code generation we have been experimenting with and which gives us a good performance gain (about 5 to 9% on average in our own benchmarks). This optimization will be available in the next release of EiffelStudio 14.05. As you can see keeping exception trace in finalized mode has an impact. Even if it makes things slower, EiffelStudio is compiled using this option so that whenever something bad happens, the automatic error reporting of EiffelStudio can send us as much details as possible on the failure. Needless to say, that we will be working in the future to make those numbers look better by improving the overall performance when either or both of exception trace and multithreading (including SCOOP) are enabled. There are other options that also have an impact on performance and that are not mentioned above: Check for Void target: this option only makes sense in non-void-safe system and is enabled by default. If you disable it gain about 1-2% in performance. Inlining and Inlinig Size: I definitely recommend enabling Inlining all the time. If you set the inlining size to 0, it will inline all empty routines and low level array access (features item and put of the SPECIAL class) without much impact on compilation time and some visible impact in execution time. If you set it to a larger number, then compilation time increases. On the Eiffel compiler, setting it to 8 slows down the compiler by 8% , but improve performance by about the same ration 8% and increase the executable size by about 7% . [Less]