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 |