| 01:00 |
| 01:06:24 | *** | Saving seen data "./dancer.seen" |
| 01:21:27 | desowin | the lcd power off improved runtime from 8h 21min to 9h 27min, less than an hour away from OF |
| 01:22:07 | desowin | considering we run at maximum OF can, throttling is probably going to help |
| 02:00 |
| 02:42:20 | | Quit j-r (Remote host closed the connection) |
| 03:00 |
| 03:06:25 | *** | Saving seen data "./dancer.seen" |
| 03:06:32 | | Join j-r [0] (~j-r@p2003000621560733404207fffefd0a65.dip0.t-ipconnect.de) |
| 03:34:14 | desowin | and well, I should use power instead of current for quickly checking change effectiveness |
| 03:35:22 | desowin | as current goes up when voltage drops, energy conversion efficiency at different input voltages is negligible |
| 03:37:01 | | Quit kadoban (Ping timeout: 246 seconds) |
| 04:00 |
| 04:06:11 | desowin | about time estimate, should it use the measured discharge rate, or should it use user (Rockbox firmware) entered discharge rate? |
| 04:06:30 | desowin | using measured rate, the value changes quite significantly depending on the backlight |
| 04:07:29 | desowin | so you get lower (but adequate if you won't turn backlight off) estimate that goes up when screen if off |
| 04:08:20 | desowin | so it's pretty much ideal for blind users as they can just extend the battery life by always turning off backlight |
| 05:00 |
| 05:06:28 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:06:32 | *** | No seen item changed, no save performed. |
| 07:37:58 | braewoods | desowin: why not make it a setting? |
| 07:38:38 | braewoods | the hardware is more reliable in theory but if they do a battery replacement somehow, the battery monitor / charger chip may no longer be accurate |
| 08:00 |
| 08:32:41 | desowin | well, it wouldn't help as the estimate would still go from bq27000 |
| 08:45:50 | braewoods | i see |
| 08:47:44 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 09:00 |
| 09:03:03 | braewoods | interesting. seems this quirk of whether directories are included or not depends on the archiving software. |
| 09:03:27 | braewoods | the ones we normally use do that but apparently android APKs exclude directories |
| 09:03:35 | braewoods | hm. |
| 09:06:36 | *** | No seen item changed, no save performed. |
| 09:18:19 | | Join F3l1x_10m [0] (~Al3x_10m@user/f3l1x-10m/x-3393542) |
| 10:00 |
| 10:14:34 | | Quit massiveH (Quit: Leaving) |
| 11:00 |
| 11:03:09 | | Quit ufdm_ (Quit: Leaving) |
| 11:03:22 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 11:06:39 | *** | Saving seen data "./dancer.seen" |
| 11:31:20 | | Join kadoban [0] (~kadoban@user/kadoban) |
| 11:44:26 | braewoods | i see some improvements that could be added to the rockbox FAT driver. |
| 11:44:43 | braewoods | mostly emulation of utime system call or something similar |
| 11:45:09 | braewoods | to allow manual updates of mtime and atime fields |
| 13:00 |
| 13:06:40 | *** | No seen item changed, no save performed. |
| 13:09:07 | | Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:1d24:7939:8db2:2195) |
| 13:10:03 | | Join ZincAlloy [0] (~Adium@95.90.188.174) |
| 13:19:14 | braewoods | speachy: i think i found a suitable inflate library. it clearly states "This source code is public domain." is this a problem to use in rockbox? |
| 13:19:37 | speachy | nope, PD is free-for-all |
| 13:19:47 | braewoods | thought so but i thought i'd ask |
| 13:19:59 | speachy | we should still give credit, of course. |
| 13:20:12 | braewoods | i plan to, i'm just going to strip out the parts we don't really need. |
| 13:20:31 | braewoods | it needs ~2k bytes for its internal state struct |
| 13:20:37 | braewoods | i doubt i can stack allocate that |
| 13:20:50 | braewoods | so core_alloc here i come |
| 13:21:04 | braewoods | i pick this because it's simple to integrate due to little integration with regular libc |
| 13:27:56 | speachy | oh, FYI −− Tropical Storm Elsa is projected to pretty much go straight overhead over the next 24 hours. I don't anticipate any outages but one never knows. |
| 13:30:00 | braewoods | ok |
| 13:30:57 | braewoods | speachy: btw, if we wanted to emulate utime, would it be difficult to integrate? all it does is allow manual setting of mtime and atime records or their equivalent thereof |
| 13:31:22 | speachy | don't see why it would matter. do any of our filesystems even have atime? |
| 13:31:36 | braewoods | isn't that what acctime field is? |
| 13:32:10 | braewoods | oh |
| 13:32:11 | speachy | iirc fat32 just has mtime.. |
| 13:32:34 | braewoods | the struct internally has only the date field for access |
| 13:32:37 | braewoods | lol |
| 13:33:12 | braewoods | speachy: fat.h shows fields for creation, modify, and access (very limited) |
| 13:33:24 | braewoods | to date they're only updated automatically if at all |
| 13:33:39 | speachy | the fat32 directory entry only stores last modified time & date in separate fields. |
| 13:33:46 | braewoods | indeed |
| 13:33:56 | braewoods | i'm guessing limitation of underlying FS |
| 13:34:00 | braewoods | or else it'd probably be present |
| 13:34:10 | speachy | (as in that's what is stored on-disk) |
| 13:34:31 | braewoods | yea i understand, if we emulate it obviously will be crude and not 100% |
| 13:34:42 | braewoods | we can just implement the portion we can use |
| 13:34:54 | braewoods | and use the host version where full support is available |
| 13:35:04 | speachy | so ctime = mtime, and atime can always be "now" |
| 13:35:32 | braewoods | just not sure how one would write an api for updating these |
| 13:35:40 | braewoods | the FAT driver is a bit confusing |
| 13:35:58 | speachy | heh, atime isn't used that often any more even on more capable filesystems as it incurs a substantial performance penalty. plus wears out SSDs a lot faster than is otherwise necessary |
| 13:36:22 | braewoods | it's probably why relatime and noatime are a thing |
| 13:36:49 | speachy | yep |
| 13:36:53 | braewoods | in any case i'd like to have a utime api if at all possible... just not sure how i'd do it myself |
| 13:37:09 | braewoods | it would allow me to set the timestamps of extracted files to what is in the ZIP archive |
| 13:37:52 | braewoods | i'll poke around and see what my options are for modifying only the file metadata |
| 13:38:30 | braewoods | but right now i'm focusing on inflate |
| 13:38:46 | braewoods | for reference this is the one i'm trying to adapt |
| 13:38:49 | braewoods | http://achurch.org/tinflate.c |
| 13:39:00 | braewoods | i found it through an obscure link |
| 13:40:10 | braewoods | it does break a few rockbox rules; i'll try to change the struct at least. |
| 13:40:17 | braewoods | the macros though would require a lot of rewriting |
| 13:45:02 | speachy | external code we pull in we try to modify as little as possible to make keeping it in sync easier. |
| 13:47:04 | braewoods | i could just make it follow rules on the external header and alias it internally |
| 13:47:12 | speachy | that's reasonable |
| 13:47:31 | speachy | and matches our general behavior |
| 13:53:44 | braewoods | i'm probably going to strip out their crc algorithm though since we already have one we can add |
| 13:54:52 | * | braewoods is trying to avoid duplicates of the same reusable algorithm. |
| 14:00 |
| 14:11:18 | | Quit emacsomancer (Read error: Connection reset by peer) |
| 14:12:55 | | Join emacsomancer [0] (~emacsoman@c-174-52-88-123.hsd1.ut.comcast.net) |
| 14:39:24 | | Join reductum [0] (~reductum@cpe-72-134-86-174.natsow.res.rr.com) |
| 14:39:31 | desowin | I don't get why powermgmt.c inflates the first battery voltage reading by 15 mV. It dates back to 11 Nov 2006 where I see absolutely no reason for "+ 15000" in the SVNr11507 |
| 14:39:56 | desowin | later that magic value just got scaled with the units changed |
| 14:48:40 | speachy | just enough to keep teh device from auto-powering-off? |
| 14:53:10 | desowin | maybe, but that still doesn't really answer the question "why?" |
| 14:54:37 | speachy | to prevent a boot loop cycle when the battery is really weak but charging |
| 14:55:02 | speachy | not saying that's why, but it is a scenario I've run into before |
| 14:55:32 | speachy | boost the initial reading a little prevent shutdown long enough to get some charging done |
| 15:00 |
| 15:06:41 | *** | Saving seen data "./dancer.seen" |
| 15:21:47 | _bilgus | yes^ Ive had the same issues with sansa clip_ |
| 15:22:32 | _bilgus | it brings the running average up but should pretty quickly settle towards the actual value |
| 15:24:00 | _bilgus | Ive run into at least one that has such transients that every reading gets averaged before even attempting to get a value |
| 15:27:46 | braewoods | interesting |
| 15:28:23 | braewoods | there's two main headers for deflate streams... and they both use different checksum algorithms. |
| 15:28:44 | braewoods | shouldn't be too hard to support those later but for now i just need raw deflate stream support |
| 15:31:09 | braewoods | _bilgus: is there a reason we use bmp instead of png? |
| 15:31:17 | braewoods | i'd guess simplicity |
| 15:31:22 | speachy | bingo |
| 15:31:33 | _bilgus | yep bitmaps are so easy |
| 15:31:43 | braewoods | though if we implement ZIP support we could rely on that for compression if we wanted to |
| 15:31:49 | braewoods | for loading files |
| 15:32:27 | _bilgus | I'd hazard a guess that it would not help anything |
| 15:32:36 | braewoods | perhaps so |
| 15:33:09 | _bilgus | you would still be utilizing it as a bitmap in the image buffer |
| 15:33:52 | _bilgus | now maybe to store the compressed version in ram and load it to the buffer through the decompression maybe? |
| 15:34:44 | _bilgus | but how much space are we talking here enough to justify having a decoder sitting in ram |
| 15:37:03 | braewoods | no idea. |
| 15:37:13 | | Join Maxdamantus [0] (~Maxdamant@user/maxdamantus) |
| 15:37:32 | braewoods | in any case i'm working on adding inflate support that's pretty lightweight so we can support a large subset of zip files |
| 15:37:32 | speachy | not just decoder but the decompression overhead too |
| 15:37:35 | speachy | png isn't lightweight |
| 15:37:44 | _bilgus | just the fact we can use themes as a zip is nice |
| 15:38:14 | _bilgus | no worries about unzipping them |
| 15:38:18 | braewoods | the main mode of operation i plan to support is extraction to disk but extraction to memory can also be a thing |
| 15:38:27 | _bilgus | either is fine |
| 15:38:36 | _bilgus | space is pretty cheap |
| 15:38:49 | braewoods | but i at least need to support deflate to make this all work |
| 15:39:05 | braewoods | i'm going to omit ZLIB / GZIP header support unless we can find a reason to add it later |
| 15:39:22 | braewoods | but it'll be possible to add it to the library |
| 15:39:43 | braewoods | i mainly need raw stream processing |
| 15:40:29 | braewoods | from what i understand ZIP doesn't need those headers since it already has a checksum in its archive metadata |
| 15:42:21 | braewoods | _bilgus: how big is the typical rockbox stack? |
| 15:42:36 | _bilgus | thats what I was just about to address |
| 15:42:39 | _bilgus | lol |
| 15:42:46 | _bilgus | reading the tinflate lib |
| 15:42:58 | _bilgus | so you'd set up your thread |
| 15:43:01 | braewoods | i was planning to allocate part of it dynamically |
| 15:43:18 | _bilgus | and feed it a stack I suppose |
| 15:43:20 | braewoods | if i did, there's about 100 bytes that are stack allocated. |
| 15:44:32 | _bilgus | till it switches contexts I think every target has a default stack for threads |
| 15:45:14 | _bilgus | I'm not sure how that would work in core though |
| 15:45:35 | braewoods | it's why my zip library puts most of the heavy stuff in a core_alloc buffer |
| 15:45:50 | braewoods | i try to keep local stack usage below 60 bytes or so |
| 15:46:33 | _bilgus | well figure they all have a stack outlined in the map file but Ive no Idea how much you get of that before you blow it |
| 15:47:15 | _bilgus | I can get at least a file path on the stack in all targets |
| 15:47:21 | _bilgus | so 260 bytes |
| 15:47:49 | braewoods | yea, i chose to put the file path in my zip buffer in the core_alloced handle |
| 15:48:00 | braewoods | just to reduce stress on the stack |
| 15:49:11 | _bilgus | I think you could still alloc a thread in core |
| 15:49:27 | _bilgus | it'd also allow you to set your stack |
| 15:49:37 | braewoods | why would I want to allocate a thread for this? |
| 15:50:02 | _bilgus | then you get more control |
| 15:50:28 | _bilgus | its cooperative multi threading so you need to yield when ready |
| 15:51:39 | _bilgus | in fact you will be doing potentially long running actions |
| 15:52:05 | braewoods | i thought that's what callbacks are for |
| 15:52:42 | _bilgus | I imagine you'd be yielding there |
| 15:53:08 | _bilgus | if you don't create your thread you would be running in the main thread |
| 15:53:16 | braewoods | so i need to redesign my zip library to use threads? |
| 15:53:20 | speachy | hopefully the main thread. |
| 15:53:24 | _bilgus | so it'd still be the same diff I think just no control |
| 15:53:55 | _bilgus | well if you don't yield then it doesn't switch |
| 15:54:38 | _bilgus | so your callback would be the yield point |
| 15:54:44 | braewoods | ok. |
| 15:54:59 | _bilgus | mostlikely call yield() the do the cb |
| 15:55:04 | _bilgus | then* |
| 15:55:37 | _bilgus | I did something similar in lua |
| 15:56:05 | braewoods | i'll yield but i think it best to stick to the caller's thread otherwise |
| 15:56:44 | _bilgus | you shall find that out :) |
| 15:57:07 | _bilgus | theres a few docs that talk about it |
| 15:57:11 | braewoods | i thought threads were mainly for long running background tasks |
| 15:57:27 | braewoods | zip isn't exactly intended to be running all the time |
| 15:58:27 | | Quit ats (Quit: quieter GPU) |
| 16:00 |
| 16:00:12 | braewoods | _bilgus: what do you mean by that? lol |
| 16:00:13 | _bilgus | https://www.rockbox.org/wiki/RockboxKernel |
| 16:00:39 | _bilgus | in terms of a dap a long running task is anything than the pb buffer |
| 16:00:50 | _bilgus | longer than. |
| 16:02:56 | _bilgus | still I don't think that chnages your underlying code |
| 16:03:20 | braewoods | unless i wanted to redesign it to put most stuff on the stack |
| 16:03:22 | _bilgus | its just going to be important to the next layer so something to keep in mind |
| 16:05:43 | _bilgus | eh if you can keep it in its own buffer that seems much better |
| 16:06:21 | _bilgus | if you also set up that buffer to allow buflib to move the data then its pretty damn good |
| 16:06:41 | braewoods | _bilgus: erm... i saw the warning in comments about that. |
| 16:07:08 | braewoods | basically said don't use these with functions that yield |
| 16:07:48 | braewoods | that's why i opted for the unmovable data blocks while my zip code is running |
| 16:07:54 | _bilgus | thats a good point but I think you just have to se a mutex to do so |
| 16:08:20 | braewoods | my code is only intended to reserve memory for a brief while |
| 16:08:44 | braewoods | but it could take longer depending on the archive size |
| 16:09:26 | braewoods | i'll add some yields to my code between major phases and in each callback run |
| 16:09:48 | braewoods | i wasn't even aware how threading worked here |
| 16:09:57 | braewoods | i'm used to regular threads which require little thought |
| 16:10:17 | _bilgus | well actually regual threads require so much more thought |
| 16:10:27 | _bilgus | its just glossed over |
| 16:10:38 | _bilgus | these threads are v. simple |
| 16:10:46 | braewoods | so more like fibers? |
| 16:11:16 | braewoods | https://en.wikipedia.org/wiki/Fiber_(computer_science) |
| 16:11:28 | _bilgus | yeah I suppose from what I remember of them they weren't great either |
| 16:12:02 | _bilgus | yes in that definition exactly |
| 16:12:09 | speachy | it has occurred to me that since we no longer care about the really-limited sh parts, we could go to a full preemptible RTOS if we really wanted. |
| 16:12:15 | _bilgus | but the fibers I remember were MS maybe |
| 16:15:29 | _bilgus | the coop multitasking works really well here since we control all the source |
| 16:34:27 | | Quit user890104 (Changing host) |
| 16:34:27 | | Join user890104 [0] (~Venci@freemyipod/user890104) |
| 16:34:34 | | Quit user890104 (Changing host) |
| 16:34:34 | | Join user890104 [0] (~Venci@freemyipod/fmibot) |
| 16:34:43 | | Quit user890104 (Changing host) |
| 16:34:43 | | Join user890104 [0] (~Venci@freemyipod/user890104) |
| 16:36:42 | | Join cockroach [0] (~blattodea@user/cockroach) |
| 16:37:41 | | Join ats [0] (~ats@cartman.offog.org) |
| 17:00 |
| 17:03:01 | | Quit yosafbridge (Ping timeout: 265 seconds) |
| 17:04:27 | | Join yosafbridge [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de) |
| 17:06:42 | *** | Saving seen data "./dancer.seen" |
| 17:15:18 | | Quit speachy (Quit: WeeChat 3.0.1) |
| 17:15:32 | | Join speachy [0] (~speachy@209.2.65.77) |
| 17:15:32 | Mode | "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) |
| 17:22:01 | | Quit speachy (Changing host) |
| 17:22:01 | | Join speachy [0] (~speachy@rockbox/speachy) |
| 17:22:01 | Mode | "#rockbox +v speachy" by osmium.libera.chat |
| 17:25:14 | speachy | ok, cloaks are available. please let me know what you'd like. |
| 17:26:22 | | Part speachy (WeeChat 3.0.1) |
| 17:26:25 | | Join speachy [0] (~speachy@rockbox/speachy) |
| 17:26:26 | Mode | "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) |
| 17:44:36 | | Quit lebellium (Quit: Leaving) |
| 17:51:09 | | Quit ZincAlloy (Quit: Leaving.) |
| 19:00 |
| 19:06:44 | *** | Saving seen data "./dancer.seen" |
| 19:45:15 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 21:00 |
| 21:06:48 | *** | No seen item changed, no save performed. |
| 21:23:53 | | Quit cockroach (Quit: leaving) |
| 23:00 |
| 23:06:52 | *** | Saving seen data "./dancer.seen" |
| 23:31:38 | | Quit dconrad () |
icon identifies that the person is a core developer (has commit access).