[libre-riscv-dev] Very Subtle Synchronous nMigen Behavior

[Luke Kenneth Casson Leighton]

On Friday, June 19, 2020, Jacob Lifshay <programmerjake at gmail.com> wrote:

> On Thu, Jun 18, 2020, 18:01 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > On Fri, Jun 19, 2020 at 1:31 AM Yehowshua <yimmanuel3 at gatech.edu> wrote:
> > >
> > > I will mention I won’t use wildcards in any code I commit ever.
> >
> > urrr, thank you :)
> >
> > the problem is not immediately apparent until you start developing
> > large codebases, importing from multiple sources (some your own, some
> > other people's libraries), and wish to navigate them.
> >
>
> not to imply I think wildcards are a good idea in python, but pyls (the
> language server protocol implemention for python) makes it nearly trivial
> to navigate to the place where each symbol is defined, just by using the
> go-to-definition command. it can be used with vim and many other text
> editors/IDEs, such as VSCode (what I use, mostly because it has the best
> Rust support out of all non-vim editors).


indeed, the tools exist that allow jumping.  i have used ctags for 20
years, now.

there is an inherent problem with such jumping: loss of context of which
command is currently *actually* editing which file.

 i did "ps aux | grep vi | wc" only yesterday and it came back with 420
separate and distinct vi sessions.

each of the virtual windows (of which i am using six at the moment, each
one dedicated to different contextual work) contains up to TWELVE 80x65
xterms.

at least 6 of those xterms *in each virtual desktop* contains between five
and ONE HUNDRED backgrounded vi sessions.

i can therefore switch contexts rapidly - from helping you, jacob, or
helping you, cole, or working on the L0CacheBuffer, by moving to the
appropriate virtual desktop and the relevant editors are there *just as i
left them*

and given that often six files open at once is *not enough* given the
complexity of the project i frequently have to background one vi session
and flip to another, often several times a minute.

with up to a hundred vi jobs backgrounded, i see the name of the file and
can easily type "%64" to return to it.

if however the command in question does *not* take me to that file because
i used "ctags" (or pyls) to jump to an arbitrary file then the command line
"jobs" listing is not just useless, it is *misleading*.

i therefore take great care to return to the file, and often if i really
need to trace multiple tag chains will open up a special session just
typing "vi" not "vi filename" and close it afterwards to get rid of it.

i developed this workflow technique when dealing with complex projects
because of RSI and the amount of typing that it saves is enormous over
time, from not having to constantly re-open closed files.

it also clearly helps rapidly switch contexts and thus enables me to help
everyone else much more effectively.




>


>
> > for minerva, i found it was already seriously problematic to navigate
> > the codebase in order to track down which class came from which actual
> > file.  in addition, they actually had (may still have) a duplicate
> > class that was wildcard-imported in one location and *overridden with
> > a second*.  if they had explicitly named it the discrepancy would have
> > been caught fairly quickly.
> >
>
> I quite like how rust handles wildcard imports: all explicitly named
> imports take priority over wildcards and if there is a name that comes from
> multiple wildcard imports, then it errors with an ambiguity error.


unfortunately, python simply takes whatever the last definition was.

in the case of minerva this has allowed them entirely miss that there are
two definitions of the same class in two different files.

i have contacted them. i am waiting for them to respond.

l.



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