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 2022-12-16

00:29:00 Quit CH23_M (Read error: Connection reset by peer)
00:29:40 Join CH23_M [0] (~CH23@revspace/participant/ch23)
01:55:39rb-bluebotBuild Server message: New build round started. Revision 28f768cb84, 303 builds, 8 clients.
01:57:09***Saving seen data "./dancer.seen"
02:18:13rb-bluebotBuild Server message: Build round completed after 1354 seconds.
02:18:15rb-bluebotBuild Server message: Revision 28f768cb84 result: All green
02:18:20rb-bluebotBuild Server message: New build round started. Revision 79e6139f56, 303 builds, 8 clients.
02:34:59rb-bluebotBuild Server message: Build round completed after 1000 seconds.
02:35:02rb-bluebotBuild Server message: Revision 79e6139f56 result: All green
02:35:07rb-bluebotBuild Server message: New build round started. Revision a6bafe51a6, 303 builds, 8 clients.
02:55:15rb-bluebotBuild Server message: Build round completed after 1208 seconds.
02:55:16rb-bluebotBuild Server message: Revision a6bafe51a6 result: All green
03:57:13***No seen item changed, no save performed.
04:38:17 Join mink [0] (~mink@2a07:3e00:81:0:7b6:4663:f93b:9fae)
05:57:16***No seen item changed, no save performed.
06:17:20 Quit CH23_M (Ping timeout: 252 seconds)
06:17:49 Join CH23_M [0] (~CH23@revspace/participant/ch23)
06:46:40 Quit CH23_M (Read error: Connection reset by peer)
06:46:59 Join CH23_M [0] (~CH23@revspace/participant/ch23)
07:06:33rb-bluebotBuild Server message: New build round started. Revision 222ff0cb14, 303 builds, 7 clients.
07:30:04rb-bluebotBuild Server message: Build round completed after 1411 seconds.
07:30:06rb-bluebotBuild Server message: Revision 222ff0cb14 result: All green
07:38:56 Join massiveH [0] (~massiveH@2600:4040:a992:a300:e9a8:115:65f7:b836)
07:57:18***Saving seen data "./dancer.seen"
08:15:27 Join _mink [0] (~mink@
08:18:14 Quit mink (Ping timeout: 255 seconds)
08:30:55rb-bluebotBuild Server message: New build round started. Revision 626be18da0, 303 builds, 7 clients.
08:51:20 Quit CH23_M (Ping timeout: 252 seconds)
08:51:41 Join CH23_M [0] (~CH23@revspace/participant/ch23)
08:55:11 Quit massiveH (Quit: Leaving)
08:56:46rb-bluebotBuild Server message: Build round completed after 1551 seconds.
08:56:48rb-bluebotBuild Server message: Revision 626be18da0 result: All green
09:05:07rb-bluebotBuild Server message: New build round started. Revision 6f54bb63fc, 303 builds, 7 clients.
09:23:08rb-bluebotBuild Server message: Build round completed after 1080 seconds.
09:23:09rb-bluebotBuild Server message: Revision 6f54bb63fc result: All green
09:57:20***Saving seen data "./dancer.seen"
10:27:11_bilgus_haas_surround is now fixed enjoy!
10:28:18_bilgus_Amachronic (logs) Sorry, I broke some of your patches I rebased and fixed the conflicts this a record for a fully green board?
11:01:50_bilgus_nah but give me a few days to make it all red again :p
11:02:25speachy...even the barely-consistent android builds haven't hiccupped
11:16:16speachyI've been too swapmed with $dayjob and $meatspace stuff to deal with the VM migration.
11:17:15speachyMade some progress on some of the ancillary stuff though; set up the necessary holes in IDS. mail forwarding, spam prevention, etc.
11:17:29speachykeepig things synched up too.
11:29:19 Quit _mink (Remote host closed the connection)
11:48:52 Quit tchan (Ping timeout: 256 seconds)
11:49:40 Join tchan [0] (
11:57:24***Saving seen data "./dancer.seen"
13:19:22 Join lebellium [0] (
13:22:03 Join mink [0] (
13:56:00 Quit mink (Remote host closed the connection)
13:57:27***Saving seen data "./dancer.seen"
14:38:19 Join bilgus_ph [0] (~bilgus_ph@
14:39:05bilgus_phSpeachy awesome on the sync part I started to go through flyspray and thought better of it after 5 or 6 in case it'd be lost
14:39:32speachynah, please keep it up.
14:39:47speachythe worst case is we'll lose 24h of changes.
14:41:35speachyunless forced on top of me I don't intend to do the VM migration until sometime around/between xmas and the new year.
14:42:23speachytrying to get ahead of $dayjob and more um, urgent things like dealing with plumbing disasters.
14:43:49bilgus_phThat's when we have plans to do everything at dayjob that we have been putting off for the last 3 months too nobody around to care what's broken then..  probably the opposite in the RB case though :p
14:59:16 Quit bilgus_ph (Quit: Connection closed)
15:57:31***Saving seen data "./dancer.seen"
17:13:31 Quit lebellium (Quit: Leaving)
17:24:41__builtinDoes anyone have some idea on how to best fix,53045.0.html?
17:25:08__builtinthe ipod video has either 32 MB or 64 MB of DRAM, detectable only at runtime
17:26:55__builtinbut plugins overlays are linked into the end of the audio buffer, while assuming 64 MB of RAM
17:28:30__builtinbut then at runtime on a 32 MB device, the loader will see that the overlay wants to be loaded into an unmapped address and die
17:28:53speachyI don't think plugin is position-independent.
17:30:07__builtinyeah, exactly - that's the issue
17:30:15__builtinI suppose I could try linking it with -fPIC
17:30:27__builtinbut that'll kill performance
17:31:12__builtinI see a couple alternatives - we can make the linker assume 32 MB instead of 64 (probably a non-starter)
17:31:36__builtinwe can ship two overlay bins, one for 32 MB and one for 64 MB, and choose between them at runtime (also fugly)
17:32:31speachywe use -fPIC on sim builds and mips android (wtf?)
17:33:59speachyanother option is to split the ipod5g into two separate builds?
17:34:33speachythat's probably the least-awful option. though I don't know how we'd tell folks to use the right one or not.
17:34:47__builtinyeah, also seems pretty involved
17:34:58__builtinand would need rbutil work
17:35:28__builtinmaybe the best route forward is to try -fPIC and see if it 1) works and 2) doesn't kill performance
17:35:29speachywell, we can't detect the difference in rbutil but adding a separate target for folks to chose between isn't the end of the world.
17:35:47speachyat least it's plugins and not codecs.
17:36:08__builtinyeah, and only plugin _overlays_
17:36:39speachyhmm, what does that actually affect? sdl stuff?
17:37:00__builtinyeah, all 3 SDL apps (quake, duke3d, wolf3d)
17:37:15__builtinand I think some others?
17:37:41__builtinalso: chessbox, goban, lua, imageviewer, and rockboy
17:39:05__builtinyeah, I think -fPIC is the least-awful option if the performance hit isn't too bad
17:41:25TrzyzetHi, PSP homebrew scene have very similar problem, first revision of the PSP has only 32MB of RAM, rest of the models has 64MB which the extra 32MB is officially used by Sony as a UMD buffer. Homebrewers mostly respect what Sony done and using 32MB allocation from first revision. I never saw rockbox code, will do that soon but I think the best solution is to do something similar to the PSP - If OS will detect extra
17:41:25Trzyzetmemory, that extra 32MB should be allocated as buffer only.
17:42:38speachywe don't have proper memory management here... I don't think we could handle a chunk missing out of the middle of the buffer
17:43:03__builtinTrzyzet: that's not a bad idea, actually - if we default to 32 MB and expand to 64 MB at compile time, it actually wouldn't be that bad
17:43:27__builtinin normal use (i.e. not loading overlay plugins), the audio buffer size could be increased to 64 MB at runtime
17:43:46__builtinwhich would maintain identical behavior to the current state
17:44:16__builtinbut when loading overlay plugins, we'd lose the high 32 MB bank
17:44:23__builtinwhich is acceptable, I think
17:44:34speachy__builtin: yeah, that seems reasonable.
17:44:41speachyleast awful solution. :)
17:45:13__builtinand if the plugin author is really desperate for memory, they could detect that case and grab the high 32 MB at runtime
17:45:26__builtin(and add it into tlsf/buflib/whatever allocator they use)
17:45:54speachywell, given the nature of the SDL plugins, those would probably greatly benefit from that extra RAM...
17:46:04__builtinnot really
17:46:12__builtinduke3d uses it as FS cache
17:46:26__builtinand quake does its own heap management
17:46:37__builtinand only wants 8 MB IIRC
17:47:17__builtinand even duke3d runs fine on 32MB, I think
17:47:59__builtinwell, actually that might not be totally true
17:48:10__builtinthe filesystem cache is only enabled for MEMORYSIZE > 32
17:49:25__builtinbut tbh it's overdue for some rework, so it could be made to handle the 32 MB case more intelligently
17:53:19__builtinthe only case where this would introduce a problem is if any plugin overlay's code exceeded 32 MB, but that's doubtful
17:57:33***Saving seen data "./dancer.seen"
18:24:03 Join bilgus_ph [0] (~bilgus_ph@
18:24:57 Join MarcAndersen [0] (~no_znepna@
18:25:51bilgus_phLet me know how -fpic works out for you if you try that route I was just debating a way to load several plugins into ram at a time and that thought arose along with compiling some to fit in a different or at least a different place in the buffer
18:26:06 Part MarcAndersen
18:29:59bilgus_phWhat I'd like to do is move some of the infrequently used routines into plugins and load them as needed you know like the tagcache routines  etc but not kick them out to run other plugins
18:32:38bilgus_phThe other option was resumable plugins but Id bet saving and restoringstate would be slow AF
18:33:47 Quit bilgus_ph (Quit: Connection closed)
18:41:44speachyI'm curious to see the size impact of -fPIC on plugins in general. Because turning that on across the board makes a lot of sense.
18:52:17 Quit SammysHP (Quit: *wuff*)
18:52:36 Join SammysHP [0] (
19:07:11 Join massiveH [0] (~massiveH@2600:4040:a992:a300:fc8e:b22c:efd8:37)
19:57:37***Saving seen data "./dancer.seen"
20:52:34 Quit CH23_M (Read error: Connection reset by peer)
20:53:25 Join CH23_M [0] (~CH23@revspace/participant/ch23)
21:49:48 Quit JanC (Read error: Connection reset by peer)
21:56:03 Join JanC [0] (~janc@user/janc)
21:57:38***Saving seen data "./dancer.seen"
22:26:46 Join chris_s [0] (
22:26:53chris_sbilgus: The tagcache seems like a pretty core feature to me. Are you sure it's infrequently used? Unless I'm misunderstanding you.
22:27:07chris_sHave to admit it, it worries me a bit to hear you say that, although I can't judge what the fallout from that would be from a performance/UX impact?
22:27:29chris_sIf anything, this could benefit from better performance. E.g., with a large library, it can take several minutes to load the database into RAM at startup, unless you disable having the dircache integrated with the database (which maybe should be offered as an option), and without the RAM cache, the performance is pretty lacking.
22:38:17hactar|antwas going to say i don't have any complaints about performance but my library is only ~11k
22:43:06chris_sIf you don't have the database loaded into RAM, you must have a higher threshold for "pain" than me, when it comes to being interrupted by UI pauses while navigating the database. :)
23:01:51 Quit Serke (Remote host closed the connection)
23:16:52 Quit chris_s (Quit: Connection closed)
23:37:11 Quit m01 (Quit: Konversation terminated.)
23:39:21 Join m01 [0] (
23:54:27_bilgus_chris_s I don't mean the whole thing I mean the ancillary functions
23:55:11_bilgus_call it a .dll instead of a plugin if you like
23:57:40***Saving seen data "./dancer.seen"

Previous day | Next day