| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 00:00 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 00:00 | |
| vaino[m] | little question, is the svp implementation in microwatt at the stage as described in the wiki? I'm wondering since this link https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv_analysis.py;hb=HEAD is dead on this page https://libre-soc.org/openpower/sv/implementation/ (under 4.1.) | 00:06 |
|---|---|---|
| lkcl | vaino[m], someone needs to do the work. if you're interested i don't mind putting in an NLnet Grant request for it | 00:10 |
| lkcl | (by "interested" i mean "interested and getting paid to do it") | 00:10 |
| *** josuah <josuah!~josuah@46.23.94.12> has quit IRC | 01:17 | |
| programmerjake | lkcl: I'd like to change the required version of pytest to 7.3.1 and pytest-xdist to 3.3.1 since we have to install from pip anyway and 3.x is ancient and ieee754fpu has required at least 6.0 for over a year and because with the plugin I wrote we don't have the running out of memory issue anymore | 02:08 |
| programmerjake | (those are the versions CI is currently using) | 02:09 |
| programmerjake | https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=pyproject.toml;h=267ae9af7d6f7a6cb20043c7f6289b3d53213f59;hb=658d12765b103405f7965a0d3c5e399446654686#l2 | 02:10 |
| programmerjake | I'm planning on adding a similar pyproject.toml with the pytest config to openpower-isa.git to always enable the plugin | 02:10 |
| programmerjake | (it's only used by pytest, so users don't need it unless they want to run tests using pytest) | 02:11 |
| programmerjake | that >=6.0 version requirement was committed may 2022 | 02:13 |
| programmerjake | created a branch containing the openpower-isa part of the proposed changes, for details, see https://bugs.libre-soc.org/show_bug.cgi?id=1100#c3 | 04:26 |
| programmerjake | important part: running pytest with SILENCELOG unset with 8 threads uses 9.46GiB ram on my system on the pytest7 branch and generates 5.8G of output log files in test-out/ | 04:26 |
| programmerjake | this is with fmv/fcvt and utf-8 tests re-enabled | 04:27 |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 07:08 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc | 07:08 | |
| lkcl | programmerjake, as long as you also update the devscripts - and check them - that will work really well. | 09:04 |
| lkcl | updating *only* the CI forces me into the position of having to do it | 09:05 |
| lkcl | *i* run tests using pytest. | 09:05 |
| lkcl | therefore it's important | 09:05 |
| lkcl | why was 6.0 chosen for ieee754fpu? | 09:08 |
| lkcl | (that decision should not have been made arbitrarily without a full review of the consequences of installing a different version than the project default) | 09:09 |
| lkcl | you see how that works? | 10:05 |
| lkcl | arbitrary decisions on which software version is used have ramifications for project management and maintainability | 10:05 |
| lkcl | they have to be consistent - for everyone | 10:06 |
| lkcl | so | 10:06 |
| lkcl | let's go through it (logic-walk-through) | 10:06 |
| lkcl | * debian/10 has pytest 3.3 which uses far more memory than 3.2.5 | 10:07 |
| lkcl | * therefore we have to use pip3 for installing pytest (sigh) | 10:07 |
| lkcl | which i did here: https://git.libre-soc.org/?p=dev-env-setup.git;a=commitdiff;h=b5eeac6cae7ba11b75edff61ac4111b57edc7fbd | 10:07 |
| lkcl | * with it no longer being possible to use the default in debian/10 *a* version can be picked | 10:08 |
| lkcl | * that version should be CONSISTENT across CI and the reproducible-build software-installation scripts | 10:08 |
| *** ghostmansd[hexch <ghostmansd[hexch!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 10:10 | |
| lkcl | so i don't actually mind at all what version is installed for pytest (and submoduls), as long as they're consistently used, and as long as they are specific versions | 10:12 |
| lkcl | allowing the version to change arbitrarily to latest-and-greatest breaks the entire concept "reproducible"! | 10:12 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 10:13 | |
| lkcl | ghostmansd[hexch, moornin :) | 10:29 |
| *** ghostmansd[hexch <ghostmansd[hexch!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 11:22 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 11:27 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.174.15> has joined #libre-soc | 11:27 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.174.15> has joined #libre-soc | 11:31 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.174.15> has quit IRC | 12:00 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.174.15> has joined #libre-soc | 12:23 | |
| *** ghostmansd[hexch <ghostmansd[hexch!~ghostmans@82.144.74.239> has joined #libre-soc | 12:34 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.174.15> has quit IRC | 12:34 | |
| *** ghostmansd[hexch <ghostmansd[hexch!~ghostmans@82.144.74.239> has quit IRC | 13:07 | |
| *** ghostmansd[hexch <ghostmansd[hexch!~ghostmans@82.144.74.239> has joined #libre-soc | 13:19 | |
| *** ghostmansd[hexch <ghostmansd[hexch!~ghostmans@82.144.74.239> has quit IRC | 13:46 | |
| *** ghostmansd <ghostmansd!~ghostmans@82.144.74.239> has joined #libre-soc | 13:49 | |
| *** ghostmansd <ghostmansd!~ghostmans@82.144.74.239> has quit IRC | 13:54 | |
| *** ghostmansd <ghostmansd!~ghostmans@82.144.74.239> has joined #libre-soc | 13:59 | |
| *** ghostmansd <ghostmansd!~ghostmans@82.144.74.239> has quit IRC | 14:32 | |
| *** ghostmansd <ghostmansd!~ghostmans@82.144.74.239> has joined #libre-soc | 14:32 | |
| ghostmansd | lkcl, I think I've found the solution which fits all our needs: https://bugs.libre-soc.org/show_bug.cgi?id=1094#c92 | 14:33 |
| ghostmansd | hell 95 comments in task already, that's crazy | 14:33 |
| ghostmansd | 20 LoC; perhaps 5-10 more with some cleanup and if registry is not global but per-class, but still impressive. And covers every damn class, regardless of whether it's Node, builtin, or anything else. | 14:35 |
| ghostmansd | The only thing I'd like to have is that these functions can be bound inside the class, as methods, without the need to pass the visitor class too. But all my attempts failed, and inspect module's magic is mentioned as fragile. | 14:39 |
| *** josuah <josuah!~josuah@46.23.94.12> has joined #libre-soc | 14:44 | |
| *** ghostmansd <ghostmansd!~ghostmans@82.144.74.239> has quit IRC | 15:11 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.174.15> has joined #libre-soc | 15:39 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.174.15> has quit IRC | 15:57 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.174.15> has quit IRC | 16:00 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.32> has joined #libre-soc | 16:03 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.162.32> has joined #libre-soc | 16:15 | |
| lkcl | i did say "if lots of lines equals bad"! :) | 16:47 |
| lkcl | ghostmansd, https://realpython.com/python-metaclasses/ | 16:54 |
| lkcl | search "One possible solution is a custom metaclass. " | 16:54 |
| lkcl | does it work creating entirely new registry dicts? | 16:57 |
| lkcl | it does! | 17:01 |
| ghostmansd | lkcl, sorry, I don't get what you ask | 17:02 |
| ghostmansd | if you ask whether I used metaclasses -- yes, I did :-) | 17:03 |
| ghostmansd | Pushed the new implementation to master | 17:05 |
| ghostmansd | It takes more lines, but most of them are checks and convenience wrappers | 17:05 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=1094#c102 | 17:07 |
| lkcl | ta-daaa, a per-class (even as classes not instances) registry. | 17:07 |
| lkcl | needs overriding of __new__ not __init__ | 17:07 |
| lkcl | " these functions can be bound inside the class, as methods, without the need to pass the visitor class too"... | 17:08 |
| lkcl | ehhhm... ehmehmehm... | 17:08 |
| lkcl | i mis-read that, and even re-reading it, it doesn't quite make sense yet | 17:09 |
| lkcl | https://sbcode.net/python/visitor/#visitorvisitor_conceptpy | 17:10 |
| lkcl | line 67, is that any good? | 17:10 |
| lkcl | oh god i just had an awful idea (if i know what you are referring to) | 17:11 |
| lkcl | in the metaclass __new__ which derives from type, *dig in* to the dictionary of functions/properties and override/redirect them (!) | 17:12 |
| ghostmansd | Overriding __init__ is fine: you'll end up with 1 registry per metaclass instance (which is a class) too. | 17:14 |
| lkcl | ok | 17:14 |
| ghostmansd | Another option would be editing ns in __new__ | 17:15 |
| lkcl | yes that was what i said (in different words). muhahaha | 17:16 |
| ghostmansd | But this would either need "_registry" field or some stuff like f"__{name}_registry" so that it can be used later as cls._registry or cls.__registry. | 17:16 |
| lkcl | that's so totally evil | 17:16 |
| ghostmansd | Well, this caaaaaan be simplified to 1 method if we drop Visitor[XXX] stuff | 17:17 |
| ghostmansd | because Visitor.__init_subclass__ is sufficient for just "goddamn edit any our subclass" | 17:17 |
| ghostmansd | But it doesn't allow such tricks, that's just a convenience wrapper so that for the most simple scenarios users don't have to create their damn metaclasses | 17:18 |
| ghostmansd | cf. new impl, I think it's mostly fine | 17:18 |
| lkcl | yeah i love it | 17:18 |
| ghostmansd | can be cut further, if we drop checks and some meat from metaclasses, but I think it's for better UX | 17:19 |
| ghostmansd | (whatever this means) | 17:19 |
| lkcl | :) | 17:19 |
| ghostmansd | what I love is that the decorator binds the stuff to an actual object | 17:19 |
| lkcl | the Visitor[xxx] kinda just feels like it would be useful. and list(Visitor) should DoTheRightThing as well | 17:19 |
| ghostmansd | and the name can be whataver we like | 17:20 |
| lkcl | yeah that's very cool | 17:20 |
| ghostmansd | "object" in Python sense, I mean, a type, but that's object too | 17:20 |
| ghostmansd | I feel we kinda reinvented pattern matching, though :-) | 17:20 |
| ghostmansd | (that's somewhat weird in Python, BTW: https://peps.python.org/pep-0636/) | 17:20 |
| lkcl | urrr that.... | 17:21 |
| ghostmansd | donnerwetter they finally got case keyword! | 17:21 |
| lkcl | Python-Version: | 17:21 |
| lkcl | 3.10 | 17:21 |
| lkcl | BLECH | 17:21 |
| ghostmansd | check the syntax, that really blows the mind | 17:21 |
| ghostmansd | totally alienish :-) | 17:21 |
| ghostmansd | but the concept is cool, I bet they have some uses for it | 17:22 |
| lkcl | yyeah python is going to shit because Guido's input was being ignored | 17:22 |
| lkcl | enough that he went "ok that's enough" and quit | 17:22 |
| ghostmansd | it's for exact matches, and we need a better flexibility where the users arbitrarily define the stuff | 17:22 |
| ghostmansd | > and quit | 17:22 |
| ghostmansd | IIRC he had some debates around some PEP | 17:23 |
| ghostmansd | ah yes, this one https://peps.python.org/pep-0572/ | 17:23 |
| ghostmansd | https://lwn.net/Articles/759654/ | 17:23 |
| ghostmansd | actually it seems this was HIS PEP | 17:24 |
| ghostmansd | fuck that's a brutal syntax | 17:24 |
| ghostmansd | a good idea to resign after it :-) | 17:25 |
| ghostmansd | so now they have match/case, :=, what's next?... | 17:25 |
| ghostmansd | x = 1, 2 # Sets x to (1, 2) | 17:26 |
| lkcl | map filter and reduce should all have been added to all iterables | 17:26 |
| ghostmansd | (x := 1, 2) # Sets x to 1 | 17:26 |
| ghostmansd | so brutal | 17:26 |
| lkcl | x.map(function) | 17:26 |
| lkcl | that's going to cause absolute chaos | 17:26 |
| ghostmansd | well they have experience with chaos, don't they?... | 17:27 |
| ghostmansd | I recall this (in)glorious str/bytes/unicode battle | 17:27 |
| ghostmansd | and other stuff which broke in Python3 | 17:27 |
| ghostmansd | so they, ahem, are not new to causing an absolute havoc | 17:27 |
| lkcl | there's been something... how can i put this... "wrong-in-the-mind" with the python software devs for some time. | 17:28 |
| ghostmansd | I'd say with many SW devs :-) | 17:28 |
| lkcl | :) | 17:28 |
| lkcl | i have a sneaking suspicion it's related to mirror-neuron atrophy | 17:28 |
| ghostmansd | but the exact definition of "wrong-in-the-mind" obviously differs with the particular person you ask :-) | 17:28 |
| lkcl | a side-effect of which is a complete inability to empathise | 17:28 |
| ghostmansd | :-D | 17:29 |
| ghostmansd | I remember such stuff from Dexter | 17:29 |
| lkcl | "how would you feel if that happened to you?" and they literally are unable to understand the question | 17:29 |
| ghostmansd | the best definition of maniac | 17:29 |
| lkcl | yes there's a standing joke in debian that if you pick any 5 debian developers you get an average of 10 mental disorders :) | 17:30 |
| ghostmansd | :-D | 17:30 |
| ghostmansd | that's kinda common for people in this profession, I bet even I have something, even though still manage to hide it undiagnosed! | 17:31 |
| lkcl | the mirror-neuron atrophy is a peer-reviewed study. "power corrupts" because they are never challenged, never get a chance to empathise | 17:31 |
| lkcl | just "telling people what to do" | 17:31 |
| lkcl | and the result is quite literally that the mirror-neurons, which are what allow you to "put yourself in someone else's shoes", atrophy | 17:32 |
| lkcl | ok afk need to walk about | 17:33 |
| ghostmansd | OK, see you later | 17:34 |
| ghostmansd | I'll continue working on walking :-) | 17:34 |
| lkcl | :) | 17:34 |
| ghostmansd | so we'll be both walking in some way :-D | 17:34 |
| *** ghostmansd[hexch <ghostmansd[hexch!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 19:36 | |
| *** ghostmansd[hexch <ghostmansd[hexch!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 19:39 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.162.32> has quit IRC | 19:39 | |
| *** ghostmansd[hexch <ghostmansd[hexch!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 19:40 | |
| *** ghostmansd[hexch is now known as ghostmansd | 19:40 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.32> has quit IRC | 19:40 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 19:42 | |
| ghostmansd | lkcl, I just thought: perhaps if we had a way to construct path, we could perhaps establish hooks on components (kinda similar to xpath in lxml2). | 19:44 |
| ghostmansd | Not sure if this is needed, but perhaps could find some uses. Not that I'm suggesting to implement it. In fact, I have no idea how to handle node names in a good way. | 19:45 |
| ghostmansd | Or, rather, how to handle them at all. | 19:45 |
| ghostmansd | lkcl, a short TL;DR on paths. I don't see a better choice for handling paths. The thing is that approach where the path is property or field of nodes fails, cf. comment 106. If you see an option how to handle this -- I'll change the code. | 21:26 |
| ghostmansd | Still, if indices are permitted, why paths aren't? | 21:27 |
| ghostmansd | For us "path" is just the name of the visitable, that's not a full path. | 21:27 |
| ghostmansd | The actual concatenation is done via your idea (stack + pop). Not inside the walk. | 21:28 |
| ghostmansd | The thing is that I need to move forward, and printing element path along with its value is perfect for debugging what entities lack the walk methods. | 21:29 |
| lkcl | indices are a known-pattern for Visitors (cf what jacob said) | 23:34 |
| lkcl | ok let's stick with it for now, and think of something later. | 23:34 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!