Welcome to Cadabra Q&A, where you can ask questions and receive answers from other members of the community.
+2 votes

Does anyone know a way to display the currently running function?

In Cadabra v1, this was extremely useful when I was doing a long list of substitutions / functions. It would give the function (e.g. "canonicalise") and display numerically how far along it was. If something were to hang, I could see immediately what the issue was.

I would love to be able to replicate that functionality within Cadabra v2. Perhaps there is a way to query the kernel for this information?

in Feature requests by (1.0k points)

Here is a hack-ish solution to this that I've been using. I've no idea how (in)efficient it is. The idea is to use console.log to dump debugging information to the Interactive Console. This is faster than passing it to the GUI.

Within the Python package, we have to pass it the Console object. I do this with

console = None
console_log = False

def ConsoleLogger(__console__):
    global console
    global console_log
    console = __console__
    console_log = True

This declares a global object 'console' wihtin the package and we use ConsoleLogger(console) to initialize it.

Then I define a Python decorator

def debugger (func):
    def wrapper(*args, **kwargs):
        console.log(f'\nCalling {func.__name__}')
        initial_terms = len(args[0])
        start_time = time.time()
        result = func(*args, **kwargs)
        end_time = time.time()
        final_terms = len(result)
        console.log(f'{initial_terms} --> {final_terms} terms in {end_time-start_time:.3f} s')
        return result
    return wrapper

Then I can call, e.g.,


to have collect_terms dump its data to the Interactive Console.

Note: the timer only times the actual function, not the debugger wrapper.

1 Answer

+1 vote

There is some internal functionality for algorithms to send out-of-band progress information to the user interface in v2, but it has mostly been to experiment with it and see what we need. Only the meld algorithm really uses it at the moment. I am not sure we have converged on the right mechanism yet, hence it hasn't been included in other algorithms.

The problem is, as always with logging, that you do not want to log too little, but you also do not want to log too much. However, this distinction is very much a function of the problem you are solving: sometimes you want to see an update for all terms canonicalise acts on, but sometimes that's a very fast part of some inner loop and you are not interested in that. Some nested progress indicator is probably best.

If you have any good ideas, please post.

by (76.2k points)