| sadmac2 | Keybuk: around? | 16:46 |
|---|---|---|
| Keybuk | yup | 16:47 |
| sadmac2 | Keybuk: could you commit your tweaks to the cursored foreach safe? | 16:47 |
| 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:48 |
| 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:49 |
| 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:51 |
| Keybuk | sadmac2: I'm not happy with it yet | 16:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| sadmac2 | Keybuk: we're running out of options | 16:58 |
| 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 | 16:59 |
| 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:00 |
| sadmac2 | Keybuk: which is not a problem? | 17:02 |
| Keybuk | right | 17:03 |
| 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:04 |
| 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:06 |
| 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:07 |
| 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:09 |
| 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:10 |
| sadmac2 | hoo! | 17:11 |
| sadmac2 | we never do it in util | 17:11 |
| Keybuk | I think I only ever do it on a list head to get the first entry | 17:15 |
| 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:16 |
| 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:17 |
| sadmac2 | does it have to be today? | 17:18 |
| sadmac2 | concurrent linked lists are a clusterfuck | 17:18 |
| sadmac2 | and you're going to need a semaphore in list head, which means we add that extra word again | 17:19 |
| sadmac2 | so what does that leave to figure out with the current list though? | 17:20 |
| 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:21 |
| 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:44 |
| 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* | 17:57 |
| Keybuk | that implies a cursor is getting left in the list | 18:01 |
| Keybuk | oh, I have something fun you can't do from an NIH_LIST_FOREACH_SAFE | 18:03 |
| Keybuk | return | 18:03 |
| Keybuk | (the list will be invalid) | 18:04 |
| sadmac | well shit | 18:08 |
| Keybuk | that wasn't that bug though | 18:08 |
| sadmac | you could fix the return thing by defining a nested function | 18:09 |
| sadmac | make your own stack frame | 18:10 |
| sadmac | trouble is getting the return type of the function you're in | 18:10 |
| Keybuk | this cursor thing causes *massive* problems | 18:40 |
| Keybuk | all basically summed up as: | 18:54 |
| Keybuk | cannot nestedly iterate the same linked list twice | 18:55 |
| 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:07 |
| === laga is now known as rhpot1991_laptop | ||
| === rhpot1991_laptop is now known as laga | ||
| * Keybuk wonders what the Finnish government would find threatening | 19:11 | |
| 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:13 |
| * Keybuk giggles | 19:25 | |
| 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:27 |
| ion_ | Ooh | 19:29 |
| 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:40 |
| * Keybuk wonders | 19:50 | |
| Keybuk | if I have an NihListCursor type | 19:50 |
| Keybuk | can I use | 19:50 |
| Keybuk | __builtin_object_size (iter, 0) == sizeof (NihListCursor) | 19:51 |
| Keybuk | :p | 19:51 |
| === mbiebl_ is now known as mbiebl | ||
| Keybuk | no, because it never evaluates iter :-/ | 19:54 |
| Keybuk | tho it should apprently | 19:54 |
| 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:08 |
| sadmac2 | Keybuk: and The object could be a list head inside of another struct. Total size equaling NihListCursor | 20:09 |
| === soren_ is now known as soren | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!