Re: CATCALLs when running tests via geant

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:[email protected]
http://www.gobosoft.com

-------------------------------------------------------------------------
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=/