| === tvoss_ is now known as tvoss | ||
| tvoss | alf_, ping | 06:09 |
|---|---|---|
| alf_ | tvoss: pong | 06:10 |
| hikiko | hi :) | 07:19 |
| sil2100 | Morning | 07:21 |
| hikiko | question: although there's a libmirclient in the repos from what I see mir trunk is one cmake project (client and server are not separate) is this true? (I am not so familiar to cmake and maybe I'm wrong) actually, I am trying to configure cmake to use a mir backend so I wonder if I have to link to mirclient library or add the client source files in the CMakeLists... :) | 07:21 |
| didrocks | hey sil2100, how was your week-end? | 07:22 |
| tvoss | hikiko, you should link to the client library | 07:24 |
| duflu | hikiko: Depend on dev package libmirclient-dev, binary package libmirclient0, and just link to libmirclient | 07:25 |
| duflu | hikiko: Though I'm not sure if the Mir source is set up to export CMake packages yet... | 07:25 |
| duflu | Hmm | 07:25 |
| hikiko | i think it isn't duflu but I am not sure | 07:29 |
| * duflu checks | 07:29 | |
| hikiko | tvoss, you mean the system library? | 07:29 |
| tvoss | hikiko, system library? | 07:30 |
| duflu | hikiko: No we don't have/install a native CMake package. We do however install pkgconfig files. You can import the "mirclient" pkgconfig module into CMake via http://www.cmake.org/cmake/help/v2.8.8/cmake.html#module:FindPkgConfig | 07:32 |
| hikiko | tvoss, i mean the libmirclient that is installed in the system | 07:33 |
| tvoss | hikiko, exactly, if you are working outside the mir source tree | 07:33 |
| duflu | hikiko: pkg_search_module(MIRCLIENT REQUIRED mirclient) | 07:34 |
| hikiko | tvoss, I am woking on the mir server so, I have to use the libmirclient of the same branch I guess | 07:34 |
| duflu | and then refer to the magic variables MIRCLIENT_* (http://www.cmake.org/cmake/help/v2.8.8/cmake.html#module:FindPkgConfig) | 07:34 |
| sil2100 | didrocks: hi! Too short ;) How about yours? | 07:34 |
| hikiko | thank you duflu :D but this will use the installed libmirclient? | 07:34 |
| didrocks | sil2100: same, too short :) still a little bit exhausted by last week | 07:35 |
| didrocks | but otherwise good :) | 07:35 |
| hikiko | mmm if I run make install in the client that wont be a problem | 07:35 |
| tvoss | hikiko, yup, then you shouldn't link against the installed one | 07:36 |
| sil2100 | didrocks: at least we were able to release everything \o/ | 07:36 |
| duflu | hikiko: Or just depend on debian package (libmirclient-dev) | 07:36 |
| didrocks | sil2100: exactly! so I feel more relaxed now :) | 07:36 |
| didrocks | sil2100: I wanted to ask you if you don't mind taking the apps stack still today for the time robru will need to catch up on his emails? :) | 07:37 |
| sil2100 | didrocks: no problem ;) | 07:37 |
| hikiko | hmmm thanks duflu but this is to link with the installed client library, in my case I am trying to do something on the server using the client library | 07:37 |
| sil2100 | didrocks: I'm poking people right now already | 07:37 |
| didrocks | sil2100: that, + the new components we will put under dailies today? (You reviewed them with Mirv, right?) | 07:37 |
| didrocks | sil2100: excellent, thanks! | 07:37 |
| hikiko | is there any way to link with the client of the same branch? | 07:37 |
| hikiko | (except of including the files) | 07:38 |
| duflu | hikiko: "same branch" as what? | 07:38 |
| sil2100 | didrocks: all branches have been reviewed and merged in, so we should be able to redeploy stacks to get them daily released - but should I prepare needs-packaging bugs for the new packages? | 07:38 |
| didrocks | sil2100: no need for needs-packaging bug. This is more to ask for someone to package it :) | 07:39 |
| didrocks | sil2100: so yeah, just a MP with those, I'll prereview for NEWing before acking it | 07:40 |
| didrocks | (MP for putting them under daily release) | 07:40 |
| Mirv | yep, all reviewed | 07:40 |
| sil2100 | didrocks: ACK, although I saw that someone already added at least 2 of the new packages to the stacks last week, without re-deploying of course | 07:40 |
| didrocks | Mirv: sweetness! be prepared, I think we'll have more soon :) | 07:40 |
| duflu | hikiko: To use the client of your own local build you can export PKG_CONFIG_PATH=<mir_install_dir>/lib and then pkg_search_module(MIRCLIENT REQUIRED mirclient) | 07:40 |
| sil2100 | didrocks: like dbus-cpp and location-service to platform stack | 07:41 |
| didrocks | sil2100: ah, mind preparing me a list? Will be easier for my little brain :) (or a comment in the MP) | 07:41 |
| sil2100 | didrocks, Mirv: (but let's move that to -desktop) ;) | 07:41 |
| duflu | where you previously cmake -DCMAKE_INSTALL_PREFIX=<mir_install_dir> .. ; make ; make doc ; make install | 07:41 |
| didrocks | sil2100: nice idea :) | 07:41 |
| hikiko | oh, i see duflu, thanks a lot!( duflu and tvoss :D) | 07:42 |
| === hikiko is now known as Guest71645 | ||
| === hikiko_ is now known as hikiko | ||
| hikiko | duflu, ping | 08:25 |
| duflu | hikiko, pong | 08:25 |
| hikiko | I have another cmake question, if you could help.. :) | 08:26 |
| hikiko | in the client CMakeLists.txt: | 08:26 |
| hikiko | we have the tests if MIR_PLATFORM STREQUAL gbm or android | 08:26 |
| hikiko | I am trying to create a mir platform in the server | 08:27 |
| hikiko | but | 08:27 |
| hikiko | I want to use the client as it is | 08:27 |
| hikiko | but if I have the mir platform the $MIR_PLATFORM is equal to 'mir' not gbm or android | 08:27 |
| hikiko | do you have any idea on how I could solve this? | 08:28 |
| hikiko | if client and server were separate projects I wouldn | 08:29 |
| hikiko | t have to worry about that | 08:29 |
| hikiko | but now to build the server | 08:29 |
| hikiko | I need to compile the client as well | 08:29 |
| duflu | hikiko, I think you will find it's common for client+server to share a source package. And then be separate in the binary+dev packages produced | 08:30 |
| duflu | But I don't quite understand the question | 08:30 |
| hikiko | well: I added a new platform in the root CMakeLists | 08:30 |
| hikiko | called "mir" | 08:31 |
| hikiko | if I try to build from the root dir | 08:31 |
| alan_g | hikiko: if you need distinct options for the server and client then don't use a single MIR_PLATFORM variable | 08:31 |
| hikiko | alan_g, what could I do instead? | 08:32 |
| alan_g | MIR_CLIENT_PLATFORM and MIR_SERVER_PLATFORM | 08:32 |
| hikiko | :D | 08:32 |
| duflu | I don't understand the need. Mir requires client platform == server platform | 08:33 |
| hikiko | mmm but this way I have to modify both the client and the server isn't it? | 08:33 |
| hikiko | duflu, I am trying to write a nested mir | 08:33 |
| hikiko | which means I have to implement a server | 08:33 |
| hikiko | using the client lib methods | 08:33 |
| hikiko | so, I need the client to be gbm or android | 08:34 |
| hikiko | depending on the machine | 08:34 |
| hikiko | and the server to be mir | 08:34 |
| duflu | Umm, there's no such thing as "client platform" is there? It just uses whatever "platform" the local server is | 08:34 |
| hikiko | yes | 08:34 |
| duflu | so MIR_PLATFORM means MIR_SERVER_PLATFORM | 08:34 |
| hikiko | in my case yes | 08:34 |
| duflu | which is "x11" now or something? :) | 08:34 |
| hikiko | no no | 08:34 |
| duflu | or SDL | 08:35 |
| hikiko | it's not that task anymore duflu :) | 08:35 |
| hikiko | it's not the mir on X | 08:35 |
| duflu | Oh, properly nested. | 08:35 |
| hikiko | yes :) | 08:35 |
| duflu | Yes, MIR_PLATFORM=mir | 08:35 |
| duflu | Hmm | 08:35 |
| alan_g | hikiko: AIUI you actually don't want to use the client libs in the server, you want to use the host client libs | 08:35 |
| hikiko | I think what alan_g said is the best solution | 08:35 |
| hikiko | oh | 08:36 |
| hikiko | so alan_g | 08:36 |
| hikiko | I don't have to link with the client | 08:36 |
| duflu | I still don't think MIR_CLIENT_PLATFORM makes sense | 08:36 |
| hikiko | but with libmirclient installed in the system? | 08:36 |
| alan_g | duflu: +1 | 08:36 |
| duflu | Mir clients will "just work". They're not compiled for a "platform" | 08:36 |
| alan_g | hikiko: yes | 08:36 |
| hikiko | so in the client I can just add an empty mir platform | 08:37 |
| alan_g | hikiko: only if you're not supporting any clients. ;) | 08:38 |
| hikiko | haha | 08:38 |
| hikiko | braindamage | 08:38 |
| hikiko | let me think it again :) | 08:38 |
| duflu | I'm confused. But it would be nice to not have this confusion later at MP time | 08:39 |
| hikiko | if I link with the system mirclient and I have a server-side platform the nested server will be the client that will use the system libmir | 08:39 |
| hikiko | and then I have to do a client library for that server using mir functions again | 08:40 |
| hikiko | so that the clients of the nested server | 08:40 |
| hikiko | can use the nested mir? | 08:40 |
| alan_g | yes | 08:40 |
| hikiko | cool :D | 08:40 |
| hikiko | so MIR_PLATFORM is fine :) I don't need client and server! | 08:40 |
| alan_g | because, as duflu says, the client matches the server | 08:41 |
| hikiko | so I "just" have to write 2 clients: one that does what mir server does + a connection and one that does what mir client does | 08:42 |
| duflu | The client just talks a protocol. The server could be remote if only it wasn't for efficient buffer management meaning it's local, for now | 08:42 |
| duflu | Hmm | 08:43 |
| * duflu imagines an RDP buffer implementation | 08:43 | |
| duflu | Oh, and the socket is filesystem based | 08:43 |
| * alan_g imagines duflu inventing X11 | 08:43 | |
| hikiko | LOL | 08:43 |
| * duflu regrets imagining | 08:44 | |
| duflu | I did say RDP though. That's not X11 | 08:44 |
| * alan_g doesn't let facts get in the way of a good story | 08:44 | |
| hikiko | sorry :s but I don't understand everything, I can't do what I said without implement a new type of buffers or rdp for the moment? (i mean can i do a very minimal nested display for example without doing all that?) | 08:46 |
| hikiko | :S/rdp/any protocol | 08:46 |
| hikiko | I mean can I use the protobuf and the buffers as they are? | 08:47 |
| hikiko | I am refering to that: <duflu> The client just talks a protocol. The server could be remote if only it wasn't for efficient buffer management meaning it's local, for now | 08:48 |
| duflu | hikiko: Yes you're right. I was just imagining extending Mir's power in future | 08:48 |
| hikiko | yes :) I just got comfused with this ^ before you start imagining :) cool then!! | 08:50 |
| hikiko | thank you very much both alan_g and duflu :D | 08:50 |
| === mzanetti is now known as mzanetti|lunch | ||
| === mzanetti|lunch is now known as mzanetti | ||
| === alan_g is now known as alan_g|vt | ||
| === alan_g|vt is now known as alan_g | ||
| alan_g | alf_: I've discovered that, as of this morning, if I start mir on vt1 and a couple of clients on vt2 that after I switch to vt1 and back to vt2 the clients crash. Have you seen this? | 11:45 |
| alf_ | alan_g: no | 11:49 |
| alf_ | alan_g: but I haven't tried this recently | 11:49 |
| alan_g | alf_: np (I was hoping for "yes, that is...") | 11:50 |
| * alan_g decided to go back in time... | 11:51 | |
| alan_g | ...it happens with last week's code too. Fires up a box which didn't update since last week... | 11:58 |
| alan_g | ...and on that I don't see a problem with last week's code. But when I pull head it goes boom... | 12:08 |
| * alan_g checks versions carefully: 727 works, 728 fails | 12:16 | |
| alf_ | tvoss: @not implementing snapshot ubuntu api, hmm, interesting... well the shell has access to each surface's texture but only in the (EGL) context of the compositor, i.e., in the CompositingStrategy the shell will provide to mir | 12:18 |
| tvoss | alf_, hmmm ... that's a good point. the shell is only taking a screenshot as it couldn't move around surfaces on screen | 12:20 |
| tvoss | alf_, thinking about it | 12:20 |
| alf_ | tvoss: (we can't give texture ids to the shell to use with its own EGL context, since that context comes from a different EGL display and backend (mir vs gbm)) | 12:22 |
| alf_ | tvoss: (mir vs gbm/android) | 12:22 |
| tvoss | alf_, okay, thanks for the hint | 12:23 |
| alf_ | tvoss: so we either keep the snapshot api, or the shell needs to get the snapshots as part of its compositing process | 12:24 |
| tvoss | yup, I was thinking about the latter one ... | 12:25 |
| tvoss | but let me check with Saviq, too | 12:25 |
| tvoss | alf_, in a few, though, need to finish a mail | 12:25 |
| === alan_g is now known as alan_g|lunch | ||
| alf_ | tvoss: no problem... if we drop the API I need to start thinking about what to work on next :) | 12:26 |
| tvoss | alf_, I think we need to keep it intact for the time being, just need to think it threw completely | 12:29 |
| alf_ | tvoss: "or the shell needs to get the snapshots as part of its compositing process" => "get *and draw* the snapshots...", since even in this case the shell still can't use the surface textures with its own inprocess client context | 12:57 |
| === alan_g|lunch is now known as alan_g | ||
| hikiko | another question: the MirNativeBuffer in the client library is the same thing as android and gbm buffers? or this is the MirSurface in the client? | 13:30 |
| alan_g | hikiko: yes | 13:33 |
| === alan_g is now known as alan_g|tea | ||
| racarr | Good morning! | 14:37 |
| roman2861 | Who knows abous Mir on Nexus 10? | 14:42 |
| racarr | roman2861: kdub is your best bet | 14:46 |
| racarr | My memory is that support on nexus 10 isn't that explored | 14:47 |
| === alan_g|tea is now known as alan_g | ||
| kdub | roman2861, right, there's a plan to support the nexus 10, but at the moment, there are bugs that make it unusable | 15:00 |
| roman2861 | I understood it when i tried to install Mir on tablet) But when you expect to fix bugs? | 15:02 |
| kdub | roman2861, hopefully soon, but you can track this blueprint for updates https://blueprints.launchpad.net/ubuntu/+spec/client-1307-mir-nexus10 | 15:10 |
| roman2861 | Thanks | 15:11 |
| === mmrazik is now known as mmrazik|afk | ||
| kdub | status today, trying to figure out composition bypass, cleaning up some mc:: interfaces, and opening up an ipc path for clients to request swapinterval 0/1 | 15:15 |
| alf_ | alan_g: kdub: @lp 1189443, problem is that, due to the way we handle force_client_completion through exceptions, the clients can occasionally get an error response when asking from a buffer, but they are not in a good position to handle this situation right now. Also, what does getting an error response mean? Is it a fatal error, or should the client try again? It's not clear from a client's perspective. | 15:19 |
| ubot5 | Launchpad bug 1189443 in Mir "Mir clients crash when switching VTs" [Critical,New] https://launchpad.net/bugs/1189443 | 15:19 |
| alan_g | alf_: I don't think exceptions are right when switching VT | 15:21 |
| alf_ | alan_g: kdub: Yeah, perhaps we should rethink using an exception as a reaction to force_client_completion(). | 15:22 |
| kdub | why do we force_client_completion when switching vt? | 15:22 |
| alan_g | From a client perspective failing to swap_buffer is probably severe | 15:22 |
| alf_ | kdub: to be able to stop the communicator's threads | 15:22 |
| alf_ | kdub: same situation as when shutting down, but then we start again when we resume :) | 15:23 |
| alan_g | alf_: I don't think they are the same situation | 15:23 |
| racarr | they are in the code now ;) | 15:24 |
| kdub | we could also have a different method than just 'force_client_completion' i guess | 15:24 |
| racarr | This reminds me of the | 15:24 |
| kdub | that wil retry the request instead of bouncing an error out to the clients | 15:24 |
| alf_ | alan_g: right now they are, since we stop the communicator when switching VTs | 15:24 |
| alan_g | racarr: we're discussing what should be | 15:24 |
| racarr | exception handling in swap_client_buffer in | 15:24 |
| racarr | err | 15:24 |
| racarr | acquire client buffer | 15:24 |
| racarr | in SwapperSwitcher | 15:24 |
| racarr | except in this case there is no meaningful way to propagate a "try again" flag | 15:25 |
| alan_g | alf_: kdub racarr - I knew it was better to call it "shutdown()" ;) | 15:26 |
| alan_g | "pause" shouldn't need to abort requests in progress | 15:27 |
| alan_g | (Aren't those threads blocked anyway) | 15:27 |
| alan_g | hangout? | 15:28 |
| alf_ | alan_g: in the old version it didn't, it just ensured that any requests in progress would finish in some finite time | 15:28 |
| alf_ | alan_g: sure | 15:28 |
| racarr | I am actually jumping on | 15:29 |
| racarr | unity8-mir sync now | 15:29 |
| alf_ | alan_g: (and it was called force_requests_to_complete()) | 15:29 |
| racarr | I can join you guys after, or if you want to delay a little | 15:29 |
| Saviq | racarr, alf_, hey, Gerry had to split, do you have anything I should know about or need to know something from me? or can we skip todays sync meeting? | 15:29 |
| alan_g | https://plus.google.com/hangouts/_/848de4bb9222c984f54e33476685aee9165bbfcc?hl=en-GB | 15:30 |
| alf_ | Saviq: have you talked to tvoss about the snapshot API ? | 15:30 |
| Saviq | alf_, not yet, | 15:30 |
| tvoss | alf_, not yet | 15:30 |
| * alan_g is prepared to wait to get right decision | 15:30 | |
| tvoss | Saviq, otp right now, will ping you after that | 15:30 |
| racarr | Saviq: Yes, Gerry pinged me. Um...ricmm is coming today I believe | 15:30 |
| Saviq | ok then, comign | 15:30 |
| racarr | to talk about landing the dependencies (should hopefully happen, today, tomorrow) | 15:30 |
| alf_ | Saviq: tvoss: ok, thanks | 15:31 |
| racarr | alf_: I was thinking about snapshots | 15:32 |
| racarr | we can't share the texture ID directly, but we can share the buffer | 15:32 |
| racarr | right? | 15:35 |
| racarr | The same way we would to the compositor | 15:36 |
| racarr | but it becomes kind of strange... | 15:36 |
| alf_ | racarr: buffer == gbm/android native buffer? | 16:12 |
| racarr | yes | 16:12 |
| racarr | I'm having trouble wrapping my head around exaclty what the synchronization problems are though | 16:12 |
| racarr | Done with shell sync, if anyone wants to hang out still. There are a few new things for us that we could go over too | 16:13 |
| racarr | or we can wait until tomorrow (and I will try and clarify thoughts on them today) | 16:13 |
| alf_ | racarr: also, in this case the mir egl platform would need to be able to handle those types and create egl images from them | 16:17 |
| tvoss | Saviq, ping | 16:20 |
| Saviq | tvoss, pong | 16:20 |
| racarr | alf_: Yes. That's what I was thinking | 16:20 |
| racarr | it seems like we could implement that | 16:21 |
| racarr | can we on android?!?! | 16:21 |
| alf_ | kdub: ^^ Any idea? | 16:23 |
| alf_ | kdub: Can we implement eglCreateImageKHR for the Mir EGL platform on Android? | 16:23 |
| racarr | Why can't we use the existing one on android? | 16:24 |
| racarr | XD, not trying to be contrary, just having trouble wrapping my head around it | 16:24 |
| kdub | right, i don't know that there's anything to implement | 16:24 |
| racarr | there is both the problem of hooking together the bits | 16:24 |
| racarr | but then there is the problem o | 16:24 |
| racarr | is there a synchronization | 16:25 |
| racarr | problem | 16:25 |
| racarr | I mean this is basically like a client acquiring | 16:25 |
| racarr | another clients buffer | 16:25 |
| racarr | granted an internal client | 16:25 |
| racarr | hey that's the name of an interface! | 16:25 |
| racarr | but still. | 16:25 |
| alf_ | racarr: yes, our buffer swapping scheme assumes 1 producer 1 consumer (for proper functioning) and this breaks the assumption | 16:34 |
| alf_ | racarr: we still need some kind of "peeking" functionality, but if we hand out native buffer objects it complicates things | 16:35 |
| alf_ | racarr: kdub: perhaps "EGLImage InternalClient::egl_create_image(EGLDisplay disp, EGLClientBuffer buf)" and "EGLClientBuffer Buffer::egl_client_buffer()"... it's all too hazy right now :) | 16:41 |
| * kdub doesnt really know the context we're talking about | 16:42 | |
| racarr | alf_: That is what I am thinking. | 16:42 |
| racarr | but it's too hazy for me to be 100% convinced it works | 16:42 |
| racarr | kdub: Snapshots | 16:42 |
| racarr | well not snaphots | 16:42 |
| racarr | preview | 16:42 |
| racarr | s | 16:42 |
| kdub | with android you can eglCreateImageKHR with the android native buffer type | 16:42 |
| racarr | kdub: Mm. I think the confusing bit is | 16:44 |
| racarr | if one client (i.e. the shell InternalClient) | 16:44 |
| racarr | say the dash | 16:44 |
| racarr | needs to preview an application | 16:44 |
| racarr | It has to dos omething akin to like | 16:44 |
| racarr | compositor_acquire | 16:44 |
| racarr | (I think?) | 16:44 |
| racarr | the implications of this are hazy | 16:44 |
| racarr | to me XD | 16:45 |
| racarr | maybe not to you | 16:45 |
| alf_ | racarr: probably compositor_peek(), which at least is somewhat clear to me :) | 16:45 |
| kdub | right :) | 16:45 |
| racarr | it is somehow an acquire though right because how can you know when the client is done with it | 16:46 |
| racarr | espescially if we don't glflush on buffer swap | 16:46 |
| racarr | which we can only get away with for so long :p | 16:46 |
| alf_ | racarr: right, it's more of a lock, you will need to peek/release | 16:46 |
| racarr | I have a feeling there will be something called a fence involved | 16:47 |
| racarr | XD | 16:47 |
| alf_ | racarr: kdub: What confuses me (probably because I am not familiar with Android EGL impl., is how you would create an EGLImage for the *Mir* EGLDisplay? Could you just write: eglCreateImageKHR(mir_egl_display, android_native_buffer)? | 16:49 |
| racarr | In android it's all the same EGLDisplay | 16:50 |
| kdub | right | 16:51 |
| racarr | So. I think so! | 16:51 |
| kdub | http://bazaar.launchpad.net/~mir-team/mir/trunk/view/head:/src/server/graphics/android/buffer.cpp | 16:51 |
| alf_ | racarr: kdub: ok, so only for Mesa we would need to actually implement eglCreateImageKHR for the "mir" egl platform | 16:54 |
| alf_ | racarr: kdub: ok, it's becoming a bit clearer... this could work if the access to the buffers is synced by using a peek/lock mechanism. | 16:58 |
| kdub | alf_, right, i think so | 16:59 |
| alf_ | racarr: kdub: we could even enforce this at the API level, Surface::with_latest_buffer_egl_image_do(EGLDisplay, InternalClient, std::function<void(EGLImage)>) ... we would safely create/release the image, and just guarantee that it's valid for the duration of the callback function. | 17:00 |
| racarr | that API might be difficult to use | 17:01 |
| racarr | oh | 17:02 |
| racarr | I'm not sure why I thought that | 17:02 |
| racarr | XD | 17:02 |
| alf_ | all: Have a great rest of day! | 17:02 |
| racarr | alf_: Yes. I think it makes sense. | 17:02 |
| racarr | You too! | 17:03 |
| racarr | Lets talk about this tomorrow | 17:03 |
| racarr | once its had a little time to clarify | 17:03 |
| alf_ | racarr: sure | 17:03 |
| racarr | See ya! | 17:03 |
| racarr | When does kgunn come back? | 17:11 |
| === alan_g is now known as alan_g|life | ||
| === marlinc_ is now known as marlinc | ||
| === yofel_ is now known as yofel | ||
| === racarr is now known as racarr|lunch | ||
| racarr|lunch | Happy lunch! | 18:32 |
| === racarr|lunch is now known as racarr | ||
| racarr | Anyone around with some qmake knowledge? | 20:05 |
| racarr | Now I know some qmake! | 20:48 |
| === Wellark_ is now known as Wellark | ||
| bregma | *tsk* *tsk* it seems the mir codebase is liberally sprinkled with assert() macros executing code with side effects | 22:59 |
| bregma | turns out that's always been a bad idea | 22:59 |
| racarr | It's not the best idea XD | 23:02 |
| racarr | I think most of the asserts | 23:03 |
| racarr | are more of a "TODO" | 23:03 |
| racarr | than anything else | 23:03 |
| kdub | they can be removed, i'd say | 23:04 |
| bregma | the test suite depends on them actually asserting | 23:06 |
| bregma | I have an MP forthcoming | 23:06 |
| bregma | slowly | 23:06 |
| bregma | the root of the problem is that CMake sets NDEBUG by default in the current version | 23:07 |
| racarr | Ah | 23:08 |
| racarr | thanks :) | 23:08 |
| bregma | does mir have an automerger? | 23:09 |
| racarr | yes | 23:14 |
| racarr | “Follow the Road of White Nettles for three days into the mountains, and you will come to a hermitage perched on a cliff. A learned brother dwells there who keeps copies of our client’s documentation. He will advise you on the design of the system.” | 23:26 |
| racarr | ...hahahaha | 23:26 |
| racarr | Pretty much done for today :) Will be around for a while at least at computer if I can be helpful | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!