You can subscribe to this list here.
2004 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(7) 
_{Nov}
(14) 
_{Dec}


2005 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(14) 
_{Nov}
(41) 
_{Dec}
(5) 
2006 
_{Jan}
(35) 
_{Feb}
(1) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(5) 
2007 
_{Jan}
(62) 
_{Feb}
(27) 
_{Mar}
(6) 
_{Apr}
(1) 
_{May}
(8) 
_{Jun}

_{Jul}

_{Aug}
(23) 
_{Sep}
(9) 
_{Oct}
(64) 
_{Nov}
(2) 
_{Dec}
(4) 
2008 
_{Jan}
(15) 
_{Feb}

_{Mar}
(15) 
_{Apr}
(2) 
_{May}
(12) 
_{Jun}
(5) 
_{Jul}
(40) 
_{Aug}
(1) 
_{Sep}
(40) 
_{Oct}
(10) 
_{Nov}
(10) 
_{Dec}

2009 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}
(4) 
_{Jul}
(8) 
_{Aug}

_{Sep}
(6) 
_{Oct}

_{Nov}

_{Dec}

2010 
_{Jan}

_{Feb}

_{Mar}
(1) 
_{Apr}
(6) 
_{May}
(9) 
_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}
(1) 
_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1
(8) 
2
(1) 
3
(4) 
4

5
(1) 
6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30





From: Emmanuel Stapf [ES] <manus@ei...>  20041105 23:27:21

> > (abs /= maximum_integer + 1) implies sign * abs.to_integer_32 = item > > But here "maximum_integer + 1" again causes overflow. We could also do `maximum_integer.to_natural + 1'. > Then in INTEGER_nn classes there will be no need to repeat > all these assertions. That was the idea but we need to make sure that this is feasible. Manu 
From: Alexander Kogtenkov <kwaxer@ah...>  20041103 09:34:05

> Why don't we disallow the minimum integer value for abs. That's what most other > libraries do. I think we can do it as well. > On the other hand, we could do: > > abs: NATURAL_32 > > (abs /= maximum_integer + 1) implies sign * abs.to_integer_32 = item But here "maximum_integer + 1" again causes overflow. > (item /= minimum_integer) implies sign * abs.to_integer_32 This relation works even when "abs" is of type INTEGER. So, it can look like the original: (item /= minimum_integer) implies sign * abs = item where "abs" is of type INTEGER. > We still need > to discuss the business of INTEGER_GENERAL to see if we plan on using it or not. This class can be used to specify common interface for all INTEGER classes, i.e. pre and postconditions, class invariants, etc. E.g., we could have class INTEGER_GENERAL inherit COMPARABLE HASHABLE NUMERIC feature  Limits minimum: like Current  Minimum integer value deferred ensure result_not_void: Result /= Void end maximum: like Current  Maximum integer value deferred ensure result_not_void: Result /= Void end feature  Status report sign: like Current  Sign of integer deferred ensure result_not_void: Result /= Void valid_result: Result.is_equal (one) or else Result.is_equal (zero) or else Result.is_equal (one) end feature  Operations abs: like Current require not_minimum: not is_equal (minimum) deferred ensure non_negative_result: Result >= zero end invariant is_equal (minimum) or else is_equal (sign * abs) end Then in INTEGER_nn classes there will be no need to repeat all these assertions. Regards, Alexander Kogtenkov 
From: Emmanuel Stapf [ES] <manus@ei...>  20041103 06:10:04

> What about using SF bugtracking system to keep the list of TODO/FIXME? I'm fine using this as well. Manu 
From: Emmanuel Stapf [ES] <manus@ei...>  20041103 06:07:52

> > I plan to write similar tests for Free ELKS with 'getest' so that I > > can at least check whether Gobo can reply on it. If you > want I can put > > these tests somewhere in test/ (next to library/). > > It would be great. Manu? > > (As I understand, the tests you mention are not part of Gobo package. > Otherwise they will be duplicated which is not good.) Yes, the directory is created. Manu 
From: Emmanuel Stapf [ES] <manus@ei...>  20041103 06:03:44

> So, would not it be better to use INTEGER for abs and specify > that abs as well as other arithmetic operations are performed > modulo 32 bits, therefore they can overflow, examples are > "abs" performed on minimum integer, '*' performed on values > with product beyond 32 bits, etc. > and just document this behavior? (A side effect of this > approach is better performance.) If someone needs precise > arithmetic, he have to use special classes anyway. Why don't we disallow the minimum integer value for abs. That's what most other libraries do. On the other hand, we could do: abs: NATURAL_32 (abs /= maximum_integer + 1) implies sign * abs.to_integer_32 = item or (item /= minimum_integer) implies sign * abs.to_integer_32 Is this acceptable? Regards, Manu PS: If you don't mind, I'll add a skeleton class for all the NATURAL_xx type in the next few days, they will closely follow the INTEGER_xx classes. We still need to discuss the business of INTEGER_GENERAL to see if we plan on using it or not. Per ECMA we should, but I think at ECMA we still have some gray area here. 
From: Alexander Kogtenkov <kwaxer@ah...>  20041102 09:49:19

Eric Bezault wrote: > > 4) change type of a result to NATURAL_nn ... > Personally I prefer 4). ... > As for `abs' returning a different type, it is not worse > that `infix "/"' which returns a DOUBLE. There is still a problem with class invariant sign * abs = item E.g., for INTEGER we will have sign: INTEGER abs: NATURAL_32 item: INTEGER In order to perform "*" we need to convert NATURAL_32 to INTEGER_mm. Absolute value of minimum integer cannot be converted back to INTEGER. So, we could change the invariant to sign * abs.to_integer_64 = item But this approach does not work for class invariant in INTEGER_64, because there is no INTEGER_128. So, would not it be better to use INTEGER for abs and specify that abs as well as other arithmetic operations are performed modulo 32 bits, therefore they can overflow, examples are "abs" performed on minimum integer, '*' performed on values with product beyond 32 bits, etc. and just document this behaviour? (A side effect of this approach is better performance.) If someone needs precise arithmetic, he have to use special classes anyway. Regards, Alexander Kogtenkov 
From: Eric Bezault <ericb@go...>  20041101 14:01:05

Alexander Kogtenkov wrote: > Eric Bezault wrote: >>I plan to write similar tests for Free ELKS with 'getest' so that I >>can at least check whether Gobo can reply on it. If you want I can >>put these tests somewhere in test/ (next to library/). > > It would be great. Manu? > > (As I understand, the tests you mention are not part of Gobo package. > Otherwise they will be duplicated which is not good.) The tests I mentioned are not written yet, but I will write them when using Free ELKS in Gobo. So they will be either in the Gobo package or in Free ELKS, but not both. The advantage of putting them in Free ELKS is that they can be shared by all users/developers of Free ELKS. I think that some tests will look like the ones in: $GOBO/test/kernel/ks_test_*.e probably with more comments to explain each test, and with more test cases to exercise boundary values (which are often the source of bugs).  Eric Bezault mailto:ericb@... http://www.gobosoft.com 
From: Alexander Kogtenkov <kwaxer@ah...>  20041101 13:40:09

Eric Bezault wrote: > I plan to write similar tests for Free ELKS with 'getest' so that I > can at least check whether Gobo can reply on it. If you want I can > put these tests somewhere in test/ (next to library/). It would be great. Manu? (As I understand, the tests you mention are not part of Gobo package. Otherwise they will be duplicated which is not good.) Alexander Kogtenkov 
From: Alexander Kogtenkov <kwaxer@ah...>  20041101 13:34:11

The accompanying bug is in a class invariant: sign * abs = item Let's look at types of the features in class INTEGER_8: sign: INTEGER abs: INTEGER_8 item: INTEGER_8 For value 128 we'll have sign = 1 (INTEGER) abs = 128 (INTEGER_8) item = 128 (INTEGER_8) Then sign * abs = 128 (INTEGER) and sign * abs = item gives false. If "sign" were of type INTEGER_8, then there were no problems even with implementation of "abs" that returns negative result for minimum integer. Wouldn't it be better to change type of "sign" from INTEGER to INTEGER_8? BTW, according to ELKS'95 the type of "abs" should be "like Current" and not "INTEGER*". Alexander Kogtenkov 
From: Eric Bezault <ericb@go...>  20041101 13:31:46

Alexander Kogtenkov wrote: > Would it make sense to document the specification and implementation > details not only in assertions and comments, but also in a set of tests, > so that we can always run them to see if some changes are breaking? In Gobo I use 'getest' for that. Thanks to these tests I actually found and reported several bugs in ISE's kernel classes implementation. I plan to write similar tests for Free ELKS with 'getest' so that I can at least check whether Gobo can reply on it. If you want I can put these tests somewhere in test/ (next to library/).  Eric Bezault mailto:ericb@... http://www.gobosoft.com 
From: Alexander Kogtenkov <kwaxer@ah...>  20041101 12:59:45

> > There is a bug in specification of feature INTEGER*.abs. Would it make sense to document the specification and implementation details not only in assertions and comments, but also in a set of tests, so that we can always run them to see if some changes are breaking? What about using SF bugtracking system to keep the list of TODO/FIXME? Alexander Kogtenkov 
From: Alexander Kogtenkov <kwaxer@ah...>  20041101 12:50:38

The accompanying bug is in a class invariant: sign * abs = item Let's look at types of the features in class INTEGER_8: sign: INTEGER abs: INTEGER_8 item: INTEGER_8 For value 128 we'll have sign = 1 (INTEGER) abs = 128 (INTEGER_8) item = 128 (INTEGER_8) Then sign * abs = 128 (INTEGER) and sign * abs = item gives false. If "sign" were of type INTEGER_8, then there were no problems even with implementation of "abs" that returns negative result for minimum integer. Wouldn't it be better to change type of "sign" from INTEGER to INTEGER_8? BTW, according to ELKS'95 the type of "abs" should be "like Current" and not "INTEGER*". Alexander Kogtenkov 
From: Eric Bezault <ericb@go...>  20041101 12:40:09

Alexander Kogtenkov wrote: > There is a bug in specification of feature INTEGER*.abs. > It accepts any integer and produces a nonnegative result > with the same type. But this does not work for minimum > integer value, because the corresponding positive value > cannot be represented in the same integer type. E.g., > for INTEGER_8 the minimum value is 128. But 128 > cannot be represented by INTEGER_8. I can see the > following solutions to this problem: > 1) add a precondition that the integer is not minimal > 2) change a postcondition so that minimum input value > gives negative result > 3) change type of a result to INTEGER_mm, where mm is > higher than nn of the current type (so that INTEGER_8.abs > will be of type INTEGER_16) > 4) change type of a result to NATURAL_nn > > None of the above seems ideal to me because > 1) additional checks before calling "abs" will complicate the code > 2) negative result looks strange for this feature > 3) there is no "higher" type for INTEGER_64 > 4) result falls into a domain of different types with different rules Personally I prefer 4). In fact I think that when we will have NATURAL it will be better to replace entities declared of type INTGER with an assertion "blahblah >= 0" (e.g. STRING.count, ARRAY.capacity, etc.) by entities of type NATURAL. That way we double the capacity of these containers and the "assertion" is checked at compilation time. As for `abs' returning a different type, it is not worse that `infix "/"' which returns a DOUBLE. > BTW, would not it make sense to change implementation of "abs" from > Result := abs_ref.item > to > if item >= 0 then > Result := Current > else > Result := Current > end > and remove "abs_ref" altogether? I think that `abs_ref' was a workaround for a bug in the old days of ISE Eiffel. We should indeed get rid of it.  Eric Bezault mailto:ericb@... http://www.gobosoft.com 
From: Alexander Kogtenkov <kwaxer@ah...>  20041101 11:15:31

There is a bug in specification of feature INTEGER*.abs. It accepts any integer and produces a nonnegative result with the same type. But this does not work for minimum integer value, because the corresponding positive value cannot be represented in the same integer type. E.g., for INTEGER_8 the minimum value is 128. But 128 cannot be represented by INTEGER_8. I can see the following solutions to this problem: 1) add a precondition that the integer is not minimal 2) change a postcondition so that minimum input value gives negative result 3) change type of a result to INTEGER_mm, where mm is higher than nn of the current type (so that INTEGER_8.abs will be of type INTEGER_16) 4) change type of a result to NATURAL_nn None of the above seems ideal to me because 1) additional checks before calling "abs" will complicate the code 2) negative result looks strange for this feature 3) there is no "higher" type for INTEGER_64 4) result falls into a domain of different types with different rules 2) seems to be the most simple, because it just documents the current behaviour. BTW, would not it make sense to change implementation of "abs" from Result := abs_ref.item to if item >= 0 then Result := Current else Result := Current end and remove "abs_ref" altogether? Regards, Alexander Kogtenkov 