08:49 <galibert[m]> Does C(0) work?

08:50 <galibert[m]> instead of 0 of course

08:52 <jfng[m]1> TypeError: int() argument must be a string, a bytes-like object or a real number, not a 'Const', during Signal instantiation this time

08:52 <galibert[m]> wow, didn't expect that one

08:52 <jfng[m]1> 0 works with other kinds of layouts, e.g. StructLayout, so i don't think that's the problem

08:53 <jfng[m]1> galibert[m]: it tries to do Const(Const(0)), i think

09:28 <jfng[m]1> found one way to do it: Value.cast(a).reset

10:45 <_whitenotifier-6> [amaranth-soc] jfng opened pull request #40: CSR register API prototype - https://github.com/amaranth-lang/amaranth-soc/pull/40

11:07 <_whitenotifier-6> [amaranth-soc] jfng edited pull request #40: CSR register API prototype - https://github.com/amaranth-lang/amaranth-soc/pull/40

11:08 <charlottia> <jfng[m]1> "found one way to do it: Value...." <- `a.as_value().reset` too. `a.reset` where `a` is a `View` is equal to `a["reset"]`, which for underlying `ArrayLayout`s, does a `word_select` (i.e. tries to slice the underlying signal, which would be desirable if you said `a[2]` or something). It tries to value-cast the string `"reset"` to use as an offset, which is the error you see there.

11:12 <jfng[m]1> i see, that aligns with what the stacktrace reported

11:12 <jfng[m]1> i'm just a bit surprised to step on a `TypeError` just by referencing an attribute of an object

11:13 <charlottia> I think it can be a little confusing, because Signal(shape, ...) where shape is a ShapeCastable subclass instance wraps the newly created Signal in that class, so while it looks like you just made a Signal which is now in a, you actually made a Signal and a View, and the View's in a and the Signal's its target/as_value().

11:13 <charlottia> > <@jfng:matrix.org> i see, that aligns with what the stacktrace reported

11:13 <charlottia> > i'm just a bit surprised to step on a `TypeError` just by referencing an attribute of an object

11:13 <charlottia> Yes; it's an "interesting" effect of the `getattr`->`getitem` forwarding `View` does, I guess?

11:14 <jfng[m]1> charlottia: yeah, and it won't be a `Signal` until you `Value.cast()` it

11:14 <charlottia> Yes, or as_value().

11:15 <charlottia> Maybe it'd be better if ArrayLayout-backed Views didn't do the getattr forwarding, to avoid this.

11:16 <charlottia> (right now View is generic enough to work for struct/union/array/flexible layout happy paths without any modification, but it complicates the non-happy paths like these.)

11:26 <jfng[m]1> agreed, gettattr forwarding is useful when your field have names (i.e. strings); since array fields use indices, you couldn't access them like that anyway

11:27 <charlottia> Indeed!