jakevin
jakevin
In fact ,this library must be read after the source code is understood. it is hard to use.
Maybe when I am free, I will consider rewriting by myself because ，the time I was wasting on this library might be enough for me to write by myself.
Hi, I'm willing to take this task up if it still exists. @quodlibetor @frankmcsherry
In the [doc](https://materialize.com/docs/sql/system-catalog/#mz_dataflow_operator_addresses), `mz_dataflow_operator_addresses` contains addresses for both operators and channels. It is indeed misleading. It may be better to replace it with `mz_dataflow_operator_channel_addresses`.
`mz_dataflow_operator_addresses` is in `system-catalog.md`, `diagnosing-using-sql.md`, `buildin.rs`, `hierarchical.jsx`, `memory.jsx`, `catalog.td`, `render-delta-join.td`. Do all need to be replaced? And the doc should also be corrected.
Hi, I willing to take this task up.
I'm not sure whether I got the right point of issue. In order to expose the underlying channel, Is it enough that modify [ch](ch chan interface{}) into Ch? I think...
> And also try to change the example test which I pointed to in the original description. The test should be changed, but it will be easy for me if...
Maybe I get the point. because underlying channel is't exposed, there aren't some tests. https://github.com/grpc/grpc-go/blob/997ce619eb555b6a481e741afa6390ad3cd80d5c/xds/internal/server/listener_wrapper_test.go#L212 change into `lw, readyCh, xdsC, lis, cleanup := newListenerWrapper(t)` And I should add some tests...