Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 08 23:30

    pmoura on lvm_cyclic

    Update version to 3.53.0-b01 in… Update the `attvars` example te… Merge branch 'master' into lvm_… (compare)

  • Dec 08 23:14

    pmoura on lvm_coroutining

    Update the `figures` example to… (compare)

  • Dec 08 21:02

    pmoura on lvm_coroutining

    Update version to 3.53.0-b01 in… Update the `attvars` example te… Merge branch 'master' into lvm_… (compare)

  • Dec 08 19:34

    pmoura on master

    Update the `attvars` example te… (compare)

  • Dec 08 19:13

    pmoura on master

    Update version to 3.53.0-b01 in… (compare)

  • Dec 08 17:03

    pmoura on lvm_coroutining

    Update `coroutining` library fo… (compare)

  • Dec 08 16:49

    pmoura on lvm_coroutining

    Update `dif` and `coroutining` … (compare)

  • Dec 07 18:11

    pmoura on lvm_cyclic

    Fix typo in the output of the `… Improve `packs` tool documentat… Change version to 3.52.0 stable… and 1 more (compare)

  • Dec 07 11:57

    pmoura on lgt3520stable

    (compare)

  • Dec 07 11:15

    pmoura on master

    Change version to 3.52.0 stable… (compare)

  • Dec 07 10:52

    pmoura on master

    Improve `packs` tool documentat… (compare)

  • Dec 07 10:26

    pmoura on master

    Fix typo in the output of the `… (compare)

  • Dec 06 21:36

    pmoura on master

    Fix `type` library object type-… Update SVG diagrams (compare)

  • Dec 06 19:45

    pmoura on master

    Fix handling of a partial list … Update SVG diagrams Fix typo in type argument of th… (compare)

  • Dec 03 23:08

    pmoura on master

    Improve documentation on using … (compare)

  • Dec 03 20:54
    pmoura commented #121
  • Dec 03 20:49
    ccr185 commented #121
  • Dec 03 20:48
    ccr185 closed #121
  • Dec 03 20:48
    ccr185 commented #121
  • Dec 03 20:41
    pmoura commented #121
A Man With A Clever Disguise
@ACleverDisguise
A single file for now.
OK, I found the path.
Paulo Moura
@pmoura
Ok.
?
A Man With A Clever Disguise
@ACleverDisguise
If I load the tester.lgt by itself the flag is clear because of course it is.
I need to load debug first, then tester, to have the debug flag set.
Paulo Moura
@pmoura
It may be simpler to remove the calls to set_logtalk_flag(debug,on) from those initialization directives and just call this goal at the top-level (assuming here you're doing interactive debugging) when you want to see the debug messages.
A Man With A Clever Disguise
@ACleverDisguise
Probably, yes.
Well, when I'm debugging I will always want to see them. It's when I run just the tester that I'll do it manually.
Paulo Moura
@pmoura
You can always have multiple loader files, e.g. loader.lgt, loader_debug.lgt, ...
A Man With A Clever Disguise
@ACleverDisguise
I was trying to be too tricky for my own good by having a root loader that gets modified depending on if I want to debug, test, etc.
I'll just stop trying to be too DRY.
It's not as if these scripts change a lot.
Paulo Moura
@pmoura
Your loader_debug.lgt file can simply do logtalk_load(loader) +set_logtalk_flag(debug,on)` + ... so you would still use a single root loader file and derive from it in a minmal way.
A Man With A Clever Disguise
@ACleverDisguise
OK, we're back to this.
debug is on, manually confirmed.
Not a single print_message in the debug domain got printed.
If I change it to information, they all get printed.
So even manually turning the debug flag on before loading the tester still gives me tests that don't display debug messages.
Paulo Moura
@pmoura
You can use the object_property/2 predicate to check the properties of the object containing those calls.
A Man With A Clever Disguise
@ACleverDisguise
Not sure what I'm checking for? debugging is set, among a host of others that don't seem relevant.
Paulo Moura
@pmoura
Contents of the tester.lgt file?
A Man With A Clever Disguise
@ACleverDisguise
:- initialization((
    set_logtalk_flag(report, warnings),
    logtalk_load(loader),
    logtalk_load(lgtunit(loader)),
    logtalk_load(two3tree, [source_data(on), debug(on)]),
    logtalk_load(tests, [hook(lgtunit)]),
    tests::run
)).
Paulo Moura
@pmoura
And the debug message printing calls are in the two2three file?
A Man With A Clever Disguise
@ACleverDisguise
tests file right now.
I'm trying to nail down a problem in the validation predicates in the tests.
Paulo Moura
@pmoura
Can you paste one of the clauses that contain the print message call?
A Man With A Clever Disguise
@ACleverDisguise

First the uses clause that gives me the message in a convenient format. Currently set to information but if I change it to debug it never prints anything.

    :- uses(logtalk, [print_message(information, two3tree_tests, Message) as dbg(Message)]).

Now a typical clause:

    depth(Din, node(L, _, R), Dout) :-
        depth(L, DL),
        depth(R, DR),
        DL == DR, % if the depths don't match, this is a big problem!
        Dout is  Din + DL,
        dbg(depth-(Dout-node2_descend)).
Paulo Moura
@pmoura
That clause is not calling dbg/1. You meant to paste a different one?
A Man With A Clever Disguise
@ACleverDisguise
So that uses clause works. Messages print. But without changing anything else in the code, and after manually turning the debug flag on and confirming it's on, changing it to debug makes it stop working.
Oh, right. Sorry.
Fixed.
I took a test, not a helper. :)
Paulo Moura
@pmoura
Is the dbg/1 call ever reached?
A Man With A Clever Disguise
@ACleverDisguise
If I switch it to information it displays, so yes.
Paulo Moura
@pmoura
I assume so?
A Man With A Clever Disguise
@ACleverDisguise
% depth: 1-node2_leaf
% depth: 1-node(leaf,10-value10,leaf)
% two3tree_insert_1: success (in 0.0004346110000001957 seconds)
% depth: 1-node3_leaf
% depth: 1-node(leaf,10-value10,leaf,20-value20,leaf)
% two3tree_insert_2: success (in 0.00041456800000005956 seconds)
Test output for a successful test.
Paulo Moura
@pmoura
And if you modify that clause to print the value of the debug flag?
A Man With A Clever Disguise
@ACleverDisguise

OK, so I'll give you two results. Here's the run with dbg/1 using information:

% depth: 1-node2_leaf
% on
% depth: 1-node(leaf,10-value10,leaf)
% two3tree_insert_1: success (in 0.00029869099999979554 seconds)
% depth: 1-node3_leaf
% depth: 1-node(leaf,10-value10,leaf,20-value20,leaf)
% two3tree_insert_2: success (in 0.0002536849999996704 seconds)

And here's the run with dbg/1 using debug on the same test results:

% on
% two3tree_insert_1: success (in 0.00033641100000014745 seconds)
% two3tree_insert_2: success (in 0.00021322999999995318 seconds)
The dbg/1 messages vanish if configured for debug but are visible if configured for information. In both cases the current_logtalk_flag (displayed using print_message/3 using information always) is on.
A Man With A Clever Disguise
@ACleverDisguise
Adding this to the tests object doesn't change anything:
    :- set_logtalk_flag(debug, on).
Paulo Moura
@pmoura
I think I have enough details from you to look into it. Possible tomorrow.
A Man With A Clever Disguise
@ACleverDisguise
It's not critical, just to be clear. I'm fine with using information class. I was just wondering if there was something I was missing.
Paulo Moura
@pmoura
Not clear at this time. Nothing obviously wrong. But I have meetings all day and can't look at it today.
A Man With A Clever Disguise
@ACleverDisguise
By the way, I'd just like to thank you for making lgtunit so civilized.
Most testing frameworks set my teeth on edge and make me avoid writing tests until I have to.
Paulo Moura
@pmoura
:-)
A Man With A Clever Disguise
@ACleverDisguise
lgtunit is a positive joy to work with by comparison.
Paulo Moura
@pmoura
Have you already played with lgtunit QuickCheck implementation?
A Man With A Clever Disguise
@ACleverDisguise
Played, yes. Not integrated into workflow.