| 00:13:58 | | MrMcNuggets (MrMcNuggets) joins |
| 00:16:44 | | MrMcNugg1 quits [Ping timeout: 265 seconds] |
| 00:20:40 | | MrMcNuggets quits [Read error: Connection reset by peer] |
| 00:28:32 | | nexussfan (nexussfan) joins |
| 01:05:51 | | Bleo182600722719623455222011079 quits [Quit: The Lounge - https://thelounge.chat] |
| 01:10:57 | | Bleo182600722719623455222011079 joins |
| 02:08:30 | | Bleo182600722719623455222011079 quits [Client Quit] |
| 02:22:45 | | Bleo182600722719623455222011079 joins |
| 02:24:35 | <@arkiver> | JAA: klea: on priority, the way i see it, with the weights we have a kind of "horizontal" distribution of projects, with priority we add a vertical dimension to that too |
| 02:24:45 | <@arkiver> | it would be useful now and i think in the future too |
| 02:24:58 | <klea> | hmm, yeah, perhaps. |
| 02:25:43 | <@arkiver> | or we may end up with weights like 10000, 100, 1, 2 :P |
| 02:25:50 | <@arkiver> | (in that case it would be three priority levels |
| 02:25:52 | <@arkiver> | ) |
| 02:27:21 | <@arkiver> | we're going to allow for a check every 10 minutes on if the warrior can run the project or not. this could mean that if a warrior is banned and we know it take a certain amount of time before unbanning happens, it can switch to another project, and on a next check if it can run the previous project again, it will restart running that instead |
| 02:28:56 | | fuzzy80211 (fuzzy80211) joins |
| 02:29:26 | <@arkiver> | for example in #badapple it seems like a ban may take some time to resolve. and since the majority is already banned from #deloaderjp we could have auto_projects sorted as "(uploaderjp) -> (applediscussions) -> (telegram, instagram)" |
| 02:30:14 | <@arkiver> | if it ends up banned from uploaderjp and applediscussions, it will check every x seconds (at least 10 minutes) if first uploaderjp works again, then checks if applediscussions works again, and otherwise continue with telegram,instagram |
| 02:31:16 | <@arkiver> | let's say one is also banned from instagram we'd have chain uploaderjp->applediscussions->instagram->telegram if instagram was selected first from the lower priority level, or uploaderjp->applediscussions->telegram if instagram was not selected |
| 02:32:24 | <@arkiver> | so in a chain A->B->...->Z we'd periodically check first A again, then B, etc. and if find one of those working we cut the chain to that working one, stop what we're doing with the lower level project, and continue with the project we found working |
| 02:33:19 | <@arkiver> | and i think this can be done nicely mathemetically so that in the case of no ban anywhere, the distribution is followed again, and in the case of some ban somewhere the local distribution will aways be followed well |
| 02:34:20 | <@arkiver> | upon changed to the auto_projects JSON, we'll reevaluate the choice at the highest priority at which the distribution changed |
| 02:34:39 | <@arkiver> | (and of course "redistribute" keeping in mind the previous distribution so we minimize switching) |
| 02:56:26 | <@arkiver> | (sorry wall of text... but let me know what you think) |
| 02:56:51 | <klea> | Sounds fine, I think? |
| 02:58:22 | <@arkiver> | well, or is there something other than this priority system that could have the same or better effect? |
| 02:58:25 | <@arkiver> | klea: ^ |
| 02:58:39 | <klea> | I don't think so. |
| 03:02:48 | | michaelblob76413410836305926 quits [Ping timeout: 256 seconds] |
| 03:10:50 | | michaelblob76413410836305926 joins |
| 03:18:01 | <@arkiver> | klea: JAA: i was thinking just an extra "priority" field, like {"project":"uploaderjp","weight":1,"priority":1}, what do you think? |
| 03:18:24 | <klea> | I suppose it's fine. |
| 03:18:25 | <@arkiver> | with a missing priority interpreted as lowest priority |
| 03:42:38 | | DogsRNice joins |
| 03:48:31 | | Bleo182600722719623455222011079 quits [Client Quit] |
| 04:02:34 | | Bleo182600722719623455222011079 joins |
| 04:49:22 | | DogsRNice quits [Read error: Connection reset by peer] |
| 05:55:37 | | nexussfan quits [Remote host closed the connection] |
| 09:32:54 | | pseudorizer quits [Quit: ZNC 1.10.3 - https://znc.in] |
| 09:34:30 | | nothere_ quits [Ping timeout: 265 seconds] |
| 09:35:28 | | RedCat quits [Ping timeout: 265 seconds] |
| 09:37:37 | | pseudorizer (pseudorizer) joins |
| 10:00:26 | | Bleo182600722719623455222011079 quits [Quit: The Lounge - https://thelounge.chat] |
| 10:03:12 | | Bleo182600722719623455222011079 joins |
| 10:14:17 | | RedCat joins |
| 10:21:14 | | nothere joins |
| 10:32:18 | | RedCat quits [Ping timeout: 265 seconds] |
| 10:57:31 | | RedCat joins |
| 14:42:49 | | justauser|ttt joins |
| 16:24:01 | | TheTechRobo_ (TheTechRobo) joins |
| 16:24:38 | | ScenarioPlanet quits [Ping timeout: 256 seconds] |
| 16:24:39 | | TheTechRobo quits [Ping timeout: 265 seconds] |
| 17:12:18 | | pseudorizer quits [Quit: ZNC 1.10.3 - https://znc.in] |
| 17:22:06 | | pseudorizer (pseudorizer) joins |
| 20:28:14 | | x9fff00 (x9fff00) joins |
| 20:50:07 | | myuar quits [Quit: The Lounge - https://thelounge.chat] |
| 21:20:01 | | Muad-Dib quits [Quit: ZNC - http://znc.in] |
| 21:26:56 | | Muad-Dib joins |
| 21:51:01 | | Chris501026 quits [Ping timeout: 256 seconds] |
| 22:44:03 | | Chris501026 (Chris5010) joins |