Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2021-06-20

00:06:31braewoods__builtin: yea, ~ doesn't get expanded in some cases
00:07:05braewoodsusually it only gets expanded when it is the first character of an argument
00:08:18 Quit F3l1x_10m (Ping timeout: 244 seconds)
00:16:53 Quit advcomp2019 (Ping timeout: 258 seconds)
00:20:39__builtinhmm, that would be nice to fix
00:21:12__builtinwhat is the ${i#*=} syntax in
00:26:20__builtinand now I'm getting an error in running tools/scramble
00:26:33__builtinit's perror'ing a "Success" for some reason
00:27:18__builtinon tools/scramble.c:507
00:28:04__builtinwhich is happening since rockbox.bin is zero bytes long
00:30:17__builtinwhich is happening because rockbox.elf has no sections (but a valid ELF header)
00:34:31__builtinah, `make veryclean` fixed it
00:34:44__builtinjust a plain `clean` didn't cut it
01:13:25braewoodshm interesting
01:13:58braewoodsi think i'm going to expand the auto-ROLO so i can implement an alternative that may work better than direct file manipulation
01:14:10braewoodsfor MTP mode anyway
01:14:23braewoodsdepends how my ZIP code works out
01:33:43***Saving seen data "./dancer.seen"
02:12:58braewoodsoh that's an idea
02:13:21braewoodssome people like being able to play music from ZIP archives
02:13:36braewoodsi wonder how hard it'd be to treat ZIP file like a RO directory
02:29:55braewoodsthen again this is a bad idea
03:26:25 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
03:33:44***No seen item changed, no save performed.
03:39:02 Join petur [0] (
04:02:09 Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:95be:db05:d768:7e44)
04:36:58 Quit spork (Ping timeout: 244 seconds)
04:39:11 Join spork [0] (
05:17:21 Join F3l1x_10m [0] (~Al3x_10m@user/f3l1x-10m/x-3393542)
05:28:54 Quit F3l1x_10m (Ping timeout: 265 seconds)
05:33:48***Saving seen data "./dancer.seen"
05:53:54 Join F3l1x_10m [0] (~Al3x_10m@user/f3l1x-10m/x-3393542)
06:33:48rb-bluebotBuild Server message: New build round started. Revision 2ca5774cf9, 297 builds, 9 clients.
06:37:26 Quit Retr0id (Quit: Ping timeout (120 seconds))
06:38:04 Join Retr0id [0] (~Retr0id@user/retr0id)
06:47:32rb-bluebotBuild Server message: Build round completed after 824 seconds.
06:47:35rb-bluebotBuild Server message: Revision 2ca5774cf9 result: All green
06:55:08 Quit speachy (Ping timeout: 252 seconds)
07:12:43 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
07:33:51***Saving seen data "./dancer.seen"
07:37:19 Join speachy [0] (~speachy@
07:37:19Mode"#rockbox +v speachy" by ChanServ (
08:06:36 Join cockroach [0] (~blattodea@user/cockroach)
09:14:21 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
09:33:52***No seen item changed, no save performed.
11:04:10braewoods_bilgus: i think i found a way to reduce the footprint of a few bootloaders by about 250 bytes.
11:04:31braewoodsthe ones using the mi4 crc32 algorithm
11:05:30braewoodsi'm thinking of adding a smaller version of this crc algorithm because I need it for my own code
11:33:51 Quit akaWolf (Ping timeout: 265 seconds)
11:33:55***Saving seen data "./dancer.seen"
12:14:42 Join akaWolf [0] (
12:52:31 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
13:04:43 Quit _bilgus (Ping timeout: 265 seconds)
13:06:55 Join _bilgus [0] (~bilgus@
13:25:01 Quit advcomp2019 (Ping timeout: 258 seconds)
13:33:56***Saving seen data "./dancer.seen"
13:47:36 Join dconrad [0] (~dconrad@
13:49:04 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
14:29:52 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
14:43:36 Quit advcomp2019 (Ping timeout: 258 seconds)
15:18:58 Quit dconrad (Remote host closed the connection)
15:34:00***Saving seen data "./dancer.seen"
15:37:07 Join dconrad [0] (~dconrad@
15:47:30 Quit massiveH (Quit: Leaving)
15:52:26 Quit petur (Ping timeout: 265 seconds)
15:56:08 Quit cockroach (Quit: leaving)
16:04:30 Join petur [0] (
17:15:01 Quit akaWolf (Ping timeout: 258 seconds)
17:22:46 Join akaWolf [0] (
17:34:02***Saving seen data "./dancer.seen"
18:20:39 Quit wolfshappen_ (Ping timeout: 268 seconds)
18:29:33 Quit lebellium (Quit: Leaving)
18:55:35 Quit fmlatghor (Remote host closed the connection)
18:55:35 Quit petur (Remote host closed the connection)
18:55:59 Join fmlatghor [0] (~lcoogan@2601:5cd:8100:2890:9220:3aff:fe1a:350d)
19:07:26 Quit dconrad (Remote host closed the connection)
19:30:54 Join wolfshappen [0] (
19:31:39 Join dconrad [0] (~dconrad@
19:34:03***Saving seen data "./dancer.seen"
19:44:09 Quit wolfshappen (Quit: later)
19:44:29 Join wolfshappen [0] (
20:18:06 Quit dconrad (Read error: Connection reset by peer)
20:18:39 Join dconrad [0] (~dconrad@
21:30:38 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
21:34:05***Saving seen data "./dancer.seen"
21:48:59_bilgusbraewoods assuming the same output?
21:49:14braewoods_bilgus: i think so.
21:49:20braewoodsi'll have to investigate.
21:49:35braewoodsbut i noticed the crc32 function used seems identical to the one used in ZIP files
21:49:46braewoodsand there's more space optimized versions available
21:49:51braewoodssmaller lookup table
21:50:31_bilgusIIRC our initial coefficient was different
21:50:39braewoodsfor the mi4 one?
21:50:43_bilgusseed rather
21:51:05braewoodsyea, but if i can find one that works with a seed of 0 like the existing one
21:51:11braewoodsi'll try that
21:51:41braewoodsin any case i was wanting to make a reuseable version of the crc algorithm i need for ZIP
21:52:02braewoodsit's not much but in some cases every byte counts
21:52:20braewoodsi'll do some tests and see what I find
21:52:48braewoodslet me see what ports even use MI4
21:52:54braewoodsthink it's all pp
21:53:50braewoods_bilgus: i'll see if this more compact CRC algorithm is identical to the existing one
21:53:56braewoodsin terms of output
21:54:07braewoodsi found it while researching small ones
21:54:18braewoodsand i found it shares the same coefficient as the mi4 one
21:54:28braewoodsso i thought maybe this can be added as a replacement for that
21:54:39braewoodssave some space since bootloaders usually need it
21:55:06braewoodsit uses 16 byte lookup table vs 256
22:06:03 Quit advcomp2019 (Ping timeout: 265 seconds)
22:10:03 Quit dconrad (Remote host closed the connection)
22:19:52 Join dconrad [0] (~dconrad@
22:19:52_bilgusyeah trading for speed then
22:20:45braewoods_bilgus: our general crc32 algorithm already does that
22:21:13braewoods_bilgus: so, bad idea?
22:21:28braewoodsi was trying to find another source of the crc32 algorithm i need
22:22:50_bilgusIDK won't really matter as I doubt the speed difference will be noticed assuming the same output
22:23:15_bilgusyou wouldn't want to block an older bootloader from upgrade
22:24:22 Quit dconrad (Ping timeout: 258 seconds)
22:33:47braewoods_bilgus: welp, the existing mi4 is identical in algorithm. it only differs from the zip one in two ways...
22:34:06braewoodsthe starting crc value is different and the zip one xors the results with 0xffffffff
22:34:21braewoodsotherwise a lot of code we could reuse
22:35:26_bilgusis it compatible in license?
22:35:48braewoodsthe original source says it came from zlib
22:35:58braewoodsso probably, i'll see if i can found that in zlib
22:36:25braewoodsi was just testing the existing one we have in git already
22:36:37braewoodsgiven a few minor changes it produces the same crc as zip
22:37:37braewoodswith us dropping the old archos... do we need to be this stingy with space?
22:37:47braewoodshow much RAM did the archos even have?
22:38:57_bilgusthe clip, clip+ and maybe fuze v1 v2
22:39:27_bilgusthat bootloader is within 100? bytes
22:39:42braewoodsok, so leave the main crc function alone
22:39:45braewoodsgot it
22:39:50_bilgusI think I left that much last time
22:43:21 Quit j-r (Ping timeout: 268 seconds)
22:53:07braewoodsthis is what i was considering using. tinf has a space optimized version of the same algorithm. it just needs a few tweaks to act like our existing one.
22:53:22braewoodsremove the xor at the end and change the starting value
22:56:53_bilgusyeah it has like 3 less ops than our current
22:57:47 Join j-r [0] (
22:57:49braewoodsi'm just trying to give us more room to work on our bootloaders
22:57:55braewoodsthis seemed like a way to help that
23:00:39_bilgusjust lut supply the table in such a way
23:01:13braewoods_bilgus: eh?
23:01:40_bilgusthe lut can just be supplied by the caler
23:01:51braewoodsh right
23:02:33braewoodsi'm thinking of adding this other version to our existing crc32.c and call it crc32r or so since it's the reversed variant of our current polynomial
23:02:57_bilgusah I was puzzling over that on the calc just now
23:03:25braewoodswould be useful anywhere else we need the same crc32 algorithm.
23:06:54braewoodsoh wait
23:07:14braewoodsthe space savings is more significant
23:07:24braewoodsclose to 1K because it's a 4 byte element type
23:34:08***Saving seen data "./dancer.seen"
23:40:25 Join dconrad [0] (~dconrad@
23:41:50braewoods_bilgus: g#3490
23:41:53rb-bluebotGerrit review #3490 at : rockbox: add a crc32 reverse polynomial function by James Buren
23:42:05braewoodsi decided to keep the first commit simple
23:48:53 Quit dconrad ()

Previous day | Next day