Sucessfully added Simon -Says (Advances Version) game #445

Simon Says (Advanced Version) Game
Project Overview
This project involves the development of an Advanced Version of the classic Simon Says memory game. The game challenges players to recall and replicate sequences of colors, with difficulty increasing as they progress through levels. This version provides a highly interactive experience through visual and audio feedback, score tracking, and level progression.
Task Overview
This task involved creating the Simon Says Advanced Version game and merging it with the main branch as part of the development process. Below is a summary of the completed task:

Branch Created: simon-says
Task Completed: Developed a Simon Says game, tested it thoroughly, and successfully merged it into the main branch.
Commit Details: All changes were committed and pushed successfully.
Pull Request Details: This PR includes the fully functioning Simon Says game integrated into the project.
Issue Number: #445

Game Features

Enhanced Memory Challenge: Players must remember progressively longer and more intricate sequences of colors.
Visual and Audio Feedback: Each color is accompanied by a sound and visual cue, enhancing the immersive experience.
Level Progression: Difficulty increases as players successfully complete each level, introducing longer sequences.
Score Tracking: Points are awarded based on player performance, with levels contributing to the score.

Tech Stack

HTML5: Structured the game layout with buttons and display elements.
CSS3: Styled the interface with responsive design, including animations for button interactions.
JavaScript (ES6): Implemented game logic, user interaction, and sound effects for game interactivity.

Task Completion

[x] Created simon-says branch
[x] Completed Simon Says game development
[x] Linked and merged with the main branch
[x] Submitted pull request for review

Tags for Admin Consideration
Please make sure the following tags are allocated to this PR:

gihacktoberfest
hacktoberfest-accepted
level3
gssoc-ext

How to Play

Start the Game: Click the "Start Game" button to begin.
Follow the Pattern: The game will show a sequence of colors that you must replicate by clicking the corresponding buttons.
Increase Difficulty: Each level will add one more color to the sequence, increasing the difficulty.
Scoring: Earn points for every correct sequence. Try to achieve the highest score!

Task Completion Video
https://github.com/user-attachments/assets/dd160f3a-ea0f-4818-93e3-bbf35d544a40
Thank you for reviewing this pull request. I look forward to your feedback and approval.

Bubble Shooter Game Development
Task Overview
This task involved creating a Bubble Shooter game from scratch and linking it to the main branch as part of the development process for issue no. #446. Below is a brief summary of the completed task:

Branch Created: bubble-shooter
Task Completed: Developed a Bubble Shooter game and merged it with the main branch after thorough testing.
Commit Details: All changes were committed and successfully pushed.
Pull Request Details: This PR includes the fully functioning Bubble Shooter game integrated into the project.

Features of the Bubble Shooter Game

Canvas-based gameplay using JavaScript and HTML5.
Players can shoot bubbles from a cannon, aiming to match three or more bubbles of the same color.
Grid-based system with collision detection to snap bubbles into place and check for matches.
Score updates automatically as bubbles are popped.
Dynamic game environment where bubbles fall when matching sets are removed.
Fully responsive for desktop browsers.

Tags for Admin Consideration
Please make sure the following tags are allocated to this PR:

gihacktoberfest
hacktoberfest-accepted
level3
gssoc-ext

Task Completion Video
https://github.com/user-attachments/assets/a91c04d6-ed1f-4e42-8223-8f0d73df6757
Thank you for reviewing this pull request. I look forward to your feedback and approval.

Checklist:

[x] Created bubble-shooter branch
[x] Completed Bubble Shooter game development
[x] Linked and merged with the main branch
[x] Submitted pull request for review for this project

@iamrahulmahato In this PR i have added two project i.e Simon-Says(Advanced Version) and Shooter Game. I hope that doe not affect in assigning the PR label Tags seperately.

i am closing it make a new pr for this with the issue no

@iamrahulmahato The thing is i mad two pull request one after another and due to that both the PR apper. When I went to raise the PR the both the coomits are still together i.e the projrcts. I solved this over night to reduce confilts. Help me nagivate through .


Ideas for improving resiliency of the client

It seems like it would be useful for the client to have additional resiliency capabilities such as retries, exponential backoff, auto-handling of rate limiting, circuit breaker, etc. that would both protect the caller and callee, both of which would be useful to prevent common situations where services fall like dominoes (e.g. Discovery, then LMS).
Each idea could be ticketed separately.

@johnnagro: Did you say there is enterprise code that might be lifted for some of this?

[inform] From DRF throttling docs:

If the .wait() method is implemented and the request is throttled, then a Retry-After header will be included in the response.

It's unclear to if a custom throttle is required to get this behavior. However, it is possible, and would allow clients to call as efficiently as possible when throttled.


Markdown fixes

This is taking in the fixes from @drodil and adding a couple other small changes in.

This builds on top of this: https://github.com/thearegee/bookworms/pull/7
Then added some more tweaks


Added instruction to modify deviceId variable

If user created a deviceId using a custom deviceId different from the proposed "MyNodeDevice", the deviceId variable needs to be modified accordingly.

@olivoarroba : Thanks for your contribution! The author, @dominicbetts, has been notified to review your proposed change.

Hi @olivoarroba  - many thanks for this suggestion. I don't believe this change is necessary - the previous steps in the article ask you to create a device called MyNodeDevice, and this is the value assigned to the deviceId variable in the code. The only change necessary to the code is the connection string. We tried with the Quickstarts to keep things as simple as possible in order to minimize the code edits. Thanks, Dominic

Alright, it just happens that I gave my device a custom name so I had to edit that. Thanks for the reply.


AttributeError: 'RuntimeJob' object has no attribute 'queue_position'

New problem occurring sometimes on the CI with the remote checks:
See for example https://github.com/CQCL/pytket-qiskit/actions/runs/3739982145/jobs/6347818708#step:7:522

https://github.com/CQCL/pytket-qiskit/pull/53 comments out the use of job_monitor and performs a manual timed check on the RuntimeJob status attribute. This is only a temporary fix as the information we share is less descriptive than that provided by job_monitor, i.e. it does not give a queue position.

This should be solved in the next qiskit release, in case we want to repair this on our end as well :)


bad link to file matching patterns

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

ID: 1d1d9884-19f7-592b-f47c-8cf100639ff0
Version Independent ID: 555c3826-60d9-2589-54af-850efbfbb13a
Content: .NET Core CLI task - Azure Pipelines
Content Source: docs/pipelines/tasks/build/dotnet-core-cli.md
Product: devops
Technology: devops-cicd-tasks
GitHub Login: @pulkitaggarwl
Microsoft Alias: puagarw

Hi @TimShererWithAquent - was this closed on accident?

@spottedmahn It's fixed in the attached PR.

🤦♂

thanks @TimShererWithAquent!

commit for reference: https://github.com/MicrosoftDocs/azure-devops-docs/commit/444e8145869e38f00703d7a63f6ff6d1728ca2a6#diff-f64294218836a69fa679d3e485a599ce0b14801457133588c6d7cdd0281ff4d6
interesting... wonder why markdown links don't work here? 🤔

@spottedmahn Some tables are still formatted as html. Markdown links (and some formatting, I think) doesn't work in an html table.
The longer term fix will be to convert the table to markdown.


Crash whil changing stage as J&E

Crash when going from B1 to B2.
repentance_run_tracker_error_dump-12-05-21-103739PM.zip

I think it's fixed from last hotfix, let me know if there is other issues like this !


[Android] Fix performance issue in recomposition

Problem
Setting the style of the underlying EditText is an expensive operation due to the fact that it forces a re-render. In a traditional view-based app this isn't a problem however, in compose, the wrapper's update block may be called frequently regardless of whether the style argument has changed, causing the the expensive operation to be triggered frequently.
Solution
This change ensures that setting the style in the underlying EditText only takes effect and triggers an expensive re-render if the new style is different to the old style.

Codecov Report
Patch coverage: 88.57% and project coverage change: -0.12% :warning:

Comparison is base (2f1c7cc) 88.34% compared to head (39c8b45) 88.22%.

Additional details and impacted files
@@             Coverage Diff              @@
##               main     #798      +/-   ##
============================================
- Coverage     88.34%   88.22%   -0.12%
- Complexity      370      371       +1
============================================
  Files           154      123      -31
  Lines         17856    16344    -1512
  Branches        862      257     -605
============================================
- Hits          15775    14420    -1355
+ Misses         1850     1717     -133
+ Partials        231      207      -24

Flag
Coverage Δ

uitests
68.03% <88.57%> (-5.83%)
:arrow_down:

uitests-android
68.03% <88.57%> (+0.01%)
:arrow_up:

uitests-ios
?

unittests
88.19% <0.00%> (+1.12%)
:arrow_up:

unittests-android
52.15% <0.00%> (+0.14%)
:arrow_up:

unittests-ios
?

unittests-rust
89.95% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed
Coverage Δ

...io/element/android/wysiwyg/EditorStyledTextView.kt
62.50% <0.00%> (ø)

.../java/io/element/android/wysiwyg/EditorEditText.kt
64.62% <75.00%> (+0.05%)
:arrow_up:

...wysiwyg/compose/internal/RichTextEditorStyleExt.kt
100.00% <100.00%> (+3.22%)
:arrow_up:

...wyg/internal/view/EditorEditTextAttributeReader.kt
100.00% <100.00%> (ø)

...ternal/view/EditorStyledTextViewAttributeReader.kt
100.00% <100.00%> (ø)

...ava/io/element/android/wysiwyg/view/StyleConfig.kt
100.00% <100.00%> (ø)

...siwyg/view/inlinebg/SpanBackgroundHelperFactory.kt
100.00% <100.00%> (ø)

... and 31 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Just wanted to make sure we aren't fixing the wrong part here: Why is the update lambda called so often? In theory it should only be called:

On composition (right after the factory lambda has run).
This should generally not be a performance problem.
Whenever any state reads within the update lambda itself change.
This looks more like the possible culprit. Though it's definitely not normal. So it is worth investigating.

Could we try to do this optimization closer to the source of the issue by reducing the number of times unwanted state changes trigger call to update?
My 2 cents:

The compose compiler doesn't see the RichTextEditorStyle as stable so it will trigger unnecessary recompositions (hence reruns of the update lambda).
The onError lambda is not stable by definition so it might also cause unwanted recompositions (but take this with a grain of salt, I hereby summon @jmartinesp for more help about it).

This page explains how to debug stability issues in compose: https://developer.android.com/jetpack/compose/performance/stability/diagnose

My 2 cents:

The compose compiler doesn't see the RichTextEditorStyle as stable so it will trigger unnecessary recompositions (hence reruns of the update lambda).
The onError lambda is not stable by definition so it might also cause unwanted recompositions (but take this with a grain of salt, I hereby summon @jmartinesp for more help about it).

AFAIK it shouldn't be any of those 2 possible issues that's the root cause here:

RichTextEditorStyle is a data class containing other data classes with either primitives or stable classes (unless I missed something), so it should also be stable.
The onError lambda passed is a function reference in EXA which (if I'm not mistaken) can be compared, unlike a lambda, so it shouldn't cause recompositions.

Then it's even more worth doing some debugging into why that lambda is called so often.

Aha, I thought it seemed a bit fishy that the update block would be triggered despite the variables used there not being updated!
Thanks for the info on debugging stability issues - it turns out instability is the root cause. I'll open a new PR with the fix.


Rails/MatchRoute error

Expected behavior
No error.
Actual behavior
Output:
1 error occurred:
An error occurred while Rails/MatchRoute cop was inspecting /.../pandemic-ebt-ca/config/routes.rb:18:14.
Errors are usually caused by RuboCop bugs.
Please, report your problems to RuboCop's issue tracker.
https://github.com/rubocop-hq/rubocop/issues

Mention the following information in the issue report:
0.88.0 (using Parser <IP_ADDRESS>, rubocop-ast 0.2.0, running on ruby 2.6.6 x86_64-darwin19)
RuboCop failed!

I reverted back to Rubocop 0.87.1, but the problem persisted.
Steps to reproduce the problem
Run rubocop on the following routes.rb file:
https://github.com/codeforamerica/pandemic-ebt-ca/blob/master/config/routes.rb#L17-L19
17            { get: :edit, put: :update }.each do |method, action|
18              match "/#{controller_class.to_param}",
19                    action: action,

RuboCop version
0.88.0 (using Parser <IP_ADDRESS>, rubocop-ast 0.2.0, running on ruby 2.6.6 x86_64-darwin19)

I'm assuming the error lies within the cop Rails/MatchRoute, transfering...


1.20 support

?

Gonna work on it rn!

?

hey you can use it with 1.20.1 normally

?

If you want to build it for 1.20.1 please use this gradle.properties
# Done to increase the memory available to gradle.
org.gradle.jvmargs=-Xmx1G

# Fabric Properties
	# check these on https://modmuss50.me/fabric.html
	minecraft_version=1.20.1
	yarn_mappings=1.20.1+build.9
	loader_version=0.14.21

# Mod Properties
	maven_group = me.aqua
	archives_base_name = NameProtect

# Dependencies
	# check this on https://modmuss50.me/fabric.html
	fabric_version=0.85.0+1.20.1


Bug fix/check document key validity

Scope & Purpose
Assertion thrown in stack below if an empty key is used. Handle it accordingly, produce proper error code.

[x] :hankey: Bugfix (requires CHANGELOG entry)
[ ] :pizza: New feature (requires CHANGELOG entry, feature documentation and release notes)
[ ] :fire: Performance improvement
[ ] :hammer: Refactoring/simplification
[ ] :book: CHANGELOG entry made

Backports:

[ ] No backports required
[x] Backports required for:

Related Information
Crash occured first with setting Replication to 2

[ ] Docs PR:
[ ] Enterprise PR:
[x] GitHub issue / Jira ticket number: https://arangodb.atlassian.net/browse/BTS-253
[ ] Design document:

Testing & Verification
This was discovered during improving the testing.

[ ] This change is a trivial rework / code cleanup without any test coverage.
[ ] The behavior in this PR was manually tested
[x] This change is already covered by existing tests, such as shell-document.js would trigger this missbehaviour.
[ ] This PR adds tests that were used to verify all changes:

[ ] Added new C++ Unit tests
[ ] Added new integration tests (e.g. in shell_server / shell_server_aql)
[ ] Added new resilience tests (only if the feature is impacted by failovers)

[ ] There are tests in an external testing repository:
[x] I ensured this code runs with ASan / TSan or other static verification tools

Link to Jenkins PR run:

http://jenkins01.arangodb.biz:8080/view/PR/job/arangodb-matrix-pr/13139/

http://<IP_ADDRESS>:8080/view/PR/job/arangodb-matrix-pr/13168/

http://<IP_ADDRESS>:8080/view/PR/job/arangodb-matrix-pr/13579/

http://<IP_ADDRESS>:8080/view/PR/job/arangodb-matrix-pr/13579/

http://<IP_ADDRESS>:8080/view/PR/job/arangodb-matrix-pr/13587/

http://<IP_ADDRESS>:8080/view/PR/job/arangodb-matrix-pr/13587/

http://<IP_ADDRESS>:8080/view/PR/job/arangodb-matrix-pr/13593/

http://<IP_ADDRESS>:8080/view/PR/job/arangodb-matrix-pr/13593/

Tests blue

Tests blue


Rename Google.Cloud.Secrets.V1Beta1 to Google.Cloud.SecretManager.V1Beta

Fixes #3977.
We'll do a release in January.

And I think the PR will need to be splitten in two, first all the changes, and then apis.json and regenerate projects? I think that's what's making CI fail.

We can ignore CI - it always fails when things are deleted.

Oh, but maybe not Travis. Will sort it all out tomorrow probably.

Okay, I believe both CI failures are due to it still trying to build Secrets. Merging.


Pretty Progress Printout

It would be really nice to get a printout of the progress of the tests like how cucumber prints it. I'm finding myself constantly trying to figure out which step is broken when using gherking-testcafe.
e.g.
 Running tests in:
 - Chrome 78.0.3904 / Mac OS X 10.14.0

 fixture
..F-..

Failures:

1) Scenario: Signing up a new user # features/example.feature:5
   ✔ Before # features/support/hooks.js:49
   ✔ Given I open the sample app # features/step_definitions/example.js:8
   ✖ When I signup # features/step_definitions/example.js:12

looks like this is where cucumber-js' implementation is. How hard would this be to add?

Hey @anisjonischkeit
I agree, this is very painful.
I investigated this some time back. I figured the best option would be to extend testcafe's reporter API. This would then also solve #7. The problem there is, that the reporter API is very separate from the runner and it's very hard to enhance it (the reporter API) with additional data (like information which steps were successful).
So if you're feeling luck, I would be very happy about very PR in this direction!

Not sure if this is a new thing but to me it looks pretty straightforward to (add metadata to the tests)[https://devexpress.github.io/testcafe/documentation/test-api/test-code-structure.html#specifying-testing-metadata] (unless I'm missing something here).
Looking at the (reporter-plugin docs)[https://devexpress.github.io/testcafe/documentation/extending-testcafe/reporter-plugin/reporter-methods.html] though, it looks like I wouldn't be able to print anything between when a Cucumber Scenario starts and finishes (ie. before/after a step). What do you think about adding an additional reportStepStart/reportStepEnd (or maybe reportStepChange is better since we might get race conditions if we fire these asynchronously) to the reporter object that we can call (before each test)[https://github.com/kiwigrid/gherkin-testcafe/blob/a8c27a6351ccb4126adcd372456cc3f314f2d72f/src/compiler.js#L107].

Wow, you really gave some thought into it. Thank you!
You are right: Out of the box, it is not possible to use the existing reporter API.
The additional methods you mentioned would be the direction I would want to go. But we have a problem there:
As I said, the reporter is very decoupled from the test runner. It actually communicates via an event emitter, that is unreachable from the runner, so we do not have any (simple) means to reach it from there.
My idea was to

emit events when a step starts and ends (I would do two events here - this makes the API more flexible) - make sure meaningful metadata is passed to the function
extend the reporter class to handle those events (see how it's done for fixture start)
Implement the reporter to print your result

Additional thoughts to your comment:

In your first sentence you mentioned to put metadata to the test. I would not do that. It uses the test object in a way it is not intended to be used. We are building tooling around tests, we should be very careful what we pass to the consumer of the APIs.
Steps do not run in parallel. We always await a step before running the next one. So using reportStepStart and reportStepEnd are fine.

Alright, I've made a little start on this.
Regarding 1. are you just talking about passing specific logging data rather than the full step (so that the reporter can't mess with the original step object)? That sounds very sensible to me.
Regarding 2. I understand that the tests run sequentially however in the docs for the reporter, the handlers are all async reportTestStart (so I guess printing can be done asynchronously so that you don't slow down the runner with your printing). I guess as a first implemenation though we could just do the printing synchronously (and thinking about it a little more, I don't think synchronising the async tasks will actually be a problem with a promise chain).
I think I'm starting to understand what you mean regarding the reporter being decoupled from the runner. It looks to me like the reporter is initialised somewhere in testcafe's codebase, do you know if there is any way to get the specific instance that testcafe initialises so that we get this (that has all the functions to write)? I've started by making it so that initialising the reporter returns a singleton with our reportStepStart and reportStepEnd methods but I'm not sure if this will cause a problem anywhere else; if there is anything that might require multiple instances of a reporter (possibly running tests in parallel). Ideally I'd like to just get the instance initialised in testcafe.

Regarding 1. are you just talking about passing specific logging data rather than the full step (so that the reporter can't mess with the original step object)? That sounds very sensible to me.

No, I meant that I would not add the cucumber steps to the test or fixture metadata. I would be fine with passing the cucumber step to the reporter.

Regarding 2. I understand that the tests run sequentially however in the docs for the reporter, the handlers are all async reportTestStart (so I guess printing can be done asynchronously so that you don't slow down the runner with your printing). I guess as a first implemenation though we could just do the printing synchronously (and thinking about it a little more, I don't think synchronising the async tasks will actually be a problem with a promise chain).

Very true. But this is something that the reporter needs to handle.

I think I'm starting to understand what you mean regarding the reporter being decoupled from the runner. It looks to me like the reporter is initialised somewhere in testcafe's codebase, do you know if there is any way to get the specific instance that testcafe initialises so that we get this (that has all the functions to write)? I've started by making it so that initialising the reporter returns a singleton with our reportStepStart and reportStepEnd methods but I'm not sure if this will cause a problem anywhere else; if there is anything that might require multiple instances of a reporter (possibly running tests in parallel). Ideally I'd like to just get the instance initialised in testcafe.

The reporters are initialized in the runner. We replace the runner in runner.js, so we do have direct access to the reporters.
Maybe, we need to change the whole logic of how the compiler exposes the tests and how the runner consumes them to make this work nicely.
But if I'm being honest about it, I don't know the internal logic (i.e. where is the test created, where is it consumed, where are events emitted, where are they consumed, ...) well enough to point you into the right direction here. This would need some serious digging on my side.


WIP Camera Shake

Adds noise-based camera shake. A camera shake can be started in the TestScene by pressing spacebar.
The shake code itself uses methods that seem to be widely standard in the Godot community. References included in the code.
Below I've detailed the reasoning behind the introduction of the _pending_node_updates system.
Regarding the new array
There's a few weird things in here that I wanted feedback on before going too much further.
I ran into an issue with the new CameraShaker node and the existing SpringArm3D node which necessitated the creation of the _pending_node_updates array. The ThirdPersonCamera.gd script provides exports for properties which are defined on children nodes. This allows useful functionality such as allowing editing "inner properties" when the scene is instantiated in other scenes. But it appears that when one sets a non-default value for any of these properties, one of the first things Godot 4.2.1 does on start up is call the set function. This caused an exception due to the child node not being initialized yet.
For example, when I set a non-default value in the editor for the spring_arm_collision_mask, a call to the set function was dispatched immediately on start-up. This meant that when it got to the line
$RotationPivot/OffsetPivot/CameraSpringArm.collision_mask = value
The $ (get_node) call would be unable to retrieve a node as the CameraSpringArm was not ready yet. Thus an exception would result in attempting to access collision_mask on a nil object.
The _pending_node_updates array was introduced as a way to "defer" the update until _physics_process ran. At that point the children nodes would have to be ready, and thus a get_node call on their Node path would succeed.
This pattern was further complicated by default values not getting a set call. If the code and the Editor agree, then the Editor has no need to submit set calls on Node start-up. But then this meant that default values would not be pushed down to the children nodes. Thus I added to the _ready function the "identity" assignments like
shake_volatility = shake_volatility
This guarantees a set call at the beginning so that we can push the values down to the sub nodes. (Another option would be to set the defaults of the children nodes to agree with the defaults of the root ThirdPersonCamera node. But this introduces a potential source of confusing user error that I wanted to avoid.)
I'm wondering a bit whether I have simply misunderstood something fundamental in Godot about how to set children node properties. Let me know if there's a better way to go about this.

Thanks for the camera shake implementation. 🚀
About the issue leading to _pending_node_updates
I encountered the exception related to the children node not being initialized yet, at early stage of development, when accessing them through their onready variable (_camera_spring_arm, _camera_shaker). However, using $ in the setter seemed to bypass this issue on my end.
Anyway, I have a proposition for that particular issue. Instead of employing an array to store updates, I've introduced the _set_when_ready function. This function checks if the ThirdPersonCamera is ready before attempting to set the value. If the ThirdPersonCamera is not yet ready, the function waits for it to be ready before assigning the value.
I made a Pull request to your branch: eistre91#1

I merged in your PR and added in a new resource called CameraShakePreset. The idea is that a developer could set up the different types of shake they need for different events, and then the different shakes can be accessed from the top level ThirdPersonCamera.

Thank.
I will test and review that soon.


Cyclical imports of modules

I am writing some more utility functions for numbat, currently I'm working on str_split which splits a string into a list of strings based on a string pattern. I Would like to put this in the core::strings module as that fits it very well, but because I need the core::lists module and it already has a dependency on the former, this is not possible. I think it would be beneficial to either allow such cyclical dependencies or to document how such cases aught to be handled.
I know F# disallows cyclical dependencies, so if we don't want to support it, maybe we could look to it for other approaches to handle such cases.

I stumbled over this topic in numbat once earlier and I think it is actually possible at the moment to have cyclical dependencies of modules on each other as long as the actual functions/function calls in them don't cyclically depend on each other. Whichever module gets imported first will just be ignored the second time the same use statement appears.
That said, cyclical imports may cause a lot of trouble and should be discouraged if not prohibited in my eyes.

I think it is actually possible at the moment to have cyclical dependencies of modules on each other as long as the actual functions/function calls in them don't cyclically depend on each other.

If so, I couldn't manage to make it work. I was developing a new function, so nothing else depended on it, but depending on module load order either lists or strings module threw an error due to an unrecognized name the first time the respective module used a function from the other.

I don't know your exact code of course but I would suspect that you have the use statement before all functions needed by the other module are defined (probably on the very top of the file as we usually do). If you do it "over cross" it should work, e.g:
a.nbt:
# Functions to be used in b.nbt
fn f_a1(x) = x
fn f_a2(x) = x + 1

use b

# Functions using functions from b.nbt
fn f_a3(x) = f_b1(x) * f_b2(x)

b.nbt:
# Functions to be used in a.nbt
fn f_b1(x) = x
fn f_b2(x) = x - 1

use a

# Functions using functions from a.nbt
fn f_b3(x) = f_a1(x) + f_a2(x)

This is quite error prone and not very ergonomic of course which is why I think it should be avoided.

You are exactly right about how I did it. I see now why it didn't work the way I tried it. I very much agree that this should be avoided. I would rather make a new file than import mid file unless there is very compelling reason for it.

I agree with everything that has been said. If we implement more fine-grained importing and a better module structure, I think we could selectively import certain functions without causing trouble. This works well in languages like Rust, for example. Until then, let's split files and build a tree-like structure without any cycles, if possible.

I am considering an approach where I add a folder with the name of the file being split. Then the original file can just use the modules in the folder similar to prelude, but each file can be imported independently if desired.
So for example when splitting strings.nbt the following file structure would result:
strings.nbt
strings/
    foo.nbt
    bar.nbt

Where the strings::foo and strings::bar modules are the modules the original strings module were split into.
Would that be an acceptable way to split the files?


grpc_python_plugin not installed with pip install grpcio-tools?

I am experimenting the python grpc hello world example.
gPRC tools is installed with python3.6 pip.
$ python -m pip install grpcio
$ python -m pip install grpcio-tools

$ python -m grpc_tools.protoc --version
libprotoc 3.5.1

And compile using grpc tools as a python module works fine.
$ python -m grpc_tools.protoc -I. --python_out=. --grpc_python_out=. helloworld.proto

I would like to also try to using the system protoc to compile, however, this fails due to grpc_python_plugin is not found.
$ protoc --version
libprotoc 3.5.1

$ protoc -I. --python_out=. --grpc_python_out=. --plugin=protoc-gen-grpc=`which grpc_python_plugin` helloworld.proto

protoc-gen-grpc_python: program not found or is not executable
--grpc_python_out: protoc-gen-grpc_python: Plugin failed with status code 1.

I then built grpc_python_plugin from gits, and it works fine.
$ git clone https://github.com/grpc/grpc.git
$ git submodule update --init
$ make grpc_python_plugin

$ ls ~/gits/grpc/bins/opt/
grpc_python_plugin  protobuf

$ protoc -I. \
    --python_out=. \
    --grpc_python_out=. \
    --plugin=protoc-gen-grpc_python=~/gits/grpc/bins/opt/grpc_python_plugin \
    helloworld.proto

In summary, my questions:

From my understanding, the first approach, e.g., using python module is preferred, right?
What is the difference between the two approaches, python module grpc_tools, and protoc with grpc plugin?
Is it possible to get the grpc_python_plugin via pip install, or similar way?

PS:
I explored protoc with grpc plugins to compile python and javascript out together, which works fine.
protoc -I. \
    --python_out=. \
    --grpc_python_out=. \
    --plugin=protoc-gen-grpc_python=`which grpc_python_plugin` \
    --js_out=import_style=commonjs,binary:. \
    --grpc_out=. \
    --plugin=protoc-gen-grpc=`which grpc_tools_node_protoc_plugin` \
    helloworld.proto

Thank you very much!

From @iamnoah #26210 -
I would just comment on #15675 if it were not locked, but just wanted to point out there is an easy solution for those looking for a binary for the python gRPC plugin:
pip install grpclib protobuf
The plugin binary is then available as protoc-gen-grpclib_python or protoc-gen-python_grpc in the bin/ directory for your python env. (If you are using buf, it can be used as name: python_grpc or name: grpclib_python.)


Object references or IDs in tree

Can we get a reference identification in the tree view for objects/arrays?
req: Object
    connection: Object { ... } #15
    res: Object { ... } #16
    trailers: Object { ... } #17
res: Object { ... } #16

Eclipse does something similar:

It's convenient for eyeballing references.

Sounds like low hanging fruit. Why not? I think it is a good idea.

https://youtu.be/-QRZpligDOs
On Sat, Sep 3, 2016, 21:36 Daniel Brännström<EMAIL_ADDRESS>wrote:

Sounds like low hanging fruit. Why not? I think it is a good idea.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kiddkai/atom-node-debugger/issues/183#issuecomment-244565810,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABn5MWnlD7BNCqwyk5ZxE40RbgWaNLjuks5qmcw7gaJpZM4JXN8o
.

Implemented and merged to master. Sample screen shot:


CSS style error for link page

See: https://forum.casbin.com/go/node-casbin/links

@oceanlvr I don't think this issue got fixed, see: https://forum.casbin.com/go/casbin/links

@hsluoyz Sorry, it was my mistake that caused not all file to be submitted completely, I do some change in app.js but not commit.
I fix this style error now.


Not work under osx

Please fix, looking forward to make https://travis-ci.org/snowyu/node-nosql-leveldb/ green!

Can compile above node v7 now. But It can not destroy iterator on Mac when exiting.
You can try your unit test.

Thanks. Could you please publish the latest code to NPM?
Then I'll be able to test it in my project.

Try this:
"dependencies" : {
"nosql-leveldb" : "git://github.com/snowyu/node-nosql-leveldb.git"
}

Bad news: it Segmentation fault again.
See: https://travis-ci.com/zixia/flash-store/jobs/131516727

All tests passed on Mac. You can try it again now.

Released 3.0.1.


fix(supermediaplayer): use time base to correct pts

Signed-off-by: pingkai<EMAIL_ADDRESS>

Codecov Report

Merging #631 (2904b79) into develop (954fa45) will increase coverage by 0.08%.
The diff coverage is 60.00%.

@@             Coverage Diff             @@
##           develop     #631      +/-   ##
===========================================
+ Coverage    66.89%   66.98%   +0.08%
===========================================
  Files          230      230
  Lines        12885    12899      +14
===========================================
+ Hits          8620     8640      +20
+ Misses        4265     4259       -6

Impacted Files
Coverage Δ

mediaPlayer/SMPMessageControllerListener.cpp
72.05% <25.00%> (-2.31%)
:arrow_down:

mediaPlayer/SuperMediaPlayer.cpp
73.54% <66.66%> (+0.87%)
:arrow_up:

mediaPlayer/SuperMediaPlayer.h
90.69% <100.00%> (+0.14%)
:arrow_up:

mediaPlayer/subTitle/subTitleSource.h
20.00% <0.00%> (-60.00%)
:arrow_down:

framework/demuxer/play_list/SegmentList.cpp
72.83% <0.00%> (-7.41%)
:arrow_down:

mediaPlayer/subTitle/subTitleSource.cpp
85.71% <0.00%> (-2.39%)
:arrow_down:

framework/demuxer/play_list/HLSStream.cpp
64.17% <0.00%> (-1.31%)
:arrow_down:

framework/demuxer/play_list/SegmentTracker.cpp
73.55% <0.00%> (-0.83%)
:arrow_down:

mediaPlayer/MediaPlayer.cpp
68.51% <0.00%> (-0.20%)
:arrow_down:

... and 10 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 954fa45...2904b79. Read the comment docs.

Codecov Report

Merging #631 (2904b79) into develop (954fa45) will increase coverage by 0.08%.
The diff coverage is 60.00%.

@@             Coverage Diff             @@
##           develop     #631      +/-   ##
===========================================
+ Coverage    66.89%   66.98%   +0.08%
===========================================
  Files          230      230
  Lines        12885    12899      +14
===========================================
+ Hits          8620     8640      +20
+ Misses        4265     4259       -6

Impacted Files
Coverage Δ

mediaPlayer/SMPMessageControllerListener.cpp
72.05% <25.00%> (-2.31%)
:arrow_down:

mediaPlayer/SuperMediaPlayer.cpp
73.54% <66.66%> (+0.87%)
:arrow_up:

mediaPlayer/SuperMediaPlayer.h
90.69% <100.00%> (+0.14%)
:arrow_up:

mediaPlayer/subTitle/subTitleSource.h
20.00% <0.00%> (-60.00%)
:arrow_down:

framework/demuxer/play_list/SegmentList.cpp
72.83% <0.00%> (-7.41%)
:arrow_down:

mediaPlayer/subTitle/subTitleSource.cpp
85.71% <0.00%> (-2.39%)
:arrow_down:

framework/demuxer/play_list/HLSStream.cpp
64.17% <0.00%> (-1.31%)
:arrow_down:

framework/demuxer/play_list/SegmentTracker.cpp
73.55% <0.00%> (-0.83%)
:arrow_down:

mediaPlayer/MediaPlayer.cpp
68.51% <0.00%> (-0.20%)
:arrow_down:

... and 10 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 954fa45...2904b79. Read the comment docs.


Update (new version) of MEF3 format (MED).

Hello,
I am Matt Stead, the creator of all the MEF formats (1-3).  The new version MEF version (MED) is faster & produces better compression than its predecessors. It continues to be HIPAA & IRB compliant. A fuller description of MED is available on https://MEDFormat.org.
I currently have 4 groups asking me about official BIDS compatibility.
MED data can be read in open source multiple tools (Matlab, FieldTrip, EEGLab, Python , Neo).
These tools are freely available in compiled form for all major platforms (MacOS, Linux, Windows) as well as having source code and specification documents available on https://github.com/MEDFormat.
There are also multiple free data converters (MEF, EDF, DAT, Neuralynx (NCS & NRD), & NATUS) available.
I would be happy to make the pull request for this.
@bids-standard/raw-electrophys-ieeg

FWIW I'm +1 on this, but I don't work with these data.
I believe the places to update in the schema would be:

https://github.com/bids-standard/bids-specification/blob/master/src/schema/objects/extensions.yaml
https://github.com/bids-standard/bids-specification/blob/master/src/schema/rules/files/raw/ieeg.yaml

I did open https://github.com/MEDFormat/MEDPython/issues/6, though. The usability of a GPL'd Python library is questionable if users do not want to GPL their own code. I am having trouble digging up references, but I recall seeing some lack of clarity whether Python's import mechanism triggered LGPL or not. IIRC the most similar license that was definitely safe for use in non-GPL Python projects was the Mozilla Public License v2.

I am +1 on this as well, as long as we can make sure that the old MEF3 format remains valid.

Totally agree with this we already started using MED in BIDS.

Hi all, we fully support this as we would also like to use MED in BIDS in our Epilepsy Research Group.

Hello everyone, we are also a few research groups in Grenoble, France to use the MED format and are hoping for it to be included in the BIDS format! Thank you.

Hello, I confirm that having MED in BIDs would be really useful for the management and sharing of the data of our database. Thank you!

We'd be very glad to have both MED and MEF3 in BIDS!

I think @effigies described the next steps above. Are there any examples you are interested in adding as well?

Hi Dora,
I’ll try to get into this tomorrow.  I’ve been busy adding parity capabilities to MED library (optional damage recovery mechanism).  think it will be finished today.
I think I have the info I need to do this.  It looked pretty easy.
Cheers, Matt
￼
Matt Stead
@.***

On Oct 10, 2024, at 11:10 AM, dorahermes @.***> wrote:
I think @effigies https://github.com/effigies described the next steps above. Are there any examples you are interested in adding as well?
—
Reply to this email directly, view it on GitHub https://github.com/bids-standard/bids-specification/issues/1931#issuecomment-2405641723, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATNKTHUUODFJMRVQ2JGKIQLZ22YHNAVCNFSM6AAAAABO5W2BXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBVGY2DCNZSGM.
You are receiving this because you authored the thread.

Hi Chris,
I did the changes & pull requests that you recommended, but on one it failed a check:
https://github.com/bids-standard/bids-specification/pull/1957￼
Update ieeg to include MED.yaml by MEDFormat · Pull Request #1957 · bids-standard/bids-specification
github.com
The check error is in "schemacode_ci / Validate schema”
Which gives this for the test details:
=========================== short test summary info ============================
FAILED tools/schemacode/bidsschematools/data/tests/test_rules.py::test_rule_objects - AssertionError: Undefined objects found in rules: files.deriv.preprocessed_data.ieeg_ieeg_common.extensions[0] == .medd/
files.raw.ieeg.ieeg.extensions[0] == .medd/
============ 1 failed, 1 passed, 66 deselected, 2 warnings in 7.59s ============
I looked around for that file, but I could not find it.
Any chance you can point me to it?
Cheers, Matt
￼
Matt Stead
@.***

On Sep 26, 2024, at 2:05 PM, Chris Markiewicz @.***> wrote:
FWIW I'm +1 on this, but I don't work with these data.
I believe the places to update in the schema would be:
https://github.com/bids-standard/bids-specification/blob/master/src/schema/objects/extensions.yaml
https://github.com/bids-standard/bids-specification/blob/master/src/schema/rules/files/raw/ieeg.yaml
I did open MEDFormat/MEDPython#6 https://github.com/MEDFormat/MEDPython/issues/6, though. The usability of a GPL'd Python library is questionable if users do not want to GPL their own code. I am having trouble digging up references, but I recall seeing some lack of clarity whether Python's import mechanism triggered LGPL or not. IIRC the most similar license that was definitely safe for use in non-GPL Python projects was the Mozilla Public License v2.
—
Reply to this email directly, view it on GitHub https://github.com/bids-standard/bids-specification/issues/1931#issuecomment-2377833243, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATNKTHVXMNZAGHNNILQ7RI3ZYRSIPAVCNFSM6AAAAABO5W2BXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZXHAZTGMRUGM.
You are receiving this because you authored the thread.

I'll merge those into a single PR...

Hi all. If iEEG users (ping @dorahermes @cimbi @EmmanuelBarbeau @michaelpereira73 @KLehongre @tjr1, who have chimed in already) could have a review of https://github.com/bids-standard/bids-examples/pull/469/files to make sure that it looks correct, that would be greatly appreciated.
@MEDFormat provided an emptied data directory, and I updated it along the lines of the already existing ieeg_epilepsy example. Validation is passing on the schema validator using the schema changes proposed in #1956. I have not made a plan to update the legacy validator, though it would not be difficult if someone wants this to be available in the legacy validator (you would just update these lines).
The main thing that needs review is that this dataset would be understandable to iEEG researchers and work with BIDS tools.

Hi Chris,
From what I can see it looks like MED is BIDS approved.  If I’m wrong about that, please let me know.
Cheers, Matt
￼
Matt Stead
@.***

On Oct 18, 2024, at 7:48 AM, Chris Markiewicz @.***> wrote:
Hi all. If iEEG users (ping @dorahermes https://github.com/dorahermes @cimbi https://github.com/cimbi @EmmanuelBarbeau https://github.com/EmmanuelBarbeau @michaelpereira73 https://github.com/michaelpereira73 @KLehongre https://github.com/KLehongre @tjr1 https://github.com/tjr1, who have chimed in already) could have a review of https://github.com/bids-standard/bids-examples/pull/469/files to make sure that it looks correct, that would be greatly appreciated.
@MEDFormat https://github.com/MEDFormat provided an emptied data directory, and I updated it along the lines of the already existing ieeg_epilepsy example. Validation is passing on the schema validator using the schema changes proposed in #1956 https://github.com/bids-standard/bids-specification/pull/1956. I have not made a plan to update the legacy validator, though it would not be difficult if someone wants this to be available in the legacy validator (you would just update these lines https://github.com/bids-standard/bids-validator/blob/bec5fea5318953073dc8b97908f11a77ca00845e/bids-validator/bids_validator/rules/file_level_rules.json#L454-L463).
The main thing that needs review is that this dataset would be understandable to iEEG researchers and work with BIDS tools.
—
Reply to this email directly, view it on GitHub https://github.com/bids-standard/bids-specification/issues/1931#issuecomment-2422522081, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATNKTHSUBRF2HTFB24PABILZ4EGSTAVCNFSM6AAAAABO5W2BXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRSGUZDEMBYGE.
You are receiving this because you were mentioned.

From what I can see it looks like MED is BIDS approved. If I’m wrong about that, please let me know.

just to be pedantic: things become "official"' in BIDS when there is a new release (usually when a BIDS extension proposal is merged), so until there is a new release, features that have been merged in the default branch of the specification are not yet will only become official BIDS approved on the next release
We usually have 1or 2 releases a year and the last one was in September.

Thanks, Remi.
Cheers, Matt
￼
Matt Stead
@.***

On Nov 8, 2024, at 12:56 AM, Remi Gau @.***> wrote:
From what I can see it looks like MED is BIDS approved. If I’m wrong about that, please let me know.
just to be pedantic: things become "official"' in BIDS when there is a new release (usually when a BIDS extension proposal is merged), so until there is a new release, features that have been merged in the default branch of the specification are not yet will only become official BIDS approved on the next release
We usually have 1or 2 releases a year https://github.com/bids-standard/bids-specification/releases and the last one was in September.
—
Reply to this email directly, view it on GitHub https://github.com/bids-standard/bids-specification/issues/1931#issuecomment-2463987556, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATNKTHQBNUQNSSU5UOFSN4LZ7RVBBAVCNFSM6AAAAABO5W2BXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRTHE4DONJVGY.
You are receiving this because you were mentioned.


could test.sh operate in unprivileged mode?

since https://github.com/gmkurtzer/singularity/pull/159 is merged, I thought it would be nice to avoid sudoing while testing for various reasons ;)

I suspect we'd need a separate test.sh to avoid using sudo.
One problem we have is any use of raw disk images will require a setuid binary for the next year or so: you can only use chroot directories.

Not all of test.sh uses sudo, I'd suggest we just have a set of tests that are not calling sudo and operate on a directory in which the test image would be exported to.
A year? hehe, you are optimistic! I wonder if the loop devices would ever be namespaced. Have you heard anything on this?
Thanks!

I think that, once FUSE mounts are available to unprivileged users, then libguestfs would provide the ability to read/write the filesystem (alternately, fuseext may work).  Based on current progress, it seems reasonable to guess this would be available to mainline kernels within a year.  That would mean RHEL8 or so?
Looks like loopback device support would be feasible, but perhaps further out.

I am going to close this because I don't think there is much that can be done (at least not at present and/or for a while). Fuze integration does potentially offer a really good option if loop devices can not be made namespace-able. Feel free to comment to the thread if you feel I should re-open it.
Thanks!


Make Stanzas/ExtensionElements immutable

Requires major changes in the OmemoMessage class :/
Return copies of arrays only, make attributes final and remove all setters

I made OmemoMessage and OmemoBundle immutable. I'll let OmemoDeviceList as it is, since it inherits HashSet.


thank u! Gonna check that

thank u! Gonna check that
Originally posted by @pitser90 in https://github.com/atom/atom/discussions/23437#discussioncomment-1892071

Thanks for reaching out!
We require the template to be filled out on all new issues and pull requests. We do this so that we can be certain we have all the information we need to address your submission efficiently. This allows the maintainers to spend more time fixing bugs, implementing enhancements, and reviewing and merging pull requests.
Thanks for understanding and meeting us half way 😀


Add tests showing IOptions

Rename MerakiDashboardClientSettings to MerakiDashboardClientOptions.
Remove MerakiDashboardClientSettingsSetup.
Update README.md.

Also, add a test to ensure MerakiDashboardClient public methods are virtual.

Tests pass. Approved.


How to reduce the false positive from the Request Missing an Accept Header (9200300) rule in the Azure Web Application Gateway (WAF)?

Hello everyone,
I oversee the monitoring of Azure WAF logs through Splunk. Currently, there's a significant volume of false positive traffic generated by Azure WAF, leading to frequent triggers of anomaly detection and creating a considerable amount of noise. The browser do show that there are Accept header when I Inspect the web page however the rule is still being trigger. Therefore, I'm seeking ways to address this issue.
[Refer to the screenshots below]

My initial solution was to use Exclusion List in Azure Portal to exclude this specific type of traffic but no avail. In addition, I submitted a support ticket to Microsoft Azure to address this concern. However, the suggested solution was to disable the rule, which isn't ideal for my requirements. Disabling the rule would mean that any potentially malicious traffic might go unnoticed, as the rule wouldn't be able to flag it.

Do you have any pro tips or alternative solutions? Thanks.

Hello @JacobChua12345 ,
In some cases, it may be reasonable to disable a rule entirely per the suggestion that you received previously. Rules that do not directly identify an attack string, but merely identify something unusual can be decent candidates for such consideration.
However, it is also often a good idea to see if one can resolve an issue with false positives by limiting when the rule is executed, rather than disabling a rule entirely.
You don't specify what you mean by 'this specific type of traffic'. If there are clear conditions under which these FPs occur, then you can exclude the action of 920300 by using a new rule that checks for those conditions and then uses (for example) the ctl:ruleRemoveById action.

Q: What is ctl:ruleRemoveById? and how does it help to reduce/remove these FPs?
The specific type of rule I meant was the Request Missing an Accept Header. However, the web page do have Accept header.
By referencing this website: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1751
Definition of the rule is as followed:
The rule is designed to identify and raise an alert for requests that do not include an "Accept" header, except in cases where it is an OPTIONS request or the request is coming from specific User Agents (WebKit or Android)
This is my Accept header and it obviously doesn't statisfy the rule but it is still being triggered.

If that is the case how do I solve it? I tried to exclude the Accept Header, HTTP Request Method & the Cookie but it didn't work.

@JacobChua12345 the CoreRuleSet project is not part of Trustwave's ModSecurity engine, but a separate project run by OWASP, you might have more luck with your question on their github project https://github.com/coreruleset/coreruleset

@EarlRoth Alright, I have submitted a issue to coreRuleSet. Can I request to keep this issue open? Thank you.

Hello @JacobChua12345 ,
I don't think there's an advantage to keeping this item open in addition to your new one on the other repo (absent any discovery of an actual engine issue).


Search repos by username

Users can enter a GitHub username and see a list of all repos from that account.

Repos with no open issues will display a checkmark.

Repos with open issues will display an X with the number of issues or pull requests

completed


add-category les-rayons-uv-quels-effets-sur-la-sante-et-celle-de-vos-…

…enfants.md

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


Enable MFA from the UI should redirect to MFA setup to logged users.

Current Result
There's a 404 in the Network tab
Expected result
It should be redirected to /multifactor_authentication and block any other URL
Additional info
The redirection takes place in Rails here but we should also check this
See this comment to reproduce the static.js redirection locally

There's a PR in progress that adds support for redirecting specific ajax requests depending on the error code + payload sent by the server.
I've talked with @jesusbotella and we can just add support for this case in that PR. Steps would be:

Return 401 + a payload to say redirect_to_multifactor_authentication from here when format.json. We may want to avoid using redirect_or_not_found
Add a file like this one that handles the 401 and redirect_to_multifactor_authentication
Import and set the new interceptor on the dashboard javascript files.


Review bar and "sticky" file header layout regression

Due to #26711 (and other old PRs) , now the "sticky" file header doesn't work well with uncertain review bar height.
Before, the sticky top was hard-coded to 2 magic numbers, but the "review bar" has been changed many times and it uses "flex" layout, the height is not predictable.

Height needs to be predictable for sticky to work, unless there is another solution but I'm not aware of.

I am not working on it either, just open an issue for record.


removed calls to cursor_set_visible on all platforms fixes #10167

First we remove mesege, then we remove curser, the curse generator... what's next, get rid of shit?!?

I made the effort of changing the commit message. Only the branch still is cursed...


docs: random bits

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 55.23%. Comparing base (5c5b217) to head (26de6cf).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #93      +/-   ##
==========================================
+ Coverage   54.97%   55.23%   +0.26%
==========================================
  Files          10       10
  Lines        1146     1146
==========================================
+ Hits          630      633       +3
+ Misses        437      435       -2
+ Partials       79       78       -1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


starred expression throws a syntax error - python 3.9.4

After this change I'm getting an exception with Python 3.9.4:
$ python3 tbui.py
Traceback (most recent call last):
  File "/home/.../src/twixtbot-ui/src/tbui.py", line 14, in <module>
    import files as fi
  File "/home/.../src/twixtbot-ui/src/files.py", line 217
    return (*parse_tsgf_file(content)), enable_crossing_lines
            ^
SyntaxError: can't use starred expression here

removing parentheses helps

Indeed. My pull request #73 didn't include parenthesis. @steven68 added them, but afaik they shouldn't be there...

Without brackets it didn't work with Python 3.6
Python 3.9 is not yet supported (see README.md), i.e. we do no syntax checks with github workflows.

Thanks for clarifying this. Well, that Python... (minor version change brings syntax change, wtf?)

... going forward I'd like to support 3.9 as well.  I will look into it. Maybe agtoever's suggestion will work for all 4 versions.


"core-js": "^2.5.7" deprecated

I use "@tableau/embedding-api": "3.9.0" in one of my projects. And in one day my npm ci stuck. The reason was "core-js": "^2.5.7", because this version is deprecated: https://www.npmjs.com/package/core-js?activeTab=versions
"core-js": "^2.5.7" is peerDependencies of @tableau/api-internal-contract-js
@tableau/api-internal-contract-js is dependencies of @tableau/embedding-api

I am facing the same problem; the CI/CD pipeline is stuck because of npm ci.

I am facing the same problem; the CI/CD pipeline is stuck because of npm ci.

npm ci --legacy-peer-deps


Ingress with no path will cause a panic

Ingress with no path will cause a panic
If no path is set the HTTP field is nil causing a panic. The below yaml cause Rancher to panic.
apiVersion: extensions/v1beta1
kind: Ingress
spec:
  rules:
  - host: hostname

https://github.com/rancher/rancher/issues/27230


Multiple requests (XHR) are fired for each Radio Listener change

Describe the bug
When multiple Radio items (either group of Radio or single RadioButtons component) are used within layout that utilize Listener there are multiple XHR requests performed on each click ie. for 3 items:

first click: 1 request
second click: 2 requests
third click: 4 requests
4th -> 6
5th -> 13
6th -> 23 requests and so on

When Select component is used there is always only one XHR request triggered on value change (valid behavior)
To Reproduce

Create a Screen with some layout that have at least two radio items (Radio with the same name or RadioButtons component)
Add  some Listener that will change a layout rows/columns below the radio fields
Open the view in your webbrowser with devtools network tab active
Observe the request counter on each radio/radiobutton click

📄 SampleScreen
    public function layout(): array
    {
        return [
            Layout::rows([
                RadioButtons::make('item')
                    ->options([
                        'A' => 'One',
                        'B' => 'Two',
                        'C' => 'Three'
                    ])
                    ->title(__('Item')),
                    ]),
            ItemListener::class
        ];
    }

    public function asyncSwitchItem($item){
        return [];
    }`

📄 ItemListener
    protected $targets = ['item'];
    protected $asyncMethod = 'asyncSwitchItem';

    protected function layouts(): array
    {
        return [
            Layout::rows([
                Input::make('field')->title(__('Some field'))
            ])
        ];
    }

Expected behavior
One XHR per click
Server:

Platfrom Version: 9.19.8
Laravel Version: 8
PHP Version:  7.4

Thanks @tabuna I thought that if part of the layout will be replaced after field value has changed it should be separated from it. Your solution suits my current use case and solves problem of redundant XHRs


CORE-7034: draft new higher level signing interface for discussion

Add higher level signing operations that work out SignatureSpec based on key and possibly digest algorith,.

My own playing around lead to:
@CordaSerializable
data class DigitalSignatureMetadata(
    val timestamp: Instant,
    val signatureSpec: SignatureSpec,
    val properties: Map<String, String>
)

@CordaSerializable
data class DigitalSignatureAndMetadata(
    val signature: DigitalSignature.WithKeyHash,
    val metadata: DigitalSignatureMetadata
)

interface SignatureSpecService {
    @Suspendable
    fun getDefaultSignatureSpec(publicKey: PublicKey, digestAlgorithm: DigestAlgorithmName): SignatureSpec?

    @Suspendable
    fun getCompatibleSignatureSpecs(publicKey: PublicKey, digestAlgorithm: DigestAlgorithmName): List<SignatureSpec>
}

interface SigningService {
    @Suspendable
    fun sign(
        bytes: ByteArray,
        publicKey: PublicKey,
        signatureSpec: SignatureSpec
    ): DigitalSignature.WithKeyHash

    @Suspendable
    fun sign(
        bytes: ByteArray,
        metadataProperties: Map<String, String>,
        digestAlgorithm: DigestAlgorithmName,
        publicKey: PublicKey
    ): DigitalSignatureAndMetadata

}

@DoNotImplement
interface DigitalSignatureVerificationService {
    @Suspendable
    fun verify(
        bytes: ByteArray,
        expectedPublicKey: PublicKey,
        signatureSpec: SignatureSpec,
        signature: DigitalSignature
    )

    @Suspendable
    fun verify(
        bytes: ByteArray,
        expectedPublicKey: PublicKey,
        signature: DigitalSignatureAndMetadata
    )

}

I also think this PR needs to include re-adding a HashDigestFactory to applucation/crypto, because it is currently sending people off to wrong module to make SecureHash

My own playing around lead to:
@CordaSerializable
data class DigitalSignatureMetadata(
    val timestamp: Instant,
    val signatureSpec: SignatureSpec,
    val properties: Map<String, String>
)

I'd want to make this named metadataProperties,  to be consistent with

@CordaSerializable
data class DigitalSignatureAndMetadata(
val signature: DigitalSignature.WithKeyHash,
val metadata: DigitalSignatureMetadata
)
interface SignatureSpecService {
@Suspendable
fun getDefaultSignatureSpec(publicKey: PublicKey, digestAlgorithm: DigestAlgorithmName): SignatureSpec?
@Suspendable
fun getCompatibleSignatureSpecs(publicKey: PublicKey, digestAlgorithm: DigestAlgorithmName): List<SignatureSpec>

}
interface SigningService {
@Suspendable
fun sign(
bytes: ByteArray,
publicKey: PublicKey,
signatureSpec: SignatureSpec
): DigitalSignature.WithKeyHash

Any reason not to put metadataProperites on this overload as well as the next one?
The caller still has to cope with consistently putting the DiigitalSignture together with the payload and signed-over metadata, in such a way that verify will take it.
So I think we either returned a new SignedMessage data class, which has a toBytes() method, or return the bytes directly if we don't want people poking around inside the signed message.

@Suspendable
fun sign(
    bytes: ByteArray,
    metadataProperties: Map<String, String>,
    digestAlgorithm: DigestAlgorithmName,
    publicKey: PublicKey
): DigitalSignatureAndMetadata

So, you're requiring people here to get any non-string  metadata down to strings, ideally in a standardised way? I imagine this could be a source of errors, so we may want to support a small number of additional metadata arguments, e.g. secureHashMetadataProperites of tpe Map<String, SecureHash> with the requirement that the keys do not conflict, so that the caller doesn't need to figure out how to do that.

}
@DoNotImplement
interface DigitalSignatureVerificationService {
@Suspendable
fun verify(
bytes: ByteArray,
expectedPublicKey: PublicKey,
signatureSpec: SignatureSpec,
signature: DigitalSignature
)
@Suspendable
fun verify(
bytes: ByteArray,
expectedPublicKey: PublicKey,
signature: DigitalSignatureAndMetadata
)
}

Should this return the metadata, so that a caller can pass in the full bytes of the signed document, and verify would pull out the metadata, and return it deserialised?

The intent was that the
@Suspendable
fun sign(
bytes: ByteArray,
publicKey: PublicKey,
signatureSpec: SignatureSpec
): DigitalSignature.WithKeyHash

is a raw signing facility it signs precisely the bytes you give it.
the
@Suspendable
fun sign(
    bytes: ByteArray,
    metadataProperties: Map<String, String>,
    digestAlgorithm: DigestAlgorithmName,
    publicKey: PublicKey
): DigitalSignatureAndMetadata

version forms a DigitalSignatureMetadata with the chosen SignatureSpec set correctly and then concatenates the users's ByteArray and the Serialized DigitalSignatureMetadata to sign. returning the signature itself plus metadata in the DigitalSignatureAndMetadata. So this is a safer to use form, but it does include some implicit logic around precisely how the bytes to sign are formed. I would be fine with making public (as we used to) a
@CordaSerializable
data class SignableData(val bytes: ByteArray, val metadata: DigitalSignatureMetadata)

to document this serialization better and allow you to independently construct a signature from the raw API.
Also, it is becoming clear that we need a version of sign that can identify which keys in a set are owned by you and return those  signatures. This is needed for ledger logic, though we definitely do need the internal service in Flow Engine to store key mappings so that we can reduce the number of expensive queries required to locate our own keys. A method signature would probably be:
@Suspendable
fun signWithOwnedKeys(
bytes: ByteArray,
metadataProperties: Map<String, String>,
digestAlgorithm: DigestAlgorithmName,
publicKey: Set
): List

This seems to have diverged considerably from what I thought we had agreed! I thought we had agreed:

Keep signing and verifying as basic operations that sign bytes and verify bytes against signature object
Do not regard SignatureSpec as being inside signed materials as part of signing service API. Instead have separated service to get correct SignatureSpec for a specific public key and hashing algorithm name. Up to user to make byte array that does contain this info and then sign
Put in separate service for that SignatureSpec determination that can get 'default' SignatureSpec, but also list of all compatible SignatureSpecs.
Make output of signing DigitalSignature.WithId rather than DigitalSignature.WithKey to prevent mis-use of the PublicKey in DigitalSignature.WithKey.
Put back in a proper DigestService into application/crypto
Provide a method that will take a set of public keys and can sign with those keys (or leaves of any composite keys) that we own.

Closing after slack discussion with @mnesbit's summarised in his comment this morning.


Error while starting zigbee2MQTT

zigbee2mqtt add-on version (if edge, please report commit hash):
Operating environment (HassOS, Virtual Machine, Device/platform running Home Assistant):
HassOS 4.13
Description of problem:
This stopped working at last night without any changes. I flashed my CC2531 stick again without any help CC2531ZNP-with-SBL.hex
Your entire configuration from the frontend (with sensitive fields redacted):
data_path: /share/zigbee2mqtt
external_converters: []
devices: devices.yaml
groups: groups.yaml
homeassistant: true
permit_join: true
mqtt:
  base_topic: zigbee2mqtt
  server: 'mqtt://<IP_ADDRESS>:1883'
  user: mqtt
  password: mqtt
serial:
  port: /dev/ttyACM0
advanced:
  pan_id: 6754
  channel: 11
  network_key:
    - 1
    - 3
    - 5
    - 7
    - 9
    - 11
    - 13
    - 15
    - 0
    - 2
    - 4
    - 6
    - 8
    - 10
    - 12
    - 13
  availability_blocklist: []
  availability_passlist: []
  availability_timeout: 60
device_options: {}
blocklist: []
passlist: []
queue: {}
frontend:
  port: 8099
experimental:
  new_api: true
socat:
  enabled: false
  master: 'pty,raw,echo=0,link=/dev/ttyZ2M,mode=777'
  slave: 'tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5'
  restartdelay: 1
  initialdelay: 1
  options: '-d -d'
  log: false

Your logs from Home Assistant
><EMAIL_ADDRESS>start /zigbee2mqtt-1.15.0
> node index.js
Zigbee2MQTT:info  2020-10-16 10:46:47: Logging to console and directory: '/share/zigbee2mqtt/log/2020-10-16.10-46-47' filename: log.txt
Zigbee2MQTT:info  2020-10-16 10:46:48: Starting Zigbee2MQTT version 1.15.0 (commit #1.15.0)
Zigbee2MQTT:info  2020-10-16 10:46:48: Starting zigbee-herdsman...
Zigbee2MQTT:error 2020-10-16 10:47:08: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2020-10-16 10:47:08: Failed to start zigbee
Zigbee2MQTT:error 2020-10-16 10:47:08: Exiting...
Zigbee2MQTT:error 2020-10-16 10:47:08: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)
    at ZStackAdapter.<anonymous> (/zigbee2mqtt-1.15.0/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:92:31)
    at Generator.throw (<anonymous>)
    at rejected (/zigbee2mqtt-1.15.0/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:25:65)
npm
 ERR! code ELIFECYCLE
npm ERR! errno 1
npm
 ERR<EMAIL_ADDRESS>start: `node index.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2020-10-16T07_47_08_294Z-debug.log
2020-10-16T10:47:08: PM2 log: App [npm:0] exited with code [1] via signal [SIGINT]
2020-10-16T10:47:08: PM2 log: App [npm:0] starting in -fork mode-
2020-10-16T10:47:08: PM2 log: App [npm:0] online
><EMAIL_ADDRESS>start /zigbee2mqtt-1.15.0
> node index.js
Zigbee2MQTT:info  2020-10-16 10:47:11: Logging to console and directory: '/share/zigbee2mqtt/log/2020-10-16.10-47-11' filename: log.txt
Zigbee2MQTT:info  2020-10-16 10:47:12: Starting Zigbee2MQTT version 1.15.0 (commit #1.15.0)
Zigbee2MQTT:info  2020-10-16 10:47:12: Starting zigbee-herdsman...
Zigbee2MQTT:error 2020-10-16 10:47:32: Error while starting zigbee-herdsman
Zigbee2MQTT:error 2020-10-16 10:47:32: Failed to start zigbee
Zigbee2MQTT:error 2020-10-16 10:47:32: Exiting...
Zigbee2MQTT:error 2020-10-16 10:47:32: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)
    at ZStackAdapter.<anonymous> (/zigbee2mqtt-1.15.0/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:92:31)
    at Generator.throw (<anonymous>)
    at rejected (/zigbee2mqtt-1.15.0/node_modules/zigbee-herdsman/dist/adapter/z-stack/adapter/zStackAdapter.js:25:65)
npm
 ERR! code ELIFECYCLE
npm ERR! errno 1
npm
ERR<EMAIL_ADDRESS>start: `node index.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2020-10-16T07_47_32_816Z-debug.log
2020-10-16T10:47:33: PM2 log: App [npm:0] exited with code [1] via signal [SIGINT]
2020-10-16T10:47:33: PM2 log: App [npm:0] starting in -fork mode-
2020-10-16T10:47:33: PM2 log: App [npm:0] online
><EMAIL_ADDRESS>start /zigbee2mqtt-1.15.0
> node index.js
Zigbee2MQTT:info  2020-10-16 10:47:36: Logging to console and directory: '/share/zigbee2mqtt/log/2020-10-16.10-47-36' filename: log.txt
Zigbee2MQTT:info  2020-10-16 10:47:37: Starting Zigbee2MQTT version 1.15.0 (commit #1.15.0)
Zigbee2MQTT:info  2020-10-16 10:47:37: Starting zigbee-herdsman...
Zigbee2MQTT:info  2020-10-16 10:47:47: zigbee-herdsman started
Zigbee2MQTT:info  2020-10-16 10:47:47: Coordinator firmware version: '{"meta":{"maintrel":2,"majorrel":2,"minorrel":7,"product":2,"revision":20190425,"transportrev":2},"type":"zStack30x"}'
Zigbee2MQTT:info  2020-10-16 10:47:47: Currently 0 devices are joined:
Zigbee2MQTT:warn  2020-10-16 10:47:47: `permit_join` set to  `true` in configuration.yaml.
Zigbee2MQTT:warn  2020-10-16 10:47:47: Allowing new devices to join.
Zigbee2MQTT:warn  2020-10-16 10:47:47: Set `permit_join` to `false` once you joined all devices.
Zigbee2MQTT:info  2020-10-16 10:47:47: Zigbee: allowing new devices to join.
Zigbee2MQTT:info  2020-10-16 10:47:47: Started frontend on port 8099
Zigbee2MQTT:info  2020-10-16 10:47:47: Connecting to MQTT server at mqtt://<IP_ADDRESS>:1883
Zigbee2MQTT:info  2020-10-16 10:47:48: Connected to MQTT server
Zigbee2MQTT:info  2020-10-16 10:47:48: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload 'online'
Zigbee2MQTT:info  2020-10-16 10:47:48: MQTT publish: topic 'zigbee2mqtt/bridge/info', payload '{"commit":"1.15.0","config":{"advanced":{"adapter_concurrent":null,"availability_blacklist":[],"availability_blocklist":[],"availability_passlist":[],"availability_timeout":60,"availability_whitelist":[],"cache_state":true,"cache_state_persistent":true,"cache_state_send_on_startup":true,"channel":11,"elapsed":false,"ext_pan_id":[221,221,221,221,221,221,221,221],"homeassistant_discovery_topic":"homeassistant","homeassistant_legacy_triggers":true,"homeassistant_status_topic":"hass/status","last_seen":"disable","legacy_api":true,"log_directory":"/share/zigbee2mqtt/log/%TIMESTAMP%","log_file":"log.txt","log_level":"info","log_output":["console","file"],"log_rotation":true,"log_syslog":{},"pan_id":6754,"report":false,"soft_reset_timeout":0,"timestamp_format":"YYYY-MM-DD HH:mm:ss"},"ban":[],"blocklist":[],"device_options":{},"devices":{"0x680ae2fffe97ad47":{"friendly_name":"0x680ae2fffe97ad47"},"0x680ae2fffea7e281":{"friendly_name":"0x680ae2fffea7e281"},"0x680ae2fffef91930":{"friendly_name":"0x680ae2fffef91930"},"0xec1bbdfffe2de77b":{"friendly_name":"0xec1bbdfffe2de77b"},"0xec1bbdfffe8811cb":{"friendly_name":"0xec1bbdfffe8811cb"},"0xec1bbdfffe8812d5":{"friendly_name":"0xec1bbdfffe8812d5"},"0xec1bbdfffe9ebc14":{"friendly_name":"0xec1bbdfffe9ebc14"}},"experimental":{"new_api":true,"output":"json"},"external_converters":[],"frontend":{"port":8099},"groups":{},"homeassistant":true,"map_options":{"graphviz":{"colors":{"fill":{"coordinator":"#e04e5d","enddevice":"#fff8ce","router":"#4ea3e0"},"font":{"coordinator":"#ffffff","enddevice":"#000000","router":"#ffffff"},"line":{"active":"#009900","inactive":"#994444"}}}},"mqtt":{"base_topic":"zigbee2mqtt","include_device_information":false,"password":"mqtt","server":"mqtt://<IP_ADDRESS>:1883","user":"mqtt"},"passlist":[],"permit_join":true,"queue":{},"serial":{"disable_led":false,"port":"/dev/ttyACM0"},"whitelist":[]},"coordinator":{"meta":{"maintrel":2,"majorrel":2,"minorrel":7,"product":2,"revision":20190425,"transportrev":2},"type":"zStack30x"},"log_level":"info","network":{"channel":11,"extended_pan_id":"0x00124b0014d47b96","pan_id":6755},"permit_join":true,"version":"1.15.0"}'
Zigbee2MQTT:info  2020-10-16 10:47:48: MQTT publish: topic 'zigbee2mqtt/bridge/devices', payload '[{"definition":null,"endpoints":{"1":{"bindings":[],"clusters":{"input":[],"output":[]}},"11":{"bindings":[],"clusters":{"input":["ssIasAce"],"output":["ssIasZone","ssIasWd"]}},"110":{"bindings":[],"clusters":{"input":[],"output":[]}},"12":{"bindings":[],"clusters":{"input":[],"output":[]}},"13":{"bindings":[],"clusters":{"input":["genOta"],"output":[]}},"2":{"bindings":[],"clusters":{"input":[],"output":[]}},"242":{"bindings":[],"clusters":{"input":[],"output":[]}},"3":{"bindings":[],"clusters":{"input":[],"output":[]}},"4":{"bindings":[],"clusters":{"input":[],"output":[]}},"47":{"bindings":[],"clusters":{"input":[],"output":[]}},"5":{"bindings":[],"clusters":{"input":[],"output":[]}},"6":{"bindings":[],"clusters":{"input":[],"output":[]}},"8":{"bindings":[],"clusters":{"input":[],"output":[]}}},"friendly_name":"Coordinator","ieee_address":"0x00124b0014d47b96","interview_completed":true,"interviewing":false,"network_address":0,"supported":false,"type":"Coordinator"}]'
Zigbee2MQTT:info  2020-10-16 10:47:48: MQTT publish: topic 'zigbee2mqtt/bridge/groups', payload '[]'
Zigbee2MQTT:info  2020-10-16 10:47:48: MQTT publish: topic 'zigbee2mqtt/bridge/config', payload '{"commit":"1.15.0","coordinator":{"meta":{"maintrel":2,"majorrel":2,"minorrel":7,"product":2,"revision":20190425,"transportrev":2},"type":"zStack30x"},"log_level":"info","network":{"channel":11,"extendedPanID":"0x00124b0014d47b96","panID":6755},"permit_join":true,"version":"1.15.0"}'

It seems your add-on is working now. But the error: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms) is usually happening when z2m can't connect to the stick.
This is not really a problem of the add-on but of the z2m (issues go here: https://github.com/Koenkk/zigbee2mqtt/issues/new/choose)
To solve this you usually have a few action courses (that you can try in order):

Press reset button on stick
Removing and reinserting the stick
Re-flashing the stick firmware

@McPaHa Can you confirm if your add-on is working now?

Oh sorry... It's working now
su 1. marrask. 2020 klo 12.27 Marius<EMAIL_ADDRESS>kirjoitti:

@McPaHa https://github.com/McPaHa Can you confirm if your add-on is
working now?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/danielwelch/hassio-zigbee2mqtt/issues/449#issuecomment-720066051,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIVYJNE5KEUZ2OFJAERWMHLSNUZYTANCNFSM4SS7XC6A
.


Automatically play when network is restored

I use exoplayer play hls(live-m3u8), when the network is interrupted, the player throw an exception "ERROR_CODE_IO_NETWORK_CONNECTION_FAILED", but after network is restored, the player does not continue to play, I need register network listener and setPlayWhenReady(true)?

I need register network listener and setPlayWhenReady(true)?

Yes, this sounds about right to me. You'd have to call prepare() though, as playWhenReady does not change when an playback exception occurs.
You can configure the load error handling by setting a configured or custom LoadErrorHandlingPolicy. There a section in the developer guide about this.
By default the load error handling policy will retry a couple of times. The player continues to play out the available buffered media and then transitions into STATE_IDLE with a playback exception.
In the case you are describing, an app can call prepare() again when the network is restored.
I don't think that ExoPlayer should resolve a playback error itself by guessing the reason being network outage that came back again. One reason is that ExoPlayer actually doesn't know from where media is loaded. This can be the network, a local file, the local cache or other sources. Simply listening to network availability wouldn't generally work I think - an app can handle this better.

I need register network listener and setPlayWhenReady(true)?我需要注册网络监听器和setPlayWhenReady（true）？

Yes, this sounds about right to me. You'd have to call prepare() though, as playWhenReady does not change when an playback exception occurs.是的，这听起来对我来说是正确的。但是你必须调用 prepare() ，因为当播放异常发生时 playWhenReady 不会改变。
You can configure the load error handling by setting a configured or custom LoadErrorHandlingPolicy. There a section in the developer guide about this.您可以通过设置已配置或自定义的 LoadErrorHandlingPolicy 来配置加载错误处理。在开发者指南中有一节是关于这个的。
By default the load error handling policy will retry a couple of times. The player continues to play out the available buffered media and then transitions into STATE_IDLE with a playback exception.默认情况下，加载错误处理策略将重试几次。播放器继续播放可用的缓冲媒体，然后转换到 STATE_IDLE ，但出现播放异常。
In the case you are describing, an app can call prepare() again when the network is restored.在您所描述的情况下，当网络恢复时，应用可以再次调用 prepare() 。
I don't think that ExoPlayer should resolve a playback error itself by guessing the reason being network outage that came back again. One reason is that ExoPlayer actually doesn't know from where media is loaded. This can be the network, a local file, the local cache or other sources. Simply listening to network availability wouldn't generally work I think - an app can handle this better.我不认为ExoPlayer应该通过猜测网络中断的原因来解决播放错误。一个原因是ExoPlayer实际上不知道媒体从哪里加载。这可以是网络、本地文件、本地缓存或其他源。我认为，简单地听取网络可用性通常不会起作用-一个应用程序可以更好地处理这一点。

Thank you for providing the imformation;it has given me a clearer understanding of the issue.


Workaround for syntax highlighting issue in GitHub

BTW, any idea were to report this syntax highlighting issue? In the linguist repo maybe?

BTW, any idea were to report this syntax highlighting issue? In the linguist repo maybe?

Not directly, see: https://github.com/github/linguist#theres-a-problem-with-the-syntax-highlighting-of-a-file
The provider for C++ is https://github.com/textmate/c.tmbundle

Thanks, looks the same as textmate/c.tmbundle#51

Cherry-picked for 3.1.1.


Question: Embed Hue dashboard in custom application

Hi,
does Hue have a support for embedding into custom applications? We like the dashboarding capabilities that Hue offers, and we'd like to make it part of our app - using iframe (or some other mechanism).
Does Hue already have this feaure? Or is it at least planned? Or we are on our own? (if so, can you please share any hints).
Thank you in advance!

A revamp of the chart is coming. First step will be to make it easier to share links/reports. Embedding is not decided yet but might come afterwards.


Kafka ch controller should not recreate the dispatcher if it is missing

Describe the bug
Kafka ch controller recreates the Kafka ch dispatcher when it sees the dispatcher deployment is missing and this causing ownership problems when the Kafka channel components are deployed with an operator.
For example, at OpenShift Serverless we install the Knative Kafka components with our operator.
This operator simply applies the YAML in the manifest, which includes the Kafka ch dispatcher as well. When the installation CR is deleted, operator deletes everything in the manifest YAML including the Kafka ch dispatcher deployment.
However, Kafka ch dispatcher deployment is sometimes recreated by the Kafka ch controller, if Kubernetes decides to delete the Kafka ch controller pod after the Kafka ch dispatcher deployment. What I mean is, controller often has time to react and recreate the dispatcher deployment before the pod is stopped by Kubernetes.
Our operator, or, basically any operator that installs Knative Kafka components, need to own the dispatcher deployment otherwise it cannot propagate the readiness and it cannot do proper cleanups.
Expected behavior
The issue here is that we have 2 owners for the Kafka ch dispatcher deployment. What we suggest is that Kafka ch controller should only touch the replica count and nothing else. It should not recreate the dispatcher deployment if it is missing.
To Reproduce
Knative release version
0.21
Additional context

need to own the dispatcher deployment otherwise it cannot propagate the readiness

Can you elaborate more on that? why can't it propagate the readiness otherwise?

Kafka ch controller should only touch the replica count and nothing else

Why would the controller touch the replica count? I thought scaling the dispatcher deployment is a user concern, so either via yaml/kubectl or via the operator that installs the channel.

need to own the dispatcher deployment otherwise it cannot propagate the readiness
Can you elaborate more on that? why can't it propagate the readiness otherwise?

Sure. If you the dispatcher pod is crashing, operator needs to state this in the installation CR (KnativeKafka in OpenShift Serverless case) status. Before, operator wasn't owning the dispatcher pod and there were some scenarios where the image was wrong for the dispatcher but the operator was saying "all good".

Why would the controller touch the replica count? I thought scaling the dispatcher deployment is a user concern, so either via yaml/kubectl or via the operator that installs the channel.

The idea is that don't start the dispatcher pod unless there's a Kafka channel created. This is done to save resources. Dispatcher pods are shared among Kafka channels, so the traditional "create the pod when channel is created and delete it when the channel is deleted" approach can't be used. For example, for KafkaSource, we create the adapter per source and delete the adapter when source CR is deleted. This is not the case here.
I guess we can even get rid of this optimization and start running the pod with 1 replica directly.

If the dispatcher pod is crashing, operator needs to state this in the installation CR (KnativeKafka in OpenShift Serverless case) status.

I think the operator can watch for the status without owning the deployment right? .
IMHO I think this approach is correct. The controller should only care about "is there a ready dispatcher" for the channel status reasons. The yaml (and subsequently the operator) should create/delete/scale the deployment. And have the replicas in the repo config yaml set to 1.

I think the operator can watch for the status without owning the deployment right? .

Yeah, but then we need to do additional checks like manually querying the API server for dispatcher deployment existence and checking the status. We don't do that currently.

I guess we can even get rid of this optimization and start running the pod with 1 replica directly.

Even if we set it here to just 1 replica, the deployment it still touched.
/cc @lionelvillard


fixing the sync job and adding dry run param

Codecov Report

Merging #367 into release-1.14-sprint2 will not change coverage.
The diff coverage is n/a.

@@                   Coverage Diff                   @@
##             release-1.14-sprint2     #367   +/-   ##
=======================================================
  Coverage                   40.83%   40.83%
  Complexity                    765      765
=======================================================
  Files                         110      110
  Lines                        7536     7536
  Branches                      850      850
=======================================================
  Hits                         3077     3077
  Misses                       4132     4132
  Partials                      327      327

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 ae3f039...d04f823. Read the comment docs.


Tidy root directory of ocm-repository

Description
The root directory of the ocm repository is cluttered with files and directories.
As part of the Open-Source readiness initiative, the root directory should look well structured. To achieve this, we have to tidy up the repository - delete unused files and move the files to the place where they belong.
TODO

[x] Delete sonar-project.properties
[x] Move CODEOWNER to .github (see doc)
[ ] Move VERSION and version.go if possible
[x] Move https://github.com/open-component-model/ocm/blob/main/migrate.sh, https://github.com/open-component-model/ocm/blob/main/migrate.mig, and https://github.com/open-component-model/ocm/blob/main/migrate.md
[ ] ...

If you see some more, please adjust the description

we keep the VERSION file as is.