[Libre-soc-dev] my current plan regarding simdsignal

[lkcl]

On October 24, 2021 4:12:08 AM UTC, Jacob Lifshay <programmerjake at gmail.com> wrote:

>In this particular case, I think it's fine, since the way it is used is
>such that it's much more similar to how Python's super() function
>works:
>If code is inside the `with SimdScope(...)`, then it will use that
>SimdScope. If it's outside, then it will raise an error.

jacob: please, no.  globals are not fine.  i have made that absolutely clear.

wby are you ignoring what i am saying and continuing to justify something that someone with 20 years experience in.python has said "no" to?  i don't understand.

>
>I originally got this idea from Rust's async design, where async
>functions
>can get access to the state necessary to schedule the async function to
>be
>woken up again after I/O by accessing a only-set-within-a-scope
>thread-local variable.

we are not using async in python it is too new and advanced.

>I can change it to also use a thread-local (needed if code is
>multithreaded
>rather than just multiprocess like usual for Python (multiprocess is
>standard for tests)).

no, please stop.  this introduces complex low-level features of python that other programmers from a hardware background will not understand.

the last thing we need is more complexity.

>The idea is that each Elaboratable class that we refactor to use
>SimdSignal
>will basically always wrap its elaborate() (and maybe __init__ too)
>function's body in a `with SimdScope`, such that it's always pretty
>obvious
>where the scope comes from.

this is more overloading that is unnecessary.  no.  please, just get of the global.

please accept this and stop justifying its use.

please accept that a global is unacceptable.

i have already said "hard no" on globals.

sorry to have to put it so bluntly, but which bit of "hard no" was unclear?

>Then, that one that does not will error in the unit test since they
>aren't
>using a `with SimdScope` since they decided to always pass SimdScope in
>explicitly instead.

i don't understand what you are saying here, why would that be different?  no, please don't explain it, please just get rid of the global.

please listen.

please get rid of the global.

did i say please get rid of the global?

please let me know when you have got rid of the global.

if there is anything unclear about "please get rid of the global" please let me know.


>If desired, I could also add a `with SimdScope.none()` that allows
>forcing
>SimdScope.get  to error even if your code is in a nested scope.

more complexity on top of more complexity: please listen and just get rid of the global and anything to do with globals.

we have to keep the code dead simple and strsightforward so that it is readable by average programmers.

that means not using advanced techniques "just because they are there" unless there is really no other choice.

what you are describing is getting more and more alarmingly complex with every message you write, to justify using something that should not have been added in the first place, adding more and more workarounds

>scope, so they won't conflict there, either. if the inner pipeline's
>elaborate is delayed till after the outer pipeline's elaborate
>finishes,
>then the scopes are no longer nested, just like case 1.

i have already a design in mind which carries the context through from the pipeline API.  the Mix-In class is established from the PSpec config, chosen extremely early, and passes and propagates relevant information right throughout every single pipeline with zero code modifications, dropping the relevant scoping info into literally every module.

this was conceptualised 2 years ago.

elaboratable is a completely inappropriate and unnecessary place to overload which will bring in more complexity.

you have not been part of those design discussions or ideas because at the time you were primarily focussed on Kazan and then stopped working on Libre-SOC for 18 months to do unpaid work on rust.

i had to design the roadmap myself and it is mapped out already, very clearly, with design decisions propagating through a hundred classes.

new ideas such as overloading elaborate are 18 months too late and too disruptive, and being based on a global are not acceptable anyway.

sorry.

l.