<cr1901_modern>
Ahhh cool perfect timing whitequark, I have a Christmas present for you
<cr1901_modern>
a nice big PR :D
<whitequark>
which?
<cr1901_modern>
boneless merge
<whitequark>
ahh
<cr1901_modern>
I can stick around for a bit longer, but after that I need to sleep- need to be somewhere in 8 hours
<sb0>
kbackmann: you need to call fsm.finalize() to create the state signal. finalizing the top-level module will finalize everything including all FSMs.
<GitHub195>
[smoltcp] 1uka commented on pull request #268 1bd109e: I could not find out their values for other OSes, the most I can do is change this to only compile on macOS if that is what you are implying. https://github.com/m-labs/smoltcp/pull/268#discussion_r243889442
<GitHub8>
[smoltcp] 1uka commented on pull request #268 1bd109e: To get the interface MTU, you would need to create a raw socket first, and then call `SIOGIFMTU` for the same interface your BPF device is "bound" to. Now this MTU that you would get would not include the length of `struct bpf_hdr` which gets prepended to every packet by BPF, and your packet will be truncated if it has the length of the MTU. ... https://gith
<sb0>
cr1901_modern: just do the exact same thing that artiq does
<sb0>
cr1901_modern: you may even skip creating the platform object when the corresponding environment variable is set
<whitequark>
every module in nmigen is carefully written to only export the minimal and meaningful amount of symbols
<whitequark>
if you still don't like that, you are welcome to prefix names, but i have tried doing that right away and i resent the resulting verbosity
<whitequark>
python is already too uselessly verbose for nmigen
<lkcl>
it decreases readability, prevents and prohibits analysis tools from working, pollutes the namespace in ways that you cannot determine, and places a burden onto the maintainer of the library
<lkcl>
it's considered to be one of the worst practices in python
<lkcl>
hence why i said "um" because i was trying to downplay mentioning it
<lkcl>
i don't like the prefixing either (import nmigen.cli followed by nmigen.cl.main(foo)) that's crap
<lkcl>
from nmigen import (Signal, Module) and so on is the way that i do things, it works well, it's really clear, pyflakes and other automated code-analysis and verification tools can do their job correctly
<lkcl>
and users don't end up going, "oh, hmmm, i can create a class called Signal" or other glaring errors
<whitequark>
lkcl: i don't really care about what is "considered worst practices in python" because python is mostly worst practices
<whitequark>
i mean, it is the language where the recommended way to check for a missing element in a dict is catching KeyError
<whitequark>
anyway
<whitequark>
`from nmigen import *` precisely doesn't put a lot of stuff into your namespace. it only puts the things that virtually every nmigen design will need
<whitequark>
you can tell where it came from, because if you structure your code well, you have files that are dedicated to defining nmigen gateware
<whitequark>
and if pyflakes cannot handle `*`, it is broken and should be replaced
<whitequark>
if, somehow, you really *do* want to mix gateware and non-gateware in the same file, which you shouldn't do,
<whitequark>
then you do `import nmigen as nm` or something.
<whitequark>
i am extremely tired of adding Yet Another Import at the top of the file when i start using an ubiquitous nmigen/migen feature. it is distracting, unnecessary, and wasteful.
<whitequark>
i will not get rid of *.
lkcl has quit [Ping timeout: 268 seconds]
lkcl has joined #m-labs
<cr1901_modern>
Not every PEP8 practice should be followed IMO. The 80-col limit should be nuked from orbit too IMHO
<lkcl>
that's *11* 80x65 xterms side-by-side, in coordinates (2,2) of a (6x4) virtual desktop.
<lkcl>
on a 3000x1800 laptop LCD.
<lkcl>
i have memory issues. it is *absolutely essential* that i get as many editor sexsions on-screen, side-by-side, as i can possibly fit.
<lkcl>
if it became common-place that code spanned greater than 80 characters, it would be absolutely disastrous for my ability to do any work, effectively.
<lkcl>
whitequark: understood. it's something that you have to personally experience the detrimental effects of, in order to fully appreciate why "import *" is such bad practice.
<lkcl>
that usually occurs if you've worked with python for a long time, or have worked on any 100,000+ line python codebase.
<lkcl>
using it to create HDLs, is so specialist that it's actually quite unlikely that you'll run into the worst of the worst issues that most people encounter, in python, when using "import *"
<lkcl>
whitequark: pyflakes is not broken: the practice of "import *" is so broken as far as type-checking and import-checking is concerned that *no* tool could possibly do the job of verifying whether the code containing an "import *" is formally correct.
<lkcl>
again: this comes down to HDLs being such a small, niche and specialist area that obscure bugs caused by the use of "import *" are relatively low probability.
<lkcl>
"i am extremely tired of adding Yet Another Import".... yep, i hear ya :) it's why "import *" was added in the first place :)
<lkcl>
it was likely copied from java.
<lkcl>
unfortunately, by the time the harm it causes was realised, given that python is a dynamic language, it was far, far too late to remove it.
<lkcl>
cr1901_modern: i surmise that you use an IDE of some description, and that you most likely run it full-screen. do you edit exclusively only one file at a time?
<lkcl>
i laughed myself silly one time when i had to do "jobs | grep vim | grep <keyword>" because i *background* vim editors
<lkcl>
i laughed hysterically because i decided to do "ps aux | grep vim | wc". it came up with SIX HUNDRED AND FIFTY simultaneous vim editor sessions.
<lkcl>
in one window alone i had backgrounded over a hundred and fifty
<lkcl>
:)
<lkcl>
it was some extremely complex programming, involving code auto-generation. 350 IDL files, from which six separate c, c++, .h and makefile fragments were created.
<lkcl>
if i had been looking at them one by one, full screen, i would have gone completely insane with the amount of re-typing the names of the files.