LogtalkDotOrg/logtalk3

General discussion on Logtalk

Paulo Moura

@pmoura

Isn't the loader file loading the code that you want to debug?

A Man With A Clever Disguise

@ACleverDisguise

The loader file loads the library, yes, and compiles it with debug.

Then in the debug file I load the debugger and set the debug flag.

Paulo Moura

@pmoura

Ok.

A Man With A Clever Disguise

@ACleverDisguise

But in circumstances I'm trying to characterize now, when I do current_logtalk_flag/2 I get 'off'.

And that is likely the source of my problems. But I can't figure out when it's turning the flag off.

Paulo Moura

@pmoura

In that initilization/1 directive above, you're turning on the debug flag globally.

A Man With A Clever Disguise

@ACleverDisguise

Yes. That's what I was expecting.

I want my debug messages to display while I'm debugging.

Paulo Moura

@pmoura

After you load the file above containg that initilization/1 directive, current_logtalk_flag(debug,on) should be true and your debug messages should be displayed.

A Man With A Clever Disguise

@ACleverDisguise

There's a path that somehow gets me to that flag being off.

I haven't figured it out, but that's the source of the problem.

The flag is turned off at some point in operations.

Paulo Moura

@pmoura

Nothing in that directive would do that.

Do you have some code compiled in optimized mode?

A Man With A Clever Disguise

@ACleverDisguise

I mess around with {*}, {?}, and loading other helper scripts (like my tester), so one of those may be turning it off again.

Just the library code.

Paulo Moura

@pmoura

And you have debug calls in that library code that you're compiling in optimized mode?

A Man With A Clever Disguise

@ACleverDisguise

No, I mean YOUR standard library. :D

Paulo Moura

@pmoura

Ok.

A Man With A Clever Disguise

@ACleverDisguise

:- initialization((
    logtalk_load([
        dictionaries(loader),
        types(loader)], [optimize(on), debug(off)]),
    logtalk_load([
        two3tree
    ], [optimize(off), debug(on)])
)).

That's the loader script.

Paulo Moura

@pmoura

So, the debug calls that are not printing are iside your application objects?

A Man With A Clever Disguise

@ACleverDisguise

Yes, or my tests.

Paulo Moura

@pmoura

logtalk_load([dictionaries(loader),types(loader)], [optimize(on), debug(off)]) can simply be logtalk_load([dictionaries(loader),types(loader)]).

A Man With A Clever Disguise

@ACleverDisguise

It defaults to optimize and no debug?

I tend to over-specify to establish intent.

Paulo Moura

@pmoura

No. But the loader files for those libraries already ensure they are compiled in optimized mode.

Is two2tree a single file or a loader file?

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.

Where communities thrive

People

Repo info

Activity