gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] XML/XSLT processing times

[Berend de B. <be...@po...>]

>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:

    Colin> I did some timings of other methods of copying an XML file to
    Colin> try to put this into perspective:

You could try the expat one, this was one of my reasons for using expat
as expat was still faster, despite the prohibitive event chaining
overhead. It's an interesting architecture, but performance is ****.

Did you look at memory consumption as well? That's also a biggie with
Eiffel. If you don't use memory, like the C versions do, performance is
much better.


    Colin> Anyway, there seems little hope of getting the XSLT library
    Colin> to perform on this basis. It would seem the entire XML
    Colin> parser/event infrastructure would need re-writing. I have no
    Colin> appetite for the task given the current W3C climate.

If you need performance, absolutely. As we can now use agents, we
probably can cleanup this a bit, and have the event infrastructure sit
on top of that.

BTW, I've always found the ISE profiler an indispensable tool in solving
performance problems, but as you say, it'll be a lot of work.

-- 
Cheers,

Berend de Boer

[gobo-eiffel-develop] XML/XSLT processing times

[Colin P. A. <co...@co...>]

I am just about ready to give up on the XSLT library. The W3C's
attitude to the XML "standard" being a prime driver (what's the point
of implementing a standard when it will arbitrarily and
retrospectively be pulled from underneath you?). The other is my
inability to solve the performance problem.

I have done some timings on an identity transformation of a 10MB XML
file. This is likely to be the worst case scenario for using
ST_STRING, as the cost of copying all the strings from UC_UTF8_STRING
to ST_STRING ought to be significant compared with the rest of the
processing (which is the least possible for any XSLT transformation
that does not involve filtering out some of the data). Even so, this
cost ought to be relatively low, and I would have hoped for an overall
improvement.

Instead the runtime goes from 26 seconds to 35 seconds.

I did some timings of other methods of copying an XML file to try to
put this into perspective:

1. Identity transformation using Saxon and xsltproc -> 1.5 and 1
second respectively. Pretty damning.
2. Linux cp command - 25 milliseconds.
3. Gobo Eiffel XML parser using the example/xml/tree/formatter program
(modified to operate in unicode string mode, as there were unicode
character references in the XML file, and commenting out the DTD in
the file, as the program will not process an external DTD) - 15
seconds.
4. Gobo Eiffel XML parser using the example/xml/event/print program
(same modifications as above). Output redirected to a file. - 26 seconds.

The last one was particularly intriguing, as I noticed half the time
was kernel time. I redirected it to /dev/null instead and it came down
to 10 seconds. I'm not sure what is going on at all here. Any thoughts?

Anyway, there seems little hope of getting the XSLT library to perform
on this basis. It would seem the entire XML parser/event
infrastructure would need re-writing. I have no appetite for the task
given the current W3C climate.

ST_STRING might be useful anyway. Shall I post the classes here for review?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] CATCALLs when running tests via geant

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:
    >> That is what is so difficult.

    Eric> No one said that CAT-call were easy.

Nor is improving the performance of gexslt.
It appears (using ISE as I can't compile with gec) that there is no
significant change to the performance using ST_STRING.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] CATCALLs when running tests via geant

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> The problem is the use of TUPLE [NATURAL_32,
>     Eric> INTEGER].is_equal. In line 267, it calls `equal' with
>     Eric> results of `item'. TUPLE.item is a source of CAT-call. So
>     Eric> you should figure out where you call TUPLE.is_equal and
>     Eric> replace that call by a CAT-call-free call.
> 
> That is what is so difficult. 

No one said that CAT-call were easy.

> Why isn't the call in the stack?

Please explain how it could be in the stack (without showing the
whole program text in the error message).

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

Re: [gobo-eiffel-develop] CATCALLs when running tests via geant

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

Colin Paul Adams wrote:
> That meant I was easily able to eliminate my node-iterator agent
> problems, but I'm at a loss as to know what to make of stuff like
> this:
> 
> [CATCALL] class TUPLE [NATURAL_32, INTEGER] (ANY,97,8): type
>         'NATURAL_32' of actual argument #1 does not conform to type
>         'INTEGER_32' of formal argument in feature `is_equal' in class
>         'INTEGER_32': 
>         Target type: 'INTEGER_32'
>                 Attachment stack #1
>                         class TUPLE [NATURAL_32, INTEGER] (ANY,97,8): target
>                         class TUPLE [NATURAL_32, INTEGER] (267,25): argument
>                         class TUPLE [NATURAL_32, INTEGER] (56,39): assignment
>                         class TUPLE [NATURAL_32, INTEGER] (60,2): built-in
>                 Attachment stack #2
>                         class TUPLE [NATURAL_32, INTEGER] (ANY,97,8): target
>                         class TUPLE [NATURAL_32, INTEGER] (267,25): argument
>                         class TUPLE [NATURAL_32, INTEGER] (54,40): assignment
>                 Attachment stack #3
>                         class TUPLE [NATURAL_32, INTEGER] (ANY,97,8): target
>                         class TUPLE [NATURAL_32, INTEGER] (267,25): argument
>                         class TUPLE [NATURAL_32, INTEGER] (36,2): built-in
>         Argument type: 'NATURAL_32'
>                 Attachment stack #1
>                         class TUPLE [NATURAL_32, INTEGER] (ANY,97,23): argument
>                         class TUPLE [NATURAL_32, INTEGER] (267,35): argument
>                         class TUPLE [NATURAL_32, INTEGER] (56,39): assignment
>                         class TUPLE [NATURAL_32, INTEGER] (60,2): built-in
>                 Attachment stack #2
>                         class TUPLE [NATURAL_32, INTEGER] (ANY,97,23): argument
>                         class TUPLE [NATURAL_32, INTEGER] (267,35): argument
>                         class TUPLE [NATURAL_32, INTEGER] (50,40): assignment
>                 Attachment stack #3
>                         class TUPLE [NATURAL_32, INTEGER] (ANY,97,23): argument
>                         class TUPLE [NATURAL_32, INTEGER] (267,35): argument
>                         class TUPLE [NATURAL_32, INTEGER] (36,2): built-in
> 
> This doesn't even point me at the class to look at, let alone a line
> number.
> 
> I guess they will be calls to do_all_with_index where I have failed to
> change a local variable from DS_ARRAYED_LIST [INTEGER] to
> DS_ARRAYED_LIST [NATURAL_32], and therefore probably some usage of
> {ST_STRING}.do_forward/all_with_index, so I can probably track them
> (there are a lot of these) down by checking callers of this routine
> from EiffelStudio, but wouldn't it be possible to give the line in the
> source code where this occurs?

The problem is the use of TUPLE [NATURAL_32, INTEGER].is_equal. In line
267, it calls `equal' with results of `item'. TUPLE.item is a source
of CAT-call. So you should figure out where you call TUPLE.is_equal
and replace that call by a CAT-call-free call.

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

Re: [gobo-eiffel-develop] CATCALLs when running tests via geant

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> The problem is the use of TUPLE [NATURAL_32,
    Eric> INTEGER].is_equal. In line 267, it calls `equal' with
    Eric> results of `item'. TUPLE.item is a source of CAT-call. So
    Eric> you should figure out where you call TUPLE.is_equal and
    Eric> replace that call by a CAT-call-free call.

That is what is so difficult. Why isn't the call in the stack?

Interestingly, eiffelstudio produces no runtime CATCALL detection messages any
more when run the test suite (it did until I fixed the node-iterator agents).
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] CATCALLs when running tests via geant

[Colin P. A. <co...@co...>]

Forwarded:
>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:

>>>>> "Eric" == Eric Bezault <er...@go...> writes:
    Eric> Colin Paul Adams wrote:
    >>> I'm trying to run the xslt tests using geant test_debug_ge,
    >>> and I'm getting a lot of messages identical to this one:
    >>> 
    >>> [CATCALL] class TUPLE [NATURAL_32, INTEGER] (ANY,97,8): type
    >>> 'NATURAL_16' of actual argument #1 does not conform to type
    >>> 'INTEGER_16' of formal argument in feature `is_equal' in class
    >>> 'INTEGER_16'
    >>> 
    >>> 
    >>> as well as many other CATCALL messages.
    >>> 
    >>> How do I get additional information to try to track down the
    >>> problems?

    Eric> Use gelint with the --catcall option.

    Colin> That meant I was easily able to eliminate my node-iterator
    Colin> agent problems, but I'm at a loss as to know what to make
    Colin> of stuff like this:

    Colin> [CATCALL] class TUPLE [NATURAL_32, INTEGER] (ANY,97,8):
    Colin> type 'NATURAL_32' of actual argument #1 does not conform to
    Colin> type 'INTEGER_32' of formal argument in feature `is_equal'
    Colin> in class 'INTEGER_32': Target type: 'INTEGER_32' Attachment
    Colin> stack #1 class TUPLE [NATURAL_32, INTEGER] (ANY,97,8):
    Colin> target class TUPLE [NATURAL_32, INTEGER] (267,25): argument
    Colin> class TUPLE [NATURAL_32, INTEGER] (56,39): assignment class
    Colin> TUPLE [NATURAL_32, INTEGER] (60,2): built-in Attachment
    Colin> stack #2 class TUPLE [NATURAL_32, INTEGER] (ANY,97,8):
    Colin> target class TUPLE [NATURAL_32, INTEGER] (267,25): argument
    Colin> class TUPLE [NATURAL_32, INTEGER] (54,40): assignment
    Colin> Attachment stack #3 class TUPLE [NATURAL_32, INTEGER]
    Colin> (ANY,97,8): target class TUPLE [NATURAL_32, INTEGER]
    Colin> (267,25): argument class TUPLE [NATURAL_32, INTEGER]
    Colin> (36,2): built-in Argument type: 'NATURAL_32' Attachment
    Colin> stack #1 class TUPLE [NATURAL_32, INTEGER] (ANY,97,23):
    Colin> argument class TUPLE [NATURAL_32, INTEGER] (267,35):
    Colin> argument class TUPLE [NATURAL_32, INTEGER] (56,39):
    Colin> assignment class TUPLE [NATURAL_32, INTEGER] (60,2):
    Colin> built-in Attachment stack #2 class TUPLE [NATURAL_32,
    Colin> INTEGER] (ANY,97,23): argument class TUPLE [NATURAL_32,
    Colin> INTEGER] (267,35): argument class TUPLE [NATURAL_32,
    Colin> INTEGER] (50,40): assignment Attachment stack #3 class
    Colin> TUPLE [NATURAL_32, INTEGER] (ANY,97,23): argument class
    Colin> TUPLE [NATURAL_32, INTEGER] (267,35): argument class TUPLE
    Colin> [NATURAL_32, INTEGER] (36,2): built-in

    Colin> This doesn't even point me at the class to look at, let
    Colin> alone a line number.

    Colin> I guess they will be calls to do_all_with_index where I
    Colin> have failed to change a local variable from DS_ARRAYED_LIST
    Colin> [INTEGER] to DS_ARRAYED_LIST [NATURAL_32], and therefore
    Colin> probably some usage of
    Colin> {ST_STRING}.do_forward/all_with_index, so I can probably
    Colin> track them (there are a lot of these) down by checking
    Colin> callers of this routine from EiffelStudio, but wouldn't it
    Colin> be possible to give the line in the source code where this
    Colin> occurs?  -- Colin Adams Preston Lancashire

-- 
Colin Adams
Preston Lancashire

[gobo-eiffel-develop] XML parser reading from wrong source

[Colin P. A. <co...@co...>]

In one of the XSLT tests for the reworked libraries, the XML parser is
reading data from some location other than scanner.input_stream. I
know this is the case, because I recognize some of the content text -
this comes from a previous data XML file, processed in a previous step
of the test. The first step generates a transformation in-memory,
according to the contents of this data file. The second step uses
this generated transformation to process yet another data file.

It is while compiling the generated transformation that the bad
content appears. The whole of the generated transformation is
correctly parsed, but the parsed xsl:stylesheet element has 6 children
instead of 5, and the fifth child is a text node with this errant
data.

What I would like to know is where the scanner can read it's input
other than from `input_stream', so I can debug this better.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Backward iterators

[Paul M. <jum...@gm...>]

On Sat, Nov 1, 2008 at 1:52 PM, Colin Paul Adams
<co...@co...> wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>
>    >> *_backwards seems straight-forward.
>
>    Eric> My dictionary says that Americans use "backward" instead of
>    Eric> "backwards".
>
> There's a subtle difference in meaning in England, in that the former
> could be construed as a slight. But i don't object.

FWIW:

backward and backwards both have negative connotations in the US.
When used appropriately here, they both refer to a static orientation.

For movement, we use forward and reverse.

-paul


>
>
>    Eric> We could have the forward(s) and backward(s) versions, and
>    Eric> have `do_all' use one or the other (when people don't care
>    Eric> about the direction of the traversal). For example in
>    Eric> DS_CONTAINER we have `do_all' since we don't really know or
>    Eric> care about traversal directions. In class DS_LINEAR it could
>    Eric> be implemented using `do_forward(s)'.
>
> That sounds good to me. You might try selling it to Manu for Free ELKS
> too. There wouldn't be any compatibility (I left out the preceding
> adjective :-) ) problem, either.
> --
> Colin Adams
> Preston Lancashire
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gobo-eiffel-develop mailing list
> gob...@li...
> https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
>

Re: [gobo-eiffel-develop] CATCALLs when running tests via geant

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Colin Paul Adams wrote:
>     >> Some other the other reported problems appear to be due to the
>     >> poor conformance rule for agents.
> 
>     Eric> Yes, this has been designed that way to punish people who
>     Eric> want to overuse agents ;-)
> 
> So it's Franck's fault then, for persuading me to replace loops with
> iterators.
> 
>     >> so there is no error (`append_node' will receive an argument
>     >> that conforms to XM_XPATH_NODE). Therefore I need to supress
>     >> these messages. Is that possible?
> 
>     Eric> Yes, you can find the solution in Karine's slides from last
>     Eric> week.  Try to use:
> 
>     Eric>    agent append_node ({XM_XPATH_TREE_NODE} ?)
> 
> That won't work - some nodes will be XM_XPATH_TINY_NODEs instead.

Ah, I see. I think that I already raised this issue at ECMA
last year. Not being a big fan of "use agent everywhere"
I didn't push any further. In my opinion there are many
issues with agents that make me prefer use "regular" feature
calls (and hence loops). There is this typing issue. Then
there are the inline agents that are too verbose and go against
reuse. But without inline agents, agents are not expressive
enough to my taste. And the use of agents does not go very
well with DbC. Furthermore ISE's storable does not handle
them correctly. So, I'm fine using agents in very specific
situations. But not everywhere.

For your particular problem, perhaps you can add an extra
iterator routine in XM_XPATH_AXIS_ITERATOR, something like
`do_all_nodes' which takes a PROCEDURE [ANY, TUPLE [XM_XPATH_NODE]]
as argument.

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

Re: [gobo-eiffel-develop] CATCALLs when running tests via geant

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> Colin Paul Adams wrote:
    >> Some other the other reported problems appear to be due to the
    >> poor conformance rule for agents.

    Eric> Yes, this has been designed that way to punish people who
    Eric> want to overuse agents ;-)

So it's Franck's fault then, for persuading me to replace loops with
iterators.

    >> so there is no error (`append_node' will receive an argument
    >> that conforms to XM_XPATH_NODE). Therefore I need to supress
    >> these messages. Is that possible?

    Eric> Yes, you can find the solution in Karine's slides from last
    Eric> week.  Try to use:

    Eric>    agent append_node ({XM_XPATH_TREE_NODE} ?)

That won't work - some nodes will be XM_XPATH_TINY_NODEs instead.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] CATCALLs when running tests via geant

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

Colin Paul Adams wrote:
> Some other the other reported problems appear to be due to the poor
> conformance rule for agents.

Yes, this has been designed that way to punish people who
want to overuse agents ;-)

> so there is no error (`append_node' will receive an argument that
> conforms to XM_XPATH_NODE). Therefore I need to supress these
> messages. Is that possible?

Yes, you can find the solution in Karine's slides from last week.
Try to use:

    agent append_node ({XM_XPATH_TREE_NODE} ?)

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

Re: [gobo-eiffel-develop] CATCALLs when running tests via geant

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

Colin Paul Adams wrote:
> I'm trying to run the xslt tests using geant test_debug_ge, and I'm
> getting a lot of messages identical to this one:
> 
> [CATCALL] class TUPLE [NATURAL_32, INTEGER] (ANY,97,8): type
> 'NATURAL_16' of actual argument #1 does not conform to type
> 'INTEGER_16' of formal argument in feature `is_equal' in class
> 'INTEGER_16' 
> 
> 
> as well as many other CATCALL messages.
> 
> How do I get additional information to try to track down the problems?

Use gelint with the --catcall option.

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

Re: [gobo-eiffel-develop] CATCALLs when running tests via geant

[Colin P. A. <co...@co...>]

>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:

    Colin> I'm trying to run the xslt tests using geant test_debug_ge,
    Colin> and I'm getting a lot of messages identical to this one:

    Colin> [CATCALL] class TUPLE [NATURAL_32, INTEGER] (ANY,97,8):
    Colin> type 'NATURAL_16' of actual argument #1 does not conform to
    Colin> type 'INTEGER_16' of formal argument in feature `is_equal'
    Colin> in class 'INTEGER_16'


    Colin> as well as many other CATCALL messages.

    Colin> How do I get additional information to try to track down
    Colin> the problems?


Some other the other reported problems appear to be due to the poor
conformance rule for agents. For instance, these messages:

[CATCALL] class XM_XSLT_COMPLEX_CONTENT_OUTPUTTER (417,5): type
'PROCEDURE [XM_XSLT_COMPLEX_CONTENT_OUTPUTTER, TUPLE [XM_XPATH_NODE]]'
of actual argument #1 does not conform to type 'PROCEDURE [ANY, TUPLE
[XM_XPATH_TREE_NODE]]' of formal argument in feature `do_all' in class
'XM_XPATH_EMPTY_ITERATOR [XM_XPATH_TREE_NODE]' 
[CATCALL] class XM_XSLT_COMPLEX_CONTENT_OUTPUTTER (417,5): type
'PROCEDURE [XM_XSLT_COMPLEX_CONTENT_OUTPUTTER, TUPLE [XM_XPATH_NODE]]'
of actual argument #1 does not conform to type 'PROCEDURE [ANY, TUPLE
[XM_XPATH_NAMESPACE_NODE]]' of formal argument in feature `do_all' in
class 'XM_XPATH_NAMESPACE_AXIS_ITERATOR' 
[CATCALL] class XM_XSLT_COMPLEX_CONTENT_OUTPUTTER (417,5): type
'PROCEDURE [XM_XSLT_COMPLEX_CONTENT_OUTPUTTER, TUPLE [XM_XPATH_NODE]]'
of actual argument #1 does not conform to type 'PROCEDURE [ANY, TUPLE
[XM_XPATH_TREE_NODE]]' of formal argument in feature `do_all' in class
'XM_XPATH_TREE_ANCESTOR_ENUMERATION' 
[CATCALL] class XM_XSLT_COMPLEX_CONTENT_OUTPUTTER (417,5): type
'PROCEDURE [XM_XSLT_COMPLEX_CONTENT_OUTPUTTER, TUPLE [XM_XPATH_NODE]]'
of actual argument #1 does not conform to type 'PROCEDURE [ANY, TUPLE
[XM_XPATH_TREE_ATTRIBUTE]]' of formal argument in feature `do_all' in
class 'XM_XPATH_TREE_ATTRIBUTE_ENUMERATION' 

(and more of the same) are coming from this code:

	append_item (a_item: XM_XPATH_ITEM) is
			-- Output an item (atomic value or node) to the sequence.
		do
			if a_item.is_atomic_value then
				if previous_atomic then
					notify_characters (shared_single_blank_string, 0)
				end
				notify_characters (a_item.as_atomic_value.string_value, 0)
				previous_atomic := True
			elseif a_item.is_document then
				a_item.as_document.new_axis_iterator (Child_axis).do_all (agent append_node)
			elseif a_item.is_error then
				on_error (a_item.error_value.error_message)
			else
				check
					node: a_item.is_node
					-- items are atomic values or nodes
				end
				a_item.as_node.copy_node (Current, All_namespaces, True)
				previous_atomic := False
			end
		end
	
	append_node (a_node: XM_XPATH_NODE) is
			-- Output a node to the sequence.
			-- Needed because of wrong agent conformance rule.
		do
			append_item (a_node)
		end

so there is no error (`append_node' will receive an argument that
conforms to XM_XPATH_NODE). Therefore I need to supress these
messages. Is that possible?
-- 
Colin Adams
Preston Lancashire

[gobo-eiffel-develop] CATCALLs when running tests via geant

[Colin P. A. <co...@co...>]

I'm trying to run the xslt tests using geant test_debug_ge, and I'm
getting a lot of messages identical to this one:

[CATCALL] class TUPLE [NATURAL_32, INTEGER] (ANY,97,8): type
'NATURAL_16' of actual argument #1 does not conform to type
'INTEGER_16' of formal argument in feature `is_equal' in class
'INTEGER_16' 


as well as many other CATCALL messages.

How do I get additional information to try to track down the problems?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Backward iterators

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

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> I thought about that as well. I think that I was the first
>     Eric> one to explicitly state in the header comments that the
>     Eric> iterators are traversing from first to last. Which of course
>     Eric> raises the issue that we miss the iterators from last to
>     Eric> first. We also probably miss a few other possible iterators
> 
> There is a class in EiffelBase, called something like LINEAR_ITERATOR
> that has a whole lot of variants. It might be worth taking a look at
> (but with caution - when I last looked at it, it was a real mess - at
> least as far as contracts went. i raised the issue with Manu, and they
> did something about it, but i haven't looked at it to see what0.
> 
>     Eric> such as do_until.  Any naming convention for the backward
>     Eric> iterator feature names?
> 
> *_backwards seems straight-forward.

My dictionary says that Americans use "backward" instead
of "backwards".

> E.g do_all_backwards, do_if_backwards and do_all_with_index_backwards
> all read ok.
> 
> It would be more compact to drop the all, but then we get an
> inconsistent pattern:
> 
> do_backwards, do_if_backwards, do_backwards_with_index.
> 
> Still, I think I prefer these shorter names.
> If we were starting from scratch, I would definitely go for this,
> along with fo_forwards, etc., rather than do_all.

We could have the forward(s) and backward(s) versions,
and have `do_all' use one or the other (when people
don't care about the direction of the traversal). For
example in DS_CONTAINER we have `do_all' since we don't
really know or care about traversal directions. In
class DS_LINEAR it could be implemented using
`do_forward(s)'.

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

Re: [gobo-eiffel-develop] Backward iterators

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    >> *_backwards seems straight-forward.

    Eric> My dictionary says that Americans use "backward" instead of
    Eric> "backwards".

There's a subtle difference in meaning in England, in that the former
could be construed as a slight. But i don't object.


    Eric> We could have the forward(s) and backward(s) versions, and
    Eric> have `do_all' use one or the other (when people don't care
    Eric> about the direction of the traversal). For example in
    Eric> DS_CONTAINER we have `do_all' since we don't really know or
    Eric> care about traversal directions. In class DS_LINEAR it could
    Eric> be implemented using `do_forward(s)'.

That sounds good to me. You might try selling it to Manu for Free ELKS
too. There wouldn't be any compatibility (I left out the preceding
adjective :-) ) problem, either.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Backward iterators

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

Colin Paul Adams wrote:
> In several places in the XSLT library, I have to process structures
> backwards, using new_cursor, finish, before. This precludes converting
> the loops to using agents with do_all, do_if etc. This will annoy
> Franck.
> 
> Well, I have no objection to annoying Franck, since he won't fix the
> bugs in the XML parser. But if he decides to do so, can we reward him
> with backward iterators?

I thought about that as well. I think that I was the first one
to explicitly state in the header comments that the iterators
are traversing from first to last. Which of course raises the
issue that we miss the iterators from last to first. We also
probably miss a few other possible iterators such as do_until.
Any naming convention for the backward iterator feature names?

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

Re: [gobo-eiffel-develop] Backward iterators

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> I thought about that as well. I think that I was the first
    Eric> one to explicitly state in the header comments that the
    Eric> iterators are traversing from first to last. Which of course
    Eric> raises the issue that we miss the iterators from last to
    Eric> first. We also probably miss a few other possible iterators

There is a class in EiffelBase, called something like LINEAR_ITERATOR
that has a whole lot of variants. It might be worth taking a look at
(but with caution - when I last looked at it, it was a real mess - at
least as far as contracts went. i raised the issue with Manu, and they
did something about it, but i haven't looked at it to see what0.

    Eric> such as do_until.  Any naming convention for the backward
    Eric> iterator feature names?

*_backwards seems straight-forward.

E.g do_all_backwards, do_if_backwards and do_all_with_index_backwards
all read ok.

It would be more compact to drop the all, but then we get an
inconsistent pattern:

do_backwards, do_if_backwards, do_backwards_with_index.

Still, I think I prefer these shorter names.
If we were starting from scratch, I would definitely go for this,
along with fo_forwards, etc., rather than do_all.
-- 
Colin Adams
Preston Lancashire

[gobo-eiffel-develop] Backward iterators

[Colin P. A. <co...@co...>]

In several places in the XSLT library, I have to process structures
backwards, using new_cursor, finish, before. This precludes converting
the loops to using agents with do_all, do_if etc. This will annoy
Franck.

Well, I have no objection to annoying Franck, since he won't fix the
bugs in the XML parser. But if he decides to do so, can we reward him
with backward iterators?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] KL_STRING_VALUES

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

Colin Adams wrote:
> `interpreted_string' could have a postcondition that the result is not
> the same object as `a_string'.

I just added it. However I find it less expressive than the header
comment which says that we will get a new object at each call.

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

[gobo-eiffel-develop] KL_STRING_VALUES

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

`interpreted_string' could have a postcondition that the result is not
the same object as `a_string'.

Re: [gobo-eiffel-develop] Poor error message

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@us...> writes:

    Eric> Colin Paul Adams wrote:
    >> Gec is giving some poor error messages.
    >> 
    >> Im am still seing some plain "Syntax error" messages - these
    >> could be greatly improved.

    Eric> Hopefully you see the contextual indication of where the
    Eric> syntax error is, don't you?

Sometimes the real error can be a long way back. I can easily lose an
hour a day (I did yesterday) looking for such problems.

    Eric> It has been two years now since I had plan to write a better
    Eric> parser.  But it's a big task and I never found time yet to
    Eric> start such development. I hope I can do that soon.

Good.

    >> 
    >> 
    >> [VMRC-2] class XM_XSLT_STYLE_ELEMENT (50,2): replicated
    >> features XM_XSLT_STYLE_ELEMENT have not been selected.
    >> 
    >> I have no clue as to which the replicated features might be. My
    >> only remedy is to try compiling with ISE instead.

    Eric> In fact the information was in the compiler. There was just
    Eric> a typo in the code that displays the error message. Instead
    Eric> of displaying the feature names, it was displaying the name
    Eric> of the current class.  This has now been fixed in the
    Eric> version of the compiler in Subversion, and now you should
    Eric> get:

    Eric> [VMRC-2] class XM_XSLT_STYLE_ELEMENT (50,2): replicated
    Eric> features XM_XPATH_DEBUGGING_ROUTINES.string_equality_tester,
    Eric> XM_XPATH_TREE_ELEMENT.uc_string_equality_tester have not
    Eric> been selected.  ---- [VMRC-2] class XM_XSLT_INSTRUCTION
    Eric> (37,2): replicated features
    Eric> XM_XPATH_DEBUGGING_ROUTINES.string_equality_tester,
    Eric> XM_XPATH_COMPUTED_EXPRESSION.uc_string_equality_tester have
    Eric> not been selected.

Thanks. That's much better.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Internal error in GEC

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@us...> writes:

    Eric> Colin Paul Adams wrote:
    >> I've just suddenly started seeing half-a-dozen
    >> 
    >> [GIAAA] internal error.
    >> 
    >> messages.

    Eric> It was because validity check on inspect instructions was
    Eric> not implemented yet. There is a new version of the compiler
    Eric> in Subversion. Validity check on inspect instructions is not
    Eric> fully implemented yet, but at least it reports the following
    Eric> errors instead of the internal errors:

    Eric> [VOMB-2] class XM_XSLT_SUB_PICTURE (204,9): inspect choice
    Eric> a_per_mille' is not a constant attribute.

Thanks.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Poor error message

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

Colin Paul Adams wrote:
> Gec is giving some poor error messages.
> 
> Im am still seing some plain "Syntax error" messages - these could be
> greatly improved.

Hopefully you see the contextual indication of where the
syntax error is, don't you?

It has been two years now since I had plan to write a better parser.
But it's a big task and I never found time yet to start such 
development. I hope I can do that soon.

> Then I get this:
> 
> 
> [VMRC-2] class XM_XSLT_STYLE_ELEMENT (50,2): replicated features
> XM_XSLT_STYLE_ELEMENT have not been selected.
> 
> I have no clue as to which the replicated features might be. My only
> remedy is to try compiling with ISE instead.

In fact the information was in the compiler. There was just a typo
in the code that displays the error message. Instead of displaying
the feature names, it was displaying the name of the current class.
This has now been fixed in the version of the compiler in Subversion,
and now you should get:

[VMRC-2] class XM_XSLT_STYLE_ELEMENT (50,2): replicated features 
XM_XPATH_DEBUGGING_ROUTINES.string_equality_tester, 
XM_XPATH_TREE_ELEMENT.uc_string_equality_tester have not been selected.
----
[VMRC-2] class XM_XSLT_INSTRUCTION (37,2): replicated features 
XM_XPATH_DEBUGGING_ROUTINES.string_equality_tester, 
XM_XPATH_COMPUTED_EXPRESSION.uc_string_equality_tester have not been 
selected.

You should probably rename them so that they share the same name
and hence avoid the need for a 'select' clause.

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