Russ Cox

No change in consensus, so **[accepted](https://golang.org/s/proposal-status#accepted)**. 🎉 This issue now tracks the work of implementing the proposal. — rsc for the proposal review group

This proposal has been added to the [active column](https://go.dev/s/proposal-status#active) of the proposals project and will now be reviewed at the weekly proposal review meetings. — rsc for the proposal review...

Part of the reason for the limit is that the implementation stores that many frames for every sample. We are planning to remove that bad implementation decision which will make...

@nsrip-dd As @prattmic mentioned above, the problem is that the [64]uintptr (now [512]uintptr in your CL) is stack allocated, and that's kind of a lot to zero during the signal...

It sounds like we all agree that we should make the pprof handler record many more stack frames by default, one way or another, and that therefore we don't need...

**Removed from the [proposal process](https://go.dev/s/proposal)**. This was determined not to be a “significant change to the language, libraries, or tools” or otherwise of significant importance or interest to the broader...

This proposal has been added to the [active column](https://go.dev/s/proposal-status#active) of the proposals project and will now be reviewed at the weekly proposal review meetings. — rsc for the proposal review...

It sounds like people are generally happy with ``` package encoding type ScalarMarshaler[T bool | int64 | uint64 | float64 | complex128] interface { MarshalScalar() (T, error) } type ScalarUnmarshaler[T...

Moving this to likely accept, but it seems like we should wait for Go 1.21 to make sure we land the encoder updates and the new implementations of these methods...

Based on the discussion above, this proposal seems like a **[likely accept](https://go.dev/s/proposal-status#likely-accept)**. — rsc for the proposal review group