[libre-riscv-dev] [Bug 217] create a "ring" system which allows pad locations to be specified conveniently

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=217

--- Comment #10 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jean-Paul.Chaput from comment #8)

>   Obviously. Because it works on my end. I will redo the whole install
>   process under Debian 10 in the next few days to see if I can reproduce
>   your problem.

i forgot to say, jean-paul: i have debian/10 now as well. the "export
LD_LIBRARY_PATH=....lib export LD_LIBRARY_PATH= ... lib64" hack shown here
makes the install "work" with no mods needed to alliance/coriolis2
https://libre-riscv.org/HDL_workflow/coriolis2/

also, we are doing soclayout/experiment7 which is a duplicate of
benchs/nmigen/alu_hier (for now)


>  
> > I hope I was able to somehow address the issue of creating the layer Luke
> > mentions:
> > 
> > https://git.libre-riscv.org/?p=soclayout.git;a=blob;f=experiments7/doAlu16.
> > py;hb=HEAD#l25
> > 
> > But otherwise I am lost. And the overall quality of the Python code I'm
> > dealing with in Coriolis makes me want to poke my eyes out. I'm terribly
> > sorry if I offended someone, but at the same time I'm sure I'm not the only
> > one saying this. I wonder why it is so bad and where to start improving it.
> 
>   Coriolis has always been tricky to install from sources (but try to build
>   the whole Gnome3 stack instead of using packaged versions to make a fair
>   comparison). 

eek! :)

>   but ranting about "this is badly written" do not help. I flatter myself
>   to have the "scientific spirit", so if you pinpoint me badly written code
>   and *why* it is so (with reference), I will improve it in my futur code
>   and progressively rewrite the old one.

none of the python code is pep8 compliant, jean-paul.  the 2-spaces indentation
is extremely hard on the eyes for anyone used to the pep8 standard (because the
smaller indentation makes "code blocks" that much harder to visually identify).

and the use of commas at the *beginning* of the line on a parameter list,
rather than the usual place at the *end* of the line, is very difficult to get
used to.  i find that, automatically, i add the comma at the end (because that
is the pep8 standard) and of course it creates a syntax error because there is
a *second* (unexpected) comma at the start of the next line.

a single run of autopep8 will "fix" that however any lines that have to be
wrapped (due to length over-run) can be "mashed" somewhat in an inappropriate
fashion, by putting function parameters onto a single line (forcibly).

this is done in a lot of places anyway (single line per function parameter) so
it may not be so bad.

however... i haven't mentioned any of this because i felt it was more important
to get working "stuff" within the context of what time you have and also
knowing that you have... "memorised" the python code in this (unusual,
non-standard) format... and moving to strict pep8 would be quite disruptive and
time-consuming (for you to get used to).

it would need careful scheduling because, really, you need to hit the entire
codebase with a single carefully-reviewed autopep8 update and commit, and not
do *anything* else in between.

if there is a good time to schedule that, we can have several people help out
with it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.