WIP: custom platform properties

See original merge request on GitLab
In GitLab by [Gitlab user @tpollard] on Nov 6, 2020, 16:55
This is related to https://gitlab.com/BuildStream/buildstream/-/issues/1313
In short, there are remote-exection usecases where server/worker implementations may incorporate custom/additional platform properties, or choose not to implement all/any of the 'optional' standard properties, as defined by the platform message lexicon:
https://github.com/bazelbuild/remote-apis/blob/master/build/bazel/remote/execution/v2/platform.md

[x] Add tests (probably excessive running the full set of tests against multiple platform configurations?)
[ ] Add validation type filtering (no nesting etc)
[ ] Add support for multi value properties (i.e, ISA which needs support adding already even without this MR)
[ ] Cache Key considerations (when changing default properties which have previously constituted get_unique_key() for the sandbox config)

This branch is being exercised with this remote-apis-testing MR https://gitlab.com/remote-apis-testing/remote-apis-testing/-/merge_requests/192

In GitLab by [Gitlab user @tpollard] on Nov 6, 2020, 16:56
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 6, 2020, 16:56
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 13:06
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 13:06
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 13:13
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 13:13
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 13:14
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 13:14
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 15:21
added 1 commit
7eee7ea7 - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 15:21
added 1 commit
7eee7ea7 - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 15:42
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 15:42
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 15:50
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 15:50
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 15:50
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 15:50
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 16:01
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 16:01
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 16:02
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 16:02
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 16:02
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 16:02
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 16:04
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 9, 2020, 16:04
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 10, 2020, 12:54
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 10, 2020, 12:54
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 10, 2020, 13:44
added 1 commit
b6f2f26a - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 10, 2020, 13:44
added 1 commit
b6f2f26a - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 10, 2020, 13:55
added 1 commit
6fef601e - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 10, 2020, 13:55
added 1 commit
6fef601e - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 10, 2020, 14:07
added 1 commit
60e5903b - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 10, 2020, 14:07
added 1 commit
60e5903b - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 10, 2020, 16:49
added 1 commit
def5d301 - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 10, 2020, 16:49
added 1 commit
def5d301 - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 10, 2020, 16:50
marked the task Add tests (expand remote_services fixture?) as completed

In GitLab by [Gitlab user @tpollard] on Nov 10, 2020, 16:50
marked the task Add tests (expand remote_services fixture?) as completed

In GitLab by [Gitlab user @tpollard] on Nov 10, 2020, 16:50
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 10, 2020, 16:50
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 10, 2020, 17:36
added 1 commit
fee056bd - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 10, 2020, 17:36
added 1 commit
fee056bd - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 11:04
added 1 commit
36766aba - Try with without a custom property
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 11:04
added 1 commit
36766aba - Try with without a custom property
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 11:15
added 14 commits
945cbba5 - _loader/loader.py: Avoid double dictionary lookupa90de781 - _loader/loader.py: Fix _load_file() for cross project link element loads.eeb2ab18 - _loader/loader.py: Fixing new pylint "no-member" error8e0e4702 - get release and snapshot badges from docs websitec225ff50 - testutils/platform: Refactor to be compatible with Python 3.953b9590d - _loader/loader.py: Support overriding elements93d62dfa - tests/format/junctions.py: Testing element override scenariosb19107ad - plugins/elements/junction.py: Documenting element overrides.2afa8f0c - _stream.py: Make `_enqueue_plan` a timed activity86fd33de - tox.ini/.gitlab-ci.yml: Add test environment for Python 3.9c5a35e66 - NEWS/setup.py: Advertise our support for Python 3.9b2785e50 - src/buildstream/element.py: __use_remote_execution() reword desc9b2e0005 - WIP custom platform propertiese8210fba - try debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 11:15
added 14 commits
945cbba5 - _loader/loader.py: Avoid double dictionary lookupa90de781 - _loader/loader.py: Fix _load_file() for cross project link element loads.eeb2ab18 - _loader/loader.py: Fixing new pylint "no-member" error8e0e4702 - get release and snapshot badges from docs websitec225ff50 - testutils/platform: Refactor to be compatible with Python 3.953b9590d - _loader/loader.py: Support overriding elements93d62dfa - tests/format/junctions.py: Testing element override scenariosb19107ad - plugins/elements/junction.py: Documenting element overrides.2afa8f0c - _stream.py: Make `_enqueue_plan` a timed activity86fd33de - tox.ini/.gitlab-ci.yml: Add test environment for Python 3.9c5a35e66 - NEWS/setup.py: Advertise our support for Python 3.9b2785e50 - src/buildstream/element.py: __use_remote_execution() reword desc9b2e0005 - WIP custom platform propertiese8210fba - try debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 11:26
added 1 commit
c66aab73 - try debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 11:26
added 1 commit
c66aab73 - try debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 11:36
added 1 commit
3f9c075b - try debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 11:36
added 1 commit
3f9c075b - try debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 11:50
added 22 commits
3f9c075b...f6ee38f5 - 20 commits from branch master166bff5a - WIP custom platform propertiesf9798863 - Add debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 11:50
added 22 commits
3f9c075b...f6ee38f5 - 20 commits from branch master166bff5a - WIP custom platform propertiesf9798863 - Add debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 12:01
added 1 commit
82dc448a - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 12:01
added 1 commit
82dc448a - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 12:23
added 1 commit
6d463fe2 - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 12:23
added 1 commit
6d463fe2 - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 12:44
added 1 commit
8d087fe2 - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 12:44
added 1 commit
8d087fe2 - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 13:03
added 2 commits
994f9f7e - WIP custom platform properties6a92ec5a - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 13:03
added 2 commits
994f9f7e - WIP custom platform properties6a92ec5a - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 13:22
added 2 commits
3ed9d44d - WIP custom platform propertiesffb45e7e - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 13:22
added 2 commits
3ed9d44d - WIP custom platform propertiesffb45e7e - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 13:36
added 1 commit
39b48ae2 - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 13:36
added 1 commit
39b48ae2 - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 13:50
added 1 commit
c4460bae - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 13:50
added 1 commit
c4460bae - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 14:04
added 1 commit
6596a062 - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 14:04
added 1 commit
6596a062 - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 14:19
added 1 commit
69d0daf1 - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 14:19
added 1 commit
69d0daf1 - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 14:37
added 1 commit
69dc3dea - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 14:37
added 1 commit
69dc3dea - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 14:50
added 1 commit
6b981693 - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 14:50
added 1 commit
6b981693 - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 15:12
added 1 commit
5b0a660d - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 15:12
added 1 commit
5b0a660d - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 15:56
added 1 commit
38a1d2aa - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 15:56
added 1 commit
38a1d2aa - Add some debug
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 16:13
added 1 commit
5591e4e2 - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 16:13
added 1 commit
5591e4e2 - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 16:28
added 1 commit
675a70db - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 11, 2020, 16:28
added 1 commit
675a70db - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 13:00
mentioned in merge request remote-apis-testing/remote-apis-testing!161

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 13:00
mentioned in merge request remote-apis-testing/remote-apis-testing!161

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 13:19
added 1 commit
36b09064 - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 13:19
added 1 commit
36b09064 - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 13:34
added 1 commit
2cf4846f - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 13:34
added 1 commit
2cf4846f - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 13:47
added 1 commit
d2a5b844 - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 13:47
added 1 commit
d2a5b844 - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 14:11
added 1 commit
eff1a5cf - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 14:11
added 1 commit
eff1a5cf - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 14:36
added 1 commit
f8c1f193 - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 14:36
added 1 commit
f8c1f193 - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @adds68] on Nov 12, 2020, 14:43
Commented on .gitlab-ci/buildgrid-remote-execution.yml line 36
./server.yml ?

In GitLab by [Gitlab user @adds68] on Nov 12, 2020, 14:43
Commented on .gitlab-ci/buildgrid-remote-execution.yml line 36
./server.yml ?

In GitLab by [Gitlab user @adds68] on Nov 12, 2020, 14:45
resolved all threads

In GitLab by [Gitlab user @adds68] on Nov 12, 2020, 14:45
resolved all threads

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 14:48
added 1 commit
3daa03fa - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 14:48
added 1 commit
3daa03fa - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 15:06
added 1 commit
a7aace94 - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 15:06
added 1 commit
a7aace94 - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 15:14
added 1 commit
bb743fb6 - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 15:14
added 1 commit
bb743fb6 - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 15:38
added 1 commit
39d0c154 - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 15:38
added 1 commit
39d0c154 - Try using custom bgd conf
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 15:52
added 1 commit
24bdad8e - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 15:52
added 1 commit
24bdad8e - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 15:55
The RE tests should now be working with the default properties, with the addition of a custom property and with a default property not set (ISA).

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 15:55
The RE tests should now be working with the default properties, with the addition of a custom property and with a default property not set (ISA).

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 16:02
added 1 commit
474d23f7 - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 16:02
added 1 commit
474d23f7 - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 16:03
added 1 commit
abd19c98 - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 16:03
added 1 commit
abd19c98 - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 16:08
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 12, 2020, 16:08
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 13, 2020, 15:56
mentioned in merge request remote-apis-testing/remote-apis-testing!192

In GitLab by [Gitlab user @tpollard] on Nov 13, 2020, 15:56
mentioned in merge request remote-apis-testing/remote-apis-testing!192

In GitLab by [Gitlab user @tpollard] on Nov 16, 2020, 10:45
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 16, 2020, 10:45
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 16, 2020, 13:37
This is branch now passing the buildstream-buildbarn integration test at https://gitlab.com/remote-apis-testing/remote-apis-testing/-/merge_requests/192

In GitLab by [Gitlab user @tpollard] on Nov 16, 2020, 13:37
This is branch now passing the buildstream-buildbarn integration test at https://gitlab.com/remote-apis-testing/remote-apis-testing/-/merge_requests/192

In GitLab by [Gitlab user @tpollard] on Nov 18, 2020, 10:30
I feel like this implementation needs initial review before working on the remaining hardening

In GitLab by [Gitlab user @tpollard] on Nov 18, 2020, 10:30
I feel like this implementation needs initial review before working on the remaining hardening

In GitLab by [Gitlab user @tpollard] on Nov 18, 2020, 10:45
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 18, 2020, 10:45
changed the description

In GitLab by [Gitlab user @tristanvb] on Nov 20, 2020, 05:12
First pass highlevel API considerations:

Custom platform properties as I understand, must be worker bound and not RE service bound. From the BuildStream perspective, I think it only makes sense to have these configurable at the SandboxConfig level, and not at the project level (a project-wide default can be set for project elements across the board anyway).
Having platform properties configurable only at the project level would preclude use cases where a project requires some elements to be built in some specific environments while others need to be built in different environments (and I think that the ability to build in multiple different environments is one of the more significant value additions which RE brings to the table).

The default-platform-properties approach deserves some discussion.
Ideally, a project author should not have to special case project or element configuration in any was just because the build site has been configured to be connected to an RE service.
The behavior we're looking for is:

If BuildStream is building locally, and if an element requires a platform property which cannot be satisfied by buildbox-run on the local build machine, then BuildStream exits (either early exit, or build everything which can be built, that is a separate discussion).
If BuildStream is building over an RE service, and if no worker on that service can be found with the platform properties required by that element, then that element fails in that build (again, either as early as possible or not, separate concern).

If I understand correctly, default-platform-properties (probably more aptly named as default-platform-requirements) is a set of platform properties that BuildStream core decides to require for element builds on an RE service.
This (iiuc) mostly revolves things like locally discovered machine architecture reported by uname.
I personally do not like having this switch, as we're straying into territory where project authors need to make special considerations only based user configuration, like whether a user decided to build on an RE service or not (if there is project configuration here; it is only advice, user configuration has the last word on details of how to build, project data consists of what to build).
I think it would be more desirable to force the project authors to specify required platform properties more explicitly, rather than have BuildStream core automatically derive anything from the local platform, which has no relation to the platform the project should be built on (if we are running in RE mode, there is no reason to expect the local platform to be relevant at all). If there are platform properties which must absolutely be specified when building on an RE service, then the build can simply fail if the project author failed to specify that platform property requirement.
It is also worth considering how platform properties can be extended. If we have a local boolean switch which says that BuildStream will automatically derive stuff from the local build host, can such automatically required platform properties be extended in a backwards compatible way ? I think not, I think that upgrading to a version of BuildStream which suddenly requires a new platform property automatically, will break cache key stability.

In GitLab by [Gitlab user @tristanvb] on Nov 20, 2020, 05:12
First pass highlevel API considerations:

Custom platform properties as I understand, must be worker bound and not RE service bound. From the BuildStream perspective, I think it only makes sense to have these configurable at the SandboxConfig level, and not at the project level (a project-wide default can be set for project elements across the board anyway).
Having platform properties configurable only at the project level would preclude use cases where a project requires some elements to be built in some specific environments while others need to be built in different environments (and I think that the ability to build in multiple different environments is one of the more significant value additions which RE brings to the table).

The default-platform-properties approach deserves some discussion.
Ideally, a project author should not have to special case project or element configuration in any was just because the build site has been configured to be connected to an RE service.
The behavior we're looking for is:

If BuildStream is building locally, and if an element requires a platform property which cannot be satisfied by buildbox-run on the local build machine, then BuildStream exits (either early exit, or build everything which can be built, that is a separate discussion).
If BuildStream is building over an RE service, and if no worker on that service can be found with the platform properties required by that element, then that element fails in that build (again, either as early as possible or not, separate concern).

If I understand correctly, default-platform-properties (probably more aptly named as default-platform-requirements) is a set of platform properties that BuildStream core decides to require for element builds on an RE service.
This (iiuc) mostly revolves things like locally discovered machine architecture reported by uname.
I personally do not like having this switch, as we're straying into territory where project authors need to make special considerations only based user configuration, like whether a user decided to build on an RE service or not (if there is project configuration here; it is only advice, user configuration has the last word on details of how to build, project data consists of what to build).
I think it would be more desirable to force the project authors to specify required platform properties more explicitly, rather than have BuildStream core automatically derive anything from the local platform, which has no relation to the platform the project should be built on (if we are running in RE mode, there is no reason to expect the local platform to be relevant at all). If there are platform properties which must absolutely be specified when building on an RE service, then the build can simply fail if the project author failed to specify that platform property requirement.
It is also worth considering how platform properties can be extended. If we have a local boolean switch which says that BuildStream will automatically derive stuff from the local build host, can such automatically required platform properties be extended in a backwards compatible way ? I think not, I think that upgrading to a version of BuildStream which suddenly requires a new platform property automatically, will break cache key stability.

In GitLab by [Gitlab user @tpollard] on Nov 23, 2020, 12:05
Hi [Gitlab user @tristanvb] thanks for the initial comments, I'll try and answer where I can:

Custom platform properties as I understand, must be worker bound and not RE service bound.

In terms of Buildgrid, the server also needs to be configured to allow arbitrary/custom properties for jobs before they're assigned to a worker, this MR currently has an example of that using the required config from https://gitlab.com/BuildGrid/buildgrid/-/blob/master/buildgrid/_app/settings/reference.yml#L150 Without BuildStream being able to query the capabilities of a server (which even if it could I don't think it should) I think the remotespec is the correct place for this config.

preclude use cases where a project requires some elements to be built in some specific environments while others need to be built in different environments

I agree, there's definitely usecases where a project could have elements that need to be built on differing workers (for instance, with gpu acceleration present). I suppose one approach to that could be to have specific junctions for specific environments?

I think it would be more desirable to force the project authors to specify required platform properties more explicitly

I wouldn't be against this, but I also can see the view that the current sourcing of 'default properties' is a nice to have. However if a user wants to specify 'custom properties', then I'd be happy if that then superseeded any local decisions bst would normally make (i.e, the user needs to declare all the properties they require if they want to stray from the local defaults). This would be more explicit, and would only require a single new config option.
It is worth considering the complication of cachekeys being a product of these local defaults from the host sandboxconfig (uname etc), if not set by the user/project/element. For instance, this could lead to hashing linux and x86-64 for the key but then ignoring this input data and building remotely with darwin and arm64 as the platform properties with this explicit superseeding without some form of validation against the sanboxconfig values. Not just cachekeys either, this could lead to issues when trying to launch a local sandbox on an artifact that was built remotely without handling the mismatch.

In GitLab by [Gitlab user @tpollard] on Nov 23, 2020, 12:05
Hi [Gitlab user @tristanvb] thanks for the initial comments, I'll try and answer where I can:

Custom platform properties as I understand, must be worker bound and not RE service bound.

In terms of Buildgrid, the server also needs to be configured to allow arbitrary/custom properties for jobs before they're assigned to a worker, this MR currently has an example of that using the required config from https://gitlab.com/BuildGrid/buildgrid/-/blob/master/buildgrid/_app/settings/reference.yml#L150 Without BuildStream being able to query the capabilities of a server (which even if it could I don't think it should) I think the remotespec is the correct place for this config.

preclude use cases where a project requires some elements to be built in some specific environments while others need to be built in different environments

I agree, there's definitely usecases where a project could have elements that need to be built on differing workers (for instance, with gpu acceleration present). I suppose one approach to that could be to have specific junctions for specific environments?

I think it would be more desirable to force the project authors to specify required platform properties more explicitly

I wouldn't be against this, but I also can see the view that the current sourcing of 'default properties' is a nice to have. However if a user wants to specify 'custom properties', then I'd be happy if that then superseeded any local decisions bst would normally make (i.e, the user needs to declare all the properties they require if they want to stray from the local defaults). This would be more explicit, and would only require a single new config option.
It is worth considering the complication of cachekeys being a product of these local defaults from the host sandboxconfig (uname etc), if not set by the user/project/element. For instance, this could lead to hashing linux and x86-64 for the key but then ignoring this input data and building remotely with darwin and arm64 as the platform properties with this explicit superseeding without some form of validation against the sanboxconfig values. Not just cachekeys either, this could lead to issues when trying to launch a local sandbox on an artifact that was built remotely without handling the mismatch.

In GitLab by [Gitlab user @juergbi] on Nov 25, 2020, 08:13
It's overall pretty tricky because the Remote Execution API allows the server implementation a lot of flexibility. I.e., it's underspecified and the servers are not required to support any particular platform property. The reason for this is that RE clients and their (sandboxing) requirements are also quite diverse.
Platform properties are used for a variety of use cases. From OS/ISA selection to sandboxing restrictions, Docker images, hardware requirements and project tagging. The effect of this is that at least in some cases BuildStream as a client will need server-specific 'platform properties'.
I think our aim should be that anything that is not specific to a particular RE server (and thus, is typically also applicable to local builds) is declared in the project or element-level sandbox config and takes part in the cache key calculation.
However, configuration that is truly server-specific should clearly not take part in the cache key calculation and thus belongs in the remote-execution section, in my opinion.
A concern are aspects that are not specific to a particular RE server, however, where the RE server requires non-standard configuration (or standard configuration does not even exist).
I tend towards something like the following:

Support server-specific platform properties in the remote-execution section as in this MR (I'd shorten custom-platform-properties to just platform-properties, though). Also support multi-valued properties by means of YAML lists.
Support overriding platform properties from the sandbox section in the remote-execution section. I.e., let the latter take precedence. However, drop default-platform-properties and require explicit listing of each property to override, reducing the risk of accidentally diverging/skipping configuration. Support e.g. OS: [] (empty YAML list) to unset a property.
Also support custom platform properties in the sandbox section, adding a platform-properties dict (or reapi-platform?). These properties will take part in the cache key calculation and be passed to both buildbox-run and remote execution (unless overridden by server-specific properties).¹ We could defer this until we have a use case for it.
Reject/fail builds that specify platform properties not supported by the local sandbox. For remote execution we can't determine what the server supports, so it's up to the server to reject the action for unsupported platform properties.

¹ A more radical variant would be to simply make sandbox a dict of REAPI platform properties and completely drop BuildStream core logic mangling with platform properties. However, this would definitely have some downsides: not forcing arch/OS values to exist (risk of underspecified cache key), not providing the convenience of inferring the arch/OS from the host (or arch alias), possible problem to enable network and inherit uid for non-isolated bst shell, maybe more.

In GitLab by [Gitlab user @juergbi] on Nov 25, 2020, 08:13
It's overall pretty tricky because the Remote Execution API allows the server implementation a lot of flexibility. I.e., it's underspecified and the servers are not required to support any particular platform property. The reason for this is that RE clients and their (sandboxing) requirements are also quite diverse.
Platform properties are used for a variety of use cases. From OS/ISA selection to sandboxing restrictions, Docker images, hardware requirements and project tagging. The effect of this is that at least in some cases BuildStream as a client will need server-specific 'platform properties'.
I think our aim should be that anything that is not specific to a particular RE server (and thus, is typically also applicable to local builds) is declared in the project or element-level sandbox config and takes part in the cache key calculation.
However, configuration that is truly server-specific should clearly not take part in the cache key calculation and thus belongs in the remote-execution section, in my opinion.
A concern are aspects that are not specific to a particular RE server, however, where the RE server requires non-standard configuration (or standard configuration does not even exist).
I tend towards something like the following:

Support server-specific platform properties in the remote-execution section as in this MR (I'd shorten custom-platform-properties to just platform-properties, though). Also support multi-valued properties by means of YAML lists.
Support overriding platform properties from the sandbox section in the remote-execution section. I.e., let the latter take precedence. However, drop default-platform-properties and require explicit listing of each property to override, reducing the risk of accidentally diverging/skipping configuration. Support e.g. OS: [] (empty YAML list) to unset a property.
Also support custom platform properties in the sandbox section, adding a platform-properties dict (or reapi-platform?). These properties will take part in the cache key calculation and be passed to both buildbox-run and remote execution (unless overridden by server-specific properties).¹ We could defer this until we have a use case for it.
Reject/fail builds that specify platform properties not supported by the local sandbox. For remote execution we can't determine what the server supports, so it's up to the server to reject the action for unsupported platform properties.

¹ A more radical variant would be to simply make sandbox a dict of REAPI platform properties and completely drop BuildStream core logic mangling with platform properties. However, this would definitely have some downsides: not forcing arch/OS values to exist (risk of underspecified cache key), not providing the convenience of inferring the arch/OS from the host (or arch alias), possible problem to enable network and inherit uid for non-isolated bst shell, maybe more.

In GitLab by [Gitlab user @tpollard] on Nov 25, 2020, 15:54
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 25, 2020, 15:54
changed the description

In GitLab by [Gitlab user @tpollard] on Nov 26, 2020, 10:24
added 11 commits
abd19c98...19a450c3 - 10 commits from branch masterb32ef1d4 - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 26, 2020, 10:24
added 11 commits
abd19c98...19a450c3 - 10 commits from branch masterb32ef1d4 - WIP custom platform properties
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 26, 2020, 14:52
added 1 commit
45e36db6 - Remove  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 26, 2020, 14:52
added 1 commit
45e36db6 - Remove  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 26, 2020, 16:45
added 1 commit
e1449829 - Remove  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 26, 2020, 16:45
added 1 commit
e1449829 - Remove  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 09:46
added 1 commit
3c149b3b - Remove  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 09:46
added 1 commit
3c149b3b - Remove  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 10:23
added 1 commit
dc5fbd35 - Remove  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 10:23
added 1 commit
dc5fbd35 - Remove  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 12:25
added 1 commit
e770509b - Remove  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 12:25
added 1 commit
e770509b - Remove  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 13:20
added 1 commit
1303bc1b - Remove 'default-platform-properties'  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 13:20
added 1 commit
1303bc1b - Remove 'default-platform-properties'  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 14:19
added 1 commit
1c3bc0a5 - Remove 'default-platform-properties'  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 14:19
added 1 commit
1c3bc0a5 - Remove 'default-platform-properties'  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 14:43
added 1 commit
f521c49c - Remove 'default-platform-properties'  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 14:43
added 1 commit
f521c49c - Remove 'default-platform-properties'  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 15:12
added 1 commit
b3d1c275 - Remove 'default-platform-properties'  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 15:12
added 1 commit
b3d1c275 - Remove 'default-platform-properties'  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 15:27
added 1 commit
555d0289 - Remove 'default-platform-properties'  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 15:27
added 1 commit
555d0289 - Remove 'default-platform-properties'  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 15:46
added 1 commit
7c401da9 - Remove 'default-platform-properties'  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 15:46
added 1 commit
7c401da9 - Remove 'default-platform-properties'  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 15:47
added 1 commit
8d466373 - Remove 'default-platform-properties'  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 15:47
added 1 commit
8d466373 - Remove 'default-platform-properties'  and reduce scope
Compare with previous version

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 16:35
[Gitlab user @juergbi]
I've added a commit (will squash and tidy etc after agreement/code review ofc) which drops the default-platform-properties bool, changing custom-platform-properties to platform-properties, and allowing that as an entry point to explicitly disable any locally derived sandbox 'default' platform properties by providing a value of [] as suggested.
If one of the 'default' properties is passed via this config option, providing a value which is anything other than [] will not be accepted and a related SandBoxError is raised (there's also a new test for this). If we limit changing the values of these properties (OSFamily, ISA etc. Those that are not specific/custom to the remote server) to sandbox config, then it ensures the true value will be part of the cache key, and match reality when using the config locally (important when trying to launch a local sandbox on an element that may have been built remotely on an isa/os that is not supported locally). When launching a remote sandbox the capabilities of the local sandbox are also not assessed pre-preemptively, so this means we won't wrongly block remote builds when buildbox locally is limited to the host environment which does not match the remote executor.
What do you think? (There's obviously a few things left to implement, like allowing properties to have list values and preventing nested dicts in the yaml, etc)

In GitLab by [Gitlab user @tpollard] on Nov 27, 2020, 16:35
[Gitlab user @juergbi]
I've added a commit (will squash and tidy etc after agreement/code review ofc) which drops the default-platform-properties bool, changing custom-platform-properties to platform-properties, and allowing that as an entry point to explicitly disable any locally derived sandbox 'default' platform properties by providing a value of [] as suggested.
If one of the 'default' properties is passed via this config option, providing a value which is anything other than [] will not be accepted and a related SandBoxError is raised (there's also a new test for this). If we limit changing the values of these properties (OSFamily, ISA etc. Those that are not specific/custom to the remote server) to sandbox config, then it ensures the true value will be part of the cache key, and match reality when using the config locally (important when trying to launch a local sandbox on an element that may have been built remotely on an isa/os that is not supported locally). When launching a remote sandbox the capabilities of the local sandbox are also not assessed pre-preemptively, so this means we won't wrongly block remote builds when buildbox locally is limited to the host environment which does not match the remote executor.
What do you think? (There's obviously a few things left to implement, like allowing properties to have list values and preventing nested dicts in the yaml, etc)


KAFKA-12701: Remove topicId from MetadataReq since it was not supported in 2.8.0

More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
#9622 add topicId in MetadataResponse and MetadataRequest, but describe topic using topicId is supported by #9769
sadly #9622 PR was merged but #9769 PR was held off, for more details: https://github.com/apache/kafka/pull/9769#issuecomment-772830472
I think this is a bug so we should fix this for 2.8.0.
This PR should be cherry-picked to 2.8.0.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@dengziming : We probably can't remove a field from an existing protocol without changing the version. Otherwise, the client will be confused on the exact protocol for a particular version. We could bump up the version (keeping all the fields the same) in 3.0 and implement the functionality for topicId there. For 2.8, we probably want to at least document in the protocol that topicId is not supported.

@dengziming. I should have paid attention. I just saw this. I opened https://github.com/apache/kafka/pull/10584

Thank you @junrao @jolshan , move to #10584


Relax Cabal-Version to >= 1.10 and add Setup.hs (cabal check warning)

Cabal-Version: >=1.10 is a good default to use, cabal check warns if it needs to be constrained. This makes the library buildable on a default GHC-7.0 install.

Thank you!  This is up on Hackage as index-core-1.0.2


[SPARK-18161] [Python] Allow pickle to serialize >4 GB objects when possible (Python 3.4+)

What changes were proposed in this pull request?
Since pickle protocol 4 (available in Python 3.4+) allows for serialization of > 4 GB errors, use pickle protocol 4 when available in the Broadcast and PickleSerializer classes.
How was this patch tested?
This was tested through pyspark shell and serializing a large numpy array with / without the changes.
Author: Sloane Simmons
This contribution is my original work and I license the work to the project under the project's open source license.

Can one of the admins verify this patch?

cc @davies

Do we plan to move this forward? Do you have the time to update this @singularperturbation ?

Would you be ok with someone taking over this PR if your busy?

I'm also interested in pushing this PR forward. Is there anything else that is needed to be done to merge it except rebasing it and resolving conflicts?

Can one of the admins verify this patch?

So yeah if anyone has the spoons to take this over it should just be fixing the merge conflicts. Feel free to ping me on the PR.

I'm still interested in merging this PR. I made a fork from the PR author's repo, pulled current Spark master branch and rebased the PR author's branch onto it. Now I have a branch with all fixed needed and no conflicts: https://github.com/inpefess/spark/tree/pickle_protocol_4
@holdenk, what we should do now?

Up next make a PR to the Apache spark repo with a title following the same format as this one and then you can at mention me for the review.

@holdenk done: https://github.com/apache/spark/pull/20691

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Jenkins ok to test. @inpefess if you can update this PR to master now is a great time to get this in since the next release after 2.4 is going to be 3 so it's easier to change formats and stuff.

Test build #98097 has started for PR 15670 at commit ce7893a.

Test build #98097 has finished for PR 15670 at commit ce7893a.

This patch fails Spark unit tests.
This patch does not merge cleanly.
This patch adds no public classes.

Build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/98097/
Test FAILed.


Feat/lint updates

See doc for PR info. Changes are only concerned with hop-node just to get on the same page but can probably be applied to all packages if/when appropriate.
Meta

Use es2021 throughout since it is supported by all browsers/servers in 2023
Update linting, formatting and compilation rules to fit our style

From a high level, the rules were set by following best practices and by observing how we code. For the most part, no meaningful changes have been made that would affect code style.

Versioning

Update typescript to latest version

Unlocks latest features like decorators
Meta

60% smaller build
80-90% faster build/startup of typescript

Update eslint to latest version

Latest features, best practices, rulesets
Compatibility - our version of node  is the last version supported by eslint <8 and will probably be deprecated in 9

Update node to LTS (20.10.0)

Latest ecmascript features like decorators
No more need for --legacy-peer-deps
No more need for node-fetch since fetch is native in node since v17.5 and is stable as of v21 (and basically stable in v20. V20 specifically optimized fetch performance)
heapdump now comes with native v8 package
Security updates for 16 stopped in Oct 2023, 20 stops >Jul 2026
Meta

Update .nvmrc to latest LTS version (20.10.0)
Remove .nodeversion since that only deals with nodenv, which I do not believe is used

Other

Pin dependencies

Allows for removal of --no-cache on docker image build to save from npm i on each build unless package.json or package-lock.json changes.

Removed @types dir. IMO allows for simpler tsconfig since all types are covered by default and no risk of bad overwrite.

Some packages introduced types since we first looked, others are now ignored with // @ts-expect-error

Closed in favor of #545


About support ROS2

@LimHyungTae Thanks for releasing the code.
Do you have any plans to support ROS2?

Hello there, I hope so, but still, I have no plan to port the algorithm into ROS2. If you do that, I'm glad to advertise your effort on my README.md :)


controls bar unavailable after inline editing

If I edit my page and the page has to scroll, the top control bar disappears, and can't undo this effect.
Effectively I can't save or preview anymore.

I could not reproduce this behavior. Can you please explain it a bit more detailed?

Beste Andreas,
I can.
First a screen shot How I see it.
What I miss is:

The preview and trash icons.
2.
I have about 800 small files in the content directory,
only a small amount is accessible, there is no scroll bar.
screenshot 2,
If I add a few extra blank lines in the text, the last row is available for editing.
The line "[NginxConfig]: http://picocms.org/in-depth/nginx/“ is visible.

Op 4 jul. 2017, om 23:32 heeft Andreas Lenhardt<EMAIL_ADDRESS>het volgende geschreven:
I could not reproduce this behavior. Can you please explain it a bit more detailed?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Due to the fact that you used the email reply function there are no screenshots available.
Could you please retry using the github website?

Hey,
I published some fixes. Unfortunately, I don't own a Mac so I can't test it for safari.
Regards
Andi

Beste Andi,
works like a advertised. great fix.
Works on Apple Safari.
Can close this issue as the issue is fixed
Thanks again for your help
Henk Melching

Op 11 jul. 2017, om 17:24 heeft Andreas Lenhardt<EMAIL_ADDRESS>het volgende geschreven:
Hey,
I published some fixes. Unfortunately, I don't own a Mac so I can't test it for safari.
Regards
Andi
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I'm glad that I could help.
Regards
Andi


Idea to mitigate memory overhead

We should likely only retain (in memory) files contents if they are under a certain file size.
The optimization is most important for lots of small files, but for larger files I suspect retaining the content in memory is worse then just re-reading it.

Notes
likely want to avoid strings > 10,000
(on sample app with 22MB estimate with 4381 items top ~1000 approx 10-15MB which would be covered by > 10,000)


[rlg] Mixing textured calls with plain calls causes artefacts

Issue description
Some raylib functions make use of textures (e.g. DrawRectangle), while others do not (e.g. DrawTriangleLines). Interleaving such calls without explicitly calling rlglDraw() seems to be causing unwanted artefacts in the output image.
Environment
macOS 10.13.5, OpenGL 4.1. I have not tested on other platforms.
INFO: GPU: Vendor:   Intel Inc.
INFO: GPU: Renderer: Intel(R) Iris(TM) Graphics 6100
INFO: GPU: Version:  4.1 INTEL-10.34.27
INFO: GPU: GLSL:     4.10

Issue Screenshot

Code Example
The following code intends to draw several vertically aligned squares and horizontally aligned circles divided into outlined triangles, but produces the image above.
BeginDrawing();

    ClearBackground(RAYWHITE);

    for (int i = 0; i < 20; i++) {
        DrawRectangle(100, 100 + i * 20, 200, 200, (Color){160, 160, 160, 64});
        for (int j = 0; j < 997; j++) {
            // rlglDraw();
            DrawTriangleLines((Vector2){
                200 + i * 40, 200
            }, (Vector2){
                200 + i * 40 + 100 * sinf(M_PI * 2 * j / 997),
                200 + 100 * cosf(M_PI * 2 * j / 997)
            }, (Vector2){
                200 + i * 40 + 100 * sinf(M_PI * 2 * (j + 1) / 997),
                200 + 100 * cosf(M_PI * 2 * (j + 1) / 997)
            }, LIGHTGRAY);
        }
    }

EndDrawing();

If the rlglDraw() above is uncommented, the artefact will disappear.
The problem seems to be caused by the incorrect texture being bound at the time of rlglDraw() after mixing the two types of calls.
On a side note, DrawTriangle() and DrawTriangleLines() do not call rlCheckBufferLimit() at the beginning, but that is not the cause of this issue.
Thanks in advance!

Thanks for reporting @kawa-yoiko!
Actually all shapes use a texture, so they can share the same shader. Texture is usually a white pixel or a white character from the default font.
Undoubtely it's related to reaching the batch buffer limit and no issuing the required draw call properly... I'll check it more carefully.

Ahh I'm not familiar with the structure, now I see ^ ^
Thanks for the prompt reply & for looking into it!

Hopefully #893 is the solution!


Handle narrow to unsubscribed stream.

[x]  Create UI.

[x]  Handle subscribe button.

[x] Handle stream events.

I don't think having so much custom code for handling the 'no messages' and 'not subscribed' case is worth it.

refactored litter bit. What other approaches are you thinking of?

Other high-level concerns: we are adding translations very soon, and you can not assume that a text that fits in some space in English, will fit in the same space when translated. We should also be considering different sizes of device screens.

yes, will make sure that it looks good in all languages on different screen sizes.

Updated
PR includes
Handle narrow to unsubscribe/invalid stream.  …
-Disable switch in Subscription screen.
In case when stream is not subscribed
and stream is invite only.
fix:#568
-Ensure stream is valid  before narrowing from link in messages.
If not valid then show message in snackbar.

-Narrow to home if narrow in cache becomes outdated (stream deleted).
-Handle stream update, create, remove, events.
-Added tests for stream events.
Fix:#555

Hey, let's move this PR along. Can you rebase, please? Thanks.

Updated

@borisyankov Rebased 👍 .

splitting this PR :)

closing this. Only one part remaining is https://github.com/zulip/zulip-mobile/pull/735


Excludes old asm lib from jsonpath lib

Transitively excludes old asm lib from com.toomuchcoding.jsonassert:jsonassert(which it pulls in from jsonpath -> json-smart -> smart-asserter .
Fixes gh-1561
This cleans up the spring-cloud-contract side of the street. The spring-boot-starter-test needs to do the same thing to totally be rid of the old asm lib.
Points to note

There may be a cleaner, maven-esque way to do this rather than brute force exclusions in the N places that jsonassert is being used. If so, please share.

An alternative would have been to exclude the asm lib from the jsonassert lib and then all we would have to do is bump its version number in here. I chose not to do this as excluding the asm only works under the assumption that an asm lib will be available by the consuming application. We know that is the case here in spring-cloud-contract because it is used by Spring applications. We do not have that same guarantee w/ jsonassert. Removing it from there could break its consumers. This is the less risky move.

Hey @bono007 com.toomuchcoding.jsonassert:jsonassert is actually my project so if you feel like we can fix the problem at its core then just file an issue and we can release a new version of it.

Hey @bono007 com.toomuchcoding.jsonassert:jsonassert is actually my project so if you feel like we can fix the problem at its core then just file an issue and we can release a new version of it.

@marcingrzejszczak I saw that was your project. I think that is a cleaner fix but my only concern is non-spring consumers of it. If that is not an issue I can fix it there.
BTW, I ❤ the name com.toomuchcoding - too funny.

@marcingrzejszczak I saw that was your project - I heart the name com.toomuchcoding - too funny. I think that is a cleaner fix but my only concern is non-spring consumers of it. If that is not an issue I can fix it there.

We can fix it there and release a major version 1.0.0 that is breaking.

@marcingrzejszczak I will submit an MR to com.toomuchcoding.jsonassert:jsonassert w/in the hour. Once released I will update this MR accordingly.

https://github.com/marcingrzejszczak/jsonassert/pull/35

@marcingrzejszczak - my assumption going into my "fix" was that Spring Core brought in the newer version of ASM. However, further discussion on the Spring Boot Starter Test portion of this work has revealed that Spring Core actually shades ASM (like a good library should).
I think we should remove these exclusions and instead either

Do nothing - the reported issue has a simple workaround
Use the shaded jsonassert.

Sorry for the churn on this one but I would rather catch this up front than in the wild if possible.

Sure, can you create a PR then that reverts https://github.com/spring-cloud/spring-cloud-contract/commit/de8333deed5f97aca4d8571cbb92941b2e346a45 ?
As for the shaded jsonassert - that's actually a breaking change as I mentioned before. I'd go with doing nothing and once the boot starter ever changes we'll figure it out

Sounds good @marcingrzejszczak . I will not get to it until this evening but I will get it taken care of.


modify dockerfile

Refs #4919.

Pull Request Test Coverage Report for Build 2241

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

Totals

Change from base Build 1175:
0.0%

Covered Lines:
11890

Relevant Lines:
20482

💛  - Coveralls

Codecov Report

Merging #4956 into master will decrease coverage by 0.15%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #4956      +/-   ##
============================================
- Coverage     54.45%   54.30%   -0.16%
  Complexity      440      440
============================================
  Files          1140     1140
  Lines         20482    20493      +11
  Branches       3765     3765
============================================
- Hits          11154    11129      -25
- Misses         8620     8659      +39
+ Partials        708      705       -3

Impacted Files
Coverage Δ
Complexity Δ

...che/shardingsphere/core/rule/BindingTableRule.java
73.07% <0.00%> (-26.93%)
0.00% <0.00%> (ø%)

.../apache/shardingsphere/core/rule/ShardingRule.java
77.39% <0.00%> (-2.19%)
0.00% <0.00%> (ø%)

...rite/token/generator/impl/IndexTokenGenerator.java
87.50% <0.00%> (ø)
1.00% <0.00%> (ø%)

...rding/rewrite/engine/ShardingSQLRewriteEngine.java

...e/token/pojo/impl/GeneratedKeyAssignmentToken.java

...sharding/rewrite/token/pojo/impl/OrderByToken.java

...rite/token/pojo/impl/AggregationDistinctToken.java

...ding/rewrite/token/pojo/impl/ProjectionsToken.java

...token/pojo/impl/GeneratedKeyInsertColumnToken.java

.../pojo/impl/LiteralGeneratedKeyAssignmentToken.java

... and 31 more

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 4d53d22...74bfe15. Read the comment docs.


Exception on callback

[info] GET /auth/steam/callback
[debug] Processing with DropsquadsWeb.AuthController.callback/2
  Parameters: %{"openid.assoc_handle" => "1234567890", "openid.claimed_id" => "https://steamcommunity.com/openid/id/76561198020220006", "openid.identity" => "https://steamcommunity.com/openid/id/76561198020220006", "openid.mode" => "id_res", "openid.ns" => "http://specs.openid.net/auth/2.0", "openid.op_endpoint" => "https://steamcommunity.com/openid/login", "openid.response_nonce" => "2018-05-05T17:43:32ZcIyuKWjMHYPSjms0UBt4txzkyhc=", "openid.return_to" => "http://<IP_ADDRESS>:4000/auth/steam/callback", "openid.sig" => "VyYdNx0Ab2kdzpvb5AXBV07+yj8=", "openid.signed" => "signed,op_endpoint,claimed_id,identity,return_to,response_nonce,assoc_handle", "provider" => "steam"}
  Pipelines: [:browser]
[error] Task #PID<0.415.0> started from #PID<0.408.0> terminating
** (FunctionClauseError) no function clause matching in Ueberauth.Strategy.Steam.retrieve_user/1
    (ueberauth_steam) lib/ueberauth/strategy/steam.ex:112: Ueberauth.Strategy.Steam.retrieve_user(%{"openid.assoc_handle" => "1234567890", "openid.claimed_id" => "https://steamcommunity.com/openid/id/76561198020220006", "openid.identity" => "https://steamcommunity.com/openid/id/76561198020220006", "openid.mode" => "id_res", "openid.ns" => "http://specs.openid.net/auth/2.0", "openid.op_endpoint" => "https://steamcommunity.com/openid/login", "openid.response_nonce" => "2018-05-05T17:43:32ZcIyuKWjMHYPSjms0UBt4txzkyhc=", "openid.return_to" => "http://<IP_ADDRESS>:4000/auth/steam/callback", "openid.sig" => "VyYdNx0Ab2kdzpvb5AXBV07+yj8=", "openid.signed" => "signed,op_endpoint,claimed_id,identity,return_to,response_nonce,assoc_handle", "provider" => "steam"})
    (elixir) lib/task/supervised.ex:88: Task.Supervised.do_apply/2
    (elixir) lib/task/supervised.ex:38: Task.Supervised.reply/5
    (stdlib) proc_lib.erl:247: :proc_lib.init_p_do_apply/3
Function: #Function<1.113179099/0 in Ueberauth.Strategy.Steam.handle_callback!/1>
    Args: []
[error] Ranch protocol #PID<0.408.0> (:cowboy_protocol) of listener DropsquadsWeb.Endpoint.HTTP terminated

https://github.com/kouwasi/ueberauth_steam fixes the matching error


[Usage] load the checkpoint of llava-llama-2

When did you clone our code?
I cloned the code base before 5/1/23, but have pulled the latest code base
Describe the issue
Issue: When I load the checkpoint of llava-llama-2 in model zoo, I meet the error as follows:
Log:
You are using a model of type llava to instantiate a model of type llava_mpt. This is not supported for all configurations of models and can yield errors.
*** OSError: Error no file named pytorch_model.bin, tf_model.h5, model.ckpt.index or flax_model.msgpack found in directory ckpt/llava.

Hi, it is strange that it goes to the MPT. Can you provide the full command you used? Thanks.

when I using follow command, I meet a problem.
from transformers import pipeline
pipe = pipeline("text-generation", model="liuhaotian/llava-v1-0719-336px-lora-vicuna-13b-v1.3")

I am a new starter, is there any other ways to download the pre-trained model？
Is it possible to check the model has already been downloaded correctly to the local manually, where to change the parameter to load the model locally? Can you show me the folder structure?

Hi, for CLI inference, please follow our instructions here.

I faced the same issue when I was using the local parameters (cloned from huggingface).

Maybe check if your folder contains the proper index.json file? It should NOT contain pytorch_model.bin actually as it is sharded.

Oops! Thanks for this. My bad. It should work now.


Optimise variant rebuilds to casts

A Result<A, B> pattern match of this form
switch res {
    case ...;
    case (#err e) { ... (#err e) ... }
}

where the RHS #err e has type Result<C, B> can always be optimised to
switch res {
    case ...;
    case (#err _) { ... (prim "cast" : Result<A, B> -> Result<C, B>) res ... }
}

Generally this transformation is valid for variants as long as the alternative is not affected by the type change (i.e. has neither sub-values of type A or C).
This can probably be implemented as an IR pass, and can potentially exhibit nice gains w.r.t. cycles and size in code that uses monadic error propagation a lot.

These are quite ubiquitous: mapOk, chain and flatten in mo:base/Result show this pattern.

It’d be a bit sad to have a IR-to-IR pass that has to resert to prim cast because the resulting program can no longer be typechecked. That’s incidentially why GHC doesn't do the optimization you mention at the Core level (but at the STG level it does, I think).
We could improve the type checker so that in the body of a switch (v) {case (#tag e) …}, the type of v is refined to { #tag : … }, or something.
Of course, if the experiment in #3955 shows that that the perf impact is too large to ignore, that can change the story a bit.

Refining the scrutinee to a subtype sounds like a solution, but we cannot do it in the way GHC does it for GADT matches (type-directed). We'd have to resort to operational evidence (pointing to the case pattern that performed the match) and verifying (type-checking) such a thing sounds hairy to me.


Define or limit pager dimensions

In some multi-head configurations, particularly when two large monitors are placed side-by-side horizontally, the pager's dimension could become too big and take up too much space on the tray.
Could it be possible to add a "width" attribute (and possible a "height" one, that could be useful in case of vertical pagers) to the "Tray" tag? When specified, they should make the dimensions constant.

Currently JWM maintains the aspect ratio of the desktops in the pager, which I assume is causing the problem here.  I usually set the desktop layout up in such a way that the pager looks right.  Of course, there's really no reason why the aspect ratio needs to be maintained and this should be pretty easy to implement.


application stylePreprocessorOptions cannot detect paths from a library

🐞 Bug report
Command (mark with an x)
- [ ] new
- [x] build
- [x] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Is this a regression?
The behaviour worked in 8.0.3, and stopped working in 8.1.2.
Description
There is 1 application and 1 library. Let's call this application tenant and the library shared-lib.
A component in the tenant wants to import a stylesheet of a component from shared-lib. This particular stylesheet imports a CSS like so:
@import 'colors'; // the lib's ng-package.json styleIncludePaths is already configured.

This will compile just fine in the library.
Now there is a component in tenant that wants to import this particular stylesheet.
This used to work before by doing this:

Import the stylesheet explicitly,  in projects/tenant/components/tenant-util.component.ts

  styleUrls: [
    '../../../../shared-lib/src/lib/components/util.component.scss',
    './tenant-util.component.scss'
  ]
...

Configure stylePreprocessorOptions in the tenant project settings.

"projects": {
    "tenant": {
           ...
           "stylePreprocessorOptions": {
              "includePaths": [
                "projects/shared-lib/src/lib/stylesheets"
              ]
            },

🔬 Minimal Reproduction
Clone this repo: https://github.com/jonathanlie/angular-demo

To demonstrate the working version, inside the cloned repo:

git checkout angular-cli-8.0.3
npm install
ng build shared-lib
ng serve --aot tenant

To demonstrate the non-working version

git checkout master
sudo rm -r ./node_modules
npm install
ng build shared-lib
ng serve --aot tenant

There will be an error when serving the tenant app as described in the section below.
🔥 Exception or Error

10% building 3/3 modules 0 activeℹ ｢wds｣: Project is running at http://localhost:4200/webpack-dev-server/
ℹ ｢wds｣: webpack output is served from /
ℹ ｢wds｣: 404s will fallback to //index.html

chunk {main} main.js, main.js.map (main) 2.07 kB [initial] [rendered]
chunk {polyfills} polyfills.js, polyfills.js.map (polyfills) 712 bytes [initial] [rendered]
chunk {runtime} runtime.js, runtime.js.map (runtime) 6.09 kB [entry] [rendered]
chunk {styles} styles.js, styles.js.map (styles) 17 kB [initial] [rendered]
chunk {vendor} vendor.js, vendor.js.map (vendor) 341 kB [initial] [rendered]
Date: 2019-07-19T06:18:00.166Z - Hash: d82cd3d8b42ac99436fa - Time: 1565ms

ERROR in Module build failed (from /angular-demo/node_modules/sass-loader/lib/loader.js):

@import 'colors';
       ^
      Can't find stylesheet to import.
  ╷
1 │ @import 'colors';
  │         ^^^^^^^^
  ╵
  stdin 1:9  root stylesheet
      in /angular-demo/projects/shared-lib/src/lib/components/util.component.scss (line 1, column 9)

🌍 Your Environment

Angular CLI: 8.1.2
Node: 12.3.1
OS: darwin x64
Angular: 8.1.2
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.801.2
@angular-devkit/build-angular      0.801.2
@angular-devkit/build-ng-packagr   0.801.2
@angular-devkit/build-optimizer    0.801.2
@angular-devkit/build-webpack      0.801.2
@angular-devkit/core               8.1.2
@angular-devkit/schematics         8.1.2
@ngtools/json-schema               1.1.0
@ngtools/webpack                   8.1.2
@schematics/angular                8.1.2
@schematics/update                 0.801.2
ng-packagr                         5.3.0
rxjs                               6.4.0
typescript                         3.4.5
webpack                            4.35.2

This seems to be related to a bug fix in https://github.com/sass/dart-sass/blob/master/CHANGELOG.md#javascript-api-3 which was done to align dart-sass with node-sass.
Using node-sass, indeed yields the same error but It does provide further details.
ERROR in ../shared-lib/src/lib/components/util.component.scss
Module build failed (from c:/git/cli-repos/angular-demo/node_modules/sass-loader/lib/loader.js):

var colors = require('./colors');
module['exports'] = colors;

// Remark: By default, colors will add style properties to String.prototype
//
// If you don't wish to extend String.prototype you can do this instead and native String will not be touched
//
//   var colors = require('colors/safe);
//   colors.red("foo")
//
//
require('./extendStringPrototype')();
^
      Invalid CSS after "v": expected 1 selector or at-rule, was "var colors = requir"
      in c:\git\cli-repos\angular-demo\node_modules\colors\lib\index.js (line 1, column 1)

Debugging it a bit, I noticed that the problem is that the file name is colors.scss, which is being resolved to the colors, node_modules instead of the sass file. Renaming the file to variables.scss does seem to resolve the issue.
This seems to be an issue from sass-loader  Please file an issue on their issue tracker.

Thanks for the swift response! It didn't occur to me that this could be the cause. Will consider filing an issue on their issue tracker later on.


[Impeller] Texture to Texture blits are misconfigured in GLES backend.

See https://ci.chromium.org/ui/p/flutter/builders/staging/Linux_pixel_7pro animated_blur_backdrop_filter_perf_opengles__timeline_summary/719/overview
After making GL errors fatal, several CI tests started failing. The error is Fatal GL Error GL_INVALID_OPERATION(1282) encountered on call to glBlitFramebuffer which is likely due to an error state listed in https://registry.khronos.org/OpenGL-Refpages/es3.0/html/glBlitFramebuffer.xhtml .
Since its for the onscreen, it might be either framebuffer completeness or sample count mismatch.

moving to P2 since we're not shipping GLES right now

This issue is distinct from https://github.com/flutter/flutter/issues/157064, as the glBlitFramebuffer proc is actually resolving here, but erroring out on usage.

I re-enabled the strict checking and cannot reproduce this error anymore. Closing as fixed!


⚠ Bofrost.es has degraded performance

In 11efd97, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1822 ms

Resolved: Bofrost.es performance has improved in 33547fe after 26 minutes.


[BUG] k8s 部署报错

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
我按照部署文档上的 yaml 进行部署,在k8s集群上启动报错
Expected Behavior
No response
Steps To Reproduce
No response
Environment
ShenYu version(s):

Debug logs
No response
Anything else?
No response

pls in english

Re question in English


Main/Pause Menus

Description
Create intuitive game menus for the start screen and game pausing. The menus should allow the user to easily start or resume a game, configure settings and navigate through different points in the game, such as the home screen, different levels and different gamemodes. The menu buttons should be named and designed so their function is clear to first-time users.
In the final product, the start screen menu will appear at the start of the game and the pause menu will appear when the user pauses the game.
Both screens should aim to be visually and emotionally appealing, especially the start screen as it is the user's first impression of the game.
SubFeature/component
Main menu
Displayed upon game startup. This screen will have a background image that fits the game’s theme and displays the game’s logo.

Start new game: Go to opening cutscene with minimal wait time.

Difficulty selection: Buttons to choose a difficulty for the game.

Resume game: Shown only when the user has a game in progress. On click, resume game with minimal wait time.
How to play: Guide to how to play the game. List the keys that are used and what each one does (no mouse). Give an overview of how to play the game. This will most likely be a static screen at first, but it can be interactive later.
Game settings: Volume/sound effects sliders, customisable keybindings.
Achievements: Optional. Could show stats and levels reached.

Pause menu
Displayed when the user pauses by pressing P.

Save and quit: Return to the main menu.
Resume: Go back to the game.
How to play: Same as with the main menu. This could be useful if the player forgets how to play or jumps right into a game without checking how to play first.

Dependencies

#11

Tasks

[ ] #22
[ ] #20
[ ] #21
[ ] #25

Milestones

[ ] Design the initial layout and navigation structure of the game menu (Aug. 15)
[ ] Implement pause, continue, and save functionalities within the menu (Aug. 20)
[ ] Implement the game's settings page (Aug.23)
[ ] Develop dynamic menu options based on game state and player interactions (Aug. 26)
[ ] Finalise documentation (Aug. 29)

Completion Deadline: 29 Aug
Extras (optional)

[ ] How to Play? : Add a section with tutorials or guides that explain the rules, controls, and tips for the game, helping new players get started.
[ ] Character List Menu: In case we have many character options, there should be a menu to display all locked and unlocked characters.

Documentation

Menu design
Menu features and code documentation
User guide to starting the game

Members

Jigyasu Mittal (@JigyasuMittal )
Sahajdeep Singh Narang (@sahajdeep31)
Ian Pinto (@IanP96)
Tri Nhan Pham (@TriNhan-Pham)
Aditya Raj Singh (@Aditya6283)

This ticket is looking good so far, make sure to update it with links to the task tickets and documentation as they are created. This ticket is approved and you can start creating the associated task tickets.

Pause menu ditched for sprint 1, that will be for a future sprint


Add task to generate release body

In this PR I introduce a task to generate the body for a new release.
We use the git-cliff project through their docker image to generate a changelog between the current tag and the latest release's tag.
I have customised the format of the release body a bit to fit our Github usage (i.e. squash commits). This is orthogonal to any automation efforts we want to do in the future.
I paste what the release body would look like now for discussion (note that we are missing this actual PR, hence why we see three dangling commits at the beginning).
=====
Faabric's Changelog
Here is what has changed since last release:
[0.3.1] - 2022-02-23

Ci: generate release body with changelog
Ci: add step to generate changelog
Bumping code version for release
Detect CPU information (#231)
Executor context (#228)
Conan cache improvements (#230)
Remove SGX-related message fields (#229)
Master to main (#227)

[0.3.0] - 2022-02-11

Version bump (#226)
Generate documentation (#223)
Executor decision caching and single-host optimisations (#222)
XOR diffing (#224)
Use conan action (#225)
Use dirty page flags instead of dirty regions (#219)
Periodically Check For Migration Opportunities (#214)
Add gdbinit config (#217)
Remove timed mutex from ptp broker (#220)
Cmake minimum version and skylake (#218)
Cmake: quote conan revisions (#213)
Dirty tracking performance improvements (#210)
Introduce Fixed-Capacity Queues (#205)
Merge regions overhaul (#201)
Add in-proc PAIR sockets (#206)
Use matrix build for sanitisers (#208)
No need to acquire a lock to set a message id in mpi (#203)
Snapshots overhaul (#176)

[0.2.3] - 2021-12-20

Pin Conan dependencies to revision (#200)
Locality aware gather (#198)
Return executed time with successful status request (#197)
Fix reduce bug and add regression test (#195)
More race condition fixes (#193)
Locality Aware Reduce (#191)
Minor fixes (#192)
Locality Aware Broadcast (#185)
Enable/disable scheduling topology hints through an env. variable (#188)
Re-use conan cache for built dependencies (#187)
Adding support for sanitised builds (#182)
Retry GET from Redis for messages in the Execution Graph (#181)
Use NEVER_ALONE for chained MPI calls (#184)
Add Scheduling Topology Hints (#180)
Fix race condition in scheduler reset (#179)
Get ExecGraph hosts (#178)
Make sure conan packages get compiled with C++20 enabled (#177)
Track Message Type in Execution Graph (#175)
Snapshot diff merging fixes (#174)
Scheduler hints and fixes for distributed coordination bugs (#169)
Fixes for MPI message graph (#173)
Adding arbitrary information to execution graph (#166)
Add distributed coordination operations (#161)
Use faster lld as the linker (#168)

[0.2.1] - 2021-10-27

Cmake Cleanup Faabric Part 2 (#165)
Cmake cleanup Faabric Part 1 (#164)
Initialise point-to-point mappings from scheduler output (groundwork) (#160)
README flair (#159)
Allow merge regions to cross pages (#158)
Allow generating execution graphs from MPI runs (#154)
Generalised point-to-point messaging (#151)
Fix issue with hanging shutdown when not really started (#155)
Remove sgx check from faabric runner (#153)
Add snapshot if exists function to snapshot registry (#152)
Multi-threaded server message endpoints (#147)
Change default mpi base port and allow value to be set through env variable (#150)
Add ignored snapshot regions (#148)
Add crash handler to tests (#149)
Merge docker compose files (#146)
Add a crash handler that prints backtraces to FaabricMain users (#145)
Compare pointers rather than ids in Scheduler::notifyExecutorShutdown (#144)
Snapshot diff merge operations (#142)
Not use emplace for editing vector elements (#143)
Specify timeouts when timing out (#140)
Add snapshotExists function to registry (#136)
Set appid on messages (#137)
Fix race condition in test (#138)
Latency fixes (#135)

@csegarragonz let's also remove the commit bodies and just include the headline commits. There are links to the PRs that people can click on if they want more detail.

@Shillaker we don't need to add git-cliff as a dependency, as we rely on the docker image to run it. further, git-cliff is written in rust, what means that we couldn't use pip to manage its installation anyway.
i add the new release body format in the updated pr description, i agree with you and think it is more concise and readable.

Ah whoops, sorry I'd assumed git-cliff was a python module. Interesting choice to go with Rust...


action: relax the condition of release tag

Allow to publish release version by tag like v0.3.0-alpha.0.
Signed-off-by: Yan Song<EMAIL_ADDRESS>

Codecov Report

Merging #68 (64f34df) into main (c1c4b6e) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #68   +/-   ##
=======================================
  Coverage   31.63%   31.63%
=======================================
  Files          19       19
  Lines        1476     1476
=======================================
  Hits          467      467
  Misses        934      934
  Partials       75       75

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 c1c4b6e...64f34df. Read the comment docs.


CSON preview as JSON

Maybe .cson files should preview JSON rather than CoffeeScript, perhaps via cson2json…

@aki77 See #10


73 | Set Matrix Zeroes | C++

Title - Set Matrix
What will change -
I would like to provide the solution to SET MATRIX ZEROES
Link :: SET MARTIX ZEROES
Please assign it to me

Type of Issue -
Please add/delete options that are not relevant.

[x] Adding New Code
[x] Improving Code
[x] Improving Documentation
[x] Bug Fix

Programming Language
Please add/delete options that are not relevant.

[ ] Python
[X] C++
[ ] Java
[ ] SQL

Self Check

Ask for issue assignment and wait to get assigned to it before making Pull Request.
Add your file in the proper folder
Clean Code and Documentation for better readability
Add Title and Description of the program in the file

:star2: Star it :fork_and_knife:Fork it :handshake: Contribute to it!
Discord server ✉ - https://discord.gg/CXksGdn
Happy Coding,

Please assign this to me. Thanks

@nilnguyenkl  you may create new issue ..... 😶

@vipul-2003 issues are assigned to those who ask for it first. Please read the contributions guideline.

@vipul-2003 issues are assigned to those who ask for it first. Please read the contributions guideline.

Hey thats not good , i have read the contributions rules and even also requested for assigning me clearly scene in large .... 😶😐

@vipul-2003 issues are assigned to those who ask for it first. Please read the contributions guideline.

Hey thats not good , i have read the contributions rules and even also requested for assigning me clearly scene in large .... 😶😐

Look at the issue raised

@vipul-2003 when you create an issue, you also need to mention it in the comments that you want the issue to be assigned to you. You can look at all the previous issues. They were assigned to those who mentioned it first. It doesn't matter who raised that issue!

@vipul-2003 when you create an issue, you also need to mention it in the comments that you want the issue to be assigned to you. You can look at all the previous issues. They were assigned to those who mentioned it first. It doesn't matter who raised that issue! Also, please read the guidelines.

No worry ....


[Event Request] Codeunit 99000854 "Inventory Profile Offsetting" - Procedure MaintainPlanningLine - OnMaintainPlanningLineOnBeforeCopyDueDateToInvtProfile

Please add an Event OnMaintainPlanningLineOnBeforeCopyDueDateToInvtProfile in Procedure MaintainPlanningLine in Codeunit 99000854 "Inventory Profile Offsetting"
[Event Request] Codeunit 99000854 - Inventory Profile Offsetting - procedure MaintainPlanningLine
    var
        PurchaseLine: Record "Purchase Line";
        ProdOrderLine: Record "Prod. Order Line";
        AsmHeader: Record "Assembly Header";
        TransLine: Record "Transfer Line";
        CurrentSupplyInvtProfile: Record "Inventory Profile";
        PlanLineNo: Integer;
        RecalculationRequired: Boolean;
        IsHandled: Boolean;
    begin
        ...

        if RecalculationRequired then begin
            Recalculate(
              ReqLine, Direction,
              ((SupplyInvtProfile."Planning Line Phase" < SupplyInvtProfile."Planning Line Phase"::"Routing Created") or
               (ReqLine."Action Message" = ReqLine."Action Message"::New)) and
              (ReqLine."Ref. Order Type" = ReqLine."Ref. Order Type"::"Prod. Order"));
            ReqLine.UpdateDatetime;
            ReqLine.Modify();

            SupplyInvtProfile."Starting Date" := ReqLine."Starting Date";

            OnMaintainPlanningLineOnBeforeCopyDueDateToInvtProfile(SupplyInvtProfile, ReqLine); // <-- NEW EVENT

            SupplyInvtProfile."Due Date" := ReqLine."Due Date";
        end;

        if NewPhase = NewPhase::Obsolete then begin
            if SupplyInvtProfile."Planning Line No." <> ReqLine."Line No." then
                ReqLine.Get(CurrTemplateName, CurrWorksheetName, SupplyInvtProfile."Planning Line No.");
            ReqLine.Delete(true);
            SupplyInvtProfile."Planning Line No." := 0;
            SupplyInvtProfile."Planning Line Phase" := SupplyInvtProfile."Planning Line Phase"::" ";
        end;

        SupplyInvtProfile.Modify();

        OnAfterMaintainPlanningLine(ReqLine);
    end;

[IntegrationEvent(false, false)]
local procedure OnMaintainPlanningLineOnBeforeCopyDueDateToInvtProfile(var SupplyInvtProfile: Record "Inventory Profile"; var ReqLine: Record "Requisition Line")
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 43085.


Use Python 3.6 in Travis CI

This PR fixes the error of from typing import Type in Travis CI caused by tornado==6.0.1 by switching from Python 3.5 to 3.6.
https://travis-ci.org/chainer/chainerrl/jobs/504242079

LGTM, too


Issue #3945 Fixed

BUGS:

Please describe the issue that you solved if its not filed.
I have solved the html code showing while sharing the product on social media (Facebook)
Otherwise please mention issue #id and use comma if your PR
solves multiple issues.

For things other than bugs:

Describe that thing in very short line, word limit is 200.
HTML code showing while sharing because  of appropriate syntax usage in Laravel blade file that i have corrected
Otherwise use issue #id if the issue was filed as feature request.

Use "{!!" for description only.

OK Sure


Infra: Create a plugin in buildSrc to generate files with constants

Currently such tasks are copy-pasted among almost all subprojects

Looks like there is an existing plugin for this: https://github.com/gmazzo/gradle-buildconfig-plugin


[Autocomplete] Allow the clear x-button to be accessible via tabbing

Summary
The tabIndex for the clear button is currently set to -1, causing the button to be inaccessible via tabbing. For accessibility reasons, it would be nice to make this button available. Perhaps there can be a property that can be passed down to override the tabIndex value.
Examples
No response
Motivation
It'll be easier for the keyboard user to be able to clear all of the inputs rather than pressing the delete button many times until the input is clear.
Search keywords: autocomplete, clear button, tab, accessibility

Duplicate of #30815


Weekly Report 2024-09-12

What did you do this week?

I found more people for interviews and started creating a google form to ask interview questions to a wider group of people.

I am looking into web scraping using JavaScript. This YouTube video goes over using playwright https://playwright.dev/ to scrap: https://www.youtube.com/watch?v=DOtJEwVsJic . Something I learned about scraping is that proxies can help mitigate websites from cutting off access when scraping. Also playwright is free and open source.

This week, I sketched the search results page for our website and figured out UI features that will be important once we start building our site. Additionally, I started creating the templates for both user personas and stories in our wiki page.

@pbgmidi Let's create a folder for the web scraping feature we will implement. This will be a program running on the server side, and it won't have any direct interactions with our web app.


Detect left, right when swipe

How can detect left or right when swipe.
Thanks.

I am also in search of catching which direction I swiped and currently which index I am at.

Hey, I read through the issues and found out that using a combination of onMomentumScrollEnd and onScrollBeginDrag props together might be a solution. You can look for the changes on the index field of the state and detect left/right swipe according to the increase and decrease of the intial index which is captured by onScrollBeginDrag.

I've found a trick that works to disable right / left swipping
In my case I wanted to disable right swipping in the case the user didn't complete the card, for left swipping you could use the same logic:
onMomentumScrollEnd={(e, state, context) => {
            if(state.index > this.currentIndex && this.currentIndex > 0) {
              this._swiper.scrollBy(-1)
            }
            this.currentIndex = state.index;
          }}

You get this:

@milkers use index doesn't work for loop=true, especially having 2 items, the index will be 0,1,0,1,0,1 ...

@tdurand this way doesn't look good. still see the next slide.
Anyway to stop the scrolling?

@Tom29 stopping won't work since onMomentumScrollEnd gets called after animation is complete.

I think i found a better solution. I Use the onScrollBeginDrag and the onScroll event. The onScrolBeginDrag fires before the onScroll event, so I save the offset of the slide in the onScrollBeginDrag and when the onScroll event is fired I compare the offset.
onScrollBeginDrag(e) {
    this.setState({ offset: e.nativeEvent.contentOffset.y });
  }

  onScroll(e) {
    const dragOffset = e.nativeEvent.contentOffset.y;
    const { offset, index } = this.state;
    this.setState({ loadingIndex: dragOffset > offset ? index + 1 : index - 1 });
  }

 render() {
    const { channels, navigator } = this.props;
    const { index, loadingIndex } = this.state;

    return (
            <Swiper
              horizontal={false}
              showsButtons={false}
              showsPagination={false}
              ref={(swiper) => { this.swiper = swiper; }}
              loadMinimal
              loadMinimalSize={0}
              loadMinimalLoader={
                <LivePlayerSpinner
                  cover={channels[loadingIndex].cover}
                  title={channels[loadingIndex]['current-schedule-program'].title}
                />
              }
              loop={false}
              onIndexChanged={this.onIndexChange}
              index={index}
              onScrollBeginDrag={this.onScrollBeginDrag}
              onScroll={this.onScroll}
              scrollEventThrottle={16}
            >
              { channels.map(channel => <VideoPlayer live key={channel['content-id']} content={channel} navigator={navigator} />) }
            </Swiper>
);

@acollazomayer onScroll doesn't work for me, how do you get that event?

@femiveys the onScroll events comes with the swiper component

That's strange. I cannot access them. In the latest version onScroll is never called for me. Maybe it is because the pages are WebViews

@acollazomayer same here onScroll doesn't work for me


Make a broomstick hudbar

It's highly possible that we could make broomstick's timer a hudbar.
I think we could even make so the hudbar IS the timer, then if the hudbar gets to 0, it is deleted/hidden and the effect gets to its end. If an icon is needed, I think the one for the broomstick would be self-explicit.
I thought to it seeing this video

Good idea, but in this case we should delete the chat messages which was here for this reason
In fact, a small timer hud bar with the amount of seconds could be interesting and more readable for players


chore: add goimports

Closes #

[x] Well-formatted commit messages
[x] Rebased/mergeable
[x] Tests pass

Failure before running make fmt

Failure before running make fmt

It turns out goimports just splits std libraries to the top, and all other groups are just sorted.
Manually fixed the grouping for some files.

It turns out goimports just splits std libraries to the top, and all other groups are just sorted.
Manually fixed the grouping for some files.


Adds affiliations to work form.

closes #3156
Why was this change made? 🤔
How was this change tested? 🤨
⚡ ⚠ If this change involves consuming from or writing to another service (or shared file system), run integration test create_object_h2_spec.rb and/or test manually in [stage|qa] environment, in addition to specs. ⚡
Unit, Amy
Does your change introduce accessibility violations? 🩺
⚡ ⚠ Please ensure this change does not introduce accessibility violations (at the WCAG A or AA conformance levels); if it does, include a rationale. See the Infrastructure accessibility guide for more detail. ⚡
No, per SiteImprove.


Build and document the control of multiple clusters

How to start and stop the entire pipeline

Rubin uses ArgoCD. Ask Stelios.

30/JUN/21

@RoyWilliams and tms-epcc agreed this is being dealt with as part of Cycle-4 under Review and set resilience plan

29/SEP/21

this start/stop has been checked.
Roy advised Ken what needed to done and Ken did this.
details on how to this in Lasair Principles of Operation


feature: Pre-commit integration

Is your feature request related to a problem? Please describe.

Make the Griffe repo provide pre-commit hook(s).
Describe the solution you'd like

Let's provide a .pre-commit-hooks.yaml to be able to run Griffe as a pre-commit hook.

Ha, I'm not a fan of the pre-commit tool. I'm not sure I want to maintain hooks here for a tool I don't use :sweat_smile: Isn't there a central repository for that (asking everytime) :thinking: Or, could this be provided in a third-party repository? Like in a pre-commit-griffe repository maintained by someone else :smile:?

A separate repository could be made, like https://github.com/astral-sh/ruff-pre-commit.
I could maintain it and see if it's worth it.

Thanks, I'd much prefer that :slightly_smiling_face:
Or that pre-commit hosts a community hooks repository or something. As shared privately, I think it's unfair to put some burden on every project that your users want to use your tool (pre-commit) with.
If pre-commit allows its users to easily host project hooks in third-party repos, that's great, but apparently it's not the case, as I can see in https://github.com/astral-sh/ruff-pre-commit where they actually have to configure a new Python package (pyproject.toml) for that. Well, their use-case is for pre-built wheels, which shows another limitation of pre-commit I guess (can it only install from source?).


Input whitespace The number of Spaces saved is not the number of Spaces I entered

Describe the bug
Input whitespace The number of Spaces saved is not the number of Spaces I entered
Screenshots

I'm sorry for the late reply. I'll check.

@jwlee1108 When can you repair it? thanks


Using EmailAlerter in strategies

Hi Gareth,
I am not so familiar with Spring, but is there any way to use EmailAlerter on strategies? For example, I would like to notify myself about order executions.

Not at the moment. The EmailAlerter is an internal component and was designed to be used by the core engine to notify users about bot crashes.
It's fairly easy to create your own EmailAlerter and bundle it with your strategies - I think some folks already do this as well as record their trades/orders in an external database.
To change to the bot to make the EmailAlerter available would require a fair bit of work. One approach might be to create an EmailAlertService in a new bxbot-strategy-services module/jar. Strats would be dependent on this if they wanted to send email alerts. The new module could re-use the existing repository layers etc... Sadly, I've not got time to do this at the moment as the day job is pretty hectic (!) and most of my free time is spent working on a Blockchain project, but feel free to fork the repo and have a go!

Thank you @gazbert I will try to do something as you suggested.


Question: Where is the best place to release the resources of my SwapChainPanel

I have a WinUI unpackaged app with just a SwapChainPanel subclass inside it.
In my constructor, I have:
        this.Loaded += VideoView_Loaded;
        this.Unloaded += VideoView_Unloaded;

The loaded event does get triggered, but the unloaded event does not get triggered when I close the application.
I could listen for the window to be closed, but my end goal would be to redistribute that component (trying to implement a WinUI port of LibVLCSharp ).
What is the best way to free the ressources? (like D3D11Device etc...) Where is the best place to call DirectXHelpers.ReportLiveObjects(); in my test app to know if I'm introducing leaks ?

@codendone FYI