molon
molon
关于 spawnWorker 的调用时机在Lock外这点有相同的疑惑。 另外无意冒犯，想请教: 如果在固定了 pool 的 size 的前提下，想把一个 task 丢进 pool 里运行，大家一般都会想到预先开启size个gorountine 内部对一个chan进行loop，然后想往 pool 里塞任务的话只要往chan里丢就可以了，而且还直接 select ctx 之类的方法。 那ants选用 cond 锁来自己实现这块逻辑的最直接的好处在哪里呢？
> Did you manage to get this fixed? ``` func (fs *FileStream) Close() error { fmt.Println("Close", fs.path) if fs.f == nil { return nil // return errors.New("FileStream was never written...
貌似是不支持现在，可以自己加个自定义的decoder https://github.com/json-iterator/go/blob/27518f6661eba504be5a7a9a9f6d9460d892ade3/extra/fuzzy_decoder.go#L174-L192
> > the DialTLS says it's for non-proxied HTTPS requests，But if I want to make requests with transport and proxy，How to make that？ > > There are some code samples...
这个感觉不应该这个库来做，如果只是为了诸如stringWithFormat的需求的话，想?:@""也懒得写得话完全可以覆写一个stringWithFormat方法把字符串nil过滤成空就可以了啊。
@ibireme 如果确定sqlite官网版本的性能比较高，为何不考虑将其直接拎到pod里，有什么弊端么？
@ibireme 这样的话 或许再开一个带有最新版本sqlite的podspec是个好的选择。:)
个人感觉无论是不是为了防止app崩溃，属性的默认值这个口子还是很有必要的。 而json里的null则可以认作目的纯碎是为了让属性的值重置成默认值。 例如某NSInteger类型的属性默认值是-1而不是0。 NSString类型的属性默认值是@""而不是nil等等。 上述需求是需要`key->special default value`口子，这个也是就前几天就遇到这种真实需求。 而若为了防止崩溃，应该还要有下面两个口子: - `type->special default value`，例如NSString->@"" - 全局的`type->special default value`
> This is working as intended. See https://github.com/protocolbuffers/protobuf-go/releases/tag/v1.20.0#v1.20-nil-values for details. Is fuzzy unmarshal acceptable? For example, 64bit integers will be marshaled to string type, but `json.Number` can still be properly...
Another case: ``` &testv1.CaseValue{ Vs: []*structpb.Value{ structpb.NewNullValue(), nil, }, } ``` This results in an error `google.protobuf.Value: none of the oneof fields is set` Shouldn't the zero value of `google.protobuf.Value`...