Current dev as of 1/9: Autocompletion dead? Server status bar dead?

Development
1

Yesterday, git fetch upstream and merge.

Today: Build tip of dev branch.

IDE launches, but no autocompletion or class name highlighting.

Server boots a process but status bar stays dark.

w = Window("test", Rect(800, 200, 500, 400)).front; doesn’t open a window (but other instructions post results, so the interpreter seems OK).

I had been using 3.13.0, wanted to update my stuff for kwargs and then discovered this quite weird behavior.

Ubuntu Studio 22.04 w/ XFCE.

Back to 3.13…

hjh

2

This is related to #6576.

1 Like
3

Comparing the new and old code that has changes in functionality, a good candidate can be this change from io_service::work to work_guard: the old just runs, the new has some explicit management enhancements 


    // Old
    boost::asio::io_context::work work(ioContext);
    ioContext.run();

    // New 
    boost::asio::executor_work_guard<boost::asio::io_context::executor_type> work =
        boost::asio::make_work_guard(ioContext);
    ioContext.run();

Possible ideas trying a fix (work guard stays alive for the entire duration, with safety-net ):


static void asioFunction() {
    // this first
    auto work = boost::asio::make_work_guard(ioContext);
    
    try { // make sure it stays alive
        ioContext.run();
    } catch (...) {
        work.reset(); // if shit happens, reset
        throw;
    }
    
    //  guard destroyed when the function exits
}

— this is the new intended usage. Please double-check this if someone can do it —

https://www.boost.org/doc/libs/1_87_0/doc/html/boost_asio/reference/executor_work_guard.html

4

@smoge The old and new code are really equivalent, so that can’t be the reason for the bug. (For debugging, one could insert a printf statement after ioContext.run() to verify that the ASIO thread does not terminate early.)

AFAICT work_guard is just the replacement for work, similar to io_context vs. io_service. They both do the same thing: they keep the ASIO event loop running – even if there are no outstanding async operations – until they go out of scope. When we call stop on the ioContext, all pending operations, including the work guard, are cancelled and the thread returns.

5

Thank you, pal @Spacechild1

Do you see another suspect?

6

I think so: Boost 1.87 support by capital-G · Pull Request #6576 · supercollider/supercollider · GitHub

1 Like
7

Thanks – then I’ll watch that issue for updates, and in the meantime postpone upgrading SC.

hjh

8

You can also checkout the commit before the problematic one (if there is a reason to use this branch)