sb0_ changed the topic of #m-labs to: https://m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
kristianpaul has joined #m-labs
kristianpaul has quit [Quit: leaving]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #m-labs
_whitelogger has joined #m-labs
_whitelogger has joined #m-labs
sb000 has joined #m-labs
<sb000> fwiw I also don't think * is particularly harmful
<sb000> and is
<sb000> and it is convenient
<sb000> artiq is a somewhat large non-hdl python codebase, and there haven't been many issues with *
<sb000> hardware bugs, and sayma in particular, are far worse in terms of time wasted and frustration
<sb000> problems with * are generally deterministic, and there is good visibility
sb000 has quit [Ping timeout: 256 seconds]
<whitequark> "pyflakes is not broken: the practice of "import *" is so broken as far as type-checking and import-checking is
<whitequark> concerned that *no* tool could possibly do the job of verifying whether the code containing an "import *" is formally correct."
<whitequark> this is spoken by someone who cannot make good tools, and looking for an excuse.
<whitequark> maybe the other parts you are saying are true. this one is not.
<whitequark> and yes. no one in python is remotely capable of making good tools.
<whitequark> i had to write a parser to get minimally decent diagnostics, how fucked up is that?
<whitequark> (also, why is "formally correct" even mentioned here? linters do not verify anything as formally correct, or even incorrect, they just suggest things, frequently in error.)
<whitequark> and in case you are wondering about my qualification, this all started when i wrote a tool that would compile a subset of ruby (including metaprogramming and such) to native executable code via a muxture of static analysis and abstract interpretation
<whitequark> `import *` would be one of the singular easiest features to implement in a static analysis tool. it presents no challenge at all.
<whitequark> actually, writing static analysis tools for python is so absurdly easy (for a dynlang, anyway) that it should have some of the best tooling (for dynlangs) in existence. and yet what exists is pathetic.
<whitequark> instead of a tool that would *reformat* (again, extremely regular and easy to work with) python syntax to fit an arbitrary column width limit, you have a tool that *complains* to the developer that the *developer* should fix it, or add fucking newlines?
<whitequark> just fix the code. what sort of idiot makes a tool that, instead of using the common codebase and capabilities of a machine to *fix* the formatting that it *knows* how to fix, instead decides to waste time of many thousands of developers *telling* them to fix it?
<whitequark> ah yeah, it's because python didn't have a tooling-grade parser before i wrote it. nevermind.
<whitequark> (yes, i know autopep8 exists. it is not reliable, and the whole point is that *only* autopep8 should exist.)
<cr1901_modern> attie: That "miracle of the fishes" line is really _REALLY_ good
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 2 commits to master [+0/-0/±3] https://git.io/fhTlb
<_whitenotifier-6> [m-labs/nmigen] whitequark b4fbef6 - back.rtlil: clarify $verilog_initial_trigger behavior. NFC.
<_whitenotifier-6> [m-labs/nmigen] whitequark 54e3195 - hdl.dsl: implement FSM.
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/472282253?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. 79.79% (+0.32%) compared to 010ddb9 - https://codecov.io/gh/m-labs/nmigen/commit/54e3195dcb5e5925507d2dd83e2d8ddec273551d
<_whitenotifier-6> [nmigen] Success. 100% of diff hit (target 79.47%) - https://codecov.io/gh/m-labs/nmigen/commit/54e3195dcb5e5925507d2dd83e2d8ddec273551d
<key2> what is the fsm._flush() ?
<whitequark> its irrelevant to consumers of the library
<key2> k
<key2> so fsm are done ?
<whitequark> mostly
<key2> thats a good news :)
<key2> you managed to do it as a primitive then
<whitequark> sure
<whitequark> that was always the plan
<key2> when you do m.next = "FIRST" you are in the context, right ?
<key2> i mean if you have an FSM in an FSM, there won't be any confusion
<whitequark> yeah
<whitequark> it'll refer to innermost
<key2> k
<key2> and how would you from second fsm change the state of first fsm?
<whitequark> you can't
<key2> :)
<key2> u'd have to use an intermediate signal
<key2> that second fsm assign and first fsm sees
<key2> at the same time u'd tel lme it's like using a "break" when you have 2 cascaded loop in c
<whitequark> rust has a construct like
<whitequark> 'outer while foo { while bar { break 'outer } }
<key2> rust is not that rustic :)
<key2> so what's missing in fsm ? as u said mosly done
<whitequark> a way to get the state signal and encoding
<key2> encoding meaning ?
<whitequark> map from state names to numbers
<key2> ahh
<key2> also, there would be a way to have a debug thing so a signal would have the name of the state /
<key2> a bit like migen does currently ?
<key2> when simulating, we can see the name of the state in gtkwave
<whitequark> yeah, I forgot to put that in
<key2> it could be just a Switch/case that is added on debug
<whitequark> nah
<whitequark> there is no debug or nondebug mode in nmigen and there will never be
<whitequark> just like there will never be synthesis/non-synthesis mode
<key2> then how would u
<whitequark> nmigen simulator supports this natively and with gtkwave this can be done by filter processes
<whitequark> or filter files
<key2> yeah but then it means you'd generate filter files along
<whitequark> yes
<key2> so u'd need to openthe gtkw file
<whitequark> yes
<key2> which has the filter applied
<key2> fair enough
<key2> filter files are executable files in fact ?
<key2> to which gtkwave sends/receive data through a pipe on stdin/out
<key2> ?
<whitequark> that is filter processes
<whitequark> there are also plain text mapping files
<whitequark> filter processes are useful for e.g. disassemblers
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhT4a
<_whitenotifier-6> [m-labs/nmigen] whitequark 72039b6 - hdl.dsl: add signal decoder to FSM state signal.
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/472290821?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Failure. 79.77% (-0.03%) compared to 54e3195 - https://codecov.io/gh/m-labs/nmigen/commit/72039b607283d9f0f83e78d70c026075169dccbf
<_whitenotifier-6> [nmigen] Failure. 50% of diff hit (target 79.79%) - https://codecov.io/gh/m-labs/nmigen/commit/72039b607283d9f0f83e78d70c026075169dccbf
rohitksingh has joined #m-labs
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to master [+1/-0/±1] https://git.io/fhTBc
<_whitenotifier-6> [m-labs/nmigen] whitequark 597d778 - examples: add an FSM usage example (UART receiver).
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/472295649?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. 79.77% remains the same compared to 72039b6 - https://codecov.io/gh/m-labs/nmigen/commit/597d778cf6cbc8cd90312ab280f9067531437972
<_whitenotifier-6> [nmigen] Failure. 0% of diff hit (target 79.77%) - https://codecov.io/gh/m-labs/nmigen/commit/597d778cf6cbc8cd90312ab280f9067531437972
<key2> whitequark: in fact, I created a gdb server, that takes in entry the .vcd itself, so I could step in the vcd postmortem as I don't have a debugger right now
<whitequark> ha, that's nice
<key2> by diffing the memory, it is possible to allow gdb to even inspect the memory !
<key2> so I could print all my values of struct and so on, really helped !
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 3 commits to master [+0/-0/±6] https://git.io/fhTgU
<_whitenotifier-6> [m-labs/nmigen] whitequark 040811c - hdl.ir: add an API for retrieving generated values, like FSM signal.
<_whitenotifier-6> [m-labs/nmigen] whitequark 934546e - hdl.dsl: provide generated values for FSMs.
<_whitenotifier-6> [m-labs/nmigen] whitequark 35a44f0 - hdl.dsl: forbid m.next= inside of FSM but outside of FSM state, too.
<whitequark> key2: fsm is done now
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/472330309?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. 79.94% (+0.17%) compared to 597d778 - https://codecov.io/gh/m-labs/nmigen/commit/35a44f017f6660c3c429b63791298fd1c6f9ec95
<_whitenotifier-6> [nmigen] Success. 100% of diff hit (target 79.77%) - https://codecov.io/gh/m-labs/nmigen/commit/35a44f017f6660c3c429b63791298fd1c6f9ec95
<key2> cool, so we need Records
<key2> ;)
<key2> then i might be able to port
<whitequark> first we need some tests
<whitequark> for genlib and stuff
<key2> mmh
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to master [+1/-0/±1] https://git.io/fhTg1
<_whitenotifier-6> [m-labs/nmigen] whitequark fe8cb55 - lib.cdc: add tests for MultiReg.
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/472333740?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. 80.3% (+0.35%) compared to 35a44f0 - https://codecov.io/gh/m-labs/nmigen/commit/fe8cb552041ca1d62989f83d46d71ff3726cee9f
<_whitenotifier-6> [nmigen] Success. 100% of diff hit (target 79.94%) - https://codecov.io/gh/m-labs/nmigen/commit/fe8cb552041ca1d62989f83d46d71ff3726cee9f
<whitequark> key2: well i started testing your code
<whitequark> and immediately found a bug
<whitequark> width -> self.width
<key2> ha
<key2> i didn’t test it
<key2> just translated it
<whitequark> thats why i asked you to write tests
<whitequark> because i know this results in bugs
<key2> where is that?
<key2> width was a prameter iirc
<whitequark> yeah but its not in get_fragment
<key2> ahhh
<key2> am not on computer but i see
<key2> it was in self
<key2> i have to go check all those
<whitequark> also I think the Decoder is just buggy
<whitequark> with m.Case():
<whitequark> with m.If(self.n):
<whitequark> m.d.comb += self.o.eq(0)
<whitequark> this shouldn't be in the default case
<whitequark> yeah, it wasn't in the default case in migen
<whitequark> so every one of those has a bug...
<whitequark> tests are important
<key2> i never said this core was correct, i just asked u if it looked the way you would translate it
<whitequark> ok
<whitequark> it works now
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to master [+3/-0/±1] https://git.io/fhT28
<_whitenotifier-6> [m-labs/nmigen] whitequark 5287477 - lib.coding: port from Migen.
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/472339069?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. 80.61% (+0.3%) compared to fe8cb55 - https://codecov.io/gh/m-labs/nmigen/commit/528747703d8fe260f1279e17a31b2626ebae040c
<_whitenotifier-6> [nmigen] Success. 100% of diff hit (target 80.3%) - https://codecov.io/gh/m-labs/nmigen/commit/528747703d8fe260f1279e17a31b2626ebae040c
futarisIRCcloud has joined #m-labs
rohitksingh has quit [Ping timeout: 250 seconds]
<whitequark> sb0: question.
<whitequark> there is a pattern that i found somewhat common.
<whitequark> let's say you have a register, a signal, and a strobe that stores the signal into the register.
<whitequark> and somewhere else, you want to see either the value that's already in the register, or, when the strobe is active, the value that's going to be stored there.
<whitequark> i feel like i write this a lot.
rohitksingh has joined #m-labs
<whitequark> is there a name for this / do you think we should add an abstraction for it?
<_whitenotifier-6> [nmigen] jfng opened pull request #14: compat.genlib.coding: fix import. - https://git.io/fhTVr
<_whitenotifier-6> [nmigen] whitequark closed pull request #14: compat.genlib.coding: fix import. - https://git.io/fhTVr
<_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fhTV6
<_whitenotifier-6> [m-labs/nmigen] jfng 73ed870 - compat.genlib.coding: fix import.
<_whitenotifier-6> [nmigen] whitequark commented on pull request #14: compat.genlib.coding: fix import. - https://git.io/fhTVi
<_whitenotifier-6> [nmigen] Error. The Travis CI build could not complete due to an error - https://travis-ci.org/m-labs/nmigen/builds/472354718?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/472354809?utm_source=github_status&utm_medium=notification
<_whitenotifier-6> [nmigen] Success. 80.61% remains the same compared to 5287477 - https://codecov.io/gh/m-labs/nmigen/commit/73ed87030902ccece4ba6e94adb3904c56b51916
<_whitenotifier-6> [nmigen] Success. Coverage not affected when comparing 5287477...73ed870 - https://codecov.io/gh/m-labs/nmigen/commit/73ed87030902ccece4ba6e94adb3904c56b51916
<GitHub-m-labs> [artiq] jbqubit commented on issue #1166: > perhaps just because of the limited scope bandwidth.... https://github.com/m-labs/artiq/issues/1166#issuecomment-449979335
<lkcl> whitequark: i was the lead developer of pyjamas, so i've done AST conversions / munging, etc. etc. - it's why i'm a big fan of [n]migen. we had to use lib2to3's pgen.py for the py-to-js language translator, because the one in python2 had been heavily optimised (use of tuples)
<whitequark> okay.
<whitequark> then I don't know why you see `import *` as troublesome.
<whitequark> it's not inherently worse than any other Python feature. in the easy case (which, fwiw, is the case for every nMigen module), you lexically find an assignment to __all__ (which gives you the names) or complain if there isn't any.
<whitequark> in the hard case, you may have to deal with metaprogramming and such. but any Python tools already have to cope with the existence of e.g. setattr.
<whitequark> arguably, `import *` is *much* easier to deal with than most other Python features because mandating that all modules from which you `import *` have a `__all__` member is good practice that is trivial to comply with
<whitequark> in constrast, you can't mandate that all getattr() arguments be constant strings or something
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<GitHub-m-labs> [artiq] hartytp closed issue #1129: HMC7043 cycle slip breaks DAC sync https://github.com/m-labs/artiq/issues/1129
<GitHub-m-labs> [artiq] hartytp commented on issue #792: @sbourdeauducq is this funded? I'm currently planning to use this for Sayma synchronisation, so it would be good to have it finished before v2.0 hw arrives. https://github.com/m-labs/artiq/issues/792#issuecomment-449984689
<GitHub-m-labs> [artiq] hartytp commented on issue #619: @sbourdeauducq am I right in thinking that this is no longer needed, since we will use transceivers for RTM DRTIO on v2.0 hw? In which case, does that free up some funding for other purposes? https://github.com/m-labs/artiq/issues/619#issuecomment-449984974
<GitHub-m-labs> [artiq] hartytp commented on issue #792: > I'm currently planning to use this for Sayma synchronisation... https://github.com/m-labs/artiq/issues/792#issuecomment-449988165
hartytp has joined #m-labs
<hartytp> sb0: AFAICs moving Sayma DAC config to kernels will be mainly straightforwards in the new HW rev once RTM DRTIO is up
<hartytp> the main thing I wasn't sure about was config of the JESD core
<hartytp> what's the right way of doing that over DRTIO?
<hartytp> is there a way of doing CSR access over DRTIO?
<hartytp> I'll aim to use Kasli + DIO breakout + ADF eval board to get a driver written for the PLL before v2.0 hw arrives.
hartytp has quit [Ping timeout: 256 seconds]
_whitelogger has joined #m-labs
lkcl has quit [Ping timeout: 244 seconds]
lkcl has joined #m-labs
rohitksingh has quit [Ping timeout: 245 seconds]
_whitelogger has joined #m-labs
futarisIRCcloud has joined #m-labs
hartytp has joined #m-labs
<hartytp> sb0: also, am I right in thinking that there is no easy way of implementing DRTIO on Sayma RTM?
<hartytp> if we had that I could port the DAC init to the core device and test the new PLL + sync scheme using v1.0 hw + eval boards
hartytp has quit [Ping timeout: 256 seconds]