{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":540141969,"defaultBranch":"main","name":"au","ownerLogin":"aurora-opensource","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2022-09-22T19:37:38.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/97064011?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1716468451.0","currentOid":""},"activityList":{"items":[{"before":"044b6131444ea38170255b72327d34387c8a7c63","after":"dd47f6aa908e8ab3bfa711eceb5f0f460c5dfcb8","ref":"refs/heads/gh-pages","pushedAt":"2024-05-23T12:49:34.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Deployed 221d8f4 to main with MkDocs 1.6.0 and mike 2.1.1","shortMessageHtmlLink":"Deployed 221d8f4 to main with MkDocs 1.6.0 and mike 2.1.1"}},{"before":"daaf5cac768a0811277e4f818a9d4114d1f2ea39","after":null,"ref":"refs/heads/chiphogg/requirements-7-8-9-10","pushedAt":"2024-05-23T12:47:31.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"}},{"before":"c08228a5995a81ac6cc3576f09993241068f026f","after":"221d8f41c41419bbdb585fb4cdea1217b8011fd1","ref":"refs/heads/main","pushedAt":"2024-05-23T12:47:27.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"},"commit":{"message":"Refresh python requirements and add instructions (#238)\n\nIt's been a while since we updated `requirements_lock.txt`, and we've\r\naccumulated four Dependabot alerts (7, 8, 9, and 10). I took the\r\nopportunity to write down all the steps we should take when doing this\r\nupdate. Naturally, I also performed all of those steps.\r\n\r\nFor the A/B website comparison, I found 3 differences:\r\n\r\n- Menu alignment has been tweaked on a few pages to reduce word wrapping\r\n- Tab headers are underlined\r\n- Mermaid diagram arrowheads are thicker\r\n\r\nFor testing `mike`, the suggested workflow actually caught some breaking\r\nchanges for our monkey patch code. I therefore made the first step to\r\nsimply directly check the patched APIs.\r\n\r\nThe new version of mkdocs now warns about anchors, and it caught an\r\nincorrect anchor in a recent doc update. I've fixed that as well.","shortMessageHtmlLink":"Refresh python requirements and add instructions (#238)"}},{"before":"48c85a86998f27316dc424e0647b8981fadac053","after":"daaf5cac768a0811277e4f818a9d4114d1f2ea39","ref":"refs/heads/chiphogg/requirements-7-8-9-10","pushedAt":"2024-05-23T12:41:59.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"},"commit":{"message":"Revert \"Meaningless commit\"\n\nThis reverts commit 18712095d9f1e0e0644d047dc6ed7c935d7e60de.","shortMessageHtmlLink":"Revert \"Meaningless commit\""}},{"before":null,"after":"48c85a86998f27316dc424e0647b8981fadac053","ref":"refs/heads/chiphogg/requirements-7-8-9-10","pushedAt":"2024-05-22T21:26:23.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"},"commit":{"message":"Refresh python requirements and add instructions\n\nIt's been a while since we updated `requirements_lock.txt`, and we've\naccumulated four Dependabot alerts (7, 8, 9, and 10). I took the\nopportunity to write down all the steps we should take when doing this\nupdate. Naturally, I also performed all of those steps.\n\nFor the A/B website comparison, I found 3 differences:\n\n- Menu alignment has been tweaked on a few pages to reduce word wrapping\n- Tab headers are underlined\n- Mermaid diagram arrowheads are thicker\n\nFor testing `mike`, the suggested workflow actually caught some breaking\nchanges for our monkey patch code. I therefore made the first step to\nsimply directly check the patched APIs.\n\nThe new version of mkdocs now warns about anchors, and it caught an\nincorrect anchor in a recent doc update. I've fixed that as well.","shortMessageHtmlLink":"Refresh python requirements and add instructions"}},{"before":"0828b1873e2e2f885a5afebdc14ead8376ab488d","after":"044b6131444ea38170255b72327d34387c8a7c63","ref":"refs/heads/gh-pages","pushedAt":"2024-05-09T16:47:07.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Deployed c08228a to main with MkDocs 1.5.3 and mike 1.1.2","shortMessageHtmlLink":"Deployed c08228a to main with MkDocs 1.5.3 and mike 1.1.2"}},{"before":"9d14eb777ef9ac059b64f23db37bb10255db9091","after":null,"ref":"refs/heads/chiphogg/qp-round#221","pushedAt":"2024-05-09T16:44:57.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"}},{"before":"5339f61ee4e56f7cfa7bfabef07d5bf66bfa3eb8","after":"c08228a5995a81ac6cc3576f09993241068f026f","ref":"refs/heads/main","pushedAt":"2024-05-09T16:44:54.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"},"commit":{"message":"Support `QuantityPoint` in rounding functions (#237)\n\nIncludes the `round`, `floor`, and `ceil` families.\r\n\r\nThere's more subtlety here than for `Quantity`, because we can have\r\nadditive offsets. However, since these functions all aim to behave like\r\nthe standard library, and the standard library always uses floating\r\npoint, then it's actually quite simple. The way we handle rounding a\r\nquantity point in different units than it's stored is to first perform\r\nthe conversion, then do the rounding. As with quantities, we use\r\n`RoundingRep` to make sure we're using a sane floating point type to\r\nperform the conversion.\r\n\r\nIncludes a bunch of new test cases, and doc updates.\r\n\r\nFixes #221.","shortMessageHtmlLink":"Support QuantityPoint in rounding functions (#237)"}},{"before":"7c5722503263819de30daaa8c9bf2ab0456ca51b","after":"0828b1873e2e2f885a5afebdc14ead8376ab488d","ref":"refs/heads/gh-pages","pushedAt":"2024-05-09T15:41:40.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Deployed 5339f61 to main with MkDocs 1.5.3 and mike 1.1.2","shortMessageHtmlLink":"Deployed 5339f61 to main with MkDocs 1.5.3 and mike 1.1.2"}},{"before":"f2f1f2f9c53131770fc0329a08c4a48c1e0022e8","after":"9d14eb777ef9ac059b64f23db37bb10255db9091","ref":"refs/heads/chiphogg/qp-round#221","pushedAt":"2024-05-09T15:40:19.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"},"commit":{"message":"Merge branch 'main' into chiphogg/qp-round#221","shortMessageHtmlLink":"Merge branch 'main' into chiphogg/qp-round#221"}},{"before":"cb1f18b9b959c7cabd9530cdfbc1d03bbe585d38","after":null,"ref":"refs/heads/chiphogg/isnan#221","pushedAt":"2024-05-09T15:39:43.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"}},{"before":"b9b89f804d4ae03c4371be3951343aacd118c095","after":"5339f61ee4e56f7cfa7bfabef07d5bf66bfa3eb8","ref":"refs/heads/main","pushedAt":"2024-05-09T15:39:38.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"},"commit":{"message":"Support `QuantityPoint` in `isnan` (#236)\n\nHelps #221.","shortMessageHtmlLink":"Support QuantityPoint in isnan (#236)"}},{"before":"a3e80863b8f505010bfe6c555c74e180f626c826","after":"7c5722503263819de30daaa8c9bf2ab0456ca51b","ref":"refs/heads/gh-pages","pushedAt":"2024-05-09T15:34:59.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Deployed b9b89f8 to main with MkDocs 1.5.3 and mike 1.1.2","shortMessageHtmlLink":"Deployed b9b89f8 to main with MkDocs 1.5.3 and mike 1.1.2"}},{"before":null,"after":"f2f1f2f9c53131770fc0329a08c4a48c1e0022e8","ref":"refs/heads/chiphogg/qp-round#221","pushedAt":"2024-05-09T15:33:39.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"},"commit":{"message":"Support `QuantityPoint` in rounding functions\n\nIncludes the `round`, `floor`, and `ceil` families.\n\nThere's more subtlety here than for `Quantity`, because we can have\nadditive offsets. However, since these functions all aim to behave like\nthe standard library, and the standard library always uses floating\npoint, then it's actually quite simple. The way we handle rounding a\nquantity point in different units than it's stored is to first perform\nthe conversion, then do the rounding. As with quantities, we use\n`RoundingRep` to make sure we're using a sane floating point type to\nperform the conversion.\n\nIncludes a bunch of new test cases, and doc updates.","shortMessageHtmlLink":"Support QuantityPoint in rounding functions"}},{"before":"1ed8c8939e090f8c94710b463c40ebe1b4695626","after":"cb1f18b9b959c7cabd9530cdfbc1d03bbe585d38","ref":"refs/heads/chiphogg/isnan#221","pushedAt":"2024-05-09T15:33:00.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"},"commit":{"message":"Merge branch 'main' into chiphogg/isnan#221","shortMessageHtmlLink":"Merge branch 'main' into chiphogg/isnan#221"}},{"before":"17c2aa9a428c1e7ee0a50f71ef24ca28861233c3","after":null,"ref":"refs/heads/chiphogg/point-unit-slots#221","pushedAt":"2024-05-09T15:32:11.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"}},{"before":"30440ed679c98127785c89398af9717382f230dd","after":"b9b89f804d4ae03c4371be3951343aacd118c095","ref":"refs/heads/main","pushedAt":"2024-05-09T15:32:07.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"},"commit":{"message":"Add associated unit trait for quantity point (#235)\n\nTo complement `AssociatedUnitT`, which is for `Quantity`, we add\r\n`AssociatedUnitForPointsT`, to support `QuantityPoint`. This lets us\r\nsimplify the in/as implementations for `QuantityPoint` the same way we\r\nhad already done for `Quantity`. But the main point is to make it\r\neasier to add unit slots to APIs that work with `QuantityPoint`, which\r\nwill help #221.\r\n\r\nWe also update the docs. The docs for the trait predate the tidy\r\nconcept of a \"unit slot\", so we change the language to be more\r\nconsistent. And on the unit slot page, we add docs for the new options\r\n(symbols and constants) on the quantity side, and say a few more words\r\nabout quantity points.","shortMessageHtmlLink":"Add associated unit trait for quantity point (#235)"}},{"before":null,"after":"1ed8c8939e090f8c94710b463c40ebe1b4695626","ref":"refs/heads/chiphogg/isnan#221","pushedAt":"2024-05-09T01:38:20.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"},"commit":{"message":"Support `QuantityPoint` in `isnan`\n\nHelps #221.","shortMessageHtmlLink":"Support QuantityPoint in isnan"}},{"before":null,"after":"17c2aa9a428c1e7ee0a50f71ef24ca28861233c3","ref":"refs/heads/chiphogg/point-unit-slots#221","pushedAt":"2024-05-08T22:17:58.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"},"commit":{"message":"Add associated unit trait for quantity point\n\nTo complement `AssociatedUnitT`, which is for `Quantity`, we add\n`AssociatedUnitForPointsT`, to support `QuantityPoint`. This lets us\nsimplify the in/as implementations for `QuantityPoint` the same way we\nhad already done for `Quantity`. But the main point is to make it\neasier to add unit slots to APIs that work with `QuantityPoint`, which\nwill help fix #221.\n\nWe also update the docs. The docs for the trait predate the tidy\nconcept of a \"unit slot\", so we change the language to be more\nconsistent. And on the unit slot page, we add docs for the new options\n(symbols and constants) on the quantity side, and say a few more words\nabout quantity points.","shortMessageHtmlLink":"Add associated unit trait for quantity point"}},{"before":"704ce15f195985feb90cb17803481363e767e7d6","after":"a3e80863b8f505010bfe6c555c74e180f626c826","ref":"refs/heads/gh-pages","pushedAt":"2024-05-02T14:17:43.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Deployed 30440ed to main with MkDocs 1.5.3 and mike 1.1.2","shortMessageHtmlLink":"Deployed 30440ed to main with MkDocs 1.5.3 and mike 1.1.2"}},{"before":"5e75904eeb9a8a79efb2d94f202218b5101153b9","after":null,"ref":"refs/heads/chiphogg/calc-rep#233","pushedAt":"2024-05-02T14:15:29.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"}},{"before":"87bf5b3d60728da7f888fd292f1b82cd5b83412d","after":"30440ed679c98127785c89398af9717382f230dd","ref":"refs/heads/main","pushedAt":"2024-05-02T14:15:25.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"},"commit":{"message":"Explicitly specify `QuantityPoint` calc type (#234)\n\nWe want to carry out our intermediate computations in the common type of\r\nthe old and new rep, generally. However, we already know from #222 that\r\nif the new rep is a signed integer, and the old rep is unsigned, we need\r\nto be careful to use a signed type for intermediate computations.\r\n\r\nTo preserve this behaviour but restore correct behavoiur for other cases\r\n(namely, #233), we add a new type trait for this intermediate type. It\r\nbasically boils down to the common type, but with an explicit carve-out\r\nto keep #222 fixed. We explicitly cast both participants to this new\r\ntype-for-intermediate-computations, and then cast to the destination rep\r\nat the end.\r\n\r\nCompile time tests showed no discernible impact at all. This change has\r\nalso passed all Aurora-internal builds.\r\n\r\nFixes #233.","shortMessageHtmlLink":"Explicitly specify QuantityPoint calc type (#234)"}},{"before":null,"after":"5e75904eeb9a8a79efb2d94f202218b5101153b9","ref":"refs/heads/chiphogg/calc-rep#233","pushedAt":"2024-05-02T13:31:56.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"},"commit":{"message":"Explicitly specify `QuantityPoint` calc type\n\nWe want to carry out our intermediate computations in the common type of\nthe old and new rep, generally. However, we already know from #222 that\nif the new rep is a signed integer, and the old rep is unsigned, we need\nto be careful to use a signed type for intermediate computations.\n\nTo preserve this behaviour but restore correct behavoiur for other cases\n(namely, #233), we add a new type trait for this intermediate type. It\nbasically boils down to the common type, but with an explicit carve-out\nto keep #222 fixed. We explicitly cast both participants to this new\ntype-for-intermediate-computations, and then cast to the destination rep\nat the end.\n\nFixes #233.","shortMessageHtmlLink":"Explicitly specify QuantityPoint calc type"}},{"before":"36620056ba7054573603e26966f10a8f9162b7e5","after":"704ce15f195985feb90cb17803481363e767e7d6","ref":"refs/heads/gh-pages","pushedAt":"2024-04-25T14:47:14.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Deployed 87bf5b3 to main with MkDocs 1.5.3 and mike 1.1.2","shortMessageHtmlLink":"Deployed 87bf5b3 to main with MkDocs 1.5.3 and mike 1.1.2"}},{"before":"6d148e8007854193de7e049b93af231e010a0f89","after":null,"ref":"refs/heads/chiphogg/enable-if-not-quantity#228","pushedAt":"2024-04-25T14:45:01.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"}},{"before":"ffea2743c96b6d1cf4378fe25cf779314e6c8439","after":"87bf5b3d60728da7f888fd292f1b82cd5b83412d","ref":"refs/heads/main","pushedAt":"2024-04-25T14:44:58.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"},"commit":{"message":"Permit arithmetic operations with more types (#229)\n\nThe goal of these `std::is_arithmetic` SFINAE uses was to avoid\r\nambiguous overloads when we multiply a `Quantity` with another\r\n`Quantity`. It was only ever a shortcut. It seems to work well in most\r\ncases, but recently, a user pointed out that it doesn't help\r\n`std::complex`. (To be clear, we could _form_ a `Quantity` with\r\n`std::complex` rep, but we couldn't multiply or divide a `Quantity` with\r\na `std::complex` scalar.)\r\n\r\nThis PR takes a different approach.\r\n\r\nFirst, we define what constitutes a valid \"rep\". We're very permissive\r\nhere, using a \"deny-list\" approach that filters out empty types, known\r\nAu types, and other libraries' units types (which we detect via our\r\n`CorrespondingQuantity` trait). Incidentally, this should give us a\r\nnice head start on #52.\r\n\r\nNext, we permit an operation (multiplication or division) depending on\r\nhow the \"candidate scalar\" type would interact with the Quantity's rep:\r\nsimply put, the result must itself both exist, and be a valid rep.\r\n\r\nThe net result should be that we automatically consider a much wider\r\nvariety of types --- including complex number types from outside the\r\nstandard library --- to be valid scalars. Crucially, this should also\r\nbe able to avoid breaking existing code: we are introducing potentially\r\na _lot_ of new overloads for these operators, and we can't allow any to\r\ncreate an ambiguity with existing overloads.\r\n\r\nHelps #228, but we need more Magnitude support.","shortMessageHtmlLink":"Permit arithmetic operations with more types (#229)"}},{"before":null,"after":"6d148e8007854193de7e049b93af231e010a0f89","ref":"refs/heads/chiphogg/enable-if-not-quantity#228","pushedAt":"2024-03-30T21:17:06.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"},"commit":{"message":"Permit arithmetic operations with more types\n\nThe goal of these `std::is_arithmetic` SFINAE uses was to avoid\nambiguous overloads when we multiply a `Quantity` with another\n`Quantity`. It was only ever a shortcut. It seems to work well in most\ncases, but recently, a user pointed out that it doesn't help\n`std::complex`. (To be clear, we could _form_ a `Quantity` with\n`std::complex` rep, but we couldn't multiply or divide a `Quantity` with\na `std::complex` scalar.)\n\nThis PR takes a different approach.\n\nFirst, we define what constitutes a valid \"rep\". We're very permissive\nhere, using a \"deny-list\" approach that filters out empty types, known\nAu types, and other libraries' units types (which we detect via our\n`CorrespondingQuantity` trait). Incidentally, this should give us a\nnice head start on #52.\n\nNext, we permit an operation (multiplication or division) depending on\nhow the \"candidate scalar\" type would interact with the Quantity's rep:\nsimply put, the result must itself both exist, and be a valid rep.\n\nThe net result should be that we automatically consider a much wider\nvariety of types --- including complex number types from outside the\nstandard library --- to be valid scalars. Crucially, this should also\nbe able to avoid breaking existing code: we are introducing potentially\na _lot_ of new overloads for these operators, and we can't allow any to\ncreate an ambiguity with existing overloads.","shortMessageHtmlLink":"Permit arithmetic operations with more types"}},{"before":"ea2f3f1fa39c402755dc07ee93f9ecbff26157e7","after":"36620056ba7054573603e26966f10a8f9162b7e5","ref":"refs/heads/gh-pages","pushedAt":"2024-03-11T16:52:40.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"github-actions[bot]","name":null,"path":"/apps/github-actions","primaryAvatarUrl":"https://avatars.githubusercontent.com/in/15368?s=80&v=4"},"commit":{"message":"Deployed ffea274 to main with MkDocs 1.5.3 and mike 1.1.2","shortMessageHtmlLink":"Deployed ffea274 to main with MkDocs 1.5.3 and mike 1.1.2"}},{"before":"0f0f32320b5569c472e75b5827adf31813ebfe12","after":null,"ref":"refs/heads/chiphogg/not-forbidden-but-not-permitted#226","pushedAt":"2024-03-11T16:50:26.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"}},{"before":"492e5bdd3878d0d6e65c9d4eba8dc305db749272","after":"ffea2743c96b6d1cf4378fe25cf779314e6c8439","ref":"refs/heads/main","pushedAt":"2024-03-11T16:50:22.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"chiphogg","name":"Chip Hogg","path":"/chiphogg","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1819744?s=80&v=4"},"commit":{"message":"Delete `ForbidsComposingWith` mixin (#227)\n\nIt causes problems with Apple Clang version 9, apparently. I think this\r\ncompiler technically falls outside of our support window. However, an\r\nactual user is having issues with it, and I think `ForbidsComposingWith`\r\nis adding only very marginal value anyway. I tried deleting it and the\r\nerror messages became a couple of lines shorter, although perhaps less\r\ndirect (no more reference to \"explicitly deleted\").\r\n\r\nAmusingly, I'm keeping the unit test for it around, because it's one of\r\nthose unfortunate \"uncomment to test\" deals, and the tests _will_ still\r\npass. (We'll get compiler errors for doing unsupported operations.)\r\n\r\nFixes #226.","shortMessageHtmlLink":"Delete ForbidsComposingWith mixin (#227)"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEUgJRggA","startCursor":null,"endCursor":null}},"title":"Activity ยท aurora-opensource/au"}