EiffelStudio

The past 6 months we have been working on some new language improvements to simplify and improve the expressiveness of Eiffel. The first improvement is the conditional expression. Very often, depending on some boolean value you expect either one ... [More] result or another. Although one can express this, it is sometime tedious and/or not very readable. Using the new expression type, you would be able to write the following: Result := if is_even then my_value // 2 else (my_value + 1) // 2 end The other improvements are related to agents and to summarize those in 2 lines, we would like to go from the following agent call: my_agent.call ([arg1, arg2]) to simply just my_agent (arg1, arg2) . To achieve this, two new additions to the language are necessary. The first one is simplifying feature calls when the last argument is a TUPLE by not having to write the manifest tuple. Instead you simply list all the elements of the tuple as remaining arguments. For example, given the following declaration: my_routine (a_arg: INTEGER; a_coord: TUPLE [INTEGER, INTEGER]) you will now be able to write either of the following: my_routine (1, [2, 3]) my_routine (1, 2, 3) The second addition is the notion of parenthesis alias. Very similar to bracket alias, you can choose one routine of the current class to be the parenthesis alias. The direct benefit is that a call can be done without providing a name, just the arguments. For example, if in a class you have the following declaration: my_routine alias "()" (arg1: INTEGER) then you can all this routine using either of the following syntax: a: A a.my_routine (1) a (1) Merging those two new additions to routine call from ROUTINE or item from FUNCTION gives us the intended effect of simplifying agent calls. At the moment, we are busy ironing out the details and the new validity rules. Those improvements will appear in this fall release and the spring release of 2014. Let us know what you think in the comments below. Happy Eiffeling! Manu [Less]

The past 6 months we have been working on some new language improvements to simplify and improve the expressiveness of Eiffel. The first improvement is the conditional expression. Very often, depending on some boolean value you expect either one ... [More] result or another. Although one can express this, it is sometime tedious and/or not very readable. A simple example would be: Result := if is_even then my_value // 2 else (my_value + 1) // 2 end The other improvements are related to agents and to summarize those in 2 lines, we would like to go from the following agent call: my_agent.call ([arg1, arg2]) to simply just my_agent (arg1, arg2) . To achieve this, two new additions to the language are necessary. The first one is simplifying feature calls when the last argument is a TUPLE by not having to write the manifest tuple. Instead you simply list all the elements of the tuple as remaining arguments. For example, given the following declaration: my_routine (a_arg: INTEGER; a_coord: TUPLE [INTEGER, INTEGER]) you will now be able to write either of the following: my_routine (1, [2, 3]) my_routine (1, 2, 3) The second addition is the notion of parenthesis alias. Very similar to bracket alias, you can choose one routine of the current class to be the parenthesis alias. The direct benefit is that a call can be done without providing a name, just the arguments. For example, if in a class you have the following declaration: my_routine alias "()" (arg1: INTEGER) then you can all this routine using either of the following syntax: a: A   a.my_routine (1) a (1) Merging those two new additions to routine call from ROUTINE or item from FUNCTION gives us the intended effect of simplifying agent calls. At the moment, we are busy ironing out the details and the new validity rules. Those improvements will appear in this fall release and the spring release of 2014. Let us know what you think in the comments below. Happy Eiffeling! Manu [Less]

Starting this fall, the EiffelStudio versioning will change from Y.X format (the last version in this scheme will be 7.3) to the YY.MM format. Which means that the version from November 2013 will be 13.11. This will be updated throughout our tools ... [More] and the only significant change will be the default location of EiffelStudio which used to be EiffelXY, now it will be Eiffel_YY.MM to make it easier to read. The added benefit will be that by just looking at the first two components of the full version number we can easily know when it was released. And for those who might not know, the last two components of the full version number put together form the actual subversion revision number of when EiffelStudio was built. For each major release we create a branch named Eiffel_X.Y (it will now be Eiffel_YY.MM). This is where release specific bug fixes are added if needed. Whenever we do an actual release on our website, we create a tag release also named Eiffel_X.Y/Rn (and now it will be Eiffel_YY.MM/Rn) where `n' stands for the n-th release made for this particular version. The subversion number for the tag release will match exactly the last two components of the full version of EiffelStudio. For example, if we take the 7.3 release, the current full revision is 7.3.9.2766, thus the subversion revision number is 92766. This was the first release of 7.3, thus you can look at the last commit at the following URL which is indeed 92766 by typing the following command: svn info Happy Eiffeling, Manu [Less]

Starting this fall, the EiffelStudio versioning will change from Y.X format (the last version in this scheme will be 7.3) to the YY.MM format. Which means that the version from November 2013 will be 13.11. This will be updated throughout our tools ... [More] and the only significant change will be the default location of EiffelStudio which used to be EiffelXY, now it will be Eiffel_YY.MM to make it easier to read. The added benefit will be that by just looking at the first two components of the full version number we can easily know when it was released. And for those who might not know, the last two components of the full version number put together form the actual subversion revision number of when EiffelStudio was built. For each major release we create a branch named Eiffel_X.Y (it will now be Eiffel_YY.MM). This is where release specific bug fixes are added if needed. Whenever we do an actual release on our website, we create a tag release also named Eiffel_X.Y/Rn (and now it will be Eiffel_YY.MM/Rn) where `n' stands for the n-th release made for this particular version. The subversion number for the tag release will match exactly the last two components of the full version of EiffelStudio. For example, if we take the 7.3 release, the current full revision is 7.3.9.2766, thus the subversion revision number is 92766. This was the first release of 7.3, thus you can look at the last commit at the following URL https://svn.eiffel.com/eiffelstudio/tags/Eiffel_73/R1 which is indeed 92766 by typing the following command: svn info https://svn.eiffel.com/eiffelstudio/tags/Eiffel_73/R1/ Happy Eiffeling, Manu [Less]

Starting this fall, the EiffelStudio versioning will change from Y.X format (the last version in this scheme will be 7.3) to the YY.MM format. Which means that the version from November 2013 will be 13.11. This will be updated throughout our tools ... [More] and the only significant change will be the default location of EiffelStudio which used to be EiffelXY, now it will be Eiffel_YY.MM to make it easier to read. The added benefit will be that by just looking at the first two components of the full version number we can easily know when it was released. And for those who might not know, the last two components of the full version number put together form the actual subversion revision number of when EiffelStudio was built. For each major release we create a branch named Eiffel_X.Y (it will now be Eiffel_YY.MM). This is where release specific bug fixes are added if needed. Whenever we do an actual release on our website, we create a tag release also named Eiffel_X.Y/Rn (and now it will be Eiffel_YY.MM/Rn) where `n' stands for the n-th release made for this particular version. The subversion number for the tag release will match exactly the last two components of the full version of EiffelStudio. For example, if we take the 7.3 release, the current full revision is 7.3.9.2766, thus the subversion revision number is 92766. This was the first release of 7.3, thus you can look at the last commit at the following URL https://svn.eiffel.com/eiffelstudio/tags/Eiffel_73/R1 which is indeed 92766 by typing the following command: svn info https://svn.eiffel.com/eiffelstudio/tags/Eiffel_73/R1/ Happy Eiffeling, Manu [Less]

On Tuesday, March 12th, we will be celebrating the 20th anniversary of the first commit on EiffelStudio (formerly known as EiffelBench). The first commit entry reads: Author: grator Date: Fri Mar 12 13:00:58 1993 UTC Message: Initial revision At the ... [More] time, the source control management system used at Eiffel Software was RCS. We had one user grator who was in charge of committing any changes. The name grator is an abbreviation of integrator as it was too long for a username at the time (9 characters when 8 was the limit.) If your code was not satisfactory for grator you would have to go back and improve your work. Starting in July 1995, the policy was relaxed and users were allowed to commit their modification themselves. In 1997/98, we upgraded our source control management system to CVS. It made a huge improvements for our development work on Windows where we could now commit directly from Windows rather than having to create a tarball and move it to UNIX where the commit would be done. At the end of 2005, we migrated to subversion a few month before open sourcing the code of EiffelStudio in April 2006. Having 20 years worth of history is invaluable. Often we go back to find out why certain changes were made. We are lucky to have that much historical information. In addition, it is good way to track how things are done and how they evolve over the years. What would be the next source control management system we will be using? Who knows? But one thing is sure, it has to preserve the whole history. No way we can remove this jewel of information. Happy committing and Eiffeling! Manu [Less]

On Tuesday, March 12th, we will be celebrating the 20th anniversary of the first commit on EiffelStudio (formerly known as EiffelBench). The first commit entry reads:   At the time, the source control management system used at Eiffel Software was ... [More] RCS. We had one user grator who was in charge of committing any changes. The name grator is an abbreviation of integrator as it was too long for a username at the time (9 characters when 8 was the limit.) If your code was not satisfactory for grator you would have to go back and improve your work. Starting in July 1995, the policy was relaxed and users were allowed to commit their modification themselves. In 1997/98, we upgraded our source control management system to CVS. It made a huge improvements for our development work on Windows where we could now commit directly from Windows rather than having to create a tarball and move it to UNIX where the commit would be done. At the end of 2005, we migrated to subversion a few month before open sourcing the code of EiffelStudio in April 2006. Having 20 years worth of history is invaluable. Often we go back to find out why certain changes were made. We are lucky to have that much historical information. In addition, it is good way to track how things are done and how they evolve over the years. What would be the next source control management system we will be using? Who knows? But one thing is sure, it has to preserve the whole history. No way we can remove this jewel of information. Happy committing and Eiffeling! Manu [Less]

On Tuesday, March 12th, we will be celebrating the 20th anniversary of the first commit on EiffelStudio (formerly known as EiffelBench). The first commit entry reads: Author: grator Date: Fri Mar 12 13:00:58 1993 UTC Message: Initial revision At the ... [More] time, the source control management system used at Eiffel Software was RCS. We had one user grator who was in charge of committing any changes. The name grator is an abbreviation of integrator as it was too long for a username at the time (9 characters when 8 was the limit.) If your code was not satisfactory for grator you would have to go back and improve your work. Starting in July 1995, the policy was relaxed and users were allowed to commit their modification themselves. In 1997/98, we upgraded our source control management system to CVS. It made a huge improvements for our development work on Windows where we could now commit directly from Windows rather than having to create a tarball and move it to UNIX where the commit would be done. At the end of 2005, we migrated to subversion a few month before open sourcing the code of EiffelStudio in April 2006. Having 20 years worth of history is invaluable. Often we go back to find out why certain changes were made. We are lucky to have that much historical information. In addition, it is good way to track how things are done and how they evolve over the years. What would be the next source control management system we will be using? Who knows? But one thing is sure, it has to preserve the whole history. No way we can remove this jewel of information. Happy committing and Eiffeling! Manu [Less]

In 7.3 we are introducing an improved completion in the EiffelStudio editor. In addition to being able to see the feature name, feature signature, you will now be able to see the contracts of the routine as you can see in the screenshot below. If you have any other suggestions we could do to improve the completion, let us know!

In 7.3 we are introducing an improved completion in the EiffelStudio editor. In addition to being able to see the feature name, feature signature, you will now be able to see the contracts of the routine as you can see in the screenshot below. If you have any other suggestions we could do to improve the completion, let us know!