<whitequark>
awygle: cool! FIFO and memory stuff is all yours, enum stuff I might pick up depending on how it goes but I currently have more important task
<whitequark>
Degi: how do you want to use them?
<awygle>
:D
proteus-guy has joined #nmigen
Stary has quit [Ping timeout: 264 seconds]
Stary has joined #nmigen
<_whitenotifier-3>
[nmigen] whitequark commented on issue #254: Find solution to translate values to strings for Symbiyosys vcd files - https://git.io/Jfenw
anuejn_ has joined #nmigen
vup2 has joined #nmigen
MadHacke1 has joined #nmigen
zignig_ has joined #nmigen
MadHacker has quit [*.net *.split]
vup has quit [*.net *.split]
zignig has quit [*.net *.split]
anuejn has quit [*.net *.split]
____ has joined #nmigen
chipmuenk has joined #nmigen
<_whitenotifier-3>
[nmigen] whitequark commented on issue #252: Windows Batch is horrible; PowerShell is nicer - https://git.io/Jfecx
<_whitenotifier-3>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JfeCu
<_whitenotifier-3>
[nmigen] whitequark commented on issue #252: Windows Batch is horrible; PowerShell is nicer - https://git.io/JfeWI
thinknok has joined #nmigen
<_whitenotifier-3>
[nmigen] whitequark commented on issue #217: r_data is undefined after a simultaneous write to an empty AsyncFIFO - https://git.io/Jfe88
Asu has joined #nmigen
thinknok has quit [Ping timeout: 265 seconds]
<_whitenotifier-3>
[nmigen] programmerjake commented on issue #252: Windows Batch is horrible; PowerShell is nicer - https://git.io/Jfe40
<_whitenotifier-3>
[nmigen] whitequark commented on issue #252: Windows Batch is horrible; PowerShell is nicer - https://git.io/Jfe4o
david-sawatzke[m has quit [Quit: killed]
emily has quit [Quit: killed]
jfng has quit [Quit: killed]
Vinalon has quit [Ping timeout: 240 seconds]
jfng has joined #nmigen
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
david-sawatzke[m has joined #nmigen
emily has joined #nmigen
thinknok has joined #nmigen
thinknok has quit [Read error: Connection reset by peer]
thinknok has joined #nmigen
MadHacke1 is now known as MadHacker
<_whitenotifier-3>
[nmigen] FFY00 commented on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/Jfead
<_whitenotifier-3>
[nmigen] whitequark commented on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/JfeXM
<anuejn_>
whitequark: it would be great if there was a possibility to create a module that is automagically added to the submodules of the module that was last recently used
<anuejn_>
i think it was discussed (or proposed by you?) a few days ago
<anuejn_>
should i file an issue on that?
<whitequark>
I think that is a very slippery slope in terms of design
<whitequark>
regardless of the design aspect, it cannot be implemented reliably with the current term rewriting system
<whitequark>
so let's discuss it once that's fixed
<anuejn_>
term rewriting system?
<whitequark>
a way in which code is handled internally in nmigen
<anuejn_>
ah ok
<anuejn_>
i see
<whitequark>
it's something i inherited from omigen and did not consider very carefully back then
<whitequark>
and it really needs complete rewriting
<anuejn_>
should i just come again in a few month or is there anything i can do?
<whitequark>
i think the former, my plate is quite full so even if we decide on something, it is unlikely to be usable in short term
<anuejn_>
ok
<whitequark>
for now, workarounds exist (pass the module around) if inelegant
<whitequark>
i am well aware of the issue but there is no obvious solution to it
<anuejn_>
is the same thing true if i want to express my thoughts on some redesign of Records?
<whitequark>
go ahead
<whitequark>
some context: the current Records are pretty much just bitfield structs
<whitequark>
(where each bitfield is its own Signal)
<whitequark>
my current position is that any use of a Record that is not intended to pack together some related data to handle it all at once, is likely a misuse
<whitequark>
but i am open to your thoughts
<anuejn_>
ok, so my main problem with records is that there is a lot of dynamic python foo going on (via __getattr__ and having a seperate fields) which screws a lot with static analysis
<anuejn_>
so i am currently using just plain python classes which all inherit from one marker class to do bundly my signals
<Sarayan>
shouldn't static analysis be done at the rtlil level?
<anuejn_>
ah static analysis at the python level i.e. in IDEs
<anuejn_>
but my approach has the problem, that it doesnt play nice with the rest of the nmigen ecosystem (obviously)
<Sarayan>
ok
<whitequark>
hmmm
<_whitenotifier-3>
[nmigen] mithro commented on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/JfeMv
<anuejn_>
and even if anybody would just use classes to bundle signals, it would be not obvious what such a bundle class is
<whitequark>
would you prefer something more like dataclasse?
<anuejn_>
yup thats exactly what i wanted to describe
<whitequark>
okay, i hear tha
<whitequark>
*that
<whitequark>
in fact i have seen people in the past reinvent something quite dataclass-like
<whitequark>
i haven't considered this as an option before, and i like your proposal
<anuejn_>
yeah i am currently doing that too
<whitequark>
i'll have to see how it plays together with our 3.6 version requirement
<whitequark>
however, there is one significant issue
<whitequark>
what about records parameterized by width?
<whitequark>
can you write this in a way that plays nice with vscode etc?
<whitequark>
by the way, if you have not realized it yet, by inheriting from nmigen.hdl.ast.UserValue, you can make something that is as first-class as a Record
<anuejn_>
we could just overwrite the constructor of the dataclass, cant we?
<whitequark>
but will your tools understand that a given field has type Signal(addr_width) ?
<anuejn_>
it will list all the (maybe not really present) fields
<anuejn_>
so you will get autocomplete for these as well
<whitequark>
hm.
<whitequark>
so you're just looking to expose to the IDE a list of fields?
<whitequark>
you don't care about their types?
<anuejn_>
and for the width of tools it is not really a concern, because that is not preserved at all currently, since the type of a signal is simply 'Signal' and not generic over its width
<Degi>
whitequark, re renaming FPGA balls: Like instead of having to use for example A5 that you can use UART1_rx or so
<whitequark>
Degi: that's what resources are for, no?
<whitequark>
you define a Resource("uart", 1, Subsignal("rx", ...))
<anuejn_>
whitequark: i think your example is not quite complex enough to cover all the edge cases
<anuejn_>
what might be a problem is where a constructor argument really has an effect on the type of a field
<whitequark>
Signal should be generic over its width, really
<whitequark>
it is just not hooked up to python typing machinery
<anuejn_>
yup
<whitequark>
so in my example, there *is* an effect on the type of a field
<whitequark>
it is just not visible at the moment
<anuejn_>
okay, i see what you mean :)
<anuejn_>
but even then, a signal of with 1 feels the same as a signal of with 8 (has the same fields) and therefore is quite similiar in regards of ide-foo
<whitequark>
I would say seeing the widths of signals in an IDE is quite important
<whitequark>
it is something I have to think a lot while writing nMigen code
<anuejn_>
ok i just tried what happens if i change the type of a field depending on a constructor parameter and my ide (pycharm) just assumes it has the type of the last assigned thing
<anuejn_>
which is bad
<whitequark>
unfortunate
<anuejn_>
so we would need to help it with further manual annotation
<anuejn_>
(in those cases)
<anuejn_>
but for less complex ones (and even for the complex ones) it would still bring great improvements for my workflow because i dont have to remember all my hierarchical records anymore (yay)
<anuejn_>
re UserValue nice, thanks :). But one of my concerns is that if i roll my own shit, it is not really interoperable with other peoples code.
<whitequark>
define interoperable
<_whitenotifier-3>
[nmigen] emilazy commented on issue #252: Windows Batch is horrible; PowerShell is nicer - https://git.io/JfeMF
<_whitenotifier-3>
[nmigen] whitequark opened issue #354: Inherit `Record` from `UserValue` - https://git.io/JfeMN
<anuejn_>
hm... pass it in all places where i could pass a record?
<whitequark>
UserValue will let you do that
<anuejn_>
ok nice :)
<_whitenotifier-3>
[nmigen] whitequark commented on issue #252: Windows Batch is horrible; PowerShell is nicer - https://git.io/JfeD0
<_whitenotifier-3>
[nmigen] whitequark closed issue #252: Windows Batch is horrible; PowerShell is nicer - https://git.io/JfeDE
proteus-guy has quit [Remote host closed the connection]
proteus-guy has joined #nmigen
<anuejn_>
whitequark: should i try to work on https://github.com/nmigen/nmigen/issues/354 or do you think it is the kind of issue, that is easier for you to implement than to review?
<whitequark>
anuejn_: feel free to
pinknok has joined #nmigen
thinknok has quit [Ping timeout: 256 seconds]
<_whitenotifier-3>
[nmigen] whitequark opened issue #355: [RFC] Redesign UserValue to avoid breaking code that inherits from it - https://git.io/Jfeyi
<awygle>
an nmigen with an explicit Ports struct for modules is interesting to think about
<awygle>
err object I guess
<whitequark>
awygle: that's a bit of a far future thing
<whitequark>
but yes
<whitequark>
definitely necessary
<_whitenotifier-3>
[nmigen] FFY00 commented on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/Jfey9
<awygle>
I gotta figure out why I don't get pings anymore
<awygle>
Maybe I left myself signed in on my work computer before going to wfh
<_whitenotifier-3>
[nmigen] mithro commented on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/JfeHf
<_whitenotifier-3>
[nmigen] FFY00 commented on pull request #349: setup.py: add "wheel" to setup_requires - https://git.io/JfeHG
futarisIRCcloud has joined #nmigen
<_whitenotifier-3>
[nmigen] WRansohoff commented on issue #341: nMigen should avoid emitting very large wires that cause issues in Yosys - https://git.io/JfeQO