[06:55] <RAOF> Hm.
[06:56] <RAOF> You know, we *could* drop the `extern "C"` on our platform interfaces, and rely on `mir::SharedLibrary::load_function<>` to get the right symbol.
[06:56] <RAOF> That would prevent this bug, and also some UB.
[07:25] <RAOF> Hm.
[07:25] <RAOF> And it would only require relying on a little implementation-defined behaviour.
[07:25] <RAOF> I'm actually warming to the idea.
[07:49] <alan_g[m]> I'm curious what UB problem you're talking about, but I guess I'll find out when you PR a solution
[07:51] <RAOF> We throw exceptions across extern "C" boundaries.
[07:52]  * RAOF is not actually going to PR a solution to that, because it turns out to involve implementing an Itanium ABI name mangler.
[08:09] <alan_g[m]> That one. Yeah. The approach I would take is to embed a hard-coded lookup table for the mangled names. But I've been sufficiently motivated
[08:11] <alan_g[m]> *not been
[08:13] <RAOF> A function-only name mangler would not be a particularly terrible task, but 🤷‍♀️.
[08:14] <alan_g[m]> A name mangler is really something for std::
[08:14] <RAOF> I mean, yes.
[08:14] <RAOF> Although it's implementation defined, so the standard wouldn't really have a lot to say about it.
[08:15] <alan_g[m]> That's the point: the standard can say "do what the implementation does"
[08:15] <RAOF> type_info::name() gets you everything but what we want, too :)
[08:15] <RAOF> Yeah, it'd totally be a useful addition to std::
[08:22] <RAOF> Anyway! Today:
[08:22] <RAOF> * (very nearly) Plumbed "only load RenderingPlatforms that can drive at least one display" probing through
[08:22] <RAOF> * Did a little investigation into how to make our symbol loading nicer, particularly catching errors at compile time (prompted by the probing change causing segfaults due to a signature change).
[08:22] <RAOF> * Decided that it's tractable, but not for now 😉 
[08:22] <RAOF> Oh, no.
[08:22] <RAOF> It's actually even more tractable, isn't it?
[08:23] <RAOF> type_info::name() gives us everything but what we want, but string concatenation should be able to take us the rest of the way?
[08:25] <RAOF> Damn.
[08:25] <RAOF> Now I'll think about it more 🤦‍♀️
[08:41] <alan_g[m]> Relying on unspecified behaviour isn't a whole lot better than relying on undefined behaviour. Just because we know g++/clang++ return the mangled name doesn't make it safe
[09:00] <alan_g[m]> Damn! You got me thinking about it again. Mangling correctly is hard without the compilation context (it needs to know about macros, typedefs and using declarations - and, for some cases, the current function name). It is probably possible from the clang AST, but that's, at best, an extra compilation pass.
[09:09] <RAOF> Right, but we don't need a general-purpose mangler; we just need to be able to mangle free-functions not in a namespace.
[09:11] <alan_g[m]> We actually only need a few known functions - a lookup table will suffice
[09:12] <RAOF> That's true.
[09:13] <RAOF> We could also automate that in the build process, right? Build an object exposing that symbol, read the mangled name out of objdump.
[09:14] <RAOF> Or, because we only have a list of like 5 symbols, not bother.
[09:16] <alan_g[m]> Or, because throwing exceptions through extern "C" works for the implementations we use, not bother
[16:48] <alan_g[m]> Today:
[16:48] <alan_g[m]> * Got a "working" spike of drag-n-drop
[16:48] <alan_g[m]> Note: Monday is a public holiday here, and I'm taking Tuesday as vacation
[16:54] <sophie-w> Oops, I've been forgetting to do my updates.
[16:54] <sophie-w> Yesterday and the day before:
[16:54] <sophie-w> - worked on the issue of gedit not coming up in mir-ci, and eventually decided the most straightforward way  to fix this was to use pluma editor instead: https://github.com/MirServer/mir-ci/pull/35