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]
|