[00:14] <RAOF> Grr.
[00:40] <RAOF> Threadsafety by making every individual component threadsafe is maybe not the best idea.
[01:38] <racarr> RAOF: Yeah...I had this thought when I studied
[01:38] <racarr> Chromium and they have this...uh
[01:39] <racarr> well rather than each component is thread safe its more like components live in threads
[01:39] <racarr> and the threads are like
[01:39] <racarr> higher level than the components
[01:39] <racarr> e.g. render thread, ipc thread, etc...
[01:39] <racarr> grr sorry I can't think of how to articulate it quickly
[01:39] <RAOF> The google juice for that would be CSP (communicating sequential processes) I believe.
[01:39] <racarr> but it was a really different model that I thought probably made more sense
[01:39] <racarr> yeah I mean
[01:39] <racarr> it looked like that because the main communication between them was
[01:40] <racarr> this fd thing but
[01:40] <racarr> even without going full like...
[01:40] <racarr> I mean even with still using shared memory concurrency
[01:40] <racarr> youc an group components in a smarter way and not
[01:40] <racarr> require thread safety on each one
[01:40] <RAOF> Just on the interface between them, yeah.
[01:41] <RAOF> (CSP doesn't imply not shared-memory, either)
[01:42] <racarr> yeah thats true.
[01:42] <racarr> Running out to Go club (Game not Lang)!
[01:42] <RAOF> Coo!
[01:42] <RAOF> Have fun!
[02:24] <AlbertA> vogons: so prepping for 0.15 release, abi compliance checker complains mir client is not ABI compatible because of enum MirPixelFormat mir_pixel_formats has changed...
[02:26] <AlbertA> any opinions on the matter?
[02:27] <RAOF> AlbertA: False positive.
[02:27] <RAOF> Or, rather, only code that currently fails to work will change behaviour.
[02:27] <RAOF> (I believe what it's complaining about in the value of mir_pixel_formats has changed)
[02:28] <AlbertA> yeah I couldn't think of anything....but it's late....
[02:28] <AlbertA> RAOF: right, which should be unused or just used for bounds checking
[02:28] <RAOF> The only way code can usefully use it is still valid (as a guard value).
[02:28] <RAOF> Correct.
[02:28] <AlbertA> as long as it doesn't go down should be ok....
[02:29] <RAOF> It technically is an ABI change, as something which called mir_foo(..., mir_pixel_formats) changes behaviour from erroring to passing.
[02:29] <RAOF> But people who write such code deserve what they get :)
[02:29] <RAOF> Hm.
[02:30] <AlbertA> he he yep
[02:30] <RAOF> Actually, that could plausibly break a test-suite.
[02:31] <RAOF> But almost certainly doesn't, and shouldn't break any code that *users* care about.
[02:31] <RAOF> So, go ahead.
[02:31] <AlbertA> test-suite probing behavior of mir client apis?
[02:31] <AlbertA> with invalid inputs?
[02:32] <AlbertA> I suppose so....but is there such a thing in the wild?
[02:32] <RAOF> A toolkit could reasonably use that to check its handling of Mir errors, for example.
[02:33] <AlbertA> umm true... but that's why you mock those things :)
[02:33] <RAOF> I don't think there is such a test-suite in the wild, and I don't think that “inputs which were invalid remain invalid” is an ABI guarantee we make.
[02:55] <duflu> AlbertA: Yep mir_pixel_formats is intended to be a value current for the code it's compiled into. One should expect (and plan for) other users to be aware of a different value for mir_pixel_formats
[02:56] <duflu> AlbertA: Also, my MP up for review solves an issue that will block 0.15.
[02:57] <duflu> Although I'm making great progress optimizing QtMir, that won't be finished for a while
[03:02] <AlbertA> duflu: thanks, which MP?
[03:02] <duflu> AlbertA: My only one up for review :)
[03:02] <AlbertA> always triple buffers?
[03:02] <AlbertA> duflu: ok
[07:43] <RAOF> Man, GLibMainLoop is thorny.
[08:59] <duflu> greyback: Fun fact: I successfully prototyped very short buffer holds in QtMir and found less than expected performance. Then looked at Mir again and found I had regressed the short hold feature back in Feb. Mir needs fixing :)
[08:59] <greyback> duflu: em, woo!
[13:25] <kenvandine> kgunn, with silo 0 installed, usc doesn't start, is that known?
[13:25] <kenvandine> ERROR: /build/mir-GtufN4/mir-0.13.4+15.04.20150717/src/platform/graphics/platform_probe.cpp(59): Throw in function std::shared_ptr<mir::SharedLibrary> mir::graphics::module_for_device(const std::vector<std::shared_ptr<mir::SharedLibrary> >&)
[13:25] <kenvandine> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEEE
[13:25] <kenvandine> std::exception::what: Failed to find platform for current system
[13:31] <greyback_> kenvandine: known issue, USC needs rebuild
[13:31] <kenvandine> greyback_, ok, so is someone doing that?
[13:31] <kgunn> kenvandine: yep, sorry....
[13:31] <greyback_> kenvandine: yep, will ping when it ready
[13:32] <kenvandine> thx
[13:32] <greyback_> someone rebuilt bits before it was all ready... :)
[13:32] <kgunn> i rebuilt mir last night and got stuck on the u-s-c merge
[13:32] <kgunn> greyback_: ah,....that would be me
[13:32] <kgunn> greyback_: altho i did retarget mir0.14 and the whole bit
[13:33] <greyback_> kgunn: no worries, I had mir & qtmir updated, but wanted to finish usc before rebuilding
[13:33] <kgunn> yeah, i prolly shouldn't have done the piece wise rebuild
[13:33] <kgunn> esp after sending out mails
[13:33] <kgunn> classic
[13:34]  * kgunn hasn't checked mail and can only imagine