Saturday, 2022-11-19

*** ghostmansd[m] <ghostmansd[m]!> has quit IRC08:54
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc08:56
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC09:32
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc09:32
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC09:39
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc10:02
lkcl-ok so this is likely the source of the misunderstanding12:37
lkcl-when i said "i do not wish to see dataclasses be used"12:37
lkcl-i mean12:37
lkcl-"i do not wish to see "import dataclasses" be used anywhere within the codebase"12:38
lkcl-i did not mean12:38
lkcl-"i do not wish to see the GENERAL ABSTRACT CONCEPT known as data space classes (data classes) used anywhere within the codebase"12:38
lkcl-you can deduce that this was what i meant because i referred you to some code examples that are in fact *already* data space classes already in use12:39
lkcl-> <lkcl-> you should be able to appreciate why i used setattr() in PowerOp()12:39
*** ghostmansd <ghostmansd!> has quit IRC12:51
ghostmansd[m]What is the problem with particular import? This is no more convincing than "I don't like to see any setattr on object instead of using a dict instead". Second, if this import is generated, say, by Python AST, what is the problem there?13:08
ghostmansd[m]Do you have the problem with the exact way Python uses to implement the data classes?13:09
lkcl-i have a problem with the committing of code that contains "types", of the form "x : datatype".14:12
lkcl-it comes primarily from jacob's over-use of types in the codebase, resulting in 3 to 5 times as much code, and preventing and prohibiting of flexibility.14:13
lkcl-the use of that import, if banned, prevents the use of "the module known by the name dataclass"14:14
lkcl-and thus, i expect by implication, that its functionality *not* be re-created verbatim14:14
lkcl-in particular, the creation of code that is then committed to the repository that contains syntax of the form "x : datatype"14:15
lkcl-the way that *you* used "x : datatype" made me very nervous but because you used it solely for the purposes of declaring the format, i was "okay" with it14:16
lkcl-now that you are converting to a file-based *dynamic generated* format i am much happier14:16
lkcl-because, ultimately, i can foresee that the presence of code that is of the form "x : datatype" will be removed - entirely - from the codebase14:17
lkcl-you'll almost certainly end up using setattr() to *dynamically* add the field members with the field types, using metaclasses14:18
lkcl-and that i have absolutely no problem with at all14:19
lkcl-auto-generating code that is an exact verbatim copy of what is in, i can see the value of doing that because it avoids making mistakes14:20
lkcl-(preserving the comments is going to be a little tricky)14:20
lkcl-class EXTSOperand(RegisterOperand):14:20
lkcl-    n_zeros: int  # number of zeros - set through constructor override14:20
lkcl-but doable14:20
lkcl---->@_dataclasses.dataclass(eq=True, frozen=True)<----14:21
lkcl-class Operand:14:21
lkcl-this can go, to be replaced with the class and decorators that jacob created14:21
lkcl-so, the practical guide is:14:25
lkcl-1) don't commit code to the codebase that is of the form "class X: fieldname1: type1 fieldname2: type2" (but auto-generating it is - reluctantly and initially okay)14:26
lkcl-2) don't use "import dataclasses", use jacob's replacement instead14:26
lkcl-that's it.14:27
lkcl-... yes. that's it.14:27
lkcl-if you can stick to that i'm perfectly happy.14:27
ghostmansd[m]What are the decorators and the class by Jacob?14:47
ghostmansd[m]No idea why you checking the operands, though. These are not subject to be changed. What I want to change is that the stuff with fields is autogenerated.14:48
ghostmansd[m]That is, for example, RM modes.14:48
lkcl-programmerjake will be able to tell you15:44
lkcl-without some context i don't know the difference.  so if the principle i am describing does not apply to "the operands" (because they're not planned to be changed) then the principle that i describe should be applied to what you *are* planning to auto-generate15:45
lkcl-(and, ultimately, the operands - which are using the python "import dataclass" - also tackled and the use of "the built-in module known by the name "dataclass" also removed, at a later date, under a much-lower-priority task)15:47
lkcl-ah, i am starting to get the picture.  Fields - you mean the content loaded from fields.txt15:48
lkcl-that's covered at present by the very class that i first described: PowerOp.15:48
lkcl-PowerOp has been specifically designed to be a data space class15:48
lkcl-it does not need replacing15:48
lkcl-it needs *upgrading*... but it does *not* need replacing15:48
lkcl-so where it says this:15:49
lkcl-            fname = get_pname(field, name)15:49
lkcl-            setattr(self, field, Signal(ptype, reset_less=True, name=fname))15:49
lkcl-            debug_report.add(field)15:49
lkcl-there must be an option to *override* the hard-coded addition of Signal()15:49
lkcl-(which should never have been done, that was very much specifically not the intention)15:50
lkcl-what's going on, what's going on...15:50
lkcl-        self.op = PowerOp(name=name, subset=col_subset)15:50
lkcl-        for d in dec:15:50
lkcl-in PowerDecoder...15:50
lkcl-so that should have received some arguments to tell it "yeah i don't want hard-coded nmigen Signals, i want you to create something of class {insert classname}"15:51
lkcl-what i am saying is: please do not duplicate - or replace - PowerOp.15:52
*** tplaten <tplaten!> has joined #libre-soc15:52
lkcl-please *morph* PowerOp - as was originally intended 24+ months ago - to be suitable for *dual* use15:52
lkcl-1) PowerDecoder15:52
lkcl-2) power_insns.py15:52
lkcl-the last thing we want is time spent (wasted) duplicating what is already in - all the exceptions, all the field names, all the logic, only to then have15:53
lkcl-a) two sets of near-identical code15:54
lkcl-b) a massive effort to replace the use of PowerOp with something that's completely different with completely different names that causes tens of thousands of lines in the SoC HDL to be forcibly and unnecessarily altered15:54
lkcl-now, what i don't have a problem with is:15:55
lkcl-the creation of a *derived base class* that PowerOp uses15:55
lkcl-and the moving of the power_op_csvmap and power_op_types to a separate module15:56
lkcl-from which derives to *create* PowerOp where PowerOp has *EXACTLY* the same publicly-functioning API that it presently has15:56
lkcl-and - crucially and importantly - (Fields class) presents *EXACTLY* the same field names, exactly the same properties15:57
lkcl-but (potentially) ends up with something say called... oo... PowerInsnFieldsPowerOp or something (anything suitable)15:57
lkcl-but *duplicating* the functionality and all the lessons that three separate team members have done over the past 24 months15:58
lkcl-this will not be ok.15:58
lkcl-changing the power_op_csvmap or power_op_types likewise is not ok because it has a cascade-effect onto the SoC HDL15:59
lkcl-all of the pipelines (12 so far, and there will be more) *all* have the field names hard-coded into their HDL15:59
lkcl-so those names *absolutely cannot* change16:00
lkcl-(and neither can the CSV file columns)16:00
lkcl-this is quite a tricky and delicate line to walk16:00
lkcl-because you are proposing altering (or worse duplicating, giving us a future maintenance headache) some core critical fundamental code that was amongst the very first code ever developed in the entire project16:01
*** lxo <lxo!> has quit IRC16:08
ghostmansd[m]I'll think about it when I get to this task. I'm far away from it, no sooner than I complete the assembly in the current stage.16:57
lkcl-not a problem. it will take time to absorb and think about, and some planning.17:46
lkcl-normally that process takes several days even weeks for me so i perfectly understand17:47
*** lxo <lxo!> has joined #libre-soc17:48
*** lkcl- is now known as lkcl19:01
ghostmansd[m]Appreciated. Also, any tips on this?
lkclas long as the amounts selected do not mean that other people do not get a fair amount (you'll need to drill down to the other bugreports) then just pick some numbers that seem fair19:21
lkclother people (including me) will soon let you know if it is too much (or too little).19:22
lkclthe important thing however when changing the amounts is to always always always run the budget-sync program19:23
lkclnohup budget-sync -c budget-sync-config.toml -o mdwn19:23
lkclthen examine the contents of the file "nohup.out"19:24
lkclfor example19:24
lkclbudget-sync reports that 955 and 958 are missing a milestone dropdown19:24
lkclthis is not information that you can spot just by looking at one and only one bugreport19:25
lkclalso, the output shows you the list of *all* dependencies in tree-form19:25
lkcl(it is the contents of this:
lkcl(but i only ever upload that *after* correcting every single error that everyone has made in the intervening time since it was last run)19:25
lkcl(which is one of the many things that has gotten to be too much for me)19:26
*** choozy <choozy!> has joined #libre-soc19:29
lkclit also does not help that my internet connection is severely compromised.  it is currently 15k/sec upload and 30k/sec download. it gets up to around 30k/sec upload and 800k/sec (0.8 mbits/sec) occasionaly19:29
lkclthe weather (which is affecting 3G/4G signals) is also *damaging* packets at ISO Layer 1 and 2... *and they're propagating up to ISO Layer 3 and 4*19:32
lkcltranslation: i get UDP and TCP traffic that says it's valid, when in fact it's not in the least bit valid, resulting in "invalid SSL socket connection" and other insane normally never-seen errors19:33
lkclif errors _are_ detected, an entire HTTP transfer is cancelled or disappears *without a retry*19:34
lkclit just took 3 attempts to do an HTTP POST to bugs.libre-soc.org19:34
lkclusing a different browser... success. finally.19:36
*** ghostmansd <ghostmansd!> has joined #libre-soc19:44
*** ghostmansd <ghostmansd!> has quit IRC20:10
ghostmansd[m]Luke, I really don't want to make these guesses and also would like to avoid to be involved in taking budget-related decisions, at all costs.20:35
ghostmansd[m]So you can write any number here and I will update the relevant tasks.20:36
ghostmansd[m]If I feel this is too low, I will tell it. If I feel this is too high, I will do it too, and I think I already demonstrated it on various accasions.20:39
lkcli need all of you - every one of you - to take more responsibility, now.20:39
ghostmansd[m]I hate it so much when I have to make management decisions...20:39
lkclpreviously i said "no" because there were too many mistakes and it was quicker, during the insane rush to meet the deadline, for me to correct them.20:39
lkclit's not "management" decisions for other people, it's *self*-management decisions20:40
lkclthere is an unbelievably massive difference20:40
lkcl(ok writing the MoU itself is an admin task)20:40
lkclbut as far as budgets are concerned, i need everyone to step up and take direct responsibility, here20:40
lkclrather than using me as the central "authority" or "single point" or "central hub and checker"20:42
ghostmansd[m]Ok, how about this?20:47
ghostmansd[m]400 EUR for 966, considering the instruction inself plus pseudocode fixes plus some issues fixed in the code plus enhancements for selectable int; 100 EUR for you there.20:47
ghostmansd[m]100 EUR for 967 plus for all discussions in all three tasks.20:47
ghostmansd[m]I'm not sure how much needs to be allocated for Andrey for 968, but I assume no less than 200-300 EUR?20:47
ghostmansd[m]966: lkcl=100, ghostmansd=40020:49
ghostmansd[m]967: ghostmansd=10020:49
ghostmansd[m]968: andrey=200..300?20:49
ghostmansd[m]lkcl, maybe your part should be increased, too. Please check whether this is correct adjustment.20:51
lkclyes everyone about 50% more than that, in order to properly value our work.20:52
ghostmansd[m]Also, it'd really be great if I could merge RFPs for 966 and 967 into a single payment, otherwise I'd have to pay fees on both tasks.20:52
lkclyes that's supposed to happen automatically, but it clearly isn't.20:53
lkclif when you put in the RFPs, make sure in the "notes" to say "please merge these as one single payment due to fees" and list the other RFPs to merge with20:53
ghostmansd[m]Ah, OK, cool!20:53
lkclthey do it all the time, it's just a little more work, and normally it never matters20:54
ghostmansd[m]Andrey's nickname to cast here is octavius, right?20:54
lkclok, so you can "cheat" slightly, with budget-sync.  what you can do is be "lazy", and not edit the parent bugreport(s) down the chain: instead, use the built-in calculations and just write them into the bugreport on a 2nd pass :)20:55
lkclyes, altough if you look at budget-sync-config.toml you will see aliases that work just as well20:55
ghostmansd[m]966={lkcl=150, ghostmansd=600}, 967={ghostmansd=150}, 968={octavius=300..450}20:58
ghostmansd[m]What do you mean by built-in calculations?20:58
ghostmansd[m]Aaah I get it, just update the children, lauch the tool, then update the parent?20:59
ghostmansd[m]I'll put 450 for octavius, I hope he won't protest21:00
lkcluh-huhn :)21:01
lkclbut bear in mind that modifying the parent may result in *its* parent needing modifying...21:02
lkcland sometimes the errors "cascade"21:02
lkclso you have to go "uhnnn... actually this is just the child (leaf) node being the wrong value somewhere"21:03
*** tplaten <tplaten!> has quit IRC21:04
ghostmansd[m]Hm. What's the parent task for 968, document shift-and-add?21:13
lkcl1 sec..21:14
ghostmansd[m]966 has 771; 967 has 840; but 968 has empty parent21:14
lkclchecking 589....21:14
lkcl# Documentation of designs, code, processes, and other relevant things as needed21:15
lkclIn order to make it more likely for our project to be understandable and21:15
lkcluseful as part of review. Documentation of designs, code, processes, and other relevant things is necessary. Also creation of Draft ISA Standards pages.21:15
lkclBudget: 10000 EUR21:15
ghostmansd[m]Thanks, updated to 97621:16
ghostmansd[m]Rerunning the tool21:16
lkclbtw on that one i am doing as much as octavius, because i am (a) teaching him (b) interacting with him (c) doing almost as much if not more *because* i am teaching him21:17
lkcland that (in and of itself) also becomes part of the documentation (IRC logs etc.)21:17
ghostmansd[m]Perfect, 450:450?21:17
ghostmansd[m]Would that be fine?21:18
*** ghostmansd <ghostmansd!> has joined #libre-soc21:18
ghostmansd[m]Or 300:450?21:18
ghostmansd[m](300 is from 200 I initially suggested as starting range for octavius)21:18
ghostmansd[m]i.e. 200 + 50% tuning21:19
ghostmansd[m]I'm judging from "if not more":-)21:19
ghostmansd[m]See how terrible I am at this? I warned you!21:20
lkcl450:450 for now.  we can always increase it as things go along21:20
lkcldon't worry, really! this happens all the time21:20
lkclpeople do a little bit more, the budget goes up some more.21:20
lkclin the end, it hits the limit of the parent, and we have to say "ok it can't go any higher, now instead we have to change the scope of the task"21:21
lkclit is a process of adaptation21:21
ghostmansdERROR:root:Budget assigned to task excluding subtasks (cf_budget field) doesn't match calculated value: bug #966, calculated value 75021:23
ghostmansdERROR:root:Budget assigned to task including subtasks (cf_total_budget field) doesn't match calculated value: bug #966, calculated value 75021:23
ghostmansdHow should I treat this? Does it just tell me that I need to update the parent?21:23
ghostmansd> <lkcl> don't worry, really! this happens all the time21:27
ghostmansdWell, my primary point of confusion is that all numbers there seem to be too high, to be honest. Compared to amount of time and efforts for 948, 949 and 950, 966 and 967 were simple and quick.21:29
ghostmansdEither 948..950 should be higher, or I should take less for 966/967. Because the latter took a couple of evenings, and the former already taken waaaaay more.21:30
ghostmansdAnd this is not caused by the difficult code, rather by amount of actual work that has to be done.21:31
ghostmansdAnother sort of confusion is that I have no idea how difficult and time-wasting can be some tasks for someone but me.21:32
ghostmansdSay, something I could do for a week you could do in a day, and won't be bothered at all, and you won't consider this a difficult task.21:32
ghostmansd> <ghostmansd> How should I treat this? Does it just tell me that I need to update the parent?21:36
ghostmansdTried updating the parents, but the error's still here.21:36
*** ghostmansd <ghostmansd!> has quit IRC21:48
*** doppo <doppo!~doppo@2604:180::e0fc:a07f> has quit IRC22:21
*** doppo <doppo!~doppo@2604:180::e0fc:a07f> has joined #libre-soc22:24
*** choozy <choozy!> has quit IRC23:16

Generated by 2.17.1 by Marius Gedminas - find it at!