Logging from C code does not unify with logging from python about cocotb HOT 8 CLOSED

This is interesting (relatively) the python method PyCallable_Check seems to think that the pointer passed in is NULL, at least that is what the debug looks like when matched up to the C source of the method. Revisit later.

from cocotb.

After some more looking at this it seems to be that the filter object is returning false and so not outputting anything to log.

from cocotb.

We should filter out the DEBUG messages that appear as cocotb starts up since they are generally meaningless to users.

We probably just want one INFO message to indicate that the Python interpreter has started successfully.

from cocotb.

How is logging enabled/ disabled? (Didn't find it in the documentation ;) )

from cocotb.

-DFILTER in lib/gpi/Makefile filters any debug log messages from the C world.

In Python it's all using the standard logging library so you can do something like this:

dut.log.setLevel(logging.ERROR)
cocotb.scheduler.log.setLevel(logging.DEBUG)

from cocotb.

Just trying to clarify some things:

The LOG_WARN etc macros in the library use gpi_log to send log messages to the Python handler, with the module name cocotb.gpi

How do I control the level of filtering on those messages from Python -assuming -DFILTER is defined?

from cocotb.

The logging is controlled by LOG_ however there is a bug at the moment in the filter inside gpi_log, currently wrapped with FILTER. The problem being that no matter what the filter level the python object we call always rejects message and so nothing is printed. The current code is a work around such that you can have logging from the C world but it is all or nothing and a compilation time option.

see bug #12

from cocotb.

ok - that matches the behaviour I was seeing.

Gordon

On Thu, Jul 11, 2013 at 4:17 AM, stuarthodgson [email protected]:

The logging is controlled by LOG_ however there is a bug at the moment in
the filter inside gpi_log, currently wrapped with FILTER. The problem being
that no matter what the filter level the python object we call always
rejects message and so nothing is printed. The current code is a work
around such that you can have logging from the C world but it is all or
nothing and a compilation time option.

see bug #12 #12

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12#issuecomment-20799388
.

from cocotb.