| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 08:54 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.173> has joined #libre-soc | 08:56 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.173> has quit IRC | 09:32 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 09:32 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 09:39 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 10:02 | |
| lkcl- | ok so this is likely the source of the misunderstanding | 12:37 |
|---|---|---|
| lkcl- | when i said "i do not wish to see dataclasses be used" | 12:37 |
| lkcl- | i mean | 12:37 |
| lkcl- | "i do not wish to see "import dataclasses" be used anywhere within the codebase" | 12:38 |
| lkcl- | i did not mean | 12: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 use | 12:39 |
| lkcl- | > <lkcl-> you should be able to appreciate why i used setattr() in PowerOp() | 12:39 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 12: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 verbatim | 14: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 it | 14:16 |
| lkcl- | now that you are converting to a file-based *dynamic generated* format i am much happier | 14: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 codebase | 14:17 |
| lkcl- | you'll almost certainly end up using setattr() to *dynamically* add the field members with the field types, using metaclasses | 14:18 |
| lkcl- | and that i have absolutely no problem with at all | 14:19 |
| lkcl- | auto-generating code that is an exact verbatim copy of what is in power_insn.py, i can see the value of doing that because it avoids making mistakes | 14: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 override | 14:20 |
| lkcl- | but doable | 14: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 created | 14: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 instead | 14:26 |
| lkcl- | that's it. | 14:27 |
| lkcl- | oh | 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 you | 15: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-generate | 15: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.txt | 15:48 |
| lkcl- | right | 15: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 class | 15:48 |
| lkcl- | it does not need replacing | 15:48 |
| lkcl- | it needs *upgrading*... but it does *not* need replacing | 15: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!~isengaara@55d46476.access.ecotel.net> has joined #libre-soc | 15:52 | |
| lkcl- | please *morph* PowerOp - as was originally intended 24+ months ago - to be suitable for *dual* use | 15:52 |
| lkcl- | 1) PowerDecoder | 15:52 |
| lkcl- | 2) power_insns.py | 15:52 |
| lkcl- | the last thing we want is time spent (wasted) duplicating what is already in power_decoder.py - all the exceptions, all the field names, all the logic, only to then have | 15:53 |
| lkcl- | a) two sets of near-identical code | 15: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 altered | 15:54 |
| lkcl- | now, what i don't have a problem with is: | 15:55 |
| lkcl- | the creation of a *derived base class* that PowerOp uses | 15:55 |
| lkcl- | and the moving of the power_op_csvmap and power_op_types to a separate module | 15:56 |
| lkcl- | from which power_decoder.py derives to *create* PowerOp where PowerOp has *EXACTLY* the same publicly-functioning API that it presently has | 15:56 |
| lkcl- | and - crucially and importantly - power_insns.py (Fields class) presents *EXACTLY* the same field names, exactly the same properties | 15: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 months | 15: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 HDL | 15:59 |
| lkcl- | all of the pipelines (12 so far, and there will be more) *all* have the field names hard-coded into their HDL | 15:59 |
| lkcl- | so those names *absolutely cannot* change | 16:00 |
| lkcl- | (and neither can the CSV file columns) | 16:00 |
| lkcl- | this is quite a tricky and delicate line to walk | 16: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 project | 16:01 |
| *** lxo <lxo!~lxo@linux-libre.fsfla.org> has quit IRC | 16: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 understand | 17:47 |
| *** lxo <lxo!~lxo@linux-libre.fsfla.org> has joined #libre-soc | 17:48 | |
| *** lkcl- is now known as lkcl | 19:01 | |
| ghostmansd[m] | Appreciated. Also, any tips on this? https://libre-soc.org/irclog/%23libre-soc.2022-11-18.log.html#t2022-11-18T18:15:30 | 19:02 |
| lkcl | as 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 fair | 19:21 |
| lkcl | other people (including me) will soon let you know if it is too much (or too little). | 19:22 |
| lkcl | the important thing however when changing the amounts is to always always always run the budget-sync program | 19:23 |
| lkcl | nohup budget-sync -c budget-sync-config.toml -o mdwn | 19:23 |
| lkcl | then examine the contents of the file "nohup.out" | 19:24 |
| lkcl | for example | 19:24 |
| lkcl | budget-sync reports that 955 and 958 are missing a milestone dropdown | 19:24 |
| lkcl | this is not information that you can spot just by looking at one and only one bugreport | 19:25 |
| lkcl | also, the output shows you the list of *all* dependencies in tree-form | 19:25 |
| lkcl | (it is the contents of this: https://libre-soc.org/task_db/report/) | 19:25 |
| 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!~choozy@75-63-174-82.ftth.glasoperator.nl> has joined #libre-soc | 19:29 | |
| lkcl | it 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) occasionaly | 19:29 |
| lkcl | the 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 |
| lkcl | translation: 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 errors | 19:33 |
| lkcl | if errors _are_ detected, an entire HTTP transfer is cancelled or disappears *without a retry* | 19:34 |
| lkcl | it just took 3 attempts to do an HTTP POST to bugs.libre-soc.org | 19:34 |
| lkcl | 4... | 19:35 |
| lkcl | 5... | 19:36 |
| lkcl | using a different browser... success. finally. | 19:36 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 19:44 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 20: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 |
| lkcl | i 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 |
| lkcl | previously 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 |
| lkcl | it's not "management" decisions for other people, it's *self*-management decisions | 20:40 |
| lkcl | there is an unbelievably massive difference | 20:40 |
| lkcl | (ok writing the MoU itself is an admin task) | 20:40 |
| lkcl | but as far as budgets are concerned, i need everyone to step up and take direct responsibility, here | 20:40 |
| lkcl | rather 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=400 | 20:49 |
| ghostmansd[m] | 967: ghostmansd=100 | 20: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 |
| lkcl | yes 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 |
| lkcl | yes that's supposed to happen automatically, but it clearly isn't. | 20:53 |
| lkcl | if 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 with | 20:53 |
| ghostmansd[m] | Ah, OK, cool! | 20:53 |
| lkcl | they do it all the time, it's just a little more work, and normally it never matters | 20:54 |
| ghostmansd[m] | Andrey's nickname to cast here is octavius, right? | 20:54 |
| lkcl | ok, 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 |
| lkcl | yes, altough if you look at budget-sync-config.toml you will see aliases that work just as well | 20: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] | Neat | 20:59 |
| ghostmansd[m] | I'll put 450 for octavius, I hope he won't protest | 21:00 |
| lkcl | uh-huhn :) | 21:01 |
| lkcl | but bear in mind that modifying the parent may result in *its* parent needing modifying... | 21:02 |
| lkcl | and sometimes the errors "cascade" | 21:02 |
| lkcl | so you have to go "uhnnn... actually this is just the child (leaf) node being the wrong value somewhere" | 21:03 |
| *** tplaten <tplaten!~isengaara@55d46476.access.ecotel.net> has quit IRC | 21:04 | |
| ghostmansd[m] | Hm. What's the parent task for 968, document shift-and-add? | 21:13 |
| lkcl | 1 sec.. | 21:14 |
| ghostmansd[m] | 966 has 771; 967 has 840; but 968 has empty parent | 21:14 |
| lkcl | ermermerm... | 21:14 |
| lkcl | checking 589.... | 21:14 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=589#c0 | 21:15 |
| lkcl | # Documentation of designs, code, processes, and other relevant things as needed | 21:15 |
| lkcl | In order to make it more likely for our project to be understandable and | 21:15 |
| lkcl | useful as part of review. Documentation of designs, code, processes, and other relevant things is necessary. Also creation of Draft ISA Standards pages. | 21:15 |
| lkcl | Budget: 10000 EUR | 21:15 |
| lkcl | URL: https://bugs.libre-soc.org/show_bug.cgi?id=776 | 21:15 |
| ghostmansd[m] | Thanks, updated to 976 | 21:16 |
| ghostmansd[m] | Rerunning the tool | 21:16 |
| lkcl | btw 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 him | 21:17 |
| lkcl | and 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!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 21: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% tuning | 21: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 |
| lkcl | 450:450 for now. we can always increase it as things go along | 21:20 |
| lkcl | don't worry, really! this happens all the time | 21:20 |
| lkcl | people do a little bit more, the budget goes up some more. | 21:20 |
| lkcl | in 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 |
| lkcl | it is a process of adaptation | 21:21 |
| ghostmansd | ERROR:root:Budget assigned to task excluding subtasks (cf_budget field) doesn't match calculated value: bug #966, calculated value 750 | 21:23 |
| ghostmansd | ERROR:root:Budget assigned to task including subtasks (cf_total_budget field) doesn't match calculated value: bug #966, calculated value 750 | 21:23 |
| ghostmansd | How 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 time | 21:27 |
| ghostmansd | Well, 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 |
| ghostmansd | Either 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 |
| ghostmansd | And this is not caused by the difficult code, rather by amount of actual work that has to be done. | 21:31 |
| ghostmansd | Another sort of confusion is that I have no idea how difficult and time-wasting can be some tasks for someone but me. | 21:32 |
| ghostmansd | Say, 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 |
| ghostmansd | Tried updating the parents, but the error's still here. | 21:36 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 21:48 | |
| *** doppo <doppo!~doppo@2604:180::e0fc:a07f> has quit IRC | 22:21 | |
| *** doppo <doppo!~doppo@2604:180::e0fc:a07f> has joined #libre-soc | 22:24 | |
| *** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has quit IRC | 23:16 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!