Jean-Michaël Celerier

hi, I just did a commit here : https://github.com/jcelerier/CompilerExplorer/commit/5653f3742f507416dc270ac2de0f02cbdf68f81c#diff-66f29047dffe593f0e23274d7ad2b6eeR182 that adds support for fetching automatically the correct include paths & defines that the Qt code model use (at least on...

> But i can't accept the part where you return only local compilers yep that's why I didn't do a PR ! but I couldn't get it to work with...

So for this issue I'd like to redo the LFO process in avendish as this grants better flexibility than the previous API this was implemented with. I had started here...

so the compatibility mechanism currently is : - Processes have a different UUID - Processes can have a "deprecated" flag. If they have this flag, the user cannot create new...

interesting, I first tried with asio::post(channel.get_executor(), ...) but the channel never received the message. Need to investigate more. I will also check with concurrent_channel, thanks for the hint. Would that...

right, something like this should be safer: ```C++ namespace libremidi { struct channel { cobalt::channel& impl; void operator()(const libremidi::message& message) { cobalt::spawn(impl.get_executor(), task(message), asio::detached); } cobalt::task task(libremidi::message message) { co_await...

Yes, for the channel I understand, but the write to the channel is wrapped into a cobalt::spawn on the channel's executor (the main one). Is that safe ?

great, thanks !

Hello ! can you share the score you have ? When you say lower branch is it the one with Interval.cuba2 and does it crash when editing or when playing...

i'm trying to see if I can build a flatpak to offer an alternative way. Not sure I can do anything about AppImageLauncher bugs sadly...