00:10 <vup> I am currently trying to write a layer that builds on top of nmigen and adds some (useful for me) features. For that I wanted to create a wrapper around `Module`. This is however impossible because the `__init_subclass__` raises. Is inheriting from `Module` just never supported? (I can of course just patching out `__init_subclass__` from `Module`, but that feel very dirty)

01:07 <whitequark> inheriting from nmigen classes (with a few exceptions) is intentionally not supported

01:07 <whitequark> if you do that, your code *will* break

01:07 <whitequark> instead, wrap them.

01:08 <whitequark> you don't need inheritance to wrap something, you can proxy calls

01:08 <whitequark> this inverts the relationship between our codebases and allows us to change the interface and implementation without breakage

01:18 <vup> hmm well I mean if I just proxy using getattr it doesn't really help, but I understand

01:19 <vup> I guess I will probably need a "proper" wrapper at some point anyways

09:24 <lkcl> whitequark: you saw, i am considering doing a (very limited) subset of the nmigen API sufficient to auto-generate c code? (Liskov Substitution Principle)

09:24 <lkcl> we have a massive (proven) body of work - the Power ISA decoder - which is needed elsewhere and i'm certainly not rewriting / duplicating it

09:25 <lkcl> easiest way: a drop-in API-compatible alternative that outputs c

09:27 <lkcl> the other option would, instead of a total ground-up replacement, would be to (carefully) implement the AST node-walker functions (the ones that output rtlil) with versions that output c, instead

09:29 <lkcl> although, like you pointed out above, i'm wary of doing that because it effectively treads on the internal options available to you (i.e. may have implied "support")

09:48 <whitequark> lkcl: the nmigen language (the stuff currently described on https://nmigen.info/nmigen/latest/lang.html and the stuff not yet described there) is a part of public API and you're free to reimplement it

09:48 <whitequark> there's an aspect where implementations may diverge

09:49 <whitequark> so long as this is your *private* implementation that aspect is unimportant

09:49 <whitequark> if you're going to publish it and advertise it as something nmigen-compatible it becomes important

09:49 <whitequark> so it's best to coordinate if you have that in your plans

11:10 <lkcl> whitequark, everything we do is public, never private

11:11 <lkcl> oh: nlnet RFP? :)

11:12 <whitequark> lkcl: RFP sent and money received

11:12 <lkcl> (on the c-generator, we're looking at maybe 8-10 months out, btw)

11:12 <lkcl> fantastic

11:12 <zignig_> lkcl: fyi gmt +8 .wa.au.

11:12 <whitequark> lkcl: regarding the c-generator, there is a difference between having code in public and actively promoting it

11:13 <whitequark> basically, the difference between "here's what we use for task X" and "here's what you should use for task X"

11:13 <whitequark> former? reimplement any of our APIs as much as you want no problem

11:13 <whitequark> latter? coordination is ideal

11:14 <lkcl> whitequark: ah yeah, got it. well, the idea is, it'll auto-generate code that ends up in the linux kernel

11:14 <lkcl> (for emulation of instructions that would be insane to put in hardware, even with nmigen)

11:15 <lkcl> OpenPOWER is mmmmental. NINE hundred and fifty instructions expected of a "RISC" system!

11:16 <whitequark> lkcl: as long as the use of the nmigen API itself stays roughly within your project, we're completely unconcerned with exactly what you're doing there, and, since you're implementing a public API, you're covered by our stability/evolution guarantees

11:16 <whitequark> so go aheda

11:16 <whitequark> if all you need is generate that code for linux? sure, no problem at all

11:16 <lkcl> appreciated.

11:16 <whitequark> since it will not affect language evolution in any way

11:16 <whitequark> and that's our main concern

11:17 <lkcl> however... the openpower-isa project is now independent, and the other idea (which has been picked up by someone with Formal Mathematical Proof expertise)

11:17 <lkcl> is to also add a translator that auto-generates Sail proofs