<_whitenotifier-6>
[GlasgowEmbedded/glasgow] attie 7e809cc - README: amaranth depends on py3.8, so follow suit
<_whitenotifier-6>
[GlasgowEmbedded/glasgow] attie 624b387 - README: convert py3.7 specific steps into generic py3 steps, and list oldest Debian and Ubuntu versions supported
<_whitenotifier-6>
[GlasgowEmbedded/glasgow] ... and 2 more commits.
<whitequark>
mwk: it's almost certainly an issue with the DPLL
<whitequark>
I never quite tuned it right
<mwk>
(also it's slow as fuck, being in Python and running on ... this cursed laptop)
<whitequark>
the plan was to prototype in Python and then port to HDL
<whitequark>
and not actually run it in Python
<whitequark>
but the port to HDL never happened
<mwk>
oh.
<mwk>
hm.
<mwk>
I thought dumping the raw magnetic data was supposed to be a feature?
<whitequark>
yea like, i had 0 confidence in my DSP skill
<whitequark>
mwk: as *an* option, yes
<whitequark>
as the option, no
<whitequark>
I was thinking of being able to mount the floppy as an nbd device
<mwk>
mhm!
<mwk>
I see
<mwk>
... and that'd also involve a write path
<mwk>
or not?
<whitequark>
yea
<mwk>
that'd be cool
<whitequark>
it would; to do writes you do need to have the DPLL in hardware
<whitequark>
to sync to the header
<whitequark>
this is why it's currently lacking
<mwk>
yeah, figured
<mwk>
anyway!
<mwk>
I think it's PR time
<d1b2>
<attiegrande> i'm intrigued my merge queues... not entirely sure what they're for(?)
<whitequark>
attiegrande: it's two things
<whitequark>
first: with normal PRs, unless you force every PR to be up to date to be mergeable, the code that greenlights the PR and the code that ends up in the main branch are different
<whitequark>
meaning, you can end up with a broken main
<whitequark>
and if you force every PR to be up to date, this creates an incredible amount of pointless churn for PR authors
<whitequark>
second: there are projects that use hours or days worth of compute for every single build
<whitequark>
and you really do not want to be trapped in the update-PR-and-pray-no-one-races-with-you loop
<whitequark>
like, it can make time-to-merge be measured in weeks for purely workflow reasons
<whitequark>
rust family projects popularized this, the bots were called bors and homu
<d1b2>
<attiegrande> i had a read of their docs, but couldn't quite see the real benefit - perhaps i've not been exposed to bigger projects enough
<whitequark>
the first benefit is the real one
<whitequark>
as in, if you do not ensure through policy or workflow that tests on main always succeed at the point of push, you are being fundamentally unserious about software development
<d1b2>
<attiegrande> ohh, hang on. it tests/checks the PR itself, and where previously you'd click "merge" even if the branch had moved forward... we now put it in the queue, and it's retested before it's merged?
<whitequark>
like you know how industrial accidents unfold, right? normalization of deviance
<d1b2>
<attiegrande> duh, that makes a lot of sense
<whitequark>
d1b2: yes
<whitequark>
in addition it can batch green PRs so that you don't retest every single one individually
<d1b2>
<attiegrande> yeah, i get it now
<d1b2>
<attiegrande> thanks 🙂
<whitequark>
eg if you have three PRs approved in the span of 5 minutes right now, it'll batch all 3
<d1b2>
<attiegrande> the way it just jumped on re-testing surprised me (i didn't click "okay i'm ready, run the queue")
<d1b2>
<attiegrande> but I guess it'll do the first immediately, and then the next two together (in your 3x up example)
<whitequark>
I think there are configuration options for this or sth
<d1b2>
<attiegrande> yeah, makes sense
<mwk>
alright, so about migrating off compat... if I understand correctly, the deadline is close enough that it'd be actually desired to have an untested PR for an applet that I have no means of testing?
<_whitenotifier-6>
[GlasgowEmbedded/glasgow] attie 49ee8ab - README: amaranth depends on py3.8, so follow suit
<_whitenotifier-6>
[GlasgowEmbedded/glasgow] attie 41520af - README: convert py3.7 specific steps into generic py3 steps, and list oldest Debian and Ubuntu versions supported
<_whitenotifier-6>
[GlasgowEmbedded/glasgow] ... and 2 more commits.
<mwk>
oh.
<mwk>
wrong branch, nvm
<mwk>
okay, there's only one spurious, program-xc6s
<mwk>
the non-spurious ones left: audio.yamaha_opx, memory.onfi, video.rgb_input
<mwk>
and I think there was a PR for rgb_input already?
<mwk>
there is
<whitequark>
it's kind of cursed
<whitequark>
I would frankly prefer to close it and delegate to you
<mwk>
huh.
<mwk>
fair enough
<whitequark>
I can actually test that particular PR, I have the GameBoy hardware it's written for
<mwk>
... oh, there's a FSM with a ResetInserter
<_whitenotifier-6>
[GlasgowEmbedded/glasgow] whitequark deleted tag omigen
<_whitenotifier-6>
[GlasgowEmbedded/glasgow] attie 49ee8ab - README: amaranth depends on py3.8, so follow suit
<_whitenotifier-6>
[GlasgowEmbedded/glasgow] attie 41520af - README: convert py3.7 specific steps into generic py3 steps, and list oldest Debian and Ubuntu versions supported
<_whitenotifier-6>
[GlasgowEmbedded/glasgow] ... and 2 more commits.
<mwk>
whitequark: actually, how would one deal with that FSM in idiomatic amaranth?
<whitequark>
well,
<whitequark>
i have bad news
<mwk>
I can't access m.next outside of a state; the ways I can see are: 1) direct assignment to fsm's state signal, 2) a new domain for the FSM, 3) add reset test in every state, 4) ... what that PR is doing
<mwk>
2) seems the last cursed now that I think of it?
<mwk>
anyway, I... don't understand how this applet works at all
<mwk>
it doesn't match the data sheet of the LCD mentioned in the help message at all, for one; does it require some custom circuitry between that thing and glasgow?
<mwk>
in particular I don't understand what SKIP-FIRST-PIXEL is doing, or the strange wraparound behavior when it actually hits row == self.rows
<mwk>
test_build (glasgow.applet.interface.analyzer.AnalyzerAppletTestCase) ... ERROR: Max frequency for clock 'cd_sync_clk_if_0__i_$glb_clk': 29.10 MHz (FAIL at 30.00 MHz)
<mwk>
sigh :/
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
Guest52 has joined #glasgow
Guest52 has quit [Client Quit]
redstarcomrade has quit [Read error: Connection reset by peer]