gobo-eiffel-develop

Re: [gobo-eiffel-develop] Binary search tree

[Daniel T. <dan...@gm...>]

Eric Bezault wrote:
> Daniel Tuser wrote:
>> Just to make it clear, the binary search tree implementation is still 
>> not finished. There is still at least one bug and I didn't test it 
>> extensively.
>
> In that case, I suggest that I release a new version of Gobo
> first. Then I will have more time to review your code and see
> how to best integrate it with the existing classes.
>
Yes. We have enough time :-).

I just found a problem related to gec. I know that you try to make gec 
compatible to the compiler of Eiffel Software. The following class works 
with EiffelStudio but does not compile with gec. I didn't have time to 
have a closer look at the inheritance problem, so I just show you the 
problem as you are preparing a release. You certainly need the binary 
search tree classes from the previous post to compile the test.

class TEST_1

create

    make

feature {NONE}

    make is
           -- Creation procedure.
       local
          l_comparator: DS_COMPARABLE_COMPARATOR [STRING]
       do
          create l_comparator.make
          create tree.make (l_comparator)
       end

    tree: DS_AVL_TREE_SET [STRING]

end

Re: [gobo-eiffel-develop] Binary search tree

[Eric B. <er...@go...>]

Daniel Tuser wrote:
> I just found a problem related to gec. I know that you try to make gec 
> compatible to the compiler of Eiffel Software. The following class works 
> with EiffelStudio but does not compile with gec. I didn't have time to 
> have a closer look at the inheritance problem, so I just show you the 
> problem as you are preparing a release. You certainly need the binary 
> search tree classes from the previous post to compile the test.
> 
> class TEST_1
> 
> create
> 
>    make
> 
> feature {NONE}
> 
>    make is
>           -- Creation procedure.
>       local
>          l_comparator: DS_COMPARABLE_COMPARATOR [STRING]
>       do
>          create l_comparator.make
>          create tree.make (l_comparator)
>       end
> 
>    tree: DS_AVL_TREE_SET [STRING]
> 
> end

I tried to compiled it with the very latest version of gec
and it compiled. So I guess the problem has been fixed since
you last tried it.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Binary search tree

[Daniel T. <dan...@gm...>]

Eric Bezault wrote:
> I tried to compiled it with the very latest version of gec
> and it compiled. So I guess the problem has been fixed since
> you last tried it.
>

I gave you the wrong class, with that class. With that class and the 
previous version of the binary search tree implementation you get the 
compile error with gec and not problem with the compiler of Eiffel 
Software. The reason for that problem seams to be a different 
interpretation of anchored types. My intuition tells me that gec is 
correct, but I didn't check it in the ECMA specification.
test.e is the class that shows the difference and there is a newer 
version of the binary search tree, that does not have the 
incompatibility, but there is still at least one bug.

Re: [gobo-eiffel-develop] Binary search tree

[Eric B. <er...@go...>]

Daniel Tuser wrote:
> Eric Bezault wrote:
>> I tried to compiled it with the very latest version of gec
>> and it compiled. So I guess the problem has been fixed since
>> you last tried it.
>>
> 
> I gave you the wrong class, with that class. With that class and the 
> previous version of the binary search tree implementation you get the 
> compile error with gec and not problem with the compiler of Eiffel 
> Software. The reason for that problem seams to be a different 
> interpretation of anchored types. My intuition tells me that gec is 
> correct, but I didn't check it in the ECMA specification.

I guess you were referring to these errors:

----
[VJAR] class DS_RED_BLACK_TREE (DS_COMMON_BINARY_SEARCH_TREE,285,18): 
the source of the assignment (of type 'DS_BINARY_SEARCH_TREE_NODE 
[INTEGER, INTEGER]') does not conform nor convert to its target entity 
(of type 'DS_RED_BLACK_TREE_NODE [INTEGER, INTEGER]').
----
[VJAR] class DS_AVL_TREE (DS_COMMON_BINARY_SEARCH_TREE,285,18): the 
source of the assignment (of type 'DS_BINARY_SEARCH_TREE_NODE [INTEGER, 
INTEGER]') does not conform nor convert to its target entity (of type 
'DS_AVL_TREE_NODE [INTEGER, INTEGER]').
----
[VJAR] class DS_BINARY_SEARCH_TREE_SET 
(DS_COMMON_BINARY_SEARCH_TREE,285,18): the source of the assignment (of 
type 'DS_COMMON_BINARY_SEARCH_TREE_NODE [INTEGER, INTEGER]') does not 
conform nor convert to its target entity (of type 
'DS_BINARY_SEARCH_TREE_SET_NODE [INTEGER]').
----
[VJAR] class DS_RED_BLACK_TREE_SET 
(DS_COMMON_BINARY_SEARCH_TREE,285,18): the source of the assignment (of 
type 'DS_COMMON_BINARY_SEARCH_TREE_NODE [INTEGER, INTEGER]') does not 
conform nor convert to its target entity (of type 
'DS_RED_BLACK_TREE_SET_NODE [INTEGER]').
----
[VJAR] class DS_AVL_TREE_SET (DS_COMMON_BINARY_SEARCH_TREE,285,18): the 
source of the assignment (of type 'DS_COMMON_BINARY_SEARCH_TREE_NODE 
[INTEGER, INTEGER]') does not conform nor convert to its target entity 
(of type 'DS_AVL_TREE_SET_NODE [INTEGER]').
----

These are what I call flat Degree 3 errors. I think that gec is
indeed correct in reporting these errors because it is part of
ECMA. As for the compatibility with ISE EiffelStudio, I think that
these errors will also be reported if you add the option
"full_class_checking" in your ECF file.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Binary search tree

[Eric B. <er...@go...>]

Daniel Tuser wrote:
> Eric Bezault wrote:
>> These are what I call flat Degree 3 errors. I think that gec is
>> indeed correct in reporting these errors because it is part of
>> ECMA. As for the compatibility with ISE EiffelStudio, I think that
>> these errors will also be reported if you add the option
>> "full_class_checking" in your ECF file.
>>
> That's interesting. I am a little bit surprised that those errors are 
> not reported by default.

I guess EiffelStudio will report them by default at some point,
after a transitional period.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Binary search tree

[Daniel T. <dan...@gm...>]

The left-leaning red-black tree implementation is finished. 
Unfortunately it is very slow compared to the other binary search tree 
variants.

Re: [gobo-eiffel-develop] Binary search tree

[Daniel T. <dan...@gm...>]

I made several changes in the binary search tree implementation. All the 
proposed modifications are included with some minor exceptions. One 
example is that I don't use the l_* prefix for all locals, e.g. if there 
is `i: INTEGER' it is still present and not `l_i: INTEGER'. Name clashes 
should not be a problem in this case.
In class DS_BINARY_SEARCH_TREE there is a short `Todo' comment. I know, 
that it is against all conventions. It is just there to show, that it is 
not finished and not in a stable state.
I did not have enough time so far to modify DS_AVL_TREE and 
DS_RED_BLACK_TREE. That is going to be very time consuming to split the 
features.

Regards,
Daniel

Re: [gobo-eiffel-develop] Binary search tree

[Daniel T. <dan...@gm...>]

Daniel Tuser wrote:
> I don't use the l_* prefix for all locals, e.g. if there is `i: 
> INTEGER' it is still present and not `l_i: INTEGER'
I just saw that you do that as well.

Re: [gobo-eiffel-develop] Binary search tree

[Daniel T. <dan...@gm...>]

Eric Bezault wrote:
> Daniel Tuser wrote:
>> I just found a problem related to gec. I know that you try to make 
>> gec compatible to the compiler of Eiffel Software. The following 
>> class works with EiffelStudio but does not compile with gec. I didn't 
>> have time to have a closer look at the inheritance problem, so I just 
>> show you the problem as you are preparing a release. You certainly 
>> need the binary search tree classes from the previous post to compile 
>> the test.
>>
>> class TEST_1
>> ...
>
> I tried to compiled it with the very latest version of gec
> and it compiled. So I guess the problem has been fixed since
> you last tried it.
I used the svn version and made a bootstrap to get the latest version of 
gec. But maybe I somehow mixed two variants of the binary search tree 
implementation. I tried to avoid that, but probably I missed something. 
Maybe I can reproduce it, but it is not very likely.