| robert_ancell | RAOF, did you look at https://code.launchpad.net/~vanvugt/mir/super-simple-connect/+merge/153307? | 03:26 |
|---|---|---|
| RAOF | I had not; looking. | 03:29 |
| RAOF | Google Mock: Fuzzing g++ since 2012 | 05:48 |
| RAOF | Bah! The android build is broken? | 06:24 |
| RAOF | kdub: I'm having problems with the android build. Here? | 07:43 |
| alan_g | alf_: have you looked into the trunk failure to build for android? | 09:51 |
| === mmrazik is now known as mmrazik|lunch | ||
| === mmrazik|lunch is now known as mmrazik | ||
| mmrazik | hello | 14:19 |
| mmrazik | are you guys aware mir fails to build in PPA? | 14:19 |
| mmrazik | https://launchpadlibrarian.net/134529318/buildlog_ubuntu-quantal-amd64.mir_0.0.2bzr507quantal0_FAILEDTOBUILD.txt.gz | 14:19 |
| mmrazik | I don't quite see why it was ok in jenkins :-/ | 14:19 |
| mmrazik | it looks like r505 is the first one that started to fail | 14:20 |
| alan_g | mmrazik: that's https://code.launchpad.net/~alan-griffiths/mir/fix-bug-1156543/+merge/153740 | 14:26 |
| mmrazik | great | 14:27 |
| alan_g | mmrazik: it was OK as we build with input in CI and without for PPA | 14:27 |
| mmrazik | I see | 14:28 |
| mmrazik | should we just add a build without input as well? | 14:28 |
| alan_g | There are too many options that we don't test - is on my TODO list (but low down) | 14:28 |
| alan_g | mmrazik: Please feel free | 14:28 |
| mmrazik | alan_g: ok | 14:28 |
| alan_g | mmrazik: we break the android target even more often | 14:29 |
| mmrazik | alan_g: yeah... android is on my list. I can add the crosscompile easily (like in 5 minutes). I'm having some troubles with running the tests on the phone | 14:30 |
| mmrazik | I'll just add the compile | 14:30 |
| mmrazik | better than nothing | 14:30 |
| alan_g | mmrazik: even if it didn't run (oh you said that) | 14:30 |
| mmrazik | alan_g: I was overly optimistic with those 5 mins :-/ It used to work last week but there is a new dependency (glog) and jenkins is unable to find it. Need to ping kdub later where am I supposed to get it | 14:49 |
| alan_g | mmrazik: the glog dependency shouldn't have landed | 14:50 |
| mmrazik | alan_g: its in kdub's ndk script | 14:50 |
| mmrazik | alan_g: which is called from the cross-compile script | 14:50 |
| alan_g | mmrazik: I see. (I fixed glog for raring+armhf - not sure where we are on quantal) | 14:51 |
| mmrazik | alan_g: so maybe all we need to do is to remove the dep from lp:~kdub/mir/ndk-rewrite for now | 14:52 |
| alan_g | mmrazik: I'd guess so. kdub will know what the current status is | 14:53 |
| mmrazik | ack | 14:53 |
| kdub | good morning | 14:59 |
| racarr | Morning | 15:00 |
| kdub | mmrazik, the line that has glog for me in my sources is "deb [arch=armhf] http://ports.ubuntu.com/ubuntu-ports/ raring main restricted universe multiverse" | 15:04 |
| mmrazik | kdub: so its not supposed to build on quantal? | 15:04 |
| * mmrazik tries with raring | 15:05 | |
| kdub | mmrazik, good point... i haven't sorted out where the quantal package is | 15:05 |
| kdub | mmrazik, we should only build for quantal because thats the only environment we have to run on | 15:06 |
| kdub | mmrazik, would it ease what you're doing if i roll back that change? | 15:06 |
| mmrazik | kdub: I'm trying to add android build (using the cross-compile script) to the ci/autolanding process | 15:06 |
| kdub | yay | 15:07 |
| mmrazik | I don't really mind if it is running on raring or quantal | 15:07 |
| mmrazik | kdub: if quantal makes more sense then we need to resolve the dependency somehow (possibly reverting it) | 15:07 |
| mmrazik | kdub: the compilation started on raring | 15:08 |
| mmrazik | so it seems to be fine there | 15:08 |
| kdub | mmrazik, it should build on both... we just don't have a raring phablet image to test the result on | 15:08 |
| mmrazik | kdub: I'm struggling with the phone anyway :-/ So let me add the raring build (without tests) for now | 15:09 |
| alan_g | racarr: kdub could someone look at https://code.launchpad.net/~alan-griffiths/mir/fix-bug-1156543/+merge/153740 ASAP | 15:09 |
| kdub | mmrazik, sounds good, getting the raring build (minus tests) under ci is a good first step | 15:10 |
| racarr | alan_g: approved | 15:11 |
| alan_g | racarr: ta | 15:12 |
| kdub | oh, standup today: working on unblocking the glog branch, hope to mp my branch for android display construction | 15:28 |
| kdub | will get my nex7 working again too | 15:28 |
| racarr | hrm " the_frontend_shell() override | 15:33 |
| racarr | " ? | 15:33 |
| racarr | test_focus_management_api.cpp | 15:33 |
| racarr | this doesn't work with my GCC | 15:33 |
| alan_g | racarr: are you still using 4.6? | 15:34 |
| racarr | 4.7.2 | 15:34 |
| alan_g | racarr: I don't believe you | 15:34 |
| racarr | this is an old branch so maybe the build directory is so old its on 4.6 | 15:35 |
| racarr | I will try that | 15:35 |
| racarr | I believe me though I have tried to add | 15:35 |
| racarr | override in the past to | 15:35 |
| racarr | testing server configuration overrides | 15:35 |
| racarr | but my GCC never supported it | 15:35 |
| alan_g | 4.7 does | 15:35 |
| racarr | ok yep it was an old build directory is all :) | 15:36 |
| racarr | alan_g: Fixed header installation in prepare-for-inprocess-egl (r508) | 15:40 |
| alan_g | racarr: ack, just finishing off some renaming changes and will look | 15:41 |
| racarr | alf_: ^ | 15:42 |
| racarr | You still have a dissaprove on prepare-for-inprocess-egl | 15:42 |
| racarr | if you can take a look | 15:42 |
| racarr | needs fixing* | 15:42 |
| === alan_g is now known as alan_g|tea | ||
| kdub | hello philipballew | 15:59 |
| philipballew | hey kdub | 16:00 |
| philipballew | be back, reboot time | 16:01 |
| === alan_g|tea is now known as alan_g | ||
| racarr | alan_g: Updated prepare-for-inprocess-egl-clients again to fix android build | 16:21 |
| racarr | was just some unmerged test structure reorg | 16:21 |
| racarr | havent tested myself yet though chroot is still updating | 16:21 |
| kdub | alan_g, with the google log package, armhf/quantal seems to be broken https://launchpad.net/ubuntu/+source/google-glog | 16:22 |
| kdub | alan_g, would you know who to ping about that? | 16:22 |
| alan_g | racarr: Just offered up the refactoring we discussed Friday - https://code.launchpad.net/~alan-griffiths/mir/refactor-shell-cleaner-Surface-class/+merge/153851 | 16:22 |
| alan_g | kdub: looking... | 16:23 |
| kdub | maybe seb128 ? | 16:23 |
| racarr | alan_g: Looking | 16:25 |
| alan_g | kdub: seb128 | 16:25 |
| seb128 | kdub, can't you use the raring version? | 16:25 |
| seb128 | quantal is "stable", e.g not an active serie | 16:25 |
| seb128 | work is not happening on it | 16:25 |
| seb128 | we could SRU a fix if really needed though... | 16:26 |
| kdub | seb128, the phablet builds are still quantal | 16:26 |
| kdub | makes installing/compiling mir on quantal easier | 16:27 |
| kdub | but i don't know how much effort an sru is though | 16:27 |
| seb128 | I don't think that deb has lot of depends, just wget and dpkg -i it on quantal if needed | 16:28 |
| seb128 | sru ... needs the fix to be uploaded, reviewed, validated, stay a week in staging for verification and then hit -updates | 16:29 |
| seb128 | it's not a ton of work but we try to not spent time on quantal at this point | 16:29 |
| kdub | seb128, yes, it looks like the download/dpkg -i is the easier route to go | 16:30 |
| racarr | err. looking for real now | 16:50 |
| dank101 | Hola | 17:00 |
| UbuPhillup_ | dank101: hallo | 17:00 |
| racarr | alan_g: Ok got comically distracted but just now went through refactor-shell-cleaner-surface-class | 17:11 |
| alan_g | racarr: amusing | 17:11 |
| racarr | it looks good and clears up the tests...it took me a few reads though...I think the naming SurfaceSource/SurfaceBuilder | 17:12 |
| racarr | is kind of unclear | 17:13 |
| racarr | and I wasn't sure what to expect from the types | 17:13 |
| alan_g | racarr: any help with the names gratefully received | 17:13 |
| racarr | I wonder if SurfaceBuilder is 'SurfaceOwner' | 17:13 |
| racarr | that is how It hink of it | 17:13 |
| racarr | Really its like a SurfaceOwnerController but that's unhelpfully verbose | 17:14 |
| racarr | it's also very much like a SurfaceManager ;) | 17:16 |
| kgunn | racarr: surfaceCoordinator? | 17:17 |
| racarr | I am not sure. Don't want to block on it I think but wanted to see if we could come up with an idea because while I think SurfaceBuilder provides a good description | 17:17 |
| alan_g | racarr: I'm not sure that really helps (but open to persuasion). At least part of the problem is that surfaces::Surface and shell::Surface are confusing names | 17:17 |
| racarr | of what the class does within shell:: it doesn't clarify the relationship between surfaces and shell and the ownership model (which is the primary purpose of this class) | 17:17 |
| racarr | so I think between the controller, source, and builder there is a lot of ambiguity of responsibility | 17:18 |
| racarr | kgunn: Maybe...that's sort of what the object is but not necessarily what it exposes to shell:: | 17:18 |
| racarr | alan_g: shell::Window | 17:18 |
| alan_g | racarr: as alf keeps pointing out the design talks about surfaces | 17:19 |
| racarr | a window is a surface with a certain ownership model, an input channel, window management metadata (state...) etc. | 17:19 |
| racarr | hmm | 17:19 |
| alan_g | Maybe we can edit the design? | 17:20 |
| racarr | I think | 17:20 |
| alan_g | I am | 17:20 |
| racarr | the distinctin between surface and window is a useful one to make | 17:20 |
| alan_g | racarr: Sure | 17:21 |
| racarr | because...hmm...haven't made this concrete yet | 17:21 |
| racarr | but I am imagining the shell might wnat to create surfaces for certain effects or components | 17:21 |
| racarr | that are nothing like windows | 17:21 |
| racarr | and should be a surfaces::Surface and in the surface stack | 17:21 |
| racarr | but are not a shell::Window | 17:21 |
| === kgunn is now known as kgunnAFK | ||
| racarr | is it | 17:23 |
| racarr | a SurfaceArbitrator? | 17:23 |
| racarr | I think that's my last idea. | 17:24 |
| alan_g | racarr: who do we ask why the design talks about *surfaces*? Is that just an assumption about implementation? | 17:24 |
| racarr | Hmm. I dunno. I will try and find out | 17:25 |
| racarr | katie: ^ | 17:25 |
| racarr | alan_g: My impression, is even as an assumption about implementation, it doesn't really assume much right? | 17:26 |
| alan_g | racarr: Because if we can line up the terminology as "windows" it reduces the overloading. | 17:26 |
| racarr | what is a surface ;) how is it different from a layer? how is it different from a window? | 17:26 |
| katie | racarr, alan_g, i used surfaces because we wanted to move away from assuming things were windows | 17:26 |
| racarr | I think surface is just a word we | 17:27 |
| racarr | like | 17:27 |
| racarr | katie: We own the definition of window though | 17:27 |
| katie | i think that it helped us iearly on to move away from our old way of thinking | 17:27 |
| katie | early | 17:27 |
| alan_g | Hmm, so maybe surfaces::Surface is the one with a wrong name | 17:27 |
| katie | racarr, i don't know what you mean | 17:27 |
| racarr | katie: I mean, there is nothing we have to | 17:28 |
| racarr | assume by calling things windows | 17:28 |
| racarr | because we are defining that word by behavior | 17:28 |
| racarr | katie: the context, btw is about windows being a kind of surface. | 17:29 |
| racarr | alan_g: Hehe. I like | 17:29 |
| alan_g | katie: We'd like to get clear terminology and at the moment we've two meanings for "surface" within mir | 17:29 |
| racarr | layers::Layer, but I think that's | 17:29 |
| racarr | just because I like the word layer | 17:29 |
| alan_g | racarr: I don't think layer does it - too much baggage | 17:31 |
| racarr | mm. | 17:31 |
| alan_g | racarr: tile has a different sort of baggage | 17:31 |
| racarr | scenegraph::? | 17:32 |
| racarr | surfaces is like a scene graph, shell is the controller and compositor is the view | 17:32 |
| racarr | but | 17:33 |
| racarr | it's shell that cares about words like | 17:33 |
| katie | alan_g, racarr , from my point of view surface implies something more generic than a window | 17:33 |
| racarr | "Surface" or "Window" 'sufaces/scene gaph' | 17:33 |
| katie | but I did not assume any particular implementation :) | 17:33 |
| racarr | only cares about what appears on the screen | 17:33 |
| racarr | <not convinced....brainstorm> | 17:34 |
| racarr | katie: One of the thoughts is everything an application makes is a window whereas | 17:34 |
| racarr | the shell may want to create more general surfaces | 17:34 |
| alan_g | katie: agreed | 17:35 |
| racarr | I could be | 17:35 |
| racarr | I dunno | 17:36 |
| racarr | I tend to think of surface as a more generic window too but | 17:37 |
| racarr | I could be just as easily convinced that a surface was a subregion of a window or something else | 17:37 |
| alan_g | racarr: we rename "surfaces" to "scenegraph" and "surfaces::Surface" to "surfaces::Page"? | 17:37 |
| alan_g | racarr: we rename "surfaces" to "scenegraph" and "surfaces::Surface" to "scenegraph::Page"? | 17:37 |
| racarr | which makes me think that the words really aren't that useful | 17:37 |
| racarr | alan_g: Hmm...I dunno about page...why page? | 17:38 |
| alan_g | racarr: don't like "surface", "layer", "tile", tried something else... | 17:38 |
| racarr | :) | 17:39 |
| racarr | scenegraph::Node is a little jarring at first when you think about | 17:39 |
| racarr | the shell/surfaces interaction as it is written now | 17:39 |
| racarr | but maybe it makes sense, a | 17:39 |
| alan_g | I think Node is a bit too general | 17:40 |
| racarr | shell::Surface is a scenegraph node with certain behavior | 17:40 |
| racarr | mm | 17:40 |
| === mhall119 is now known as mhall119|lunch | ||
| racarr | because in particular it's | 17:40 |
| racarr | a renderable target or something | 17:40 |
| racarr | to that effect. | 17:40 |
| alan_g | <cough/> as now written shell::Surface has a surfaces::Surface | 17:40 |
| racarr | hmm | 17:42 |
| racarr | I liked the idea of scenegraph...but now I am looking for a word for this "renderable target" concept, i.e. with swappable color buffers, etc | 17:43 |
| racarr | and the only convention really (from dri, etc) | 17:43 |
| alan_g | "image" | 17:43 |
| racarr | is "Surface" | 17:43 |
| racarr | i.e. this is the terminology in mesa etc | 17:43 |
| racarr | alan_g: It seems strange for an Image to have a buffer swapper | 17:43 |
| alan_g | ack | 17:43 |
| racarr | I think I like the most shell::Window and surfaces::Surface | 17:44 |
| racarr | I would be almost inclined to say scenegraph::Surface | 17:44 |
| racarr | because the shell, can then insert in to the scene graph say | 17:44 |
| racarr | a scenegraph::Image | 17:44 |
| racarr | as an overlay or some such | 17:44 |
| racarr | but | 17:45 |
| racarr | it's kind of an imagined case for now | 17:45 |
| racarr | a possible concrete example of | 17:46 |
| alan_g | racarr: should we land the current version and continue to think about names? (Because I don't think the latter is zeroing in yet.) | 17:46 |
| racarr | a non window surface, is a software cursor | 17:46 |
| racarr | it could either just be drawn by the compositor (through ijecting PointerController) | 17:47 |
| racarr | or it could actually be modelled in the scene graph as an element | 17:47 |
| racarr | I think this simplifies the model for implementing compositor:: but | 17:47 |
| racarr | it really depends, do we have a SurfaceStack or a SceneGraph? | 17:48 |
| racarr | alan_g: Hmm I think so | 17:48 |
| alan_g | I think we *should* have a scenegraph | 17:49 |
| racarr | me too :) | 17:49 |
| alan_g | (Relatively simple compared to those in gaming engines) | 17:49 |
| alan_g | "scenegraph::Facet"? | 17:49 |
| racarr | alan_g: For April fools I want to implement a mir compositor on the Unity3D game engine | 17:50 |
| racarr | just to really mess with people... | 17:50 |
| alan_g | racarr: you need to b e quick | 17:50 |
| racarr | maybe next year | 17:50 |
| === rsalveti_ is now known as rsalveti | ||
| racarr | Facet is kind of general | 17:51 |
| racarr | it sounds more like something the compositor sees | 17:51 |
| racarr | than the shell | 17:51 |
| racarr | i.e. something you look at but not touch | 17:51 |
| alan_g | racarr: the shell is mostly working with shell::Surface (which has a scenegraph::Facet) | 17:52 |
| * alan_g isn't really convinced | 17:52 | |
| racarr | hmm. it's a good thought | 17:52 |
| racarr | does shell::Surface modify the scenegraph::Facet or is it all through a controller? | 17:53 |
| racarr | I think it doesn't capture the fact that it has | 17:53 |
| racarr | advance_bufer and get_buffer_ipc_package though | 17:54 |
| racarr | or perhaps once we redo the API it just has next_buffer | 17:54 |
| racarr | scenegraph::Buffers | 17:54 |
| racarr | scenegraph::AdvanceableBuffer | 17:54 |
| alan_g | racarr: I'm approaching EOD - so have to leave it to you for now. | 17:55 |
| alan_g | I think that tries to capture too mcu | 17:55 |
| racarr | hehe ok | 17:55 |
| racarr | thanks for chatting :) | 17:55 |
| alan_g | *much | 17:55 |
| racarr | mm... | 17:55 |
| racarr | Hopefully it will come to me | 17:55 |
| alan_g | racarr: it is good to talk. Maybe you can find someone else with the right idea in a different timezone. | 17:55 |
| racarr | Have a good evening | 17:56 |
| racarr | Mm | 17:56 |
| alan_g | Have a good day | 17:56 |
| === mhall119|lunch is now known as mhall119 | ||
| === kgunnAFK is now known as kgunn | ||
| racarr | kdub: Could your android bug you just filed be about the input stuff in frontend? | 18:28 |
| kdub | racarr, just updated with details | 18:29 |
| kdub | was just going to ping you to advise :) https://bugs.launchpad.net/mir/+bug/1156749 | 18:29 |
| ubot5 | Launchpad bug 1156749 in Mir "example clients in rev508 do not connect" [Critical,In progress] | 18:29 |
| racarr | kdub: The problem is DummyInputManager server/server/input returns | 18:36 |
| racarr | null mi::InputChannel I guess | 18:36 |
| racarr | but hmm that should be fine... | 18:36 |
| racarr | kdub: I will look at it soon | 18:44 |
| racarr | zoned in atm | 18:44 |
| racarr | kdub: Unless it is blocking you :) | 18:49 |
| kdub | racarr, it will start generating a lot of question marks, so its best to fix asap | 18:50 |
| kdub | racarr, i mp-ed up a fix | 19:11 |
| racarr | kdub: Ah...actually | 19:17 |
| racarr | the code is in error...I guess a committ was lost | 19:17 |
| racarr | it should be if | 19:17 |
| racarr | surface->supports_input() | 19:17 |
| racarr | response->add_fd(surface->client_input_fd()) | 19:17 |
| racarr | sorry to not look sooner...was unwinding a big "make this test compile list" | 19:18 |
| racarr | also branch contains extra commented out lines | 19:18 |
| kdub | racarr, ah ok... could you upload over? (i pushed to a team branch) | 19:19 |
| racarr | kdub: https://code.launchpad.net/~mir-team/mir/fix-surface-creation-when-input-disabled/+merge/153912 | 19:27 |
| racarr | pushed changes and approved you should approve and change to approved | 19:28 |
| racarr | (How many approvables could an approver prove if an approver could approv approvables?) | 19:28 |
| racarr | We may never know | 19:28 |
| kgunn | racarr: same as licks on a tootsie-pop | 19:28 |
| kgunn | racarr: i just realized age gap on my comment http://www.youtube.com/watch?v=0UYvsk6_foc | 19:30 |
| racarr | I remember these commercials :) | 19:32 |
| kdub | racarr, i have a half written test for this condition, i'm going to finish that up and upload at the same time | 19:34 |
| racarr | kdub: Great! | 19:35 |
| kdub | racarr, pushed, but we'll wait for jenkins and another review | 19:47 |
| kdub | since we both have committed to the branch | 19:48 |
| racarr | since my dist upgrade yesterday | 19:48 |
| racarr | most shared_ptr errors generated internal compiler errors | 19:48 |
| racarr | rather than line numbers :( | 19:48 |
| racarr | line numbers were a crutch anyway | 19:49 |
| racarr | kdub: Test looks good | 19:58 |
| racarr | kdub: Though the name made me expect to see a test that | 19:58 |
| racarr | replicated the failure scenario | 19:58 |
| racarr | err hmm | 19:59 |
| racarr | nvm I had a backwards in my head | 19:59 |
| robert_ancell | RAOF, "Also unlike XCB and Xlib, it's programmatically generated from the protocol definition". I guess XCB sort of solved that problem by rewriting the spec in a programatic way | 19:59 |
| kdub | robert_ancell, quick review? https://code.launchpad.net/~mir-team/mir/fix-surface-creation-when-input-disabled/+merge/153912 | 20:11 |
| robert_ancell | kdub, looking | 20:11 |
| kdub | thanks | 20:11 |
| robert_ancell | kdub, yeah, looks good to me | 20:12 |
| robert_ancell | kdub, you want me to set the master status? | 20:12 |
| kdub | robert_ancell, won't hurt, should be fixed in short order though | 20:13 |
| robert_ancell | tvoss, Was your issue in https://code.launchpad.net/~robert-ancell/mir/server-headers/+merge/153281 resolved? | 20:40 |
| robert_ancell | racarr, also ^ | 20:41 |
| racarr | I hate it when tests pass and htey arent supposed to | 20:45 |
| robert_ancell | racarr, do you need to review this https://code.launchpad.net/~afrantzis/mir/multi-threaded-compositor-synced-with-trunk/+merge/153661? It says your review is "pending" | 20:56 |
| kgunn | robert_ancell: was just noticing the same ^ | 21:00 |
| racarr | robert_ancell: I approved the old version...am just abstaining now...trying not to get distracted :) | 21:06 |
| racarr | I am happy for it to land I looked over the weekend briefly but didn't approve because it was brief | 21:06 |
| * kdub is still reviewing multithreaded compositor branch | 21:07 | |
| === kgunn is now known as kgunnAFK | ||
| === rsalveti_ is now known as rsalveti | ||
| racarr | brb lunch | 21:24 |
| robert_ancell | kgunnAFK, can you change the drafter on https://blueprints.launchpad.net/ubuntu/+spec/client-1303-qt-mir-backend? | 21:36 |
| robert_ancell | alf_, can you change the drafter on https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-glmark2 to mir-team? | 21:37 |
| robert_ancell | kgunnAFK, and also https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-galaxynexus | 21:40 |
| kdub | i ticked multithreaded compositor to 'approved to land' | 21:58 |
| racarr | Back | 22:03 |
| racarr | send-clients-input is 16/19 todos finished XD | 22:03 |
| racarr | maybe its done growing... | 22:03 |
| RAOF | robert_ancell: Right. You write a machine-parsable version of the protocol for XCB, and then codegen from that. | 22:05 |
| robert_ancell | kdub, nice | 22:08 |
| kgunn | robert_ancell: ack will do | 22:31 |
| kgunn | robert_ancell: hey...more clean up, can you make me (or you) the "assignee" to https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-converged | 22:37 |
| robert_ancell | kgunn, I set the drafter to mir-team, does that work? | 22:37 |
| kgunn | robert_ancell: no, bill filler wanting a name there...just put me | 22:38 |
| kgunn | why i have no idea | 22:38 |
| robert_ancell | kgunn, can you do it now I changed the drafter? | 22:38 |
| kgunn | robert_ancell: real time/live race condition :) | 22:39 |
| kgunn | had to refresh page | 22:39 |
| robert_ancell | heh | 22:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!