Tuesday, 2022-08-02

*** octavius <octavius!~octavius@> has quit IRC00:32
lkcl-naah. that's "only" 25,000 intrinsics01:13
lkcl-the answer's no.01:13
lkcl-hard no.01:13
lkcl-SV is a 2-Dimensional ISA in effect: the prefix is separate from the suffix, and intrinsics should reflect that01:14
lkcl-it's the whole damn point.01:15
programmerjakewell, sorry, llvm doesn't work that way...unless you want to spend many years rewriting major portions of it -- also i highly doubt they'd accept it upstream. imho what we need is to have intrinsics with const parameters, so we only need one generic intrinsic for each op such as add, sub, mul, etc. and the rest is determined by input/output types and const arguments01:25
programmerjakethere's only 25-50 such ops (add, sub, mul, etc...) we'd need, because llvm ir is pretty simple.01:31
programmerjakethat's not including all our specialty extensions, just svp64 and base powerisa01:32
programmerjakedo note those ops won't match 1:1 to svp64, since some things work better in ir as separate ops that are fused in the backend, e.g. imho twin-predication should be built from separate register compress/expand ops and the underlying add/etc. op.01:35
programmerjakejust like how powerisa's rotate and mask ops are expressed in llvm ir as separate shift, and, or, and rotate ops01:36
programmerjakealso, where the svp64 intrinsics match existing intrinsics, the existing intrinsics should be used to take advantage of code already written using those intrinsics -- both frontends like clang and rustc and optimizations like loop autovectorization.01:39
lkcl-we're not limiting what svp64 can do either03:03
lkcl-fitting into a broken paradigm is a serious mistake.03:05
lkcl-the entire paradigm for llvm is to fit with SIMD (and now RVV).03:05
lkcl-they are based on 1D ISAs03:06
lkcl-SVP64 is a 2D ISA03:06
lkcl-the paradigms do not match and they're just going to have to suck it up.03:06
lkcl-any kind of compromise here basically means limiting SVP64 to 0.5% of its full capability03:07
lkcl-which is about as stupid as it gets.03:07
lkcl-it sends a message "we wasted 3+ years of our lives to design an ISA that we can't be bothered to state our case and assert ourselves in a reasonable and rational way why things should be done better"03:08
lkcl-i'm sorry but that's just not in the least bit acceptable03:08
lkcl-we've developed literally the most powerful ISA in the world03:09
lkcl-it was quite by accident, but that's no excuse03:09
lkcl-NO compromises.03:09
lkcl-if that means we have to raise USD 25 million to get the compiler done then we goddamn raise USD 25 million.03:10
lkcl-now, that said, there's a way to go about presenting a case for a different approach as reasonable people03:16
lkcl-and there's a way to do it as complete dickheads03:16
lkcl-the former's much more sensible03:17
programmerjakei said 25-50 generic intrinsics, not 1M03:17
lkcl-but if we go to them and say "we want to fit in with llvm's limited scalable vector intrinsics that were never designed with the full capability of svp64 in mind"03:18
lkcl-we're sending a message that svp64 is like all other 1D ISAs03:19
lkcl-that's a mistake that we'll never fully recover from03:19
programmerjakewe're fitting in only where the svp64 op is identical, because backward compat is impprtant, otherwise it uses a svp64 intrinsic.03:19
programmerjakewe don't want everyone who uses llvm to have to rewrite everything just to use svp64, when their existing code is perfectly sufficient and can be easily translated by llvm's backend03:20
programmerjakethat's kinda like saying "i don't like c's for loop, i have a better replacement, so lets build a c compiler with only the replacement and not the original for loop and everyone can just rewrite all their c code to use the new for loop, all of debian, linux, and everything else written in c"03:23
programmerjakeso that's why i want svp64 to use the existing intrinsics when possible03:24
programmerjake> we're sending a message that svp64 is like all other 1D ISAs03:28
programmerjakeno, we're sending a message that existing 1D ISA's operations also work on svp64 -- which is true and a large part of why svp64 is better than rvv (which doesn't really support fixed-length ops)03:28
lkcl-hmm hmm, let me mull on it for a while04:06
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC06:30
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc06:30
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC06:42
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc06:45
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC07:03
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc07:04
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC07:24
markostbh, it would be simpler even as an alternative to just fork llvm and work our own 2D intrinsics, and just send a PR when ready, and just try to be as non-intrusive as possible, llvm has been quite receptive in the past, probably more than gcc so I don't think it's unlikely07:31
markosie, I would follow both paths07:32
markosa) short term just support the most common operations, b) long term, fork and design/implement a 2D intrinsics on a fork of llvm07:33
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc07:35
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC07:51
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc07:53
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC08:06
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC08:07
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc08:08
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC08:12
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc08:20
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC08:30
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc08:33
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc08:42
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC08:43
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc08:44
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC09:25
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc09:25
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC09:25
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC09:29
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc09:30
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC10:27
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc10:31
*** octavius <octavius!~octavius@> has joined #libre-soc10:39
markoscoming to elaborate a bit more on what I suggest, the first plan is easy to implement and would probably take only a few months and should be only used an interim solution -keeping the same intrinsic names- while the 2nd is the proper long term goal, requiring much more work10:47
markoshowever it would still be nice to do, because it would help solve possible problems10:48
markosif I'd have to choose only one solution, I'd go for the 2nd10:48
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc10:52
ghostmansdlkcl, I might have asked this already, but still. In RM-1P-1D.csv, what are the 1P-1D parts? I assume 1P/2P are sv_ptype; what does 1D mean? Perhaps I could re-use this stuff as a hint and put more checks there upon parsing it all.10:59
lkcl-1P is 1 predicate, 2P is twin predicate11:36
lkcl-1D means "1 destination"11:36
lkcl-1s means "1 source"11:36
lkcl-that's either GPR, FPR, or CR.11:36
lkcl-(excluding Rc=1 which is implicit and always matches with the destination result)11:37
lkcl-so, "2S" means "there were a total of 2 source registers, they were GPRs, FPRs, or CR Fields"11:37
lkcl-in this way you can tell at a glance exactly how many registers there are11:38
lkcl-and therefore how many entries in the RM.EXTRA you have to fill in11:38
lkcl- 643             elif value == 'RM-1P-2S1D':11:39
lkcl-that's only 3 registers (2 source + 1 dest)11:39
lkcl-therefore it can fit in EXTRA311:39
lkcl- 644                 res['Etype'] = 'EXTRA3'  # RM EXTRA3 type11:39
lkcl-so what about any instructions beginning "cr" such as "crand", "cror"?11:40
lkcl- 645                 if insn_name.startswith('cr'):11:40
lkcl- 646                     res['0'] = 'd:BT'  # BT: Rdest1_EXTRA311:40
lkcl- 647                     res['1'] = 's:BA'  # BA: Rsrc1_EXTRA311:40
lkcl- 648                     res['2'] = 's:BB'  # BB: Rsrc2_EXTRA311:40
lkcl-let's make EXTRA3_0 the destination extension for BT11:40
lkcl-EXTRA3_1 cover the 1st source BA11:40
lkcl-and EXTRA3[2] cover the 2nd, BB11:40
lkcl-really quite boring and by-the-numbers-bloody-obvious11:41
lkcl-but if you don't have a "register profile" (total number of reg operands) you can't do that11:41
lkcl-sv_analysis.py goes through the entirrre ISA looking for "register profiles"11:42
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC12:23
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc12:24
octaviuslkcl, are there any tasks you need assistance with? After friday afternoon I'll be heading off to orienteer in the Lake District, and will be away for a week.12:25
octaviusThe HiTas examples that seem to hang, haven't progressed after a few hours. So my intuition tells my there's something missing, but I didn't see errors or warning during the build process.12:25
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC12:37
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC12:38
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc12:40
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC13:06
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc13:08
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc13:32
ghostmansdlkcl, thanks for the explanation!13:56
ghostmansdalso, another question on svp64 tables. We have sv_inX and sv_out entries. In CSV files, we have say addi,NORMAL,,2P,EXTRA3,d:RT,s:RA,0,0,RA_OR_ZERO,0,0,RT,0,0,1,0 record, where sv_in1is RA_OR_ZERO. However, the resulting sv_in1 in get_svp64_csv won't be RA_OR_ZERO, but it would be one of SVEXTRA, right?13:59
ghostmansdAh yeah, found it: # now examine in1/2/3/out, create sv_in1/2/3/out14:00
ghostmansdHaving 0,1,2,3 and in1,in2,in3,out fields is controversial, I'd say :-)14:03
ghostmansdAs I understand, we don't really use these per se, but, rather, call decode_extra on them and then convert this all to sv_in1 et al., right?14:03
lkcl-octavius, the pinmux - joining the Mux-GPIO class you wrote, with the json-reader-class ineptly named "Pins", is your next mission :)14:12
lkcl-octavius, ok we wait for Marie-Minerve to come back from holiday14:12
octaviusalso, fvmw is very cool (prepping my spare laptop with IRC to take with me)14:13
lkcl-ghostmansd, i think the 0,1,2,3 if i recall correctly, refers to the EXTRA indexing14:13
lkcl-it... i remember melting my brain on how that actually works.14:14
ghostmansdThese can be like d:RT or similar14:14
ghostmansdThey're used by decode_extra.14:15
lkcl-i remember it being complicated. i'm in the middle of something (mentally) so you'll have to excuse me, i can't cope with flipping between one complex topic and another just as complex14:15
ghostmansdSure :-)14:15
ghostmansdI think I already found the answer, anyway14:16
lkcl-but, did you get the idea of putting bitsel into the actual CSV file as a comment?14:16
lkcl-the important bit about that idea is that it tells you that the bitsel applies to the *entire* CSV file14:16
lkcl-i did explain this but you likely missed it14:16
ghostmansdNope, I didn't miss it :-)14:16
lkcl-i said that in create_pdecode, the *parent* has the bitsel which applies to its *child* list of Subdecoders()14:17
ghostmansdI'm not sure whether we should put it as comment, I'd rather preferred having some standalone file which has this mapping14:17
lkcl-if you can add bitsel to the... mmmm yuk14:17
lkcl-yeah that kinda works14:17
ghostmansdEven hardcoding it in the code is better...14:17
ghostmansdBecause, well, comments are comments14:17
lkcl-i kinda like the information being directly at the point it's used14:18
ghostmansdThere are exceptions like shebang, though14:18
ghostmansdYeah, me too... The only thing which prevents it is the CSV format14:18
ghostmansdBecause it's somewhat limited14:18
ghostmansdAnd putting anything that doesn't fit it in comments is not a silver bullet either14:18
ghostmansdRight now I'm re-thinking basic structures around CSVs so that all stuff is typed properly (e.g. Ptype field comes out of CSV parser as power_enums.SVPtype, and so on).14:20
lkcl-as you probably noticed i have a pretty direct "get-it-done-y'all" attitude to certain types of programming problems14:21
lkcl-it leads to surprisingly compact code, when compared to "The Nice Way With Classes n Stuff"14:22
lkcl-but is horrendous to understand, later14:22
ghostmansdboth approaches have the right to exist :-)14:26
ghostmansdI actually use both, the "nice way with classes" preferably when there's a need to refactor the code (e.g. when it has to be used by more than 1 subsystem)14:26
lkcl-yehyeh no makes perfect sense14:27
lkcl-octavius, do print out that PDF and actually put it in the post to FundingBox14:30
lkcl-toshywoshy, same14:31
lkcl-just remember to scan the words for that missing "NOT" in the legally-binding declarations14:31
octaviusAh yes, lkcl, will do. Writing that Polish address is going to be fun XD14:40
lkcl-if you can, send it Recorded Delivery then send a copy of the receipt to Marie14:41
lkcl-it will get held up in customs but we dont' care, it's the "proof-of-posting" that's important14:42
octaviusSure, no prob14:42
lkcl-toshywoshy, you got ACKs on the 2 grants? 2 is a good idea https://libre-soc.org/nlnet_2022_librebmc/14:47
toshywoshyyes, I got submission ids, I did not get any mail confirmation yet, they tend to come in very late14:49
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC16:03
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc16:04
lkcl-yes, 3 days late16:15
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC16:16
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc16:17
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC17:17
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc17:17
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC17:25
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC17:27
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc17:27
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC17:32
*** octavius <octavius!~octavius@> has quit IRC17:44
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc18:41
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc20:04
ghostmansdlkcl, any tips on what PU can be? From the sources it seems it can be either 1 or be omitted. Should I consider a boolean value?20:05
ghostmansdAlso, speaking of SVP64 CSVs (not "vanilla" ones). What mode could be?20:22
ghostmansdinsn,mode,CONDITIONS,Ptype,Etype,0,1,2,3,in1,in2,in3,out,CR in,CR out,PU,out220:22
ghostmansdFrom the code, it seems that it can be NORMAL, LDST, BRANCH or CROP...20:23
ghostmansdIs it correct? I'm thinking of adding yet another enum to establish it once and forever, and have the corresponding checks.20:24
ghostmansdAh yeah, right, https://libre-soc.org/openpower/sv/svp64/ has Mode section.20:26
programmerjakelkcl, afaict i found a bug: both if and else set pack to 1: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/sv_analysis.py;hb=b1efd05e410dd33888967b6dfe9a618f6b480f27#l49220:27
lkcl-programmerjake, ahh magic, i hadn't actually written any unit tests yet20:30
lkcl-ghostmansd, there's two flags, pack and unpack. they can *both* be set.20:30
lkcl-i wrote some assembler options err... yesterday?20:30
ghostmansdI'm just looking at CSVs, don't really think of asm now :-)20:31
lkcl-fouund iiit https://libre-soc.org/irclog/%23libre-soc.2022-07-30.log.html#t2022-07-30T05:29:4920:31
lkcl-the way it works is:20:32
lkcl-there is vector loops 0..vl-120:32
lkcl-and there is subvector loops 0..subvl-120:32
lkcl-there is also source-looping and there is dest-looping20:32
lkcl-the "normal" way you do element-walking is20:33
lkcl-for i in range(VL): for j in range(SUBVL): index = (i*SUBVL)+j20:33
lkcl-where if SUBVL=1 then obviously that degenerates to just a VL loop20:33
lkcl-Pack will *invert* the application of the for-loops for *source* index walking20:34
lkcl-Unpack invert the application of the for-loops for *destination* index walking20:34
programmerjakepack/unpack will definitely be useful for 3D stuff, i was planning on just using several strided load/stores for that20:34
lkcl-it's freaky as hell :)20:34
lkcl-yeah, 3D and RGB/ARBG or YUV pixels in video.20:35
lkcl-because you can pack/unpack all the R R R R separate from G G G G and B B B B20:35
* lkcl- (explaining to ghostmansd, programmerjake)20:35
ghostmansdOK, so basically PU indicates whether insn supports /vp /pu /vu /pu, right?20:36
ghostmansdI mean PU field in CSV20:36
lkcl-"/vp" for pack and "/vu" for unpack and "/pu" for both flags20:36
lkcl-yes, freakily, both flags being set is perfectly valid20:37
lkcl-there's only 3 settings because the default is "don't raise either flag"20:37
lkcl-no point wasting asm-space raising default settings20:38
ghostmansdOK, I understand that in insn encoding, we can set PACK_en or UNPACK_en or even both.20:38
ghostmansdBut what about CSV field?20:38
lkcl-here's the weird bit20:38
programmerjakejust saw: https://www.phoronix.com/news/Linux-6.0-SPI-Better-Perf20:39
lkcl-based on how you've designed sv_binutils, you *should* just be able to re-run it and laugh manically at how easy it was to adapt to the new LDST-2P-1S1D-PU format20:39
programmerjakebetter linux SPI performance might be useful for us20:39
lkcl-as in: the *only* thing you should actually need to do is add the "/pu" "/vp" and "/vu" flags support.20:40
ghostmansdbinutils are not an issue, they don't even consider fields they don't know how to deal with yet20:41
ghostmansdI'm raising these questions due to 838 and 83520:41
lkcl-yes, exactly, and the changes from EXTRA3 to EXTRA2 are... ahhh20:41
*** octavius <octavius!~octavius@> has joined #libre-soc20:41
lkcl-honestly i'm not so bothered by the csv files containing "comments that happen to mean stuff"20:45
lkcl-however a comment saying "the next line means stuff, don't alter it" is probably a good idea :)20:46
lkcl-or even if you think it a good idea to put the contents into another CSV file it would be best to have comments in that, as well20:46
lkcl-eh what the heck.  bitsel.csv20:46
ghostmansdyes, I'm thinking of keeping such information in separate file20:46
ghostmansdby the way, CSVs suck :-)20:47
ghostmansdthe only reason I'm considering them now is because they're simple20:47
ghostmansdthat's as long as the stuff is simple, obviously20:48
ghostmansdand also for a least astonishment: if all the data is in CSV, why should bitsel be somewhere else, eh?20:48
lkcl-yyep, and they're ubiquitous.20:48
lkcl-true :)20:48
lkcl-i think it sensible to hit all the minor_xxx.csv files with a comment saying "bitsel.csv says what column 0 means"20:50
programmerjakeimho we should use something like json5 -- json with comments and allowing trailing comments and not requiring quotes for object keys...last time we discussed it we took the easy route of adding comments to the csv instead20:50
programmerjaketrailing commas*20:51
lkcl-latest-and-greatest terminates all and any possibility of older systems from being able to read the data.20:56
lkcl-this is... not a good attitude to take towards data that is intended to be accessible as a specification20:57
lkcl-csv files can be read by sed, awk, bash, and simple perl scripts20:58
ghostmansdthey only cannot be read by humans :-)21:00
ghostmansdsorry, could not resist21:00
ghostmansdI don't recall the exact quote, but, kinda like...21:03
programmerjakeiirc jq can easily be used, it's commonly available on linux systems21:05
programmerjakeit's kinda like awk, but for json21:06
ghostmansdThere are languages which are designed to be machine-readable. There are languages which are designed to be human-readable. XML fits neither of these niches.21:07
ghostmansdI don't recall the quote, perhaps even the language chosen was different, but you get the spirit :-)21:08
programmerjakejson fits both, but better as machine readable. csv is nearly totally non-human readable because you have to go to great lengths to figure out which column your in.21:09
programmerjakeimho sed/awk compatibility is less important than being human readable, jq is a sufficient replacement21:10
ghostmansdWell it's possible if you have a good editor21:11
programmerjakeyes, so is raw binary...21:11
ghostmansdJokes aside21:11
ghostmansdThis looks like a broken entry; I'd have expected s:RS;s:RA21:12
ghostmansdother entries below stdux too21:13
ghostmansdAlso, s:CR doesn't look like a valid entry, too; s:CR0 does, as well as s:CR1. Please correct me if I'm wrong.21:15
programmerjakewhich table? mtcr stores to the whole CR reg so s:CR would be correct afaict21:17
programmerjakestill in openpower/isatables/LDSTRM-2P-2S1D.csv?21:17
programmerjakeah, that's correct -- it reads the whole CR reg -- CR0-721:18
ghostmansdtwo tables which have such records21:18
ghostmansdOK, there's a need to support one more entry in enum then :-)21:19
ghostmansdThanks programmerjake21:19
programmerjakeidk if we want to support sv prefixed mfcr...seems not very useful21:20
programmerjakeiirc lkcl decided to support it anyway21:21
ghostmansdlol seriously?21:28
ghostmansdOrderedDict([('insn', 'fishmv'), ('mode', 'NORMAL'), ('CONDITIONS', ''), ('Ptype', '2P'), ('Etype', 'EXTRA3'), ('0', 'TODO'), ('1', '0'), ('2', '0'), ('3', '0'), ('in1', 'FRS'), ('in2', 'NONE'), ('in3', 'NONE'), ('out', 'FRS'), ('CR in', 'NONE'), ('CR out', 'NONE'), ('PU', '1'), ('out2', 'NONE')])21:28
ghostmansdI'm struggling to understand how I'm expected to handle TODO? :-)21:29
ghostmansdthe fact that the current code _works_ is rather alarming21:31
programmerjakehmm, treat that as polling git until the TODO disappears :)21:31
*** octavius <octavius!~octavius@> has quit IRC22:04
*** octavius <octavius!~octavius@> has joined #libre-soc22:04

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!