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
<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>
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?
<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 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