[Libre-soc-dev] Task 939 and its subtasks

[Dmitry Selyutin]

On Tue, Nov 22, 2022 at 11:37 PM lkcl <luke.leighton at gmail.com> wrote:
>
> On Tue, Nov 22, 2022 at 7:01 PM Dmitry Selyutin <ghostmansd at gmail.com> wrote:
>>
> > I'd take this with a grain of salt. :-)
>
> no, really:

Please don't speak for everybody around. If it takes 45 minutes for
you to change this code respectively -- this might be correct.
Otherwise this is quite an exaggeration, starting from the whole ply
concept.


> if that takes more than 45 minutes then something is very very wrong.

No, it's not. People are different. Some outperform in one area,
others -- in different. This is perfectly normal.


> from there, the confidence builds massively because all you have
> to do is say, "NEXT".  pick any function (any one of the BNFs),
> create associated unit tests, and it's done.
>
> with there being so few BNF expressions, it quickly becomes
> "routine".

Later -- yes. But not on the first iteration. Especially not for a newcomer.


> the "gotchas" in c are that you have to declare variables.  well, just
> accumulate those, drop them into a separate data structure during
> the BNF walk, and now you have 2 data structures, one of which
> may be post-process-substituted into the other.
>
> > I'd argue with MAINTAINABLE and SIMPLE as one who debugged and
> > modified it, especially since you write it in CAPS.
>
> three other people have demonstrated self-learned capability to
> both comprehend, debug, and modify the python-ply-based parser.
> this is enough empirical evidence to support the hypothesis that the
> code is both simple and also maintainable.

This is not an argument. All these "three other people" could have
understood this parser if it was written in Rust. Does this prove
anything? You could argue it would have taken more time, but I suspect
not everybody would agree (though I certainly would). Anyway, no,
according to my particular understanding of maintainability, there's a
lot to improve, same for simplicity. These both statements don't imply
one should immediately rewrite it in Rust, obviously. For me other
considerations are sufficient.


> exactly like qemu user mode!

OK then, it's clearer now. Thanks!

>
> > Otherwise it's not clear what's needed. The system
> > calls implementation, the exact ids, the arguments, the jump table,
> > etc., is handled by the operating system. What is exactly needed on
> > the simulator's side?
>
> we'll determine that by what occurs during the actual development.
> this will be a task that follows the heuristic "success by limiting what is
> done during the available budget such that what is achieved is DEFINED
> to BECOME the scope of the task".

OK. I assume we'll deal with it in the scope of bringing Frankenstein
to life. :-)


> > To the best of my knowledge, there's no such thing as POSIX ABI
>
> then ignore my response because it will be misleading.

I'll assume that it's also about other tricky parts of user mode,
then. Stuff that doesn't fit the syscalls niche.


> > > > * EUR 6000? continuing the SFFS userspace distro from NGI POINTER
> > > that is a guide and should be linked to the bugreport.
> >
> > So this is just a completed subtask, right?
>
> yes, as a guide - example and continuation - which must - to repeat - be
> linked *TO* the bugreport THAT MUST be created.
>
> > And I simply can enter it
> > as is into 939?
>
> no absolutely not. payment has been received for that task,
> from a completely different project.  look at the milestone:
> it says "NGI POINTER", doesn't it.  it has a parent task
> "912" which is "NGI POINTER".

Then why is it present in 939? Was it moved later?
Anyway, what'd be the bug report to be created? What'd be its parent?
What'd be the relations between all these?
As I understand, I must create the child issue for 939, and simply
link 860 to it as "helper" in comment and "see also".


> > > only if the budgets for the remaining tasks are inadequate in
> > > some way.
> >
> > I don't know where to get the budget for items 2 and 3. The item 2 is
> > quite a simple one but will need some time for sure. The item 3 is a
> > big task which must be done anyway. The only option for these tasks,
> > if I incorporate them into 939, is to steal budget from other tasks,
> > and those look like budget-critical already
>
> ah.  they're big enough such that this grant *becomes* starved,
> because the scope of work has been increased so much that
> they are now much bigger than originally intended.  ok, then
> yes, they should probably move to the other Grant, but bear in
> mind that if you do that, it means delaying payment because
> they're now on *another* Grant that has to have its MoU
> *developed* (written), let alone agreed.
>
> which is why we initially intended these as very small tasks,
> so that they could go under cavatools and get you some EUR,
> quickly.

Tests for sure will go to another task, I assume they will be really
time-consuming (and likely will also reveal some stuff to be changed
in binutils, so I will be side-tracked quite often).
As for item 2, it is reasonably small, so, if we can reschedule
something from other tasks now or on a later stage in scope of this
grant, I'd prefer doing this.


-- 
Best regards,
Dmitry Selyutin