[ref_impl_eiffel] [864] AWB-146: Upgrade to EiffelStudio 6.4.78765:
Revision: 864 Author: peter.gummer Date: 2009-05-21 06:14:40 +0100 (Thu, 21 May 2009) Log Message: ----------- AWB-146: Upgrade to EiffelStudio 6.4.78765: * Anchor the externals directory to EiffelStudio revision 78765. Apply a recent Eiffel Software change to our copy of i18n.ecf. * Update adl_workbench.ecf and adl_parser.ecf to use "transitional" syntax. This allows adl_parser to compile with our .NET overrides of SYSTEM_STRING_FACTORY and INTERNAL. Unfortunately, it requires renaming of two of our features that were called 'attribute', which is now a keyword. The one in DT_COMPLEX_OBJECT_NODE is now called 'attribute_'; the one in C_COMPLEX_OBJECT is now called 'c_attribute'. (The latter seems more consistent with the naming of other features anyway, so it's probably a good change; but the former is ugly.) EDT-544: Fix the problem observed in Archetype Editor: "If you continue to specialise a node you will get to atNNNN.10 - you will then get an error saying that atNNNN.10 already exists." * The problem exists in the TAGS/Aug2007 branch and had not been fixed in BRANCHES/specialisation. This commit fixes the latter. (I'll copy this fix to TAGS/Aug2007 soon.) * The bug was in DIFFERENTIAL_ARCHETYPE_ONTOLOGY.new_specialised_term_code. This routine has no callers in ADL Workbench. Therefore, in order to debug this, I needed to write some test code, so I decided this was the perfect opportunity to try out EiffelStudio's new Testing tool. I created an "openehr_tests" cluster to contain tests for our "openehr" cluster. The test cluster, classes and routines all follow the naming conventions that http://docs.eiffel.com/book/eiffelstudio/create-manual-test recommends. * TEST_DIFFERENTIAL_ARCHETYPE_ONTOLOGY.test_new_specialised_term_code demonstrated that the bug was caused by taking the parent code's last specialised code (say, "at0001.9"), extracting the tail (say, "9") and adding 1 to it (say, "10"). The flaw in this logic was that the specialised codes were sorted as strings, not integers, and thus 'last' repeatedly found "at0001.9" instead of "at0001.10". * TEST_DIFFERENTIAL_ARCHETYPE_ONTOLOGY.test_new_specialised_constraint_code demonstrated the same bug in new_specialised_constraint_code. * Both routines are fixed by storing the tail part as an integer in the sorted set (say, 10), rather than the whole code string (say, "at0001.10"). This works because (a) integers give us the numeric sorting that we need; (b) these two routines are the only callers that are using the sorted set; and (c) storing the parent part of the code (say, "at0001.") was redundant anyway, because the set is already accessed via that code (say, "at0001"). Working with integers not only fixes both tests, it is more efficient than strings, and avoids costly string conversions on every access. * This fix revealed another bug. ARCHETYPE_ONTOLOGY.update_specialised_codes was creating specialised code sets for non-specialised parent codes. For example, "at0001.1" was correctly added to the set belonging to parent code "at0001"; but "at0.1" was added to the set belonging to the non-existent parent code "at0". It now adds only specialised codes, i.e. "at0001.1" but not "at0.1". This correction should also be a bit more efficient, because the hash table now contains fewer parent codes. * These two tests revealed another bug in new_specialised_term_code and new_specialised_constraint_code. These routines tried to access the last item in the parent code's set of specialised codes, even if the parent code had no such set, causing a Void target call. This is guarded against in TAGS/Aug2007. Copying the protection from TAGS/Aug2007 fixes this bug. * The tests also uncovered bugs in ARCHETYPE_TERM_CODE_TOOLS. In specialisation_parent_from_code_at_level, only the last level was ever stripped off the code. TEST_ARCHETYPE_TERM_CODE_TOOLS.test_specialisation_parent_from_code_at_level demonstrates this with the case of "at0000.0.1" at level 0, which was returning "at0000.0". It now correctly returns "at0000". (The algorithm has also been optimised to count down rather than up, avoiding multiple calculations of the specialisation depth in the loop's exit condition.) * TEST_ARCHETYPE_TERM_CODE_TOOLS.test_is_specialised_code demonstrated that is_specialised_code was returning False for "at0000.1". This is fixed by treating "at0000" as a special case. (This unfortunate hack was already prefigured by the FIXME comment on ARCHETYPE_TERM_CODE_TOOLS.Default_concept_code.) Modified Paths: -------------- BRANCHES/specialisation/apps/adl_workbench/app/adl_workbench.ecf BRANCHES/specialisation/components/adl_parser/lib/dotnet_dll/adl_parser.ecf BRANCHES/specialisation/libraries/common_libs/src/structures/data_tree/dt_complex_object_node.e BRANCHES/specialisation/libraries/common_libs/src/structures/data_tree/dt_object_converter.e BRANCHES/specialisation/libraries/externals/i18n.ecf BRANCHES/specialisation/libraries/openehr/src/am/archetype/comparator/archetype_flattener.e BRANCHES/specialisation/libraries/openehr/src/am/archetype/constraint_model/c_complex_object.e BRANCHES/specialisation/libraries/openehr/src/am/archetype/ontology/archetype_ontology.e BRANCHES/specialisation/libraries/openehr/src/am/archetype/ontology/archetype_term_code_tools.e BRANCHES/specialisation/libraries/openehr/src/am/archetype/ontology/differential_archetype_ontology.e Added Paths: ----------- BRANCHES/specialisation/libraries/openehr/tests/ BRANCHES/specialisation/libraries/openehr/tests/openehr_test_set.e BRANCHES/specialisation/libraries/openehr/tests/test_archetype_term_code_tools.e BRANCHES/specialisation/libraries/openehr/tests/test_differential_archetype_ontology.e Property Changed: ---------------- BRANCHES/specialisation/libraries/externals/