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 2024-09-05

00:10:25 Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net)
00:21:33 Quit othello7 (Ping timeout: 276 seconds)
00:26:34_bilgus_OlsroFR here is a little test of the spreading code I really don't see much difference in most cases https://onlinegdb.com/xFIsHEJr4 I'd even say the &7 one is spread better in some cases
00:28:23_bilgus_that said it adds 30 bytes and thus ending up at pretty much the original code size ;p
00:29:30_bilgus_I guess I don't really need to round it either so that should save a bit
00:32:51_bilgus_nope doesn't change the size compiler must already be on it
00:38:38 Quit dconrad (Remote host closed the connection)
00:39:11 Join dconrad [0] (~dconrad@152.117.104.217)
00:43:40 Quit dconrad (Ping timeout: 260 seconds)
01:00
01:27:37***Saving seen data "./dancer.seen"
02:00
02:40:52 Join dconrad [0] (~dconrad@152.117.104.217)
02:45:09 Quit dconrad (Ping timeout: 248 seconds)
03:00
03:27:40***Saving seen data "./dancer.seen"
03:47:27 Join advcomp2019_ [0] (~advcomp20@user/advcomp2019)
03:50:09 Quit speachy (Ping timeout: 260 seconds)
03:50:09 Quit TorC (Ping timeout: 260 seconds)
03:50:25 Join speachy [0] (~speachy@hurricane.shaftnet.org)
03:50:25 Quit speachy (Changing host)
03:50:25 Join speachy [0] (~speachy@rockbox/developer/speachy)
03:50:25Mode"#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat)
03:50:44 Quit advcomp2019__ (Ping timeout: 260 seconds)
03:50:44 Quit user890104_ (Ping timeout: 260 seconds)
03:50:51 Join user890104 [0] (~Venci@freemyipod/user890104)
03:53:39 Join TorC [0] (~Tor@fsf/member/TorC)
04:00
04:04:34 Join lebellium [0] (~lebellium@2a01cb0405d07f00d33a0da62bfc2206.ipv6.abo.wanadoo.fr)
05:00
05:04:14 Quit jacobk (Ping timeout: 260 seconds)
05:04:34 Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net)
05:27:41***Saving seen data "./dancer.seen"
07:00
07:27:42***No seen item changed, no save performed.
07:40:25 Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net)
07:53:20 Quit othello7 (Read error: Connection reset by peer)
08:00
08:26:22 Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net)
09:00
09:27:45***Saving seen data "./dancer.seen"
11:00
11:27:46***No seen item changed, no save performed.
11:46:54 Join dconrad [0] (~dconrad@152.117.104.217)
11:53:24 Quit jackie ()
11:59:25 Join jackie [0] (~jackie@banana-new.kilobyte22.de)
12:00
12:53:57 Quit dconrad (Remote host closed the connection)
13:00
13:27:50***Saving seen data "./dancer.seen"
14:00
14:25:15rb-bluebotBuild Server message: New build round started. Revision 22b05c97a3, 337 builds, 10 clients.
14:25:16rb-bluebotcodec: cRSID: check whole load address by Wolfram Sang
14:35:55rb-bluebotBuild Server message: Build round completed after 641 seconds.
14:35:57rb-bluebotBuild Server message: Revision 22b05c97a3 result: All green
15:00
15:27:52***No seen item changed, no save performed.
16:00
16:36:33 Quit jacobk (Ping timeout: 276 seconds)
17:00
17:27:54***Saving seen data "./dancer.seen"
17:31:26 Join OlsroFR [0] (~OlsroFR@user/OlsroFR)
17:33:19OlsroFR_bilgus_ I created a patch https://gerrit.rockbox.org/r/c/rockbox/+/5917 that remove the code that skew the randomness of each segments. I find it better (and it also reduces the complexity of the code) to get as much balanced segments as possible.
17:34:46OlsroFRIn my opinion, it's better to have a small code, with less variables and complexity, and be ensured that in all case it will be as much balanced as possible, rather than the idea to add to the first segments one more song to fill the extra space
17:35:34OlsroFRI thought also to allocate another 128 bits array to store randomness states about this rather that the magic value "1 & 7 != 7", but well, it's adding an un-necessary memory impact to a feature that works well as it is
17:36:11OlsroFRand having some songs free often in a playlist is also an opportunity to add some custom songs easy without having to remove something from the dynamic playlist, it's definitely not a problem in playlists that are so large
17:43:25 Quit OlsroFR (Quit: Client closed)
17:56:43 Quit lebellium (Quit: Leaving)
17:56:46 Join OlsroFR [0] (~OlsroFR@user/OlsroFR)
18:00
18:09:07 Quit baltazar (Quit: Lost terminal)
18:10:11 Quit JanC (Remote host closed the connection)
18:10:42 Join JanC [0] (~janc@user/janc)
18:12:01 Quit vup (Remote host closed the connection)
18:13:16 Join vup [0] (~~~~@46.101.193.235)
18:18:57 Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net)
18:35:44 Join dconrad [0] (~dconrad@152.117.104.217)
18:42:50 Quit OlsroFR (Quit: Client closed)
18:54:07_bilgus_well I suppose you have your own branch but being that I already did the work to free those 150 bytes and added back the code you just removed I find it annoying to have specified 2000 tracks and having 1920 filled or 1940 or 1996 rather than 2000 and its worth 112 bytes to me versus the 2k we just added
18:55:39_bilgus_going with the original code I did bothered you but its 300 bytes so I think we'll just leave it at that
19:00
19:00:33_bilgus_least suprise would be my thought here the code back to 3. whatever would have filled 2000 tracks when asked
19:10:42 Join OlsroFR [0] (~OlsroFR@user/OlsroFR)
19:27:55***Saving seen data "./dancer.seen"
19:34:19 Quit OlsroFR (Quit: Client closed)
19:46:25 Join massiveH [0] (~massiveH@2600:4040:a982:dc00:bdd9:a952:fb7f:cb2)
19:59:35 Join OlsroFR [0] (~OlsroFR@user/OlsroFR)
19:59:58OlsroFROk I will adjust the code to fill with 2000 tracks but more balanced. It will take a bit more memory
20:00
20:45:25OlsroFRhttps://gerrit.rockbox.org/r/c/rockbox/+/5917 updated
20:46:48OlsroFR_bilgus_ At the cost of some little additionnal memory, the randomness will now be balanced as much as possible between all segments. Should never happen but if there's really too much remaining space, I kept the logic to put all in the last segment, just in case, to be sure that the code will cover all possible cases
20:47:19OlsroFRFor this merge request, you will notice that I tried to be very carefull about code style
20:58:40 Quit OlsroFR (Quit: Client closed)
21:00
21:13:01 Join bilgusph [0] (~bilgusph@107.123.53.37)
21:15:34bilgusphOlsroFR the very first line i looked at didn't match the coodestyle have you every heard the phrase 'perfect is the enemy of good?' unless that patchset is better and smaller than whats here currently lets leave it at that,
21:16:14bilgusphTime to move on to other issues
21:16:25 Quit bilgusph (Client Quit)
21:27:57***Saving seen data "./dancer.seen"
21:30:10 Quit Moriar (Quit: Leaving.)
21:30:25 Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net)
21:36:51 Quit Moriar (Ping timeout: 246 seconds)
21:42:45 Quit dconrad (Remote host closed the connection)
22:00
22:21:40 Join dconrad [0] (~dconrad@152.117.104.217)
23:00
23:26:05 Quit massiveH (Quit: Leaving)
23:27:58***Saving seen data "./dancer.seen"

Previous day | Next day