[libre-riscv-dev] development workflow

[Luke Kenneth Casson Leighton]

btw aleksander, i thought perhaps the attached screenshot might give
you some insight into how i work so fast.  i've been buying
increasingly higher-resolution laptops over the past 20 years, this
one is 3200x1800 and i use *all* of it, to maximum impact.

the reason i'm writing this is because when i went to work for an
unethical company with "top developers" i was shocked to find how
prevalent it has become to dominate the entire screen with a single
editor window - this on screens of size 24 inches and above with
resolutions of 4000 x 1800 pixels - with the ENTIRE right hand side
*and the middle* of that editor window entirely blank and utterly
wasted.

the reason why i have such a high resolution laptop is because i feel
a need to get as much information on-screen simultaneously as i can
possibly manage (i then run 24 virtual desktops, in a 6x4 grid
pattern, so that i can switch "working contexts" without shutting
anything down).

so in this screenshot, that's ten 80x60 xterms, it's "only" 10 because
i've put gtkwave in the bottom right corner @ around 1200x700 pixels
in size.  yes, really, 5 out of the top 6 xterms contain *relevant*
information, they are:

* fpbase.py - the base class i cut out of the add.py file, earlier today
* nmigen_div_experiment.py - the div class i worked on this evening.
* test_div.py - the unit test file for the div.py file.
* divider.v - jon dawson's original verilog.
* a "diff -uwbB adder.v divider.v > /tmp/f" which i then opened up with vim

so those five editor windows give me *simultaneous* side-by-side
access to all the information i need [none of this "full screen let's
open one file at a time, hooray" crap]

here's the justification for why all those files are open:

it's absolutely essential to have the fpbase.py open *at the same
time* as the div.py file... because otherwise, how am i going to know
what the function being called actually does?  i need to know the
contents of the function.  i might actually need to *add* a function
to the base file.  i might need to *correct* that function.  why would
i close the frickin files to do that, when i *know* i will need to
open it 15-30 seconds later??

the unit test file is open next to the div.py file, because, duh, i
want to add unit tests and then check the results.  i don't want to
*close* the unit test file just because it was edited, that would be
silly: it would be a waste of my time, requiring extra commands to be
typed.

divider.v is open because i can do a visual SIDE-BY-SIDE comparison of
the div.py with the divider.v.

the diff file from adder.v and divider.v is open because i originally
made div.py a copy of add.py, and the diff of the *VERILOG* files
tells me where i should be focussing attention to make changes on the
PYTHON files.

specifically: any parts of the adder.v and divider.v that are
identical tells me that i do *NOT* need to make *ANY* changes to the
corresponding div.py PYTHON file.


in addition, in the bottom left corner, i have some of nmigen edited
and open, because i am finding that i often need to refer to the
actual source code, particularly to check what arguments some of
nmigen's classes take.

next to that window, you can see evidence that i recently installed
yosys :)   next to _that_ you can see i had to apt-get install
libffi-dev (one of yosys's dependencies).

finally, i decided to open fmul.py just... because :)  so in that
window, i can help you out with code review... *without* losing any of
the context in the 5 windows above.

i also use the trick of *not* exiting editors, i *background* them.
this is the list of jobs in the window in which test_div.py is open:

lkcl at fizzy:~/src/libreriscv/ieee754fpu/src/add$ jobs
[1]   Stopped                 vi s_addMagsF32.c  (wd:
~/src/libreriscv/ieee754fpu/berkeley-softfloat-3/source)
[2]+  Stopped                 vi f.v
[3]   Stopped                 vi test_add.py
[5]   Stopped                 vi pipeline.py
[6]   Stopped                 vi pipeline_example.py
[7]   Stopped                 vi README.md  (wd: ~/src/libreriscv/ieee754fpu)
[8]-  Stopped                 vi test_div.py

f.v is the output from running the nmigen-to-verilog command.
test_add.py is open in case i want to go back to adding some more add
unit tests.  i developed the pipeline class in the same window, and
also edited the README.md and added some notes, and s_addMagsF32.c i
left open, from conversations we had last week.  it proved useful to
keep it open as it helped me to determine what the canonical
representation for INF is, and other things.

it's quite involved, and it's absolute hell to re-establish if ever
the laptop crashes... and here's why:

$ ps auxw | grep "vi " | wc
    451    5418   38670

yes, really, on this laptop, i have *451* vim sessions open, the
majority of them backgrounded.  many of those are still open from work
done on spike-sv, from several months ago: uptime is currently 156
days (wheww).

yes i've had people look over my shoulder and their eyes pop out :)
it's not for everyone, this approach, and yes it's taken 20 years to
refine.  just some food for thought :)

l.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2019-02-16_19-24.png
Type: image/png
Size: 343455 bytes
Desc: not available
URL: <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/attachments/20190216/830b8a65/attachment-0001.png>