| *** octavius <octavius!~octavius@190.147.93.209.dyn.plus.net> has quit IRC | 00:50 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC | 09:42 | |
| *** cesar <cesar!~cesar@2001:470:69fc:105::76c> has quit IRC | 09:42 | |
| *** underpantsgnome[ <underpantsgnome[!~tinybronc@2001:470:69fc:105::2:1af6> has quit IRC | 09:42 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC | 09:42 | |
| *** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has quit IRC | 09:42 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC | 09:42 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc | 09:48 | |
| ghostmansd | lkcl, could you, please, check 917, 918, 919 and 920? I re-allocated the budget from 917 to its children. | 10:19 |
|---|---|---|
| *** cesar <cesar!~cesar@2001:470:69fc:105::76c> has joined #libre-soc | 10:20 | |
| *** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has joined #libre-soc | 10:20 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #libre-soc | 10:20 | |
| *** psydroid <psydroid!~psydroid@user/psydroid> has joined #libre-soc | 10:20 | |
| *** underpantsgnome[ <underpantsgnome[!~tinybronc@2001:470:69fc:105::2:1af6> has joined #libre-soc | 10:20 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc | 10:21 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 11:11 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 11:44 | |
| ghostmansd | lkcl, in CR ops at https://libre-soc.org/openpower/sv/cr_ops/ | 12:18 |
| ghostmansd | How do we differ 3-bit and 5-bit? | 12:18 |
| ghostmansd | I see some explanation below, but confused what to look at in the code | 12:20 |
| lkcl | ghostmansd, please put it back | 12:22 |
| programmerjake | i'd expect you'd look at the output cr field, if it is a 5-bit field in the suffix, you can use 3-bits in the prefix, otherwise you need 5-bits in the prefix | 12:22 |
| ghostmansd | What do you mean to put it back? The tasks? | 12:22 |
| lkcl | please restore those budgets immediately. all budgets have to be exactly as they are in the RFP system | 12:22 |
| ghostmansd | Ah OK | 12:22 |
| ghostmansd | 1 sec | 12:23 |
| lkcl | we have to put in requests for authorisation to restore them | 12:23 |
| lkcl | we have to put in requests for authorisation to change them | 12:23 |
| ghostmansd | Done | 12:23 |
| ghostmansd | I thought it's OK to move budget from parent to children | 12:24 |
| ghostmansd | Sorry | 12:24 |
| programmerjake | lkcl: this is exactly what I warned you about...if you don't tell people in a way they notice they won't know to not change budgets. | 12:24 |
| ghostmansd | > i'd expect you'd look at the output cr field, if it is a 5-bit field in the suffix, you can use 3-bits in the prefix, otherwise you need 5-bits in the prefix | 12:25 |
| lkcl | it was - it's not ok for the next 3-4 weeks. | 12:25 |
| ghostmansd | This needs some explanation. I'm dealing with the prefix; should I take a look at the operand? | 12:25 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=864 - update the field to put the submitted date | 12:25 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=838 and this one | 12:26 |
| ghostmansd | done | 12:27 |
| programmerjake | re cr fields, i'll let lkcl explain, he's more familiar with that part | 12:27 |
| ghostmansd | OK, sorry, folks | 12:27 |
| ghostmansd | I didn't think that at this point even parent<->chilren relationship should be preserved as is. | 12:28 |
| ghostmansd | My apologies. | 12:28 |
| programmerjake | basically everything except stuff assigned to the "Future" milestone needs to not be modified, marking stuff paid/submitted is just about the only exception afaict | 12:30 |
| programmerjake | for budget ^ | 12:30 |
| ghostmansd | Ah OK, now it's clear | 12:31 |
| programmerjake | cr fields -- i got them backwards by mistake...the 3/5-bit naming in the prefix is referring to the size of the cr field in the suffix | 12:34 |
| ghostmansd | Everything related to CRs is really confusing. I'm dealing with the prefix and need to know whether it's 3-bit or 5-bit. But any CR operand can be either 3-bit or 5-bit, and there can be several of those. | 12:37 |
| programmerjake | the one that matters is the cr operand that is written to by the suffix instruction | 12:38 |
| programmerjake | so you have to look at the suffix instruction to know which one to use | 12:39 |
| ghostmansd | So we only look at the operand marked as destination one? | 12:41 |
| ghostmansd | d:BT, d:BF, etc.? | 12:42 |
| programmerjake | so, if the suffix is XL-form with BT, then you use the 5-bit form of the prefix, because BT is 5 bits | 12:43 |
| programmerjake | ghostmansd: yes afaict | 12:43 |
| ghostmansd | OK, cool! | 12:43 |
| ghostmansd | Thanks! | 12:43 |
| programmerjake | lkcl: can you verify we're correct? | 12:46 |
| ghostmansd | I've pushed CR ops RM with all modes except ff3/ff5. | 12:53 |
| lkcl | programmerjake, ghostmansd it's all very simple - if it's got "F" in the name it's a 3-bit CR-Field | 13:19 |
| lkcl | BF and BFA. | 13:19 |
| lkcl | those are the only two | 13:19 |
| ghostmansd | lol | 13:19 |
| lkcl | everything else is 5. | 13:19 |
| ghostmansd | considering all this weird stuff, I can pretty much guess what F stands for | 13:19 |
| lkcl | duh :) | 13:19 |
| *** octavius <octavius!~octavius@241.147.93.209.dyn.plus.net> has joined #libre-soc | 13:20 | |
| lkcl | the only other one is mfcr mtcr which is the *entire* 32-bit scalar CR register | 13:20 |
| ghostmansd | and "it's got" -- you mean the only one operand marked as destination? | 13:20 |
| ghostmansd | because there might be up to 3 operands IIRC | 13:20 |
| lkcl | but that needs dealing with in a separate way. | 13:20 |
| ghostmansd | (in these instructions) | 13:20 |
| lkcl | in the crops group? yes only 3 operands. | 13:21 |
| lkcl | as a general rule everything maxes out at 3-in 2-out. Rc=1 and XER.CA/OV/SO push that definition slightly | 13:21 |
| ghostmansd | OK, so the algorithm for ff3/ff5 is: 1) iterate through the operands and find the destination one; 2) check if it's 3-bit or 5-bit (it's 3-bit if it's in list (BF, BFA) | 13:23 |
| ghostmansd | Correct? | 13:23 |
| lkcl | yes | 13:25 |
| lkcl | btw | 13:25 |
| lkcl | ERROR:root:Budget assigned to task excluding subtasks (cf_budget field) doesn't match calculated value: bug #919, calculated value 500 | 13:26 |
| lkcl | ERROR:root:Budget assigned to task including subtasks (cf_total_budget field) doesn't match calculated value: bug #919, calculated value 500 | 13:26 |
| lkcl | ERROR:root:Budget assigned to task excluding subtasks (cf_budget field) doesn't match calculated value: bug #918, calculated value 1000 | 13:26 |
| lkcl | ERROR:root:Budget assigned to task including subtasks (cf_total_budget field) doesn't match calculated value: bug #918, calculated value 1000 | 13:26 |
| lkcl | ERROR:root:Budget assigned to task including subtasks (cf_total_budget field) doesn't match calculated value: bug #917, calculated value 4500 | 13:26 |
| lkcl | ERROR:root:Budget assigned to task including subtasks (cf_total_budget field) doesn't match calculated value: bug #254, calculated value 14000 | 13:26 |
| lkcl | ERROR:root:Budget assigned to task including subtasks (cf_total_budget field) doesn't match calculated value: bug #140, calculated value 51500 | 13:26 |
| lkcl | https://libre-soc.org/task_db/report/ | 13:26 |
| lkcl | please don't edit budgets in future | 13:26 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=917 EUR 2500 is entirely for you (for all 3 sub-sub-tasks) | 13:29 |
| lkcl | the sub-sub-tasks are far along enough that i'm happy to say "they're done" | 13:29 |
| lkcl | we're just waiting for michiel | 13:30 |
| lkcl | ok i sorted the errors. i removed the sub-sub-task budget allocations. you still get the same amount | 13:30 |
| ghostmansd | Thanks Luke | 13:32 |
| lkcl | we have to be stupidly careful with the budget system. it's audited | 13:33 |
| lkcl | like, by the EU Commission. | 13:33 |
| lkcl | if we fuck it up NLnet gets into legal trouble. | 13:33 |
| ghostmansd | Sorry, I won't ever enter the budget again. | 13:34 |
| lkcl | i approved the two bugreports | 13:34 |
| ghostmansd | That was just a stupid assumption about parent/children tasks. | 13:34 |
| lkcl | it's checked by the program called "budget-sync" (which you can run yourself) | 13:34 |
| programmerjake | in utils.git | 13:34 |
| lkcl | but there's no "rollback" - no safety net | 13:35 |
| lkcl | https://git.libre-soc.org/?p=utils.git;a=blob;f=README.txt;hb=HEAD | 13:35 |
| programmerjake | rollback -- you look at the edit history and figure out how you messed up then fix it manually | 13:36 |
| ghostmansd | sigh | 13:36 |
| ghostmansd | yet another reason to never dive into this | 13:36 |
| ghostmansd | (even the former reason is sufficient, though) | 13:36 |
| programmerjake | i wrote budget-sync because we had trouble catching errors manually | 13:37 |
| ghostmansd | Got it | 13:38 |
| programmerjake | running budget-sync is also very handy for figuring out what tasks you have yet to be paid on...it generates a handy markdown output for everyone listed in the bugzilla database | 13:39 |
| ghostmansd | lkcl, please don't yet merge anything from dis, it's under rebase | 13:39 |
| lkcl | ghostmansd, ack | 13:51 |
| lkcl | i run it frequently and upload here https://libre-soc.org/task_db/mdwn/ | 13:52 |
| * lkcl need to do the complex FSM for pack/unpack in ISACaller, now | 13:52 | |
| lkcl | funfunfun | 13:52 |
| programmerjake | reading https://www.supergoodcode.com/sp33d2/ | 14:12 |
| programmerjake | > Obviously I’m talking about optimization, the process by which a smart and talented reader of StackOverflow copies and pastes code in exactly the right sequence such that, upon resolving all compilation errors, execution of a program utilizes fewer resources. | 14:13 |
| programmerjake | XD | 14:13 |
| ghostmansd | lol | 14:15 |
| ghostmansd | OK I think I completed both CR and Branch | 14:15 |
| ghostmansd | I tested CR operands check with a hack -- I temporary assigned prefix for crand to ((1 << 24) - 1). | 14:16 |
| ghostmansd | In other words, totally cheated. | 14:16 |
| programmerjake | that article is filled with more gems like that :) | 14:16 |
| ghostmansd | lkcl, test_dis.py is OK, I think it's safe to rebase after tests are passed | 14:17 |
| programmerjake | yay! | 14:17 |
| ghostmansd | What'd be the next point? Simply printing the stuff from the fields? | 14:17 |
| ghostmansd | Do we have the reconstruction depicted somewhere? | 14:20 |
| ghostmansd | Or I should simply do what's in pysvp64asm in a backward way? | 14:20 |
| ghostmansd | Ah yeah, likely the latter; e.g. outputting subvl=ZZZ is not as good as vec2/vec3/vec4. | 14:21 |
| ghostmansd | Still it'd be great if we had some page where there's summary, with the list of all opmodes and description what fields should be. | 14:23 |
| ghostmansd | By opmodes I mean this: opmodes = opcode.split("/") | 14:23 |
| ghostmansd | From pysvp64asm | 14:23 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 14:28 | |
| lkcl | ghostmansd, see https://bugs.libre-soc.org/show_bug.cgi?id=917#c40 | 14:29 |
| lkcl | pack/unpack is now an overload of elwidth but *only* for "normal" mode, and that's a temporary hack | 14:29 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 14:41 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.166.213> has joined #libre-soc | 14:42 | |
| * lkcl manic hysterical cackles | 15:03 | |
| lkcl | faakinellfire FSM-based dual looping is complicated | 15:03 |
| lkcl | esp. when you have to swap the order of the inner and outer loops based on a runtime decision | 15:04 |
| lkcl | mad | 15:04 |
| lkcl | yes i know, a list of the /modifiers is on the (long) todo list | 15:40 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.166.213> has quit IRC | 16:42 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 16:43 | |
| ghostmansd[m] | lkcl, do these PU changes need a doc update? | 16:47 |
| ghostmansd[m] | Because (deep breath!) I did based on docs, I didn't have to study this signal madness | 16:48 |
| ghostmansd[m] | For instructions, I look at fields.text, because I know where and what to find. Not the same with all these modes, it'd have taken several days to understand how it's mapped into signals. | 16:49 |
| ghostmansd[m] | So I suggest to at least update the docs so that I could look into them instead of wandering through the code. | 16:50 |
| programmerjake | lkcl: currently wiring up fp support in TestRunnerBase, any suggestions? | 17:05 |
| programmerjake | lkcl: is PowerDecode2.init supposed to pass regreduce_en to super().init? it passes constant False and ignores the input argument, which seems like a mistake | 17:15 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 17:48 | |
| ghostmansd | Hell Luke, either I did't push the recent version or you rebased something else. The code is doomed. :-) | 17:48 |
| ghostmansd | Perhaps this is the reason for errors, too. | 17:48 |
| ghostmansd | It seems like you rebased dis without pull... | 17:49 |
| ghostmansd | I did some force pushes later. | 17:49 |
| ghostmansd | lkcl, I'm not sure how to handle the conflict above ^ | 17:59 |
| ghostmansd | I'd rather preferred a force rewrite, to be honest, because otherwise it's just unstable code in the master. | 17:59 |
| *** tplaten <tplaten!~isengaara@55d45726.access.ecotel.net> has joined #libre-soc | 18:01 | |
| ghostmansd | I think I know why at least part of this doesn't work. We don't handle signed, and, frankly, I have no idea how to determine this. | 18:31 |
| ghostmansd | I can go over PPC_OPERAND_SIGNED in binutils, though. | 18:37 |
| programmerjake | ghostmansd, if you need something to do while waiting, I'm almost done with my part of #899 and will be waiting on you and lkcl to finish | 18:39 |
| ghostmansd | I'm not waiting, started looking at signed operands in binutils. :-) | 18:39 |
| programmerjake | ah, ok. | 18:40 |
| ghostmansd | What's expected on binutils side? | 18:40 |
| ghostmansd | Which opcodes must be added? | 18:40 |
| programmerjake | for #899? the full list is this (plus f*. opcodes) https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_enums.py;h=6c71462a0683bcfedcdb5c3e515d86ecf541cd9c;hb=56d807a8c26a358850220a34b982952fdf341027#l409 | 18:43 |
| ghostmansd | so these plus Rc-enabled, right? | 18:45 |
| ghostmansd | Wow, looks like a big chunk of work in binutils. | 18:46 |
| ghostmansd | I'll start tomorrow, OK? | 18:46 |
| programmerjake | I'd suggest doing what I did for most of the stuff in openpower-isa.git -- copy from the tail end minor_63.csv (all fptrans) and use a giant regex to reformat it to do what you want | 18:47 |
| ghostmansd | It's not that simple; binutils have some specific operands handling. | 18:48 |
| ghostmansd | Hm. I'll think how to handle it. | 18:49 |
| programmerjake | they're all X-form, 3 different groups where each group is identical except for mnemonic and XO | 18:49 |
| ghostmansd | Perhaps I'll come with something inventive. | 18:49 |
| ghostmansd | Which are the groups? | 18:49 |
| programmerjake | there's the f* FRT,FRA group, the f* FRT,FRA,FRB group and the f* FRT,FRA,RB group | 18:50 |
| ghostmansd | Aha, so they differ by operands. | 18:50 |
| ghostmansd | OK, got it. | 18:50 |
| ghostmansd | There's also test needed for each one of these, but perhaps these can be generated too. | 18:51 |
| programmerjake | within each group, only XO and the mnemonic vary, so it's pretty regular | 18:51 |
| ghostmansd | These operands are all 5-bit, right? | 18:52 |
| programmerjake | yes | 18:52 |
| ghostmansd | OK this simplifies the task. Though, on second thought, insndb is aware of operands span, so it's not a problem anyway. | 18:53 |
| ghostmansd | ^ I'll start tomorrow, OK? | 18:53 |
| programmerjake | k, thx! | 18:53 |
| ghostmansd | Likely the day after tomorrow, tomorrow will be quite occupied. | 18:53 |
| programmerjake | np | 18:53 |
| ghostmansd | Anyway, I think I'll be able to make at least part of the work automatic. | 18:53 |
| programmerjake | oh, actually the unary ops are f* FRT,FRB, not FRA...oops | 18:56 |
| ghostmansd | That's OK anyway :-) | 18:56 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 19:15 | |
| lkcl | ghostmansd[m], start small, don't think you have to tackle all of those. i'm quite happy with a subset | 19:25 |
| ghostmansd[m] | Well I saw 32 of these IIRC, and many of them are form of the same (e.g. BD has some other forms in binutils). | 19:26 |
| * lkcl currently in the middle of complex ISACaller update | 19:27 | |
| ghostmansd[m] | Also, interestingly, it appears that this split D implemented recently, must be signed too | 19:27 |
| lkcl | yes they're all either A-Form or X-Form. honestly a no-brainer | 19:27 |
| ghostmansd[m] | lkcl, please check about the rebase, we fucked it up | 19:27 |
| ghostmansd[m] | Or, well, perhaps I fucked it up | 19:27 |
| lkcl | great! yay! | 19:27 |
| ghostmansd[m] | No idea how it happened | 19:28 |
| programmerjake | lkcl: if you're talking about fptrans, they're now all X-FORM | 19:28 |
| ghostmansd[m] | My best bet is that you forgot to pull :-) | 19:28 |
| lkcl | generally it's inadviseable to use force-push on anything | 19:28 |
| ghostmansd[m] | On branches this is perfectly fine, branches are not supposed to be merged until ensured they are stable | 19:28 |
| ghostmansd[m] | Moreover, this is the best option to cleanup patch before publishing it | 19:29 |
| ghostmansd[m] | e.g. if you had some fixup after push | 19:29 |
| ghostmansd[m] | I agree this is not an option for master | 19:29 |
| lkcl | can i leave it with you, i have to get back to ISACaller, it's extremely complex | 19:31 |
| programmerjake | if you're force pushing, you can use --force-with-lease to ensure you didn't accidentally overwrite something you didn't see, it checks that you're origin/master matches the remote master, if you're pushing to master | 19:31 |
| programmerjake | I wrote master, but replace master with the appropriate branch name | 19:32 |
| lkcl | programmerjake, you mean "your origin/master" not "you are origin/master" | 19:33 |
| lkcl | it would be very weird to be equal to an origin/master whilst performing that check :) | 19:33 |
| programmerjake | yeah, you know what I meant despite my typos | 19:33 |
| programmerjake | https://git-scm.com/docs/git-push#Documentation/git-push.txt---no-force-with-lease | 19:33 |
| lkcl | i did - couldn't help it :) | 19:33 |
| lkcl | frickin sub-steps on loops aren't updating properly. reaaally wish i could do this as an iterator. | 19:36 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 19:39 | |
| ghostmansd[m] | Nah, that'd be way too simple | 19:43 |
| ghostmansd | max = operand->bitm; | 19:44 |
| ghostmansd | right = max & -max; | 19:44 |
| ghostmansd | min = 0; | 19:44 |
| ghostmansd | if (signopt) | 19:44 |
| ghostmansd | { | 19:44 |
| ghostmansd | min = ~(max >> 1) & -right; | 19:44 |
| ghostmansd | } | 19:44 |
| ghostmansd | else if (signed) | 19:44 |
| ghostmansd | { | 19:44 |
| ghostmansd | max = (max >> 1) & -right; | 19:44 |
| ghostmansd | min = ~max & -right; | 19:44 |
| ghostmansd | } | 19:44 |
| ghostmansd | Anybody experienced in bit operations? | 19:45 |
| * lkcl snorts | 19:45 | |
| ghostmansd | What does it mean, translated to human? | 19:45 |
| lkcl | no chance | 19:45 |
| ghostmansd | And assuming Python integers | 19:45 |
| ghostmansd | bitm is a mask (0x1f for 5-bit) | 19:45 |
| ghostmansd | But the rest looks kinda alien to me | 19:46 |
| ghostmansd | Damn it, binutils! | 19:46 |
| ghostmansd | I understand they sign extend... | 19:46 |
| ghostmansd | But the rest? | 19:46 |
| ghostmansd | if ((o->flags & PPC_OPERAND_SIGNED) != 0) | 19:47 |
| ghostmansd | sign_extend (op); | 19:47 |
| ghostmansd | Aha! | 19:47 |
| ghostmansd | OK they basically limit the range | 19:55 |
| ghostmansd | e.g. with mask 0b11 ranges become -2..1 | 19:56 |
| ghostmansd | so surprising, the operand is called PPC_OPERAND_SIGNED, who could imagine | 19:57 |
| ghostmansd | whoa, lkcl, thanks for the to_signed method | 20:09 |
| ghostmansd | lkcl, could you, please, run tests on dis branch when you have time? | 20:19 |
| ghostmansd | There's one known failure in pysvp64dis, with `mtspr 288,0` instruction. | 20:19 |
| ghostmansd | it gets disassembled as `mtspr 9,0`. | 20:19 |
| ghostmansd | As far as I know, SPR is not considered to be special in pysvp64dis, and perhaps it should've been. | 20:20 |
| ghostmansd | Other than that, looks really good. | 20:28 |
| *** tplaten <tplaten!~isengaara@55d45726.access.ecotel.net> has quit IRC | 20:31 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 20:38 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 21:00 | |
| lkcl | ghostmansd[m], ack willdo | 21:23 |
| ghostmansd[m] | I couldn't get what you mean in the comment to 917... I already pushed the patch for test, it worked for me | 21:23 |
| ghostmansd[m] | Except for mtspr part. | 21:24 |
| lkcl | i ran against master | 21:24 |
| programmerjake | meeting in 22min | 21:39 |
| programmerjake | 21 now | 21:39 |
| *** octavius <octavius!~octavius@241.147.93.209.dyn.plus.net> has quit IRC | 22:59 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!