ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at
<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]
<_whitenotifier-3> [nmigen/nmigen] whitequark 695a9f0 - back.pysim: optionally allow introspecting generated code.
<whitequark> wait that doesn't actually work
<_whitenotifier-3> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-3> [nmigen/nmigen] whitequark 8d0c042 - back.pysim: optionally allow introspecting generated code.
<_whitenotifier-3> [nmigen] Failure. 81.16% (-1.32%) compared to 5ae8791 -
<_whitenotifier-3> [nmigen] Failure. 62.5% of diff hit (target 82.47%) -
<_whitenotifier-3> [nmigen] Failure. 81.16% (+-1.32%) compared to 5ae8791 -
<_whitenotifier-3> [nmigen] Failure. 62.50% of diff hit (target 82.47%) -
<_whitenotifier-3> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-3> [nmigen/nmigen] whitequark 377f2d9 - back.pysim: optionally allow introspecting generated code.
<_whitenotifier-3> [nmigen] Failure. 80.85% (+-1.62%) compared to 5ae8791 -
<_whitenotifier-3> [nmigen] Failure. 60.00% of diff hit (target 82.47%) -
<whitequark> ok it does now.
<_whitenotifier-3> [nmigen] Success. 82.55% (+0.07%) compared to 5ae8791 -
<_whitenotifier-3> [nmigen] Failure. 60% of diff hit (target 82.47%) -
<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' -
<_whitenotifier-3> [nmigen] whitequark edited a comment on issue #325: pysim TypeError: unsupported operand type(s) for &: 'tuple' and 'int' -
<whitequark> lol
<_whitenotifier-3> [nmigen] Failure. 82.4% (-0.08%) compared to 5ae8791 -
<whitequark> what's wrong with travis anyway. the statuses never actually reach the notifier
<awygle> oh wow that's much more minimal than my minimal case lol
<whitequark> looks like notifico doesn't understand what "check runs" are?
<whitequark> hey, who here likes fuzz and/or property testing (of Python code)?
<whitequark> nmigen should be undergoing randomized testing of *some* kind
<awygle> I was with you until the parenthetical
<whitequark> well
<whitequark> i'm wondering if i should use Hypothesis, some of the QuickCheck ports, or just roll my own AST generator
<whitequark> the latter has the disadvantage of requiring a reducer too
cr1901_modern1 has joined #nmigen
cr1901_modern has quit [Disconnected by services]
<whitequark> incidentally, you know what's silly? that __repr__ returns whatever weird lispy thing it does
<whitequark> i'm not even sure why it does
cr1901_modern1 is now known as cr1901_modern
cr1901_modern is now known as cr1901_modern1
cr1901_modern1 is now known as cr1901_modern
cr1901_modern is now known as cr1901_modern1
<_whitenotifier-3> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-3> [nmigen/nmigen] whitequark ec7aee6 - back.pysim: fix RHS codegen for Cat() and Repl(..., 0).
<_whitenotifier-3> [nmigen] whitequark closed issue #325: pysim TypeError: unsupported operand type(s) for &: 'tuple' and 'int' -
cr1901_modern1 is now known as cr1901_modern
<_whitenotifier-3> [nmigen] Failure. 82.27% (+-0.14%) compared to 377f2d9 -
<_whitenotifier-3> [nmigen] Success. 100.00% of diff hit (target 82.40%) -
<_whitenotifier-3> [nmigen] Success. 82.56% (+0.15%) compared to 377f2d9 -
<_whitenotifier-3> [nmigen] Success. 100% of diff hit (target 82.4%) -
<_whitenotifier-3> [nmigen] Success. 82.43% (+0.02%) compared to 377f2d9 -
<_whitenotifier-3> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-3> [nmigen/nmigen] whitequark a14a572 - hdl.ast: fix off-by-1 in Initial.__init__().
<awygle> nice! thanks for the fix
<_whitenotifier-3> [nmigen] Failure. 82.27% (+-0.16%) compared to ec7aee6 -
<_whitenotifier-3> [nmigen] Success. 100.00% of diff hit (target 82.43%) -
<_whitenotifier-3> [nmigen] Success. 82.56% (+0.13%) compared to ec7aee6 -
noobos has joined #nmigen
esden has quit [Ping timeout: 248 seconds]
futarisIRCcloud has quit [Ping timeout: 248 seconds]
daveshah has quit [Ping timeout: 248 seconds]
_florent_ has quit [Ping timeout: 248 seconds]
esden has joined #nmigen
futarisIRCcloud has joined #nmigen
daveshah has joined #nmigen
_florent_ has joined #nmigen
<emily> whitequark: hypothesis is good
<emily> it is a quickcheck port
<emily> yuriks used it to do some testing of nmigen code already
<emily> as in, simulation testing
<emily> like I would say that hypothesis is a better quickcheck than haskell's.
noobos_ has joined #nmigen
noobos has quit [Ping timeout: 260 seconds]
<whitequark> hm, would it be good at generating random ASTs and minimizing failures?
<emily> yes
<emily> you'll need to write your own adapter code obviously, but yes.
<emily> IIRC hypothesis specifically has a lot of improvements on minimization over quickcheck
<emily> minimizing failure cases is a big part of what writing a good quickcheck implementation comes down to
<emily> it has very good docs imo, you can probably figure out what you'd need to do quickly
<whitequark> sweet, thanks
noobos_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
noobos has joined #nmigen
ronyrus has joined #nmigen
noobos has quit [Quit: Textual IRC Client:]
<_whitenotifier-3> [nmigen-soc] jfng opened issue #10: Peripheral API design: exposing bus interfaces -
alexhw_ has joined #nmigen
alexhw has quit [Quit: - Chat comfortably. Anywhere.]
Asu has joined #nmigen
<_whitenotifier-3> [nmigen-soc] awygle commented on issue #10: Peripheral API design: exposing bus interfaces -
<_whitenotifier-3> [nmigen] awygle opened issue #326: __repr__ implementation for Layout -
<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> +def deprecated(message: Union[str, Warning], stacklevel: int = 2) -> \
<emily> + Callable[[Callable[..., T]], Callable[..., T]]:
<emily> + def decorator(f: Callable[..., T]) -> Callable[..., T]:
<emily> true beauty.
<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> ( 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
<_whitenotifier-3> [nmigen-soc] jfng commented on issue #10: Peripheral API design: exposing bus interfaces -
<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 -