{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":20664755,"defaultBranch":"master","name":"pymoca","ownerLogin":"pymoca","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2014-06-09T22:42:19.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/33698687?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1712143543.0","currentOid":""},"activityList":{"items":[{"before":"f559a73f56361a12e0746cf93ca26dc4f6cc9297","after":"cbf2fc3cc49a0ae5fcbdd6c8aae7f1adb51f1375","ref":"refs/heads/fixesfor091","pushedAt":"2024-04-03T11:27:05.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"setup.py: Fix installation on Python >= 3.10\n\nA string comparison for versions would result in \"3.10.0\" being smaller\nthan \"3.5.0\" (because 3.1 is smaller than 3.5). We should just do a\ntuple comparison.","shortMessageHtmlLink":"setup.py: Fix installation on Python >= 3.10"}},{"before":null,"after":"f559a73f56361a12e0746cf93ca26dc4f6cc9297","ref":"refs/heads/fixesfor091","pushedAt":"2024-04-03T11:25:43.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"ci: pin windows version\n\nPin the windwos version to 2019.\nFor windows-latest (= windows-2022 at the moment),\nthe test GenCasadiTest::test_codegen fails with error\ndistutils.errors.DistutilsPlatformError: Unable to find vcvarsall.bat","shortMessageHtmlLink":"ci: pin windows version"}},{"before":"2d02861e545246a7afa7dfe7657ea830ed170d91","after":"9d597d76aa2b82bd3d563d4938a098af8baafd49","ref":"refs/heads/master","pushedAt":"2024-01-30T13:47:09.000Z","pushType":"pr_merge","commitsCount":3,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"parser/cache: Use more accurate clock in _microseconds_since_epoch\n\nNote that this improvement was not enough to solve the caching issues as\naddressed in 6fdfe8c3. It is still a better clock than\n`datetime.utcnow()` [0], especially on Windows. It also saves a level of\nindirection of going through `datetime` objects.\n\n[0] `utcnow()` uses `time.time()` behind the scenes, and then constructs\na datetime object from it.","shortMessageHtmlLink":"parser/cache: Use more accurate clock in _microseconds_since_epoch"}},{"before":"a48ca1b70e1974f0f6154e491ea43bcf719d1c90","after":"1433fa2c24705e34faed8249d452c844e6fa4512","ref":"refs/heads/cache-timing-cleanup-improvements","pushedAt":"2024-01-30T13:36:46.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"parser/cache: Use more accurate clock in _microseconds_since_epoch\n\nNote that this improvement was not enough to solve the caching issues as\naddressed in 6fdfe8c3. It is still a better clock than\n`datetime.utcnow()` [0], especially on Windows. It also saves a level of\nindirection of going through `datetime` objects.\n\n[0] `utcnow()` uses `time.time()` behind the scenes, and then constructs\na datetime object from it.","shortMessageHtmlLink":"parser/cache: Use more accurate clock in _microseconds_since_epoch"}},{"before":"23bb61185adc53216727237c93ad5717a715dba9","after":"a48ca1b70e1974f0f6154e491ea43bcf719d1c90","ref":"refs/heads/cache-timing-cleanup-improvements","pushedAt":"2024-01-30T13:34:46.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"parser/cache: Use more accurate clock in _microseconds_since_epoch\n\nNote that this improvement was not enough to solve the caching issues as\naddressed in 6fdfe8c3. It is still a better clock than\n`datetime.utcnow()` [0], especially on Windows. It also saves a level of\nindirection of going through `datetime` objects.\n\n[0] `utcnow()` uses `time.time()` behind the scenes, and then constructs\na datetime object from it.","shortMessageHtmlLink":"parser/cache: Use more accurate clock in _microseconds_since_epoch"}},{"before":"4b5f9f78b2a568f2bf2e592d5057ec2a8f08326d","after":"2d02861e545246a7afa7dfe7657ea830ed170d91","ref":"refs/heads/master","pushedAt":"2024-01-30T13:33:43.000Z","pushType":"pr_merge","commitsCount":2,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"CI/CD: Fix failing cache test due to coarse clock on Windows\n\nWe compare the `last_prune` / `last_hit` times in the tests, checking\nthat a second successive call updates the value. The time between calls\nmight take a couple hundred us to a few ms, especially when there is\nvery little work we do inbetween like in `test_parse_cache_hit`.\n\nThis particular `test_parse_cache_hit` test was also the test that fails\non Windows on CI/CD, as it turns out that the clock on that platform is\nquite coarse. Two successive calls to `parser.parse()` meaning two\nsuccessive calls to `_microseconds_since_epoch()`, would return the\nexact same time twice. This would cause the assertion in the test to\nfail.\n\nThere are more accurate clocks available ( see `time.time_ns()`,\nhttps://peps.python.org/pep-0564/ ), but even those are not enough on\nWindows to make the tests succeed at all times.\n\nAs a workaround we therefore make sure that, when updating the\n`last_hit` / `last_prune` time, we at the very least increment it by 1\n(microsecond).","shortMessageHtmlLink":"CI/CD: Fix failing cache test due to coarse clock on Windows"}},{"before":"6fdfe8c338e6a5b0750ed54f93b66f7a4c3f3c20","after":"e2b4d449ee711791f733623d9d75bff091944412","ref":"refs/heads/test-cache-add-delay","pushedAt":"2024-01-30T13:26:50.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"CI/CD: Fix failing cache test due to coarse clock on Windows\n\nWe compare the `last_prune` / `last_hit` times in the tests, checking\nthat a second successive call updates the value. The time between calls\nmight take a couple hundred us to a few ms, especially when there is\nvery little work we do inbetween like in `test_parse_cache_hit`.\n\nThis particular `test_parse_cache_hit` test was also the test that fails\non Windows on CI/CD, as it turns out that the clock on that platform is\nquite coarse. Two successive calls to `parser.parse()` meaning two\nsuccessive calls to `_microseconds_since_epoch()`, would return the\nexact same time twice. This would cause the assertion in the test to\nfail.\n\nThere are more accurate clocks available ( see `time.time_ns()`,\nhttps://peps.python.org/pep-0564/ ), but even those are not enough on\nWindows to make the tests succeed at all times.\n\nAs a workaround we therefore make sure that, when updating the\n`last_hit` / `last_prune` time, we at the very least increment it by 1\n(microsecond).","shortMessageHtmlLink":"CI/CD: Fix failing cache test due to coarse clock on Windows"}},{"before":"23bb61185adc53216727237c93ad5717a715dba9","after":"6fdfe8c338e6a5b0750ed54f93b66f7a4c3f3c20","ref":"refs/heads/test-cache-add-delay","pushedAt":"2024-01-29T21:15:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"CI/CD: Fix failing cache test due to coarse clock on Windows\n\nWe compare the `last_prune` / `last_hit` times in the tests, checking\nthat a second successive call updates the value. The time between calls\nmight take a couple hundred us to a few ms, especially when there is\nvery little work we do inbetween like in `test_parse_cache_hit`.\n\nThis particular `test_parse_cache_hit` test was also the test that fails\non Windows on CI/CD, as it turns out that the clock on that platform is\nquite coarse. Two successive calls to `parser.parse()` meaning two\nsuccessive calls to `_microseconds_since_epoch()`, would return the\nexact same time twice. This would cause the assertion in the test to\nfail.\n\nThere are more accurate clocks available ( see `time.time_ns()`,\nhttps://peps.python.org/pep-0564/ ), but even those are not enough on\nWindows to make the tests succeed at all times.\n\nAs a workaround we therefore make sure that, when updating the\n`last_hit` / `last_prune` time, we at the very least increment it by 1\n(microsecond).","shortMessageHtmlLink":"CI/CD: Fix failing cache test due to coarse clock on Windows"}},{"before":null,"after":"23bb61185adc53216727237c93ad5717a715dba9","ref":"refs/heads/cache-timing-cleanup-improvements","pushedAt":"2024-01-29T21:12:26.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"parser/cache: Use more accurate clock in _microseconds_since_epoch\n\nNote that this improvement was not enough to solve the caching issues as\naddressed in 6fdfe8c3. It is still a better clock than\n`datetime.utcnow()` [0], especially on Windows. It also saves a level of\nindirection of going through `datetime` objects.\n\n[0] `utcnow()` uses `time.time()` behind the scenes, and then constructs\na datetime object from it.","shortMessageHtmlLink":"parser/cache: Use more accurate clock in _microseconds_since_epoch"}},{"before":"6fdfe8c338e6a5b0750ed54f93b66f7a4c3f3c20","after":"23bb61185adc53216727237c93ad5717a715dba9","ref":"refs/heads/test-cache-add-delay","pushedAt":"2024-01-29T21:02:37.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"parser/cache: Use more accurate clock in _microseconds_since_epoch\n\nNote that this improvement was not enough to solve the caching issues as\naddressed in 6fdfe8c3. It is still a better clock than\n`datetime.utcnow()` [0], especially on Windows. It also saves a level of\nindirection of going through `datetime` objects.\n\n[0] `utcnow()` uses `time.time()` behind the scenes, and then constructs\na datetime object from it.","shortMessageHtmlLink":"parser/cache: Use more accurate clock in _microseconds_since_epoch"}},{"before":"040f7a5e528e112e2f105b1b95255a837bd230f5","after":"6fdfe8c338e6a5b0750ed54f93b66f7a4c3f3c20","ref":"refs/heads/test-cache-add-delay","pushedAt":"2024-01-29T10:12:16.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"CI/CD: Fix failing cache test due to coarse clock on Windows\n\nWe compare the `last_prune` / `last_hit` times in the tests, checking\nthat a second successive call updates the value. The time between calls\nmight take a couple hundred us to a few ms, especially when there is\nvery little work we do inbetween like in `test_parse_cache_hit`.\n\nThis particular `test_parse_cache_hit` test was also the test that fails\non Windows on CI/CD, as it turns out that the clock on that platform is\nquite coarse. Two successive calls to `parser.parse()` meaning two\nsuccessive calls to `_microseconds_since_epoch()`, would return the\nexact same time twice. This would cause the assertion in the test to\nfail.\n\nThere are more accurate clocks available ( see `time.time_ns()`,\nhttps://peps.python.org/pep-0564/ ), but even those are not enough on\nWindows to make the tests succeed at all times.\n\nAs a workaround we therefore make sure that, when updating the\n`last_hit` / `last_prune` time, we at the very least increment it by 1\n(microsecond).","shortMessageHtmlLink":"CI/CD: Fix failing cache test due to coarse clock on Windows"}},{"before":null,"after":"6fdfe8c338e6a5b0750ed54f93b66f7a4c3f3c20","ref":"refs/heads/really-fix-cicd","pushedAt":"2024-01-29T10:11:14.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"CI/CD: Fix failing cache test due to coarse clock on Windows\n\nWe compare the `last_prune` / `last_hit` times in the tests, checking\nthat a second successive call updates the value. The time between calls\nmight take a couple hundred us to a few ms, especially when there is\nvery little work we do inbetween like in `test_parse_cache_hit`.\n\nThis particular `test_parse_cache_hit` test was also the test that fails\non Windows on CI/CD, as it turns out that the clock on that platform is\nquite coarse. Two successive calls to `parser.parse()` meaning two\nsuccessive calls to `_microseconds_since_epoch()`, would return the\nexact same time twice. This would cause the assertion in the test to\nfail.\n\nThere are more accurate clocks available ( see `time.time_ns()`,\nhttps://peps.python.org/pep-0564/ ), but even those are not enough on\nWindows to make the tests succeed at all times.\n\nAs a workaround we therefore make sure that, when updating the\n`last_hit` / `last_prune` time, we at the very least increment it by 1\n(microsecond).","shortMessageHtmlLink":"CI/CD: Fix failing cache test due to coarse clock on Windows"}},{"before":"d3653d9f73e037a61f35974832ee91be5fa03ddd","after":"4b5f9f78b2a568f2bf2e592d5057ec2a8f08326d","ref":"refs/heads/master","pushedAt":"2024-01-27T16:46:28.000Z","pushType":"pr_merge","commitsCount":2,"pusher":{"login":"kentrutan","name":"Kent Rutan","path":"/kentrutan","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10179274?s=80&v=4"},"commit":{"message":"pyproject: Update development status classifier to 'alpha'\n\nWe are certainly no longer in the planning phase, but also not quite\nthat stable and compliant with the spec yet that we can call it 'beta'.","shortMessageHtmlLink":"pyproject: Update development status classifier to 'alpha'"}},{"before":"6245d616d53ee0dfad94888c7f212cb367f57b0b","after":"e9107cdf331d15ef2ff8e3019aa12be81c33315b","ref":"refs/heads/update-project-metadata","pushedAt":"2024-01-27T16:43:09.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"kentrutan","name":"Kent Rutan","path":"/kentrutan","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10179274?s=80&v=4"},"commit":{"message":"pyproject: Update development status classifier to 'alpha'\n\nWe are certainly no longer in the planning phase, but also not quite\nthat stable and compliant with the spec yet that we can call it 'beta'.","shortMessageHtmlLink":"pyproject: Update development status classifier to 'alpha'"}},{"before":"e34e2ad1cbf710284bbfcd027bbf825f87392679","after":"d3653d9f73e037a61f35974832ee91be5fa03ddd","ref":"refs/heads/master","pushedAt":"2024-01-27T15:54:27.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"kentrutan","name":"Kent Rutan","path":"/kentrutan","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10179274?s=80&v=4"},"commit":{"message":"CI/CD: Update max Python to 3.12\n\nWe need setuptools as a dependency for distutils.ccompiler to work in\nPython 3.12 and higher.\n\nAlso since there are so many versions of Python active (3.8 to 3.12),\nit seems excessive to test every version. This changes\nthe matrix to just three versions: 3.8, 3.10, 3.12. For future updates,\nI envision picking min, max, and median of the supported Python\nversions.","shortMessageHtmlLink":"CI/CD: Update max Python to 3.12"}},{"before":"b4319408bf17626551e7fb3a2ed1a896a602ceb8","after":"a44c0290a8c714fc181883dc81afd87cb5e09fdd","ref":"refs/heads/cicd-test-python-312","pushedAt":"2024-01-27T13:50:58.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"force rerun","shortMessageHtmlLink":"force rerun"}},{"before":"10b6e7a91504c82cfd3e3795a3cd28245679adb0","after":"b4319408bf17626551e7fb3a2ed1a896a602ceb8","ref":"refs/heads/cicd-test-python-312","pushedAt":"2024-01-27T13:37:36.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"CI/CD: Update max Python to 3.12\n\nAlso since there are so many versions of Python active (3.8 to 3.12),\nit seems excessive to test every version. This changes\nthe matrix to just three versions: 3.8, 3.10, 3.12. For future updates,\nI envision picking min, max, and median of the supported Python\nversions.","shortMessageHtmlLink":"CI/CD: Update max Python to 3.12"}},{"before":"ece64f0bd839bbf49a41989ca5bda05153f99786","after":"e34e2ad1cbf710284bbfcd027bbf825f87392679","ref":"refs/heads/master","pushedAt":"2024-01-27T13:22:59.000Z","pushType":"pr_merge","commitsCount":3,"pusher":{"login":"kentrutan","name":"Kent Rutan","path":"/kentrutan","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10179274?s=80&v=4"},"commit":{"message":"Consolidate ANTLR tools into antlr directory\n\nRenames the \"java\" subdirectory to \"antlr\" and moves the antlr_build.py\nscript into it.","shortMessageHtmlLink":"Consolidate ANTLR tools into antlr directory"}},{"before":"1ffbfb304353dddbce6b4687420a96c575ce2b04","after":"3d54c93a6effd4f599f51fe636fc52ffbd632ccb","ref":"refs/heads/setup-py-to-pyproject","pushedAt":"2024-01-27T01:39:31.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"kentrutan","name":"Kent Rutan","path":"/kentrutan","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10179274?s=80&v=4"},"commit":{"message":"Consolidate ANTLR tools into antlr directory\n\nRenames the \"java\" subdirectory to \"antlr\" and moves the antlr_build.py\nscript into it.","shortMessageHtmlLink":"Consolidate ANTLR tools into antlr directory"}},{"before":"41c8a7bdb8c0f435c4ab7176d6c5848366673d68","after":"040f7a5e528e112e2f105b1b95255a837bd230f5","ref":"refs/heads/test-cache-add-delay","pushedAt":"2024-01-26T23:31:32.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"fixy test","shortMessageHtmlLink":"fixy test"}},{"before":null,"after":"41c8a7bdb8c0f435c4ab7176d6c5848366673d68","ref":"refs/heads/test-cache-add-delay","pushedAt":"2024-01-26T23:28:10.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"sleep only in github actions","shortMessageHtmlLink":"sleep only in github actions"}},{"before":"604a233e72fe8bde3ae2562e6b597fa4c4d6bdf0","after":"1ffbfb304353dddbce6b4687420a96c575ce2b04","ref":"refs/heads/setup-py-to-pyproject","pushedAt":"2024-01-26T14:39:56.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"setup: Fully switch from setup.py to pyproject.toml\n\nWe were partially using both, which is asking for trouble when it comes\nto various build tools.\n\nWe split off the antlr compile command to its separate file (not part of\nthe pymoca library). It's just a `python antlr_build.py` call now,\ninstead of having `python setup.py antlr`.","shortMessageHtmlLink":"setup: Fully switch from setup.py to pyproject.toml"}},{"before":"66b1a0248660cb03c3ac66ee5c02bfe27179be7e","after":"6245d616d53ee0dfad94888c7f212cb367f57b0b","ref":"refs/heads/update-project-metadata","pushedAt":"2024-01-26T14:38:33.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"pyproject: Update development status classifier to 'alpha'\n\nWe are certainly no longer in the planning phase, but also not quite\nthat stable and compliant with the spec yet that we can call it 'beta'.","shortMessageHtmlLink":"pyproject: Update development status classifier to 'alpha'"}},{"before":"06cde26ca8ef934f1a8f73cd4039082bcee2518b","after":"ece64f0bd839bbf49a41989ca5bda05153f99786","ref":"refs/heads/master","pushedAt":"2024-01-26T14:17:31.000Z","pushType":"pr_merge","commitsCount":2,"pusher":{"login":"kentrutan","name":"Kent Rutan","path":"/kentrutan","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10179274?s=80&v=4"},"commit":{"message":"CI/CD: Fix failing cache test likely due to SQLite sync issues\n\nOn GitHub Actions, and only on the Windows platform, the check\n`self.assertGreater(second_hit_time, first_hit_time)` would fail, as\nboth times would be equal. There is probably some funky stuff going on\nwith SQLite not being able to properly notify the reader (the test) that\na writer (the `parse` call) made changes. We therefore force a close and\nre-open of the database.\n\nNote that:\n- The second parse call does correctly read from the cache. We check the\n  log messages that this is the case (see parent commit)\n- Such erratic reader/writer sync behavior is probably because of the\n  use of mounted storage.","shortMessageHtmlLink":"CI/CD: Fix failing cache test likely due to SQLite sync issues"}},{"before":null,"after":"66b1a0248660cb03c3ac66ee5c02bfe27179be7e","ref":"refs/heads/update-project-metadata","pushedAt":"2024-01-25T14:45:26.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"pyproject: Update development status classifier to 'beta'\n\nWe are certainly no longer in the planning phase.","shortMessageHtmlLink":"pyproject: Update development status classifier to 'beta'"}},{"before":"6dd10cf6c0e162bb7899460fce3ff011f14d8a9e","after":"604a233e72fe8bde3ae2562e6b597fa4c4d6bdf0","ref":"refs/heads/setup-py-to-pyproject","pushedAt":"2024-01-24T15:38:46.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"setup: Fully switch from setup.py to pyproject.toml\n\nWe were partially using both, which is asking for trouble when it comes\nto various build tools.\n\nWe split off the antlr compile command to its separate file (not part of\nthe pymoca library). It's just a `python antlr_build.py` call now,\ninstead of having `python setup.py antlr`.","shortMessageHtmlLink":"setup: Fully switch from setup.py to pyproject.toml"}},{"before":"12ab6851661b91432e9dbeaaa33a279a74cf63af","after":"b92f4527b31f0b7cb184f8ac8658636696ef618e","ref":"refs/heads/setuptools-scm-instead-of-versioneer","pushedAt":"2024-01-24T15:36:53.000Z","pushType":"push","commitsCount":3,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"ugh, ugly","shortMessageHtmlLink":"ugh, ugly"}},{"before":"671a82350d0d00dabf9bc5e63f256cb01add4058","after":"12ab6851661b91432e9dbeaaa33a279a74cf63af","ref":"refs/heads/setuptools-scm-instead-of-versioneer","pushedAt":"2024-01-24T14:34:08.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"Use setuptools_scm instead of versioneer\n\nWe are already using setuptools for many things, and setuptools_scm\nseems to become the defacto standard for automatic versioning.\n\nVersioneer suffixed with `.dirty` when there were local changes, and\nthat `setuptools_scm` uses a suffix with the date in it by default, e.g.\n`.d20240124` and increments the preceding version number to the next\nguess. We therefore modified the checks on \"dirty state\" for caching\npurposes accordingly.\n\nNote that it is hypothetically possible to make setuptools_scm behave\nlike versioneer, and suffix with `.dirty`. This was however not easy to\nget to work correctly, and seemed to fail in some cases depending on how\none requests the version.","shortMessageHtmlLink":"Use setuptools_scm instead of versioneer"}},{"before":"db0b5cce264059b6c8317d332a8687801fd5196f","after":"6dd10cf6c0e162bb7899460fce3ff011f14d8a9e","ref":"refs/heads/setup-py-to-pyproject","pushedAt":"2024-01-24T14:33:11.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"setup: Fully switch from setup.py to pyproject.toml\n\nWe were partially using both, which is asking for trouble when it comes\nto various build tools.\n\nWe split off the antlr compile command to its separate file (not part of\nthe pymoca library). It's just a `python antlr_build.py` call now,\ninstead of having `python setup.py antlr`.","shortMessageHtmlLink":"setup: Fully switch from setup.py to pyproject.toml"}},{"before":"0ffd252321443c2362c199fe1cbbaa888e56d560","after":"671a82350d0d00dabf9bc5e63f256cb01add4058","ref":"refs/heads/setuptools-scm-instead-of-versioneer","pushedAt":"2024-01-24T14:31:09.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jackvreeken","name":"Jack Vreeken","path":"/jackvreeken","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26876632?s=80&v=4"},"commit":{"message":"Use setuptools_scm instead of versioneer\n\nWe are already using setuptools for many things, and setuptools_scm\nseems to become the defacto standard for automatic versioning.\n\nVersioneer suffixed with `.dirty` when there were local changes, and\nthat `setuptools_scm` uses a suffix with the date in it by default, e.g.\n`.d20240124` and increments the preceding version number to the next\nguess. We therefore modified the checks on \"dirty state\" for caching\npurposes accordingly.\n\nNote that it is hypothetically possible to make setuptools_scm behave\nlike versioneer, and suffix with `.dirty`. This was however not easy to\nget to work correctly, and seemed to fail in some cases depending on how\none requests the version.","shortMessageHtmlLink":"Use setuptools_scm instead of versioneer"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEJpFoKAA","startCursor":null,"endCursor":null}},"title":"Activity · pymoca/pymoca"}