Sunday, 2023-06-11

*** jn <jn!~quassel@user/jn/x-3390946> has quit IRC04:05
*** jn <jn!~quassel@2a0a:a541:c46d:0:20d:b9ff:fe49:15fc> has joined #libre-soc04:06
*** jn <jn!~quassel@2a0a:a541:c46d:0:20d:b9ff:fe49:15fc> has quit IRC04:06
*** jn <jn!~quassel@user/jn/x-3390946> has joined #libre-soc04:06
programmerjakeproviding 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 names05:26
programmerjakelkcl: 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 branch05:29
programmerjakeas 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 ci05:31
programmerjakei didn't actually think about which version was in debian since i always installed pytest from pip05:33
programmerjakebtw 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 that05:35
programmerjakeicr but something i put in the config file may have been added in version 605:35
ghostmansd[m]programmerjake, coincidentally, some of paths are in fact indices :-)09:30
lkclprogrammerjake, 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
lkclFOSS developers have a habit of rushing ahead without thought for consequences, introducing latest-and-greatest-features without proper testing09:59
lkclmornin all10:00
lkclghostmansd[m], yes they are however they're converted to strings.10:00
lkclwwhat i thought was: pass them in as ints, then require the visitor to do map(str, path) themselves10:01
ghostmansd[m]Does it matter? As I know Python is capable of converting the strings to integers... :-)10:01
programmerjakemy plan is to use the mentioned fixed version of pytest, that was just my explanation of how we got where we are now10:01
lkclghostmansd[m], bleck10: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
lkclprogrammerjake, understood10:02
lkclghostmansd[m], it was just an idea10:02
ghostmansd[m]Ah OK, got it10:02
programmerjakefor the visitor imho passing indexes as integers and field names as strings is the best combination10:02
ghostmansd[m]Well integers are fine for sequence-like stuff10:03
ghostmansd[m]But we mostly have dicts and dataclasses there10: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 strings10:04
programmerjakeso a['a'].b[1].c would use 'a', 'b', 1, and 'c'10:04
lkclmmmhmmm... that would work10:04
ghostmansd[m]But I need some rationale if we do it10:04
ghostmansd[m]I mean, why id is better than a raw string :-)10:05
lkclit's like LDAP / X.50010: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 rationale10:05
* lkcl thinking about the a b 1 c example10:05
lkcland 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 unification10:06
ghostmansd[m]That is, having one type is better than having two10:06
ghostmansd[m]But I cannot come up with another reason10:06
programmerjakeidea: 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 everything10:07
ghostmansd[m]And, more importantly, I cannot come up with reason why int, not string10:07
lkclprogrammerjake, oh - nice.10:07
lkclghostmansd[m], i think it sensible to proceed using what we have, and see what works and what doesn't10:07
programmerjakei can come up with a reason to use int: it makes it much easier to access previous/next entry from the visitor10:08
programmerjakejust parent[idx + 1] instead of parent[str(int(idx) + 1)]10:08
lkclprogrammerjake, ahhh10:08
lkclghostmansd[m], didn't you add Visitor[x] already?10:09
lkclghostmansd[m], oh whoops10:10
programmerjakenote i didn't actually read the full visitors conversation (yet) since you sent a *lot* of emails10:10
lkcl  File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/insndb/", line 1125, in Rc10:10
lkcl    return self["Rc"].value10:10
lkcl  File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/insndb/", line 1119, in __getitem__10:10
lkcl    return cls(record=self, **kwargs)10:10
lkclTypeError: type object argument after ** must be a mapping, not tuple10:10
lkclprogrammerjake, it's been... reaallly complex just for a few lines of code, trying to communicate through an internet-deluge of broken visitor patterns10:11
programmerjakeyeah, just wanted to mention that so you wouldn't be offended if i suggest something you already considered or something10:12
programmerjakethat type error sounds like your calling the class get item even though you want a instance get item (which doesn't exist?)10:15
lkclthis is after ghostmansd[m] replaced dict with class Dict10:16
lkclso that makes sense10:16
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC10:16
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc10: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
lkclghostmansd[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
lkcli'll see if i can cope10:40
lkclit'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 work10:45
lkclit's perfectly reasonable to assume that if the user wants to modify the data, they have a good reason for doing so.10:47
lkclthat *immediately* reduces the amount of work needed to get the job done10:48
lkclnope, can't cope.10:50
lkcli'll investigate something else (spec writing)10:52
lkcloh fer god's sake :)11:06
lkcllterally, haha11:07
ghostmansd[m]That's not protecting, dicts are unhashable12:24
ghostmansd[m]I did the Dict hashable, but, if values are dicts too... well you know what I mean12:24
lkclahh yeah i do.  intriguing....13:19
lkclbtw 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!> has joined #libre-soc13:31
*** ghostmansd <ghostmansd!> has quit IRC13:34
lkclok sorted.13:37
lkcltemperatures are up, here, i'm going to have to be careful about how hard i run my laptop13:37
*** ghostmansd <ghostmansd!> has joined #libre-soc13:38
*** ghostmansd[hexch <ghostmansd[hexch!> has quit IRC13:40
lkclok "pytest -v -n 8" worked out fine in master after i cobbled together some reversions14:00
lkcl"paths" branch (which i force-pushed) is where master used to be14: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 brach14:13
lkclyes, 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
lkclthis is now too low-level to risk master branch stopping working14:27
lkclso i haven't "lost" anything - just put what the "current state" was into branch "paths" so it's not lost14:29
lkcl*then* did reversions14:29
*** ghostmansd[hexch <ghostmansd[hexch!> has joined #libre-soc15:09
*** ghostmansd <ghostmansd!> has quit IRC15:12
ghostmansd[m]Ok, I'll push further changes into a branch15:50
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC18:27
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc18:28
*** openpowerbot <openpowerbot!> has quit IRC20:04
programmerjakelkcl: if you're copying a commit, please use cherrypick, it has a standard commit format and is usually easier to use20:09
programmerjakeso, like `git cherry-pick -x <commits-to-copy>`20:12
*** openpowerbot <openpowerbot!> has joined #libre-soc20:18
ghostmansd[m]programmerjake, I had the same question :-)20:53
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC21:12
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc21:13
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC21:45
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc21:46
lkclprogrammerjake, that wasn't possible, otherwise i would have used it.23:57

Generated by 2.17.1 by Marius Gedminas - find it at!