Menu
▾
▴
gobo-eiffel-develop
|
From: Colin P. A. <co...@co...> - 2008-11-03 07:10:12
|
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 |
|
From: Colin P. A. <co...@co...> - 2008-11-03 07:16:52
|
>>>>> "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
|
|
From: Colin P. A. <co...@co...> - 2008-11-03 09:16:16
|
>>>>> "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
|
|
From: Eric B. <er...@go...> - 2008-11-03 09:43:25
|
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
|
|
From: Eric B. <er...@go...> - 2008-11-03 08:49:19
|
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 |
|
From: Colin P. A. <co...@co...> - 2008-11-09 19:44:19
|
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
|
|
From: Colin P. A. <co...@co...> - 2008-11-09 20:14:38
|
>>>>> "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
|
|
From: Eric B. <er...@go...> - 2008-11-09 20:21:59
|
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
|
|
From: Eric B. <er...@go...> - 2008-11-03 08:56:10
|
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
|
|
From: Eric B. <er...@go...> - 2008-11-09 20:32:18
|
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 |
|
From: Colin P. A. <co...@co...> - 2008-11-10 09:54:03
|
>>>>> "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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X