Skip Menu |

This queue is for tickets about the onto-perl CPAN distribution.

Report information
The Basics
Id: 97091
Status: resolved
Priority: 0/
Queue: onto-perl

People
Owner: Nobody in particular
Requestors: hartzell.george [...] gene.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 1.42



Subject: t/Ontolome.t fails test 76.
Date: Wed, 9 Jul 2014 08:58:49 -0700
To: bug-onto-perl [...] rt.cpan.org, erick.antezana [...] gmail.com
From: George Hartzell <hartzell.george [...] gene.com>
On a Mac running OS X 10.9.2 with perl v5.18.2, ONTO-PERL fails its tests. After running cpanm -L local Date::Manip to install the prerequisite into a local library, the following command failed to complete successfully: cpanm -L local OBO::Core::Term It turns out that test #76 in t/Ontolome.t is failing. After changing t/Ontolome.t to use Test::More instead of Test (so that “ok” generates useful output on failure) it reported the failure thusly. not ok 76 # Test 76 got: "52" (t/Ontolome.t at line 627) # Expected: "48" # t/Ontolome.t line 627 is: ok($go_transitive_closure->get_number_of_relationships(), 34 + 14); # many new rels: isa*partof=>partof and partof*isa=>partof 52 is indeed not equal to 34+14. Digging in a bit with the debugger, I found the following set of relationships and there are in fact 52 of them. I do not know if there are more than there should be or if the expected count is incorrect. DB<<9>> x map {$_->{ID}} values(%{$self->{RELATIONSHIPS}}) 0 '118_part_of_103' 1 '103_part_of_56' 2 '29_part_of_56' 3 '60_part_of_117' 4 '242_is_a_29' 5 '60_is_a_29' 6 '103_part_of_2' 7 '103_part_of_10' 8 '38_part_of_2' 9 '118_part_of_117' 10 '59_part_of_117' 11 '271_part_of_10' 12 '59_part_of_103' 13 '29_part_of_10' 14 '38_part_of_10' 15 '271_part_of_2' 16 '117_part_of_271' 17 '271_part_of_265' 18 '29_part_of_265' 19 '117_part_of_265' 20 '242_part_of_2' 21 '117_is_a_103' 22 '60_is_a_59' 23 '60_part_of_10' 24 '60_part_of_2' 25 '242_part_of_265' 26 '56_is_a_10' 27 '59_is_a_29' 28 '242_part_of_10' 29 '117_part_of_2' 30 '60_part_of_103' 31 '242_part_of_56' 32 '117_part_of_10' 33 '60_is_a_242' 34 '38_part_of_56' 35 '60_part_of_56' 36 '265_is_a_56' 37 '117_part_of_56' 38 '265_is_a_2' 39 '59_is_a_242' 40 '271_is_a_38' 41 '117_part_of_38' 42 '60_part_of_118' 43 '2_is_a_10' 44 '29_part_of_2' 45 '271_part_of_56' 46 '103_part_of_271' 47 '60_part_of_265' 48 '103_part_of_38' 49 '265_is_a_10' 50 '56_is_a_2' 51 '103_part_of_265' DB<<10>> Please let me know if I can investigate further. g. ​
There was indeed a bug in the computation of the transitive closure compositions (is_a*part_of => part_of and part_of*is_a=>part_of). This has been fixed in version 1.42