gobo-eiffel-develop — Development discussions

[gobo-eiffel-develop] New release of Gobo

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

I plan to build and test a new release of Gobo by the end
of the week, so that it can be included in the forthcoming
release of EiffelStudio. If you need to commit code in
SVN, can you let me know first so that we can decide whether
it should go it this release or if it can wait until the
next release? Thanks.

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

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

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

The two classes DS_BILINEAR_TABLE an DS_BILINEAR_SET are now integrated 
in the binary search tree implementation. They would be useful in my 
opinion. For the case that you do not want them, it is not hard to 
remove them from the implementation.
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.

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

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

Colin Adams wrote:
> Eric will have to answer your other points.

I'll try to have a look at it today. If I don't have time
to do so, then it will have to wait until next Tuesday as
I will be away from my computer during the coming days.

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

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

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

Colin Adams wrote:
> On 01/05/2008, Daniel Tuser <dan...@gm...> wrote:
>
>   
>>  Feedback is still welcome. Colin, are the features still too long?
>>     
>
> They are fine now.
>
> I was a bit surprised to see you have been working on some of these
> classes for nine years now. Of course they do require some careful
> thought, but I would think you might be a little quicker than that.
> :-)
>
> (Copyright 2000 - 2008 - change to Copyright 2008, I would think. )
>
>   

Ok :-)

Re: [gobo-eiffel-develop] Getting rid of select

[Colin A. <col...@go...>]

I don't remember, but I suspect that must have been the reason.

2008/5/1 Eric Bezault <er...@go...>:
> Hi Colin,
>
>  I can see that in classes XM_XSLT_GROUP_NODE_ITERATOR and
>  XM_XSLT_SORTED_GROUP_NODE_ITERATOR you are using 'select'.
>  Apart from UC_STRING, these are the only two occurrences of
>  'select' in Gobo. Right from the start I tried to avoid using
>  'select' because it was not working correctly when compiled
>  with SmartEiffel. OK, we don't care about SmartEiffel anymore,
>  but now there is a push from ECMA to get rid of 'select'.
>  So I was wondering why you used 'select' in these classes.
>  Was it just because the features involved were attributes
>  and one cannot undefine an attribute (to have it merged with
>  the version from the other inheritance branch)? If this is
>  the reason, then there is a way to merge two attributes coming
>  from two different parents. You just have to redefine this
>  attribute in both inheritance branches:
>
>  class C
>  inherit
>      A
>         redefine
>            attr
>         end
>      B
>         redefine
>            attr
>         end
>  feature
>      attr: TYPE
>           -- ...
>  end
>
>  --
>  Eric Bezault
>  mailto:er...@go...
>  http://www.gobosoft.com
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  gobo-eiffel-develop mailing list
>  gob...@li...
>  https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>

[gobo-eiffel-develop] Getting rid of select

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

Hi Colin,

I can see that in classes XM_XSLT_GROUP_NODE_ITERATOR and
XM_XSLT_SORTED_GROUP_NODE_ITERATOR you are using 'select'.
Apart from UC_STRING, these are the only two occurrences of
'select' in Gobo. Right from the start I tried to avoid using
'select' because it was not working correctly when compiled
with SmartEiffel. OK, we don't care about SmartEiffel anymore,
but now there is a push from ECMA to get rid of 'select'.
So I was wondering why you used 'select' in these classes.
Was it just because the features involved were attributes
and one cannot undefine an attribute (to have it merged with
the version from the other inheritance branch)? If this is
the reason, then there is a way to merge two attributes coming
from two different parents. You just have to redefine this
attribute in both inheritance branches:

class C
inherit
     A
        redefine
           attr
        end
     B
        redefine
           attr
        end
feature
     attr: TYPE
          -- ...
end

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

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

[Colin A. <col...@go...>]

On 01/05/2008, Daniel Tuser <dan...@gm...> wrote:

>  Feedback is still welcome. Colin, are the features still too long?

They are fine now.

I was a bit surprised to see you have been working on some of these
classes for nine years now. Of course they do require some careful
thought, but I would think you might be a little quicker than that.
:-)

(Copyright 2000 - 2008 - change to Copyright 2008, I would think. )


Eric will have to answer your other points.

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

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

The test cases for binary search trees are now written. The attachment 
also contains some modifications.
I've got a proposals for the class hierarchy of the DS_* classes. I 
would like to have DS_BILINEAR_TABLE and DS_BILINEAR_SET. And 
DS_SPARSE_TABLE inherits DS_BILINEAR_TABLE and DS_SPARSE_SET inherits 
DS_BILINIEAR_SET. In the attachment the binary search tree 
implementation already uses DS_BILINEAR_TABLE. In my opinion it makes 
sense to have a common ancestor for hash table and binary search trees 
that has both the table and cursor features.
I am working on a set implementation based on binary search trees. That 
is why I would like to have DS_BILINEAR_SET as well. I am trying to make 
it very much like hash table and hash set. The goal is actually to get 
an abstraction of binary search tree that can be reused for the set 
implementation.
Feedback is still welcome. Colin, are the features still too long?

Re: [gobo-eiffel-develop] Code to create a UC_UTF8_STRING from STRING_GENERAL

[Colin A. <col...@go...>]

On 21/04/2008, Eric Bezault <er...@go...> wrote:

>  After looking at class UC_STRING, I'm wondering whether we should
>  just adapt the routines `make_from_string' and `make_from_substring'
>  so that we can pass a STRING_GENERAL. Perhaps we will have to
>  rename the version of `make_from_string' inherited from STRING.
>  Or add `make_from_string_general', `make_from_substring_general',
>  make `make_from_substring' obsolete (make it call
>  `make_from_substring_general') and modify `make_from_string'
>  to call `make_from_string_general'. I'm not sure what the best
>  naming convention is.

I think the last suggestion (adding make_from_string_general and
changing make_from_string to call make_from_string_general, etc.) is
best.

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

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

[Colin A. <col...@go...>]

2008/4/24 Daniel Tuser <dan...@gm...>:
>  I know that the indexing clause does not conform to the Gobo styling
> standards so far. And the class name should be in the same line as the class
> keyword. Those are the two non-conforming things I know. Did you find more?

Also there were several routines without a header comment.

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

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

Daniel Tuser wrote:
> In the Gobo documentation "author" is used in the indexing clause, but 
> most Gobo classes do not have it. So I won't use it.

No need for "author".

> I have several multi-line "description"s in the indexing clause that are 
> enclosed in "[ ]". Should I use % as seen e.g. in DS_SPARSE_TABLE?

You can use "[ ]".

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

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

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

Colin Adams wrote:
> There area a load of empty feature clauses and a dummy invariant in at
> least one
> class.
>   
Done.
> Then I dislike the absence of a blank line after create and inherit.
>   
Done.
> Also I dislike seeing local variables with names that might class with
> attributes (and so forcing unnecessary renames in descendants).
> I personally now write all argument names as a_*, and all local names
> as either a single chanaracter or l_*. I am converting my existing
> code on a piecemeal basis.
>   
I like that suggestion and will do it like this.


Colin Adams wrote:
> On 24/04/2008, Daniel Tuser <dan...@gm...> wrote:
>
>
>   
>>> Some of the routines are too long to read on the screen.
>>>       
>> I don't like that as well. Those are the algorithms that could also be
>> implemented as recursive features. I will see what I can do to improve that.
>> But I will not make them recursive.
>> A splitting into more features is also not easy as some features would
>> require about 4 or 5 arguments. I was already working on that but stopped
>> because the resulting code was not more readable. It could be done using
>> attributes. But it would take some time.
>>  Do you think that has to be changed?
>>     
>
> I would say yes, provided there is no significant performance impact.
>
> I don't think passing 5 arguments is a reason not to do it, as the
> routines receiving 5 arguments are all secret.
>   
5 arguments are no reason, I share that point of view. At the end it has 
to be readable and understandable. I am just not sure if that is 
achieved by splitting the features. But I will certainly try it.

In the Gobo documentation "author" is used in the indexing clause, but 
most Gobo classes do not have it. So I won't use it.

I have several multi-line "description"s in the indexing clause that are 
enclosed in "[ ]". Should I use % as seen e.g. in DS_SPARSE_TABLE?

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

[Colin A. <col...@go...>]

On 24/04/2008, Daniel Tuser <dan...@gm...> wrote:
> Colin Adams wrote:

>  I know that the indexing clause does not conform to the Gobo styling
> standards so far. And the class name should be in the same line as the class
> keyword. Those are the two non-conforming things I know. Did you find more?

There area a load of empty feature clauses and a dummy invariant in at
least one
class.

Then I dislike the absence of a blank line after create and inherit.

Also I dislike seeing local variables with names that might class with
attributes (and so forcing unnecessary renames in descendants).
I personally now write all argument names as a_*, and all local names
as either a single chanaracter or l_*. I am converting my existing
code on a piecemeal basis.

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

[Colin A. <col...@go...>]

On 24/04/2008, Daniel Tuser <dan...@gm...> wrote:


> > Some of the routines are too long to read on the screen.
> >
> >
>  I don't like that as well. Those are the algorithms that could also be
> implemented as recursive features. I will see what I can do to improve that.
> But I will not make them recursive.
>  A splitting into more features is also not easy as some features would
> require about 4 or 5 arguments. I was already working on that but stopped
> because the resulting code was not more readable. It could be done using
> attributes. But it would take some time.

>  Do you think that has to be changed?

I would say yes, provided there is no significant performance impact.

I don't think passing 5 arguments is a reason not to do it, as the
routines receiving 5 arguments are all secret.

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

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

Colin Adams wrote:
> You would also need to write some general documentation in the gobodoc format.
>   
Ok.
> I've taken a fairly casual look. Generally it looks good.
>
> The one thing that does stand out is that it does not conform to the
> Gobo styling standards.
>   
I know that the indexing clause does not conform to the Gobo styling 
standards so far. And the class name should be in the same line as the 
class keyword. Those are the two non-conforming things I know. Did you 
find more?
> I'm rather puzzled by this comment:
>
> " Direct instances should not be used in practice as the trees may
> become unbalanced."
>
> The class name (DS_BINARY_SEARCH_TREE) does not dictate balanced
> trees. Nor does there seem to be anything at first glance that
> requires the tree to be balanced.
>
> So perhaps you mean to say that creating direct instances is not
> advisable. (otherwise you could simply mark the class as deferred).
>   
You are right. "Not advisable" is much better.
> In DS_BINARY_SEARCH_TREE_NODE, the assertion tags on the creation
> procedures don't read well to me:
>
> 			reuse_if_no_parent: parent = Void
> 			reuse_if_no_left_child: left_child = Void
> 			reuse_if_no_right_child: right_child = Void
>
> I don't understand what is going on here. Make is not used in the
> class except as a creation procedure, when the assertions are
> trivially True (nor do it seem to be used in the descendants).
>   
This kind of code is actually the reason why I have to check the whole 
code again. The design was not detailed when I started, as I just did 
not know what was needed such that also Red-Black- and AVL-Trees could 
reuse as much code as possible. So at certain positions it is not yet 
good enough.
> Some of the routines are too long to read on the screen.
>   
I don't like that as well. Those are the algorithms that could also be 
implemented as recursive features. I will see what I can do to improve 
that. But I will not make them recursive.
A splitting into more features is also not easy as some features would 
require about 4 or 5 arguments. I was already working on that but 
stopped because the resulting code was not more readable. It could be 
done using attributes. But it would take some time.
Do you think that has to be changed?

Another minor improvement I am going to use is the "Performance: O(...)" 
comment as it is present in some Gobo classes.

Thanks for your comment.

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

[Colin A. <col...@go...>]

On 22/04/2008, Daniel Tuser <dan...@gm...> wrote:
> Hi all
>  I would like to know whether the Gobo community and developers are
> interested in a binary search tree implementation. Recently I needed it and

Personally, I've never had the need for one. But I think it would be a
useful addition to the structure library.

>  My implementation inherits from DS_TABLE and DS_BILINEAR. The
> implementation is NOT finished, I have to revisit every single line of code
> including the comments. If you are interested I would be happy to get some
> general feedback, such that I could take it into account when revisiting the
> code. Test cases are missing so far.

You would also need to write some general documentation in the gobodoc format.

I've taken a fairly casual look. Generally it looks good.

The one thing that does stand out is that it does not conform to the
Gobo styling standards.

I'm rather puzzled by this comment:

" Direct instances should not be used in practice as the trees may
become unbalanced."

The class name (DS_BINARY_SEARCH_TREE) does not dictate balanced
trees. Nor does there seem to be anything at first glance that
requires the tree to be balanced.

So perhaps you mean to say that creating direct instances is not
advisable. (otherwise you could simply mark the class as deferred).

In DS_BINARY_SEARCH_TREE_NODE, the assertion tags on the creation
procedures don't read well to me:

			reuse_if_no_parent: parent = Void
			reuse_if_no_left_child: left_child = Void
			reuse_if_no_right_child: right_child = Void

I don't understand what is going on here. Make is not used in the
class except as a creation procedure, when the assertions are
trivially True (nor do it seem to be used in the descendants).

Some of the routines are too long to read on the screen.

[gobo-eiffel-develop] Binary search tree

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

Hi all
I would like to know whether the Gobo community and developers are 
interested in a binary search tree implementation. Recently I needed it 
and was not happy with BINARY_SEARCH_TREE from ISE, so I had to build a 
new one.
My implementation inherits from DS_TABLE and DS_BILINEAR. The 
implementation is NOT finished, I have to revisit every single line of 
code including the comments. If you are interested I would be happy to 
get some general feedback, such that I could take it into account when 
revisiting the code. Test cases are missing so far.

Regards
Daniel Tuser

Re: [gobo-eiffel-develop] Code to create a UC_UTF8_STRING from STRING_GENERAL

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

Colin Adams wrote:
> On 21/04/2008, Eric Bezault <er...@go...> wrote:
>>  In fact having it as creation procedure will allow us to avoid
>>  having to create the intermediary object `l_bytes'.
>>
>>  After looking at class UC_STRING, I'm wondering whether we should
>>  just adapt the routines `make_from_string' and `make_from_substring'
>>  so that we can pass a STRING_GENERAL. Perhaps we will have to
> 
> We could do that, as we have the is_string_8 query to choose between
> the current implementation and the STRING_32 one.

We don't need `is_string_8'. We just need to use STRING_GENERAL.code.

>>  rename the version of `make_from_string' inherited from STRING.
>>  Or add `make_from_string_general', `make_from_substring_general',
>>  make `make_from_substring' obsolete (make it call
>>  `make_from_substring_general') and modify `make_from_string'
>>  to call `make_from_string_general'. I'm not sure what the best
>>  naming convention is.
> 
> I don't think we need to rename anything.

We do: `make_from_string' is inherited from STRING with an
argument of type STRING. We cannot redefine it to accept
an argument of type STRING_GENERAL.

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

Re: [gobo-eiffel-develop] Code to create a UC_UTF8_STRING from STRING_GENERAL

[Colin A. <col...@go...>]

On 21/04/2008, Eric Bezault <er...@go...> wrote:
>  In fact having it as creation procedure will allow us to avoid
>  having to create the intermediary object `l_bytes'.
>
>  After looking at class UC_STRING, I'm wondering whether we should
>  just adapt the routines `make_from_string' and `make_from_substring'
>  so that we can pass a STRING_GENERAL. Perhaps we will have to

We could do that, as we have the is_string_8 query to choose between
the current implementation and the STRING_32 one.

>  rename the version of `make_from_string' inherited from STRING.
>  Or add `make_from_string_general', `make_from_substring_general',
>  make `make_from_substring' obsolete (make it call
>  `make_from_substring_general') and modify `make_from_string'
>  to call `make_from_string_general'. I'm not sure what the best
>  naming convention is.

I don't think we need to rename anything.

Re: [gobo-eiffel-develop] Time library and XSLT formatting

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

Colin Adams wrote:
> I just tried it and it passes (ISE 5.7 on Windows, after doing an svn update).

Hmm, this is strange: I ran the test again (no need to run svn update
as I was already up-to-date) and now the test succeeds. Weird!

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

Re: [gobo-eiffel-develop] Time library and XSLT formatting

[Colin A. <col...@go...>]

I just tried it and it passes (ISE 5.7 on Windows, after doing an svn update).

On 22/04/2008, Eric Bezault <er...@go...> wrote:

>  I get this assertion violation when compiling the xslt
>  tests with ISE 5.7 with assertions on.
>
>  Test Summary for xslt
>
>  # Passed:     83 tests
>  # Failed:     0 test
>  # ABORTED:    1 test
>  # Total:      84 tests (453 assertions)
>
>  Test Results:
>  ABORT:  [XM_XSLT_TEST_BOOKS.test_transform] Eiffel exception
>  -------------------------------------------------------------------------------
>  Class / Object      Routine                Nature of exception
>   Effect
>  -------------------------------------------------------------------------------
>  ST_XSD_DATE_TIME_FORMAT
>                      zoned_date_time_to_string @9
>                                             valid_zoned_date_time_string:
>  <0000000003EAFE88>                         Postcondition violated.
>   Fail
>  -------------------------------------------------------------------------------
>  ST_XSD_DATE_TIME_FORMAT
>                      zoned_date_time_to_string @4
>  <0000000003EAFE88>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XPATH_DATE_TIME_VALUE
>                      string_value @4
>  <0000000003EAF488>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XPATH_DATE_TIME_VALUE
>                      convert_to_type @6
>  <0000000003EAF488>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_CONTENT_CONSTRUCTOR
>                      evaluate_item @15
>  <0000000003C919F0>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_COMPILED_VALUE_OF
>                      expand_children @8
>  <0000000003C91980>  (From XM_XSLT_TEXT_CONSTRUCTOR)
>                                             Routine failure.
>    Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_COMPILED_VALUE_OF
>                      evaluate_item @8
>  <0000000003C91980>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_COMPILED_VALUE_OF
>                      create_iterator @5
>  <0000000003C91980>  (From XM_XSLT_TEXT_CONSTRUCTOR)
>                                             Routine failure.
>    Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_COMPILED_VALUE_OF
>                      create_node_iterator @5
>  <0000000003C91980>  (From XM_XSLT_INSTRUCTION)
>                                             Routine failure.
>    Fail
>  -------------------------------------------------------------------------------
>  XM_XPATH_BLOCK_NODE_ITERATOR
>                      forth @18
>  <0000000003EAE928>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_CONTENT_CONSTRUCTOR
>                      evaluate_sequence @48
>  <0000000003C916F8>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_CONTENT_CONSTRUCTOR
>                      evaluate_item @24
>  <0000000003C916F8>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_COMPILED_COMMENT
>                      expand_children @8
>  <0000000003C91690>  (From XM_XSLT_TEXT_CONSTRUCTOR)
>                                             Routine failure.
>    Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_COMPILED_COMMENT
>                      generate_tail_call @6
>  <0000000003C91690>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_BLOCK       generate_tail_call @13
>  <0000000003C915F0>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_BLOCK       generate_events @8
>  <0000000003C915F0>  (From XM_XSLT_INSTRUCTION)
>                                             Routine failure.
>    Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_FIXED_ELEMENT
>                      generate_tail_call @26
>  <0000000003C91570>  (From XM_XSLT_ELEMENT_CONSTRUCTOR)
>                                             Routine failure.
>    Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_COMPILED_TEMPLATE
>                      expand @6
>  <0000000003C91540>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_COMPILED_TEMPLATE
>                      generate_tail_call @8
>  <0000000003C91540>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_TRANSFORMER apply_templates_2 @25
>  <0000000003D0E0B0>  (From XM_XSLT_TEMPLATE_ROUTINES)
>                                             Routine failure.
>    Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_TRANSFORMER apply_templates @33
>  <0000000003D0E0B0>  (From XM_XSLT_TEMPLATE_ROUTINES)
>                                             Routine failure.
>    Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_TRANSFORMER perform_transformation @10
>  <0000000003D0E0B0>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_TRANSFORMER transform_document @24
>  <0000000003D0E0B0>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_TRANSFORMER transform @71
>  <0000000003D0E0B0>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_TEST_BOOKS  test_transform @17
>  <0000000004A41D18>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  PROCEDURE           fast_call
>  <0000000004A41D88>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  PROCEDURE           call @3
>  <0000000004A41D88>                         Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_TEST_BOOKS  execute_without_rescue @4
>  <0000000004A41D18>  (From TS_TEST_CASE)    Routine failure.
>   Fail
>  -------------------------------------------------------------------------------
>  XM_XSLT_TEST_BOOKS  execute_with_rescue @3
>  <0000000004A41D18>  (From TS_TEST_CASE)    Routine failure.
>   Retry
>  ===============================================================================
>
>
>  --
>  Eric Bezault
>  mailto:er...@go...
>  http://www.gobosoft.com
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  gobo-eiffel-develop mailing list
>  gob...@li...
>  https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>

Re: [gobo-eiffel-develop] Time library and XSLT formatting

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

Colin Paul Adams wrote:
>>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:
> 
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>     Eric> formatting classes in 'date' library.  I guess moving it to
>     Eric> string/date should be OK. I would hope that the library
>     Eric> 'math' does not depend on 'string'.
> 
>     Colin> It's library.xace shows no indication of a dependency. More
>     Colin> significantly, the system.xace for it's tests does not
>     Colin> include the string/library.xace, and decisively, nor does
>     Colin> the generated ge.xace in that test cluster.
> 
>     Colin> So I will go ahead with this move.
> 
> Done, and committed.

I get this assertion violation when compiling the xslt
tests with ISE 5.7 with assertions on.

Test Summary for xslt

# Passed:     83 tests
# Failed:     0 test
# ABORTED:    1 test
# Total:      84 tests (453 assertions)

Test Results:
ABORT:  [XM_XSLT_TEST_BOOKS.test_transform] Eiffel exception
-------------------------------------------------------------------------------
Class / Object      Routine                Nature of exception 
  Effect
-------------------------------------------------------------------------------
ST_XSD_DATE_TIME_FORMAT
                     zoned_date_time_to_string @9
                                            valid_zoned_date_time_string:
<0000000003EAFE88>                         Postcondition violated. 
  Fail
-------------------------------------------------------------------------------
ST_XSD_DATE_TIME_FORMAT
                     zoned_date_time_to_string @4
<0000000003EAFE88>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XPATH_DATE_TIME_VALUE
                     string_value @4
<0000000003EAF488>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XPATH_DATE_TIME_VALUE
                     convert_to_type @6
<0000000003EAF488>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XSLT_CONTENT_CONSTRUCTOR
                     evaluate_item @15
<0000000003C919F0>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XSLT_COMPILED_VALUE_OF
                     expand_children @8
<0000000003C91980>  (From XM_XSLT_TEXT_CONSTRUCTOR)
                                            Routine failure. 
   Fail
-------------------------------------------------------------------------------
XM_XSLT_COMPILED_VALUE_OF
                     evaluate_item @8
<0000000003C91980>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XSLT_COMPILED_VALUE_OF
                     create_iterator @5
<0000000003C91980>  (From XM_XSLT_TEXT_CONSTRUCTOR)
                                            Routine failure. 
   Fail
-------------------------------------------------------------------------------
XM_XSLT_COMPILED_VALUE_OF
                     create_node_iterator @5
<0000000003C91980>  (From XM_XSLT_INSTRUCTION)
                                            Routine failure. 
   Fail
-------------------------------------------------------------------------------
XM_XPATH_BLOCK_NODE_ITERATOR
                     forth @18
<0000000003EAE928>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XSLT_CONTENT_CONSTRUCTOR
                     evaluate_sequence @48
<0000000003C916F8>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XSLT_CONTENT_CONSTRUCTOR
                     evaluate_item @24
<0000000003C916F8>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XSLT_COMPILED_COMMENT
                     expand_children @8
<0000000003C91690>  (From XM_XSLT_TEXT_CONSTRUCTOR)
                                            Routine failure. 
   Fail
-------------------------------------------------------------------------------
XM_XSLT_COMPILED_COMMENT
                     generate_tail_call @6
<0000000003C91690>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XSLT_BLOCK       generate_tail_call @13
<0000000003C915F0>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XSLT_BLOCK       generate_events @8
<0000000003C915F0>  (From XM_XSLT_INSTRUCTION)
                                            Routine failure. 
   Fail
-------------------------------------------------------------------------------
XM_XSLT_FIXED_ELEMENT
                     generate_tail_call @26
<0000000003C91570>  (From XM_XSLT_ELEMENT_CONSTRUCTOR)
                                            Routine failure. 
   Fail
-------------------------------------------------------------------------------
XM_XSLT_COMPILED_TEMPLATE
                     expand @6
<0000000003C91540>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XSLT_COMPILED_TEMPLATE
                     generate_tail_call @8
<0000000003C91540>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XSLT_TRANSFORMER apply_templates_2 @25
<0000000003D0E0B0>  (From XM_XSLT_TEMPLATE_ROUTINES)
                                            Routine failure. 
   Fail
-------------------------------------------------------------------------------
XM_XSLT_TRANSFORMER apply_templates @33
<0000000003D0E0B0>  (From XM_XSLT_TEMPLATE_ROUTINES)
                                            Routine failure. 
   Fail
-------------------------------------------------------------------------------
XM_XSLT_TRANSFORMER perform_transformation @10
<0000000003D0E0B0>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XSLT_TRANSFORMER transform_document @24
<0000000003D0E0B0>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XSLT_TRANSFORMER transform @71
<0000000003D0E0B0>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XSLT_TEST_BOOKS  test_transform @17
<0000000004A41D18>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
PROCEDURE           fast_call
<0000000004A41D88>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
PROCEDURE           call @3
<0000000004A41D88>                         Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XSLT_TEST_BOOKS  execute_without_rescue @4
<0000000004A41D18>  (From TS_TEST_CASE)    Routine failure. 
  Fail
-------------------------------------------------------------------------------
XM_XSLT_TEST_BOOKS  execute_with_rescue @3
<0000000004A41D18>  (From TS_TEST_CASE)    Routine failure. 
  Retry
===============================================================================


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

Re: [gobo-eiffel-develop] Code to create a UC_UTF8_STRING from STRING_GENERAL

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

Colin Adams wrote:
> Here is the functional version. It should be straight-forward to
> change it to a creation procedure.
> 
> Note that it is liberal on the memory creation of l_bytes, to avoid
> any resizing of this buffer.

In fact having it as creation procedure will allow us to avoid
having to create the intermediary object `l_bytes'.

After looking at class UC_STRING, I'm wondering whether we should
just adapt the routines `make_from_string' and `make_from_substring'
so that we can pass a STRING_GENERAL. Perhaps we will have to
rename the version of `make_from_string' inherited from STRING.
Or add `make_from_string_general', `make_from_substring_general',
make `make_from_substring' obsolete (make it call
`make_from_substring_general') and modify `make_from_string'
to call `make_from_string_general'. I'm not sure what the best
naming convention is.

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