| 00:29:00 | | Quit CH23_M (Read error: Connection reset by peer) |
| 00:29:40 | | Join CH23_M [0] (~CH23@revspace/participant/ch23) |
| 01:00 |
| 01:55:39 | rb-bluebot | Build Server message: New build round started. Revision 28f768cb84, 303 builds, 8 clients. |
| 01:57:09 | *** | Saving seen data "./dancer.seen" |
| 02:00 |
| 02:18:13 | rb-bluebot | Build Server message: Build round completed after 1354 seconds. |
| 02:18:15 | rb-bluebot | Build Server message: Revision 28f768cb84 result: All green |
| 02:18:20 | rb-bluebot | Build Server message: New build round started. Revision 79e6139f56, 303 builds, 8 clients. |
| 02:34:59 | rb-bluebot | Build Server message: Build round completed after 1000 seconds. |
| 02:35:02 | rb-bluebot | Build Server message: Revision 79e6139f56 result: All green |
| 02:35:07 | rb-bluebot | Build Server message: New build round started. Revision a6bafe51a6, 303 builds, 8 clients. |
| 02:55:15 | rb-bluebot | Build Server message: Build round completed after 1208 seconds. |
| 02:55:16 | rb-bluebot | Build Server message: Revision a6bafe51a6 result: All green |
| 03:00 |
| 03:57:13 | *** | No seen item changed, no save performed. |
| 04:00 |
| 04:38:17 | | Join mink [0] (~mink@2a07:3e00:81:0:7b6:4663:f93b:9fae) |
| 05:00 |
| 05:57:16 | *** | No seen item changed, no save performed. |
| 06:00 |
| 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:00 |
| 07:06:33 | rb-bluebot | Build Server message: New build round started. Revision 222ff0cb14, 303 builds, 7 clients. |
| 07:30:04 | rb-bluebot | Build Server message: Build round completed after 1411 seconds. |
| 07:30:06 | rb-bluebot | Build 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:00 |
| 08:15:27 | | Join _mink [0] (~mink@193.134.219.71) |
| 08:18:14 | | Quit mink (Ping timeout: 255 seconds) |
| 08:30:55 | rb-bluebot | Build 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:46 | rb-bluebot | Build Server message: Build round completed after 1551 seconds. |
| 08:56:48 | rb-bluebot | Build Server message: Revision 626be18da0 result: All green |
| 09:00 |
| 09:05:07 | rb-bluebot | Build Server message: New build round started. Revision 6f54bb63fc, 303 builds, 7 clients. |
| 09:23:08 | rb-bluebot | Build Server message: Build round completed after 1080 seconds. |
| 09:23:09 | rb-bluebot | Build Server message: Revision 6f54bb63fc result: All green |
| 09:57:20 | *** | Saving seen data "./dancer.seen" |
| 10:00 |
| 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 |
| 10:56:42 | speachy | ....is this a record for a fully green board? |
| 11:00 |
| 11:01:50 | _bilgus_ | nah but give me a few days to make it all red again :p |
| 11:02:25 | speachy | ...even the barely-consistent android builds haven't hiccupped |
| 11:16:16 | speachy | I've been too swapmed with $dayjob and $meatspace stuff to deal with the VM migration. |
| 11:17:15 | speachy | Made some progress on some of the ancillary stuff though; set up the necessary holes in IDS. mail forwarding, spam prevention, etc. |
| 11:17:29 | speachy | keepig 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] (~tchan@c-98-206-141-238.hsd1.il.comcast.net) |
| 11:57:24 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 13:19:22 | | Join lebellium [0] (~lebellium@2a01cb040109a600a11b3c8db891adf5.ipv6.abo.wanadoo.fr) |
| 13:22:03 | | Join mink [0] (~mink@125.215.164.109.static.wline.lns.sme.cust.swisscom.ch) |
| 13:56:00 | | Quit mink (Remote host closed the connection) |
| 13:57:27 | *** | Saving seen data "./dancer.seen" |
| 14:00 |
| 14:38:19 | | Join bilgus_ph [0] (~bilgus_ph@172.56.28.84) |
| 14:39:05 | bilgus_ph | Speachy 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:32 | speachy | nah, please keep it up. |
| 14:39:47 | speachy | the worst case is we'll lose 24h of changes. |
| 14:41:35 | speachy | unless 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:23 | speachy | trying to get ahead of $dayjob and more um, urgent things like dealing with plumbing disasters. |
| 14:43:49 | bilgus_ph | That'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:00 |
| 15:57:31 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:13:31 | | Quit lebellium (Quit: Leaving) |
| 17:24:41 | __builtin | Does anyone have some idea on how to best fix https://forums.rockbox.org/index.php/topic,53045.0.html? |
| 17:25:08 | __builtin | the ipod video has either 32 MB or 64 MB of DRAM, detectable only at runtime |
| 17:26:55 | __builtin | but plugins overlays are linked into the end of the audio buffer, while assuming 64 MB of RAM |
| 17:28:30 | __builtin | but 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:53 | speachy | I don't think plugin is position-independent. |
| 17:30:07 | __builtin | yeah, exactly - that's the issue |
| 17:30:15 | __builtin | I suppose I could try linking it with -fPIC |
| 17:30:20 | __builtin | s/linking/compiling |
| 17:30:27 | __builtin | but that'll kill performance |
| 17:31:12 | __builtin | I see a couple alternatives - we can make the linker assume 32 MB instead of 64 (probably a non-starter) |
| 17:31:36 | __builtin | we can ship two overlay bins, one for 32 MB and one for 64 MB, and choose between them at runtime (also fugly) |
| 17:32:31 | speachy | we use -fPIC on sim builds and mips android (wtf?) |
| 17:33:59 | speachy | another option is to split the ipod5g into two separate builds? |
| 17:34:33 | speachy | that'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 | __builtin | yeah, also seems pretty involved |
| 17:34:58 | __builtin | and would need rbutil work |
| 17:35:28 | __builtin | maybe the best route forward is to try -fPIC and see if it 1) works and 2) doesn't kill performance |
| 17:35:29 | speachy | well, 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:47 | speachy | at least it's plugins and not codecs. |
| 17:36:08 | __builtin | yeah, and only plugin _overlays_ |
| 17:36:39 | speachy | hmm, what does that actually affect? sdl stuff? |
| 17:37:00 | __builtin | yeah, all 3 SDL apps (quake, duke3d, wolf3d) |
| 17:37:15 | __builtin | and I think some others? |
| 17:37:41 | __builtin | also: chessbox, goban, lua, imageviewer, and rockboy |
| 17:39:05 | __builtin | yeah, I think -fPIC is the least-awful option if the performance hit isn't too bad |
| 17:41:25 | Trzyzet | Hi, 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:25 | Trzyzet | memory, that extra 32MB should be allocated as buffer only. |
| 17:42:38 | speachy | we 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 | __builtin | Trzyzet: 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 | __builtin | in normal use (i.e. not loading overlay plugins), the audio buffer size could be increased to 64 MB at runtime |
| 17:43:46 | __builtin | which would maintain identical behavior to the current state |
| 17:44:16 | __builtin | but when loading overlay plugins, we'd lose the high 32 MB bank |
| 17:44:23 | __builtin | which is acceptable, I think |
| 17:44:34 | speachy | __builtin: yeah, that seems reasonable. |
| 17:44:41 | speachy | least awful solution. :) |
| 17:45:13 | __builtin | and 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:54 | speachy | well, given the nature of the SDL plugins, those would probably greatly benefit from that extra RAM... |
| 17:46:04 | __builtin | not really |
| 17:46:12 | __builtin | duke3d uses it as FS cache |
| 17:46:26 | __builtin | and quake does its own heap management |
| 17:46:37 | __builtin | and only wants 8 MB IIRC |
| 17:47:17 | __builtin | and even duke3d runs fine on 32MB, I think |
| 17:47:59 | __builtin | well, actually that might not be totally true |
| 17:48:10 | __builtin | the filesystem cache is only enabled for MEMORYSIZE > 32 |
| 17:49:25 | __builtin | but tbh it's overdue for some rework, so it could be made to handle the 32 MB case more intelligently |
| 17:53:19 | __builtin | the 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:00 |
| 18:24:03 | | Join bilgus_ph [0] (~bilgus_ph@172.56.29.167) |
| 18:24:57 | | Join MarcAndersen [0] (~no_znepna@217.74.221.70) |
| 18:25:51 | bilgus_ph | Let 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:59 | bilgus_ph | What 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:38 | bilgus_ph | The 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:44 | speachy | I'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] (~SammysHP@faol.sammyshp.de) |
| 19:00 |
| 19:07:11 | | Join massiveH [0] (~massiveH@2600:4040:a992:a300:fc8e:b22c:efd8:37) |
| 19:57:37 | *** | Saving seen data "./dancer.seen" |
| 20:00 |
| 20:52:34 | | Quit CH23_M (Read error: Connection reset by peer) |
| 20:53:25 | | Join CH23_M [0] (~CH23@revspace/participant/ch23) |
| 21:00 |
| 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:00 |
| 22:26:46 | | Join chris_s [0] (~chris_s@ip-095-223-073-240.um35.pools.vodafone-ip.de) |
| 22:26:53 | chris_s | bilgus: The tagcache seems like a pretty core feature to me. Are you sure it's infrequently used? Unless I'm misunderstanding you. |
| 22:27:07 | chris_s | Have 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:29 | chris_s | If 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:17 | hactar|ant | was going to say i don't have any complaints about performance but my library is only ~11k |
| 22:43:06 | chris_s | If 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:00 |
| 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] (~quassel@vps-b172b88b.vps.ovh.net) |
| 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" |
icon identifies that the person is a core developer (has commit access).