| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 16:18 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.36> has joined #libre-soc | 16:19 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.36> has quit IRC | 16:22 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.52.80> has joined #libre-soc | 16:27 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.52.80> has quit IRC | 16:34 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 16:36 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 17:30 | |
| ghostmansd | lkcl, I've thought about the pattern matching (e.g. fields), and came to conclusion this deserves a standalone task. Besides that task, I'd like to address the following: | 17:49 |
|---|---|---|
| ghostmansd | 1) dataclasses we have now for the fields must be generated too, and this must be described in some files, too; | 17:50 |
| ghostmansd | 2) we need to bind specifiers to specific fields on assembly; | 17:51 |
| ghostmansd | 3) we need to teach disassembly "guess" specifiers from the fields in mostly automatic way. | 17:51 |
| ghostmansd | I have to think about the exact format yet, because this is really complex task. I still think that we'll have to tune it, because not everything can be expressed with the declarative language, but the major part can and should be done in an automatic way. | 17:53 |
| ghostmansd | That said, #939 seems to be the best place for this subtask. And, really, it'll be one of the most complicated parts. And it deserves its own budget. | 17:54 |
| ghostmansd | Then, once we're capable of doing this in Python, this should be done in binutils, also generated automatically, but likely this deserves its own task, too. | 17:56 |
| ghostmansd | As an alternative, #947 can be extended to incorporate these changes; in this case, there will be a standalone subtask of #947, and #947 budget must be changed respectively. | 17:58 |
| ghostmansd | I think that we will end up with some declarative way to generate instruction prefix fields, and some option to bind these to specifiers (both in assembly and disassembly). Currently we do all these tricks manually (e.g. checking the exact RM mode in disassembly). | 18:00 |
| ghostmansd | At the first stage, assembly will simply move to insndb; and then, some bits of insndb will be generated from some file(s) describing the relationship between specifiers and instruction fields. | 18:02 |
| ghostmansd | lkcl, I've started filling #939: https://bugs.libre-soc.org/show_bug.cgi?id=939 | 18:12 |
| ghostmansd | Also, #964, #966 and #967 belong to a different MoU, CryptoRouter, but have no assigned budget yet. And that MoU seems to be signed: #589. It'd be great if at least these can be assigned with budget and submitted. | 18:15 |
| lkcl- | dataclasses are wholly inappropriate for the job, here (they always were). | 21:35 |
| lkcl- | if the fields are in a file-format, then dataclasses are 100% out of the question eliminated from all and any consideration. | 21:36 |
| lkcl- | something like nmigen Record, or a namedtuple, or a dict, or a class that derives from dict, or a class that derives from dict and also creates attributes (even if they are hidden through overriding __getattr__/__setattr__) is far more appropriate | 21:38 |
| lkcl- | (or, in the constructor, call "setattr(self, fieldname, field_object_to_be_added)" | 21:39 |
| lkcl- | now that you understand why dataclasses were never appropriate, having learned that they are static declarations that by defintion can never under any circumstances be dynamic | 21:40 |
| lkcl- | you should be able to appreciate why i used setattr() in PowerOp() | 21:40 |
| lkcl- | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_decoder.py;h=396a2d4f319eab94a403e72995a22c3f91ce9ba5;hb=d7967c3c21fbf1d37f200b9284232aec15a7fadd#l202 | 21:40 |
| lkcl- | in that class, i made the decision not to derive from dict() | 21:40 |
| lkcl- | or to add (according to LSP) function overrides that *make* it like dict() | 21:40 |
| lkcl- | but instead just used setattr() | 21:41 |
| lkcl- | a technique for solving the need for custom expressions is instead to have them in pseudo-code. | 21:42 |
| lkcl- | i cannot tell you where i got that idea from, but i can say that if you use anything else *other* than pseudo-code, then it will have to be removed at an unspecified date once an announcement is made which i cannot tell you about because you are not a member of the OpenPOWER Foundation | 21:43 |
| lkcl- | and i am bound by Confidentialiy Agreements and cannot disclose what the source of the information is | 21:43 |
| lkcl- | well, #772 is the top-level task, and has a total of EUR 9,000 | 21:51 |
| ghostmansd[m] | > now that you understand why dataclasses were never appropriate | 21:51 |
| ghostmansd[m] | No I don't. What's wrong with dataclasses? | 21:51 |
| lkcl- | they are a static declaration. | 21:51 |
| lkcl- | you absolutely cannot have a dynamic dataclass. it is a mutually-exclusive contradiction. | 21:52 |
| ghostmansd[m] | No they are not. You can create the dataclass dynamically. Not even a slightest idea how you came to that conclusion. | 21:52 |
| lkcl- | i still do not want them in the codebase. | 21:52 |
| ghostmansd[m] | This is not a technical rationale. | 21:52 |
| lkcl- | i tolerated them whilst there was no other choice | 21:52 |
| lkcl- | it is what it is. | 21:53 |
| lkcl- | their whole purpose is to forcibly use "types" (the "x : y" syntax) which i despise and detest | 21:54 |
| *** yambo <yambo!~yambo@69.145.120.113> has quit IRC | 21:54 | |
| lkcl- | every time i see that code syntax utilised, it causes me to get angry that it was unnecessarily inserted into code | 21:54 |
| lkcl- | therefore *that* is a problem | 21:54 |
| lkcl- | there does not have to be a technical rationale. | 21:54 |
| ghostmansd[m] | Luke, we already iterated through this. The formula "I don't just like it" does not express anything other than personal preferences. | 21:54 |
| lkcl- | and as the project leader, the person who is burdened with the task of reviewing absolutely everybody's code | 21:55 |
| ghostmansd[m] | And "unnecessarily" is just an opinion. You push me towards your own preferences. | 21:55 |
| lkcl- | if it irritates me, then that wastes my time *which i do not have* | 21:55 |
| lkcl- | please do read again what markos said on this topic | 21:55 |
| lkcl- | you have to treat my time as an extremely valuable commodity | 21:56 |
| lkcl- | one that if i am not satisfied because of arguing, then *by default* because i did not say "yes" (because the limited time was spent arguing instead), the answer *is* "no" | 21:56 |
| ghostmansd[m] | And how do dataclasses waste your time with dataclasses? | 21:57 |
| lkcl- | because i dislike them | 21:57 |
| ghostmansd[m] | Perfect. | 21:57 |
| lkcl- | and that really is the end of the matter. i am not prepared to spend my time arguing about it. | 21:57 |
| lkcl- | i find even the arguing to be such a waste of time and so unpleasant that i do not wish to take part in it | 21:58 |
| lkcl- | therefore *by default*, dataclasses are out | 21:58 |
| lkcl- | it doesn't have to be "technically rational". | 21:58 |
| ghostmansd[m] | Ok, no task then. I'm OK with surrendering on that. | 21:59 |
| lkcl- | at some point - in approximately one to five months time - i will have enough of a handle on them to be able to explicitly answer your question "why" | 21:59 |
| lkcl- | but right now i simply cannot. | 21:59 |
| lkcl- | i have an *intuition* that they are dangerous and the completely wrong tool for the job | 21:59 |
| ghostmansd[m] | I already heard this "I'll tell later why". | 21:59 |
| lkcl- | ok whew | 22:00 |
| lkcl- | jacob created a class which has the "good" bits of dataclasses | 22:00 |
| lkcl- | which i am perfectly fine with. they provide an __hash__ and a __somethingelse__ function and a couple of others | 22:01 |
| lkcl- | i have absolutely no problem at all with people using *that* class. | 22:01 |
| lkcl- | back to task budgets. | 22:01 |
| ghostmansd[m] | I mean, I won't do this task. You don't want dataclasses to be generated, and give no rationale, and no explanation. Ok, fine, I won't generate these. | 22:02 |
| lkcl- | generate? | 22:02 |
| lkcl- | were you intending to *generate* code that derives from dataclass? | 22:02 |
| ghostmansd[m] | I wanted to generate the code which is manually written now. | 22:03 |
| lkcl- | (i mean: generate code that contains classes that derive from "dataclass"?) | 22:03 |
| ghostmansd[m] | All these instruction "bits" and "fields". | 22:03 |
| lkcl- | rright, ok, that's exactly the technique that i went through with SQL, and ultimately rejected. after literally spending 18-24 months going through exactly that process which you are now proposing | 22:03 |
| lkcl- | this was around the time that Ian Bicking created sqlobject | 22:04 |
| lkcl- | and other people created sqlalchemy | 22:04 |
| lkcl- | the lesson that i learned when those people created sqlobject and sqlalchemy, but i had "autogenerated" static code, was a face-palm moment | 22:05 |
| ghostmansd[m] | Luke, I really have other issues to worry about now. I don't really have time or patience to discuss about personal preferences. If you think I will waste my time persuading you — I won't. | 22:05 |
| ghostmansd[m] | You never give any rationale, so no, I won't bite this. | 22:05 |
| lkcl- | i realised that there was absolutely no need to generate the static code, but instead that you could, exactly as with sqlobject and sqlalchemy, *directly* provide the attributes | 22:05 |
| lkcl- | i am explaining | 22:05 |
| lkcl- | just indirectly | 22:06 |
| lkcl- | back to the explanation | 22:06 |
| ghostmansd[m] | Luke, I ask you to close this topic. | 22:06 |
| lkcl- | ... | 22:06 |
| ghostmansd[m] | My experience is different. | 22:06 |
| ghostmansd[m] | Let's respect each other. | 22:06 |
| lkcl- | i feel i'm misunderstanding / missing something. | 22:07 |
| lkcl- | are you intending to close the task and use dynamic-generated data structures? | 22:08 |
| lkcl- | or are you intending to close the task and not do it *at all*? | 22:08 |
| ghostmansd[m] | Everything is dynamic in Python, including dataclasses. | 22:08 |
| lkcl- | or, are you intending to leave the task to someone else? | 22:08 |
| lkcl- | ... | 22:08 |
| ghostmansd[m] | You can construct these, either via make_dataclass, or via AST, or by any other code-generation option. | 22:09 |
| ghostmansd[m] | They are as dynamic as anything else. | 22:09 |
| ghostmansd[m] | And, well, no less dynamic than namedtuple. | 22:09 |
| lkcl- | you may be misunderstanding my use of the word "dynamic". | 22:09 |
| lkcl- | by "dynamic" i mean, "the data structure in-memory such as an AST is created by reading some other file-format" | 22:10 |
| ghostmansd[m] | Luke, I'm too tired to hold this discussion. First, we already had it. Second, it serves no useful purpose. | 22:10 |
| ghostmansd[m] | Yes, and you _can_ read file and build the dataclass. | 22:11 |
| ghostmansd[m] | Or, well, you can build the fields I created. | 22:11 |
| lkcl- | ok let's continue when we're both better rested | 22:11 |
| lkcl- | and thought it over | 22:11 |
| ghostmansd[m] | Actually, I rather mean the Field classes I introduced. | 22:11 |
| lkcl- | ahhh | 22:11 |
| ghostmansd[m] | And I don't get how they are different to dataclasses in concept. | 22:12 |
| lkcl- | that's perfectly fine | 22:12 |
| markos | I think these discussions are best done NOT on IRC | 22:12 |
| ghostmansd[m] | Because, even though they don't have @dataclass decorator, they logically are similar. | 22:12 |
| lkcl- | as long as they do not derive - ultimately - *from* "dataclass" - at the lowest lowest level | 22:12 |
| ghostmansd[m] | Except that we have "bits", not "types". | 22:12 |
| ghostmansd[m] | No they are not. | 22:12 |
| lkcl- | then that's perfectly fine | 22:13 |
| ghostmansd[m] | I mean that they are logically like dataclasses. | 22:13 |
| lkcl- | ahhh that's totally different. | 22:13 |
| lkcl- | the bit i am objecting to is having *actual code* committed into the repository that contains "x : y" | 22:13 |
| lkcl- | phone call... let's carry on when not tired | 22:14 |
| ghostmansd[m] | `CR: _Field = (3, 4)` is almost the same. | 22:14 |
| ghostmansd[m] | It also uses type annotations, just for a bit different purposes than dataclass. | 22:15 |
| ghostmansd[m] | Long story short: I wanted to generate stuff like NormalFFRc0RM automatically from some files instead of writing it in the code. | 22:17 |
| ghostmansd[m] | Short story long: I claim this code is essentially no different than dataclasses. And all this syntax sugar is just for reader's convenience. And these can be created dynamically. | 22:18 |
| ghostmansd[m] | Even though there's no @dataclass decorator and not any type can be used, these are conceptually similar. | 22:19 |
| *** yambo <yambo!~yambo@69.145.120.113> has joined #libre-soc | 22:23 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!