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