[libre-riscv-dev] FHDLTestCase

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sun, Jun 7, 2020 at 12:22 AM Yehowshua <yimmanuel3 at gatech.edu> wrote:
>
> >
> >> Which reminds me, we need to separate FHDLTestCase class
> >> into the nmutils repo since it's no longer officially maintained.
> >
> > (i've done that already.  we also need to take a copy of the
> > nmigen._tools.py code.  could you ask whitequark if she expects that
> > to also happen, that we create multiple copies of more and more code
> > from nmigen?)
> >
>
> Just now seeing this. Glad you did that!

from nmigen._toolchain import require_tool

https://git.libre-soc.org/?p=nmutil.git;a=blob;f=src/nmutil/formaltest.py;hb=HEAD


> I’ll ask.

basically, without coming out and actually saying "this is completely
ridiculous, it leads down a rabbithole of copying more and more of
nmigen into a separate repository, which everyone else will likewise
have to do", we need to slowly and diplomatically educate her in the
python collaborative practices that she's missing.

nmigen is extremely unusual in that it is a "root" project (zero
external dependencies).  it's self-contained, is whitequark's first
experience with python, and consequently she has *zero* experience of
python collaborative development practices that have taken 20 years to
establish.

given that nmigen may well be the very first time that some HDL
engineers ever *use* python extensively (Staf, for example i believe
may fall into this category), there is a huge responsibility that
falls on whitequark's shoulders to learn and then make sure to use
best collaborative python practices.  and it is a huge responsibility.

unfortunately, my efforts to communicate with her about this did not
go well.  when i spoke with her about the extremely damaging practice
of using wildcard imports, rather than go "ah: i understand how this
is extremely detrimental to collaborative development, i will give it
some thought", her response was, "the python programming language
should not be broken.  it is not my responsibility: it is the
responsibility of the python developers.  they should never have added
the feature".

to her credit she *is* responding on some things.  usually it takes
more than one person to communicate with her about a given issue.
over time, she'll get it, i am sure, as she is extremely intelligent.

l.