--- Log for 01.07.121  Server: tantalum.libera.chat  Channel: #rockbox
--- Nick: rb-logbot_  Version: Dancer V4.16  Started: 3 days and 20 hours ago

01.03.54 ***     Saving seen data "./dancer.seen"
01.43.35 Quit    Piece_Maker (Read error: Connection reset by peer)
01.44.57 Join    Piece_Maker [0] (~Piece_Mak@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net)
01.57.08 Nick    JanC_ is now known as JanC (~janc@user/janc)
03.03.56 ***     Saving seen data "./dancer.seen"
03.29.38 Quit    akaWolf (Ping timeout: 252 seconds)
04.18.25 Join    akaWolf [0] (~akaWolf@akawolf.org)
05.03.58 ***     Saving seen data "./dancer.seen"
07.04.00 ***     No seen item changed, no save performed.
08.23.48 Join    massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
09.04.04 ***     No seen item changed, no save performed.
09.27.49 #       <braewoods> speachy, _bilgus: i'm considering how i should size my read buffer. i've usually done powers of 2 to date, but does that matter for rockbox? is there any benefit to it being a power of 2 at the higher level API? if rockbox is doing its own buffering it may not matter all that much...
09.31.39 #       <braewoods> i'm basically trying to write my own mini-allocation code for ZIP support to reduce waste of the provided "scratch paper"
09.31.52 #       <braewoods> basically managing my own stack from what would otherwise be a heap allocation
10.12.49 Quit    massiveH (Quit: Leaving)
10.13.18 Join    massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
10.14.46 Quit    massiveH (Client Quit)
10.15.05 Join    massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
10.15.38 Quit    massiveH (Client Quit)
10.15.57 Join    massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
10.16.07 Quit    massiveH (Client Quit)
10.17.26 #       <speachy> braewoods: size/resource use is more important than performance.  and rockbox already has its own read buffering going on, so I'd not htink there's much advantage to anythin gover 512 bytes.
11.04.08 ***     Saving seen data "./dancer.seen"
11.27.13 #       <braewoods> speachy: ok. thanks.
11.29.01 #       <f1refly> braewoods: the size of allocated buffers should not make any difference on regular hardware. it's nice to go with familiar numbers tho as it helps to think about the problem imo 
11.29.08 #       <f1refly> so i get where you're coming from
11.29.36 #       <braewoods> usually it's more about how much i have to keep in memory at once.
11.29.59 #       <braewoods> i've been using larger reads just to avoid having to write more complex parsing code
11.30.07 #       <braewoods> think like 64k or so at a time.
11.30.40 #       <braewoods> otherwise i need something more advanced to refill my ram buffer or so and that's kinda involved when the whole data chunk is small enough to fit in RAM.
11.31.04 #       <braewoods> this is all for my ZIP stuff and it's only used temporarily so not a permanent reservation
11.31.16 #       <braewoods> i'm also reusing buffers once they're done with their original purpose
11.31.53 #       <braewoods> for my ZIP support i decided to split my code into 3 phases...
11.32.23 #       <braewoods> seeks can be expensive when you're jumping all over the file so i decided to cache the data i need from the CD in one read pass so i won't need to seek back to do it while i'm processing the actual file data
11.32.36 #       <f1refly> i wrote the logic to reuse a partially read buffers content last week, avoiding it seems like a logical choice to me :)
11.32.55 #       <braewoods> ah, just a habit i developed from learning about parsers.
11.32.58 #       <f1refly> that seems very reasonable
11.33.18 #       <braewoods> i'm trying to decide how to utilize the memory best
11.33.28 #       <braewoods> and caching small data so i don't need to seek back to it is a good use for it
11.33.42 #       <braewoods> that probably will kill the ZIP performance more than anything
11.33.53 #       <f1refly> yes, it is 
11.34.29 #       <braewoods> i actually deployed a stripped down version of the CD because it has a lot of fields i don't actually need because the LF header has most of it
11.34.31 #       <f1refly> how are you going to manage what you keep at what place?
11.34.33 #       <braewoods> it's a duplicate
11.34.41 #       <f1refly> are you doing that centrally or where you use it?
11.34.49 #       <braewoods> what do you mean?
11.34.52 #       <braewoods> the memory allocation?
11.35.24 #       <braewoods> i'm taking a large memory chunk the the user of the ZIP code provides so i don't need to deal with how it should be allocated
11.35.39 #       <braewoods> instead i just chunk up the memory chunk they give me to allocate memory for my ZIP code
11.35.52 #       <braewoods> kinda like the function stack
11.36.15 #       <braewoods> it also allows me to dynamically use it so smaller entries don't use as much space
11.36.34 #       <braewoods> and i don't need to pay the regular price that usually comes with dynamic memory allocations
11.37.25 #       <f1refly> so you're putting tiny parts into your big allocated buffer, right?
11.37.35 #       <f1refly> or am i just too dumb to get it right now?
11.37.43 #       <braewoods> well let me show my code so far
11.38.07 #       <braewoods> it's not ready to be staged into rockbox but this is what i have
11.38.30 #       <braewoods> https://github.com/braewoods/rockbox/blob/microzip/firmware/common/zip.c
11.38.41 #       <braewoods> i start from the point of when the zip handle is first opened
11.38.44 #       * f1refly is clocking out of work for the day
11.39.19 #       <braewoods> i try to get an aligned pointer from the provided buffer
11.39.29 #       <braewoods> i assign that for the zip handle's own stuff
11.39.52 #       <braewoods> then i store the pointer to the remainder of the chunk for future allocations in the handle itself
11.40.06 #       <braewoods> checking if there's enough space remaining each time i need to use it
11.41.17 #       <braewoods> i thought it best to do this so i can minimize the cost and space waste normally associated with dynamic memory management
11.41.30 #       <braewoods> it also allows me to work with more kinds of memory buffers
11.41.52 #       <braewoods> since i'm planning for this to be usable in bootloaders and rockbox core
11.42.25 #       <braewoods> i'm read a lot about memory management techniques but this is honestly my first time actually trying it for myself
11.42.49 #       <braewoods> i normally just use malloc and call it a day
11.43.08 #       <braewoods> but the overhead it has makes me want to roll my own in this case
11.43.18 #       <braewoods> since rockbox has limited memory and cpu resources
11.43.24 #       <f1refly> give me a few minutes more to read into your file
11.45.10 #       <braewoods> most of my use of it doesn't need aligned access but some of it does
11.45.36 #       <braewoods> note it's still under development
11.45.47 #       <braewoods> this is like my third overhaul as i got ideas for how to improve i
11.45.50 #       <braewoods> it
11.45.58 #       <braewoods> think this is my last major revision
11.46.16 #       <braewoods> i decided i needed to more intelligently use my RAM buffers
11.46.32 #       <braewoods> instead of always using a fixed size like a moron...
11.46.36 #       <braewoods> X)
11.46.44 #       <braewoods> if this was a PC i'd do that just for simplicity but
11.46.59 #       <braewoods> i don't have gigabytes of RAM or megabytes of stack space at my disposal
11.47.24 #       <braewoods> i wanted to try to make this usable even on our lowest RAM target, around 2MB I believe
11.47.41 #       <f1refly> I think i get it now
11.47.44 #       <f1refly> looks pretty good
11.48.06 #       <braewoods> f1refly: it's based on the same principle as stack allocations
11.48.16 #       <f1refly> yes
11.48.26 #       <f1refly> i only know in theory how that works
11.48.30 #       <braewoods> which is the most efficient way to dynamically manage memory
11.48.33 #       <f1refly> never had to implement something like it before
11.48.35 #       <braewoods> but it comes with a cost
11.48.38 #       <f1refly> but your implementatino looks good
11.48.50 #       <braewoods> there's an upper limit on how much you can allocate with it
11.49.03 #       <braewoods> but it's excellent way for dynamic allocations of temporary buffers or so
11.49.17 #       <braewoods> after all in my use case all the permanent stuff is going to be handled by the user callback
11.49.29 #       <braewoods> i just need to buffer it long enough for them to do their thing
11.50.55 #       <f1refly> hmm
11.51.12 #       <f1refly> can you recommend me a book where i can learn more?
11.51.39 #       <f1refly> i develop c++ for a living but always wanted to learn more about c best practices
12.18.42 #       <braewoods> f1refly: about memory management?
12.25.46 #       <speachy> "let someone else do it"  :D
12.26.30 #       <braewoods> sometimes i think the most complex part of a libc is all the dynamic memory APIs.
12.26.38 #       <braewoods> they all have to work together
12.26.56 #       <speachy> threading
12.27.00 #       <braewoods> malloc, calloc, aligned_alloc
12.27.01 #       <speachy> that's the real mess.  
12.27.13 #       <braewoods> yea, and threading also plays a part since these have to be thread safe
12.49.13 Join    lebellium [0] (~lebellium@2a01:cb10:2e:2000:8d8d:14e6:d447:3796)
13.04.11 ***     No seen item changed, no save performed.
13.54.53 Quit    advcomp2019 (Read error: Connection reset by peer)
13.56.44 Join    advcomp2019 [0] (~advcomp20@user/advcomp2019)
15.04.12 ***     Saving seen data "./dancer.seen"
16.18.07 Quit    lebellium (Quit: Leaving)
16.28.42 Quit    rb-bluebot (Ping timeout: 268 seconds)
16.29.56 Quit    bluebrother (Ping timeout: 268 seconds)
16.31.36 Join    bluebrother [0] (~dom@55d4dc16.access.ecotel.net)
16.42.27 Join    rb-bluebot [0] (~rb-bluebo@55d4dc16.access.ecotel.net)
16.57.52 #       <_bilgus> braewoods, I'm a bit surprised the inbuilt buflib wasnt good enough TLSF
16.59.48 #       <_bilgus> eh Two-Level Segregated Fit before you think its some weird turn of phrase :p
17.00.52 #       <speachy> Thread-Local Storage?
17.00.55 #       <speachy> heh
17.04.13 ***     Saving seen data "./dancer.seen"
18.00.50 Quit    akaWolf (Ping timeout: 252 seconds)
18.33.39 Join    akaWolf [0] (~akaWolf@akawolf.org)
19.04.15 ***     Saving seen data "./dancer.seen"
19.59.24 Quit    MarcAndersen (Read error: Connection reset by peer)
21.04.18 ***     Saving seen data "./dancer.seen"
21.16.53 Join    richbridger [0] (~richbridg@213-225-32-103.nat.highway.a1.net)
21.18.01 Quit    aquijoule_ (Read error: Connection reset by peer)
21.30.12 #       <kirvesAxe> Uhh... any idea what could cause rockbox running on an AGPtek Rocker to refuse playing .ogg files under one directory tree, but playing other file types from there and all types of files from other directories without issues? :)
21.31.57 #       <kirvesAxe> (this issue appeared after the latest "take the microsd card for a spin on the PC" phase)
22.39.38 Quit    amiconn (Quit: No Ping reply in 64 seconds.)
22.40.11 Quit    j-r (Ping timeout: 244 seconds)
22.40.34 Join    j-r [0] (~j-r@p2003000621560705404207fffefd0a65.dip0.t-ipconnect.de)
22.40.47 Join    amiconn [0] (jens@p200300ea8722b300305e95fffec66ff3.dip0.t-ipconnect.de)
23.04.21 ***     Saving seen data "./dancer.seen"
23.10.50 Quit    blbro[m] (Remote host closed the connection)
23.10.53 Quit    kadoban (Read error: Connection reset by peer)
23.11.53 Join    kadoban [0] (~kadoban@user/kadoban)
23.18.00 Join    blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7)
23.29.15 Join    mendel_munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net)
23.31.10 Quit    munkis (Ping timeout: 258 seconds)
23.31.51 Nick    mendel_munkis is now known as munkis (~mendel_mu@ool-ae2cb218.dyn.optonline.net)
23.33.08 Quit    kadoban (Quit: node-irc says goodbye)
23.43.22 Quit    blbro[m] (Quit: node-irc says goodbye)