[16:46] Keybuk: around? [16:47] yup [16:47] Keybuk: could you commit your tweaks to the cursored foreach safe? [16:48] GStreamer is painful, partially thanks to GObject OO, which causes the equivalent of [16:48] end [16:48] class Foo [16:48] to be, like, 100 lines of code. [16:48] ion_: yes. GObject hurts [16:49] ion_: Gstreamer is alright in some other languages. Ruby has bindings that seem ok, but they aren't stable enough to use [16:49] I want to write a plugin; i guess i have do it in C. [16:49] ion_: what's the plugin do? [16:51] Really gapless playback of successive songs, taking possible silence in the beginning/end of audio stream into account. (Not crossfading.) [16:51] ion_: most music players I've seen don't even get normal gapless playback right [16:51] Indeed [16:51] ion_: though that's probably possible in current gstreamer. just not done right [16:54] sadmac2: I'm not happy with it yet [16:55] Keybuk: me neither, but that's no reason to keep it out of source control :) [16:55] its less broken than head [16:56] I'm not sure that's true [16:56] there's too much potential for bugs by having the cursor in the linked list [16:56] you can no longer assume that foo->next is of the same type as foo [16:57] Keybuk: which is why we need to get rid of foo->next [16:57] in code outside the libs [16:57] NIH_LIST_NEXT() [16:57] I disagree [16:57] it makes other code too inefficient [16:58] Keybuk: we're running out of options [16:59] Keybuk: I've already tried non linked list data structures, and we get similar issues [16:59] Keybuk: any other solutin is going to make list_head bigger. We need information to do this [17:00] I suspect it's not a problem anyway [17:00] since the cursor is of the same size as the list head [17:02] Keybuk: which is not a problem? [17:03] right [17:04] I don't think the kinds of uses for which you would iterate a linked list are the same as those you'd expect the next element to be of a particular size [17:06] Keybuk: we use tne next pointer quite a bit in the test cases for init, but only in a couple places in the actual software [17:06] right [17:06] and in the test cases, we always check the size ;) [17:06] in fact, checking the size is one of the fundamental tests [17:06] Keybuk: that's how we could find cursors. [17:07] Keybuk: we could ask nih_alloc how big the memory area is [17:07] oh, that's still a problem for stack. [17:07] nvm [17:07] wait, what does happen if you size-check a stack pointer? [17:09] size check only works if allocated with nih_alloc [17:09] you'd get a core dump probably [17:09] or invalid data [17:09] valgrind would certainly notice [17:09] figured [17:10] in almost every circumstance, you'd fail the nih_alloc assert() if you don't coredump [17:10] ok, looks like we never grab next inside the iterator in init [17:11] hoo! [17:11] we never do it in util [17:15] I think I only ever do it on a list head to get the first entry [17:16] which will only fail for a few moments between when the loop puts the cursor there and when the loop realizes the cursor's there and terminates [17:17] so until we go multithread (if we do) all is well [17:17] I'd kinda like to make libnih threadsafe one day [17:18] does it have to be today? [17:18] concurrent linked lists are a clusterfuck [17:19] and you're going to need a semaphore in list head, which means we add that extra word again [17:20] so what does that leave to figure out with the current list though? [17:21] we still need to make insert-before work [17:21] I'm not too worried about that atm [17:21] I never do it :) [17:21] ok [17:21] then we've fixed the issue :) [17:44] Testing event_pending() [17:44] BAD: wrong value for event->progress, expected 1 got 2 [17:44] at tests/test_event.c:249 (test_pending). [17:44] zsh: abort (core dumped) ./test_event [17:44] ... [17:57] Testing event_pending() [17:57] ==31387== Invalid write of size 8 [17:57] ==31387== at 0x42BC9C: nih_list_add (list.c:147) [17:57] ==31387== by 0x42C203: nih_hash_add (hash.c:179) [17:57] ==31387== by 0x405301: test_pending (test_event.c:244) [17:57] ==31387== by 0x414A61: main (test_event.c:1987) [17:57] ==31387== Address 0x7ff000558 is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes [17:57] *giggle* [18:01] that implies a cursor is getting left in the list [18:03] oh, I have something fun you can't do from an NIH_LIST_FOREACH_SAFE [18:03] return [18:04] (the list will be invalid) [18:08] well shit [18:08] that wasn't that bug though [18:09] you could fix the return thing by defining a nested function [18:10] make your own stack frame [18:10] trouble is getting the return type of the function you're in [18:40] this cursor thing causes *massive* problems [18:54] all basically summed up as: [18:55] cannot nestedly iterate the same linked list twice [19:07] Mmkay, the Finnish government has dedicated a team of ten police officers to “monitor the Internet” for “threatening content”, with a budget of a million € a year. === laga is now known as rhpot1991_laptop === rhpot1991_laptop is now known as laga [19:11] * Keybuk wonders what the Finnish government would find threatening [19:13] I’m not entirely sure, but it’s a part of a knee-jerk reaction to a school shooting, where the shooter posted some videos of himself doing target practice and behaving all macho in advance. [19:25] * Keybuk giggles [19:27] NihList __attribute__(cleanup(nih_list_destroy)) _##iter##_cursor = { &_##iter##_cursor, &_##iter##_cursor } [19:27] I think that solves the "return from the loop" issue :p [19:29] Ooh [19:40] that makes the definition just: [19:40] define NIH_LIST_FOREACH_SAFE(list, iter) \ [19:40] for (NihList _##iter __attribute__((cleanup(nih_list_destroy))) = \ [19:40] { &_##iter, &_##iter }, \ [19:40] *iter = nih_list_add_after ((list)->next, &_##iter)->prev; \ [19:40] iter != (list) && iter != &_##iter; \ [19:40] iter = nih_list_add_after (_##iter.next, &_##iter)->prev) [19:50] * Keybuk wonders [19:50] if I have an NihListCursor type [19:50] can I use [19:51] __builtin_object_size (iter, 0) == sizeof (NihListCursor) [19:51] :p === mbiebl_ is now known as mbiebl [19:54] no, because it never evaluates iter :-/ [19:54] tho it should apprently [20:08] Keybuk: also as is iter is statically allocated [20:08] Keybuk: and the object could not be a cursor and be statically allocated [20:09] Keybuk: and The object could be a list head inside of another struct. Total size equaling NihListCursor === soren_ is now known as soren