<awygle>
whitequark: can you clarify what you meant by "Record.connect is probably fatally flawed"?
<whitequark>
a combination of trying to do too much (all the include/exclude functionality) and too little (that functionality doesn't actually help you in most cases)
<whitequark>
in migen, Record.connect served two roles. first, it let you make easy connections between flow graph nodes. note that this is 1:1.
<whitequark>
second, it was used in Wishbone and CSR code, where the misoc modules were well-behaved (zeroed their data out, flag out, etc when not addressed)
<whitequark>
the problem is that Record.connect cannot even handle general Wishbone, and that it's not useful in nmigen-soc CSR code because it needs explicit multiplexing anyway
<whitequark>
so the only thing it *is* useful for is 1:1 connections between streams, for which it is ridiculously overcomplicated
<awygle>
i see. and by 1:1 here you mean "both streams carry exactly the same Record as payload"?
<whitequark>
i mean that there's no fanout
<awygle>
(as opposed to fanin/fanout)
<whitequark>
when Record.connect was used in misoc, you could connect multiple Wishbone endpoints together, not just two
<whitequark>
in a sort of ad-hoc not-really-compliant way
<awygle>
... huh.
<awygle>
that seems fraught
<whitequark>
yes.
<whitequark>
that's basically what I mean by "fatally flawed"
<whitequark>
it's an attractive nuisance
<awygle>
so if you had a clean sheet to do it again, what would you change? eliminate the include/exclude stuff?
<whitequark>
it leads you into adding implicit preconditions to your code so that it's more shaped like Record.connect
<whitequark>
well, here's the problem: I'm not actually sure
<whitequark>
I haven't thought about this really deeply so far
<awygle>
maybe Record.connect should die and we should have Stream.connect instead (of course we'd have to have a Stream first :p)
<awygle>
anyway, thank you for communicating the issues to me
<whitequark>
yes, I'm pretty certain that it would involve member methods for the simple case (otherwise it'd just be a normal module)
<whitequark>
it's not clear what the interface of this method should be
<awygle>
i am planning over the next few days (subject to change of course) to put together a draft of an nmigen Stream interface for us to throw darts at
<whitequark>
it might make sense for it to take a Module so that it could do m.d.comb itself (therefore being misuse resistant) or even be refactored to use a submodule if ever necessary
<whitequark>
but methods that take modules aren't currently part of convention and it looks like there could be footguns related to the state inherent in Module
<awygle>
if you'd like, i can keep it to myself until you're ready for it (i know you're busy)
<whitequark>
with m.If(foo): foo.connect(m, bar) # ehhhh...
<whitequark>
feel free to post it on the issue tracker, more eyes are good
<awygle>
okay, will do
<whitequark>
I encourage discussing it with jfng who is working closely on SoC stuff
<awygle>
i figured i would ping ktemkin as well, as they expressed interest
<whitequark>
certainly
<awygle>
i basically decided it would be hard for me to continue discussing it in abstract, and if i wanted to have any more insights i needed to implement something (or try to), hence this drafting effort
<whitequark>
yes, that sounds good
<awygle>
as an aside - i feel discouraged from commenting several times consecutively on an issue because i know that github and whitenotifier will both notify everyone else (specifically wq). should i embrace this feeling and strive to cut down noise, or ignore it and share information as it comes?
<awygle>
(the answer is "both to some degree", so really i'm asking which way i should lean)
<whitequark>
comment however is convenient, it's not an issue for me
<awygle>
mk, noted
<whitequark>
i get pinged from several hundreds of repositories, i can (have to) manage this
<awygle>
that makes sense
<awygle>
hundreds? dang, i knew you were prolific but still, dang
<awygle>
that sounds rough
<whitequark>
i think it's around 200? 130 of them are mine, though half of those are archived
<whitequark>
so maybe more like 100-150
<whitequark>
the quantity doesn't matter so much anyhow as i think the volume follows something like power law
<awygle>
sure
<_whitenotifier-3>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/Jv4xB
<awygle>
that makes me feel much better about my two failed repro attempts on that bug yesterday, tbh
<_whitenotifier-3>
[nmigen] whitequark commented on issue #325: pysim TypeError: unsupported operand type(s) for &: 'tuple' and 'int' - https://git.io/Jv4x1
<_whitenotifier-3>
[nmigen] whitequark edited a comment on issue #325: pysim TypeError: unsupported operand type(s) for &: 'tuple' and 'int' - https://git.io/Jv4x1
<_whitenotifier-3>
[nmigen-soc] awygle commented on issue #10: Peripheral API design: exposing bus interfaces - https://git.io/JvBWO
<_whitenotifier-3>
[nmigen] awygle opened issue #326: __repr__ implementation for Layout - https://git.io/JvBWw
<awygle>
emily: are you knowledgable about python type annotations/mypy?
<emily>
awygle: kkkkkind of
<emily>
awygle: as in, I started learning them by diving into the deep end of trying to annotate all of nmigen ages ago
<emily>
so I definitely know too much about how cursed it is
<awygle>
it seems less intuitive than i would have hoped. 1) mypy complains it can't find a module named nmigen, thus i can't define a NewType of Signal 2) python seems to need me to already have defined a class before i can type-annotate a method, meaning that if class A has a method which takes a B and class B has a method which takes an A i'm out of luck
<awygle>
are those two things both correct, or am i fucking it up?
<emily>
uhh, the first sounds like either a PYTHONPATH issue or you have to pass some flag to make it ignore modules without type annotations, I forget which
<emily>
you can do forward-references with 'Strings', yes it's gross
<awygle>
--ignore-missing-imports makes it ignore the missing nmigen module but then Signal becomes of type Any so i can't make a newtype :(
<emily>
awygle: not sure then... I don't think you have to annotate absolutely everything to get it to work but maybe you do ._.
<emily>
I started annotating nmigen before ever really writing anything in nmigen, because of course I did
<awygle>
mood
<awygle>
arright well, Basically Fuck This then and i'll just use the type annotations as documentation and figure the rest out later
<emily>
(https://clbin.com/9Er3S on the off-chance that anyone thinks they'll get around to completing it before I do, but tbh it's for a year-old nmigen so it'd probably be annoying to base on)
<awygle>
already too many yaks deep on this by about four
<emily>
+T = TypeVar('T')
<emily>
oh yes, you just kind of declare type variables arbitrarily
<emily>
it has no relation to, like, where the quantifier/scoping for that variable is
<emily>
rereading this is just reminding me of how much I grew to hate the python type system using it
<awygle>
[09:36:42] <awygle> mood
<awygle>
i should go to work anyway. thanks for the SAN check
<emily>
whitequark: these were also in my typing branch, dunno if still relevant but https://clbin.com/zwBZz
<_whitenotifier-3>
[nmigen-soc] jfng commented on issue #10: Peripheral API design: exposing bus interfaces - https://git.io/JvB8f
<awygle>
so if i'm writing a method i can return a list of operations (this is basically how Record.connect works), but is there a way for that list to include conditional statements? that doesn't seem compatible with the context-manager method of doing conditionals
<awygle>
i guess i could use a Mux
<whitequark>
yes, Mux exists for that
<awygle>
i seem to be getting a typeerror that Mux isn't an nMigen statement... wonder what i'm doing wrong
<awygle>
oh of course
<awygle>
have to assign it to something
attie has joined #nmigen
Asu has quit [Ping timeout: 265 seconds]
<_whitenotifier-3>
[nmigen-soc] jfng commented on issue #10: Peripheral API design: exposing bus interfaces - https://git.io/JvB2N