GRPC for C Sharp

See:

Code Labs - Building a gRPC service with C#
A basic tutorial introduction to gRPC in C#.
This guide gets you started with gRPC in C# with a simple working example.

在生成grpc 服务的时候提示，是否因为我本地的google.protobuf 版本问题？
google/protobuf/wrappers.proto: File not found.
puppet/contact.proto:7:1: Import "google/protobuf/wrappers.proto" was not found or had errors.
puppet/contact.proto:63:3: "google.protobuf.StringValue" is not defined.
puppet/contact.proto:66:3: "google.protobuf.StringValue" is not defined.
puppet/contact.proto:72:3: "google.protobuf.StringValue" is not defined.
puppet/contact.proto:75:3: "google.protobuf.StringValue" is not defined.
google/protobuf/wrappers.proto: File not found.
puppet/friendship.proto:7:1: Import "google/protobuf/wrappers.proto" was not found or had errors.
puppet/friendship.proto:34:3: "google.protobuf.StringValue" is not defined.
puppet/friendship.proto:51:3: "google.protobuf.StringValue" is not defined.
puppet/friendship.proto:59:3: "google.protobuf.StringValue" is not defined.
google/protobuf/wrappers.proto: File not found.
puppet/message.proto:7:1: Import "google/protobuf/wrappers.proto" was not found or had errors.
puppet/message.proto:92:3: "google.protobuf.StringValue" is not defined.
puppet/message.proto:100:3: "google.protobuf.StringValue" is not defined.
puppet/message.proto:109:3: "google.protobuf.StringValue" is not defined.
puppet/message.proto:117:3: "google.protobuf.StringValue" is not defined.
puppet/message.proto:125:3: "google.protobuf.StringValue" is not defined.
google/protobuf/wrappers.proto: File not found.
puppet/room.proto:7:1: Import "google/protobuf/wrappers.proto" was not found or had errors.
puppet/room.proto:60:3: "google.protobuf.StringValue" is not defined.
puppet/room.proto:63:3: "google.protobuf.StringValue" is not defined.
puppet/room.proto:75:3: "google.protobuf.StringValue" is not defined.
puppet/room.proto:78:3: "google.protobuf.StringValue" is not defined.
google/protobuf/wrappers.proto: File not found.
puppet/room_invitation.proto:7:1: Import "google/protobuf/wrappers.proto" was not found or had errors.
puppet/room_invitation.proto:11:3: "google.protobuf.StringValue" is not defined.
google/protobuf/wrappers.proto: File not found.
puppet/tag.proto:7:1: Import "google/protobuf/wrappers.proto" was not found or had errors.
puppet/tag.proto:27:3: "google.protobuf.StringValue" is not defined.
google/protobuf/wrappers.proto: File not found.
puppet/contact.proto:7:1: Import "google/protobuf/wrappers.proto" was not found or had errors.
puppet/contact.proto:63:3: "google.protobuf.StringValue" is not defined.
puppet/contact.proto:66:3: "google.protobuf.StringValue" is not defined.
puppet/contact.proto:72:3: "google.protobuf.StringValue" is not defined.
puppet/contact.proto:75:3: "google.protobuf.StringValue" is not defined.
puppet/friendship.proto:7:1: Import "google/protobuf/wrappers.proto" was not found or had errors.
puppet/friendship.proto:34:3: "google.protobuf.StringValue" is not defined.
puppet/friendship.proto:51:3: "google.protobuf.StringValue" is not defined.
puppet/friendship.proto:59:3: "google.protobuf.StringValue" is not defined.
puppet/message.proto:7:1: Import "google/protobuf/wrappers.proto" was not found or had errors.
puppet/message.proto:92:3: "google.protobuf.StringValue" is not defined.
puppet/message.proto:100:3: "google.protobuf.StringValue" is not defined.
puppet/message.proto:109:3: "google.protobuf.StringValue" is not defined.
puppet/message.proto:117:3: "google.protobuf.StringValue" is not defined.
puppet/message.proto:125:3: "google.protobuf.StringValue" is not defined.
puppet/room.proto:7:1: Import "google/protobuf/wrappers.proto" was not found or had errors.
puppet/room.proto:60:3: "google.protobuf.StringValue" is not defined.
puppet/room.proto:63:3: "google.protobuf.StringValue" is not defined.
puppet/room.proto:75:3: "google.protobuf.StringValue" is not defined.
puppet/room.proto:78:3: "google.protobuf.StringValue" is not defined.
puppet/room_invitation.proto:7:1: Import "google/protobuf/wrappers.proto" was not found or had errors.
puppet/room_invitation.proto:11:3: "google.protobuf.StringValue" is not defined.
puppet/tag.proto:7:1: Import "google/protobuf/wrappers.proto" was not found or had errors.
puppet/tag.proto:27:3: "google.protobuf.StringValue" is not defined.
puppet.proto:19:1: Import "puppet/contact.proto" was not found or had errors.
puppet.proto:21:1: Import "puppet/friendship.proto" was not found or had errors.
puppet.proto:22:1: Import "puppet/message.proto" was not found or had errors.
puppet.proto:23:1: Import "puppet/room.proto" was not found or had errors.
puppet.proto:24:1: Import "puppet/room_invitation.proto" was not found or had errors.
puppet.proto:26:1: Import "puppet/tag.proto" was not found or had errors.
puppet.proto:53:26: "puppet.ContactSelfQRCodeRequest" is resolved to "wechaty.puppet.ContactSelfQRCodeRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.ContactSelfQRCodeRequest") to start from the outermost scope.
puppet.proto:53:68: "puppet.ContactSelfQRCodeResponse" is resolved to "wechaty.puppet.ContactSelfQRCodeResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.ContactSelfQRCodeResponse") to start from the outermost scope.
puppet.proto:54:24: "puppet.ContactSelfNameRequest" is resolved to "wechaty.puppet.ContactSelfNameRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.ContactSelfNameRequest") to start from the outermost scope.
puppet.proto:54:64: "puppet.ContactSelfNameResponse" is resolved to "wechaty.puppet.ContactSelfNameResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.ContactSelfNameResponse") to start from the outermost scope.
puppet.proto:55:29: "puppet.ContactSelfSignatureRequest" is resolved to "wechaty.puppet.ContactSelfSignatureRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.ContactSelfSignatureRequest") to start from the outermost scope.
puppet.proto:55:74: "puppet.ContactSelfSignatureResponse" is resolved to "wechaty.puppet.ContactSelfSignatureResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.ContactSelfSignatureResponse") to start from the outermost scope.
puppet.proto:62:23: "puppet.ContactPayloadRequest" is resolved to "wechaty.puppet.ContactPayloadRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.ContactPayloadRequest") to start from the outermost scope.
puppet.proto:62:63: "puppet.ContactPayloadResponse" is resolved to "wechaty.puppet.ContactPayloadResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.ContactPayloadResponse") to start from the outermost scope.
puppet.proto:64:21: "puppet.ContactAliasRequest" is resolved to "wechaty.puppet.ContactAliasRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.ContactAliasRequest") to start from the outermost scope.
puppet.proto:64:58: "puppet.ContactAliasResponse" is resolved to "wechaty.puppet.ContactAliasResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.ContactAliasResponse") to start from the outermost scope.
puppet.proto:65:22: "puppet.ContactAvatarRequest" is resolved to "wechaty.puppet.ContactAvatarRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.ContactAvatarRequest") to start from the outermost scope.
puppet.proto:65:60: "puppet.ContactAvatarResponse" is resolved to "wechaty.puppet.ContactAvatarResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.ContactAvatarResponse") to start from the outermost scope.
puppet.proto:67:20: "puppet.ContactListRequest" is resolved to "wechaty.puppet.ContactListRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.ContactListRequest") to start from the outermost scope.
puppet.proto:67:63: "puppet.ContactListResponse" is resolved to "wechaty.puppet.ContactListResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.ContactListResponse") to start from the outermost scope.
puppet.proto:74:26: "puppet.FriendshipPayloadRequest" is resolved to "wechaty.puppet.FriendshipPayloadRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.FriendshipPayloadRequest") to start from the outermost scope.
puppet.proto:74:69: "puppet.FriendshipPayloadResponse" is resolved to "wechaty.puppet.FriendshipPayloadResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.FriendshipPayloadResponse") to start from the outermost scope.
puppet.proto:76:30: "puppet.FriendshipSearchPhoneRequest" is resolved to "wechaty.puppet.FriendshipSearchPhoneRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.FriendshipSearchPhoneRequest") to start from the outermost scope.
puppet.proto:76:76: "puppet.FriendshipSearchPhoneResponse" is resolved to "wechaty.puppet.FriendshipSearchPhoneResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.FriendshipSearchPhoneResponse") to start from the outermost scope.
puppet.proto:77:31: "puppet.FriendshipSearchWeixinRequest" is resolved to "wechaty.puppet.FriendshipSearchWeixinRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.FriendshipSearchWeixinRequest") to start from the outermost scope.
puppet.proto:77:78: "puppet.FriendshipSearchWeixinResponse" is resolved to "wechaty.puppet.FriendshipSearchWeixinResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.FriendshipSearchWeixinResponse") to start from the outermost scope.
puppet.proto:79:22: "puppet.FriendshipAddRequest" is resolved to "wechaty.puppet.FriendshipAddRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.FriendshipAddRequest") to start from the outermost scope.
puppet.proto:79:60: "puppet.FriendshipAddResponse" is resolved to "wechaty.puppet.FriendshipAddResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.FriendshipAddResponse") to start from the outermost scope.
puppet.proto:80:25: "puppet.FriendshipAcceptRequest" is resolved to "wechaty.puppet.FriendshipAcceptRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.FriendshipAcceptRequest") to start from the outermost scope.
puppet.proto:80:66: "puppet.FriendshipAcceptResponse" is resolved to "wechaty.puppet.FriendshipAcceptResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.FriendshipAcceptResponse") to start from the outermost scope.
puppet.proto:87:23: "puppet.MessagePayloadRequest" is resolved to "wechaty.puppet.MessagePayloadRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessagePayloadRequest") to start from the outermost scope.
puppet.proto:87:63: "puppet.MessagePayloadResponse" is resolved to "wechaty.puppet.MessagePayloadResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessagePayloadResponse") to start from the outermost scope.
puppet.proto:89:23: "puppet.MessageContactRequest" is resolved to "wechaty.puppet.MessageContactRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageContactRequest") to start from the outermost scope.
puppet.proto:89:62: "puppet.MessageContactResponse" is resolved to "wechaty.puppet.MessageContactResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageContactResponse") to start from the outermost scope.
puppet.proto:90:20: "puppet.MessageFileRequest" is resolved to "wechaty.puppet.MessageFileRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageFileRequest") to start from the outermost scope.
puppet.proto:90:56: "puppet.MessageFileResponse" is resolved to "wechaty.puppet.MessageFileResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageFileResponse") to start from the outermost scope.
puppet.proto:91:21: "puppet.MessageImageRequest" is resolved to "wechaty.puppet.MessageImageRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageImageRequest") to start from the outermost scope.
puppet.proto:91:58: "puppet.MessageImageResponse" is resolved to "wechaty.puppet.MessageImageResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageImageResponse") to start from the outermost scope.
puppet.proto:92:27: "puppet.MessageMiniProgramRequest" is resolved to "wechaty.puppet.MessageMiniProgramRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageMiniProgramRequest") to start from the outermost scope.
puppet.proto:92:70: "puppet.MessageMiniProgramResponse" is resolved to "wechaty.puppet.MessageMiniProgramResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageMiniProgramResponse") to start from the outermost scope.
puppet.proto:93:19: "puppet.MessageUrlRequest" is resolved to "wechaty.puppet.MessageUrlRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageUrlRequest") to start from the outermost scope.
puppet.proto:93:54: "puppet.MessageUrlResponse" is resolved to "wechaty.puppet.MessageUrlResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageUrlResponse") to start from the outermost scope.
puppet.proto:95:27: "puppet.MessageSendContactRequest" is resolved to "wechaty.puppet.MessageSendContactRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageSendContactRequest") to start from the outermost scope.
puppet.proto:95:70: "puppet.MessageSendContactResponse" is resolved to "wechaty.puppet.MessageSendContactResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageSendContactResponse") to start from the outermost scope.
puppet.proto:96:24: "puppet.MessageSendFileRequest" is resolved to "wechaty.puppet.MessageSendFileRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageSendFileRequest") to start from the outermost scope.
puppet.proto:96:64: "puppet.MessageSendFileResponse" is resolved to "wechaty.puppet.MessageSendFileResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageSendFileResponse") to start from the outermost scope.
puppet.proto:97:24: "puppet.MessageSendTextRequest" is resolved to "wechaty.puppet.MessageSendTextRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageSendTextRequest") to start from the outermost scope.
puppet.proto:97:64: "puppet.MessageSendTextResponse" is resolved to "wechaty.puppet.MessageSendTextResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageSendTextResponse") to start from the outermost scope.
puppet.proto:98:31: "puppet.MessageSendMiniProgramRequest" is resolved to "wechaty.puppet.MessageSendMiniProgramRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageSendMiniProgramRequest") to start from the outermost scope.
puppet.proto:98:78: "puppet.MessageSendMiniProgramResponse" is resolved to "wechaty.puppet.MessageSendMiniProgramResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageSendMiniProgramResponse") to start from the outermost scope.
puppet.proto:99:23: "puppet.MessageSendUrlRequest" is resolved to "wechaty.puppet.MessageSendUrlRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageSendUrlRequest") to start from the outermost scope.
puppet.proto:99:62: "puppet.MessageSendUrlResponse" is resolved to "wechaty.puppet.MessageSendUrlResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageSendUrlResponse") to start from the outermost scope.
puppet.proto:101:22: "puppet.MessageRecallRequest" is resolved to "wechaty.puppet.MessageRecallRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageRecallRequest") to start from the outermost scope.
puppet.proto:101:60: "puppet.MessageRecallResponse" is resolved to "wechaty.puppet.MessageRecallResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.MessageRecallResponse") to start from the outermost scope.
puppet.proto:108:20: "puppet.RoomPayloadRequest" is resolved to "wechaty.puppet.RoomPayloadRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomPayloadRequest") to start from the outermost scope.
puppet.proto:108:57: "puppet.RoomPayloadResponse" is resolved to "wechaty.puppet.RoomPayloadResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomPayloadResponse") to start from the outermost scope.
puppet.proto:110:17: "puppet.RoomListRequest" is resolved to "wechaty.puppet.RoomListRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomListRequest") to start from the outermost scope.
puppet.proto:110:57: "puppet.RoomListResponse" is resolved to "wechaty.puppet.RoomListResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomListResponse") to start from the outermost scope.
puppet.proto:112:16: "puppet.RoomAddRequest" is resolved to "wechaty.puppet.RoomAddRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomAddRequest") to start from the outermost scope.
puppet.proto:112:48: "puppet.RoomAddResponse" is resolved to "wechaty.puppet.RoomAddResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomAddResponse") to start from the outermost scope.
puppet.proto:113:19: "puppet.RoomAvatarRequest" is resolved to "wechaty.puppet.RoomAvatarRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomAvatarRequest") to start from the outermost scope.
puppet.proto:113:54: "puppet.RoomAvatarResponse" is resolved to "wechaty.puppet.RoomAvatarResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomAvatarResponse") to start from the outermost scope.
puppet.proto:114:19: "puppet.RoomCreateRequest" is resolved to "wechaty.puppet.RoomCreateRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomCreateRequest") to start from the outermost scope.
puppet.proto:114:54: "puppet.RoomCreateResponse" is resolved to "wechaty.puppet.RoomCreateResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomCreateResponse") to start from the outermost scope.
puppet.proto:115:16: "puppet.RoomDelRequest" is resolved to "wechaty.puppet.RoomDelRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomDelRequest") to start from the outermost scope.
puppet.proto:115:48: "puppet.RoomDelResponse" is resolved to "wechaty.puppet.RoomDelResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomDelResponse") to start from the outermost scope.
puppet.proto:116:17: "puppet.RoomQuitRequest" is resolved to "wechaty.puppet.RoomQuitRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomQuitRequest") to start from the outermost scope.
puppet.proto:116:50: "puppet.RoomQuitResponse" is resolved to "wechaty.puppet.RoomQuitResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomQuitResponse") to start from the outermost scope.
puppet.proto:118:18: "puppet.RoomTopicRequest" is resolved to "wechaty.puppet.RoomTopicRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomTopicRequest") to start from the outermost scope.
puppet.proto:118:52: "puppet.RoomTopicResponse" is resolved to "wechaty.puppet.RoomTopicResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomTopicResponse") to start from the outermost scope.
puppet.proto:119:19: "puppet.RoomQRCodeRequest" is resolved to "wechaty.puppet.RoomQRCodeRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomQRCodeRequest") to start from the outermost scope.
puppet.proto:119:54: "puppet.RoomQRCodeResponse" is resolved to "wechaty.puppet.RoomQRCodeResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomQRCodeResponse") to start from the outermost scope.
puppet.proto:120:21: "puppet.RoomAnnounceRequest" is resolved to "wechaty.puppet.RoomAnnounceRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomAnnounceRequest") to start from the outermost scope.
puppet.proto:120:58: "puppet.RoomAnnounceResponse" is resolved to "wechaty.puppet.RoomAnnounceResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomAnnounceResponse") to start from the outermost scope.
puppet.proto:136:30: "puppet.RoomInvitationPayloadRequest" is resolved to "wechaty.puppet.RoomInvitationPayloadRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomInvitationPayloadRequest") to start from the outermost scope.
puppet.proto:136:77: "puppet.RoomInvitationPayloadResponse" is resolved to "wechaty.puppet.RoomInvitationPayloadResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomInvitationPayloadResponse") to start from the outermost scope.
puppet.proto:137:29: "puppet.RoomInvitationAcceptRequest" is resolved to "wechaty.puppet.RoomInvitationAcceptRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomInvitationAcceptRequest") to start from the outermost scope.
puppet.proto:137:74: "puppet.RoomInvitationAcceptResponse" is resolved to "wechaty.puppet.RoomInvitationAcceptResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.RoomInvitationAcceptResponse") to start from the outermost scope.
puppet.proto:144:22: "puppet.TagContactAddRequest" is resolved to "wechaty.puppet.TagContactAddRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.TagContactAddRequest") to start from the outermost scope.
puppet.proto:144:60: "puppet.TagContactAddResponse" is resolved to "wechaty.puppet.TagContactAddResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.TagContactAddResponse") to start from the outermost scope.
puppet.proto:145:25: "puppet.TagContactRemoveRequest" is resolved to "wechaty.puppet.TagContactRemoveRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.TagContactRemoveRequest") to start from the outermost scope.
puppet.proto:145:66: "puppet.TagContactRemoveResponse" is resolved to "wechaty.puppet.TagContactRemoveResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.TagContactRemoveResponse") to start from the outermost scope.
puppet.proto:146:25: "puppet.TagContactDeleteRequest" is resolved to "wechaty.puppet.TagContactDeleteRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.TagContactDeleteRequest") to start from the outermost scope.
puppet.proto:146:66: "puppet.TagContactDeleteResponse" is resolved to "wechaty.puppet.TagContactDeleteResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.TagContactDeleteResponse") to start from the outermost scope.
puppet.proto:147:23: "puppet.TagContactListRequest" is resolved to "wechaty.puppet.TagContactListRequest", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.TagContactListRequest") to start from the outermost scope.
puppet.proto:147:62: "puppet.TagContactListResponse" is resolved to "wechaty.puppet.TagContactListResponse", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".puppet.TagContactListResponse") to start from the outermost scope.

It seems that you did not install the google.protobuf in your local development environment.
Please install google.protobuf before you continue, which I believe could fix your issue.

本地已经安装过google.protobuf了， 本地创建的一个grpc demo 可以正常build

之前一直使用nuget包中grpc.tools 的最新版本2.30.0生成报错，降级到2.27.0生成不报错，但是缺少google proto相关文件，最终从grpc 下载官网的 protoc-3.12.3-win64 生成成功

Congratulations!

Close this issue because #84 has been merged!


Raise a VagrantError rather than a RuntimeError for clearer message

I thought this was nicer and less confusing, what do you think?
old
$ vagrant status
There was an error loading a Vagrantfile. The file being loaded
and the error message are shown below. This is usually caused by
a syntax error.

Path: /Users/cindy/Projects/Personal/drupal-vm/Vagrantfile
Line number: 77
Message: RuntimeError: You must update Ansible to at least 2.2 to use this version of Drupal VM.

new
$ vagrant status
You must update Ansible to at least 2.2 to use this version of Drupal VM.

💯


Rescue master branch commits

This module has been given its 5 branch ahead of the rest of kitchen sink - so we should rescue the master branch commits.
The only one that seems worthwhile is 540d8abdf0aea6faa94b2131ca4fda5e0a26ac31
Acceptance Criteria

[ ] 540d8abdf0aea6faa94b2131ca4fda5e0a26ac31 has been merged into the 5 branch

PRs

Oops, I did that already: https://github.com/silverstripe/silverstripe-elemental/pull/1002


Fix memory leaks

This PR fix a problem related to memory leaks. When Layout gets the properties and methods it doesn't free the pointers after use.

Coverage increased (+0.01%) to 59.699% when pulling b0d6e937e0a3a7b818e5bd820e19fa5049713ee5 on marciliojrs:chore/release-unsafe-pointers into fb2170b2147d0993e164fc3f5fb40cb9a771caaa on schibsted:develop.

Thanks 👍


[BUG] Deepspeed elastic launcher is incompatible with torch 2.0

Describe the bug
If I run deepspeed with --elastic_training, I got the following error:
Traceback (most recent call last):
  File "./lib/python3.9/site-packages/torch/distributed/elastic/metrics/api.py", line 129, in wrapper
    result = f(*args, **kwargs)
  File "./lib/python3.9/site-packages/torch/distributed/elastic/agent/server/api.py", line 723, in run
    result = self._invoke_run(role)
  File "./lib/python3.9/site-packages/deepspeed/elasticity/elastic_agent.py", line 126, in _invoke_run
    self._initialize_workers(self._worker_group)
  File "./lib/python3.9/site-packages/torch/distributed/elastic/metrics/api.py", line 129, in wrapper
    result = f(*args, **kwargs)
  File "./lib/python3.9/site-packages/torch/distributed/elastic/agent/server/api.py", line 692, in _initialize_workers
    self._rendezvous(worker_group)
  File "./lib/python3.9/site-packages/torch/distributed/elastic/metrics/api.py", line 129, in wrapper
    result = f(*args, **kwargs)
  File "./lib/python3.9/site-packages/torch/distributed/elastic/agent/server/api.py", line 556, in _rendezvous
    self._set_master_addr_port(
TypeError: _set_master_addr_port() takes 3 positional arguments but 4 were given

The torch repository's pull request #88922 introduces an additional parameter called local_addr. You can find the specific code changes related to this parameter in this section of the commit. However, it appears that the deepspeed project is still using the outdated method and has not incorporated this new parameter yet.
To Reproduce
Run any script with --elastic_training
System info (please complete the following information):

Python 3.9
torch 2.0.1

Launcher context
deepspeed launcher

I want to learn about elastic training in DeepSpeed. I see the folder 'deepspeed/elasticity', but I can't find an introduction to this folder in the official tutorial. Can someone help? Thank you very much! @VeryLazyBoy @loadams

Hi @Truring, as a fellow newcomer in this area, I suggest checking out the following resources for a quick understanding:
Code comments on elastic config: GitHub link
Documentation on elastic config: DeepSpeed docs
For DeepSpeed's elastic launcher, it relies on torch.distributed.elastic. You can refer to the documentation for torch at: PyTorch docs

@VeryLazyBoy Thank you very much for sharing the resources! These materials are very useful to me.

I got the same error in my environment.
Environment
pytorch: 2.0.0+cu118
deepspeed: 0.13.0
"ds_config.json":
{
   "steps_per_print": 2000,
   "checkpoint": {
     "use_node_local_storage": true
   },
   "elasticity": {
     "enabled": true,
     "micro_batch_sizes": [256,512],
     "max_train_batch_size": 1024
   }
}

launching command:
deepspeed \
  --master_addr=rogpt1 \
  --elastic_training \
  --min_elastic_nodes=1 \
  --max_elastic_nodes=2 \
  --hostfile=hostfile \
  train.py \
  --deepspeed_config ds_config.json

** Error **
rogpt1:   File "/opt/conda/lib/python3.10/site-packages/torch/distributed/elastic/agent/server/api.py", line 556, in _rendezvous
rogpt1:     self._set_master_addr_port(
rogpt1: TypeError: DSElasticAgent._set_master_addr_port() takes 3 positional arguments but 4 were given

Thanks, @RobinDong - I apologize that I didn't get to this sooner.  Were you able to confirm on your side that this fixed it?

Hi @loadams, no problem. Thanks for your reply.
I have tested my PR and it could fix this problem.

Thanks @RobinDong


Unable to install SharePoint Migration Tool Public Preview (Version <IP_ADDRESS>)

Hi Im able to download the exe but when trying to install getting below error.

Im an Admin on this system
System Configuration

@ksgsharma thank you for submitting feedback.
I think the best way forward is if you open a service ticket in your tenant so this can get resolved ASAP. Based on the outcome let me know if it is something that can be called out in the docs.
Please follow this link to contact support for business products:https://docs.microsoft.com/office365/admin/contact-support-for-business-products
Please keep us posted here on the resolution so we can feed whatever information you discover into the content.
@officedocsbot close

@officedocsbot close


Facing issue - Python Flask framework -Part 4

Hello,
I am new to Python and Flask... I could follow the instructions on the Flask tutorial until I came across Sqlalchemy in Part 4 of the series.
I could import User and Post from flashblog in Python on command prompt. However when I try to create an instance of the user by setting the values for username, password and email I get an error. Can anyone please help me with this...When I execute the below...

user_1 = User(username='random'<EMAIL_ADDRESS>password='password')

The error I get is:
File "C:\Users\S\AppData\Local\Programs\Python\Python38-32\lib\site-packages\sqlalchemy\orm\instrumentation.py", line 376, in _new_state_if_none state = self._state_constructor(instance, self)
File "C:\Users\S\AppData\Local\Programs\Python\Python38-32\lib\site-packages\sqlalchemy\util\langhelpers.py", line 883, in get obj.dict[self.name] = result = self.fget(obj)
File "C:\Users\S\AppData\Local\Programs\Python\Python38-32\lib\site-packages\sqlalchemy\orm\instrumentation.py", line 202, in state_constructor self.dispatch.first_init(self, self.class)
File "C:\Users\S\AppData\Local\Programs\Python\Python38-32\lib\site-packages\sqlalchemy\event\attr.py", line 322, in call fn(*args, **kw)
File "C:\Users\S\AppData\Local\Programs\Python\Python38-32\lib\site-packages\sqlalchemy\orm\mapper.py", line 3392, in _event_on_first_init  configure_mappers()
File "C:\Users\S\AppData\Local\Programs\Python\Python38-32\lib\site-packages\sqlalchemy\orm\mapper.py", line 3276, in configure_mappers raise e
sqlalchemy.exc.InvalidRequestError: One or more mappers failed to initialize - can't proceed with initialization of other mappers. Triggering mapper: 'mapped class User->user'. Original exception was: When initializing mapper mapped class User->user, expression 'Post' failed to locate a name ('Post'). If this is a class name, consider adding this relationship() to the <class 'flaskblog.User'> class after both dependent classes have been defined.

Try to also set the author


Any example to quantise a text embedding model on Intel Gaudi2?

I was looking for example or documentation how I can load or quantise both a HF embedding model on Intel Gaudi2. is there any examples available? I don't want to use docker btw

@sleepingcat4
Please refer to:
https://github.com/intel/neural-compressor/tree/bfa27e422dc4760f6a9b1783eee7dae10fe5324f/examples/3.x_api/pytorch/nlp/huggingface_models/language-modeling/quantization/habana_fp8.

thank you! I will experiment with it tomorrow


Deprecate the swift.sourcekit-lsp.serverPath setting

Mixing and matching SourceKit-LSP servers and Swift toolchains is only supported in limited scenarios because they need to line up to a fair degree. The swift.sourcekit-lsp.serverPath setting is tremendously useful for SourceKit-LSP developers but I don’t think it should be exposed to general users. In some offline chats, we discussed if it makes sense to mark the setting as deprecated with a message like Only intended for debugging of SourceKit-LSP, which should hide it from the settings UI and thus from normal users. SourceKit-LSP developers will need to be told about the settings key and modify their settings.json manually.

Oh, great. I didn’t see that. Thanks!


Support serde deny_unknown_fields

Closes https://github.com/juhaku/utoipa/issues/812

@jayvdb Could you fix the merge conflicts, I caused them accidentally when I merged your other PR before this one.

No worries.  I was expecting the other PRs to be merged first, so all good.  Thanks for reminding me to rebase.


Fix AppVeyor setup

Would be nice if the AppVeyor setup was fixed so not all pull requests are marked as failed.

:+1:

AppVeyor is now working again.


Add full support for Ravenna streams

Add support for Ravenna streams with up to 64 Channels of audio. Audio backend should support that anyways.

Should be fixed with f090a8d but still needs testing.

Confirmed it is working with Ravenna Streams > 8 channels.


Gdomingu/codespaces config

Describe your change in plain English.
Adds some configuration to make it quick and easy to open and develop inside of a Codespace.  Much of the config was setup using the VSCode devcontainer setup GUI.
Link to the issue
Fixes https://github.com/rubyforgood/pet-rescue/issues/161

Closing because I don't think there is interest in supporting this despite its benefits. Apologies for the late response on this.


LiveShare icon feels alien to the stock icons

I think it needs an update to follow our newest icon styles in VSCode:

Similar here:

Maybe a more modern look?

Similar:

Thanks @bpasero. Adding @fubaduba for icon design updates.

Closing this as a duplicate of #2765.


added project-based-learning

html & css

hello have some contributions to make here. can i add them please


Support alternative value resolution for BaseSettings

https://github.com/pydantic/pydantic/issues/1676

Feature Request
My use case is I'm reading a toml config file and passing what is read directly to the model constructor. However, I have no way to allow users env var or .env overrides.
Essentially, configs persisted to disk cannot benefit from BaseSettings.

Hi @ofek, the way I'm currently doing it can be found here (basically defining a custom source, and rearranging the order in customise_sources). The only drawback is that I can't specify the filename (it is read from an envvar), but this might be useful still for your use case.

I've got a working implementation here that might be of interest:
https://github.com/uoft-networking/tools/blob/b1c67d6ce8def1b67af5b3ca08fe7357f595bb68/projects/core/uoft_core/__init__.py#L1209
The codebase is a mess, but it works.
Among other things it:

reads config from env vars
reads config from user-level and system-wide config files in yaml, toml, json, and ini formats
reads config from toml-formatted secrets stored in pass

If there's interest, I'd love to be able to clean it up and merge into pydantic-settings.
Right now I'm in the process of updating it to pydantic V2

Awesome, thank you!


Release/v1.116.13

Can someone approve this: its already reviewed by peter but he started the PR so it cannot be reviewed by him. @elwinschmitz @aberonni

The branch won't merge until it's updated with main. I don't want to do this myself to avoid causing issues because I'm unaware of the implications of this branch.


Fix PPU duplicates

Fixes #793.

@inglesp I've deployed this, but hadn't updated my local slack key, so it didn't report there.


When writing a custom debug adapter, variables won't clear on the test client.

I've been writing a custom debug adapter for vscode and have been running into the following issue:
When deploying your extension in server mode ( at least I haven't tested on extension host mode ), and the you drop stop the client abruptly, for any reason, whilst the front-end is still awaiting a request that affects the variables debug view, then even after the client has stopped, whatever values were in the view remain there and become locked. Starting a new debug session does not clear them, you have to open a new window with the project in order for them to clear.
These screenshots illustrate :

While debugging on the client, at the same time I have the adapter project being debugger on server mode, and paused while there is still a scopesRequest or variablesRequest response unfulfilled.

I've stopped the server without completing the request. The client's variables view remains locked with whatever was last in it.

It's happened both in the January and insider's build.

@harold-b
I am writing a debug adapter too, and can not show variables on the test client. I created #3455 for it. Could you please give me some advise?
Thanks.

this is a duplicate of #3666


DotCJade06 is disabled

Machine DotCJade-06 in queue windows.server.arm64.perf has been taken offline at request of @LoopedBard3

Except... this machine and queue are not found in the inventory. A mystery!

Helix was happy to disable the machine though.

It is now back online.

it was requested again to put this machines offline

It is now back online.


Implement project picker

Closes https://github.com/applandinc/appmap-intellij-plugin/issues/75
Status:

[x] Language detection for a directory and its subtree
[x] Java language analyzer
[x] Tests for Java language analyzer
[x] Updates web components for quickstart and appland JS applications
[x] Added Lombok to project for easier source setup
[x] Add web application to render JSON into an HTML page similar to the VSCode plugin's view
[x] Integrate language analyzer and detection results into webview
[ ] Integrate other language analyzers if needed

Current status:

Short demo:

Superseded by https://github.com/applandinc/appmap-intellij-plugin/pull/81, which is a cleaner PR


DT getActiveHand compatibility

Minecraft: 1.12.2
Forge: 2705 and 2757
DT: 0.7.8
PinklySheep: 4.0b6
When chopping down a DT Oak tree, I CTD. This happens on both single and multiplayer. Note: on the server only the client crashes, the server still runs and doesn't have any errors. After relaunching, the BWM and DT drops are there, but if there are supposed to be PS drops they do not. I've already submitted this issue on PS's end here as well.
The object in hand does not matter, I've tried bare handed, stone axe, and accidentally bonemeal. This occurs in both creative and survival
Having investigated this, Wabbit0101 has identified that this issue is occurring due to a mismatch in the way DT and PS check for the item in hand.
DT uses the call ItemStack heldItem = player.getHeldItemMainhand();
Whereas PS uses Player::getActiveHand instead (which allows for either mainhand or offhand use.
When this occurs, Minecraft crashes due to Player::getActiveHand being NULL (since DT doesn't set it).
This would be awesome if we could get an update to resolve this issue. I imagine that most likely any derived compat modules would also need to be updated to this as well (BoP, Thaumcraft, Heat and Climate). Though I run into the other issue I posted with BoP, and am not using Thaumcraft due to a (now resolved) compatibility issue between Metal Chests and Thaumcraft.

@ferreusveritas For the record, did the update on curse today include this fix? Or do I have to build the commit?

I released moments before you posted.  So you'll need to build or wait a few days.

The fix isn't right.  I'm getting a crash now.

Is it perhaps supposed to just be player.getActiveHand rather than player.getHeldItem(player.getActiveHand)?

I did add a check for a null item anyway so the latest dev might work for you.  At least it shouldn't crash.

I'll test it as soon as I get my workspace setup, been having problems getting things setup.

This has been resolved in PinklySheep.  This issue is too weird for me.  Block::removedByPlayer(...) is called by PlayerControllerMP::onPlayerDestroyBlock(...) and the player parameter can sometimes have a null for it's active hand, which shouldn't be possible since that object originates from Minecraft itself and should be fully valid.  I could set the player's active hand when it's null but should I do that?  There's no reason for me to get the held item from an offhand because as far as I understand it the tool isn't supposed to work that way anyway.  I was unable to chop a tree with an axe or any other tool in the off hand no matter what I tried.  There may be modded axes that allow off hand use but in the end this doesn't seem like my problem.  It seems like it could potentially be a forge problem.


feat: accept any version greater or equal to 1.14.0

This accepts maplibre-gl v2 as a peer dependency.

[x] briefly describe the changes in this PR
[ ] write tests for all new functionality
[x] run npm run docs and commit changes to API.md
[x] update CHANGELOG.md with changes under master heading before merging

Thanks for this. I think it would be good to have the test running in this repo on pull requests. Any chance to review #34 ?

When you update package.json, please make sure to also run npm install such that the changes are reflected in package-lock.json.
At the moment, I get the following diff:
diff --git a/package-lock.json b/package-lock.json
index 0faa298..14875db 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -1,12 +1,12 @@
 {
   "name": "@maplibre/maplibre-gl-geocoder",
-  "version": "1.3.0",
+  "version": "1.3.1",
   "lockfileVersion": 2,
   "requires": true,
   "packages": {
     "": {
       "name": "@maplibre/maplibre-gl-geocoder",
-      "version": "1.3.0",
+      "version": "1.3.1",
       "license": "ISC",
       "dependencies": {
         "lodash.debounce": "^4.0.6",
@@ -38,7 +38,7 @@
         "node": ">=6"
       },
       "peerDependencies": {
-        "maplibre-gl": "^1.14.0"
+        "maplibre-gl": ">=1.14.0"
       }
     },
     "node_modules/@babel/code-frame": {

The part about the plugin version 1.3.1 is related to the fact that we forgot to run npm install at the last version bump.

ha yeah, forgot this one. saw your PR https://github.com/maplibre/maplibre-gl-geocoder/pull/45 too :)

I've rebased to enable CI :)

Just to double-check, you tried this out with MapLibre GL JS v2.1.8?

Just to double-check, you tried this out with MapLibre GL JS v2.1.8?

I tried with 2.1.6 :)
Code is very similar to https://maplibre.org/maplibre-gl-js-docs/example/geocoder/ which seems to use v2.1.7


Update 3d registration tutorial

Is your feature request related to a problem? Please describe.
As the extract_levels implementation has been updated, the tutorial needs to be updated accordingly.
Describe the solution you'd like
Option 1: change extract_levels from [0, 1, 2, 3] to [3] to maintain the same model architecture as the pretrained weight.
Option 2: train a new model
Describe alternatives you've considered
Option 1 could be a quick fix during the training of option 2.
Additional context
N/A

thanks @kate-sann5100, I think option1 would be a good workaround for now. currently the ci is getting this error:
10:10:05  Running ./3d_registration/paired_lung_ct.ipynb
10:10:05  Checking PEP8 compliance...
10:10:05  Running notebook...
10:10:05  Before:
10:10:05      "max_epochs = 5\n",
10:10:05  After:
10:10:05      "max_epochs = 1\n",
10:10:05  Before:
10:10:05      "val_interval = 1\n",
10:10:05  After:
10:10:05      "val_interval = 1\n",
10:10:09  MONAI version: 1.0.0+120.gc8ef7fe1
10:10:09  Numpy version: 1.22.2
10:10:09  Pytorch version: 1.10.2+cu102
10:10:09  MONAI flags: HAS_EXT = False, USE_COMPILED = False, USE_META_DICT = False
10:10:09  MONAI rev id: c8ef7fe1ca3d2fbed135a60d288063d536a58eb6
10:10:09  MONAI __file__: /home/jenkins/agent/workspace/Monai-notebooks/MONAI/monai/__init__.py
10:10:09
10:10:09  Optional dependencies:
10:10:09  Pytorch Ignite version: 0.4.10
10:10:09  Nibabel version: 4.0.2
10:10:09  scikit-image version: 0.19.3
10:10:09  Pillow version: 7.0.0
10:10:09  Tensorboard version: 2.11.0
10:10:09  gdown version: 4.5.3
10:10:09  TorchVision version: 0.11.3+cu102
10:10:09  tqdm version: 4.64.1
10:10:09  lmdb version: 1.3.0
10:10:09  psutil version: 5.9.2
10:10:09  pandas version: 1.1.5
10:10:09  einops version: 0.6.0
10:10:09  transformers version: 4.21.3
10:10:09  mlflow version: 2.0.1
10:10:09  pynrrd version: 1.0.0
10:10:09
10:10:09  For details about installing the optional dependencies, please visit:
10:10:09      https://docs.monai.io/en/latest/installation.html#installing-the-recommended-dependencies
10:10:09
10:10:10  /opt/conda/lib/python3.8/site-packages/papermill/iorw.py:153: UserWarning: the file is not specified with any extension : -
10:10:10    warnings.warn(
10:23:01
Executing:   0%|          | 0/35 [00:00<?, ?cell/s]
Executing:   3%|▎         | 1/35 [00:01<00:46,  1.37s/cell]
Executing:   9%|▊         | 3/35 [00:06<01:17,  2.42s/cell]
Executing:  14%|█▍        | 5/35 [00:10<01:00,  2.01s/cell]
Executing:  26%|██▌       | 9/35 [11:50<45:28, 104.95s/cell]
Executing:  49%|████▊     | 17/35 [11:53<11:44, 39.15s/cell]
Executing:  54%|█████▍    | 19/35 [11:57<08:37, 32.33s/cell]
Executing:  60%|██████    | 21/35 [12:00<06:02, 25.90s/cell]
Executing:  71%|███████▏  | 25/35 [12:46<03:25, 20.51s/cell]
Executing:  80%|████████  | 28/35 [12:46<01:42, 14.69s/cell]
Executing:  89%|████████▊ | 31/35 [12:48<00:42, 10.65s/cell]
Executing:  89%|████████▊ | 31/35 [12:50<01:39, 24.85s/cell]
10:23:01  /opt/conda/lib/python3.8/site-packages/papermill/iorw.py:153: UserWarning: the file is not specified with any extension : -
10:23:01    warnings.warn(
10:23:01  Traceback (most recent call last):
10:23:01    File "/opt/conda/bin/papermill", line 8, in <module>
10:23:01      sys.exit(papermill())
10:23:01    File "/opt/conda/lib/python3.8/site-packages/click/core.py", line 1130, in __call__
10:23:01      return self.main(*args, **kwargs)
10:23:01    File "/opt/conda/lib/python3.8/site-packages/click/core.py", line 1055, in main
10:23:01      rv = self.invoke(ctx)
10:23:01    File "/opt/conda/lib/python3.8/site-packages/click/core.py", line 1404, in invoke
10:23:01      return ctx.invoke(self.callback, **ctx.params)
10:23:01    File "/opt/conda/lib/python3.8/site-packages/click/core.py", line 760, in invoke
10:23:01      return __callback(*args, **kwargs)
10:23:01    File "/opt/conda/lib/python3.8/site-packages/click/decorators.py", line 26, in new_func
10:23:01      return f(get_current_context(), *args, **kwargs)
10:23:01    File "/opt/conda/lib/python3.8/site-packages/papermill/cli.py", line 250, in papermill
10:23:01      execute_notebook(
10:23:01    File "/opt/conda/lib/python3.8/site-packages/papermill/execute.py", line 128, in execute_notebook
10:23:01      raise_for_execution_errors(nb, output_path)
10:23:01    File "/opt/conda/lib/python3.8/site-packages/papermill/execute.py", line 232, in raise_for_execution_errors
10:23:01      raise error
10:23:01  papermill.exceptions.PapermillExecutionError:
10:23:01  ---------------------------------------------------------------------------
10:23:01  Exception encountered at "In [15]":
10:23:01  ---------------------------------------------------------------------------
10:23:01  RuntimeError                              Traceback (most recent call last)
10:23:01  Cell In [15], line 4
10:23:01        2 dst = f"{root_dir}/pretrained_weight.pth"
10:23:01        3 download_url(resource, dst)
10:23:01  ----> 4 model.load_state_dict(torch.load(dst))
10:23:01
10:23:01  File /opt/conda/lib/python3.8/site-packages/torch/nn/modules/module.py:1482, in Module.load_state_dict(self, state_dict, strict)
10:23:01     1477         error_msgs.insert(
10:23:01     1478             0, 'Missing key(s) in state_dict: {}. '.format(
10:23:01     1479                 ', '.join('"{}"'.format(k) for k in missing_keys)))
10:23:01     1481 if len(error_msgs) > 0:
10:23:01  -> 1482     raise RuntimeError('Error(s) in loading state_dict for {}:\n\t{}'.format(
10:23:01     1483                        self.__class__.__name__, "\n\t".join(error_msgs)))
10:23:01     1484 return _IncompatibleKeys(missing_keys, unexpected_keys)
10:23:01
10:23:01  RuntimeError: Error(s) in loading state_dict for LocalNet:
10:23:01  	Missing key(s) in state_dict: "decode_deconvs.0.deconv.conv.weight", "decode_deconvs.0.deconv.adn.N.weight", "decode_deconvs.0.deconv.adn.N.bias", "decode_deconvs.0.deconv.adn.N.running_mean", "decode_deconvs.0.deconv.adn.N.running_var", "decode_deconvs.1.deconv.conv.weight", "decode_deconvs.1.deconv.adn.N.weight", "decode_deconvs.1.deconv.adn.N.bias", "decode_deconvs.1.deconv.adn.N.running_mean", "decode_deconvs.1.deconv.adn.N.running_var", "decode_deconvs.2.deconv.conv.weight", "decode_deconvs.2.deconv.adn.N.weight", "decode_deconvs.2.deconv.adn.N.bias", "decode_deconvs.2.deconv.adn.N.running_mean", "decode_deconvs.2.deconv.adn.N.running_var", "decode_convs.0.0.conv.weight", "decode_convs.0.0.adn.N.weight", "decode_convs.0.0.adn.N.bias", "decode_convs.0.0.adn.N.running_mean", "decode_convs.0.0.adn.N.running_var", "decode_convs.0.1.layers.0.conv.weight", "decode_convs.0.1.layers.1.conv.weight", "decode_convs.0.1.norms.0.weight", "decode_convs.0.1.norms.0.bias", "decode_convs.0.1.norms.0.running_mean", "decode_convs.0.1.norms.0.running_var", "decode_convs.0.1.norms.1.weight", "decode_convs.0.1.norms.1.bias", "decode_convs.0.1.norms.1.running_mean", "decode_convs.0.1.norms.1.running_var", "decode_convs.1.0.conv.weight", "decode_convs.1.0.adn.N.weight", "decode_convs.1.0.adn.N.bias", "decode_convs.1.0.adn.N.running_mean", "decode_convs.1.0.adn.N.running_var", "decode_convs.1.1.layers.0.conv.weight", "decode_convs.1.1.layers.1.conv.weight", "decode_convs.1.1.norms.0.weight", "decode_convs.1.1.norms.0.bias", "decode_convs.1.1.norms.0.running_mean", "decode_convs.1.1.norms.0.running_var", "decode_convs.1.1.norms.1.weight", "decode_convs.1.1.norms.1.bias", "decode_convs.1.1.norms.1.running_mean", "decode_convs.1.1.norms.1.running_var", "decode_convs.2.0.conv.weight", "decode_convs.2.0.adn.N.weight", "decode_convs.2.0.adn.N.bias", "decode_convs.2.0.adn.N.running_mean", "decode_convs.2.0.adn.N.running_var", "decode_convs.2.1.layers.0.conv.weight", "decode_convs.2.1.layers.1.conv.weight", "decode_convs.2.1.norms.0.weight", "decode_convs.2.1.norms.0.bias", "decode_convs.2.1.norms.0.running_mean", "decode_convs.2.1.norms.0.running_var", "decode_convs.2.1.norms.1.weight", "decode_convs.2.1.norms.1.bias", "decode_convs.2.1.norms.1.running_mean", "decode_convs.2.1.norms.1.running_var", "output_block.layers.1.conv.weight", "output_block.layers.2.conv.weight", "output_block.layers.3.conv.weight".
10:23:01  	size mismatch for output_block.layers.0.conv.weight: copying a param with shape torch.Size([3, 256, 3, 3, 3]) from checkpoint, the shape in current model is torch.Size([3, 32, 3, 3, 3]).


[Extensiblity Bug] Module Azure Blob Services API Caption Problem

Hi al-team,
in the module Azure Blob Service Api it is possible to set HTTP Header via the predefined codeunit "ABS Optional Parameters".
When using the "Range" function, a label is used that does not have locked = true. This means that the translation is always used when setting the HTTP header.
The problem is that in some XLF files the translation is different from the caption, so the HTTP request runs into an error. (e.g. in the German translation)

Can you please fix this?
In this context, I have a further question. The module deals with downloading and uploading files to Azure Blob Storage.
Since the HTTPClient data type is used in the module, the server configurations NavHttpClientMaxResponseContentSize is relevant.
Is there any way to query this value via al at runtime?
Thank you!

Hi al-team,
can you please fix this? In BC 21 the problem still exists.

@JesperSchulz  @AlexanderYakunin I have additionally created this pull request.
#20592

Taking matters into your own hands is the way to go 🥳 We'll process your PR. Closing this issue, as I believe it isn't needed anymore.


Update EndlessSky to v0.8.2

Thank you for the contribution. It was merged directly as 05dbfb29ca332e6a1a8c60843dc17d9b0d8fd7b3 to keep commit history cleaner. Your contribution is still credited to you.


Attempted to log "TypeError: Cannot read property 'URL' of null

Hi, hoping to get some help with the current issue
I'm trying to run a test to a React component that uses AWS Amplify, my tests are run with Jest with jsdom environment, and I'm using msw
When the test run I'm getting this output

  ●  Cannot log after tests are done. Did you forget to wait for something async in your test?
    Attempted to log "TypeError: Cannot read property 'URL' of null
        at new XMLHttpRequestImpl (/Users/metis/Directories/amplify/frontend/node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:111:32)
        at Object.exports.setup (/Users/metis/Directories/amplify/frontend/node_modules/jsdom/lib/jsdom/living/generated/XMLHttpRequest.js:62:12)
        at new XMLHttpRequest (/Users/metis/Directories/amplify/frontend/node_modules/jsdom/lib/jsdom/living/generated/XMLHttpRequest.js:101:22)
        at dispatchXhrRequest (/Users/metis/Directories/amplify/frontend/node_modules/axios/lib/adapters/xhr.js:21:19)
        at new Promise (<anonymous>)
        at xhrAdapter (/Users/metis/Directories/Users/metis/Directories/amplify/frontend/node_modules/axios/lib/core/dispatchRequest.js:52:10)
        at processTicksAndRejections (internal/process/task_queues.js:95:5)".

      336 |                           <Checkbox
      337 |                             checked={isItemSelected}
    > 338 |                             inputProps={{ 'aria-labelledby': labelId }}
          |               ^
      339 |                           />
      340 |                         </TableCell>
      341 |                         <TableCell

      at new XMLHttpRequestImpl (node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:111:32)
      at Object.exports.setup (node_modules/jsdom/lib/jsdom/living/generated/XMLHttpRequest.js:62:12)
      at new XMLHttpRequest (node_modules/jsdom/lib/jsdom/living/generated/XMLHttpRequest.js:101:22)
      at dispatchXhrRequest (node_modules/axios/lib/adapters/xhr.js:21:19)
      at xhrAdapter (node_modules/axios/lib/adapters/xhr.js:13:10)
      at dispatchRequest (node_modules/axios/lib/core/dispatchRequest.js:52:10)
      at processTicksAndRejections (internal/process/task_queues.js:95:5)".
      at console.log (node_modules/@jest/console/build/CustomConsole.js:185:10)
      at retrieveDevices (src/Devices/Devices.js:338:15)
      at fetchData (src/Devices/Devices.js:320:9)

I tracked down the issue to the issue to be related to an object _ownerDocument being null. This issue is similar to this one https://github.com/mswjs/interceptors/issues/27
I have already spent some time trying to debug it but unfortunately can't find the solution, meanwhile, I'm sending the test data through props to the component to test it.

Well, today with a fresh mind, I realized the issue was due to the async behavior, and by adding a waitFor element in my tests solved the issue.

Hey. I'm glad you got it resolved. Great job.

Hi, hoping to get some help with the current issue
I'm trying to run a test to a React component that uses AWS Amplify, my tests are run with Jest with jsdom environment, and I'm using msw
When the test run I'm getting this output

  ●  Cannot log after tests are done. Did you forget to wait for something async in your test?
    Attempted to log "TypeError: Cannot read property 'URL' of null
        at new XMLHttpRequestImpl (/Users/metis/Directories/amplify/frontend/node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:111:32)
        at Object.exports.setup (/Users/metis/Directories/amplify/frontend/node_modules/jsdom/lib/jsdom/living/generated/XMLHttpRequest.js:62:12)
        at new XMLHttpRequest (/Users/metis/Directories/amplify/frontend/node_modules/jsdom/lib/jsdom/living/generated/XMLHttpRequest.js:101:22)
        at dispatchXhrRequest (/Users/metis/Directories/amplify/frontend/node_modules/axios/lib/adapters/xhr.js:21:19)
        at new Promise (<anonymous>)
        at xhrAdapter (/Users/metis/Directories/Users/metis/Directories/amplify/frontend/node_modules/axios/lib/core/dispatchRequest.js:52:10)
        at processTicksAndRejections (internal/process/task_queues.js:95:5)".

      336 |                           <Checkbox
      337 |                             checked={isItemSelected}
    > 338 |                             inputProps={{ 'aria-labelledby': labelId }}
          |               ^
      339 |                           />
      340 |                         </TableCell>
      341 |                         <TableCell

      at new XMLHttpRequestImpl (node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:111:32)
      at Object.exports.setup (node_modules/jsdom/lib/jsdom/living/generated/XMLHttpRequest.js:62:12)
      at new XMLHttpRequest (node_modules/jsdom/lib/jsdom/living/generated/XMLHttpRequest.js:101:22)
      at dispatchXhrRequest (node_modules/axios/lib/adapters/xhr.js:21:19)
      at xhrAdapter (node_modules/axios/lib/adapters/xhr.js:13:10)
      at dispatchRequest (node_modules/axios/lib/core/dispatchRequest.js:52:10)
      at processTicksAndRejections (internal/process/task_queues.js:95:5)".
      at console.log (node_modules/@jest/console/build/CustomConsole.js:185:10)
      at retrieveDevices (src/Devices/Devices.js:338:15)
      at fetchData (src/Devices/Devices.js:320:9)

I tracked down the issue to the issue to be related to an object _ownerDocument being null. This issue is similar to this one #27
I have already spent some time trying to debug it but unfortunately can't find the solution, meanwhile, I'm sending the test data through props to the component to test it.

I'm having this issue too.
What msw and jest versions were you running?

Also just run into this issue

I had the same issue. It was caused by the test finishing before the async call was made. This probably caused Jsdom to be cleaned up so that XMLHttpRequest does not work properly anymore.
I accidentally had a getByText where I needed a findByText. The latter will wait for async actions like the start of the XMLHttpRequest. The former just errors and exits the tests causing the confusing error message.


Unexpected token: name «Dom7», expected: punc «;»

when I build the project, the error is appeard.
I only use  the component with the normal config.

js/3.bundle.js from UglifyJs
When the project build with UglifyJs, Unexpected token

@codeSnipe Same here! project unable to compile with UglifyJs.
If you remove uglifyjs from webpack config. Then compilation works but other issues occur.

any updates on this issues???

I fixed this with switching UglifyJS with TerserPlugin
Below is my options.
optimization: {
    minimizer: [
      new TerserPlugin({
        parallel: true,
        cache: true,
        extractComments: true,
        terserOptions: {
          ecma: 5,
          ie8: false,
          compress: true,
          warnings: true,
        },
      }),
    ],```

I ran into this issue. Is switching to terser the only way? Currently I'm trying to exclude the folder but it seems not to work.

Ok nevermind. Here is the explanation: https://github.com/mishoo/UglifyJS2/issues/659#issuecomment-447820525

right the solution with switching is just a cheep workaround.

Yes, i ended up staying with uglify and running dom7 and swiper through babel first. I kinda like that it breaks because it warns me for errors that otherwise we would only see after building when testing IE.


Request: emacsIDEAs for CLion

Is there any chance of porting this plugin to the newest IDE of jetbrains: CLion?
Would be awesome :)

I'll try porting it to CLion when I got spare time, meanwhile I'd very like to accept pull request from you guys. Thanks

@ascenator
Currently this plugin can run on CLion,  I have done nothing.
Just tested on Clion 1.1


cosmic-settings: failed to get keyboard layouts after trying to add input source

In cosmic-settings, clicking on Add input source in the Input Devices section yields the following error:
  ERROR  failed to get keyboard layouts, why: Os { code: 2, kind: NotFound, message: "No such file or directory" }

I presume that this is not expected, since support for keyboard layout configuration seems to have been implemented, but I may be wrong.
Thanks!

I was told keyboard layout settings should work, so I looked into this issue.
The problem is, that the xkb-data crate used by cosmic-settings, checks a hard coded path for the base.xml that lists available keyboard layouts. The hard coded path is /usr/share/X11/xkb/rules/base.xml  which is not nixos compatible.
A very hacky workaround to fix this would be the following:
sudo ln -s "$(nix-build --no-out-link '<nixpkgs>' -A xkeyboard_config)//share/X11/xkb/rules/base.xml" /usr/share/X11/xkb/rules/base.xml

After running this the input source options work for me, but don't use this as a permanent solution.
I prepared a patch for xkb-data to make the base.xml path configurable via a environment variable. https://github.com/man0lis/xkb-data/commit/bca8edccccb2f57393da47d41ef059c5daca5fe1
If there are no objections, I will open a pull request.

I was wondering whether it was a hard coded path somewhere. Thanks a lot for looking into this and for the patch, @man0lis!
Meanwhile, something like this also works:
# ~/.config/cosmic/com.system76.CosmicComp/v1/
(
    rules: "",
    model: "",
    layout: "fr",
    variant: "oss",
    options: Some(",compose:rctrl,caps:escape"),
)

This issue also affects cosmic-greeter.
The keyboard layout selection on the loginscreen does not work.

anyone figured out how to set a keyboard shortcut to switch input sources?

https://github.com/pop-os/xkb-data/pull/3 got merged and version 0.2.1 of xkb-data with the patch was released. We can now add a wrapper for the affected binaries which correctly sets X11_BASE_RULES_XML and X11_EXTRA_RULES_XML environment variables. (or set them globally, not sure about that one). As soon as cosmic-settings and cosmic-greeter start using the new version of xkb-data, the problems should be gone.

anyone figured out how to set a keyboard shortcut to switch input sources?

@onsails, If you edit ~/.config/cosmic/com.system76.CosmicComp/v1/xkb_config manually, you can use something like this:
(
    rules: "",
    model: "pc104",
    layout: "us,ru",
    variant: "",
    options: Some("terminate:ctrl_alt_bksp,grp:alt_shift_toggle"),
    repeat_delay: 600,
    repeat_rate: 25,
)

The key lines here are layout (put codes for your layouts of choice), and "grp" in options. My example is for Alt+Shift key combination, there is also an option for Win+Space, grp:win_space_toggl, and grp:caps_toggle for using CapsLock key.

The problem is now fixed for cosmic-settings. cosmic-greeter, cosmic-applet-input-sources and cosmic-applet-tiling still use version 0.1 of xkb-data and should start working as soon as upstream bumps then to 0.2.1 or higher.

I opened two small PRs to fix this on COSMIC's side:

https://github.com/pop-os/cosmic-greeter/pull/158
https://github.com/pop-os/cosmic-applets/pull/728

https://github.com/pop-os/cosmic-applets/issues/725 and https://github.com/pop-os/cosmic-applets/pull/728#event-15790336969 have been closed so this issue might get solved with next updates.


use goal tolerance to disable critics not of interest to within XY tolerance

Also, moved cost at pose to the cpp file, it didn't make any difference for me

Looks nice to me


add template

If there is  something wrong, just tell me. I'll fix it.

Thanks @Peng-Qu !
I will let you know once one of the template separation is done. I want to have different files based on the components( such as about me, or skills, etc), so that we can generate the one html file easily.


fix(remix): Automatically infer path to where component is mounted

Description
This PR allows to automatically infer the path for where the component is mounted so .

Checklist

[ ] npm test runs as expected.
[ ] npm run build runs as expected.
[ ] (If applicable) JSDoc comments have been added or updated for any package exports
[ ] (If applicable) Documentation has been updated

Type of change

[ ] 🐛 Bug fix
[X] 🌟 New feature
[ ] 🔨 Breaking change
[ ] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

!snapshot

Hey @octoper - the snapshot version command generated the following package versions:

Package
Version

@clerk/backend
1.0.1-snapshot.vc39d42e

@clerk/chrome-extension
1.0.1-snapshot.vc39d42e

@clerk/clerk-js
5.0.1-snapshot.vc39d42e

@clerk/clerk-expo
1.0.1-snapshot.vc39d42e

@clerk/fastify
1.0.1-snapshot.vc39d42e

gatsby-plugin-clerk
5.0.1-snapshot.vc39d42e

@clerk/localizations
2.0.1-snapshot.vc39d42e

@clerk/nextjs
5.0.1-snapshot.vc39d42e

@clerk/clerk-react
5.0.1-snapshot.vc39d42e

@clerk/remix
4.0.1-snapshot.vc39d42e

@clerk/clerk-sdk-node
5.0.1-snapshot.vc39d42e

@clerk/shared
2.0.1-snapshot.vc39d42e

@clerk/themes
2.0.1-snapshot.vc39d42e

@clerk/types
4.0.1-snapshot.vc39d42e

Tip: Use the snippet copy button below to quickly install the required packages.
@clerk/backend
npm i<EMAIL_ADDRESS>--save-exact

@clerk/chrome-extension
npm i<EMAIL_ADDRESS>--save-exact

@clerk/clerk-js
npm i<EMAIL_ADDRESS>--save-exact

@clerk/clerk-expo
npm i<EMAIL_ADDRESS>--save-exact

@clerk/fastify
npm i<EMAIL_ADDRESS>--save-exact

gatsby-plugin-clerk
npm i<EMAIL_ADDRESS>--save-exact

@clerk/localizations
npm i<EMAIL_ADDRESS>--save-exact

@clerk/nextjs
npm i<EMAIL_ADDRESS>--save-exact

@clerk/clerk-react
npm i<EMAIL_ADDRESS>--save-exact

@clerk/remix
npm i<EMAIL_ADDRESS>--save-exact

@clerk/clerk-sdk-node
npm i<EMAIL_ADDRESS>--save-exact

@clerk/shared
npm i<EMAIL_ADDRESS>--save-exact

@clerk/themes
npm i<EMAIL_ADDRESS>--save-exact

@clerk/types
npm i<EMAIL_ADDRESS>--save-exact

@octoper what does the path of useLocation() return for wildcard routes? We need to get part before the wildcard param and use that as path to the component.

@dimkl I have tested that and it resolves the full pathname as is in the browser so it seems there is no need to handle anything in that case.


[Feature Request] Complete programming language support

Hello! Nice project here! I always build my neovim config with nix and then with flakes and it awesome to see the cimmunity building a “complete” flake with many possibilities for who would like to just set neovim up declaratively.
I would like to start my contributions to this project adding plugins and color schemes but I also would like to know if there’s any plan to implement programming languages support in a declarative way, like an abstraction around plugins opts.
I would work like that:
{
  programs.nixvim = {
    languages.elixir {
      enable = true;
      lsp = {
        enable = true;
        name = “nexts”; # or elixir-ls
        package = next-ls;
      };
      # other configs
    };
    languages.rust.enable = true; # use default options
  };
}

WDYT about this possible feature? I would like to tackle this if there’s chance to evolve in discussion 😊

Ok, if that feature is against the flake philosofy, no problem with that! But I think that is different from being a neovim distribution. My point is: on neovim distributions there are configs pre-defined with a style pre-defined too, for example for buffer line/tree view and other UI plugins.
Adding support to a language is different as this project aims to give total control to the user to set up the config. So keymaps would be defined by the user. THis possible feature aims only to be a wrapper into plugins,as if I need to support elixir language one would do:
{
  programs.nixvim = {
    plugins = {
      elixir-ls.enable = true;
      elixir-tools.enable = true;
      treesitter = {
        enable = true;
        ensureInstalled = [“elixir”];
      };
    };
  };
}

Abstraction doesn’t mean miss config control, but I understand that may be outside from the project scope. Thanks for the response!

That’s a really good point of view! Indeed this feature would demand a kinda complex implementation as it should handle different options for some packages. So for elixir for example, there’s the elixir-ls and the next-ls LSPs clients. So the desired API to declare this would be:
{
  programs.nixvim = {
    languages.elixir = {
      enable = true; # basic setup as tressiter grammar for example
      elixir-tools.enable = true; # specific plugin to handle other configs, as LSP
      linting.null-ls.enable = true; # enables Credo for static analysis, for example
      lsp = {
        enable = true;
        client = {
          name = “next-ls”; # can defaults to one or be a required option
          package = next-ls-derivation;
        };
      };
    };
  };
}

and for javascript (i don’t know much about the ecosystem too):
{
  programs.nixvim = {
    languages.javascript = {
      enable = true; # basic setup as tressiter grammar for example
      linting = {
        prettier.enable = true;
        # other linting options
      };
      lsp = {
        enable = true;
        client = {
          name = “javascript-typescript-langserver”;
          package = pkgs.javascript-lsp; # example name
        };
      };
    };
  };
}

Yeah, I agree it seems an extensible and complex feature but could be a valuable one! So if is decided to not go on, I’ll close this issue 😊

With this discussion I'm pretty convinced it's not the role of nixvim itself, but more of an opinionated wrapper around of nixvim for it to have a nice added value.
From experience it's definitively though enough to follow the plugin options, it would be even harder to follow the ecosystem changes.
Though if a project builds upon nixvim to provide a more "batteries-included" approach we would include it gladly in the README!


CAMEL-11760: camel-itest-karaf - CamelServicenowTest fails

https://issues.apache.org/jira/browse/CAMEL-11760

Thanks the PR has been merged, can you close this?

Thanks!


2.0 Startup.ConfigureContainer

Document Startup.ConfigureContainer

@glennc What is this? Is this a thing?


Fix duplicate symbols of asio::dummy_return

Describe the pull request
The fix already exists (chriskohlhoff/asio#584), but it hasn't been merged yet. Would it be possible to apply a patch to fix this for version 1.75.0? It is very low impact https://gist.github.com/jprochazk/ecb261bb99489a3d0fef03a4ae27c064

What does your PR fix? Fixes #
Build any of the asio coroutine examples with latest MSVC and Boost 1.75.0. It should compile, but linking will fail:
error LNK2005: "void __cdecl boost::asio::dummy_return<void>(void)" (??$dummy_return@X@asio@boost@@YAXXZ) already defined

Which triplets are supported/not supported? Have you updated the CI baseline?
-windows- is affected, no I haven't.

Does your PR follow the maintainer guide?
I haven't read it.

@cedral Thanks for this PR!
Can you sign CLA first?
Thanks.

@cedral Thanks for this PR!
Can you sign CLA first?
Thanks.

Thanks I'll take note of the Port-Version setting for future reference. I am not sure if I am supposed to close this or not so I will leave that to you.

Thanks I'll take note of the Port-Version setting for future reference. I am not sure if I am supposed to close this or not so I will leave that to you.

LGTM.

LGTM.


Move f3 hal to dev-dependencies and fix example

The crate was not usable on any other target, because it always pulled in F3 HAL.
I moved it to dev-dependencies instead and also bumped versions. The example compiles, but I don't have an F3 board to test it.
I tested in on an STM32F429ZIT6 project instead and seems to work fine. Thanks for the crate!

@chemicstry chemicstry Thanks for the PR. I'll validate it on the actual F3 device in next couple of days to confirm it works. The change itself is good. I would ask that you amend the PR and change your line endings to LF (*nix  line endings) as you have CR/LF in a few places.
Thanks.


TPE: Skip computing collisions for static objects

This PR introduces skipping collision checking when going through the AABB tree for static objects.
This change allows large performance gains in worlds with a lot of static objects but very few non static ones.
Apart from some complex test scenarios we are working on (where I observed about 300% performance gain) I went for a pathological case and generated a shapes_population with a total of 1500 shapes (500 per type), all set to static except one and I had about double the performance (12% RTF before, 24% RTF after).
I'm considering adding caching to the CollisionDetector where, if an object didn't move since the previous time step, its collision detection step will be skipped. This would work for most scenarios where a second non static object is moving but would fail if a static object was placed (i.e. "teleported") to collide with the static but not moving object (hope this makes sense!).
This should allow further speedups in worlds with a lot of performers but only a few of them moving at the same time but I'll probably address it in a future PR if the performance gain is significant.

I'm considering adding caching to the CollisionDetector where, if an object didn't move since the previous time step, its collision detection step will be skipped.

yeah that makes sense. For caching, you mean caching the contact points? You could check if either of the entity's pose is dirty or not like here. So something like skipping collision check if both entities are static and neither of their poses are dirty?

nice! Just have small minor comments. I think we can also backport this to ign-physics2 for Citadel.

Ah I always forget the camelCase for variable names :sweat_smile:, addressed all in 1513ba6
For the porting sure, I have at least a small fix and the big one below lef to do. Maybe I'll just get everything into Dome and open a PR cherry-picking all of them at once? Otherwise I can target Citadel moving forward and we can do the usual forward merge.

yeah that makes sense. For caching, you mean caching the contact points? You could check if either of the entity's pose is dirty or not like here. So something like skipping collision check if both entities are static and neither of their poses are dirty?

If both entities are static the collision check would already be skipped by this PR. If this gets merged we would only be iterating over non static objects (from now on performers). I was thinking of caching the contact points for non static objects and return them straight away if the performer object didn't have its pose updated in the latest iteration. If I understand correctly the following behavior would change:

If the performer has a static object spawned or teleported to collide, it will now not be reported until the performer tries to move and updates its pose. This is probably not super ideal but it is probably an obscure enough case?
If a moving performer collides with a non moving performer, the non moving performer will not report a collision, but from what I understand in the normal case this would generate a duplicate collision that is filtered by CheckDuplicateCollisionPair so it might be even a desirable side effect.

But again, I'll be looking at the performance gains and make sure they are relevant enough for this to make sense.

Maybe I'll just get everything into Dome and open a PR cherry-picking all of them at once? Otherwise I can target Citadel moving forward and we can do the usual forward merge.

So far we've been trying to target the earliest ignition version as much as possible. Backporting by cherry picking also works.

If both entities are static the collision check would already be skipped by this PR.

I see.  I just checked gazebo-classic and noticed that we don't report contacts for static-static objects.. If we want, we can do something like changing the check to :
if (e->GetStatic() && !e->PoseDirty())

The downside is that it'll only report contacts for only one iteration, which may be enough for some applications. In any case, since this would be a behavior change from a released version, we should document this in Migration.md.

I was thinking of caching the contact points for non static objects and return them straight away if the performer object didn't have its pose updated in the latest iteration.

sounds good.

If the performer has a static object spawned or teleported to collide, it will now not be reported until the performer tries to move and updates its pose.

yep makes sense.

If a moving performer collides with a non moving performer, the non moving performer will not report a collision,

yep that sounds fine to me. Duplicate contacts are filtered anyway.

OK I changed the base branch to Citadel since it's a backwards compatible change.

OK I changed the base branch to Citadel since it's a backwards compatible change.

I added a small test for the new SetStatic API in 5308b6f. The changes look good to me!

I added a small test for the new SetStatic API in 5308b6f. The changes look good to me!


Problems with web/BadRequestHttpException

What steps will reproduce the problem?
I'm trying to throw BadRequestHttpException and as third parameter ($previous) I put Throwable|null variable and got
Wrong parameters for yii\\web\\BadRequestHttpException([string $message [, long $code [, Throwable $previous = NULL]]])
What is the expected result?
Throw exception without parameters problems
What do you get instead?
Wrong parameters for yii\\web\\BadRequestHttpException([string $message [, long $code [, Throwable $previous = NULL]]])
Additional info

Q
A

Yii version
2.0.34

PHP version
7.3

Operating system
Unix (Inside Docker container)

Also provide example where I do it

Yes, it should be updated to accept Throwable.


Fix measure tool unsupported turn_off for Sonos devices

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 98.399%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2765

Relevant Lines:
2810

💛  - Coveralls


Sharded GCP resources

Given feedback from recent work such as #592, create a first-class concept of a "GCE worker shard" which accepts these variables:

project (string)
region (string)
name (string)
zones (list)
shard_count (number)
worker_count_per_shard (number)
(any gcloud-cleanup and travis-worker config injection)

e.g.:

module "gce_worker_shards_paid" {
  # ...
  project = "${var.project}"
  region = "us-central1"
  name = "${var.env}-${var.index}-paid"
  zones = ["a", "b", "f"]
  shard_count = 6
  worker_count_per_shard = 5
  # ...
}

This should work similarly to the current gce_worker_group + gce_worker modules, but without having knowledge of three distinct instance groups (com, com-free, org). The GCE worker shard module should be responsible for generating service accounts and keys for both workers and a shard-specific gcloud-cleanup deployment. The capacity of the shard should not exceed 300 travis-worker processes and a single gcloud-cleanup process. In the above example, the worker count per shard of 5 multiplied by a pool size (not shown) of 50 multiplied by 6 shards would make a total pool size of 1500.

This generally looks good to me, one open question here would be the NATs. Also, I'd say this is dependent on whether we can get our quotas lifted. If we can't, I'd be inclined to going back to sharding by project and adding at least one more project to our setup.

FTR I'm not planning to do any work toward this, nor do I encourage anyone else to do work toward this, at least until we get some more/better feedback from friends at Google about API quotas.


Index fix

Now that swap_rows(i, j) swaps the rows of the matrix, we no
longer need to index via the permutation.
Discovered this through some https://github.com/BurntSushi/quickcheck exploration (https://github.com/maplant/aljabar/commit/3ffb2a15b1afb992718810b9d1ff6498e7d0e8ae), any interest in adding this?
Seems very suitable for testing various properties (i.e. going to town on https://en.wikipedia.org/wiki/Determinant#Properties_of_the_determinant).

Good catch! I’d say that if Quickcheck was helpful in discovering this, it’s definitely worthwhile to integrate in to our tests.


 Particularly, incorrect order of elements' initialization. This PR fixes broken tests.
There were two options: either to implement every of booking sample controllers + job module controller in out fake app. Or just move some booking sample's files to testdata directory and use them there. I have settle on the second option.
Now tests of revel/revel do not depend on revel/samples, only on revel/modules.
@brendensoares What else do we need for v0.12 release?

@brendensoares #728 changed the behaviour of testrunner.
For demonstration, here is a sample action:
// ToDo redirects user to Index page.
func (c *App) ToDo() revel.Result {
	// Redirecting to App.Index.
	return c.Redirect(routes.App.Index())
}

Before #728 we had:
func (t *AppTest) TestThatToDoWorks() {
	t.Get(routes.ToDo())
	// Status is equal to the status of App.Index (destination page).
	// Body is equal to the body of App.Index (destination page).
}

After merging we have:
func (t *AppTest) TestThatToDoWorks() {
	t.Get(routes.ToDo())
	// Status is equal to 301 Moved Permanently.
	// Body is empty.
}

#900 replaces "301 Moved Permanently" by our good old friend "302 Moved Temporarily". Combination of #899 and #900 will fix the broken tests.

Looking to merge this now and release v0.12. Our docs GH Pages repo has already been merged.

@brendensoares, @pedromorgan Can we make some changes to our v0.12 docs:

Update version on index page.

Remove a dot or move it to the end of "Read how the chat is implemented" sentence.
Remove get revel framework and go get github.com/revel/revel. There is no need to do it. Revel will be automatically go getted as a dependency of revel/cmd/revel.

Yeah, and can we have more elegant h1's? I'm mean a bit smaller and with a smaller bottom margin (margin between Quick Start text above and a horizontal line).

Quick Start link at the main menu leads to mostly empty pages (with some code fragments without code highlighting). Probably we should remove it for now? And when we have something to say we will return it back?

Apart from that I like our new docs.

Oh, my mistake. Those pages are not empty. Only Quick Start / Introduction / ... ones. So, can we remove just empty links and make menu consistent with the rest of revel web-site (I mean left side menu).

One of empty Quick Start / Intro pages. Pay attention to the menu:

Left side menu which is used for other sections of web-site such as Manual, Tutorial, etc. Looks more professional, doesn't it?

Good catches @anonx. @pedromorgan is taking ownership of the docs. I agree that the styling can be improved.
@pedromorgan can you fix the above 3 items noted? After that, we can resync develop branch with master via git pull and move forward with additional changes in develop. If we need to make patch releases to master in between major releases, then that's fine, but let's still use our version control workflow.


Refactor tasks

@vivid-cpreston There were a few merge conflicts which I resolved, but worth a check to make sure I didn't muck it up


Update in-product string for v6.0

Summary
Updates an existing next-steps dialog in-product text string for v6.0 Global Header element details.
Ticket Link
Fixes https://mattermost.atlassian.net/browse/MM-38748
Release Note
NONE

@cwarnermm ideally you would open a new JIRA ticket and link it with this PR ... but since it is just a rather small change we can just do this without a ticket. objections @esethna ?

Works for me @cwarnermm @michelengelen

Pull Request successfully merged
SHA: e2a192ad557e9b93d339694958ec84e685a4f2d2


Implement RedbValue for [u64] (and, more generally, for [RedbValue])

In most cases, Multimap Tables are a good substitute for Vec values. However, it would still be nice if [u64] and, more generally, [RedbValue] were supported. (possibly a subset of #666)

Unfortunately that's not possible due to endianess. You could implement a custom type, but it wouldn't be zero copy

Could you pick a platform independent endianess and load and store consistently? I don't see how this poses endianess problems that aren't also present for u64.

u64 is already stored platform independent. The problem is that &[u64]
needs to be zero copy, and so it can't be converted to the native layout.
Vec might work. That could be implemented in a way that copies when
deserializing the data
Sent from my phone
On Tue, Sep 26, 2023, 8:17 AM Lilith Orion Hafner @.***>
wrote:

Could you pick a platform independent endianess and load and store
consistently? I don't see how this poses endianess problems that aren't
also present for u64.
—
Reply to this email directly, view it on GitHub
https://github.com/cberner/redb/issues/691#issuecomment-1735760055, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGNXQA4K6GWKOTGOFQJMHLX4LWYDANCNFSM6AAAAAA5GMVYSU
.
You are receiving this because you commented.Message ID:
@.***>

Okay, that makes sense.


net/http: No error on invalid port no 556677

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?
1.6

What operating system and processor architecture are you using (go env)?
linux/386

What did you do?
A newbie created a http server to listen on port 55667, but a typo and 556677 instead

http.ListenAndServe("<IP_ADDRESS>:556677" , nil)

What did you expect to see?
An error message saying that 556677 is an invalid port no

What did you see instead?
The application just "died", no error message, no panic. App just failed silently.

OOps my bad... didnt realise message was there..


Website down

Website is not responding: https://redux.js.org

Works for me right now

We don't host either the website or the domain, but I'll try reaching out to the appropriate folks.

everything is fine now over here :) thanx


Enable cluster-wide proxy support

We need to update OADP operator and all of its dependencies to consume the cluster-wide proxy configuration values and respect them.
This is done in MTC already, so most of our dependencies already have support, it's just a matter of properly passing these env vars through the operator.

IIUC
User would configure cluster-wide proxy first via https://docs.openshift.com/container-platform/4.9/networking/enable-cluster-wide-proxy.html#enable-cluster-wide-proxy

Operator Lifecycle Manager (OLM) automatically configures Operators that it manages with the cluster-wide proxy

Enabling proxy support for operator doc
https://docs.openshift.com/container-platform/4.9/operators/operator_sdk/golang/osdk-golang-tutorial.html#osdk-run-proxy_osdk-golang-tutorial

To support proxied clusters, your Operator must inspect the environment for the following standard proxy variables and pass the values to Operands:

HTTP_PROXY
HTTPS_PROXY
NO_PROXY


TSID for "pantograph/biarticular" robot leg design?

Hello and thank you for a great tool! It works perfectly for control of a classic rigid robot.
Right now I'm wondering what it will take to use the TSID to control a robot with an a-la biarticular leg design (something like the one mentioned here) :

I can see three main difficulties:

Closed kinematic chain
Passive joint
Spring element

@andreadelprete can you please guide the right way to implement the missing features for this task (or point me that it's almost impossible in TSID framework)?

It looks like the pinocchio3 version is heading to support the loop constraints. Is there any plans to integrate the pinocchio3 in TSID?
Without pinocchio3 support, as an approximate solution of closed kinematic chain with a passive joint problem, instead of using the passive joint I can remove it and get a sort of solution by implementing a new task, something like "taskTwoFramesPositionEquality", and use it with a high gain to force the solver to keep the end of two links as close as possible, emulating the passive joint in a closed kinematic loop. Will it do the job or lead to solver failure due to over-constrained design or high-gain-induced stability problems?
Spring element is a mystery for me. I can model it as a prismatic/rotational joint, but what is the proper way to take into account the state-dependent spring dynamics generating the actuation in that additional joint?

Dear @egordv , thank you for the interesting questions. I'm glad you enjoy TSID.
I think it should be possible to make TSID work with this kind of robots.

1. It looks like the pinocchio3 version is heading to support the loop constraints. Is there any plans to integrate the pinocchio3 in TSID?

Yes. I think we'll integrate pinocchio3 in TSID when it is officially released.

2. Without pinocchio3 support, as an approximate solution of closed kinematic chain with a passive joint problem, instead of using the passive joint I can remove it and get a sort of solution by implementing a new task, something like "taskTwoFramesPositionEquality", and use it with a high gain to force the solver to keep the end of two links as close as possible, emulating the passive joint in a closed kinematic loop. Will it do the job or lead to solver failure due to over-constrained design or high-gain-induced stability problems?

If you need to model a rigid closed loop, your idea is correct, expect that you should model it with a contact (rather than a task). Currently, contacts only exist for modeling contacts between the robot and the environment. You would need to define a new contact class for contacts between two links of the robot. This should work well in practice, and I can guide you if you need some help.

3. Spring element is a mystery for me. I can model it as a prismatic/rotational joint, but what is the proper way to take into account the state-dependent spring dynamics generating the actuation in that additional joint?

If you have a spring-damper in the closed kinematic chains (as in your fig. B), then the chains are not really closed because the spring-damper allows them to move. In this case the force generated by the spring-damper can be simply computed at each iteration and added to the nonlinear forces (gravity, Coriolis, centrifugal) in the robot dynamics. This will make TSID treat these extra forces in the same way it treats gravity: namely something to compensate for (as long as it has enough motor torques to do so). In other words: it won't be very smart about it, so I'm not sure the resulting behavior is gonna be what you expect, depending on the situation.
Ideally the computation of these spring forces should happen inside Pinocchio, but I don't think Pinocchio currently supports parallel spring-dampers in the kinematic chain, so you should implement this in TSID, maybe using a custom RobotWrapper. If the spring stiffness is too high (>10'000), you might have numerical issues, similarly to what we observed when playing with elastic contact models in [1]. If you're interested in the high-stiffness case, you may need to look into numerical integration techniques that can handle it well, such as [2].
[1] Reactive Balance Control for Legged Robots under Visco-Elastic Contacts, https://andreadelprete.github.io/publication/2020_applsci_flayols/
[2] Exponential Integration for Efficient and Accurate Multibody Simulation with Stiff Viscoelastic Contacts, https://andreadelprete.github.io/publication/2022_mbsd_hammoud/

At the moment there's no way to specify which joints are passive in TSID, expect for the floating base, but it's a feature that can be added. I would first introduce this information in the RobotWrapper. Then you need to use this in the InverseDynamicsFormulation class. Probably the easiest way to handle this is to add an equality constraint for each passive joint, forcing the associated torque to zero. Torques are not decision variables however, so you would have to express them as functions of accelerations and forces, as it's already done for the base dynamics here. Basically, instead of simply selecting the top 6 rows of M, h and J to create the base-dynamics equality constraints, we should select the rows corresponding to the passive joints, which could be located anywhere inside the kinematic chain.
Another, less clean, way to achieve the same result would be to implement the TaskActuationEquality and use it to force the passive joint torques to zero.

This issue has been inactive for a while now, so I close it, but feel free to re-open it if you need to.

Hi @egordv, sorry to add a comment to this closed issue, but I was wondering whether you have a (Python) example of this scenario you mentioned above in a comment:

For example, if I use this new contact type on a classic humanoid to create a virtual spherical linkage between the robot's wrists - it's work as expected, the robot keeps it's wrists "glued" emulating a passive joint between them. To perform this task the humanoid is using all it's arms actuators.

I have a scenario where I want to carry a box with a humanoid and wanted to use the new PR #218 you made. I've pulled the changes into my repo and tried the TwoFramesEquality task (Python bindings) between two palm links of my humanoid (PAL REEM-C) but am met with a seg fault. I haven't debugged further, I will report back if I figure out the issue but I thought I'd reach out and ask anyway.
Thanks! Look forward to the PR getting merged, it looks very nice.


Regular expression dictonary

Updating the dict with few new seeds, has I found this during my continuous fuzzing in VIM.

Sounds like fun, thanks :)


Accept fs module API to define methods

Allow to give a fs-like object to define the methods. This could allow to easily export fs objects like the one provided by webdav-fs and others.

I've taken a better aproach to this, and decided to create a module that interconnect both APIs. fs-fuse allow to use any fs-like object as a FUSE filesystem, and also has a CLI compatible with the mount command so you only need to tell it the path to your module so it can be required and exported.
I think this issue can be clossed now, but probably it could be useful to give a reference to fs-fuse on the readme file, what do you think? :-)

Very cool! Send a PR that links your module

Done :-)