anchor is missing performance data for test podcast id 3

anchorAggregatedPerformance table is empty for test podcast 3. it works for test podcast 4 though.
this is the log output of pipelines which does not mention performance.
2023-08-18 11:32:23.913 | INFO     | job.open_podcast:health:73 - Checking health of https://api.openpodcast.dev/health
2023-08-18 11:32:24.657 | INFO     | __main__:<module>:226 - Sending episodesPage data to Open Podcast
2023-08-18 11:32:24.658 | INFO     | job.open_podcast:post:44 - Storing `episodesPage` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:24.975 | INFO     | job.worker:fetch:28 - Sending podcastEpisode to Open Podcast
2023-08-18 11:32:24.975 | INFO     | job.open_podcast:post:44 - Storing `podcastEpisode` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:25.295 | INFO     | job.worker:fetch:28 - Sending plays to Open Podcast
2023-08-18 11:32:25.296 | INFO     | job.open_podcast:post:44 - Storing `plays` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:25.741 | INFO     | job.worker:fetch:28 - Sending playsByAgeRange to Open Podcast
2023-08-18 11:32:25.742 | INFO     | job.open_podcast:post:44 - Storing `playsByAgeRange` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:26.023 | INFO     | job.worker:fetch:28 - Sending playsByApp to Open Podcast
2023-08-18 11:32:26.024 | INFO     | job.open_podcast:post:44 - Storing `playsByApp` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:26.331 | INFO     | job.worker:fetch:28 - Sending playsByDevice to Open Podcast
2023-08-18 11:32:26.331 | INFO     | job.open_podcast:post:44 - Storing `playsByDevice` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:26.697 | INFO     | job.worker:fetch:28 - Sending playsByGender to Open Podcast
2023-08-18 11:32:26.698 | INFO     | job.open_podcast:post:44 - Storing `playsByGender` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:27.152 | INFO     | job.worker:fetch:28 - Sending playsByGeo to Open Podcast
2023-08-18 11:32:27.153 | INFO     | job.open_podcast:post:44 - Storing `playsByGeo` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:27.576 | INFO     | job.worker:fetch:28 - Sending uniqueListeners to Open Podcast
2023-08-18 11:32:27.577 | INFO     | job.open_podcast:post:44 - Storing `uniqueListeners` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:27.863 | INFO     | job.worker:fetch:28 - Sending audienceSize to Open Podcast
2023-08-18 11:32:27.863 | INFO     | job.open_podcast:post:44 - Storing `audienceSize` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:28.188 | INFO     | job.worker:fetch:28 - Sending totalPlaysByEpisode to Open Podcast
2023-08-18 11:32:28.189 | INFO     | job.open_podcast:post:44 - Storing `totalPlaysByEpisode` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:28.490 | INFO     | job.worker:fetch:28 - Sending totalPlays to Open Podcast
2023-08-18 11:32:28.490 | INFO     | job.open_podcast:post:44 - Storing `totalPlays` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:28.804 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:28.805 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:29.154 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:29.155 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:29.464 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:29.464 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:29.727 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:29.727 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:30.012 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:30.013 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:30.291 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:30.292 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:30.565 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:30.566 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:30.862 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:30.863 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:31.154 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:31.155 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:36.809 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:36.810 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:37.087 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:37.088 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:37.390 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:37.390 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:37.659 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:37.659 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:37.946 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:37.946 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:38.228 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:38.228 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:38.526 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:38.527 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:38.773 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:38.773 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:39.123 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:39.123 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:39.417 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:39.417 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:39.705 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:39.705 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:39.980 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:39.980 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:40.267 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:40.267 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:44.255 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:44.256 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:44.522 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:44.522 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:44.820 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:44.820 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:45.114 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:45.115 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:45.409 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:45.410 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:45.704 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:45.705 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:45.980 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:45.980 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:46.271 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:46.272 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:46.598 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:46.599 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:46.875 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:46.875 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:47.132 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:47.132 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:47.422 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:47.422 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:47.719 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:47.720 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:48.014 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:48.014 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:48.276 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:48.277 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:48.568 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:48.569 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:48.898 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:48.898 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:49.196 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:49.196 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:49.468 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:49.468 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:49.760 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:49.760 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:50.049 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:50.050 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:50.371 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:50.372 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:50.631 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:50.631 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:50.907 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:50.908 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:51.203 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:51.203 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:51.590 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:51.591 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:51.871 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:51.872 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:52.162 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:52.162 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:52.438 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:52.438 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:52.723 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:52.724 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:53.005 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:53.005 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:53.280 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:53.280 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:53.559 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:53.560 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:53.865 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:53.866 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:54.244 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:54.245 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:54.516 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:54.516 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:57.427 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:57.428 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:57.687 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:57.687 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:57.962 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:57.962 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:58.346 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:58.346 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:58.616 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:58.617 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:58.908 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:58.909 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:59.181 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:59.182 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:59.454 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:59.455 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:32:59.741 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:32:59.741 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:33:00.025 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:33:00.026 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:33:00.327 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:33:00.327 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:33:00.735 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:33:00.735 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:33:01.008 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:33:01.009 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:33:01.322 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:33:01.322 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:33:01.626 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:33:01.626 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:33:01.902 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:33:01.903 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:33:02.215 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:33:02.215 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:33:02.460 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:33:02.461 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
2023-08-18 11:33:02.882 | INFO     | job.worker:fetch:28 - Sending playsByGeoCity to Open Podcast
2023-08-18 11:33:02.883 | INFO     | job.open_podcast:post:44 - Storing `playsByGeoCity` [2023-07-19 00:00:00 - 2023-08-17 00:00:00]
All items processed.

fixed by https://github.com/openpodcast/pipelines/commit/ff40b0f6e13f532130d9d22466598116b4c9f7a6


pac solution unpack on version 1.20 exports root components alphabetically

Thank you for working on getting the solution.xml to export consistently.
On pac 1.20 the sorting of the RootComponent attribute in solution.xml was changed to sort alphabetically by type, rather than numerically as was done in previous versions.  Sorting numerically seemed better.  Small nit, but worth logging.

Here's some code which will restore the sort order of RootComponents that existed before pac 1.20. This seems to be working OK for me but use with caution.
Function SortRootComponents() {

    # TEMPORARY: Since pac 1.20 a change was made to export <RootComponent> by type in alpha order, rather
    # than numerically by the type attribute. This reverts the sorting to be numeric
    $solnxml = Join-Path $solutionfolder "Other"
    $solnxml = Join-Path $solnxml "Solution.xml"

    [xml]$xmlDoc = Get-Content $solnxml
    $rootComponents = $xmlDoc.ImportExportXml.SolutionManifest.RootComponents

    # A managed solution can have an empty '<AppModuleComponents />' element, so guard against that
    if ($rootComponents -ne "") {
        Write-Host "Reordering RootComponents in " $solnxml

        # Sort the RootComponents
        $orderedRootComponents = $rootComponents.RootComponent | Sort-Object { [int]$_.type }, schemaName, id

        # Remove existing RootComponents elements.
        # Assumes that only RootComponent elements exist below the parent RootComponents element
        $rootComponents.RemoveAll()

        # Append sorted RootComponent elements
        $orderedRootComponents | ForEach-Object { $rootComponents.AppendChild($_) } | Out-Null

        # Save the update solution.xml file
        $xmlDoc.Save($solnxml)
    }
}


RemoveMSI element doesn't work

Please see the attached screenshot:

Office 2019 is installed, the 2021 XML file contains "RemoveMSI" line but the installation routine can't remove the old products.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: abccf87c-8c75-1dd7-929b-d59310979bf9
Version Independent ID: 02e16bee-5591-0312-db88-4602f8872871
Content: Deploy Office LTSC 2021 - Deploy Office
Content Source: DeployOffice/ltsc2021/deploy.md
Product: office-perpetual-itpro
GitHub Login: @DHB-MSFT
Microsoft Alias: danbrown

The Office 2019 products are not based on the legacy MSI installation technology, but rather use Click-to-Run. That's why the command to remove any MSI product does not catch the 2019 products. You can add a -statement to your XML to uninstall C2R products. E.g.  to uninstall any C2R product before executing the  portion of the XML.

ah, "" wasn't shown in the documentation...thanks...

@copenhaus   We mention the Remove option in the "Remove existing versions of Office before installing Office LTSC 2021" section of the article:
To uninstall 2019 versions of Office, Visio, or Project from the device, use the Remove element. You use the Remove element because 2019 versions of Office, Visio, and Project are installed by using Click-to-Run, not Windows Installer (MSI).
We use RemoveMSI in the xml example in the article because we think most customers moving to Office LTSC 2021 will be coming from an MSI version of Office, such as Office 2013 or Office 2016.


Doesn't detect classes inside es6 template strings

webpack 4
purgecss-webpack-plugin 1.2.0

this doesn't work (below 2 classes don't appear in the final css bundle):
const className = `no-underline bg-blue-lighter`

this works (single quote):
const className = 'no-underline bg-blue-lighter'

My config:
const path = require('path');
const glob = require('glob');
const PurgecssPlugin = require('purgecss-webpack-plugin');

class TailwindExtractor {
  static extract(content) {
    return content.match(/[A-z0-9-:/]+/g) || [];
  }
}

new PurgecssPlugin({
  // files to scan for class names.
  paths: glob.sync(path.join(__dirname, './src/**/*.js')),
  extractors: [
    {
      extractor: TailwindExtractor,
      extensions: ['js', 'jsx'],
    },
  ],
  whitelist: ['html', 'body'],
  whitelistPatterns: [],
});

Ok it turns out the match result contains the back tick ie.
['`no-underline', 'inline-block']

which is why it doesn't work. My dirty solution is removing back ticks in the final result array, hope this help.

Try this in the extractor: /[A-Za-z0-9-_:\/]+/g the A-z somehow includes a backtick


Link is broken for the discord channel.

🔎 Search Terms
github typescript team
🕗 Version & Regression Information

This is a crash
This changed between versions ______ and _______
This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
I was unable to test this on prior versions because _______
This is nothing major issue.

⏯ Playground Link
No response
💻 Code
// Your code here

### 🙁 Actual behavior

https://github.com/microsoft/TypeScript/issues/new/choose

I tried to navigate to open the above link to quickly chat in discord. But seems link the link is broken.  I need to chat with the right people for a feature request in TS docs team.
Could you please update it. Thanks

### 🙂 Expected behavior

Should be able to navigate correctly to the discord channel.

### Additional information about the issue

_No response_

The discord link works fine for me.

Thanks for the quick follow up. The chat section of that seemed broken. It is working for me now though. Thanks.👍

Thanks for the quick follow up.


Cannot import name 'CropRandomizer' from 'robomimic.models.base_nets'

I try training the model with your generated datasets, and get this error:
Cannot import name 'CropRandomizer' from 'robomimic.models.base_nets'
With suspecting incorrect installation of robomimic, I go to https://github.com/ARISE-Initiative/robomimic/blob/master/robomimic/models/base_nets.py to check. However, I can't find CropRandomizer and Randomizer either.
Could you help me figure out why and how?

Hi, it could be that they've updated their codebase. Please modify the code accordingly to accommodate their new changes, or you will need to install an older version of robomimic to use these classes.

having pip installation from requirements.txt file. what is the python version proven to be working for this repo?

Encounter the same issue in another project. Upgrading the robomimic version to 0.3.0 solves this problem.
pip install robomimic==0.3.0

Encounter the same issue in another project. Upgrading the robomimic version to 0.3.0 solves this problem.
pip install robomimic==0.3.0

Still encountering the same issue even after upgrading to 0.3.0.


Design UI for extended metadata tags

Follow up from https://github.com/NASA-AMMOS/aerie-ui/issues/575
We need to design how to handle metadata tags in the UI.

Core goal is to be able to interact with large amounts of data from a variety of sources in an intuitive and familiar way. There are two key use cases we're looking to support.
1. Flexible and evolving categorization

New science and engineering aspects that weren't anticipated at mission start
Ability for individuals or teams to create their own taxonomy

2. Categorize fixed known / fixed categories like in a persistent way across a mission

Ability to have consistent and non-cluttered access to sorting and filtering for data across the app for known categories
Useful for color coding timelines so people can learn what color means and depend on it across the mission (clipper request but i think useful to other missions)
Future bonus, admins could leverage these in their permission models (eg user only gets access to relevant subsystems)

WIP idea for proposed system supporting both use cases:

Current working direction with discussion in this figjam file
Tag requirements:

Metadata includes name, color (can be blank), createdBy id, date added
Nice to have number of times used
Users who created a tag can delete it. Admins can delete any tag.

Tag UI:

Panel with list of tags, ability to search tags, and ability to delete tags you own.
Maybe a way to filter to tags you own, or show them at the top?

Tag location:

Plans
Plan Merge
Scheduling goals
Constraints
Expansion rules

Filters:

Filter in activity dictionary
Filter in timeline layer editing
Filter in timeline table

Tags are ready to go! Pulled a lot of concepts from the github labeling system.
👉 Figma file
Main features

New visual style for tags

Round with color for tags
Square with color for subsystem

Add tag editor panel

Show color coded tags, created by, and (nice to have) description
Search tags with fuzzy search, search should lookup based on tag name, username, and description (if we can include)
Create tag editor popup

Improve panel view for tags + subsystem

Show color coded tags with new styling
Preserve current typeahead for adding new tags, show color in tag autocomplete
Nice to have: add second line for description
Nice to have: ability to collapse tags subsection and show number of total tags

Add tags and subsystems tables

Just presentational, editing still happens in the tag editor or the activity instance details
Show tags in activity table, plan table

Open questions

How does someone add tags to a plan? How does someone edit a plan?
Whats the generic approach to filtering on tags?
What are all the places tags should exist?

Expansion rules?
Constraints?
Activity types?


Updated fetch_all_by_Transcript method to optionally filter by featur…

…e_type (dna_align or protein_align features)

Changes Unknown when pulling 2765408fad63aae80bd82c7b102940b3f6c58608 on ENSCORESW-1884 into ** on master**.

Changes Unknown when pulling a2faffccad185e9e513b2b061dea58c036d97b4b on ENSCORESW-1884 into ** on master**.

I think this is good for merging now


PUT APIs behave as if they were PATCH APIs

Build context
Project version
v0.1.0
Latest commits
https://github.com/trebol-ecommerce/trebol-backend-monolith/commit/8474c7264b741d68f434be7167a2718006cf2486
Summary
How to Reproduce
Call any PUT endpoint from the REST API exposed by this backend, sending a partial object from the one expected by the API.
e.g. if it's a Person type of data and you have a registry with an idNumber set to 1, send it like this:
{
  "idNumber": "1",
  "firstName": "Jumbo"
}

It will only update the firstName in the existing registry.
Expected behavior
It should reject the object, as it only partially contains the required data. A PUT request should only accept entire valid objects and only then should update any matches.
Additional context
The current behavior should be kept for later; as the Trébol API will eventually expose both PUT and PATCH methods.
Also, when this issue gets fixed, #226 should be resolved and merged too.

hi @bglamadrid,
May I know the exact endpoints?

Hello @NyorJa
This involves all endpoints beginning with /data/ that have a PUT method, e.g.

PUT /data/customers
PUT /data/products
PUT /data/sales

And so on.

I made a related issue on this matter on the repo of the API.
When said API gets an update including the feature, the resolution of this issue should go hand-in-hand with that, too 🦾

@Valid annotation works on my end in the controller but I have challenges in setting up the unit test like an integration test

@Valid annotation works on my end in the controller but I have challenges in setting up the unit test like an integration test

That isn't really related to this issue though?
And what do you mean by doing integration tests?

I'm trying to run a @WebMVCTest in the controller class and I am encountering an error.


Fix(android): restart issue react76

Summary
fix: https://github.com/TheWidlarzGroup/react-native-video/issues/4261
fix: https://github.com/TheWidlarzGroup/react-native-video/issues/2693
Motivation
Fix issue on react native 0.76
Changes

move bufferConfig inside source
fix restart issue on react 0.76
fix constness
deprecate bufferConfig in root props
update documentation
upgrade expo exemple to expo 54 with new arch

Test plan
Can be test with the expo sample

Amazing job! Can you tell me in short what part fixed issue on 0.76? Thank You!

I don't know why but we receive multiple times setBufferConfig callback. As there was a "force restart playback" inside this function playback was restarting 🤷
Maybe an issue in react native but I did already plan to change that (it was possible that it causes some race conditions in initial start up).

@KrzysztofMoch I will release that tonight!

@hongjae-eum no it should not ... Do you use the last react native version ? 0.75 with newArch enabled ?

@hongjae-eum maybe this line: https://github.com/TheWidlarzGroup/react-native-video/blob/dd78241b0d997e87a65f2f898c7059a72951e532/android/src/main/java/com/brentvatne/common/api/Source.kt#L104
Can you try to remove the condition locally ? I think it can be the issue. I missed to overload the equals in BufferConfig ..

@freeboub
Commenting out that part(line 104) resolves the restart issue! If that part is indeed the problem, it would be great if a patch could be released quickly.

Yep, I will do it tonight, ping @KrzysztofMoch

@hongjae-eum here is the fix: https://github.com/TheWidlarzGroup/react-native-video/pull/4305
It has already been released !
Thank you for the quick feedback !


Please edit file name

Please edit file name of importer/tests/fixture/KML_Samples.kml:Zone.Identifier to avoid invalid path issue on some system

Thanks @S-Suraphat. The file has been deleted.


Change the name of the custom symlinked release

Deployer version: 6.8.0
Deployment OS: MacOS 11.2.3 (Big Sur)

I'm testing the WordPress deployment locally, and I'm trying to make a symlink from my release to a theme
After running build process, and copying the built theme to /.build folder I have these tasks in my upload.php:
<?php

use function Deployer\{task, upload, run, writeln};

task('upload:upload', function () {
	upload('{{theme_path}}/.build/', '{{release_path}}');
});

task('upload:symlink', function () {
	run('mkdir -p {{deploy_path}}/wp-content/themes/');
	run('{{bin/symlink}} {{release_path}} {{deploy_path}}/wp-content/themes/');
});

task('upload:clean', function () {
	run('rm -rf {{theme_path}}/.build');
});

So first I upload the built theme to the release path, I can see that this is done correctly, as I see the releases being filled with folders containing the built theme.
Then I'd like to symlink the latest release to the theme name folder. So I am creating the theme folder mkdir -p {{deploy_path}}/wp-content/themes/, then I am running the symlink command
run('{{bin/symlink}} {{release_path}} {{deploy_path}}/wp-content/themes/');

Which kinda works, but I am wondering if it's possible to symlink the release to the theme name folder (kinda like current is symlinked)
Currently, I have this structure when deploying
wp-content/themes/2021-03-28-155125 (symlink)

And every time I deploy I'd get a new symlink inside
wp-content/themes/2021-03-28-155125
wp-content/themes/2021-03-28-155514

What I'd like is to have
wp-content/themes/theme-name (symlink to latest release)

I tried by defining the theme name, but that does the same, only inside the theme-name folder. I'd like the theme name to be same always, but its symlink to change.

Ok I think I found it 🤦🏼♂
run('{{bin/symlink}} {{release_path}} {{deploy_path}}/wp-content/themes/{{theme_name}}');

This did the trick, kinda. Need to see what's failing with my composer setup, but that's not deployer-related.


Allow ember-mirage to generate the serializers (primaryKey and attrs) like it does for models 👍

I have a PR in the works, we have been using it at my company for a while now, wanted to get your take on it, any suggestions etc.  While fully usable, there are two issues that I cant seem to figure out and was hoping we could pair or something to get through them.   Those issues will be detailed at the bottom:
My current fork:  https://github.com/bgantzler/ember-cli-mirage/tree/serializer
Expect some of these commits to be rebased or altered as I continue testing, as a PR has not yet been submitted.
Create a new serializer based off the RestSerializer called EmberDataSerializer that does the following:

Altered the Server to generate mirage serializers based off the primaryKey and attrs hash (will be called transforms in the mirage serializer (attrs was already in use)) defined in ember data serializers. (If a mirage serializer already exists, it will extend them)
both serialize and normalize(deserialize) will transform to and from the id property of the mirage store using the specified primaryKey
both serialize and normalize(deserialize) will use a new hash transforms as follows:
allows each property to be renamed in the JSON payload like the key property in the attrs hash for ember data serializers.
allows for each relation to specify how serialize and normalize will treat the JSON payload . Values are the same as the ember data serializer. Includes the value records from the embeddedRecordsMixin. The serialize from the ember data serializer will be applied to the mirage deserialize, and the deserialize of the ember data serializer will be applied to the serialize of the mirage serialize.
still respects the includes array for side loading additional elements.
does not respect the mirage attrs array (uses the transforms hash to specify which properties to include)
does not respect alwaysSerializeIds (uses the transforms to allow each relationship to specify if ids should be included)
does not respect embed (uses transforms hash to allow each relationship to specify if it should be embedded)
Includes the pushMirageToStore method. This method works the same as the one documented in issues with the following changes. Works the same if no parameters are passed. Allows for a hash to be passed. This hash will allow you to select which tables to push and an optional where clause to be applied to that table.
For addons, provides a ember-cli-build method that can be imported into the index.js that provides for exporting the mirage folder into the application.

The two issues I am currently running into do not stop the use of these changes, just causes two minor annoyances

when I create an application serializer, and specify root: false it does not seem to be respected in the serializer code. I have to do the following, I dont understand why

normalize() {
    this.root = false;
    return EmberDataSerializer.prototype.normalize.apply(this, arguments);
}

2) when the exportToMirage is imported from ember-cli-mirage repo, the merged trees are at the wrong level. When the code is copied into the addon repo, then imported, it is correct. It Is the same code in both cases, the code is using locally provided arguments, I dont understand why it would make a difference where it is being imported from. Still an issue, but not included in this PR

Awesome.
After we ship the tutorial + v1.0 of miragejs and get back to feature development, I'd like to focus on what primitives are missing from Mirage that would allow a solution like this to exist in userland. We are thinking through a plugin or middleware system.
As you've been building this, what changes or new primitives would we need to expose so you could build this completely in userland?

What do you mean by userland, do you consider ember-cli-mirage as user land for ember?
The real change was that the current flags in mirage were an all or nothing, being allied to all properties in the serializer, so I couldn't reverse engineer the an ember data serializer into them, so I created the transforms hash (equiv of the attrs hash in ED Serializer). That hash also allowed for a property by property rename.
I kept that in ember-cli-mirage instead of making a mirageJS PR because it so closely mirrored ED way of doing it and didnt think you wanted two ways of doing things. But because it gives a much finer control the transforms hash could easily be implemented in the miragesJS rest (maybe active) serializer. I dont think think it would apply to JsonAPI.
The other major change was to the StartMirage code to create the serializers from ED serializers. This would only apply to user land of ember, which is what this add on is all about.
The bulk of the code was the transforms hash, and allowing for defaults. The renaming used the keyForAttribute. Not having id go through there and instead having a keyForId would have been nicer, but only a couple lines of code there.
Most the rest of the code was in _hashForModel and a shouldSerializeProperty would have allowed the include/exclude and could be implemented by the whitelist attrs, then maybe a serialzeProperty (have some ideas there, in fact may change my code to implement this, then that could be a mirageJS PR).

By userland I meant in your application itself, rather than having to submit a PR to miragejs or ember-cli-mirage.
I was curious if the changes you're proposing require changes to the core lib itself, or if it's more just a new serializer that would be convenient for Ember Data users to use.

Also this PR is big. We should break it down into the smallest pieces to maximize the chance of shipping it. There's been lots of large PRs that have languished in Mirage's history.
For example the pushStoreIntoDb is kind of a separate problem. It needs addressing, but probably not in this PR.

Effectively yes, this is a new serializer that is more specific to ember data that I think belongs in ember-cli-mirage as everyone should not have to reimplement this.
The push to store and merge trees could easily be moved out for a separate pr, they are really each a stand alone files. So drop those two files.
While the serializer could be in its own PR, its value is gained by the change to the startup which like models creates mirage serializers from the ED serializers, so I would prefer that remains as a whole.

Gotcha.
I wonder if we should do this as a separate package that folks can install, so you can experiment without me blocking you. My goal is eventually for ember-cli-mirage to be a very small wrapper around miragejs and this kind of moves it in the opposite direction. That's also the reason I asked whether this could be done in "userland", meaning could it be done in a separate library without any new changes or APIs added to miragejs.
Also, different apps that use Ember Data can still have different API formats. Is the idea with this serializer that the API format information is already contained in the Ember Data adapter/serializer layer, so we can just leverage that and save us the work of defining it on the Mirage side?

Correct
A separate package for the serializer would work for the serializer alone, but the real key is like models, creating the serializers off the ED serializers, so I would have to subclass startMirage, and then server, and effectively would be a replacement to ember-cli-mirage.

Ember-cli-mirage would be a thin wrapper to MirageJS except for the startMirage and Mirage doing the model generation, you still need to keep that code. I want to add to that code by generating serializers.    Exposing some more primitives in mirageJS might reduce some of the code here, but they way it renames fields, specified embed vs ids, is different than what MirageJS does, so Im not sure that would make it into MirageJS

Gotcha. Ya so that's exactly what I was talking about, what parts of mirage or ec-mirage do we need to expose so you could build something like this in a separate package without needing to change mirage.
I think ideally, ec-mirage exposes a function that gets the Ember Data model and serializer map passed into it as arguments, and you can use those to help you define any mirage config for your app.

Yes totally – the startMirage and auto discovery of models is an ec-mirage concern. I think it would be good to put some better boundaries around this code and the code that configures the Mirage server.

So what you would need to expose would be some way for another addon to hook into startMirage and Server. I dont have a suggestion for that.

Server has a config() method that can take it additional configuration, so you might be able to do it in config.js like this:
// config.js
export default function() {

  // Add additional serializers
  this.config({
    serializers: {
      application: SomeSerializer
    }
  })
}

So in theory an addon could expose a function that the host app could use to augment their server with the right serializers:
// config.js
import { defineSerializers } from 'ember-cli-mirage-ember-data'

export default function() {

  // Add additional serializers
  defineSerializers(this, mySerializers)
}

So the next question is how best to make the application's serializers (or more generally, the app's Ember Data config) available to either this function or to the config.js Mirage file.
We could do it by exporting a new named function from config.js that gets the config and lets users update it. And we could inject the ember data information into this function so users could use this to define their mirage config based on Ember Data config. And then the autodiscovery of ember data models features could be implemented in terms of this API.
Something along the lines of
// config.js
import { defineSerializers } from 'ember-cli-mirage-ember-data'

export function augmentConfig({ config, emberData }) {
  config.serializers = defineSerializers(emberData.serializerMap)
}

export default function() {
  // Normal Mirage config
}

The first option, this.config in the config.js wont work, this function is called too late, if you implemented models there the ED models would override the mirage models. In the case of serializers we dont want to override but extend.
The second if the most promising, if that method would be called before the schema is created here https://github.com/miragejs/miragejs/blob/master/lib/server.js#L464 it would allow the function to add, remove, alter the models and serializers. If it was called earlier, like here https://github.com/miragejs/miragejs/blob/master/lib/server.js#L237 we would be able to augment more, timing, logging, trackRequest, etc.
The parameter emberData would contain what? serializerMap and  modelMap? or should that not be passed and its the addons problem to do https://github.com/miragejs/ember-cli-mirage/blob/master/addon/ember-data.js.  Presumably this would be moved to the addon that implemented model discovery. I basically copied this code for and changed the regex for the serializer discovery, this wouldnt need to be part of ec-mirage anymore but part of the ec-mirage-model addon.
The nice thing about embers  addons are install and they pretty much just work. For a user to use ec-mirage now, the config would have to look like this
// config.js
import { getModels } from 'ember-cli-mirage-ember-models'; // assuming model discovery moved from ec-mirage to its own addon

export function augmentConfig({ config, emberData }) {
  options.models = getModels(config.models); // change to allow param to keep Object.assign in the method
}

export default function() {
  // Normal Mirage config
}

a breaking change. But it is clear where the user is opting into model discovery, so the config autoDiscoverModels could go away
and then to use my addon they would change to
import { getModels } from 'ember-cli-mirage-ember-models';
import { getSerializers } from 'ember-cli-mirage-ember-serializers';

export function augmentConfig({ config, emberData }) {
  options.models = getModels(config.models);
  options.serializers = getSerializers(config.serializers)
}

export default function() {
  // Normal Mirage config
}

This leaves ec-mirage as only a wrapper to start the server from startMirage and nothing else.
But do we really need two addons, ec-mirage and another to do the model discovery. And then a third for serializers. If you keep the model discovery in ec-mirage, well serializers go hand in hand with models so why not put that in ec-mirage as well. By putting everything in ec-mirage there is no additional config and the new serializer is available by just changing serializer application inherits from.
In the end, if you allow for an augmentConfig method as described above, yes, I could provide the serializerDiscovery in a separate addon.

The nice thing about embers addons are install and they pretty much just work

While true, that's also why you've been blocked on this, because of the "magic" that ec-mirage uses to instantiate + configure the Mirage server. And it's not just you, there's a ton of open issues here related to the fact that Mirage starts itself in a magical way that is not obvious how to override.
I'd like to move away from adding more "magic", since it hides the lower-level pieces and makes it hard for folks like yourself to configure Mirage when you need to.
I think the augmentConfig export is too magical, it doesn't provide enough control. I think we should try to think of a way to expose more control in a backwards compatible way.
For example, we could detect a new file called index.js that lives in the /mirage directory, and if that file exists, we don't automatically define the factories/serializers/model definitions on the server. Instead, maybe this file exports a createServer function that has everything defined right there:
// mirage/index.js
import { Server } from "miragejs";

export function createServer() {
  return new Server({
    models: {},
    serializers: {},
    // ....
  });
}

That way (1) it matches miragejs (2) users can see everything that's happening and they have the opportunity to wire up anything else they need. We'd also need some way to hook this into the initializer. So I think that's what we should focus on next, because I really don't want to add more ad-hoc APIs to ec-mirage since they just make the project harder to support.
We could eventually provide some utils to help wiring up the files on disk to Mirage but, I think a good starting place is to let folks import the files themselves and pass them in, since this is a lower-level API.

I understand.
Would makeServer.js be a better name? (I think there are many that create addons without understanding or even touching index.js)
Where are you going to draw the line on magic? You could remove setupMirage, startMirage and the Server defined in ec-mirage and just ask them to call this function in beforeEach, and then shutdown in afterEach. I think that would effectively eliminate ec-mirage as it is now. Then a new addon that does model discovery that they would import and use in this new makeServer function.
I think that effectively what is happening here https://miragejs.com/quickstarts/cypress/#step-2-define-your-server.
I think the question is what is the vision of the functionality ec-mirage as an addon provides? Just the qunit wrapper startup (with the above suggestion to get a hook to the create server). Is the model discovery part of this addon? or another addon?

I think it would be totally reasonable for ec-mirage to provide the model & serializer discovery, and to either generate an initializer or provide a helper that does so. I just think the actual instantiation shouldn't be as hidden as it is today, so that users can see how the discovered models & serializers are passed in, and can therefore change it all.
Passing the Ember Data info into a startup function seems pretty cool, as a way to simplify the setup for the user but still give them the opportunity to change it.
Re: name, yeah we can definitely brainstorm. I wasn't thinking index.js like the addon, was just thinking something like mirage/index.js in folks' apps. We can definitely brainstorm though. Could also just have a new named export from mirage/config.js, so instead of the default function export we check to see if there's a named function export called something like setupMirage or makeServer.

Obviously this would have been easier on a call or in person. :) I knew you meant mirage/index.js, I meant I think a lot of people dont realize what the name index.js means and might not look there or wonder why its called index.js (im fine with it, I understand it).
Totally agree over how some of the magic happens by making it more clear. This also opens up the ability to get access to any new configurations on Server create from mirageJS.
Aside: how does https://github.com/miragejs/ember-cli-mirage/blob/master/app/initializers/ember-cli-mirage.js#L2 work when someone renames the mirage directory, since "mirage" is hardcoded on that import. Shouldnt that throw a module not found?
Since testConfig is already a special export from config.js, I would think doing a makeServer export would be in line. Keeping with clear point of where things are happening, the startMirage.js in this case should NOT use testConfig and the default export (base-config), the user should call those within makeServer.
Heres what I see

setupMirage.js stays the same
update app/initializers/ember-cli-mirage.js to register the new makeServer. The other two (base-config and test-config) would eventually be removed
startMirage.js performs the same for backward compatibility but also detects the presence of a makeServer export. Instead of creating a new Server, calls said function that returns the new server created. Still pass the same options to makeServer that it was passing into new Server. baseConfig and testConfig will not be set to force an import or method call in makeServer for clarity (mentioned above)?
the method getModels can be imported from util/ember-data, but I would rather it be re-exported from ember-cli-mirage to keep a clean import.

I think that covers it. Would you like to see a PR for this alone, and then a follow up PR that provides serializer discovery? Not sure I understand all the testing to create another app that does this way, Ill ask if I get into any problems.
ec-mirage documentation does not seem to be within this repo, how would I go about updating documentation?

Awaiting your comments in case there are any changes. I have a PR ready to submit if the above is acceptable.
the users config.js can now look like this
import { Server } from 'miragejs';
import { discoverEmberDataModels } from 'ember-cli-mirage';

export function makeServer(options) {
  options.routes = routeHandlers;
  discoverEmberDataModels(options);
  return new Server(options)
}

export function routeHandlers() {

  this.resource('user');

}

While the route handler can still be a default export if you wanted, it doesnt have to be.

Been busy so will have to check this soon. Would say hold off on writing any more code just in case there are changes.
(I know it’d be easier to have this convo in real-time but if it wasn’t async it wouldn’t be happening at all! This is the only way I can fit it into my schedule.)

On Jun 18, 2020, at 5:15 PM, Brian Gantzler<EMAIL_ADDRESS>wrote:
Awaiting your comments in case there are any changes. I have a PR ready to submit if the above is acceptable.
the users config.js can now look like this
import { Server } from 'miragejs';
import { discoverEmberDataModels } from 'ember-cli-mirage';
export function makeServer(options) {
options.routes = routeHandlers;
discoverEmberDataModels(options);
return new Server(options)
}
export function routeHandlers() {
this.resource('user');
}
While the route handler can still be a default export if you wanted, it doesnt have to be.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/miragejs/ember-cli-mirage/issues/1989#issuecomment-646309512, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWJOCWTY7DE6DA2HCV4RKDRXJ7WVANCNFSM4N5F5OHQ.

There was very little code. I am happy with the end result.

I appreciate your work! But I want to discuss the API before looking at the implementation. There's a lot of code in your PR... I don't know if we'll need an entire new test project for this. (Each one is just a lot to maintain.)
Can we keep discussing the API? I need to understand it before moving to review the code.
What is routeHandlers and how is it + makeServer used?

Yea sure.  I wanted to show that the old and the new way both still work, so I created a new test project. Can do whatever you want there.
(sorry I left export on the routeHandlers, it isnt needed, which may have been your confusion)
Currently config.js contains an export default function which is the router handers, it just was not  named.
export default function() {
  this.resource('user');
}

We no longer need this function as an export default and we need it named to refer to it in the line options.routes = routeHandlers. (or you could choose to inline it, as mirageJS documentation shows. But as this grows, most people put it in a separate file and import it. We can now do this in ember-cli-mirage as well. examples below)
Instructions to change config.js (simple straightforward solution)

remove export default from the current function and give it a name
add the imports and the makeServer function and assign options.routes the new name you assigned to the function (example below)

import { Server } from 'miragejs';
import { discoverEmberDataModels } from 'ember-cli-mirage';

export function makeServer(options) {
  options.routes = routeHandlers;
  discoverEmberDataModels(options);
  return new Server(options)
}

function routeHandlers() {
  this.resource('user');
}

Since the route handler function is now just a function, a user could arrive at the following more complex instuctions

rename config.js to route-handers.js. (or any other name you want)
create a new file named config.js that looks like the file below. Update the import statement of routeHandlers if you choose a different location or file name

file route-handlers.js (this can be any name the user wants).
export default function() {
  this.resource('user');
}

config.js
import { Server } from 'miragejs';
import { discoverEmberDataModels } from 'ember-cli-mirage';
import routeHanders from './route-handlers';  // where the user put it and what they called it

export function makeServer(options) {
  options.routes = routeHandlers;
  discoverEmberDataModels(options);
  return new Server(options)
}

Gotcha.
Ok first, just to minimize churn, I don't think we need to rename the default export to routeHandlers. I know it's a little confusing but at this point, the default function export from config.js has been the routes for so long that I don't think there's much of a benefit in changing it.
I also think they should already be attached to the config/options object passed into makeServer.
Basically, the default makeServer function is
export function makeServer(config) {
  return new Server(config);
}

And then folks can augment the config as they please.
For discoverEmberDataModel, (1) I think it should return an object (instead of mutating the arg), second, does it need to be passed in the config at all?
I think ideally I'd like to see this:
import { Server } from 'miragejs';
import { discoverEmberDataModels } from 'ember-cli-mirage';

export function makeServer(config) {
  let finalConfig = { ...config }
  finalConfig.models = discoverEmberDataModels();

  return new Server(finalConfig);
}

// as usual
export default function() {
  this.resource('users')
}

So agree with all.
Notes: :)
I thought the removal of export default was part of the removal of magic to stear towards clearer what was happening. Both easily supported.
I went back and forth on discover models on passing the options or not (it returns the models so the assignment was available). I thought by passing the config, if additional config was needed,  it could be added with a hope of no additional changes on the users part. No problem to drop it.
End result we are on the same page and the current code I wrote needs like 2 or 3 lines tweaked and then we are there.
Documentation:
I see that the documentation is in the dummy app (missed it behind pods). Would you like me to take a stab at altering the documentation in this PR, a separate followup PR, or would you prefer to do it (Im not the best doc writer but can try if you would like)
Out of curiosity, the config could have been altered directly, yet you created a copy as finalConfig. What was the through process behind that?
I needed to read farther down the page on the documentation, I didnt realize the Spread operator could also be applied to properties, only ever seen it used on arrays.

I thought the removal of export default was part of the removal of magic to stear towards clearer what was happening.

I think this requires more consideration/work since ultimately it would be a breaking change and to keep the scope of this as small as possible, I think we should have an additive API so you can get your original problem solved. Eventually we can figure out how to move ec-mirage community all the way over to an integration story that looks like every other framework but I don't think it's necessary for this change.

I thought by passing the config, if additional config was needed, it could be added with a hope of no additional changes on the users part. No problem to drop it.

Yeah, I think the lesson I've learned from maintaining Mirage is when I try to do stuff like this it always ends up biting me. I think I'd rather have it do less + tell users to copy+paste more explicit code, since this is sort of a power user feature.

Would you like me to take a stab at altering the documentation

Would be great as part of this PR, why don't you do a first pass + I can come clean it up as needed?

Out of curiosity, the config could have been altered directly, yet you created a copy as finalConfig. What was the through process behind that?

Ya config.models = models is probably how I'd do it but, I think avoiding assignment/working with "immutable" data is a more popular/recognizable approach these days, so I did that just to make it clear that nothing special was going on and the user is free to alter what they pass in any way they like.

I needed to read farther down the page on the documentation, I didnt realize the Spread operator could also be applied to properties, only ever seen it used on arrays.

Yep, especially having dipped my toes into React + Vue ecosystem over the past year this is very popular. So I think it'd be good to adopt the prominent style.
Thanks for continuing to push this forward Brian!

the removal for the need of export default is ONLY if they create a makeServer function, export default for the old way is still supported. So I wouldnt consider that a breaking change since they already committed to a change by making a makeServer function. It also reinforces that is doesnt HAVE to be an export default in this file. They can now put the route handlers in a separate file(s) of their choosing and import it. (if they export default, we will continue to add it to the config, I would prefer to teach away from this and deprecate it at some point, rather the continue to support it).
That being said, any plan to deprecate the old way (I think it should, it leads to more code being removed from ec-mirage and the new code goes more in matching mirageJS documentation on how to define a server).
Testing.    The project 3 is huge I admit, but how do I prove the new way worked otherwise? Any ideas? If old way is deprecated, then test 1 would be removed along with it when the time comes.

I went to change the discover models method and this is why I passed options in.     The discovered ED models has to be merged with the mirage models with the mirage models winning.   This line options.models = Object.assign({}, getModels(), options.models);.
If we dont pass it in, the user would have to write this line
options.models = Object.assign({}, discoverEmberDataModels(), options.models);
not so optimal. Would prefer to hid that from them.

Additional questions.
Should we use the createServer instead of new Server in the docs?
Would you like the blueprints updated for this? Keeping with the export default I assume. However what is the desired future for the config, do we use inline definition of routes and models as the MirageJS documentation does.
import { Server } from 'miragejs';
import { mergeEmberDataModels } from 'ember-cli-mirage';

export function makeServer(config) {
   let finalConfig = {
         ...config,
         routes() {
              this.resource('users')
         },
        models: mergeEmberDataModels(config.models)
   };

  return new Server(finalConfig);
}

I realize it is simpler and easier for the docs than dealing with multiple files, should we also take this approach for documenting this way and the blueprint would look like
import { Server } from 'miragejs';
import { mergeEmberDataModels } from 'ember-cli-mirage';

export function makeServer(config) {
   let finalConfig = {
         ...config,
         routes() {
                // These comments are here to help you get started. Feel free to delete them.

                /*
                    Config (with defaults).

                    Note: these only affect routes defined *after* them!
                */

               // this.urlPrefix = '';    // make this `http://localhost:8080`, for example, if your API is on a different server
               // this.namespace = '';    // make this `/api`, for example, if your API is namespaced
               // this.timing = 400;      // delay for each request, automatically set to 0 during testing

               /*
                     Shorthand cheatsheet:

                     this.get('/posts');
                     this.post('/posts');
                     this.get('/posts/:id');
                     this.put('/posts/:id'); // or this.patch
                     this.del('/posts/:id');

                     https://www.ember-cli-mirage.com/docs/route-handlers/shorthands
              */
        },
        // Remove or comment out the following line to remove Ember Data Model discovery and merge
        models: mergeEmberDataModels(config.models)
   };

  return new Server(finalConfig);
}

This has the benefit of looking like the MirageJS documentation
I wish the makeServer function was the unnamed export default from config, while being a breaking change, its a small change and better positions ec-mirage to more closely match the usage of mirageJS proper.

If you could re-evaluate the PR https://github.com/miragejs/ember-cli-mirage/pull/1994 I would appreciate it.

Working on getting caught up on some things but this is definitely on my list. Appreciate the work!
– Sam

On Jul 6, 2020, at 3:54 PM, Brian Gantzler<EMAIL_ADDRESS>wrote:

If you could re-evaluate the PR #1994 I would appreciate it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

Bump

This issue got taken over with some pre-work to expose a makeServer option to allow better access to the underlying Mirage config.    Closing this issue and opening another one to allow for the serializer generation


groonga: 8.0.2 -> 8.0.5

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/groonga/versions.
meta.description for groonga is: '"An open-source fulltext search engine and column store"'.

Checks done (click to expand)

built on NixOS
/nix/store/m4dbxdbggxsa90m9w6zqyp1kph1qfy0b-groonga-8.0.5/bin/groonga-suggest-create-dataset passed the binary check.
/nix/store/m4dbxdbggxsa90m9w6zqyp1kph1qfy0b-groonga-8.0.5/bin/groonga passed the binary check.
Warning: no invocation of /nix/store/m4dbxdbggxsa90m9w6zqyp1kph1qfy0b-groonga-8.0.5/bin/groonga-benchmark had a zero exit code or showed the expected version
/nix/store/m4dbxdbggxsa90m9w6zqyp1kph1qfy0b-groonga-8.0.5/bin/groonga-httpd passed the binary check.
Warning: no invocation of /nix/store/m4dbxdbggxsa90m9w6zqyp1kph1qfy0b-groonga-8.0.5/bin/groonga-httpd-restart had a zero exit code or showed the expected version
3 of 5 passed binary check by having a zero exit code.
0 of 5 passed binary check by having the new version present in output.
found 8.0.5 with grep in /nix/store/m4dbxdbggxsa90m9w6zqyp1kph1qfy0b-groonga-8.0.5
directory tree listing: https://gist.github.com/1cc9468a8248dbb9b8ee95c96cec7323
du listing: https://gist.github.com/abe60c52ff46849f59908ae3ca5f2a2c

Test this build with Cachix (click to expand)

One time setup in nixpkgs Git checkout:
cachix use r-ryantm
git remote add r-ryantm https://github.com/r-ryantm/nixpkgs.git

Test this build:
git fetch r-ryantm && git checkout 5fbce1ae0eeea24dc90cd6e1374b2aaf78620fcd && nix-shell --pure -I nixpkgs=. -p groonga

cc @ericsagnes for testing.

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: groonga
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: groonga
Partial log (click to expand)
/nix/store/m4dbxdbggxsa90m9w6zqyp1kph1qfy0b-groonga-8.0.5/share/groonga/examples/dictionary/gene95/gene-import.sh: interpreter directive changed from "/bin/sh" to "/nix/store/dkh7l9a4sx7zqh8riqbj3z21sz25p8xy-bash-4.4-p23/bin/sh"
/nix/store/m4dbxdbggxsa90m9w6zqyp1kph1qfy0b-groonga-8.0.5/share/groonga/examples/dictionary/eijiro/eijiro-import.sh: interpreter directive changed from "/bin/sh" to "/nix/store/dkh7l9a4sx7zqh8riqbj3z21sz25p8xy-bash-4.4-p23/bin/sh"
/nix/store/m4dbxdbggxsa90m9w6zqyp1kph1qfy0b-groonga-8.0.5/share/groonga/examples/dictionary/edict/edict-import.sh: interpreter directive changed from "/bin/sh" to "/nix/store/dkh7l9a4sx7zqh8riqbj3z21sz25p8xy-bash-4.4-p23/bin/sh"
/nix/store/m4dbxdbggxsa90m9w6zqyp1kph1qfy0b-groonga-8.0.5/sbin/groonga-httpd-restart: interpreter directive changed from "/bin/sh" to "/nix/store/dkh7l9a4sx7zqh8riqbj3z21sz25p8xy-bash-4.4-p23/bin/sh"
checking for references to /build in /nix/store/m4dbxdbggxsa90m9w6zqyp1kph1qfy0b-groonga-8.0.5...
moving /nix/store/m4dbxdbggxsa90m9w6zqyp1kph1qfy0b-groonga-8.0.5/sbin/* to /nix/store/m4dbxdbggxsa90m9w6zqyp1kph1qfy0b-groonga-8.0.5/bin
running install tests
Groonga 8.0.5 [linux-gnu,x86_64,utf8,match-escalation-threshold=0,nfkc,mecab,onigmo,epoll]

configure options: < '--disable-static' '--disable-dependency-tracking' '--prefix=/nix/store/m4dbxdbggxsa90m9w6zqyp1kph1qfy0b-groonga-8.0.5' 'CC=gcc' 'CXX=g++' 'PKG_CONFIG_PATH=/nix/store/n3x8v9yc3sczi4wf23x03g0vbgmi9pak-kytea-0.4.7/lib/pkgconfig:/nix/store/g5bpi4farlcdlyxy741785k3pym0sh56-libedit-20180525-3.1-dev/lib/pkgconfig:/nix/store/i1lyv0v01z1ivndra433kvmaagfhlmym-ncurses-6.1-dev/lib/pkgconfig'>

Success on aarch64-linux (full log)
Attempted: groonga
Partial log (click to expand)
/nix/store/17qrrkv8v9bzyi8vyafgx5gjb90dj4cx-groonga-8.0.5/share/groonga/examples/dictionary/gene95/gene-import.sh: interpreter directive changed from "/bin/sh" to "/nix/store/6vqgi9d49smsbr2qxra52yhipg0yxf9f-bash-4.4-p23/bin/sh"
/nix/store/17qrrkv8v9bzyi8vyafgx5gjb90dj4cx-groonga-8.0.5/share/groonga/examples/dictionary/eijiro/eijiro-import.sh: interpreter directive changed from "/bin/sh" to "/nix/store/6vqgi9d49smsbr2qxra52yhipg0yxf9f-bash-4.4-p23/bin/sh"
/nix/store/17qrrkv8v9bzyi8vyafgx5gjb90dj4cx-groonga-8.0.5/share/groonga/examples/dictionary/edict/edict-import.sh: interpreter directive changed from "/bin/sh" to "/nix/store/6vqgi9d49smsbr2qxra52yhipg0yxf9f-bash-4.4-p23/bin/sh"
checking for references to /build in /nix/store/17qrrkv8v9bzyi8vyafgx5gjb90dj4cx-groonga-8.0.5...
moving /nix/store/17qrrkv8v9bzyi8vyafgx5gjb90dj4cx-groonga-8.0.5/sbin/* to /nix/store/17qrrkv8v9bzyi8vyafgx5gjb90dj4cx-groonga-8.0.5/bin
running install tests
Groonga 8.0.5 [linux-gnu,aarch64,utf8,match-escalation-threshold=0,nfkc,mecab,onigmo,epoll]

configure options: < '--disable-static' '--disable-dependency-tracking' '--prefix=/nix/store/17qrrkv8v9bzyi8vyafgx5gjb90dj4cx-groonga-8.0.5' 'CC=gcc' 'CXX=g++' 'PKG_CONFIG_PATH=/nix/store/cyxz212csra7fyv3w8ivwydfd20lbyaj-kytea-0.4.7/lib/pkgconfig:/nix/store/ax66081iaxh9n7pl6pcb7ikli2fq7wbi-libedit-20180525-3.1-dev/lib/pkgconfig:/nix/store/y9f291dmk3al90acl7v39l8h0dcc0bv1-ncurses-6.1-dev/lib/pkgconfig'>
/nix/store/17qrrkv8v9bzyi8vyafgx5gjb90dj4cx-groonga-8.0.5


Missing nimble file

Looks like the nimble file was deleted in https://github.com/ephja/nim-glfw/commit/7ad43b053b2d36e60b93787a74602c21da0d2066
Was it intentional?
The package is still listed in https://github.com/nim-lang/packages/ and the last version tagged ( 0.2.1 ) is still installable.

It was not intentional. I've re-added it. Thanks.


SwiftPM support. Dropped carthage to simplify conversion.

This is usually my .gitignore for SPMs (it's Github default one, removing Xcodeprojs and workspaces, you may want to keep xcodeproj and workspace because of the example app):
# Xcode
#
# gitignore contributors: remember to update Global/Xcode.gitignore, Objective-C.gitignore & Swift.gitignore

## User settings
xcuserdata/

## compatibility with Xcode 8 and earlier (ignoring not required starting Xcode 9)
*.xcscmblueprint
*.xccheckout

## compatibility with Xcode 3 and earlier (ignoring not required starting Xcode 4)
build/
DerivedData/
*.moved-aside
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3

## Obj-C/Swift specific
*.hmap

## App packaging
*.ipa
*.dSYM.zip
*.dSYM

## Playgrounds
timeline.xctimeline
playground.xcworkspace

# Swift Package Manager
#
# Add this line if you want to avoid checking in source code from Swift Package Manager dependencies.
Packages/
Package.pins
Package.resolved
*.xcodeproj
#
# Xcode automatically generates this directory with a .xcworkspacedata file and xcuserdata
# hence it is not needed unless you have added a package configuration file to your project
.swiftpm

.build/

# CocoaPods
#
# We recommend against adding the Pods directory to your .gitignore. However
# you should judge for yourself, the pros and cons are mentioned at:
# https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control
#
# Pods/
#
# Add this line if you want to avoid checking in source code from the Xcode workspace
# *.xcworkspace

# Carthage
#
# Add this line if you want to avoid checking in source code from Carthage dependencies.
# Carthage/Checkouts

Carthage/Build/

# Accio dependency management
Dependencies/
.accio/

# fastlane
#
# It is recommended to not store the screenshots in the git repo.
# Instead, use fastlane to re-generate the screenshots whenever they are needed.
# For more information about the recommended setup visit:
# https://docs.fastlane.tools/best-practices/source-control/#source-control

fastlane/report.xml
fastlane/Preview.html
fastlane/screenshots/**/*.png
fastlane/test_output

# Code Injection
#
# After new code Injection tools there's a generated folder /iOSInjectionProject
# https://github.com/johnno1962/injectionforxcode

iOSInjectionProject/

For gitignore, SPM also creates an appropriate gitignore file when you run
swift package init/create in the directory.


Integration with monolog reporting errors of all levels

Greetings to you all.
I have a problem with integration with monolog. It logs all levels of errors and changing the configuration doesn't help.
Repro steps:

Followed this tutorial to the letter: https://github.com/getsentry/sentry-symfony#installation
Special attention to this

// monolog.yaml

sentry:
  type: service
  id: sentry.monolog.handler
  level: error

Added this to my test controller:

public function testMonolog(LoggerInterface $logger)
{
  $logger->error('test');
  return $this->json('ok');
}

Expected behavior
To receive Error with message 'test'
Real behavior
Received following errors:

Populated the TokenStorage with an anonymous Token.
Matched route "{route}".
Error 'test'

The issue is that the Monolog handler just forwards everything to the captureEvent method while an error that gets catched by the error handler is first passed through the ErrorHandlerIntegration and FatalErrorHandlerIntegration that filter out it according to the error_types option. I'm not sure about the approach we want to take here, but here some solutions I have in mind (didn't check whether they are possible or not):

Duplicate the code that filter out the errors to report into the Monolog handler
Move the code that does the check against the error_types option from the *HandlerIntegration classes into the Client::capture* methods instead

@gliba008 You might want to check https://github.com/B-Galati/monolog-sentry-handler. There is a Symfony guide that could help you with your setup and long running process.

I can confirm this issue as well. Regardless of the level you set in section https://github.com/getsentry/sentry-symfony#step-3-configure-the-sdk, the level is always set to Logger::DEBUG in the Handler.
I mitigated this by setting the level parameter thourgh symfony DI
  sentry.monolog.handler:
    class: Sentry\Monolog\Handler
    arguments:
      $level: 'error'

Also the example for setting the handler seems to be missing the handler section
monolog:
    handler:
        sentry:
          type: service
          id: sentry.monolog.handler
          level: error #this gets ignored

IMHO it is an issue that should be reported to symfony/monolog-bundle.
It looks to be a normal behavior that service handler ignores configuration level provided in monolog bundle config as it cannot guess how to use this level value in the provided service.
@lyrixx Would you know if I am right or wrong?

Also, it is a duplicate of getsentry/sentry-symfony#229

@lyrixx Would you know if I am right or wrong?

you are right

Thanks @lyrixx. Closing this then, please open a dedicated issue in the monolog bundle and cross reference here for future readers.


pg_catalog in search_path causes error in completion.

if "search_path" contains schema "pg_catalog" application may crash.
File "/home/ubuntu/tmp/env/local/lib/python2.7/site-packages/pgcli/pgcompleter.py", line 199, in get_completions suggestion['schema'], 'tables')
File "/home/ubuntu/tmp/env/local/lib/python2.7/site-packages/pgcli/pgcompleter.py", line 268, in populate_schema_objects for obj in metadata[schema].keys()]
KeyError: u'pg_catalog'

@asenyshyn Can you tell me which version of pgcli you're using?
I believe @darikg actually fixed this in one of the previous releases.

Nope :( I can confirm this is a bug, another one I'm responsible for. Will fix tomorrow. Sorry!

This is now fixed in master. Thanks to @darikg.
You can install directly from master using the following command to check it out.
pip install -U -e git+https://github.com/amjith/pgcli.git#egg=pgcli

I'm planning to do a release sometime this weekend, so you should be able to upgrade directly from PyPI at that time.


LESQ-1010 style: wrap development stages

Description
Music year: 1968

Wrap development stages so they don't increase the page size.

Issue(s)
Fixes #
How to test

Go to https://deploy-preview-2671--oak-web-application.netlify.thenational.academy
Click on ______
You should see ______

Screenshots
How it used to look (delete if n/a):
{screenshots}

How it should now look:
{screenshots}

Checklist

[ ] Added or updated tests where appropriate
[ ] Manually tested across browsers / devices
[ ] Considered impact on accessibility
[ ] Design sign-off
[ ] Approved by product owner
[ ] Does this PR update a package with a breaking change

:tada: This PR is included in version 1.504.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Better classnames for development mode

At the moment the classnames are mangled into base64 hash or something:
e.g.
class="sc-jAaTju kAxljF sc-bdVaJa iHZvIS"

It would be nice to somehow allow rebass to pass the folder_file_componentName:base64 for development mode. The same as how css-loader does it.

This isn't something rebass has control over, it's the responsibility of the underlying styling library being used, be it either styled-components or emotion.
Both of those projects have options you can configure to enable contextual CSS class names. For emotion you would add the babel plugin and enable the autoLabel flag: https://github.com/emotion-js/emotion/tree/master/packages/babel-plugin-emotion

@johnmcdowall babel-plugin-styled-components seems to work for styled-components but not rebass components. Is their anything for rebass as well?

@MartinDawson Ah, I'm not sure about how to get the built in Rebass components to have their DisplayNames used as classes. Again though, pretty sure this isn't anything to do with Rebass, but styled-components. You might want to ask over there as well.

@johnmcdowall if you transpile via babel, add the babel-plugin-styled-components plugin to your list
Otherwise, this can be achieved by the end developer via "including" rebass in your babel-loader regex or whatnot in conjunction with babel-plugin-styled-components.

@probablyup I'm not sure I follow - wouldn't rebass already be available to babel-loader by virtue of being in node_modules?

@johnmcdowall the recommended config for babel-loader is to entirely exclude node_modules, so probably not for most projects.

@probablyup Ah, right yes - total brainfart moment. FWIW I am using emotion with rebass and adding it didn't do anything for me (more than likely because emotion's autoLabel works differently than `styled-components), but maybe your solution will help @MartinDawson.

Hopefully the next major version of Rebass works a little better with CSS-in-JS library tooling, but there's probably not much I can do to accommodate this in the current version, so closing this out

Has there been any movement on this? I'm on the newest versions of Rebass and Emotion, and I have not been able to crack this. autoLabel is working fine when I import { css } from '@emotion/core' manually, but none of the styles that go through Rebass get anything added to their CSS classes.
It seems that babel-plugin-emotion and its configuration just isn't affecting Rebass component CSS classes at all.
I attempted including node_modules/rebass in my babel-loader rule, but that seems to have no effect.

@baddox I'm interesting to see if I can help out with this. Do you have any code to share for others to take a look?

@clarkkozak Thanks for reaching out! Here's a fairly minimal example with a fresh ejected create-react-app: https://github.com/baddox/rebass-emotion-autolabel
Here's the important commit: https://github.com/baddox/rebass-emotion-autolabel/commit/0fbfc9181970cdb98bfae9ace855fd1757cb43d8
When you npm run start you can see:

The section which uses Emotion's css prop gets the CSS classes with my autoLabel configuration.
But the section which uses Rebass components and style props gets the default Emotion CSS classes.

Let me know if there's something else I can provide. Hopefully I'm just missing something silly!

@baddox I believe your code demonstrates what is the desired output and what is the immediate issue. Well done!
Seems like this has been mentioned to the emotion team as well:
https://github.com/emotion-js/emotion/issues/756
The issue above suggests a way to create a solid headstart on where a PR could be made to make sure that the autoLabel feature can work for rebass components. Due to the nature of abstracting components, it may be quite the undertaking.
Maybe even a fork of babel-plugin-emotion to babel-plugin-rebass? I'm unsure. I'm still learning this system. I'm here because wanted to see how good code is maintained, and perhaps I could help
@jxnblk and anyone else; please correct me if I'm wrong about anything.


Remove query params and product ID from span names

Changes

adds a transform processor to the collector trace pipeline
adds two rules for transforming span names:

Strip anything after a "?"
Replace productID with a token in "GET /api/products/{productID}" spans

Merge Requirements
For new features contributions please make sure you have completed the following
essential items:

[ ] CHANGELOG.md updated to document new feature additions
[ ] Appropriate documentation updates in the [docs][]
[ ] Appropriate Helm chart updates in the [helm-charts][]

We should add a changelog for this


treat rejected m-lines in offers properly

partial fix for #89
However, this will lead to errors if that m-line is ever reactivated so there is more here that needs to be done. (also, rejecting an active m-line should stop senders etc)

Codecov Report

Merging #90 into master will increase coverage by 0.19%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #90      +/-   ##
==========================================
+ Coverage   97.54%   97.74%   +0.19%
==========================================
  Files           1        1
  Lines         816     1064     +248
==========================================
+ Hits          796     1040     +244
- Misses         20       24       +4

Impacted Files
Coverage Δ

rtcpeerconnection.js
97.74% <100%> (+0.19%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a825846...4874d2d. Read the comment docs.

published as 1.2.9


Cannot deploy on Heroku clicking on "Deploy to Heroku"

Describe the bug
Cannot deploy on Heroku clicking on "Deploy to Heroku"
To Reproduce
Steps to reproduce the behavior:

Click on the button "Deploy to Heroku"
Check app logs on Heroku

Expected behavior
Run pREST instance on Heroku
Desktop (please complete the following information):

pREST version (or commit ref): b754fe35477f37744
pREST endpoint: -
PostgreSQL version: heroku default
OS: [e.g. Debian Tid]: heroku default
Go version: -
Log gist: -

Additional context
2021-03-29T19:46:11.993537+00:00 heroku[web.1]: State changed from starting to crashed
2021-03-29T19:46:11.996956+00:00 heroku[web.1]: State changed from crashed to starting
2021-03-29T19:46:13.364773+00:00 heroku[web.1]: Starting process with command `/app/prestd`
2021-03-29T19:46:15.905975+00:00 app[web.1]: Waiting for port : to become available...
2021-03-29T19:46:20.902755+00:00 app[web.1]: Ready hosting  to port  !
2021-03-29T19:46:20.945056+00:00 app[web.1]: Error: unknown command "/app/prestd" for "prest"
2021-03-29T19:46:20.945087+00:00 app[web.1]: Run 'prest --help' for usage.
2021-03-29T19:46:20.945121+00:00 app[web.1]: unknown command "/app/prestd" for "prest"
2021-03-29T19:46:21.028077+00:00 heroku[web.1]: Process exited with status 255
2021-03-29T19:46:21.126340+00:00 heroku[web.1]: State changed from starting to crashed

Thank you very much @avelino.
I will make a deployment right now


MacOS: Failed to apply 'viewport' patch

Unfortunately, hephaistos fails to apply the patch on my Macbook.
I moved hephaistos to /Users/marcel/Library/Application Support/Steam/steamapps/common/Hades:
~/Library/Application Support/Steam/steamapps/common/Hades
❯ ll
total 6.9M
drwxr-xr-x 3 marcel staff   96 Apr  7 21:18 Game.macOS.app
drwxr-xr-x 4 marcel staff  128 Apr  8 18:55 hephaistos-data
-rwxr-xr-x 1 marcel staff 6.9M Feb 28 16:29 hephaistos

I executed the patching process in this directory using ./hephaistos.
The log I get from the Terminal:
Hi! This interactive wizard will help you to set up Hephaistos.
Note: while Hephaistos can be used in interactive mode for basic usage, you will need to switch to non-interactive mode for any advanced usage. See the README for more details.

Current version: v1.6.3
Latest version: could not check latest version -- perhaps no Internet connection is available?

Pick an option:
1. Patch Hades using Hephaistos
2. Restore Hades to its pre-Hephaistos state
3. Check current Hades / Hephaistos status
4. Exit
Choice: 1

Pick an option:
1. Select from common 21:9 resolutions
2. Select from common 32:9 resolutions
3. Select from common 48:9 / triple screen resolutions
4. Input resolution manually
5. Cancel
Choice: 2

Select resolution:
1. 3840 x 1080
2. 5120 x 1440
3. Cancel
Choice: 2

Select HUD preference (for 32:9, try out both options and see what you prefer!):
1. Expand HUD horizontally (recommended for 21:9)
2. Keep HUD in the center (recommended for 48:9 / triple screen)
3. Cancel
Choice: 2

INFO:hephaistos:Using resolution: (5120, 1440)
INFO:hephaistos:Using '--scaling=hor+': computed patch viewport (3840, 1080)
INFO:hephaistos:Using '--hud=center': HUD will be kept in the center of the screen
ERROR:hephaistos:Failed to apply 'viewport' patch in 'Game.macOS.app/Contents/MacOS/Game.macOS' (no occurrences found)

I checked the printed directory Game.macOS.app/Contents/MacOS/Game.macOS and the Game.macOS file is present.

Hey, probably the MacOS binary structure has changed since the last time I had a look at it, and so the hex patches need to be updated. I will try to have a look this weekend.

Do you have a Discord handle I could add you at? That would speed up the testing :)

Do you have a Discord handle I could add you at? That would speed up the testing :)

Yes, feel free to contact me: Cliff#3526

Added! Feel free to remove your comment if you don't want to keep it advertised here :)

This should be fixed by eb6e687183247f3e0be7d9c500fb3c436fef5ee2, test build here:
hephaistos-macos.zip

Release in v1.6.4.


The Many Flavours of WMI Post

PR Summary
post_title: The many flavours of WMI management
username: FranciscoNabas
categories: PowerShell
tags: PowerShell, WMI, .NET, COM, Windows Management
summary: Working with the different ways of managing WMI.
PR Checklist

Do you want this post to be published on a specific date?: Y/N [Specify date]: N
[X] I have read the contributors guide and followed the style and process guidelines
[X] PR has a meaningful title
[ ] Includes content related an open issue

see Closing issues using keywords.

[X] This PR is ready to merge and is not Work in Progress

@FranciscoNabas I don't see any changed files in this PR.


Support qEI

In cases where the cost of n parallelized f()'s is lower than that of n sequential f()'s, the acquisition function u() can return q>1 points and the next evaluation of f()'s can take place at q points simultaneously. One such acquisition function, the multi-points expected improvements a.k.a. qEI(), have been studied in "Kriging is well-suited to parallelize optimization", "Fast Computation of the Multi-Points Expected Improvement with Applications in Batch Selection", "Bayesian Optimization with Gradients", etc. Some implementations exist in the R package DiceOptim.
It would be nice if the project incorporates this feature in its design, especially in its "Bayesian optimization loop".

Related to #343 Might make sense to move the discussion/literature search here and keep the PR thread for discussing the code.

I see. Here are some papers in chronological order:
Kriging is well-suited to parallelize optimization [https://www.researchgate.net/publication/226716412_Kriging_Is_Well-Suited_to_Parallelize_Optimization](Ginsbourger 10). Proposes Monte-Carlo method, and also provided Kriging Believer (KB) and Constant Liar (CL) heuristics.
Fast Computation of the Multi-Points Expected Improvement with Applications in Batch Selection  [https://www.researchgate.net/publication/258831560_Fast_Computation_of_the_Multi-Points_Expected_Improvement_with_Applications_in_Batch_Selection](Chevalier 12). Provides an analytical formula, which is only suitable for smaller values of q.
Parallel Bayesian Global Optimization of Expensive Functions [https://arxiv.org/abs/1602.05149](Wang 16). Uses an unbiased gradient estimator.
Bayesian Optimization with Gradients [https://arxiv.org/abs/1703.04389](Wu 17). Improves (Wang 16).
I'd also like to point out that a package, https://github.com/Yelp/MOE, implements KB, CL, and (Wang 16) in C++, and provides a python interface, and is forked by (Wu 17) for his implementation. However, it's not well structured, and quite difficult to specify a custom kernel function.

I see. here are some papers:
https://www.researchgate.net/publication/226716412_Kriging_Is_Well-Suited_to_Parallelize_Optimization (MC, Kriging Believer, Constant Liar)
https://www.researchgate.net/publication/258831560_Fast_Computation_of_the_Multi-Points_Expected_Improvement_with_Applications_in_Batch_Selection (Analytical Formula)
https://arxiv.org/abs/1602.05149 (gradient)
I'd also like to point out that, https://github.com/Yelp/MOE, a C++ package with python interface, implements MC, KB, CL, and gradient. However, it's not as well structured, and is quite difficult to customize a kernel function.

Thanks for those! For people not so deep into the parallel global optimisation jargon:

CL = constant liar
gradient = knowledge gradient
MC = ??
KB = kriging believer

Non paywalled versions:
Kriging Is Well Suited to Parallelize Optimization

MC = monte carlo


Bump haskell.nix.

We need input-output-hk/haskell.nix@50fd86f249767e8e210e2635ad0967fe001b6221 for CI of plutus-starter

Please avoid squash/rebase merge if possible, I'd like this commit in the repo with the parent it currently has.

Yep. Will merge this when it's all green