EiffelStudio

For our work on migrating all the Eiffel Software source code to void-safe mode in 6.4, I've updated our Eiffel Syntax Updater tool to update our source code automatically. The tool will be included in the next intermediate release of 6.4 so that you ... [More] can also update your code to the new ECMA syntax. We will also include compile_all, a tool that compile all the Eiffel Configuration files it finds in a directory and reports whether or not they compile successfully. We use this tool to verify that all our code compiles on a regular basis. The next release will accept attribute and note out of the box. In 6.3 you had to manually choose the transitional syntax in order to use them. I wish you a very good 2009 year. Happy Eiffeling! [Less]

In the past, some of our customers, especially those who are compiling files that are not on their local hard drive, have been complaining that degree 6 takes an enormous amount of time to complete. The reason is pretty simple. At degree 6, we fetch ... [More] the name of the classes so that proper class name resolution is done in the later degrees. To fetch the name, we open the file, reads its beginning until we find the name of the class. Once found, we close the file and continue onto the next one. On a slow network, opening a file is a very expensive operation. And even on your local drive, if your OS is Windows, it could take a long time when Windows hasn't yet buffered your files. To solve this bottleneck, EiffelStudio 6.4 will now assume on the first analysis that the class name is the same as its file name. And then when actually parsing the class at degree 5, it discovers a mismatch, it will rebuild degree 6 the expensive way to ensure that there are no other mismatches like that. At the end of the day, it should be pretty much the same to the end users that have fixed their VD80 warnings about a class name not matching its file name. So here is your first 2009 year resolution: make sure to fix those warnings before upgrading to 6.4 to benefit from the degree 6 speed up. Happy Eiffeling and Merry Christmas, Manu [Less]

We just released EiffelStudio 6.3 and are already working on the next 6.4 iteration. EiffelStudio 6.4 is a maintenance release toward a full adoption of the ECMA standard. Some of the changes in ECMA require a change in our libraries. Unfortunately ... [More] some changes are making the libraries not backward compatible. To avoid a major rewrite of your code, we will ensure that the new version of the compiler will still be able to compile the 6.3 libraries. That way when 6.4 is out, you do not have to upgrade your code right away although there will be a good incentive to do so. The list of changes are: use of alias for specifying operators in place of infix and prefix. prevent export of the copy, deep_copy, twin, deep_twin routines from ANY. use ~ operator in place of is_equal. change the postcondition of {ANY}.is_equal to enforce that it can only hold if both objects have the same type. making all our libraries void-safe. {ANY}.generating_type to return an instance of TYPE [like Current] instead of STRING. Because they are breaking changes, maybe we can pack as many breaking changes to avoid having more breaking changes in releases right after 6.4. One of them is to use NATURAL where a non-negative INTEGER is expected. You can vote for that change here. If you have other ideas of changes that has been discussed in the past and that are not in this list, feel free to post a comment. Happy Eiffeling! [Less]

Last week, I was wrapping some C code for a customer and I was surprised that my code did not work properly. I'm not a C programmer and thus this error might have been a typical gotcha but still this was a very surprising behavior. The code in ... [More] question was: void my_routine (CppClass my_obj, int buffer_count, char * buffer) {     const char * l_cstr = my_obj->getName().c_str();     memcpy(buffer, l_cstr, buffer_count); } The line that did not work was the `memcpy' call. It was only tested to fail with Visual Studio 2005 on 64-bit. I have a workaround and a friend of mine gave me some explanation on this problem. But do you know it? And if you do, do you think the rule is safe? [Less]

EiffelStudio 6.2 has just been released. For those who haven't followed the intermediate releases, here is an idea of what is included: Added new contract editor tool to ease edition of contracts on routines and classes. Added Eiffel ... [More] Information System which let you connect external documentation to your Eiffel code and vice versa. Added ability to avoid comment duplication by using the <Precursor> in your descendant comment to reuse the parent one which is shown in all our formatter tools.. Added new light batch compiler `ecb'. It provides the same features as `ec' when using the batch mode. Currently projects compiled with `ec' are not compatible with those compiled with `ecb'. The main difference between the two is that `ec' is compiled with exception trace and multithreading support which could slow down the compiler by a factor of 20 to 40% depending on your platform. Note that projects compiled with ecb are not compatible with those compiled with ec. Added experimental unit testing tool. Exceptions are objets are now implemented. Added support for new ~ operator which can compare 2 objects safely regardless of their type. Added detection of harmful catcall at runtime (harmless one are currently ignored). Added support for `note' keyword with a migration path in case `note' is being used as an identifier in your code. Added `-gc_stats' option to get some information on how much CPU time is spent in GC during an Eiffel compilation. Introduced several new much more powerful CAPs that now can be applied not only to read-only entities, but also to local variables (including Result), and can take into account execution paths as well as some obvious void-safe patterns. Happy Eiffeling, Manu Digg it! Download it! [Less]

A while ago I've heard about Haiku through an online Google Tech Talk. I was immediately captivated because Haiku is actually a clone of BeOS and I definitely remember the BeOS days. It was when Mac OS was not up to the task anymore and BeOS seemed a ... [More] promising alternative. I even met Jean Louis Gassée in 1999 at the BeOS HQ to discuss the possibility of having EiffelBench (at the time) running on BeOS. Yesterday evening I decided to try Haiku OS in VMWare (they provide a daily build of Haiku OS on their website). Of course after a few minutes, I could not resist to try compiling Eiffel code on it. So first I needed to compile the run-time, it was not so easy because the VMWare image they provide contains nothing for development. They are actually building Haiku OS on Linux using Ubuntu 7.10. First I add to get subversion to checkout the source code: http://www.haiku-os.org/files/Subversion-1.1.3.pkg Then I had to get the development tools for BeOS: http://www.bebits.com/bob/12419/BeOS5-DevTools.zip And last, patching the development tools by using this version of GCC: http://www.bebits.com/bob/21138/gcc-2.95.3-beos-070218.zip Once I had that in place, I checked out the runtime from our mirror repository of Origo. I had to do that because the subversion package (mentioned above) is an old one and does not support https which is the only protocol supported by Origo. This is a minor nuisance since our mirror is a read-only version and therefore I have to copy my files over a different machine to perform the commit. After checking out the source code, I configured the runtime to get a new configuration file for Haiku. After a few attempts and hacking <be/support/Errors.h> to rename B_BUSY into B_BUSY2 (we unfortunately define B_BUSY in our run-time) I had built a finalized runtime. I've committed my changes at rev#73300 in our repository for anyone to try. Currently I did not have time to look at 2 issues which prevents a full build of the runtime: Cannot compile the workbench runtime due to our communication stuff for debugging Cannot compile the multithreaded support since Haiku has its own threading model. Once I had done that, I compiled the calculator example on Haiku to see if it worked and it did. Next step was obviously compiling the batch compiler (the graphical would not do since we rely on GTK or Win32 for our UI and none of them exist on Haiku). I had a few issue with our internationalization code (since Haiku has limited support for it or at least no `iconv' emulation) but got rid of the issues by commenting out pieces of our code. And the compiler compiled just fine and executed as well. I've uploaded an Eiffel delivery for Haiky on our Origo and Sourceforge mirror for those who are interested in trying it. Note that it only contains the bare minimum to compile finalized executable (no workbench support and no multithreading support). To use it simply defines the following environment variable: ISE_EIFFEL to the path where Eiffel62 directory is located ISE_PLATFORM to haiku-x86 For more info on Developing for Haiku, read the following development page: http://www.haiku-os.org/development Happy Eiffeling on Haiku [Less]

Facts It's unlike me to complain (or maybe it's not, up to you to decide), but in the past few years it seems that software vendors have decided what was best for me and I really do not like this, especially when it affects 100% of the time I'm in ... [More] front of my computer.It all started when Windows XP (2000/2001) and Mac OS (2001) came out with smooth fonts. At the time, only Windows got it right. That is to say, you could disable it, period! On the Mac, you could and can still only disable it for a font size smaller than a certain value but you can only set this value at most to 12pt. How useless this is, especially when the Mac default font is more like 14pt! Basically, it means you cannot turn it off. It's no wonder why a former Mac addict (from 1985 to 1999, the year when Apple decided not to support my expensive PowerPC with Mac OS X) such as myself will not go back to using Mac OS – at least not until they get rid of font smoothing. Then Vista came along. But, Vista is now just like Mac OS, and maybe even worse since although you have a setting to turn it off, only half of the windows of the OS follow this setting – so in effect, you can't turn it off. This is actually ugly to look at. For me, among the zillions of reasons not to upgrade to Vista, that's the number one. Then, Office 2007 came along and did the same thing. Even if your Windows XP has the setting off, Office is a bad application and still decides to use smooth fonts. This is why I'm sticking to Office 2003 until they fix this in a future version of Office. But why this posting now? Simply because last night, Apple, like they do every two weeks, reminded me to update QuickTime on my laptop, but this time around, it also proposed "Safari" for Windows. I was curious and decided to install it. I was actually very excited to try it since IE and Firefox like to use a lot of memory and wanted to see how it would compare on that front. But my excitement was quickly turned down when font smoothing was enabled and like Mac OS the setting to disable it was pretty useless. For me this is a "Bye Bye" to Safari. It is sad, because the other Apple Softwares I've tried on Windows do not suffer from this problem. Are you like me? Anyone want to join me on a crusade against font smoothing? Why I don't like smooth fonts? Maybe it is hard to understand for those who do not wear corrective lenses. But if you are like me with a moderate myopia, you know that without glasses everything you see is blurry. So when you wear glasses and something is blurry, you always wonder whether or not it is you who needs new glasses or if there really is something wrong.When LCDs came along, there was no way for me to go back to CRT because I could finally get very sharp edges, no more blurry pixels. You now understand why when font smoothing was introduced, I could not stand it. Conclusion So basically, I'm not saying font smoothing should not exist, but that it is up to the user to decide what he prefers, not the OS nor the application. Preemptive comment Q: Why don't I use Unix instead?A: If nothing changes in the next few months, when it will be time to update my laptop which is becoming quite old, I might just do that. PS This is why in EiffelStudio this will never happen without the user's consent. Also, the blurriness of CRTs was what made EiffelStudio work great when using big fonts on Windows since I had to use them to reduce blurriness on my 1600x1200 CRT monitor. I still hope it is the case, but I haven't verified that since I've upgraded to a LCD monitor which does not need big fonts. [Less]

I don't know if you are like me but often when you redefine a feature, I used to copy/paste the comments so that I still know what the feature is supposed to do in english terms (in addition to the contracts of course). In 6.2, we are introducing a ... [More] new facility so that in the editor and in the flat-view of the feature you do not have to do the copy/paste. I'm going to use classes from the compiler to show the new feature. The definition of {TYPE_A}.good_generics states: good_generics: BOOLEAN is             -- Has the base class exactly the same number of generic             -- parameters in its formal generic declarations?         require             is_class_valid: is_class_valid         do             Result := True         end and now in my descendant LIKE_TYPE_A, I just do the following: good_generics: BOOLEAN is             -- <Original>         do             Result := actual_type.good_generics         end Basically, what we are doing is that the comment -- <Original> is a placeholder to get the inherited comment. In the EiffelStudio editor, it is shown by the following tooltip when you leave your mouse pointer over the feature name for a few seconds: Note that if you do put no header comment in the redefined routine, we will still show the inherited comment. However it was felt that having -- <Original> was a clear indication for the reader of the class that the header comment was not forgotten. And if you inherit the routine from various ancestors, you can choose which ancestor's comment to take by using the following syntax -- <Original {MY_ANCESTOR}>. If you have any feedback on this new feature, please let us know by dropping a comment. [Less]

A week ago, we started the cycle of intermediate releases of 6.2. They can be found on the EiffelStudio development site at http://eiffelstudio.origo.ethz.ch. One of the new feature of this release is the introduction of the ECMA specification ... [More] regarding exceptions: exceptions as objects. If you want to know more on this topic, check Ted's blog entry on the subject. It was originally scheduled for 6.1 and due to lack of testing we postponed its integration to 6.2. It should not break existing code based on integer code, but we are interested to know about your experiments with this new release. Other developments of 6.2 can be found in our road map page. And since we are starting a new year, I wish you all the best for 2008 and count on your support to spread the usage of Eiffel. [Less]

EiffelStudio 6.1 has just been released. For those who haven't followed the intermediate releases, here is an idea of what is included: New default layout for EiffelStudio tools to highlight the most common used tools whereas other tools are ... [More] still available at the bottom or via the View menu. New Errors and Warnings tool. It replaces the former Errors tool and Warnings tool and provides a nicer way to show errors and filtering them. Execution Replay in debugger to allow you to go back at previous execution states. Revisited all the dialogs to provide a nicer and consistent look and feel. Multiple errors are reported for each compilation degree. Added ability to submit a problem report within EiffelStudio when it quits unexpectedly. Support for the MinGW C compiler on Windows 32-bit. Borland is officially not supported anymore. Attached types. Non-conforming inheritance. Compiler speed up for degree 3. Happy Eiffeling, Manu [Less]