freeelks-devel — Developer discussion about ELKS implementation/bugs/improvements

You can subscribe to this list here.

 2004 2005 2006 2007 2008 2009 2010 2015 Jan Feb Mar Apr May Jun Jul Aug Sep Oct (7) Nov (14) Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct (14) Nov (41) Dec (5) Jan (35) Feb (1) Mar Apr May Jun Jul Aug Sep Oct Nov Dec (5) Jan (62) Feb (27) Mar (6) Apr (1) May (8) Jun Jul Aug (23) Sep (9) Oct (64) Nov (2) Dec (4) Jan (15) Feb Mar (15) Apr (2) May (12) Jun (5) Jul (40) Aug (1) Sep (40) Oct (10) Nov (10) Dec Jan Feb Mar Apr May Jun (4) Jul (8) Aug Sep (6) Oct Nov Dec Jan Feb Mar (1) Apr (6) May (9) Jun Jul (1) Aug Sep Oct Nov Dec Jan Feb Mar (1) Apr May Jun Jul (1) Aug Sep Oct Nov Dec
S M T W T F S

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

5

6
(7)
7
(12)
8
(4)
9

10

11

12

13

14
(3)
15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

Showing results of 41

1 2 > >> (Page 1 of 2)
 Re: [freeelks-devel] INTEGER.abs From: Alexander Kogtenkov - 2005-11-14 12:29:49 ```Eric Bezault wrote: > Personally I prefer the precondition. > > But I wonder how different this case is compared to: > > Maximum_integer + 1 Ideally we should get a precondition violation in this case too. But it does not seem practical. Because integer types implement finite rather than infinite numbers, they implement modular arithmetic. Therefore we have a relation Maximum_integer + 1 = Minimum_integer So, from this point of view, the postcondition of "abs" can be relaxed to cover the case of `Minimum_integer'. Regards, Alexander Kogtenkov ```
 Re: [freeelks-devel] INTEGER.abs From: Eric Bezault - 2005-11-14 11:58:14 ```Alexander Kogtenkov wrote: > There is an issue with feature "abs" in INTEGER_nn types. > The postcondition is violated for a minimum integer value. > Wouldn't it be better to add a precondition that the value > is not equal to this minimum or to relax the postcondition > and to allow to produce negative result in this case? Personally I prefer the precondition. But I wonder how different this case is compared to: Maximum_integer + 1 or: {NATURAL_32} 3 - {NATURAL_32} 10 -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ```
 [freeelks-devel] INTEGER.abs From: Alexander Kogtenkov - 2005-11-14 11:00:01 ```There is an issue with feature "abs" in INTEGER_nn types. The postcondition is violated for a minimum integer value. Wouldn't it be better to add a precondition that the value is not equal to this minimum or to relax the postcondition and to allow to produce negative result in this case? Regards, Alexander Kogtenkov ```
 Re: [freeelks-devel] built-in or not built-in? From: Eric Bezault - 2005-11-08 18:11:07 ```Emmanuel Stapf [ES] wrote: >>Do you think it would be possible to write test cases that >>could be used as input of both your testing tool and getest >>in one way or another? What kind of input is expected by your >>testing tool? > > Our testing tool does not rely on library, but on an expected behavior. That is to > say we usually write tests which are simply a root class plus one or more other > classes which usually generates some output (eventually take some input if > necessary) and we compare the output with the expected output. > > So if the test using getest generates some predictable output, then we could use > them, we would just need to write an Ace file that includes the gobo test library. I think it is possible to do something. We could have a class TS_TEST_CASE with routines `assert_' which could either print the expected value (in one mode) or the computed value (in another mode). Then use the first mode to generate the expected output (in a file or wherever convenient for your testing tool). Use the second mode to actually run the test. The drawback is that we would have to maintain by hand a routine which will call all `test_*' features (whereas getest does that automatically for us). But it's little nuisance compared to the benefit of having the same test case classes being usable as-is by both your testing tool and getest. Indeed, with getest we would just use Gobo's version of TS_TEST_CASE instead of the one described above. I'll try to come up with something in the coming days. -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ```
 RE: [freeelks-devel] built-in or not built-in? From: Emmanuel Stapf [ES] - 2005-11-08 16:55:22 ```> Do you think it would be possible to write test cases that > could be used as input of both your testing tool and getest > in one way or another? What kind of input is expected by your > testing tool? Our testing tool does not rely on library, but on an expected behavior. That is to say we usually write tests which are simply a root class plus one or more other classes which usually generates some output (eventually take some input if necessary) and we compare the output with the expected output. So if the test using getest generates some predictable output, then we could use them, we would just need to write an Ace file that includes the gobo test library. Manu ```
 Re: [freeelks-devel] built-in or not built-in? From: Eric Bezault - 2005-11-08 16:51:51 ```Emmanuel Stapf [ES] wrote: > I'd say that we should try to reduce the number of built-ins whenever it makes > sense. For example, CHARACTER is a good example where we do not need that many > built-ins. Indeed, it suffices to take the associated code in order to build all > the operations. In general, I would say if it is a very basic operation (e.g. > +,-,*,...) then it should be built-in because what the compiler will generate is > different from what you would write in Eiffel But in case of COMPARABLE, the Eiffel code for `infix "<="' is not what the compiler would generate if it was built-in: a <= b Eiffel: !(b < a) built-in: a <= b But after the C compiler has optimized all that, it's probably as efficient. OK, so let's keep everything in CHARACTER_REF implemented in Eiffel using `code'. -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ```
 Re: [freeelks-devel] built-in or not built-in? From: Eric Bezault - 2005-11-08 16:42:13 ```Emmanuel Stapf [ES] wrote: > Since we use our own testing tool too I don't know exactly what we should do. Do you think it would be possible to write test cases that could be used as input of both your testing tool and getest in one way or another? What kind of input is expected by your testing tool? -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ```
 Re: [freeelks-devel] built-in or not built-in? From: Eric Bezault - 2005-11-07 18:09:44 ```Emmanuel Stapf [ES] wrote: > Since we use our own testing tool too I don't know exactly what we should do. > However, looking at others, I think it is very valuable to have a testing suite. > How much code depending on getest goes to the text of the class? The test cases inherit from TS_TEST_CASE. The features in the test cases are named `test_*' and call `assert_*' features inherited from TS_TEST_CASE. So we could provide a dummy class TS_TEST_CASE with the features `assert_*' (with an implementation not using the Gobo test framework). That way the test cases should be self-contained. Then it would be up to those who want to run the tests to find a way to call all features named `test_*' (or have a creation routine which calls them all, except that the test cases in Gobo are deferred classes), or use getest. That's the only way I could see to reuse the Gobo test cases outside of the getest framework. -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ```
 RE: [freeelks-devel] built-in or not built-in? From: Emmanuel Stapf [ES] - 2005-11-07 16:37:52 ```> for. Should I copy my test cases there? I'm not sure I should > do that because they are dependent on the Gobo getest test framework. Since we use our own testing tool too I don't know exactly what we should do. However, looking at others, I think it is very valuable to have a testing suite. How much code depending on getest goes to the text of the class? If none, then we could save the tests here, then each compiler will use a different framework, but basically the same tests. On the other hand, I'm ok to use `getest'. I just need to figure out a way to include that in our testing. Manu ```
 RE: [freeelks-devel] Features inherited from NUMERIC From: Emmanuel Stapf [ES] - 2005-11-07 16:34:55 ```> That way, the implementation of these features in INTEGER_REF > will not need to explicitly create an INTEGER_REF. All this > type mismatch will be automatically dealt with by the > compiler and the runtime. > Just food for thoughts. I'm not sure which one is better, if we use `like Current' then it avoids actually changing the signature. However there is one case where it actually does not work, this is power which was actually removed from NUMERIC a while ago in our version. However the good thing about the new conformance rule with expanded, is that now it could be `like Current' in NUMERIC and whatever you like in a descendant as long as you conform to NUMERIC. Regards, Manu ```
 RE: [freeelks-devel] built-in or not built-in? From: Emmanuel Stapf [ES] - 2005-11-07 16:31:30 ```> Thinking about it, I'm not sure that reducing the number of > built-ins just because we can find an indirect way to > implement it is a good idea. I'd say that we should try to reduce the number of built-ins whenever it makes sense. For example, CHARACTER is a good example where we do not need that many built-ins. Indeed, it suffices to take the associated code in order to build all the operations. In general, I would say if it is a very basic operation (e.g. +,-,*,...) then it should be built-in because what the compiler will generate is different from what you would write in Eiffel, otherwise when it is a complex operation, then it should certainly be a built-in. Of course the above cannot be applied verbatim and we will always discuss the pros and cons of built-in on a feature basis. Hope this helps. Manu ```
 Re: [freeelks-devel] built-in or not built-in? From: Eric Bezault - 2005-11-07 10:04:03 ```Eric Bezault wrote: > BTW, here is the way I work. In Gobo CVS, if you go to > gobo/library/free_elks, you'll see a cluster 'fake'. These > are classes and features that are needed to compile the > Gobo compiler with itself, but for which I do not support > the FreeELKS version yet. The other clusters contain classes > from FreeELKS already supported by the Gobo compiler. They > are the exact copy of what is in FreeELKS CVS. I only provide > them in GOBO CVS for convenience. I guess you will do the > same at ISE if you want to replace built_in by your own > implementation. Every day I try to remove classes from > the 'fake' cluster and use the FreeELKS version instead. I forgot to mention that that while trying to support new FreeELKS classes in Gobo, I also write test cases for these classes in order to make sure that ISE and Gobo behave the same way. These test cases are in Gobo CVS in gobo/test/free_elks. If you look at the contents of these classes you will see that some features just don't work with ISE and/or with Gobo. Also, I noticed that there is an empty 'test' cluster in FreeELKS CVS. I'm not sure what this is for. Should I copy my test cases there? I'm not sure I should do that because they are dependent on the Gobo getest test framework. -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ```
 Re: [freeelks-devel] built-in or not built-in? From: Eric Bezault - 2005-11-07 09:57:37 ```Colin Paul Adams wrote: >>>>>>"Eric" == Eric Bezault writes: >>>>> > > Eric> consider that `infix "-"' does not need to be built-in > Eric> because we could have written it in terms of `infix "+"' and > Eric> `prefix "-"'. Should we be minimalist like that? I'm not > Eric> convinced and would be tempted to put these comparison and > Eric> numeric features as built-in even if we can implement them > Eric> in terms of others. > > You can always add a post-condition to define the semantics in terms > of `infix "+"' and `prefix "-"'. Yes, that's what is done in the features from COMPARABLE and the feature `infix "<"' in CHARACTER_REF. But that's not what I was talking about. My concern was about the body of these features, not their contract. -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ```
 [freeelks-devel] Features inherited from NUMERIC From: Eric Bezault - 2005-11-07 09:54:17 ```Hello, I noticed that (most) features from BOOLEAN_REF returns a BOOLEAN (not a 'like Current') and likewise for CHARACTER_REF, whereas features from INTEGER_REF (apart from `infix "/"') returns a 'like Current' and not an INTEGER. I understand that the reason for that is that these features come from NUMERIC. Now consider the day where INTEGER will conform to NUMERIC, wouldn't it we better to have: infix "+" (other: like Current): INTEGER instead of: infix "+" (other: like Current): like Current This is not possible now because in feature redeclaration we need conformance of the signature (conversion is not enough), but when we will have INTEGER conforming to NUMERIC this will be possible. That way, the implementation of these features in INTEGER_REF will not need to explicitly create an INTEGER_REF. All this type mismatch will be automatically dealt with by the compiler and the runtime. Just food for thoughts. -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ```
 Re: [freeelks-devel] built-in or not built-in? From: Colin Paul Adams - 2005-11-07 09:50:23 ```>>>>> "Eric" == Eric Bezault writes: Eric> consider that `infix "-"' does not need to be built-in Eric> because we could have written it in terms of `infix "+"' and Eric> `prefix "-"'. Should we be minimalist like that? I'm not Eric> convinced and would be tempted to put these comparison and Eric> numeric features as built-in even if we can implement them Eric> in terms of others. You can always add a post-condition to define the semantics in terms of `infix "+"' and `prefix "-"'. -- Colin Adams Preston Lancashire ```
 Re: [freeelks-devel] built-in or not built-in? From: Eric Bezault - 2005-11-07 09:44:12 ```Eric Bezault wrote: >>> For `infix "<"', the current implementation in CHARACTER_REF makes >>> the implementation recursive in CHARACTER. So it needs to be >>> built-in. However if we change the implementation in CHARACTER_REF to >>> use `code' instead of `item', then the implementation is not >>> recursive anymore and there is no need to declare it as built-in in >>> CHARACTER, apart from for efficiency as above. So, built-in or not >>> built-in? >> >> Again either way is fine with me. >> >> So if we all think that either way is fine, I'd say we should go with the >> non-built-in. > > OK, I'll change `infix "<"' to use `code' instead of > `item' then. Thinking about it, I'm not sure that reducing the number of built-ins just because we can find an indirect way to implement it is a good idea. Here we have the example of the features from COMPARABLE, but in INTEGER we could consider that `infix "-"' does not need to be built-in because we could have written it in terms of `infix "+"' and `prefix "-"'. Should we be minimalist like that? I'm not convinced and would be tempted to put these comparison and numeric features as built-in even if we can implement them in terms of others. -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ```
 Re: [freeelks-devel] built-in or not built-in? From: Eric Bezault - 2005-11-07 09:34:15 ```Emmanuel Stapf [ES] wrote: > Thinking of CHARACTER, I was thinking that I should update > the FreeELKS version with the 5.6 version of CHARACTER_REF as this one is entirely > written in Eiffel without using any C code. I already did that in my working version: for each class I try to use in Gobo, I first try to make it as close as possible to the current ISE version, and then add possibly missing built_ins. So my version of CHARACTER_REF already matches what you have in ISE 5.6/5.7, modulo built-ins. I'll commit it to CVS when I'm done with this class. BTW, here is the way I work. In Gobo CVS, if you go to gobo/library/free_elks, you'll see a cluster 'fake'. These are classes and features that are needed to compile the Gobo compiler with itself, but for which I do not support the FreeELKS version yet. The other clusters contain classes from FreeELKS already supported by the Gobo compiler. They are the exact copy of what is in FreeELKS CVS. I only provide them in GOBO CVS for convenience. I guess you will do the same at ISE if you want to replace built_in by your own implementation. Every day I try to remove classes from the 'fake' cluster and use the FreeELKS version instead. >>For `infix "<"', the current implementation in CHARACTER_REF >>makes the implementation recursive in CHARACTER. So it needs >>to be built-in. However if we change the implementation in >>CHARACTER_REF to use `code' instead of `item', then the >>implementation is not recursive anymore and there is no need >>to declare it as built-in in CHARACTER, apart from for >>efficiency as above. So, built-in or not built-in? > > Again either way is fine with me. > > So if we all think that either way is fine, I'd say we should go with the > non-built-in. OK, I'll change `infix "<"' to use `code' instead of `item' then. -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ```
 RE: [freeelks-devel] built-in or not built-in? From: Emmanuel Stapf [ES] - 2005-11-07 01:02:24 ```> COMPARABLE, and not as a side-effect of declaring them as > built-in (also, at least in the Gobo compiler, it's easier to > optimize them when they are declared as built-in!). So, > built-in or not built-in? I'm fine either way. Thinking of CHARACTER, I was thinking that I should update the FreeELKS version with the 5.6 version of CHARACTER_REF as this one is entirely written in Eiffel without using any C code. Of course it only covers the ASCII characters, not Unicode. > For `infix "<"', the current implementation in CHARACTER_REF > makes the implementation recursive in CHARACTER. So it needs > to be built-in. However if we change the implementation in > CHARACTER_REF to use `code' instead of `item', then the > implementation is not recursive anymore and there is no need > to declare it as built-in in CHARACTER, apart from for > efficiency as above. So, built-in or not built-in? Again either way is fine with me. So if we all think that either way is fine, I'd say we should go with the non-built-in. Manu ```
 RE: [freeelks-devel] Questions about BOOLEAN_REF.prefix "not" and SPECIAL.index_of From: Emmanuel Stapf [ES] - 2005-11-07 00:56:41 ```> The problem with the current implementation and the current > state of ISE Eiffel is that we cannot have SPECIAL [MY_TYPE] > if MY_TYPE does not conform nor convert to ANY. Or am I > mistaken (I don't remember what the rules for generic > constraints are in the current ISE Eiffel)? Using '=' (at I'd say this scenario never arises in practice, because the only way to not conform and not convert is to have an expanded type. And when you do that, you have to add a `to_reference' to make things work. Moreover our next release will be following the new rules for the expanded, thus we would always conform to ANY. > least as default while waiting for an implementation which > passes an agent for the comparison criterion as argument) > does not seem to have this problem. I'm fine adding this to SPECIAL now. Should we add `xxx_with_comparer' or `xxx_with_equality_tester' for each routine `xxx' of SPECIAL using `=' or `is_equal'? Regards, Manu ```
 Re: [freeelks-devel] Questions about BOOLEAN_REF.prefix "not" and SPECIAL.index_of From: Eric Bezault - 2005-11-06 20:33:31 ```Emmanuel Stapf [ES] wrote: >>* Why does SPECIAL.index_of call `equal' whereas the other >> features in this class use '='? > > Don't remember. This was done a long time ago. The problem with the current implementation and the current state of ISE Eiffel is that we cannot have SPECIAL [MY_TYPE] if MY_TYPE does not conform nor convert to ANY. Or am I mistaken (I don't remember what the rules for generic constraints are in the current ISE Eiffel)? Using '=' (at least as default while waiting for an implementation which passes an agent for the comparison criterion as argument) does not seem to have this problem. -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ```
 [freeelks-devel] built-in or not built-in? From: Eric Bezault - 2005-11-06 17:52:15 ```Hello, I'm currently working on class CHARACTER and I put the features `infix "<"', `infix ">"', `infix "<="' and `infix ">="' as built-in. Now I wonder whether this is a good idea or not. Indeed, for the last three there is no real need for them to be built-in apart from for efficiency (their implementation if not recursive). I guess that it should be up to the compiler to optimize the features coming from COMPARABLE, and not as a side-effect of declaring them as built-in (also, at least in the Gobo compiler, it's easier to optimize them when they are declared as built-in!). So, built-in or not built-in? For `infix "<"', the current implementation in CHARACTER_REF makes the implementation recursive in CHARACTER. So it needs to be built-in. However if we change the implementation in CHARACTER_REF to use `code' instead of `item', then the implementation is not recursive anymore and there is no need to declare it as built-in in CHARACTER, apart from for efficiency as above. So, built-in or not built-in? -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ```
 Re: [freeelks-devel] Questions about BOOLEAN_REF.prefix "not" and SPECIAL.index_of From: Eric Bezault - 2005-11-06 16:23:22 ```Emmanuel Stapf [ES] wrote: >>and 'equal'. But there are many more comparison criteria that >>could be useful in applications. > > > That what I meant by `comparison object' Yes, that's what I understood you meant as well: i.e. an agent of some sort passed as argument. -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ```
 RE: [freeelks-devel] Questions about BOOLEAN_REF.prefix "not" and SPECIAL.index_of From: Emmanuel Stapf [ES] - 2005-11-06 15:58:51 ```> and 'equal'. But there are many more comparison criteria that > could be useful in applications. That what I meant by `comparison object', I didn't mean the `object_comparison' stuff from EiffelBase. Manu ```
 Re: [freeelks-devel] Questions about BOOLEAN_REF.prefix "not" and SPECIAL.index_of From: Eric Bezault - 2005-11-06 15:34:58 ```Emmanuel Stapf [ES] wrote: > Don't remember. This was done a long time ago. Ideally we want a comparison object > to be given to all routines of SPECIAL since it is hard to have an additional > attribute in SPECIAL. And an extra attribute like in the container classes of EiffelBase is not a complete solution. It gives the choice between only to comparison criteria: '=' and 'equal'. But there are many more comparison criteria that could be useful in applications. -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ```
 RE: [freeelks-devel] Questions about BOOLEAN_REF.prefix "not" and SPECIAL.index_of From: Emmanuel Stapf [ES] - 2005-11-06 14:45:34 ```> * Why does BOOLEAN_REF.prefix "not" returns a 'like Current' > whereas all other similar features in this class return a > BOOLEAN? If I recall correctly, 10 years ago most routines were returning `like Current'. I believed we change most of them, but forgot some. > * Why does SPECIAL.index_of call `equal' whereas the other > features in this class use '='? Don't remember. This was done a long time ago. Ideally we want a comparison object to be given to all routines of SPECIAL since it is hard to have an additional attribute in SPECIAL. Regards, Manu ```

Showing results of 41

1 2 > >> (Page 1 of 2)