Useful failures for set inequality in plunit
Ross Boylan <[email protected]>
| Newsgroups | gmane.comp.ai.prolog.swi |
|---|---|
| Message-ID | <1376180492.4084.51.camel@localhost> |
This test: <test> test(content1, [true(X == Expected), setup(full_print(OldOptions)), cleanup(restore_print(OldOptions))]) :- content_ancestors(path(['ossecond1', 'archive']), when(date(2011, 6, 1), seq(10)), Graph), graph_ordered_nodes(Graph, X), % It's not clear if /home/ross should be here, but algorithm currently includes it. % xda1 is also marginal list_to_ord_set([xdb1, xda2, xda1, path(['osfirst1', 'home']), path(['osfirst1', 'home', 'ross']), path(['osfirst1', 'mnt']), path(['osfirst1', 'sillyfile']), path(['ossecond1', 'archive'])], Expected). </test> yields <output> ERROR: /home/ross/disks/rulesTest.plt:71: test content1: wrong answer (compared using ==) ERROR: Expected: [xda1,xda2,xdb1,path([osfirst1,home]),path([osfirst1,home,ross]),path([osfirst1,mnt]),path([osfirst1|...]),path([...|...])] ERROR: Got: [xda2,xdb1,path([osfirst1,home]),path([osfirst1,home,ross]),path([osfirst1,mnt]),path([osfirst1,oldhome]),path([osfirst1|...]),path([...|...])] </output> This is not as helpful as it could be, raising three issues in ascending order of generality: 1) The max_depth setting is truncating the output; it would be helpful to see all of it. I have tried resetting it with the setup and cleanup code <code> % enable fuller printout of failures % full_print(-OldOptions). full_print(OldOptions) :- current_prolog_flag(debugger_print_options, OldOptions), select(max_depth(_), OldOptions, Old2), set_prolog_flag(top_level_print_options, [max_depth(30) | Old2]). % restore_print(+OldOptions), the argument returned from full_print. restore_print(OldOptions) :- set_prolog_flag(debugger_print_options, OldOPtions). </code> but that is ineffective, as was an earlier version with toplevel_print_options. The source of plunit includes <code> write_options([ numbervars(true), quoted(true), portray(true), max_depth(10), attributes(portray) ]). </code> which suggests the value is wired in. Is there anything I can do about that? 2) It would be more useful to have the shorter output of values expected and not found, and then values found but not expected. The test could code that, but is there a more elegant approach? I suppose I could compute the asymmetric differences in the code and then make the true option for the test work in terms of those differences. But it still seems a bit manual. 3) Is there a better way to be comparing sets? The set option for tests is not appropriate because the value being tested is a single set, not a bunch of alternative values that satisfy the predicate. Thanks. Ross Boylan P.S. The code is rulesTest.plt, commit 5f6481edb2cc45d56af2cd5c1ef64207109367e0 on https://bitbucket.org/RossBoylan/disks if you want fuller context. rulesTest.in is the slightly human-friendlier input that './fact.py rulesTest.plt' processes into the .plt file.