23
I Use This!
Very Low Activity

News

Analyzed 36 minutes ago. based on code collected about 11 hours ago.
Posted about 14 years ago by manus_eiffel
I'm not sure if this feature was noticed by many so I figured out I would write an entry on the matter. Starting with 6.5 we have added the notion of transient attribute to our runtime. Transient attributes are not stored to disk and thus their ... [More] absence in the storable file means that they can safely be ignored upon retrieval. In a void-safe system, it also implies that the type of the attribute must be detachable. It can be useful in many scenarios. The most common one is the case of once per object implemented using an attribute and used as a caching mechanism. Since the value can easily be recomputed, you do not want to store the computed value to disk. How it works, simply declare an attribute with a special note clause: transient_attribute: detachable STRING note option: transient end In 6.5, the support for transient only works with the C storable mechanism. In our forthcoming 6.6 release, it will also work with the Eiffel storable mechanism (a.k.a. SED) on both classic and .NET. It even works on .NET when using the .NET serialization library (to this purpose we are using the Microsoft .NET NonSerializedAttribute custom attribute on Eiffel generated attributes.) In addition in 6.6, INTERNAL has been augmented with queries to find out how many persistent fields they are in a type as well as finding out if a field is transient or not. Happy Eiffeling, Manu [Less]
Posted over 14 years ago by manus_eiffel
Here are the answers for the quiz of last week: b=2 b=2 b=2 and an exception b=4 and no exception returns 2 returns 1 and b=2 The difficult ones where definitely the last 3. Note that for #4 this is rejected by C# which ... [More] forbids exiting from the finally clause (actually this is a .NET runtime restriction that has moved up to the language specification). If you are unlucky and have to program in Java (instead of Eiffel as I do), you have to be careful when handling code that makes an extensive use of try .. finally... with goto style code flow. [Less]
Posted over 14 years ago by manus_eiffel
Last week I was at the LASER 2009 summer school on Software Testing. It was pretty interesting and one brief talk captured my attention. The speaker, Martin Nordio, asked the audience if they knew Eiffel and only a few hands were raised. So he asked ... [More] if they knew Java instead. Everyone raised his hand. To show to the audience they were wrong in assuming they knew about Java, he showed 6 samples of source code written in Java and asked the audience what the program did and bet that no one would have the right 6 answers. Let's do the same here. I'm going to give you the exercises and will post the answers in my next blog entry. 1. What is the value of b at the end of this code: foo () {     int b = 1;     b++; } ? 2. What is the value of b at the end of this code: foo () {     int b = 1;     while (true) {         b++;         break;     } } ? 3. What is the value of b at the end of this code and tell us if this executes normally or with an exception: foo () {     int b = 1;     try {         throw new Exception();     }     finally {         b++;     } } ? 4. What is the value of b at the end of this code and tell us if this executes normally or with an exception: foo () {     int b = 1;     while (true) {         try {             b++;             throw new Exception();         }         finally {             b++;             break;         }     }     b++; } ? 5. The previous sample was too long, what does this return: int foo () {     try {         return 1;     }     finally {         return 2;     } } ? 6. If you have answered properly to the above questions, then you are definitely quite an expert. To prove it, tell us the value of b at the end of the call as well as the return value: int b; int foo () {     b = 0;     try {         b++;         return b;     }     finally {         b++;     } } ? PS: Feel free to post your answers as comments to this blog entry. [Less]
Posted over 14 years ago by manus_eiffel
Recently one of our customer found a loss of precision in their floating point arithmetic computations involving REAL_32 and REAL_64. This loss can be seen in the code below: make     local         x: REAL_32         y: REAL_64         z: REAL_64   ... [More]   do         x := 0         y := 1.123456789012345         z := x + y     end where at the end the value of z was not equal to the value of y. The explanation yields on the unfolded form of the x + y operation. Indeed, the compiler interprets it as: x.plus (y) Where the signature of plus in class REAL_32 reads: plus alias "+" (other: REAL_32): REAL_32 Because y is of type REAL_64 and there is a conversion from REAL_32 to REAL_64, the final code executed by the compiler is actually: z := x.plus (y.truncated_to_real) This is with the truncation to REAL_32 that we loose the precision. The conversion from REAL_64 to REAL_32 was added when the conversion mechanism was put in place to replace the magic behind numerical operation in the original version of Eiffel. The reason for adding it was that we did not want to break existing code that allowed assignment of REAL_64 to REAL_32 entities. A few years later, we now realize it was a bad move and in the next revision of EiffelStudio (i.e. 6.5) we are planning on removing that conversion. As a result some of your code might not compile. To give you an example, for EiffelStudio, over 6500 classes we had to change less than 60 classes. To better find out how you feel about that removal, I've created a poll where you can express whether or not you agree to remove that conversion. PS: Note also that the breaking change could just appear in the experimental version of the libraries so you might be immune from that problem if you keep using the compatible version. Updating your code to compile with that change will not break your code if you are compiling it with an older version of EiffelStudio which is a good thing. [Less]
Posted almost 15 years ago by manus_eiffel
Last night I've upgraded my iPod Touch to the latest iPhone OS 3.0 and its corresponding SDK. The OS upgrade went smoothly. However for the SDK, what I had done was not working when I switch the include path to use the 3.0 SDK because it also ... [More] required GCC 4.2 (by default it is GCC 4.0). Once I changed that, the Eiffel code compiled just fine. Since my last blog entry, the iPhone library available under $EIFFEL_SRC/experimental/library/iphone (and its corresponding example in $EIFFEL_SRC/examples/iphone/basic) is able to respond to the touch events. You can detect the start, the moving and the end of a touch. Here is the extract of the application: indexing     description : "basic application root class"     date        : "$Date: 2009-06-15 23:25:41 (Mon, 15 Jun 2009) $"     revision    : "$Revision: 79297 $" class     APPLICATION inherit     ARGUMENTS     SHARED_LOG     EXCEPTION_MANAGER create     make feature {NONE} -- Initialization     make             -- Run application.         local             l_app: UI_APPLICATION         do             create l_app             l_app.post_launch_actions.extend (agent launch)             l_app.launch         rescue             if attached last_exception as l_exception then                 put_string (l_exception.exception_trace)             end         end feature -- Actions     launch         local             window: UI_WINDOW             l_label: UI_LABEL             l_rect: CG_RECT         do             l_rect := (create {UI_SCREEN}.make).bounds             create window.make (l_rect)             create l_rect.make (10, 50, 300, 100)             create l_label.make_with_text ("Hello World!", l_rect)             l_label.set_background_color (                 create {UI_COLOR}.make_rgba (0, 1, 0, 1))             l_label.set_foreground_color (                 create {UI_COLOR}.make_rgba (1, 0, 1, 1))             l_label.align_text_center             window.extend (l_label)             window.touches_began_actions.extend (                 agent touch_began_action (l_label, ?))             window.touches_moved_actions.extend (                 agent touch_moved_action (l_label, ?))             window.touches_ended_actions.extend (                 agent touch_ended_action (l_label, ?))             window.show         end     touch_began_action (a_label: UI_LABEL; a_event: UI_EVENT)         local             l_point: CG_POINT         do             if attached {UI_TOUCH} a_event.all_touches.item as l_touch then                 l_point := l_touch.location                 a_label.set_text ("Starting touch " + i.out + " ...")                 a_label.set_center (l_point)                 i := i + 1             end         end     touch_moved_action (a_label: UI_LABEL; a_event: UI_EVENT)         local             l_point: CG_POINT         do             if attached {UI_TOUCH} a_event.all_touches.item as l_touch then                 l_point := l_touch.location                 a_label.set_text ("Moving touch " + i.out + " ...")                 a_label.set_center (l_point)                 i := i + 1             end         end     touch_ended_action (a_label: UI_LABEL; a_event: UI_EVENT)         local             l_point: CG_POINT         do             if attached {UI_TOUCH} a_event.all_touches.item as l_touch then                 l_point := l_touch.location                 a_label.set_text ("Ending touch " + i.out + " ...")                 a_label.set_center (l_point)                 i := i + 1             end         end     i: NATURAL_64 I'm looking for people who would like to help in improving the Eiffel iPhone library by wrapping the iPhone UI classes. If you are interested contact me so that we can get together to organize an effective plan of work. [Less]
Posted almost 15 years ago by manus_eiffel
Here it is: my first graphical iPhone/iPod Touch application entirely written in Eiffel using EiffelStudio: Nothing really fancy but it shows that it is doable. At the moment, you can test your Eiffel applications using either the iPhone Simulator ... [More] or the actual device. I'll put within the next few weeks when the iPhone graphical library is more complete the steps one should perform to achieve what I've achieved. [Less]
Posted almost 15 years ago by manus_eiffel
I was lucky to get my hands on an iPod Touch. The first thing I did was to install SSH, gcc, subversion, vim, gdb et voila! Checked out the source of the Eiffel Software runtime. Tonight, I'll compile the runtime and run our regression test suite on ... [More] it to make sure everything works properly. When this is done, I'll look at how to use Eiffel for iPhone/iPod Touch development. Anyone interested in wrapping the iPhone API, please let me know. [Less]
Posted almost 15 years ago by manus_eiffel
SourceForge started the Community Choice Awards. Click on this link to vote for EiffelStudio.
Posted about 15 years ago by manus_eiffel
Have you heard about the Y2K38 bug? If not, you should read the wikipedia entry about it. Is Eiffel immune of that problem? It depends on the platform and the C compiler you are using. The main two issues with time in the Eiffel libraries are: ... [More] The time stamp for files available through the FILE class. The EiffelTime library queries to get the current time (e.g. {DATE}.make_now). For the time stamp, regardless of your C compiler or platform, the FILE class will truncate the value since it is returning an INTEGER_32. So there is some work to be done there to get the INTEGER_64 value that most file system reports. For the EiffelTime library, it is more complicated. For sure, if you are using a 64-bit platform you are immune since the C layer we use to query the time is always 64-bit. On 32-bit platform the story is a little bit more complicated. For example, on Windows, if you use an older version than Visual Studio 2005, then your code won't work, but if you use VS 2005 or above then it should work because the C compiler uses a 64-bit representation even on 32-bit platform. For 32-bit unices, it seems that you are out of luck and as far as I can see I'm not even sure they can handle the dates beyond 2038 properly. To definitely avoid this problem, and if you haven't done so now, start developing 64-bit applications. It will certainly reduce your risk if you expect your code to run for the next 30 years or so. [Less]
Posted over 15 years ago by manus_eiffel
Like many, this weekend I've downloaded the beta version of Windows 7. And of course, the first thing I did was to install EiffelStudio. I chose the development version but I believe it should work equally well with 6.3. I was happy that it ... [More] installed without any problem using the MinGW C compiler. I compiled a few projects and everything seemed to work just fine. This made me very happy, but to top it off, Windows 7 seemed to behave properly. First the install was quick and painless. Morever disabling font smoothing has the effect of disabling font smoothing (on Vista you would get a mixture of both, see Who invented font smoothing), and enabling the windows classic style looks similar to classic style on XP (far from the ugly result with Vista). In 2010 and beyond, I'll still be using EiffelStudio and possibly using it on Windows 7. [Less]