<muurkha>
add x1,x1,13 is actively misleading; on amd64 that would mean to load the addend from memory address 13, which of course is impossible on RISC-V
<muurkha>
to indicate an immediate constant amd64 in gas assembly requires $13 and ARM requires #13
<jrtc27>
I hate that add rd, rs1, imm12 is even valid syntax
<jrtc27>
it should be "no go away and say addi"
<muurkha>
maybe we can add a warning to the assembler if someone uses that syntax
<muurkha>
;)
<jrtc27>
gas declared it valid so it must be valid until the end of time and woe betide you if your assembler doesn't support it
<jrtc27>
gas is sacred
<jrtc27>
all hail gas
* muurkha
worships gas
<muurkha>
gas taught me the true meaning of assembly!
<muurkha>
this seems related to the other alias-related thing I was complaining about where a relocation that hasn't yet been applied (so there's a zero in the immediate field) causes an addi instruction to get disassembled as a mv
<muurkha>
which IIRC you didn't think was bad
<sorear>
the relocation printing is terrible, the auipc printing is mostly just brittle, a little alias issue gets lost in the noise
jacklsw has joined #riscv
billchenchina- has joined #riscv
billchenchina has quit [Ping timeout: 245 seconds]
billchenchina- has quit [Client Quit]
billchenchina has joined #riscv
MaxGanzII has joined #riscv
MaxGanzII has quit [Remote host closed the connection]
MaxGanzII has joined #riscv
MaxGanzII has quit [Quit: Leaving]
billchenchina- has joined #riscv
billchenchina has quit [Ping timeout: 245 seconds]
MarvelousWololo has quit [Read error: Connection reset by peer]
billchenchina- has quit [Remote host closed the connection]
billchenchina- has joined #riscv
mmind00_ is now known as mmind00
mmind00 has quit [Quit: mmind00]
mmind00 has joined #riscv
ldevulder has quit [Remote host closed the connection]
wgrant has quit [Quit: WeeChat 3.5]
wgrant has joined #riscv
ldevulder has joined #riscv
danilogondolfo has joined #riscv
BootLayer has joined #riscv
esv_ is now known as esv
<courmisch>
it's one thing to accept it in, and it's a whole other thing for objdump to print it *out*. The later is what I find annoying
pecastro has joined #riscv
zjason`` is now known as zjason
billchenchina has joined #riscv
billchenchina- has quit [Read error: Connection reset by peer]
stolen has joined #riscv
jacklsw has quit [Ping timeout: 252 seconds]
unsigned has joined #riscv
awita has joined #riscv
Andre_Z has joined #riscv
billchenchina has quit [Quit: Leaving]
aerkiaga has joined #riscv
jmdaemon has quit [Ping timeout: 246 seconds]
pabs3 has quit [Ping timeout: 245 seconds]
Noisytoot has quit [Remote host closed the connection]
<conchuod>
krzk's comments about a the RESEND/v7 don't need to be addressed, because I reviewed the dt-binding stuff
Tenkawa has joined #riscv
<Esmil>
conchuod: no, i have that open in a tab, i've just been preempted a few times since i opened it. thanks!
<conchuod>
Esmil: Ah, okay. I was just making sure, since the one you reviewed was the more recent submission
<Esmil>
yeah, but i thought that had to be applied first
<Esmil>
..but maybe they're independent
<conchuod>
I think they are independent of each other.
<conchuod>
I applied both last night to a branch that was sorted with all the bindings then all of the driver stuff w/ the PLL driver bits first. LKP seems happy with it :)
<Esmil>
Ah cool
stolen has quit [Quit: Connection closed for inactivity]
Andre_Z has quit [Quit: Leaving.]
Noisytoot has quit [Remote host closed the connection]
<drewfustini>
jrtc27: good point about RV64GCV being incorrect for the C910. I'm trying to let everyone know to drop the V. It should have never been there in any of our beagle material but i think it was just blindly copied from t-head docs.
<drewfustini>
this is the best shape Robert Nelson was able to get the T-Head SDK into so far https://git.beagleboard.org/beaglev-ahead/xuantie-yocto/ but hopefully things will improve quickly now that we are talking about it
<jrtc27>
doesn't linux have INSN_R or something macros to do that nicely?
<jrtc27>
(which uses .insn where available)
<courmisch>
I don't know why people insist on not using .insn r
<drewfustini>
I'm not familiar with that... would that be a C macro?
<courmisch>
beware that v vector are not accepted as operands though. you need to "rename" them to x or f registers
<drewfustini>
I'm trying to get up to speed now that we (beagle) are in the t-head boat. I would love to have a path for people to not have to use the thead toolchain.
<jrtc27>
shame beagle went with a deliberately-standards-violating vendor
<drewfustini>
thanks
<jrtc27>
(don't care about vector, I care about page tables)
<jrtc27>
(and coherency)
<drewfustini>
it was really really hard to find a SoC vendor that could provide us any amount of volume
<jrtc27>
I get business decisions
<drewfustini>
We want to make many models of BeagleV.
<jrtc27>
but it *really* sucks from an OS dev perspective
<drewfustini>
I am really hoping a company like NXP or TI which has public docs and catalog distrbutions will eventually make a risc-v soc
<jrtc27>
because now FreeBSD needs a non-standard pmap and busdma to support all these non-standard boards
<jrtc27>
:(
<jrtc27>
I was really hoping all this T-Head crap could become history relatively quickly
<jrtc27>
and move on to standard implementations, whether from others or them
<drewfustini>
Yeah... I think there is not an ideal SoC yet to do a board with, at least not in terms of good public docs and standards complaint
<drewfustini>
Yeah me too
<palmer>
it's pretty much impossible to build a standard-compliant RISC-V system that does anything interesting, we're going to be stuck with vendor-specific behavior for ages
<drewfustini>
We will happily do new BeagleV models when new SoCs become available
<drewfustini>
For BeagleV, it's a bit of a low bar like can be get the chip in quantity and is it cheap enough for us to do a board less than $200
<drewfustini>
We'd love to have more choice in the future in terms of RISC-V SoCs
ars23 has joined #riscv
ars23 has quit [Client Quit]
<drewfustini>
I am kind of hoping none of the current crop of RISC-V SoCs become wild commercial successes and that there will be a new wave next year that at least implement some of the specs from 2021 and maybe 2022
<gurki>
i suppose building one yourself is out of scope for you?
<gurki>
theres plenty of core generators you could plug together with some synopsys ip
<gurki>
im also worried palmer might be correct
<drewfustini>
It is for now. Too much capital for a small non profit like beagle. we only have 1 employee (our executive director). We don't have the revenue to do get into taping out a chip.
<drewfustini>
I really really hoping one of the existing ARM SoCs vendors that has great public docs, owns a lot of their IP, AND sells into catalog distribution (Digi-Key, etc) will eventually make a RISC-V SoC
<gurki>
its quite hard to move a collection of soc ip to riscv
<gurki>
a lot of riscv stuff is clearly meant for fpgas
<jrtc27>
being a big existing vendor doesn't help you
<jrtc27>
look at the mess renesas made with the rz/five by using andes's garbage core
<gurki>
jrtc27: it does when you need to juggle a ton of ip
<gurki>
but as i said, its really hard to actually find a core thats suitable for asic + a ton of ips.
<jrtc27>
(at least with the configuration they have it in; they could have turned off the brokenness...)
<drewfustini>
There are two SoC vendors that I think are very good for making open source hardware boards: NXP and TI. They both sell their SoC through distros like Digi-Key and they have freely available in depth docs.
<drewfustini>
I would love someday for a company like that to do a RISC-V SoCs
ars23 has joined #riscv
<drewfustini>
unless a SoC vendor sells through distributors, they have very little incentive to have public docs (MediaTek, Broadcom, Qcom, etc).
<courmisch>
"addia0, a0, RISCV_VECTOR_VLENB*8"
<courmisch>
err
<courmisch>
isn't that hard-coding the vector length in the code??
<courmisch>
so sloppy
<drewfustini>
We won't make an official BeagleBoard or BeagleBone without public SoC docs and ability to buy SoC from distros. So for now, BeagleV is our experimental brand. I hope someday its possible to do a RISC-V BeagleBone or BeagleBoard (public docs, vendor cares about upstream, soc can be ordered in low qty from distro, etc).
<drewfustini>
courmisch: where is that addia line from?
<courmisch>
drewfustini: your link, my clipboard dropped the tab
handsome_feng has quit [Quit: Connection closed for inactivity]
pecastro_ has joined #riscv
pecastro has quit [Ping timeout: 245 seconds]
bjdooks has joined #riscv
ldevulder has quit [Quit: Leaving]
jmd_ has quit [Ping timeout: 245 seconds]
jmd_ has joined #riscv
EchelonX has joined #riscv
EchelonX has quit [Client Quit]
EchelonX has joined #riscv
jmd_ has quit [Ping timeout: 252 seconds]
arnd_ has joined #riscv
merry_ has joined #riscv
yyp_ has joined #riscv
catcream__ has joined #riscv
shreyasminocha_ has joined #riscv
jleightcap_ has joined #riscv
sm2n_ has joined #riscv
JSharp_ has joined #riscv
tafama has joined #riscv
SpaceCoaster_ has joined #riscv
h2t_ has joined #riscv
matoro_ has joined #riscv
pavelow_ has joined #riscv
vagrantc has quit [Quit: leaving]
matoro has quit [*.net *.split]
tafa has quit [*.net *.split]
drewfustini has quit [*.net *.split]
SpaceCoaster has quit [*.net *.split]
pavelow has quit [*.net *.split]
JSharp has quit [*.net *.split]
merry has quit [*.net *.split]
h2t has quit [*.net *.split]
arnd has quit [*.net *.split]
jleightcap has quit [*.net *.split]
catcream_ has quit [*.net *.split]
sm2n has quit [*.net *.split]
shreyasminocha has quit [*.net *.split]
yyp has quit [*.net *.split]
SpaceCoaster_ is now known as SpaceCoaster
arnd_ is now known as arnd
JSharp_ is now known as JSharp
merry_ is now known as merry
jleightcap_ is now known as jleightcap
sm2n_ is now known as sm2n
yyp_ is now known as yyp
shreyasminocha_ is now known as shreyasminocha
jmd_ has joined #riscv
Andre_Z has quit [Quit: Leaving.]
Armand has joined #riscv
jmd_ has quit [Remote host closed the connection]
<muurkha>
drewfustini: the vector aspects of the C910 are among its most important selling points, I think? like it's an order of magnitude boost for some workloads, right?
jmd_ has joined #riscv
<muurkha>
probably if none of the current crop of RISC-V SoCs become wild commercial successes, there won't be a new wave ever
drewfustini has joined #riscv
<muurkha>
drewfustini: the vector aspects of the C910 are among its most important selling points, I think? like it's an order of magnitude boost for some workloads, right?
<muurkha>
probably if none of the current crop of RISC-V SoCs become wild commercial successes, there won't be a new wave ever
<muurkha>
fortunately at least ESP32-C2 seems to be doing okay
<muurkha>
(sorry for repeats, drewfustini was offline)
<muurkha>
what do these numbers mean? they don't have any units
<courmisch>
cycles
<courmisch>
that's the output of FFmpeg's checkasm tool in bench mode
<muurkha>
I see
<muurkha>
and is this on real RVV or T-Head 0.7.1?
<courmisch>
the later obviously; I don't fab RVV chips in my basement
<muurkha>
you could be using an FPGA or some kind of software simulator
<muurkha>
I'm thinking, and maybe this is completely stupid, that the improvement for 16-bit and 8-bit arithmetic should be more significant than for the 32-bit arithmetic you're testing?
<courmisch>
Beijing ESWIN has used Spike to bench FFmpeg, but the numbers look too good to be true
<drewfustini>
I think the C910 still improvement on U74 for RVGC (no vector) but I don't know by how much. I noticed a lot of benchmarks use T-Head toolchain with T-Head vector.
<drewfustini>
*a lot of the C910 benchmarks, I meant
<sorear>
drewfustini: have you looked at the 0.7.1 patches on linux-riscv@ ?
<drewfustini>
From Heiko? Not too closely yet, but I am hoping beaglev ahead will be able to use that eventually.
<courmisch>
inconveniently enough, FFmpeg's checkasm won't let you bench just the unoptimised C version
<drewfustini>
Right now I'm trying to boot mainline with console on the beaglev ahead. then I can start trying patch series from the list.
<muurkha>
ugh
<courmisch>
so I can't "simply" run the same program on VF2 to see on U75
<muurkha>
right
<muurkha>
I was thinking that the gains would be largest for things like alpha-compositing, which I don't think FFmpeg does much of
<courmisch>
alpha-compositing is done in GPU these days
<muurkha>
if you have one
<courmisch>
well if you need to do alpha-compositing, you probably do
<courmisch>
I know VF1 had no GPU, but it also didn't have Vectors
<sorear>
kind of wonder how much riscv suffers for having _no_ media-specific vector instructions in base V, eg SAD
<courmisch>
anyhow, I'd be surprised if it got any better than 4x speedup with 128-bit vectors
<courmisch>
sorear: SAD? V has saturating arithmetic
<courmisch>
what it really badly lacks for multimedia is shuffling
<courmisch>
yes but as I just said, general gather is typically slower than ad-hoc shuffle.
<courmisch>
even the spec points out that slide instructions should be faster than gather
<muurkha>
aside from multimedia, shuffles are important for things like vectorized regular expression matching and I think Viterbi decoding
BootLayer has quit [Quit: Leaving]
<sorear>
simd "shuffles" are limited to a single register's worth of data, i believe on x86 the basic shuffles only operate within a 128b lane
<dzaima[m]>
yeah, I do see the better perf possibilities of ad-hoc shuffles (besides the quite important thing that variable-length vectors make shuffles significantly less "usable", unless you limit yourself to using only the low 128 bits, or dynamically generate the indexes)
<muurkha>
but I'm just a muurkha, I could be totally off-base
<sorear>
vrgather in the general case needs to shuffle up 1024 bits of data for LMUL=8 VLEN=128; i wonder if implementations will optimize vrgather for short lengths and local data movement
<courmisch>
transpose only makes sense with fixed size vectors, yes
<courmisch>
zip/unzip can work with arbitrary length though
<muurkha>
if you want to transpose a large matrix through a cache you need to do it blockwise
<muurkha>
if that's what you mean by "transpose"
<sorear>
the implementation I'm still on design notes for takes 1 cycle per 64 bits of output _if_ the output takes elements from at most 2 64-bit blocks of input, increasing proportionally
<courmisch>
in multimedia it's anyway done on macroblocks, so 8x8 or 16x16 or such
<dzaima[m]>
yeah most x86 shuffles below avx512 stay within 128-bit lanes; there is an 8xi32 shuffle though, and constant 4xi64. avx512 does have full-width shuffles though
<courmisch>
not HUGE matrices
<muurkha>
(possibly that's too obvious to be worth mentioning)
<muurkha>
yeah, 8×8 and 16×16 are nice tile sizes for either pixels or floats
<muurkha>
8 32-bit or 64-bit floats is a convenient 256 or 512 bits
<sorear>
interestingly it tries to do loads in parallel with other operations (since reads are commonly mixed with everything else, and we're mostly VRF read port limited) so for constant data like blake2's message permutation doing a gather load for each round is fewer cycles
<sorear>
transform blocks in av1 are up to 128x128
<sorear>
some operations are limited above 32x32
<courmisch>
eh
<sorear>
i need to figure out how to run an encoding/decoding benchmark under perf record so I know which parts of the spec to pay attention to
<muurkha>
but even if you're transposing a matrix without any SIMD or other vector instructions, it's important for the input and output block to fit in your L1D$ together
<courmisch>
well, I won't touch dav1d code unless I'm paid to. I only do copyleft on my free time :o
<muurkha>
ooh, blake2, nice
<courmisch>
a macroblock is way smaller than any data cache
<courmisch>
but you do have a point that you may need to prefetch judiciously
<dzaima[m]>
@sorear:libera.chat: variable runtime for vrgather is interesting, makes sense though (I was imagining it'd just always be ~quadratic, but optimizing for better indexes makes a lot of sense). Hits worst-case for n×n transposes though
<sorear>
there isn't really a good way to transpose small-element vectors in RAM in a single pass
<dzaima[m]>
rvv can do interleave/deinterleave with some widens/narrows/shifts
<sorear>
this also hits segment load/store since the register images are a transpose of the memory image. you can use segment load/store of unit stride data as a transpose engine but it doesn't always help
<courmisch>
wow, strided loads and stores are slooow on LPi4a
<courmisch>
it's not entirely surprising, to be fair
<sorear>
dzaima[m]: the libera.chat matrix integration is going away at the end of the month https://libera.chat/news/matrix-deportalling . does this affect you, and what can I do to help
<Armand>
Oh, it is?!?
<Armand>
Good.
<muurkha>
what's LPi4a?
<Armand>
Lemon Pi ?
<Armand>
:P
<dzaima[m]>
yeah the deportalling would mean I'd have to dig up an IRC client if I wanted to continue participating (which I don't do much anyway)
<courmisch>
muurkha: Lichee Pi4a
<muurkha>
aha, thanks!
<muurkha>
I should have thought of that, I have a Lichee around here
<sorear>
the Element Matrix Services bridge has been unmaintained for years due to EMS funding structures; there's a bridge being set up on the _whitelogger infrastructure which I might ask to do, but I'll only do if there are users
<sorear>
and I barely have a clue about matrix as a user
<muurkha>
o whitequark, thank you so much for everything
jmd_ has quit [Ping timeout: 250 seconds]
<dzaima[m]>
within the past ~two days, there are 5 matrix users (incl. me) with read indicators. but yeah the bridge situation on matrix is quite sad in general
<muurkha>
isn't it bad luck to have a CEO named Redmond?
<muurkha>
sorry, that was infantile, sorry
vgtw has joined #riscv
jmdaemon has joined #riscv
<Armand>
muurkha: But true.
<sorear>
what's the risc-v situation like on matrix outside of the bridge? looked over the last two weeks of #riscv:matrix.org on view.m.o and it doesn't look like a lot from people who actually have anything to do with riscv development
ars23 has quit [Quit: Leaving]
<dzaima[m]>
#riscv:matrix.org is a space (links to other rooms) so shouldn't have any messages
<sorear>
is there a way for the public to see what rooms a space links to? i was looking at the one that's bridged to telegram
<dzaima[m]>
#riscv-main:matrix.org is the biggest risc-v matrix room, but it's bridged to telegram from which >50% of the messages come; and I'd say it's of less, uh, quality, than this room
<sorear>
_curses out Zooko's triangle and matrix's choices therewith_
<dzaima[m]>
the space just links to that and #riscv-news:matrix.org, which practically doesn't have anything
unsigned has quit [Quit: .]
unsigned has joined #riscv
<muurkha>
sorear: you know, Satoshi consensus solved Zooko's Triangle
<sorear>
the correct definition of "decentralized" is tricky
<muurkha>
pre-Satoshi-consensus my definition was that decentralized systems are those that don't require consensus
<muurkha>
now my definition is that a decentralized system is one that nobody can be banned from by the choice of any person or small group
danilogondolfo has quit [Remote host closed the connection]
awita has quit [Remote host closed the connection]
djdelorie has quit [Ping timeout: 252 seconds]
djdelorie has joined #riscv
sorear changed the topic of #riscv to: If you use this channel via the public Matrix bridge, please register your interest before July 25th so that we can set up replacement bridging | RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
<sorear>
not sure anyone actually reads those but hopefully it'll help
<khem>
I use matrix bridge sorear
<sorear>
khem: do you intend to move to an IRC client or personal bridge after https://libera.chat/news/matrix-deportalling takes effect, or would you benefit from a new public bridge?
whitequark has joined #riscv
esv has quit [Remote host closed the connection]
esv has joined #riscv
<dzaima[m]>
(for what it's worth, I'd definitely prefer a public bridge to keep existing, it's just far from the end of the world if it doesn't, as far as my usage is concerned)
<khem>
I have been using IRC clients so its not a big deal to go back to past but it would be sad to loose the bridge
wingsorc has joined #riscv
vagrantc has joined #riscv
_catircservices has joined #riscv
sorear[m] has joined #riscv
whitequark[cis]1 has joined #riscv
whitequark[cis] has joined #riscv
whitequark[cis]1 has left #riscv [#riscv]
jmdaemon has quit [Ping timeout: 240 seconds]
<sorear[m]>
tap is this thing on
<whitequark>
yes
<Armand>
No.
<sorear[m]>
and I can grant Matrix-side admin rights to the other active ops (ping palmer, jrtc27) if they want it and have matrix IDs?
<whitequark[cis]>
the bridge will give IRC ops power level 50 by default, which lets them kick normal users and such
<whitequark[cis]>
let me join a test user from Matrix; an IRC op should be able to kick i
<whitequark[cis]>
s/i/it/
sorear changed the topic of #riscv to: Matrix users: #riscv:libera.chat will be ceasing operation NET Jul 25; please test #riscv:catircservices.org as a replacement | RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
staging-test2[m] has joined #riscv
<staging-test2[m]>
kick me
<Armand>
I think I'll stick with IRC.. this bridging stuff seems like a PITA. :P
staging-test2[m] was kicked from #riscv by sorear [staging-test2[m]]
<whitequark[cis]>
yep that worked just fine
<whitequark[cis]>
meaning that existing IRC ops do have control over Matrix infrastructure as-is
<whitequark[cis]>
oh, another thing to note for the ops: the bridge has running identd and each Matrix user gets their dedicated IPv6 address, those can be used in banmasks
<sorear>
I thnk something went wrong, my IRC->Matrix puppet never got elevated and so the topic change wasn't propagated to Matrix
<whitequark[cis]>
you need to authenticate through the bridge
sorear[m]1 has joined #riscv
<whitequark[cis]>
make sure you have `sorear[m]` grouped and then send `!storepass <password>` to `@appservice-irc:catircservices.org`
<whitequark[cis]>
or I guess !nick sorear[cis] then identify to nickserv then group nicks then !storepass
<whitequark[cis]>
since right now you're joined as sorear[m]1
<whitequark[cis]>
I think? I'm not sure which is which >_>
<sorear>
sorear[m]1 is passing through #riscv:libera.chat, sorear[m] is #riscv:catircservices.org
<whitequark[cis]>
oh okay
<whitequark[cis]>
anyway yeah, identify to nickserv, group as wanted, storepass, then you'll be elevated
<sorear>
so an IRC-only user who gets opped by chanserv gets "level 50" which can kick users, we tested that, but not change the topic?
<whitequark[cis]>
hm
<whitequark[cis]>
I think I misunderstood what happened, let me investigate
<whitequark[cis]>
PL 50 should be able to change the topic. the bridge itself would change the topic here, and it has PL 70
<whitequark[cis]>
(the topic change is processed under the bridge account, I think)
<whitequark[cis]>
I... honestly don't know? this should work, as far as I can tell. could be a bug
sorear changed the topic of #riscv to: Matrix users: #riscv:libera.chat will be ending operation NET Jul 25; please test #riscv:catircservices.org as a replacement | RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
<whitequark[cis]>
I think it's just a bug
<jrtc27>
sorear[m]1: @jrtc27:matrix.org
<whitequark[cis]>
it's convinced this room doesn't exist, but only for topic change purposes
<jrtc27>
not that I really use it
<whitequark[cis]>
you can change the topic on the Matrix side and that'll propagate fine
<whitequark[cis]>
which is what I usually do, and so never noticed it
<jrtc27>
also cute server acronym :P
<whitequark[cis]>
sorear: you'd have to invite jrtc27 first to give them admin permissions I think
<whitequark[cis]>
jrtc27: thank you
<whitequark[cis]>
one potential issue is that an admin cannot demote another admin
<whitequark[cis]>
(only they themselves can demote themselves)
jrtc27[m] has joined #riscv
<whitequark[cis]>
broadly speaking only the channel founder should probably be PL 100 and the rest PL 99 or something
dzaima[m]1 has joined #riscv
<whitequark[cis]>
but none of this really concerns me as the bridge operator
<jrtc27[m]>
testing 1 2 3
<jrtc27>
seems good
<whitequark[cis]>
I lowered myself to 99 for now, I'll demote myself fully once this thing seems to work reliably
<whitequark[cis]>
oh, by the way, the room doesn't actually live on catircservices.org
<whitequark[cis]>
it's federated, meaning it exists equally there, on matrix.org, etc. and the bridge just happens to post to one of the federated instances, which propagates to others
<whitequark[cis]>
nothing stops you from e.g. using the EMS plumbed rooms instead of my bridge if you ever feel like it
<whitequark[cis]>
the room ID does have :catircservices.org as a suffix, confusingly, and it will have that forever, but that's just the name; it doesn't actually affect anything
<whitequark[cis]>
this is extremely confusing if your model for Matrix is that it works like IRC and not like a slightly faster version of Bitcoin
<jrtc27>
how does that work with PLs?
<jrtc27>
cis.org decides?
<whitequark[cis]>
I don't actually know
<jrtc27>
:D
<whitequark[cis]>
like I never set out to operate Matrix, IRC, or Matrix<>IRC bridges
<whitequark[cis]>
I just needed to communicate, didn't want to run a bouncer, and eventually got pissed off by libera.chat bridge being operated not well
<whitequark[cis]>
which is usually how i end up accidentally shipping pieces of infrastructure that later become critical
<whitequark[cis]>
my Ruby parser is like the de facto standard for the Ruby ecosystem and I've never used it in any of my own projects
Armand has quit [Quit: Leaving]
<whitequark[cis]>
I got really annoyed by the existing parsers, and then distracted.
<jrtc27>
getting really annoyed by the existing X and fixing/rewriting it, yup, that sounds familiar
<jrtc27>
me and the freebsd build system of late
<whitequark[cis]>
okay, I can change the topic on Matrix side but not on IRC side since I'm not a chanop
<jrtc27>
because who doesn't love working on build systems
<whitequark[cis]>
I deliberately left a stray | at the end so that eg sorear can try removing it
<whitequark[cis]>
jrtc27: yeah I remember building a gentoo-inspired Linux distribution towards the end of high school with a friend
<whitequark[cis]>
she later deployed it at her company because, uh
<jrtc27>
uhhh
<whitequark[cis]>
it was written in Ruby and minimized the amounts of forks compared to shell, yes?
<whitequark[cis]>
which meant it was able to build images much faster under Cygwin
<whitequark[cis]>
which is both the most batshit insane way in which someone used my software well outside its bounds, and the most batshit insane reason to use it in first place
Armand has joined #riscv
<whitequark[cis]>
I was really impressed
pecastro_ has quit [Ping timeout: 245 seconds]
<whitequark[cis]>
oh yeah it built a cross-compiler and then opkg packages for your embedded target and then the sysroot
<whitequark[cis]>
basically, buildroot but with more ruby and with a handwritten recursive constraint solver that took USE flags into consideration
dzaima[m] has quit [Remote host closed the connection]
<whitequark[cis]>
I didn't know about SAT back then so it was some truly horrific thing that only didn't busy loop most of the time. it was good enough apparently
sorear changed the topic of #riscv to: Matrix users: #riscv:libera.chat will be ending operation NET Jul 25; please test #riscv:catircservices.org as a replacement | RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
dzaima[m]1 is now known as dzaima[m]
sorear changed the topic of #riscv to: Matrix users: #riscv:libera.chat will be ceasing operation NET Jul 25; please test #riscv:catircservices.org as a replacement | RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
<whitequark[cis]>
sorear: I mean on the Matrix side
<whitequark[cis]>
if you edit the topic on the Matrix side it'll propagate to IRC
<sorear[m]>
oh, topic propagation is one-way? that explains why you were suggesting nickserv changes, one moment
<whitequark[cis]>
it's not supposed to be
<whitequark[cis]>
but it is one-way due to a bug in matrix-appservice-irc that for some reason isn't being tickled with :libera.chat Matrix rooks
<whitequark[cis]>
s/rooks/rooms/
<whitequark[cis]>
the idea of fixing matrix-appservice-irc bugs does not bring me joy, so I'm suggesting to just update it on the Matrix side
<whitequark[cis]>
which has a better UI anyway; I do not miss using /topic and pasting and it having a newline in the middle and pasting wrong
<sorear[m]>
expected? Unable to find profiles for the Matrix IDs listed below - would you like to start a DM anyway? // @nickserv:catircservices.org: Profile was not found
<whitequark[cis]>
the two "magic" names to know are @libera_<nick>:catircservices.org, and @appservice-irc:catircservices.org
<sorear[m]>
if I do nickserv HELP via matrix the response messages are delivered out of order, but that sounds like a known upstream bug
<whitequark[cis]>
yes
<whitequark[cis]>
it's infuriating
<whitequark[cis]>
it probably happens because someone uses second resolution for timestamps
<whitequark>
aha
sorear[m] changed the topic of #riscv to: Matrix users: #riscv:libera.chat will be ending operation NET Jul 25; please test #riscv:catircservices.org as a replacement | RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
<whitequark[cis]>
yep that worked
<whitequark[cis]>
all right, I'm signing off for today; if the bridge misbehaves while I'm asleep (unlikely) you have enough power level to just kick or ban it
<sorear>
got it
<whitequark[cis]>
I'm not sure whether that automatically stops it from working or it checks for that, but as far as I know it should stop doing... whatever it would be doing
<whitequark[cis]>
I guess the main point of misbehavior would be on the IRC side (I meant on Matrix above) since almost everyone's on IRC
<whitequark[cis]>
where you can always just ban the subnet or the hostname
jmd_ has joined #riscv
<whitequark[cis]>
the metrics look perfectly healthy so far