{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":315097362,"defaultBranch":"master","name":"rtorrent","ownerLogin":"jesec","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2020-11-22T17:46:48.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/11585141?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1688425781.0","currentOid":""},"activityList":{"items":[{"before":"e9303f684b383c24e4b5226eb54c42439afbf27f","after":"199e8f85244c8eb1c30163d51755570ad86139bb","ref":"refs/heads/master","pushedAt":"2023-07-21T07:23:09.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"jesec","name":"Jesse Chan","path":"/jesec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11585141?s=80&v=4"},"commit":{"message":"utils: lockfile: avoid stack overflow for lockfile buffer\n\nThere appears to have been some change on openSUSE (likely some new\nhardening flags for builds, or some glibc hardening) such that incorrect\nbuffer handling results in a segfault even if the buffer is never\noverflowed.\n\nSigned-off-by: Aleksa Sarai ","shortMessageHtmlLink":"utils: lockfile: avoid stack overflow for lockfile buffer"}},{"before":"7a3fc2190f015f8a020c6240ae67a97ed8e5673d","after":"e9303f684b383c24e4b5226eb54c42439afbf27f","ref":"refs/heads/master","pushedAt":"2023-07-04T06:56:29.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"jesec","name":"Jesse Chan","path":"/jesec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11585141?s=80&v=4"},"commit":{"message":"Remove deprecated std::unary/binary_function (#46)","shortMessageHtmlLink":"Remove deprecated std::unary/binary_function (#46)"}},{"before":"f9a875b633eb083ec82f89ebeae8678ca424e8b2","after":"7a3fc2190f015f8a020c6240ae67a97ed8e5673d","ref":"refs/heads/master","pushedAt":"2023-07-04T06:55:42.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"jesec","name":"Jesse Chan","path":"/jesec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11585141?s=80&v=4"},"commit":{"message":"option_parser: fix unqualified calls to std::move (#59)\n\nhttps://reviews.llvm.org/rG70b1f6de539867353940d3dcb8b25786d5082d63","shortMessageHtmlLink":"option_parser: fix unqualified calls to std::move (#59)"}},{"before":"88fd968f3d78db55d50def1b973081359c547cb7","after":"f9a875b633eb083ec82f89ebeae8678ca424e8b2","ref":"refs/heads/master","pushedAt":"2023-07-03T23:24:36.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jesec","name":"Jesse Chan","path":"/jesec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11585141?s=80&v=4"},"commit":{"message":"download_store: ensure that session files land on the disk\n\nCurrently, save() stores session to the disk by:\n\n- serialize to bencode and write to files with .new ext\n- validate the new files\n- rename new files, removing .new ext\n\nTechnically, this is done to make sure that session files on the\ndisk are always valid/uncorrupted. However, if catastrophic events\nhappen during save(), such as system crash / power outage, the actual\ncontent of session files may not have been synced to the disk.\n\nTo make things much worse, rename() is atomic. That means we discarded\nthe previous session files without actually landing the new session files\non the disk, and we got a bunch of empty session files to deal with.\n\nThis commit adds a fsync step to ensure that session files land on the\ndisk.","shortMessageHtmlLink":"download_store: ensure that session files land on the disk"}},{"before":null,"after":"5ae89728b40b99a93dd33f880b639777bbd663a5","ref":"refs/heads/refactor/xml-as-json","pushedAt":"2023-07-03T23:09:41.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jesec","name":"Jesse Chan","path":"/jesec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11585141?s=80&v=4"},"commit":{"message":"rpc: handle XML-RPC with JSON-RPC logics\n\nThis allows us to centralize on a single set of RPC logics, sharing\nthe exception handling, error codes/messages and behaviors.\n\nThis improves consistency, reduces maintenance burden, makes future\nextension to RPC parts easier. In addition, we can ditch the dependency\non decade-old xmlrpc-c library.\n\nAs for the performance, we performed a test with 10,000 torrents in\na typical d.multicall2 call, which showed JSON-RPC is 3x faster,\ncompared to XML-RPC (xmlrpc-c). Meanwhile, rapidxml is 3-9x faster,\ncompared to expat/libxml. That means even with the conversion, we\nshouldn't see much of a performance ding. We may even have a win.","shortMessageHtmlLink":"rpc: handle XML-RPC with JSON-RPC logics"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAADWi-0zwA","startCursor":null,"endCursor":null}},"title":"Activity ยท jesec/rtorrent"}