*** jn <jn!~quassel@user/jn/x-3390946> has quit IRC | 04:05 | |
*** jn <jn!~quassel@2a0a:a541:c46d:0:20d:b9ff:fe49:15fc> has joined #libre-soc | 04:06 | |
*** jn <jn!~quassel@2a0a:a541:c46d:0:20d:b9ff:fe49:15fc> has quit IRC | 04:06 | |
*** jn <jn!~quassel@user/jn/x-3390946> has joined #libre-soc | 04:06 | |
programmerjake | providing indices to the visitor isn't actually that common, however, we have them easily available, why not just pass them in so the visitor doesn't have to recompute them? similarly for field names | 05:26 |
---|---|---|
programmerjake | lkcl: for pytest version stuff, i'll take that as a "yes, go ahead as long as versions match" -- updating the dev scripts was always my plan, they're just trivial enough that i didn't bother making a demo branch | 05:29 |
programmerjake | as for why pytest >= 6 was chosen: i understood you to prefer using nose, so i picked the pytest version that was convenient for me for ci | 05:31 |
programmerjake | i didn't actually think about which version was in debian since i always installed pytest from pip | 05:33 |
programmerjake | btw the >=6 there is just a minimum requirement, like the cmake version requirement you'd find in cmake files. i expected users to have a later version than that | 05:35 |
programmerjake | icr but something i put in the config file may have been added in version 6 | 05:35 |
ghostmansd[m] | programmerjake, coincidentally, some of paths are in fact indices :-) | 09:30 |
lkcl | programmerjake, i primarily use pytest, but we need both. reproducible-builds as we found out with the hassle surrounding memory-usage we cannot let developers "pick an arbitrary version" | 09:58 |
lkcl | FOSS developers have a habit of rushing ahead without thought for consequences, introducing latest-and-greatest-features without proper testing | 09:59 |
lkcl | mornin all | 10:00 |
lkcl | ghostmansd[m], yes they are however they're converted to strings. | 10:00 |
lkcl | wwhat i thought was: pass them in as ints, then require the visitor to do map(str, path) themselves | 10:01 |
ghostmansd[m] | Does it matter? As I know Python is capable of converting the strings to integers... :-) | 10:01 |
programmerjake | my plan is to use the mentioned fixed version of pytest, that was just my explanation of how we got where we are now | 10:01 |
lkcl | ghostmansd[m], bleck | 10:02 |
ghostmansd[m] | Strings cover more scenarios. Field of dataclass expressed as an int... well this can be done, but what's the point? | 10:02 |
lkcl | programmerjake, understood | 10:02 |
lkcl | ghostmansd[m], it was just an idea | 10:02 |
ghostmansd[m] | Ah OK, got it | 10:02 |
programmerjake | for the visitor imho passing indexes as integers and field names as strings is the best combination | 10:02 |
ghostmansd[m] | Well integers are fine for sequence-like stuff | 10:03 |
ghostmansd[m] | But we mostly have dicts and dataclasses there | 10:03 |
ghostmansd[m] | Not that I cannot teach dataclass passing kinda "field id" | 10:04 |
ghostmansd[m] | And have all Node some routine converting IDs to strings | 10:04 |
programmerjake | so a['a'].b[1].c would use 'a', 'b', 1, and 'c' | 10:04 |
lkcl | mmmhmmm... that would work | 10:04 |
ghostmansd[m] | But I need some rationale if we do it | 10:04 |
ghostmansd[m] | I mean, why id is better than a raw string :-) | 10:05 |
lkcl | it's like LDAP / X.500 | 10:05 |
ghostmansd[m] | That's basically just enumerate(dataclasses.fields()) | 10:05 |
ghostmansd[m] | (and vice versa) | 10:05 |
ghostmansd[m] | So totally doable, just need some rationale | 10:05 |
* lkcl thinking about the a b 1 c example | 10:05 | |
lkcl | and i can't really think of one, it's too early :) | 10:06 |
ghostmansd[m] | That's fine, no rush :-) | 10:06 |
ghostmansd[m] | One particular point is unification | 10:06 |
ghostmansd[m] | That is, having one type is better than having two | 10:06 |
ghostmansd[m] | But I cannot come up with another reason | 10:06 |
programmerjake | idea: have non-dict/non-sequence Nodes also support node['a'] indexing as a useful alias of node.a attribute access so generic code can just use [] for everything | 10:07 |
ghostmansd[m] | And, more importantly, I cannot come up with reason why int, not string | 10:07 |
lkcl | programmerjake, oh - nice. | 10:07 |
lkcl | ghostmansd[m], i think it sensible to proceed using what we have, and see what works and what doesn't | 10:07 |
programmerjake | i can come up with a reason to use int: it makes it much easier to access previous/next entry from the visitor | 10:08 |
programmerjake | just parent[idx + 1] instead of parent[str(int(idx) + 1)] | 10:08 |
lkcl | programmerjake, ahhh | 10:08 |
lkcl | ghostmansd[m], didn't you add Visitor[x] already? | 10:09 |
lkcl | ghostmansd[m], oh whoops | 10:10 |
programmerjake | note i didn't actually read the full visitors conversation (yet) since you sent a *lot* of emails | 10:10 |
lkcl | File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/insndb/core.py", line 1125, in Rc | 10:10 |
lkcl | return self["Rc"].value | 10:10 |
lkcl | File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/insndb/core.py", line 1119, in __getitem__ | 10:10 |
lkcl | return cls(record=self, **kwargs) | 10:10 |
lkcl | TypeError: type object argument after ** must be a mapping, not tuple | 10:10 |
lkcl | programmerjake, it's been... reaallly complex just for a few lines of code, trying to communicate through an internet-deluge of broken visitor patterns | 10:11 |
programmerjake | yeah, just wanted to mention that so you wouldn't be offended if i suggest something you already considered or something | 10:12 |
programmerjake | that type error sounds like your calling the class get item even though you want a instance get item (which doesn't exist?) | 10:15 |
lkcl | this is after ghostmansd[m] replaced dict with class Dict | 10:16 |
lkcl | so that makes sense | 10:16 |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 10:16 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.253> has joined #libre-soc | 10:18 | |
ghostmansd[m] | lkcl, sorry, I need to leave for a while. I'll fix this later today. Can you revert the commits starting from bogus one? | 10:21 |
ghostmansd[m] | Or just ignore it for a while if possible. | 10:21 |
ghostmansd[m] | Or you can fix it, the fix is simple: the stuff just returns tuple now, not dict, since I needed to hash it. You can do a manual __getitem__. | 10:23 |
lkcl | ghostmansd[m], i need to run unit tests so i'll revert the two commits. no problem. | 10:30 |
ghostmansd[m] | I think you can just adopt the original __getitem__ of that Operands class to reflect two facts: | 10:32 |
ghostmansd[m] | 1. The kwargs changed to tuple of pairs from dict. | 10:32 |
ghostmansd[m] | 2. The Operands now subclass Dict. | 10:32 |
ghostmansd[m] | That's be easy. Sorry for this havoc. | 10:32 |
lkcl | i'll see if i can cope | 10:40 |
lkcl | it's not necessary to take full copies of the data like this. it's not going to change, and "protecting" the users "from themselves" results in massive extra work | 10:45 |
lkcl | it's perfectly reasonable to assume that if the user wants to modify the data, they have a good reason for doing so. | 10:47 |
lkcl | that *immediately* reduces the amount of work needed to get the job done | 10:48 |
lkcl | nope, can't cope. | 10:50 |
lkcl | i'll investigate something else (spec writing) | 10:52 |
lkcl | https://slashdot.org/story/23/06/10/2056210/300-people-attend-a-church-sermon-generated-by-chatgpt | 11:06 |
lkcl | oh fer god's sake :) | 11:06 |
lkcl | lterally, haha | 11:07 |
ghostmansd[m] | :-D | 12:01 |
ghostmansd[m] | That's not protecting, dicts are unhashable | 12:24 |
ghostmansd[m] | I did the Dict hashable, but, if values are dicts too... well you know what I mean | 12:24 |
lkcl | ahh yeah i do. intriguing.... | 13:19 |
lkcl | btw can i suggest: | 13:20 |
lkcl | * create a branch from master (as it stands) | 13:20 |
lkcl | * call it "paths" | 13:20 |
lkcl | * *then* do reverts? | 13:21 |
*** ghostmansd[hexch <ghostmansd[hexch!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 13:31 | |
*** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 13:34 | |
lkcl | ok sorted. | 13:37 |
lkcl | temperatures are up, here, i'm going to have to be careful about how hard i run my laptop | 13:37 |
*** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 13:38 | |
*** ghostmansd[hexch <ghostmansd[hexch!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 13:40 | |
lkcl | ok "pytest -v -n 8" worked out fine in master after i cobbled together some reversions | 14:00 |
lkcl | "paths" branch (which i force-pushed) is where master used to be | 14:00 |
ghostmansd[m] | lkcl, do you suggest to commit stuff in paths branch? | 14:12 |
ghostmansd[m] | Sorry, I just didn't get why you created a brach | 14:13 |
lkcl | yes, use the branch path so that you and i can check things (i can run all unit tests) before they get cut over. | 14:27 |
lkcl | this is now too low-level to risk master branch stopping working | 14:27 |
lkcl | so i haven't "lost" anything - just put what the "current state" was into branch "paths" so it's not lost | 14:29 |
lkcl | *then* did reversions | 14:29 |
*** ghostmansd[hexch <ghostmansd[hexch!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 15:09 | |
*** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 15:12 | |
ghostmansd[m] | Ok, I'll push further changes into a branch | 15:50 |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.253> has quit IRC | 18:27 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 18:28 | |
*** openpowerbot <openpowerbot!~openpower@94-226-187-44.access.telenet.be> has quit IRC | 20:04 | |
programmerjake | lkcl: if you're copying a commit, please use cherrypick, it has a standard commit format and is usually easier to use | 20:09 |
programmerjake | so, like `git cherry-pick -x <commits-to-copy>` | 20:12 |
programmerjake | https://git-scm.com/docs/git-cherry-pick | 20:12 |
*** openpowerbot <openpowerbot!~openpower@94-226-187-44.access.telenet.be> has joined #libre-soc | 20:18 | |
ghostmansd[m] | programmerjake, I had the same question :-) | 20:53 |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 21:12 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.166.116> has joined #libre-soc | 21:13 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.166.116> has quit IRC | 21:45 | |
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 21:46 | |
lkcl | programmerjake, that wasn't possible, otherwise i would have used it. | 23:57 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!