--- Log for 05.10.120 Server: wilhelm.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 7 days and 20 hours ago 00.33.37 *** Saving seen data "./dancer.seen" 01.16.34 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) 01.21.18 Quit ZincAlloy (Ping timeout: 260 seconds) 01.29.29 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:c436:684b:28bf:595a) 01.34.11 Quit ZincAlloy (Ping timeout: 272 seconds) 01.36.30 # <_bilgus__> not sure why I hadn't thought to paste a sentinel on the buffers lua allocs from before this point 02.07.14 # _bilgus__: you mean like prepending magic bytes to know what allocated it? 02.07.35 # <_bilgus__> yeah like we do to check stack depth 02.07.49 # so make it part of the stack frame then? 02.08.00 # though i can't see that being relevant there 02.08.20 # stack and dynamic memory are different beasts... 02.08.26 # <_bilgus__> no just filling the buffer with a sentinel and later grab how much is still clean 02.09.09 # i see. so C string style sentinel? 02.09.23 # where 0 denotes the end 02.09.39 # <_bilgus__> lua doesn't do a very good job of letting you know how much memory you have free just what it has allocd currently 02.10.00 # <_bilgus__> nah no point in that just deadbeefdeadbeefdeadbeef 02.10.34 # wouldn't that be rather slow, requiring you to manually scan it every time? 02.11.31 # IOW it sounds like you'd be setting every 4 bytes to that pattern or so 02.11.44 # since i assume most of these targets have 4 byte pointers 02.12.18 # i can't see most of them using 64 bit pointers 02.12.21 # or arithmetic even 02.12.40 # <_bilgus__> its not much slower than querying the lua garbage collector about its status especially since we are doing it from c 02.12.48 # I see. 02.13.19 # <_bilgus__> that c/lua line has a lot of overhead 02.13.31 # if the maximum memory available to lua is fixed, couldn't you just find it from basic subtraction? 02.13.52 # <_bilgus__> sorta 02.14.04 # but that's not accurate enough? 02.14.20 # <_bilgus__> only problem is you don't know what lua has done with the buffer 02.14.44 # so why does that matter? 02.14.46 # <_bilgus__> it might say it has 100kb allocated but it shit on 150 kb and left blocks too small to use 02.14.55 # Oh. 02.14.57 # Fragmentation. 02.15.17 # the perils of dynamic allocatin 02.15.21 # <_bilgus__> yes lua is terrible for fragging the whole thing 02.15.32 # so you're trying to devise a method of defragging your free memory? 02.15.34 # <_bilgus__> thats why a high watermark is useful 02.16.11 # <_bilgus__> nah I've tried stuff like that but the overhead is such you are better off off loading your data and restarting lua 02.16.41 # yea. dynamic memory is a pain. 02.16.56 # convenient to use but... 02.17.44 # _bilgus__: i wonder if pool allocators could be useful 02.18.04 # though i don't know if lua is compatible with hybrid allocation strategies 02.18.17 # <_bilgus__> thats what our alloc is doing on the back end 02.19.18 # <_bilgus__> tlsf 02.19.25 # tlsf? 02.19.32 # thread local ... ? 02.19.54 # <_bilgus__> two level segregated fit 02.20.02 # ah. never heard of it. 02.20.11 # <_bilgus__> its pretty good 02.20.22 # <_bilgus__> not great but pretty good 02.20.25 # i only know of 2 things starting ith TLS 02.20.27 # with* 02.20.35 # thread local storage 02.20.41 # transport layer security 02.20.42 # lol 02.20.44 # <_bilgus__> http://www.gii.upv.es/tlsf/ 02.22.01 # i've always tried to minimize reliance on heap memory because it's better to use stack or static allocations if appropriate 02.22.23 # because of the potentially unbounded size and such 02.22.28 # err time 02.22.30 # rather 02.22.46 # but i sometimes am stuck with it because of the nature of data structures 02.24.31 # <_bilgus__> well on embedded you kinda get stuck with that but damn if it doesn't make the code so much better 02.33.41 *** Saving seen data "./dancer.seen" 02.51.13 # _bilgus__: heh. of course if you got a shitload of RAM available... these concerns seem rather moot. 02.51.27 # i usually forget about fragmentation when i have gigabytes of RAM 02.51.51 # <_bilgus__> yeah it does seem that way a lot now a days and I'm like 1GB for a text editor WTF 02.52.03 # ah, that's because of JS. 02.52.21 # <_bilgus__> no thats because of 1993 :p 02.53.09 # <_bilgus__> I just remember when a 4 megs was very expensiver 03.53.03 Quit livvy (Ping timeout: 240 seconds) 04.01.11 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 04.12.22 Quit pamaury (Ping timeout: 246 seconds) 04.33.43 *** Saving seen data "./dancer.seen" 04.59.50 Join pamaury [0] (~pamaury@maths.r-prg.net.univ-paris7.fr) 04.59.50 Quit pamaury (Changing host) 04.59.50 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 06.33.44 *** Saving seen data "./dancer.seen" 07.26.10 Join petur [0] (~petur@rockbox/developer/petur) 07.36.55 # does its internal malloc() combine adjaent freed areas? 07.37.07 # lua, I mean 07.52.40 Quit sakax (Remote host closed the connection) 08.08.53 # one thing i learned awhile ago of interest about heap allocations... 08.09.04 # the minimum allocation unit is the alignment size 08.09.13 # for most systems i use that's 8 bytes so 08.09.24 # anything less than that is wasting space 08.09.39 # the closer to a multiple of this you get the less waste 08.10.46 # also was useful when analyzing whether to store strings inline or externally 08.11.09 # really short C strings may be better off being inline to their struct if they're small 08.11.34 # <= 8 bytes 08.12.01 # otherwise... you need to allocate at least 16 bytes. 8 for the pointer and a min of 8 for the actual array 08.12.14 # so i guess it's more like length of 15 08.12.56 # assuming each string is not referenced more than once 08.18.31 # just how malloc works since it has to guarantee what it returns it suitably aligned for anything 08.18.46 # whether it's for pointers, doubles, or w/e 08.30.36 # it's worse than that, actually -- you also have the internal heap allocator per-allocation overhead. 08.33.09 # so you're really looking at a minimum of two pointers+length for overhead. 08.33.33 Join tbaxter [0] (~Adium@pool-100-34-20-58.phlapa.fios.verizon.net) 08.33.45 *** Saving seen data "./dancer.seen" 08.43.18 # _bilgus__: Ingenic fixed the DMA engine in the X1000 series; it does per-descriptor interrupts so circular, double-buffered audio operation will work. 08.45.13 # its newer mips32r2 core also has an actual priority-driven interrupt controller. Nowhere near as awesome as the ARM Cortex-M NVIC, but a vast improvement over its predecessor 08.51.30 # speachy: ah i was just looking at from the application POV. 08.51.50 # about how best to utilize available storage 08.52.03 # whether to use an array or pointer to store it 08.52.11 # rockbox is the application and the operating system, so we try to optimize the overall usage. :) 08.52.36 # for small allocations it can make more sense to inline them with a larger one 08.52.42 # is something i noticed 08.52.58 # Since I got my start in the days dinosaurs walked the earth and men wore onions on their belts (as was the fashion at the time) I've written more allocators than I care to count 08.53.51 # yep. when you have known, fixed allocation needs that don't need to beyond the scope of the immediate function... 09.15.44 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 09.32.16 Join amiconn_ [0] (jens@rockbox/developer/amiconn) 09.32.17 Nick amiconn is now known as Guest85356 (jens@rockbox/developer/amiconn) 09.32.17 Quit Guest85356 (Killed (wolfe.freenode.net (Nickname regained by services))) 09.32.17 Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn) 09.33.23 Join pixelma_ [0] (marianne@rockbox/staff/pixelma) 09.33.24 Nick pixelma is now known as Guest56388 (marianne@rockbox/staff/pixelma) 09.33.24 Nick pixelma_ is now known as pixelma (marianne@rockbox/staff/pixelma) 09.33.55 Quit Guest56388 (Ping timeout: 240 seconds) 09.46.03 Nick Oksana_ is now known as Oksana (~Wikiwide@Maemo/community/ex-council/Wikiwide) 09.48.55 # speachy: the only allocators i've written were for dynamic structs. 09.49.14 # speachy: have you ever found a use for C99 FAMs? 09.49.19 # flexible array members 09.49.32 # where the last field is an array with no specified size. 09.49.45 # it has to be dynamically allocated due to being an incomplete type 09.50.02 # I use that construct a lot, but I don't think it's commonly found in Rockbox. 09.50.21 # ok. 09.50.53 # i've rarely used it since it made resizes more expensive to perform 09.51.02 Join amiconn_ [0] (jens@rockbox/developer/amiconn) 09.51.02 Nick amiconn is now known as Guest5204 (jens@rockbox/developer/amiconn) 09.51.02 Quit Guest5204 (Killed (rajaniemi.freenode.net (Nickname regained by services))) 09.51.02 Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn) 09.51.06 # it only really made sense for fixed-size but variable allocations 09.51.14 # allocate once and don't resize. 09.51.56 # at least that was my theory anyway... 09.52.03 Join pixelma_ [0] (marianne@rockbox/staff/pixelma) 09.52.04 Nick pixelma is now known as Guest48385 (marianne@rockbox/staff/pixelma) 09.52.04 Nick pixelma_ is now known as pixelma (marianne@rockbox/staff/pixelma) 09.52.14 # if i kept the array separate the amount to resize would be less but with large enough arrays it may be enough to be irrelevant 09.52.23 # (oh, when I say "allocators" I'm referring to the likes of a malloc() implementation) 09.52.25 Quit Guest48385 (Ping timeout: 240 seconds) 09.52.34 # speachy: oh. i guess i meant constructors then. 09.52.43 # malloc wrappers or so 09.53.06 # FAMs pretty much reuqire use of dynamic allocation when they're instantiated/constructed 09.53.39 # speachy: "pretty much"? try always. they can't be used any other way. lol 09.53.39 # but the FAM structure is quite useful as an abstraction as part of an API where you don't necessarily know how many elements are in the array. 09.54.05 # the only way i could use that with the stack is if i used the non-standard alloca 09.54.35 # braewoods: there are plenty of situations where the structure and the number of elements is known at compile time. 09.55.01 # speachy: well... you'd need to create a custom type for that and you wouldn't be using a FAM anymore, no? 09.55.13 # unless you're talking about abusing type punning or so 09.55.23 # so you can just say something like struct foo = { .numelem = 5, .elem[0] = ..., .elem[1] = ... } etc 09.56.14 # you can't use sizeof(struct foo) of course 09.56.18 # direct usage of a FAM though is impossible without dynamic allocation... otherwise you need to abuse type casting from a type that can be resolved at compile time 09.56.29 # or something like that 09.57.08 # i usually tried to avoid such trickery since it can create issues 09.57.09 # an example of what I mean: https://git.shaftnet.org/cgit/selphy_print.git/tree/backend_common.h (line 261) 09.58.00 # and statically instantiated at: https://git.shaftnet.org/cgit/selphy_print.git/tree/backend_mitsu70x.c line 2337 09.58.03 # ok... that can't be statically allocated as it is... 09.58.23 # hm. 09.58.40 # (hmm, I should have made that a const struct..) 10.00.59 # I don't use that FAM element as something that can be resized. (reallocating/resizing thigns is nearly always the wrong approach anyway) 10.01.31 # speachy: i stand corrected. i just assumed it couldn't work because most structures are fixed size... 10.01.43 # i didn't know you could use it for a dynamic sized static table. 10.02.41 # If you don't know in advance how many elements are going to be needed, then yes, you'll need to dynamically allocate the structure, and you definitely can't rely on sizeof(...) :) 10.05.00 # speachy: int x <:50:>; 10.05.05 # speachy: valid C or not? :) 10.06.01 # I don't think it's valid C<=99, at least. might be valid C++ though. 10.06.15 # speachy: it's valid C. 10.06.35 # speachy: https://en.wikipedia.org/wiki/Digraphs_and_trigraphs#C 10.06.49 # a useless and esoteric feature first introduced in ANSI C 10.07.19 # can't say I've ever seen that construct before. 10.07.19 # not surprised you wouldn't know about it per say 10.07.31 # speachy: i only know about it because I read the entire ANSI C book 10.07.52 # kinda like how the 'auto' keyword is technically a keyword but virtually no one uses it 10.09.14 # i've actually considered making a macro for it 10.09.18 # #define auto __auto_type 10.09.26 # to get C++ type inference in GNU C 10.09.29 # lol 10.09.58 # speachy: how about... 10.10.03 # speachy: int x = (3, 4, 5); 10.10.08 # speachy: what value is x? 10.10.21 # 5. 10.10.25 # Correct. 10.10.42 # This is stuff i use to test beginners to C in #learnprogramming 10.10.43 # (that sort of construct is quite often used in loop evaluations 10.10.58 # there's not many places you'd want to use the comma operator 10.11.03 # not many realize it's even an operator 10.11.12 # my favorite C question is: what does '++*x++;' do? 10.11.47 # well i know *x++ increments the pointer not the underlying value 10.11.59 # if i had to guess 10.12.05 # though... 10.12.21 # i wouldn't know honestly. 10.12.34 # it's a trick question; the correct answer is "gaaah, don't do that!" 10.12.35 # i hate mixing dereference with ++ or -- 10.12.45 # due to how weird the precedence is 10.12.58 # i often use [0] instead of * just for my sanity if i'm doing anything complex 10.13.17 # since []s have precedence that's more intuitive 10.13.38 # to get the same with * you need to do 10.13.41 # (*x) 10.13.42 # or so 10.14.24 # the dereference is the highest precedence. 10.15.10 # speachy: eh? in my experience * is pretty low though... if it was highest I wouldn't need to use ()s 10.15.50 # ah. 10.15.53 # 2nd highest 10.15.59 # []s are in the highest group 10.16.22 # but the ++ 10.16.37 # which is why it increments the pointer prior to dereferencing 10.16.51 # but yeah, that expression is a doozey 10.17.37 # ok, another esoteric feature question 10.17.46 # what's this: int (*x)[50]; 10.18.08 # i think that's the right syntax 10.19.31 # yep it is 10.20.02 # speachy: for a more complete example: https://dpaste.com/D7JGV7MU5 10.20.18 # can you name it now? 10.21.03 # it's a pointer to a pointer. 10.21.12 # no, it's a pointer to an array. 10.21.20 # believe it or not those are different 10.21.21 # (well, arrays are pointers) 10.21.54 # arrays can be treated as pointers but that doesn't mean they are pointers. 10.21.55 # if you'd left off the * it would still be a pointer. 10.22.36 # it would just point to the first element of the array insted of pointing at the pointer to the first element of the array. 10.23.03 # pointers to arrays are a different language construct. the compiler considers them different at least. 10.23.13 # true arrays decay to pointers 10.23.18 # but this is different.. 10.23.18 # (ie; int x[50]; int *y = x ; int **z = x;) 10.23.43 # though in practice it's kinda useless 10.23.54 # no one uses the pointer to array construct 10.23.54 # as a static construct it is useless 10.23.55 # the declaration like that (`int (*x)[50]` vs `int **x') carries array type information. you can treat both objects the same way, but the compiler won't. 10.24.14 # indeed. 10.26.44 # here's one of my favorite weird constructs C99 introduced 10.26.46 # https://dpaste.com/5C78HRKR4 10.26.53 # array parameters 10.27.02 # I like static. 10.27.05 # I'm not a fan of using array types as part of an API. 10.27.07 # (in parameter context) 10.27.21 # amdj: what use does it serve? i've only ran into once in stack overflow 10.27.23 # but not in real code 10.27.50 # all APIs i've seen still do 10.27.56 # void* s, size_t n 10.27.58 # or so 10.28.12 # if you put it in your declaration (as opposed to just your definition -- if it's in the definition only, it has no effect, unless the function is internal to that compilation unit), it signals to callers that the argument must be non-null and be an array of at least that many elements. 10.28.38 # does it produce meaningful compiler messages? 10.28.44 # so e.g. static void foo(int a[static 4]) { } int main(void) { int a[] = { 1, 2, 3 }; foo(a); /* warning: callee requires at least 4 elements, only 3 passed */ } 10.29.28 # I brought this up a few weeks ago on an unrelated article 10.29.31 # https://news.ycombinator.com/item?id=24459119 10.29.31 # are you sure about that? GCC doesn't seem to warn at all. 10.29.43 # using GCC 7 10.30.12 # I only build with `clang -Weverything` (which actually does what that implies). gcc may need `-Wall -Wextra`. 10.30.23 # (which still doesn't enable all diagnostics) 10.30.42 # ... and also an appropriate -std=... 10.30.54 # clang and gcc default to C99 these days unless you have some ancient version. 10.31.00 # GCC 10 defaults to C11 I think. 10.31.43 # nothing on gcc 7 10.31.46 # i'll try Focal 10.32.57 # just uh thought the construct was useless since no warnings were ever produced 10.33.16 # yeah looks like gcc doesn't diagnose it. 10.33.17 # that's annoying. 10.33.34 # https://paste.debian.net/plainh/387d8d9d 10.33.48 *** Saving seen data "./dancer.seen" 10.34.03 # (gcc 9) 10.34.09 # 10 might do it. I don't have it. 10.34.20 # you use debian? 10.34.27 # linux mint 10.34.31 # the debian edition? 10.34.34 # no 10.34.34 # or the regular? 10.34.41 # ok. 10.34.43 # I have gcc-10 package 10.34.45 # trying that now 10.35.12 # aaron@tornado:~$ gcc-10 -Wall -Wextra -Wpedantic demo.c -o demo 10.35.12 # aaron@tornado:~$ 10.35.12 # nada. 10.35.16 # how useless. 10.35.19 Quit massiveH (Quit: Leaving) 10.35.23 # lesson learned: just use clang. 10.35.23 # weird. 10.35.40 # i still prefer gcc but for some features... 10.35.45 # it seems clang is better 10.36.00 # works even without any -W 10.36.13 # apparently -Warray-bounds works differently 10.36.15 # https://paste.debian.net/plainh/27a917b6 10.37.17 # so anyway if you write some function that iterates over an array at least n times or writes at least n elements to an array argument, declaring it [static n] signals to the compiler to diagnose when it detects that a too-small array is passed, which can compile-time catch some things that would be a run-time buffer overrun. 10.37.39 # (even across compilation units) 10.37.49 # (and without LTO) 10.38.59 # seems it was fixed... 10.39.01 # in GCC 11 10.39.04 # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584 10.39.19 # it also signals that the array argument should never be null which means the optimiser can elide a if (arg == NULL) { } branch. 10.39.32 # whether you consider this a feature or not is up to you ... 10.39.45 # i can see one obvious use... 10.39.54 # declaring what kind of pointer you're wanting 10.40.00 # in terms of 10.40.09 # number of elements and that it is non-null 10.40.16 # yes it does that. 10.40.24 # e.g., 10.40.28 # int arr[static 1] 10.40.40 # so for example as opposed to __attribute__((__nonnull__)) you can use ..... yes that instead of `int *arr' 10.40.53 # and it's standard 10.40.55 # so 10.41.01 # no extensions required 10.41.04 # well gcc and clang both support the nonnull attribute. 10.41.08 # indeed 10.41.11 # but in theory 10.41.13 # portable 10.41.18 # more portable 10.41.27 # i prefer standard features whenever possible myself 10.41.43 # if you later need to port to a different compiler 10.41.46 # it can make your life a lot easier 10.41.50 # clang supports some pretty fantastic function attributes 10.42.01 # though i can't see anyone needing to use anything besides gcc / clang 10.42.06 # especially in C land 10.42.14 # last I checked MSVC sucks at C anyway 10.42.22 # they prefer to focus on C++ 10.42.34 # isn't the current iteration of MSVC++ now an LLVM wrapper anyway? 10.42.39 # no idea 10.42.44 # if it is, why do they bother? 10.42.48 # static void foo(int a)__attribute__((__diagnose_if__(!a, "bar", "error"))); /* ... */ int main(void) { foo(NULL); } -> error: bar (compilation terminated) 10.43.03 # (clang only) 10.43.16 # backwards compatibility with their cmdline syntax and "features" 10.43.29 # speachy: have you tried C99 variadic macros? 10.43.39 # i've found them useful for replacing some types of variadic functions 10.43.46 # yep, pretty sure we use them in rockbox too 10.44.14 # i wrote a few hacks to use thm 10.44.18 # them 10.44.34 # like a macro that counts the number of variable arguments you pass 10.44.45 # it could support up to 63 arguments since the standard guarantees up to 127 10.45.51 # it was an alternative to needing a sentinel value to terminate the argument list I had turned into an array thanks to compound literals 10.46.13 # instead i could pass the size eliminating the need for sentinel values 10.46.15 # I try not to be terribly clever in my code constructs. 10.46.19 # lol 10.46.23 # i understand 10.46.29 # becasuse I'm by definition not going to be clever enough to debug them. 10.46.40 # i just thought it was impressive what you could do with the CPP 10.46.56 # how many layers of macro hacks you need to get certain stuff done 10.47.23 # gcc's preprocessor is turing complete :) 10.47.24 # P99 is amusing but i could never use it in a project. 10.47.33 # QPL is a bad license 10.48.25 Quit kugel (Ping timeout: 240 seconds) 10.48.56 # oh 10.49.00 # they've relicensed it 10.49.02 # to Apache 10.51.33 Join kugel [0] (~kugel@ip5b40d8e6.dynamic.kabel-deutschland.de) 10.51.33 Quit kugel (Changing host) 10.51.33 Join kugel [0] (~kugel@rockbox/developer/kugel) 10.53.56 # sorry, meant `int *a' in my example above. missed the * 10.54.19 # that would still work out though along with a diagnostic for converting a pointer to an integer. 10.58.13 # amdj: lol. if i use '&' to get a pointer to a scalar the array check doesn't even run. 10.59.17 # apparently pointers don't get checked 10.59.23 # only if it was an actual array 10.59.46 # yeah but that just goes back to the whole "arrays aren't actually pointers" thing 10.59.53 # indeed but in practice 11.00.06 # a pointer to a scalar is no different from an array of 1 element 11.00.29 # just amusing more than anything i guess 11.00.36 # :) 11.00.44 # to use this i'd basically have to use an array for everything 11.01.05 # which is impractical... dynamic arrays always accessed through a pointer 11.01.24 # so yea 11.01.27 # limited utility 11.01.45 # seems mainly useful for when you're writing to a fixed size array 11.01.52 # of up to a certain size 11.02.05 # i rarely need to do that 11.02.20 # no wonder i never see this in real code 11.02.45 # yeah, like, if you're writing a function to hash something, then you would want it to be e.g. [static 32] for SHA2-256. because if you pass a smaller buffer it will blow up. or run towers of hanoi. or any other undefined behaviour. so you'd want a diagnostic if you pass an unsigned char[20]. 11.05.48 Quit petur (Quit: Connection reset by beer) 11.06.08 # (if you don't get the reference: https://feross.org/gcc-ownage/ ) 11.08.23 # a lot of people don't know you can also include all the other qualifiers inside the [] as well 11.08.31 # e.g. static void foo(int a[const restrict static 5]) 11.08.47 # ... 11.08.57 # seriously? restrict isn't even valid for non-pointer types... 11.09.15 # yeah but arrays as function parameters decay to pointers as I'm sure you know. 11.09.28 # but in that context it looks like it applies to the 5 11.09.39 # normally restrict is applied to the type 11.09.44 # not inside []s 11.10.04 # for that matter almost no one uses restrict either 11.10.13 # then again i can't see many places where it's useful 11.10.20 # nah, in *practice* static void foo(int *restrict a, int *restrict b) is equivalent to static void foo(int a[restrict 1], int b[restrict 1]) 11.10.49 # I guess you could even take the 1 out. 11.11.22 # likewise static void foo(int a[const 1]) is in practice the same as static void foo(int *const a) 11.12.02 # but very few people use []s in array parameters 11.12.09 # since they decay to pointers in most contexts 11.12.15 # you just get diagnostics for the array variety if you pass other sized arrays (again going back to how the compiler treats array declarations differently to pointers) 11.12.20 # static is the only case where the compiler actually cares 11.12.28 # that i can tell 11.13.40 # magical funtime useless totally over-the-top edition: static void foo(int a[volatile const restrict static 5]) 11.13.51 # :D 11.16.44 # (if you don't believe me: https://paste.debian.net/plainh/a6cdbe79 ) 11.18.16 # yeah not every qualifier will have an effect (e.g. restrict does nothing here because there's only one function parameter anyway) but they're all legal. 11.19.47 # I guess it might be nice to get diagnostics for unused qualifiers ... 11.20.05 # _Generic is pretty fun 11.20.15 # it has potential 11.20.29 # but PITA at times... 11.20.43 # makes me feel like it was intended to be used with some kind of generated headers 11.20.56 # e.g., to simulate overloading 11.21.07 # I haven't played around with generics 11.21.27 # it basically lets you return some type of value at compile time based on the type of an expression 11.21.36 # it can be nearly anything 11.21.53 # integers (maybe mapping types to an enum) 11.22.08 # string literals too 11.22.17 # <_bilgus__> speachy lua doesn't use its own alloc it uses the implementation on device and yes pretty sure TLSF does some pooling but I'm not sure how sophisticated it is 11.22.57 # but i mainly see it used to map the type to the appropriate functions 11.23.26 # since you can use it to choose a function by name 11.23.35 # and then reconstruct the function call 11.23.41 # via macro substitution 11.28.28 Part bonfire ("Leaving") 11.52.20 Join livvy [0] (~livvy@gateway/tor-sasl/livvy) 12.01.28 # Build Server message: New build round started. Revision ef34126, 282 builds, 9 clients. 12.05.01 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de) 12.09.25 Quit ZincAlloy (Ping timeout: 240 seconds) 12.12.15 Join _bilgus_ [0] (~bilgus@2605:a000:1301:89f6:1809:d12b:b118:9706) 12.13.38 Quit _bilgus__ (Ping timeout: 256 seconds) 12.14.28 Quit pamaury (Quit: Konversation terminated!) 12.16.22 # Build Server message: Build round completed after 895 seconds. 12.16.26 # Build Server message: Revision ef34126 result: All green 12.17.56 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:7813:762c:b17e:d8ff) 12.22.43 Quit ZincAlloy (Ping timeout: 272 seconds) 12.23.11 Quit _bilgus_ (Remote host closed the connection) 12.25.08 Join _bilgus_ [0] (~bilgus@2605:a000:1301:89f6:1809:d12b:b118:9706) 12.33.49 *** Saving seen data "./dancer.seen" 12.40.43 Join MrZeus_ [0] (~MrZeus@2a02:c7f:70d0:6a00:fd9f:639a:c778:bcc1) 12.43.27 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:759a:33c4:8b4:3a09) 12.55.38 Join sakax [0] (~r0b0t@unaffiliated/r0b0t) 13.17.29 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 13.43.02 Quit logbot (Remote host closed the connection) 13.54.03 Join petur [0] (~petur@rockbox/developer/petur) 14.23.34 # The pine64 conversaion progressed further, btw. They're going to see if there's an existing case design they can purchase/reuse, and see what happens from there. 14.33.53 *** Saving seen data "./dancer.seen" 14.46.59 # <_bilgus_> cool with buttons?! 14.47.20 # wasn't explicitly stated but yes, I believe so. 14.50.05 # full conversation so far: www.shaftnet.org/~pizza/rb-p64.mbox 14.54.23 Quit asaba (Quit: Relay server offline) 14.54.46 Join asaba [0] (~asaba@103.113.159.184) 15.22.44 # <_bilgus_> sounds juicy :) 15.32.39 # I'm cautiously optimistic. The odds are good they'll be able to source a suitable case. My main concern is that we'll end up with vast overkill for a SoC. 15.34.09 # Personally I'd prefer a modern MCU with a few megs of external DRAM over a multicore Cortex-A SoC with a couple hundred megs of DRAM. Though the latter is likely to be cheaper. 15.37.16 # the overall HW design in that series of Zishan DSD players would be perfect; it only needs a couple of extra buttons and to swap that CPLD with external DRAM. 15.42.01 Nick mendelmunkis is now known as mendel_munkis (~mendelmun@65-128-170-32.mpls.qwest.net) 15.42.49 # in theory I would love to help write that port, in practice I would probably cause more bugs than I fixed. 15.42.54 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 16.07.23 Quit livvy (Ping timeout: 240 seconds) 16.18.39 Join MrZeus__ [0] (~MrZeus@2a02:c7f:70d0:6a00:fd9f:639a:c778:bcc1) 16.23.28 Join tobbez_ [0] (tobbez@sagiri.wrya.net) 16.25.55 Quit sh4 (Ping timeout: 244 seconds) 16.25.55 Quit MrZeus_ (Ping timeout: 244 seconds) 16.25.55 Quit tobbez (Ping timeout: 244 seconds) 16.25.55 Quit ecs (Ping timeout: 244 seconds) 16.25.55 Nick tobbez_ is now known as tobbez (tobbez@sagiri.wrya.net) 16.26.34 Join ecs [0] (esawady@d2evs.net) 16.30.23 Join sh4 [0] (shapeless@unaffiliated/sh4) 16.33.56 *** Saving seen data "./dancer.seen" 17.10.55 # _bilgus_: here's my rough list of desired HW features in a Rockbox DAP: http://www.shaftnet.org/~pizza/rb-wishlist.txt 17.11.11 # suggestions/corrections/alterations welcome. 17.11.44 # Speachy: the first correction is not to 404. 17.12.09 # moved into place, d'oh 17.17.43 # has there been any work on bare metal bluetooth support? 17.17.43 Quit lebellium (Quit: Leaving) 17.18.21 # no, because we have no suitable hardware platform for it. 17.19.05 # (I'd like a native X1000 port to the Rocker/X3ii/etc, after which a native BT stack port would be worth undertaking) 17.19.16 # I didn't think so. 17.22.04 # You say more than 64mb ram is wasted on a bare metal port. I once or twice hit ram exhaustion on Fuze+ 17.23.10 # ... playing games or otherwise mucking about with plugins, I presume? 17.23.29 # of course. 17.23.53 # I mean, all else being equal more is better, but these MCUs tend to use older RAM types which are physically larger and more power hungry than more modern options. 17.23.53 # I just think that a end user can be expected to use up to 128M 17.24.25 # ie double the RAM, it's going to have a noticable impact on size/price/battery life 17.26.40 # the max depends on the exact MCU and memory controller, but I think the largest SDRAM part one can get is 512MBit (ie 64MB) 17.28.16 # and if you try to shove two of 'em on there you're probably going to find it overall cheaper to use a DDR-capable "full CPU" SoC. 17.29.25 # maybe I'm wrong. I don't know too many people who use rockbox and my build is heavily modified so something could have been sucking ram without my realizing 17.30.57 # (I'd be shocked if the X1000E that has 64MB embedded into the package costs more than a high-end STM32F7 with 64MB SDRAM) 17.33.12 # that 64MB SDRAM alone is $13.54 by itself. 17.33.51 # (whereas the same thing in DDR2 is $5.41) 17.37.20 # and what I think is the minimal STM32H7 part to drive what I'd want is $6.84. 17.38.59 # (in large quantities the prices will go down, but nearly $20 for your MCU + RAM starts you off in a shitty position. 17.39.07 # If it's actually cheaper to get a better processor why go with a lower end one? 17.39.08 Quit MrZeus__ (Read error: Connection reset by peer) 17.39.28 # (in 2500K quantities, you're looking at ~$13.50 for the pair) 17.39.55 # software complexity, lack of hardware peripherals that do what you want, etc 17.40.37 Join MrZeus__ [0] (~MrZeus@90.203.212.4) 17.40.48 # I guess I'll leave the design to people who actually have some clue what they are doing. 17.41.37 # one of the reason the ingenic parts were so widely used is they embedded the DRAM into the package, enabling smaller pincount and PCBs. 17.41.46 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 17.42.36 # we don't truly need realtime performance, but consider the overall system responsiveness of the Rocker vs the X3ii. The latter is half the raw speed yet is far more responsive and capable. 17.42.58 # (mostly due to really crappy OS integration and overhead in the former) 17.50.25 Quit sakax (Quit: Leaving) 18.00.43 # going through this exercise pretty much demonstrates that an MCU-based platform isn't economically viable. 18.01.43 # (general-purpose MCU, that is. the various ASICs like the PPs or the AS3525 technically had pretty-high-end MCUs in them..) 18.10.31 Quit ZincAlloy (Quit: Leaving.) 18.13.26 # _bilgus_: BTW, I don't know if I mentioned it but the Rocker is on its way to you. Post office said it will be there by Thursday. 18.18.37 # fwiw don't start playing the untangle game on rockbox, it's highly addictive. 18.19.24 # :) 18.24.25 Quit pamaury (Ping timeout: 240 seconds) 18.25.04 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 18.29.17 Quit petur (Quit: Leaving) 18.33.05 Quit pamaury (Ping timeout: 240 seconds) 18.33.59 *** Saving seen data "./dancer.seen" 18.54.57 # Build Server message: New build round started. Revision c6f66cf, 282 builds, 9 clients. 19.10.30 # Build Server message: Build round completed after 932 seconds. 19.10.44 # Build Server message: Revision c6f66cf result: All green 19.10.45 # Build Server message: New build round started. Revision 914114f, 282 builds, 9 clients. 19.23.50 # Build Server message: Build round completed after 786 seconds. 19.23.51 # Build Server message: Revision 914114f result: All green 19.34.08 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 19.35.23 Join fs-bluebot [0] (~fs-bluebo@55d418c6.access.ecotel.net) 19.37.24 Quit bluebrother^ (Ping timeout: 260 seconds) 19.37.25 Quit fs-bluebot_ (Ping timeout: 240 seconds) 19.41.07 # <_bilgus_> speachy I'll ask my mom to keep her eye out for it probably grab it sunday then 19.41.45 # tweaked the WPS keymap a little just now 19.42.06 # tbh the whole keymap really should be gone over. I'd intended to do that as part of the manual update 19.42.31 # but for some reason I keep getting distracted with new hardware and their bugs.. 19.49.54 # speachy: https://assets.amuniversal.com/e55eaa906d5001301d7a001dd8b71c47 19.49.55 # lol 19.50.54 # <_bilgus_> speach looks good at first glance at least hardware wise 19.56.29 # <__builtin> genevino: hehe :) 19.57.01 # <__builtin> that one and cube are my favorites 20.13.30 # * __builtin has been meaning to clean up that SDL2 port eventually 20.13.56 # <__builtin> although my free time has all but dried up recently... 20.15.31 # __builtin: what's the benefit of SDL2 port? 20.15.47 # most of the time it's used for desktop stuff so... 20.16.03 # but why would i want to use rockbox there when there's plenty of native players? 20.16.38 # <__builtin> SDL is nice to quickly port over PC software 20.16.49 # <__builtin> we have an SDL1.2 port that hosts Quake, Duke3D and Wolf3D 20.16.56 # <__builtin> but most recent stuff runs on SDL2 20.17.20 # <__builtin> (I'm specifically looking at a port of SDLPoP, a prince of persia remake) 20.17.54 # <__builtin> also, porting SDL2 was surprisingly easy because I'd already worked out most of the kinks with SDL1.2 20.19.01 # <__builtin> g#2634 if you're interested 20.19.58 # <__builtin> I've gotten SDLPoP to boot and start gameplay, but something's locking up at that point 20.22.28 # i see 20.24.11 Quit MrZeus__ (Ping timeout: 240 seconds) 20.34.02 *** Saving seen data "./dancer.seen" 20.37.12 # __builtin: what target? 20.37.25 # * braewoods paints a bullseye on the wall. 20.37.28 # "That target!" 20.37.37 # <_bilgus_> speachy re 2808 I'd as soon put it in the context menu 20.38.25 # _bilgus_: pitch adjustment is already in the context menu 20.39.19 # __builtin: well, there's your problem, you're trying to run PoP on a target that can't fight back 20.39.51 # lol 20.40.09 # <__builtin> ipod6g 20.40.24 # <__builtin> I've only really tested sdl on the 6g, too 20.40.26 # restructured the wishlist a bit, added physical sizing and more comments 20.41.00 # doesn't bluebot usually callout gerrit links? 20.41.11 # <__builtin> it's supposed to 20.41.19 # maybe it's feeling blue today 20.41.22 # wish I could find pricing info on the ingenic SoCs. 20.41.36 # bluebot hasn't called this stuff out for at least a few days now 21.39.15 # <_bilgus_> -Weeks- 21.39.44 # <_bilgus_> well going on to weeks its been a little over a week 21.41.37 Quit kugel (Ping timeout: 264 seconds) 21.44.24 Join kugel [0] (~kugel@rockbox/developer/kugel) 21.53.57 Quit CommunistWitchDr (Quit: Fuck this, I'm out) 21.55.42 Join CommunistWitchDr [0] (quassel@024-217-039-226.res.spectrum.com) 22.34.05 *** Saving seen data "./dancer.seen" 22.36.11 Quit kugel (Ping timeout: 260 seconds) 22.49.01 Join kugel [0] (~kugel@ip5b40d8e6.dynamic.kabel-deutschland.de) 22.49.01 Quit kugel (Changing host) 22.49.01 Join kugel [0] (~kugel@rockbox/developer/kugel) 22.52.13 Quit ac_laptop (Ping timeout: 260 seconds) 22.55.52 Quit kugel (Ping timeout: 246 seconds) 22.59.22 Join kugel [0] (~kugel@ip5b40d8e6.dynamic.kabel-deutschland.de) 22.59.22 Quit kugel (Changing host) 22.59.22 Join kugel [0] (~kugel@rockbox/developer/kugel) 22.59.40 # %#%#.. the Hifiwalker H2 purchase didn't go thorugh. But I found another seller that has three of 'em for only $50. 23.00.41 # (2 available now, heh.. another has a open box model for $100, and still shrinkwrapped they're easy to find for $120. 23.05.55 Quit TheSeven (Ping timeout: 240 seconds) 23.06.16 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 23.26.56 Quit kugel (Ping timeout: 258 seconds) 23.28.55 Join kugel [0] (~kugel@ip5b40d8e6.dynamic.kabel-deutschland.de) 23.28.55 Quit kugel (Changing host) 23.28.55 Join kugel [0] (~kugel@rockbox/developer/kugel) 23.29.10 Quit t0mato (Quit: Ping timeout (120 seconds)) 23.40.30 Join t0mato [0] (~t0mato@193.32.127.158)