PR# 19648 Runtime seeing wrong object types
Problem Report Summary
Release: 19.05.10.3187 GPL Edition - macosx-x86-64)
Synopsis: Runtime seeing wrong object types
This started as an academic exercise to develop an Eiffel-only solution for big numbers. My jj_big_numbers library depends on another set of classes called jj_naturals. Cluster jj_naturals contains a set of classes which override the NATURAL_xx_REF classes. The idea was to get a common ancestor to all the natural classes, setting between NUMERIC and the NATURAL_xx classes. NUMERIC JJ_NATURAL NATURAL_8_REF -- my class NATURAL_8 NATURAL_16_REF -- my class NATURAL_16 NATURAL_32_REF -- my class NATURAL_32 NATURAL_64_REF -- my class NATURAL_64 JJ_NATURAL adds some bit operations and convenience features and allowed for generic classes that operate on NATURALs. (You can look at https://github.com/boxer41a/jj_sha for a project that seems to work just fine when using these classes.) Class JJ_BIG_NATURAL [G -> JJ_NATURAL] tests that assumption, but seems to be failing in ways that I cannot understand. So, 1) Can the above inheritance structure work? I know that sometimes things will compile but not work as a layman might think. (e.g. a few years ago I tried to modify ANY by adding attributes which seemed okay but failed during runs) 2) What is the cost of the above? Is it slower? How much?
Run autotest on BIG_NATURAL_8_TESTS. I am only concerned about two failing tests: 1) `is_negative' and 2) `from_array'. I think my generics and override classes confuse the runtime... Questions: 4) Test `is_negative' fails on my precondition "target_closed". Why? Other tests that follow the same pattern work just fine? 5) Test `set_with_array' gives incorrect results. In fact, feature `set_with_array' from JJ_BIG_NATURAL shows funny results when paused in the debugger. After executing the line "d := a_array [i] ", `d' shows a different value than what the debugger shows to be in `a_array [i]' ???
Problem Report Interactions
From:jimmy.johnson Date:2020/06/14 Status: Analyzed Download
Okay, I removed the external library. Under demo run big_natural_demo and run autotest. In BIG_NATURAL_TESTS see feature `run_all'. It describes the failures in `set_with_array' and `is_negative'. Notice that `is_negative' follows same format as `is_zero' which does not fail. ??
From:alexk_es Date:2020/06/12 Status: Analyzed Download
C compiler reports: Cannot open include file: 'gmp.h': No such file or directory
From:jimmy.johnson Date:2020/06/09 Status: Analyzed Download
Any indication what is missing? Which library or file, class, or function?
From:alexk_es Date:2020/06/08 Status: Analyzed Download
There is a dependency on some external code. As of now, C compilation fails because of unknown functions, structures, etc.
From:jimmy.johnson Date:2020/06/04 Status: Analyzed Download
Not really. I think I included all the libraries needed (except base, of course), didn't I? A week ago I made a small change to a previous iteration of the project and suddenly half the tests (even simple ones) were failing. The faults seemed to be totally unrelated to the changes. I suspect the problem has to do with my assumption that I can change the way NATURAL and NATURAL_REF classes work. I say this because the two failures I pointed out fail in odd ways. In `is_negative' I pass an agent with closed target which is a local variable just created, but when `is_negative' is run in the debugger, the type reported for the closed target is NOT the local but is the type of the enclosing class. ???
From:alexk_es Date:2020/06/04 Status: Analyzed Download
Would it be possible to prepare an example that does not require an external library and has only classes that do not work as you expect, please?