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