maxilozoz

+1

你还是换个思路去考虑比较好 说个比较寻常的例子 你google一个技术问题 得到了很多答案 最终筛选了正确答案 你为什么就可以断定这种google的结果可信度很高？ 还不是你自己去测试及总结得到的答案？ 难道你指望这个repo手把手喂你？ 你要是有更好的答案你可以贴在issue 论文也好 博客也好 各种途径都行 大家一起讨论. 你这issue算是啥 能有啥对于repo本身的推进？

> > 你还是换个思路去考虑比较好 说个比较寻常的例子 > > 你google一个技术问题 得到了很多答案 最终筛选了正确答案 你为什么就可以断定这种google的结果可信度很高？ 还不是你自己去测试及总结得到的答案？ 难道你指望这个repo手把手喂你？ 你要是有更好的答案你可以贴在issue 论文也好 博客也好 各种途径都行 大家一起讨论. 你这issue算是啥 能有啥对于repo本身的推进？ > > 我希望去掉一些不合适的链接，以免造成误导。你这是不是杠精？ 你说不合适就不合适啊？ 你能不能用脑子读一读我说的 你有好的你拿出来啊 不识字么？二极管是不是

@CarlJi 没事了 谢谢， 没仔细看代码 v2的extra可以满足 我通过环境变量注入即可

@CarlJi extra可能会被多个同宿client污染 感觉还是需要service name 例子大概是 switch os.args(0) case...

count 和 watch是一样的 不一样的地方是在倒桩收集时会同时发送到通道并通知到server server提供了cover watch接口 可以用作及时触发覆盖率变化的通知 比如实时覆盖率展示

还有 https://github.com/qiniu/goc/blob/ee63433ca4e361e5e1f209e62757c5f402659edf/pkg/build/inject.go#L267-L283 这里如果mode是set 可以只有0 -> 1的时候才发通知到通道 可以提供个选项？选项的主旨是仅当第一次触发才通知 当然适用于其他mode 比如count > 0就不通知了 只有0 -> 1会通知 场景: 比如mode是set时 通过watch想实际变化后生成总覆盖率 但是现在的watch只要触发倒桩代码就会通知 假如有很多相同代码版本的service就会merge消耗cpu很多 这边暂时用了rate来限制 支持watch message 携带具体service id及extra也是为了变化时只去获取某一个service的profile 不然无法分辨哪个service的覆盖率变动了 只能全部profile get, merge也会很耗用cpu

> 另外，你这边怎么会要用到这个watch的能力呢？具体场景是怎样的呢？ 因为service不确定什么时候停止 也就是disconnect 比如版本的切换 服务自身的crash, 可能出现service停了然后去获取profile获取不到的情况 想着既然我不知道你什么时候停 那就只要变化了我就落地一次 同时采用rate和dirty机制(也就是落地过程中watch变化了1次就再也没有变化了)保证尽可能的获取最新的覆盖率 这边大概实现： extra会是 服务名_commitID 一个服务会跑多个版本去测试 再跑一个listener服务去watch goc server 拉取所有service 然后通过extra聚合落地

could add nestd option on `FieldOptions`? ```golang type FieldOptions struct { .... Nestd *bool } const ( .... Default_FieldOptions_Nestd = bool(false) ) func (x *FieldOptions) GetNestd() bool { if x...

> Altering the `FieldOptions` type would require a proposal upstream to the main protobuf group: https://github.com/protocolbuffers/protobuf > > Oh, I think I understand what you’re trying to do. You want...