23
I Use This!
Very Low Activity

News

Analyzed about 9 hours ago. based on code collected about 20 hours ago.
Posted almost 17 years ago by manus_eiffel
Last week-end, we did our last intermediate release of the development cycle for EiffelStudio 6.0. The next month will be devoted to testing with a planned release mid-June. While waiting for the release, I'm taking the opportunity to highlight some ... [More] of the neat features of EiffelStudio 6.0. UI Tabbed editor Docking facility to organize the layout of EiffelStudio Contextual menus Internationalization with Chinese, French, German, and Russian currently supported Browsing tools New dependency tool to see dependencies of software elements Create your own formatters Debugger Added new kind of breakpoints: to print messages, hit count for condtitions. Let's you now evaluate commands in addition of queries. New ways of looking at objects. Compiler Added new ECMA features: multiple constraints, reattachment of generic derivations with expanded actual parameters to entities with reference parameters. Removed the need of a configuration file to compile small systems, you can simply do ec root_class.e to compile a class. If you want to know more about the 6.0 release, you will find more details on our wiki EiffelStudio 6.0 Features and on our documentation site when it is released. Happy Eiffeling. [Less]
Posted about 17 years ago by manus_eiffel
This was announced today: Bertrand Meyer is the Recipient of Software System Award for Impact on Software Quality. Most precisely, for designing and developing the Eiffel programming language, method and environment, embodying the Design by Contract ... [More] approach to software development and other features that facilitate the construction of reliable, extendible and efficient software. You can get the press release from: http://campus.acm.org/public/pressroom/press_releases/3_2007/eiffel.cfm And you can digg it at: http://www.digg.com/programming/Eiffel_rewarded_for_the_ACM_Software_System_Award [Less]
Posted about 17 years ago by manus_eiffel
Yesterday one of our very old server died due to a power supply failure. Nothing unusual for an old computer (Celeron 300MHz with 128MB of RAM from 1998), so when we wanted to replace the power supply, we were surprised to see this: Apparently a ... [More] mouse had settled in our server for some time. We quickly wondered how it had entered in the computer's case and we saw that one of the ISA slots hadn't been covered. Mystery solved. After the fact, we wonder if there was some relation between the power supply failure and the mouse, and where the mouse is. By the way, who said that programmers are chasing bugs? Maybe we should say that they are chasing mice. [Less]
Posted about 17 years ago by manus_eiffel
Until very recently, EiffelStudio generated .NET assemblies would not work with Mono. The culprit was the usage of the #- metadata table format (a non-standardized Microsoft .NET extension which allows specification of the metadata out-of-order) that ... [More] Mono did not support. Version 1.2 of Mono supports this format and we decided to look further by checking the compatibility status of our generated .NET assemblies. Unfortunately it does not work yet. A quick interaction with the developers behind mono and we were informed that a next release will fix the issue preventing us to run our assemblies. So what is the next step? Simply continue the testing of our generated .NET assemblies against Mono. How? Using our compiler regression tool eweasel which is using a script to test generated executables. By default the script simply executes the program and if the execution is successful it will print Execution completed, if not Execution failed. So for running against Mono, we just need to modify this script to run the executables with the mono runtime, i.e. replacing test.exe by mono.exe test.exe. Once the testing is complete we will have a very good idea of what are the differences between .Net and Mono and in case of divergences how they differ in their interpretation of the CLI standard. But that's not the end of the story. Currently EiffelStudio is using Microsoft API to read and generate the metadata tables, thus to fully support Mono we need to rewrite those parts to be API independent. After doing this, you can compile CLI assemblies on any platforms (of course to run the assembly you need Windows with .NET or any Unix with Mono). Unfortunately there is something missing in the picture, it is debugging. How to debug CLI assemblies in a Mono environment? Again we are currently using the Microsoft API for debugging on Windows and it is not clear if Mono offers an equivalent, and if it did, it is most likely very different from the Microsoft API. So until we know more about debugging Mono binaries, you will have to use the mono debugger. [Less]
Posted about 17 years ago by manus_eiffel
As of version 6.0.6.6895, EiffelStudio can compile against either EiffelBase or FreeELKS. "FreeELKS is a joint effort between Eiffel Software and Eric Bezault to provide a compiler independent implementation of the ELKS classes. Currently FreeELKS is ... [More] based on EiffelBase with minor modifications so that it can be compiled by more than one compiler, currently EiffelStudio and gec.<!--break--> The way FreeELKS works is by turning all features, that do not have a pure Eiffel implementation or that are handled specifically by a compiler, into external "built_in" features. For example, in ANY, the twin query now looks like: frozen twin: like Current is             -- New object equal to `Current'             -- `twin' calls `copy'; to change copying/twining semantics, redefine `copy'.         external             "built_in"         ensure             twin_not_void: Result /= Void             is_equal: Result.is_equal (Current)         end The current version of FreeELKS is not yet ready for release since it is an ongoing development but once the first version is available, it will be the default library used by EiffelStudio. The original EiffelBase will still be present for backward compatibility in case FreeELKS introduces some breaking changes. For those interested in how it works, here are some insights for the implementation in EiffelStudio. In the EiffelStudio delivery under $ISE_EIFFEL/studio you have a new directory built_ins with 3 subdirectories: dotnet: implementation of built_ins for .NET classic: implementation of built_ins for classic Eiffel neutral: implementation that is common to .NET and classic For each built_in feature, it will find its implementation in an Eiffel class located in one of the above directory. The lookup always start with the specific implementation (either .NET or classic) and then the neutral one. If no implementation can be found, the built_in feature is transformed into a C external whose alias is `eif_builtin_CLASS_NAME_feature_name' and an implementation must be provided by the runtime. Let's take the {ANY}.twin example which has a different implementation between .NET and classic. In classic mode, the compiler will try to load the class whose file name is ANY.e in the classic directory. Once loaded and parsed, it will lookup the `twin' feature in it and takes the Eiffel implementation as the implementation of {ANY}.twin. When looking at the flat form of a built_in feature or when stepping into a built_in routine, EiffelStudio will show you the Eiffel code corresponding to the implementation and not the `external "built_in"' body. Therefore you can even put a breakpoint in those routines. That's all there is to know about built_in features support in EiffelStudio. [Less]
Posted about 17 years ago by manus_eiffel
What is the difference between EIF_REFERENCE and EIF_OBJECT? EIF_REFERENCE is a direct reference to an Eiffel object. This reference is only valid until the next GC cycle which will move objects around and make some EIF_REFERENCE values invalid if ... [More] the GC does not update them. Storing the value of the EIF_REFERENCE is therefore unsafe. EIF_OBJECT on the other hand is a protected reference to an Eiffel object and won't change even after a GC cycle. To access its EIF_REFERENCE, simply use eif_access. What should be used? If you are building an external taking an Eiffel object, I recommend using EIF_REFERENCE rather than EIF_OBJECT since it will be faster (no protection is performed by the compiler while generating the code). But only do that if your C external does not perform any callbacks. Otherwise you have to use EIF_OBJECT. Summary Knowing when to use an EIF_REFERENCE or an EIF_OBJECT is critical to the reliability of your application when interfacing to C or CECIL.Want to know which one is used the most, check out: Google Fight Result. [Less]