OpenAI Integration not working

What version of Music Assistant has the issue?
2024.1.0
The problem
Using the provided prompt for the openai integration, and the provided yaml file for the custom_sentences/en folder, I cannot get anything to work with the assistant. I was able to get it to function with Jlo's automation blueprint, but I wanted to use the built in handling for other rooms / devices.
How to reproduce
I followed all instructions provided in the FAQ, and typed "play linkin park on rbr speaker" or any other device name, artist name, etc.
Relevant log output
Unexpected error during intent recognition
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/assist_pipeline/pipeline.py", line 988, in recognize_intent
conversation_result = await conversation.async_converse(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/conversation/init.py", line 543, in async_converse
result = await agent.async_process(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/conversation/default_agent.py", line 221, in async_process
result = await self.async_recognize(user_input)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/conversation/default_agent.py", line 195, in async_recognize
lang_intents = await self.async_get_or_load_intents(language)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/conversation/default_agent.py", line 544, in async_get_or_load_intents
return await self.hass.async_add_executor_job(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/conversation/default_agent.py", line 631, in _get_or_load_intents
merge_dict(intents_dict, custom_sentences_yaml)
File "/usr/local/lib/python3.12/site-packages/hassil/util.py", line 20, in merge_dict
assert isinstance(
AssertionError: Not a dict: None
Additional information
Server is running in a docker container on an unraid machine, version 2.0.0b93.
What version of Home Assistant Core are your running
2024.2.1
What type of installation are you running?
Home Assistant OS
On what type of hardware are you running?
Raspberry Pi

That is an error in the HA pipeline so not a problem with MA. Have you removed the Blueprint?

I removed the automation, yes. Now testing stuff, it seems like built in intents aren't working either. I guess something is broken in my instance.
I realized I can source the automation details from within the blueprint yaml file, so I just made my own automation using his as a basis. I guess I'll just build my own out for room awareness and device specific playback like I've done for lights, fans, etc. It is working fine this way at least.

I didnt ask about the automation I asked about whether you had removed the blueprint.

You might run into issues doing it that way but god luck!

The blueprint template was left there available to use, but I removed the automation that was created by the template. I think we are on the same page now? Unless having a template downloaded is a problem.
Thanks for the assist!

Could be I am not sure as I don't use them. I would remove that if you aren't using it. With the new assist feedback sentences you should be able to get some useful info. You can also add the following to your configuration.yaml so you can see more detail about the intent failure
    logger:
      default: warning
      logs:
        homeassistant.components.conversation: debug
        homeassistant.components.intent: debug

@monogoat I've only just set it up today and it's not working for me, so I'm keen to see if you had any luck getting it going.


Add prop for onCancel

Add a prop that accepts a callback that will execute when the user presses the cancel button.
Right now, I'm manually controlling the visibility of the ModalSelector, but I have no way to when the user has selected cancel other than onModalClose, but I can't use that because I'm manually controlling the visibility.

The cancel button fires close() which calls this.props.onModalClose(item).  That always fires when the cancel button is pressed.
https://github.com/peacechen/react-native-modal-selector/blob/master/index.js#L193
If you're creating the button yourself, you have complete control over its callback. I might not be understanding your question fully. Please submit a PR if a change is required in this library.


bpf: Compile bpf_netdev.c with build permutations

Add a make target for bpf_netdev.c to compile it against permutations of the most common options.
Helps to catch bpf_netdev.c compile errors faster than waiting until cilium-agent -> bpf/init.sh returns them.

This change is

test-me-please

Coverage increased (+0.05%) to 45.952% when pulling 2c4ee9c7887a95f445824b9b35b2ab1fb8485387 on pr/brb/make_bpf_netdev into cc100d07c0d6336fed10d6d8183fa34bdc1b6b3c on master.

CI provisioning failed.

test-me-please


add necessary packages to devDependencies

Issue: #6
What Changed
Currently, there are dependencies which should be devDependencies in the external dependencies. This issue causes projects which use Storybook, using this package as a dependency, to install these packages. The @types packages which are installed are added to these projects' installed types, forcing dependencies to be type checked at these particular versions. There is no workaround built into TypeScript for installing transient@types from packages, see https://github.com/microsoft/TypeScript/issues/18588.
This issue blocks my project from upgrading to Storybook 6.5.9, as lodash is having its types checked when we have version 4.17.21 installed and do not enforce strong typing on our use of lodash. The other changes are just good practice.
How to test
Run a build and run the tests.
Change Type

[x] maintenance
[ ] documentation
[ ] patch
[ ] minor
[ ] major

@aschlumpf — Thank you for your contribution! I've assigned a relevant maintainer to take a look as soon as they're able.

Love this PR!
The prettier dependency "prettier": ">=2.2.1 <=2.3.0", is quite annoying and breaking stuff.

👍 this'll unlock some of our prettier issues ❤

This also closes https://github.com/storybookjs/mdx1-csf/pull/10 💯

@shilman Any updates here for merging this in?

@shilman +1000 The prettier dependencies cause a bunch of problems, and there doesn't seem to be a way to override this. Would love to update prettier to 2.8.1 + keep it up to date!!

This update to the prettier version would help immensely! The main @storybook packages use version 2.8.1, which unlocks some fixes around generics, namely enabling prettier to properly parse typeof x<Type> syntax, where you're passing a generic to a typeof. As it's just a dev dependency, merging this PR would enable us to not use an older version of prettier and instead correctly use 2.8.1 like we'd like to!

Any  update on this?

@shilman Can we please try and get this merged soon? Thank you!

@chrisburkejr Thank you, it says I need approval from someone with write access in order to merge.


test: add setTimeout tests

Timeout was supported as-is, I've only added automated tests.

[!IMPORTANT]
http.request(u, { timeout: n }) and http.request(u).setTimeout(n) are NOT the same! The first acts on the http.Agent level, adding timeout to every net.Socket once it's created. The second, however, ignores the agent and sets the timeout on the socket once it emits the "connect" event. The first takes the connection time into account, the second doesn't.

How the first works
How the second works

I've opened a pull request to the Node.js docs (https://github.com/nodejs/node/pull/52576) to help emphasize this difference.

In the context of Interceptors, this difference is important because we can reproduce http.request(u, { timeout: n }) by making the request listener take more time than the specified timeout, but the http.request(u).setTimeout(n) must receive either a mocked or bypassed response headers before it's even added (socket connect emitted).

The latter is, technically, our limitation because we cannot emit connect on the socket until we know whether the request is mocked or bypassed. In practice, that doesn't matter because you are either mocking a response or not. We treat the mocked response headers as the initiator of the socket connection.

Also adds a this.destroyed check in passthrough() and respondWith() so they'd have no effect if the socket has been destroyed (e.g. aborted or timed out).

@mikicho, I think you should know about the difference I outlined above. See if Nock understands those two different timeouts and treats them the same. It's rather tricky and undocumented, and I wouldn't be surprised if it didn't.

I also suspect that AbortSignal.timeout(n) will act similarly to setting a timeout. But I expect it to result in the "abort" event on the request.

See if Nock understands those two different timeouts...

Nock is aware of these two, and it actually uses it for throwing a timeout error immediately if the timeout is bigger than what is defined in the interceptor.
This is a nifty feature that MSW (or mswjs/intrceptors) should consider.
P.S: when I tried to implement this for the fetch API, it turned out that the delay connection feature doesn't make much sense because Fetch doesn't provide this level of granularity.

This is a nifty feature that MSW (or mswjs/intrceptors) should consider.

Interceptors do not decide that for you so they shouldn't do anything on top of what Node.js does. Node.js doesn't do anything to the request, not even destroys it. It only emits the timeout event for you do handle that timeout in whichever fashion you want. I think it should stay that way.

delay connection feature doesn't make much sense because Fetch doesn't provide this level of granularity.

Yep, I remember that!

Interceptors do not decide that for you so they shouldn't do anything on top of what Node.js does

Nock does not change Node.js behavior here:

with "auto timeout,": timeout event emits immediately.
Without: Nock waits X seconds and emits a timeout event.


Factored WebSocket handling out of OrderBook to allow for easy creation of custom order book implementations

For my own work I needed to modify your code to subscribe to the ticker channel instead of the full orderbook. Your OrderBook code was already well segmented into code that dealt with the Websocket and code that implemented the actual order book. So rather than modify your code I factored the Websocket code out into an abstract base class and then changed your OrderBook class to inherit from it.  Now anyone with your API wrapper can easily inherit from WebSocketFeedListener to create their own order book, ticker, or level2 implementations without having to modify your API.
Since the OrderBook still has the same class signature as it originally did, your tests cases all pass without any changes to them. Happy to make changes if you see something you don't like. Details on each change below:

WebSocketFeedListener

Factored the web socket code away from the actual orderbook
implementation. The new WebSocketFeedListener is an abstract base class
that handles the websocket itself including:

Connect
Disconnect
Send / Receive messages
Subscribing to channels
Leveraging the trade log file
Async Context Manager calls

WebSocketFeedListener inherits from ABC and has a single @abstractmethod
handle_message(self), which must be implemented by subclasses.

OrderBook

Removed all WebSocket manipulation from OrderBook and left just the
OrderBook implementation. OrderBook now inherits from
WebSocketFeedListener and implements handle_message.

Thanks!
Code looks good, I'd just ask you to change the commit message so that it includes a one-liner of what it does. Right now it shows up as just a bunch of asterisks in the log.

Will do - sorry about that.

I amended the commit message. Will that work?


Rework the startup scan-for-incorrect-shred-version scan

Problem
The backup_and_clear_blockstore() method that a validator may call at startup has several flaws. A much lengthier description is provided later, but the issues are:

Only 80% of the cluster (by stake) must participate in a cluster restart. By participating in cluster restart, the blockstore cleanup is guaranteed to happen. For the other 20% of stake, this cleanup occurring is dependent on validators supplying the correct args after the fact.
As written, the blockstore scan that checks if there is cleanup necessary will run for 60s before timing out. This step is critical in cluster restarts, but could ideally be avoided for "regular" validators restarts (ie when an operator upgrades software versions) to minimize downtime.

Additional context about cluster restarts and blockstore cleaning
Cluster Restarts
A typical cluster involves the following:

Choosing a slot RESTART_SLOT to restart at (typically the latest optimistically confirmed slot that contains at least one non-vote tx)
Validators creating a snapshot at RESTART_SLOT with ledger-tool create-snapshot RESTART_SLOT --hard-fork RESTART_SLOT ...
Validators restartand supplying --expected-shred-version, --wait-for-supermajority RESTART_SLOT, and --expected-bank-hash RESTART_SLOT_BANK_HASH args to their validator

When RESTART_SLOT is chosen, it is almost always the case that leaders continue to create blocks with slot > RESTART_SLOT. That is, leaders continue to produce blocks even though the cluster fails to confirm/finalize those blocks. Given that RESTART_SLOT is chosen, any of these blocks for slot > RESTART_SLOT are to be considered invalid. We are able to detect and cleanup this state by the following means:

When validators create the restart snapshot, they supply --hard-fork RESTART_SLOT. The shred_version that gets encoded in shreds is derived from the hard forks array stored in a Bank, and the addition of a new hard fork will change the shred version

Let OLD_SV be the old shred version and NEW_SV the new shred version

When validators restart with the aforementioned cluster restart arguments, the following block is entered that will scan the blockstore and purge any shreds with slot > RESTART_SLOT and shred_version != NEW_SV

The implication here is that there could be shreds in the Blockstore with slot > RESTART_SLOT with shred_version == OLD_SV

https://github.com/anza-xyz/agave/blob/6e067fcd28620a32eab8461ad5e5be79e28d41f7/core/src/validator.rs#L600-L614
The cluster restarts when 80% of the cluster is in the wait-for-supermajority loop; this means that 80% will have supplied the necessary arguments to enter the loop (and cleanup the stale blockstore state).
The described workflow works for the 80%; however, the other 20% is where problems arise. In a perfect world, all validator operators would supply these new args to ensure their blockstores are properly cleaned. However, an inattentive operator may restart their node at a later time without the cluster restart args (ie just download snapshot from cluster). Without those args, the cleanup logic will not be run and the result is that the stale state may cause problems for that validator.
One more unfortunate piece is that validators who perform regular restarts on their node (non-cluster-restart such as for a software upgrade) might leave those cluster restart parameters in place. Leaving those parameters in place means the node will perform that scan at startup, which will timeout after 60s. The 60s scan means more time unnecessarily offline which is obviously non-ideal:
https://github.com/anza-xyz/agave/blob/6e067fcd28620a32eab8461ad5e5be79e28d41f7/core/src/validator.rs#L2184-L2191

Proposed Solution

The blockstore scan currently only occurs when the --wait-for-supermajority and --expected-shred-version arguments were supplied. We could instead move the blockstore scan to occur AFTER unpacking the snapshot; we can determine the shred version after the Bank is rebuilt by reading out the hard forks.
This part is tricky. An obvious case isroot_bank.slot() == wait_for_supermajority_slot (assuming a WFSM slot was set). However, that is essentially the existing behavior we already have. We're more interested in being able to programmatically determine when we need to run the scan and/or making the scan faster. More thought will be needed for this aspect, but a few ideas to start out:

Check only the first shred in each slot, instead of every shred. I'll probably do this anyways and I'll go into more detail in that PR on why this is valid
Check slots in parallel; we're still early in startup so contention for CPU time shouldn't be awful
Check to see if the latest (or any really) hard fork lies within the min & max blockstore slots. If so, that tells us that a restart happened "recently" and it could be worthwhile to look. On the other hand, if the oldest blockstore slot is newer than the latest hard fork, we might be in the clear to skip the scan
Always perform the scan starting from root bank slot. Assuming default snapshot config, this would mean only scanning several 100 slots which should go pretty quick, especially in light of the other optimizations I mentioned above

@AshwinSekar - Finally got around to writing this up, feel free to weigh in as we had talked about this / I know you had thought about it a bit

As a side note, there is some cleanup we can do regarding the expected_shred_version as well as the shred_version ingested through gossip via the entrypoint.
Gossip will always connect using the shred version via the entrypoint, regardless of any cli flag:
https://github.com/anza-xyz/agave/blob/f11b777e9bbbfdaa6550003ebe36c37331acd037/gossip/src/cluster_info.rs#L3204-L3207
https://github.com/anza-xyz/agave/blob/f11b777e9bbbfdaa6550003ebe36c37331acd037/gossip/src/cluster_info.rs#L1782-L1796
For the initial backup and clear we use the gossip shred version if the cli flag is not set. Otherwise we proceed with the cli flag:
https://github.com/anza-xyz/agave/blob/5769cc1792b3c00b28dd04807243a12a8543286b/validator/src/main.rs#L1128-L1130
https://github.com/anza-xyz/agave/blob/f11b777e9bbbfdaa6550003ebe36c37331acd037/core/src/validator.rs#L595-L598
And finally after loading blockstore we set the shred_version to what is computed from hard_forks:
https://github.com/anza-xyz/agave/blob/f11b777e9bbbfdaa6550003ebe36c37331acd037/core/src/validator.rs#L740-L743
So it is possible that the user supplies shred_version_1 through the CLI and:

Gossip connects using shred_version_2 from entrypoint
Initial backup_and_clear is performed using shred_version_1
Waiting for supermajority is done through gossip shred_version_2
Once blockstore is loaded the shred version is computed to be shred_version_2 matching gossip
Node then panics as shred_version_2 is not equal to shred_version_1: https://github.com/anza-xyz/agave/blob/f11b777e9bbbfdaa6550003ebe36c37331acd037/core/src/validator.rs#L747-L750

I think we should at least perform the comparison earlier so that operators that pass incorrect flags do not backup_and_clear the wrong shreds, and do not have to wait for WFSM to conclude in order to panic.

Gossip will always connect using the shred version via the entrypoint, regardless of any cli flag:

I took another look and believe this to be incorrect.
We create the Node here; this has an uninitialized shred_version as you pointed out:
https://github.com/anza-xyz/agave/blob/3ca67197c5cd142e355f0ad4263e6dd63d63f224/validator/src/main.rs#L1965
The Node is then passed to Validator::new():
https://github.com/anza-xyz/agave/blob/3ca67197c5cd142e355f0ad4263e6dd63d63f224/validator/src/main.rs#L2041-L2042
Within Validator::new(), we set the shred version based on the computed version, which is determined form HardForks that we pull out of rebuilt Bank:
https://github.com/anza-xyz/agave/blob/3ca67197c5cd142e355f0ad4263e6dd63d63f224/core/src/validator.rs#L744-L747
ClusterInfo then gets a clone of ContactInfo (recalling that node.info has the shred version set):
https://github.com/anza-xyz/agave/blob/3ca67197c5cd142e355f0ad4263e6dd63d63f224/core/src/validator.rs#L762-L766
We create a GossipService with ClusterInfo as a parameter:
https://github.com/anza-xyz/agave/blob/3ca67197c5cd142e355f0ad4263e6dd63d63f224/core/src/validator.rs#L1146-L1154
GossipService spins up a ClusterInfo::gossip() thread:
https://github.com/anza-xyz/agave/blob/3ca67197c5cd142e355f0ad4263e6dd63d63f224/gossip/src/gossip_service.rs#L81-L84
We hit the line to call process_entrypoints():
https://github.com/anza-xyz/agave/blob/3ca67197c5cd142e355f0ad4263e6dd63d63f224/gossip/src/cluster_info.rs#L1911
We check if my_shred_version() == 0 and if so, fetch shred version from entrypoints:
https://github.com/anza-xyz/agave/blob/3ca67197c5cd142e355f0ad4263e6dd63d63f224/gossip/src/cluster_info.rs#L1763
my_shred_version() accesses the shred version from ContactInfo; this value was set in core/src/validator.rs:
https://github.com/anza-xyz/agave/blob/3ca67197c5cd142e355f0ad4263e6dd63d63f224/gossip/src/cluster_info.rs#L729-L731
I recently spun up a node with --expected-shred-version set and do NOT see the Setting shred version to ... log line from process_entrypoints() that you linked above.

I agree with the analysis here. I suggest we perform the scan right after loading blockstore here:
...
We also have the "correct" shred version (more on this later) as computed from the genesis and hard_forks
...
I think we should at least perform the comparison earlier so that operators that pass incorrect flags do not backup_and_clear the wrong shreds, and do not have to wait for WFSM to conclude in order to panic.

I spliced three of your comments together here that are related. I agree with moving the backup_and_clear() call to after we have rebuilt Bank + compared expected_shred_version to computed_shred_version. Several points about this:

We will be able to error out if expected != computed
We will always have computed, so we no longer need to do if let Some(expected_shred_version) = ...

We're on the same page on all the major details, so going to start making some of these changes and we can hash out any remaining minor details in the individual PR's

I recently spun up a node with --expected-shred-version set and do NOT see the Setting shred version to ... log line from process_entrypoints() that you linked above.

Good catch, I missed that GossipService was started with the cloned ContactInfo.
I checked the other GossipService for bootstrap and it respects the flag as well, so I think we can ignore my concern
https://github.com/anza-xyz/agave/blob/3ca67197c5cd142e355f0ad4263e6dd63d63f224/validator/src/main.rs#L2012-L2014
https://github.com/anza-xyz/agave/blob/3ca67197c5cd142e355f0ad4263e6dd63d63f224/validator/src/bootstrap.rs#L155

A note for myself as I implement this. The current order of operations is:

Blockstore bad-shred-scan
Record highest slot in Blockstore for halt_at_slot in ProcessOptions
Rebuild initial bank

When we move current 1. after current 3. (so we can get hard-forks from Bank to calculate shred version), we would be recording halt_at_slot before potential purge. As such, the highest recorded slot could be a slot that is later purged. I think this is fine because if the halt_at_slot is just used to ensure that new slots to be processed are <= halt_at_slot. But, it would be more proper to record the actual value after backup_and_clear_blockstore()
OR, even better would be to actually do https://github.com/solana-labs/solana/issues/25577 so that we can split ProcessOptions up a bit (ie things that pertain to bank rebuild vs. block replay). Currently, the fact that we either rebuild from a snapshot OR start from genesis + replay slot 0 forces us to pass this struct all the time


start tmux with -CC

An extension to #38
As an overmind user
I want to specify tmux startup options, specifically -CC
So i can use iTerm2's amazing tmux integration

iTerm2's tmux integration works pretty badly with tmux clients launched by other applications. I made a few tries and didn't achieve satisfiable results, so I see this feature impossible at this point.


docker-compose to run the application in Production.

Can someone provide an example docker-compose that would run the container in production mode?

A simple example might look like this...
version: '3'

services:
  nginx:
    restart: always
  api:
    environment:
      - NODE_ENV=production
      - CORS_ORIGIN=https://getlatka.com
    restart: always
  db:
    restart: always
  redis:
    restart: always

Then, if that file is named production.yml, you can run it like this...
docker-compose -f docker-compose.yml -f production.yml up

This will override the values in docker-compose.yml with the values in production.yml


Adsk Contrib - Fix grading inversion

Fixes a bug in the GradingPrimary op inverse and implements the inverses in GradingTone and GradingRGBCurve.
Fixes a bug related to dynamic property comparison.
Allows slopes to be provided for RGB Curves.

As discussed at the last TSC meeting, I will merge the pull request (that's the last one needed) to prepare rc1.

As discussed at the last TSC meeting, I will merge the pull request (that's the last one needed) to prepare rc1.


How to share QGIS-functions over multiple scripts?

At the moment we have 2 QGIS-scripts: Autocorrectborders.py and AutoUpdateborders.py.
The QGIS-specific functions are inside these scripts, but they share some of the same functions. How can we share these functions over the scripts?  Adding to brdr.qgis? of making brdrQ-python-lib? or?

related to #30

@roefem Do you have a 'best practice' or opinion about this?

this is fixed by changing the script to a plugin.


Updating I/O and Go 1.19

Updating the input/output to handle more response codes and request body. Also updating to Go 1.19.

Since there isn't anyone else here to review this, I'll do it myself


[DDoc] [trivial] Mentioning that a container is not a range.

This often comes up on the forum/stackoverflow, and I think it's best to mention it right in Array's documentation.
It should probably be mentioned in std.algorithm docs too, but in more detail/more generally.

Thanks! @all - don't forget to use backticks for code going forward.


Enable aarch64 and ppc64le builds

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

closes #107
Dependencies are there now for aarch64 as well, so this new PR will enable builds for both aarch64 and ppc64le. The TexLive/ICU issues have also been worked out, so no other changes needed.
I'm opening this manually because the migrator is hung up on dependencies that are either not needed for aarch64/ppc64le or are already available.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

@hmaarrfk FYI

ah, looks like bwidget is still needed on aarch64.

https://github.com/conda-forge/bwidget-feedstock/pull/1

Error on drone (aarch64)
conda_build.exceptions.DependencyNeedsBuildingError: Unsatisfiable dependencies for platform linux-aarch64: {'libsm-devel-cos7-aarch64', 'libxt-devel-cos7-aarch64', 'java-1.7.0-openjdk-cos7-aarch64', 'libice-devel-cos7-aarch64', 'libxt-cos7-aarch64'}

ping @conda-forge/arm-arch

cdts are notorious hard to get through the review process
A bit of help here would be appreciated
https://github.com/conda-forge/staged-recipes/pull/10516


Error if a t110 sensor is connected.

Version of the integration
3.1.2

Configuration
Tapo T110(US)_V1_1.9.0 Build 230704

Failed to setup cannot connect

Traceback (most recent call last):
  File "/config/custom_components/tapo/config_flow.py", line 317, in _async_get_device
    await device.update()
  File "/usr/local/lib/python3.12/site-packages/plugp100/new/tapodevice.py", line 79, in update
    await component.update(state)
  File "/usr/local/lib/python3.12/site-packages/plugp100/new/components/hub_children_component.py", line 47, in update
    await child_device.update()
  File "/usr/local/lib/python3.12/site-packages/plugp100/new/tapodevice.py", line 79, in update
    await component.update(state)
  File "/usr/local/lib/python3.12/site-packages/plugp100/new/components/smart_door_component.py", line 15, in update
    self.is_open = current_state["is_open"]
                   ~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'is_open'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/config/custom_components/tapo/config_flow.py", line 143, in async_step_user
    device = await self._async_get_device(user_input)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/tapo/config_flow.py", line 322, in _async_get_device
    raise CannotConnect from error
custom_components.tapo.errors.CannotConnect

Describe the bug
Viewing the integration via settings it shows failed setup will retry.  When clicking on the integration itself it says Failed setup will retry 'is_open'.  This only occurs if I have the t110 added to the tapo app.  Just in case it's relevant, the switch is currently closed and advertised as such in the app. I had to remove it from the app again as my humidity sensor stopped reporting data,
Debug log

2024-06-12 07:44:00.576 INFO (MainThread) [custom_components.tapo.hass_tapo] Detected model of <IP_ADDRESS>: H100
2024-06-12 07:44:00.676 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.100 seconds (success: True)
2024-06-12 07:44:00.677 INFO (MainThread) [custom_components.tapo.hub.hass_tapo_hub] Found 4 children associated to hub 802D6744CB619732124FA5D2B5ACD093212418BA
2024-06-12 07:44:00.779 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.102 seconds (success: True)
2024-06-12 07:44:00.882 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.102 seconds (success: True)
2024-06-12 07:44:00.984 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.102 seconds (success: True)
2024-06-12 07:44:01.550 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.566 seconds (success: True)
2024-06-12 07:44:02.059 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.491 seconds (success: True)
2024-06-12 07:44:02.184 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.616 seconds (success: True)
2024-06-12 07:44:02.300 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.732 seconds (success: True)
2024-06-12 07:44:02.433 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.864 seconds (success: True)
2024-06-12 07:44:02.558 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.989 seconds (success: True)
2024-06-12 07:44:04.448 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 2.876 seconds (success: True)
2024-06-12 07:44:04.534 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 2.962 seconds (success: True)
2024-06-12 07:44:04.630 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 3.057 seconds (success: True)
2024-06-12 07:44:04.726 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.664 seconds (success: True)
2024-06-12 07:44:04.814 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 3.241 seconds (success: True)
2024-06-12 07:44:31.969 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.145 seconds (success: True)
2024-06-12 07:44:32.077 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.248 seconds (success: True)
2024-06-12 07:44:32.218 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.304 seconds (success: True)
2024-06-12 07:44:32.335 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.393 seconds (success: True)
2024-06-12 07:44:34.981 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.095 seconds (success: True)
2024-06-12 07:45:01.952 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.127 seconds (success: True)
2024-06-12 07:45:02.054 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.224 seconds (success: True)
2024-06-12 07:45:02.159 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.246 seconds (success: True)
2024-06-12 07:45:02.273 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.331 seconds (success: True)
2024-06-12 07:45:04.970 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.085 seconds (success: True)
2024-06-12 07:45:32.110 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.286 seconds (success: True)
2024-06-12 07:45:32.227 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.398 seconds (success: True)
2024-06-12 07:45:32.366 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.453 seconds (success: True)
2024-06-12 07:45:32.484 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.542 seconds (success: True)
2024-06-12 07:45:34.974 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.089 seconds (success: True)
2024-06-12 07:46:01.924 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.099 seconds (success: True)
2024-06-12 07:46:02.041 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.212 seconds (success: True)
2024-06-12 07:46:02.165 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.252 seconds (success: True)
2024-06-12 07:46:02.268 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.326 seconds (success: True)
2024-06-12 07:46:04.965 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.080 seconds (success: True)
2024-06-12 07:46:31.929 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.104 seconds (success: True)
2024-06-12 07:46:32.032 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.203 seconds (success: True)
2024-06-12 07:46:32.147 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.234 seconds (success: True)
2024-06-12 07:46:32.271 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.328 seconds (success: True)
2024-06-12 07:46:34.971 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.086 seconds (success: True)
2024-06-12 07:47:01.930 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.106 seconds (success: True)
2024-06-12 07:47:02.034 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.204 seconds (success: True)
2024-06-12 07:47:02.140 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.227 seconds (success: True)
2024-06-12 07:47:02.241 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.299 seconds (success: True)
2024-06-12 07:47:04.971 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.084 seconds (success: True)
2024-06-12 07:47:32.080 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.256 seconds (success: True)
2024-06-12 07:47:32.184 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.355 seconds (success: True)
2024-06-12 07:47:32.297 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.384 seconds (success: True)
2024-06-12 07:47:32.397 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.455 seconds (success: True)
2024-06-12 07:47:34.991 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.105 seconds (success: True)
2024-06-12 07:48:01.990 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.166 seconds (success: True)
2024-06-12 07:48:02.150 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.321 seconds (success: True)
2024-06-12 07:48:02.288 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.374 seconds (success: True)
2024-06-12 07:48:02.392 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.450 seconds (success: True)
2024-06-12 07:48:04.999 DEBUG (MainThread) [custom_components.tapo.coordinators] Finished fetching tapo data in 0.112 seconds (success: True)
2024-06-12 08:07:19.358 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved (None)
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 1262, in async_init
    flow, result = await self._async_init(flow_id, handler, context, data)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 1292, in _async_init
    result = await self._async_handle_step(flow, flow.init_step, data)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 528, in _async_handle_step
    if result.get("preview") is not None:
       ^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get'
2024-06-12 08:14:57.457 ERROR (MainThread) [custom_components.tapo.config_flow] Failed to setup cannot connect
Traceback (most recent call last):
  File "/config/custom_components/tapo/config_flow.py", line 317, in _async_get_device
    await device.update()
  File "/usr/local/lib/python3.12/site-packages/plugp100/new/tapodevice.py", line 79, in update
    await component.update(state)
  File "/usr/local/lib/python3.12/site-packages/plugp100/new/components/hub_children_component.py", line 47, in update
    await child_device.update()
  File "/usr/local/lib/python3.12/site-packages/plugp100/new/tapodevice.py", line 79, in update
    await component.update(state)
  File "/usr/local/lib/python3.12/site-packages/plugp100/new/components/smart_door_component.py", line 15, in update
    self.is_open = current_state["is_open"]
                   ~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'is_open'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/config/custom_components/tapo/config_flow.py", line 143, in async_step_user
    device = await self._async_get_device(user_input)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/tapo/config_flow.py", line 322, in _async_get_device
    raise CannotConnect from error
custom_components.tapo.errors.CannotConnect
2024-06-12 08:19:19.152 ERROR (MainThread) [custom_components.tapo.config_flow] Failed to setup cannot connect
Traceback (most recent call last):
  File "/config/custom_components/tapo/config_flow.py", line 317, in _async_get_device
    await device.update()
  File "/usr/local/lib/python3.12/site-packages/plugp100/new/tapodevice.py", line 79, in update
    await component.update(state)
  File "/usr/local/lib/python3.12/site-packages/plugp100/new/components/hub_children_component.py", line 47, in update
    await child_device.update()
  File "/usr/local/lib/python3.12/site-packages/plugp100/new/tapodevice.py", line 79, in update
    await component.update(state)
  File "/usr/local/lib/python3.12/site-packages/plugp100/new/components/smart_door_component.py", line 15, in update
    self.is_open = current_state["is_open"]
                   ~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'is_open'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/config/custom_components/tapo/config_flow.py", line 143, in async_step_user
    device = await self._async_get_device(user_input)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/tapo/config_flow.py", line 322, in _async_get_device
    raise CannotConnect from error
custom_components.tapo.errors.CannotConnect
2024-06-12 08:20:43.733 ERROR (MainThread) [homeassistant.components.matter] Failed to start the Matter Server add-on: Another job is running for job group addon_core_matter_server
2024-06-12 08:22:06.230 ERROR (MainThread) [custom_components.tapo.config_flow] Failed to setup cannot connect
Traceback (most recent call last):
  File "/config/custom_components/tapo/config_flow.py", line 317, in _async_get_device
    await device.update()
  File "/usr/local/lib/python3.12/site-packages/plugp100/new/tapodevice.py", line 79, in update
    await component.update(state)
  File "/usr/local/lib/python3.12/site-packages/plugp100/new/components/hub_children_component.py", line 47, in update
    await child_device.update()
  File "/usr/local/lib/python3.12/site-packages/plugp100/new/tapodevice.py", line 79, in update
    await component.update(state)
  File "/usr/local/lib/python3.12/site-packages/plugp100/new/components/smart_door_component.py", line 15, in update
    self.is_open = current_state["is_open"]
                   ~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'is_open'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/config/custom_components/tapo/config_flow.py", line 143, in async_step_user
    device = await self._async_get_device(user_input)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/tapo/config_flow.py", line 322, in _async_get_device
    raise CannotConnect from error
custom_components.tapo.errors.CannotConnect

Turns out by disabling the hub I then lost my battery sensors for my switches
Now I can't renenable due to some other error and key is open is still a problem, I guess because the t110 is connected but connected via matter.
I guess the underlying issue of the t110 needs to be fixed else the tapo integration breaks entirely
`2024-06-14 11:55:21.078 ERROR (MainThread) [custom_components.tapo.config_flow] Failed to setup cannot connect
Traceback (most recent call last):
File "/config/custom_components/tapo/config_flow.py", line 317, in _async_get_device
await device.update()
File "/usr/local/lib/python3.12/site-packages/plugp100/new/tapodevice.py", line 79, in update
await component.update(state)
File "/usr/local/lib/python3.12/site-packages/plugp100/new/components/hub_children_component.py", line 47, in update
await child_device.update()
File "/usr/local/lib/python3.12/site-packages/plugp100/new/tapodevice.py", line 79, in update
await component.update(state)
File "/usr/local/lib/python3.12/site-packages/plugp100/new/components/smart_door_component.py", line 15, in update
self.is_open = current_state["is_open"]
~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'is_open'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/config/custom_components/tapo/config_flow.py", line 231, in async_step_discovery_auth_confirm
device = await self._async_get_device_from_discovered(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/tapo/config_flow.py", line 295, in _async_get_device_from_discovered
return await self._async_get_device(config | {CONF_HOST: discovered.ip}, discovered)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/tapo/config_flow.py", line 322, in _async_get_device
raise CannotConnect from error
custom_components.tapo.errors.CannotConnect`

I just tried adding a new H100 that had a T110 already paired and I had the same issue.
Failed to setup cannot connect
Traceback (most recent call last):
File "/config/custom_components/tapo/config_flow.py", line 317, in _async_get_device
await device.update()
File "/usr/local/lib/python3.12/site-packages/plugp100/new/tapodevice.py", line 79, in update
await component.update(state)
File "/usr/local/lib/python3.12/site-packages/plugp100/new/components/hub_children_component.py", line 47, in update
await child_device.update()
File "/usr/local/lib/python3.12/site-packages/plugp100/new/tapodevice.py", line 79, in update
await component.update(state)
File "/usr/local/lib/python3.12/site-packages/plugp100/new/components/smart_door_component.py", line 15, in update
self.is_open = current_state["is_open"]
~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'is_open'

This is a duplicate of https://github.com/petretiandrea/home-assistant-tapo-p100/issues/759 and is fixed by pull request https://github.com/petretiandrea/plugp100/pull/189

Sorry I’m new to ha
Does this mean I wait for the integration to update or am I meant to do something else?
thanks


Comments to code for infinite loops

I have code that won't load because of an assumed infinite loop.  I can hit the "comment out my code" and it works fine, except that the inserted line of code is now an error because it is javascript rather than my current language.

Need to update this code to use the right return syntax per language. Probably want to move the comment logic into SpellView, where we know which language the spell is in and have the comment regex ready and all that.

How would this be accomplished in Clojure?
--- Ursprüngliche Nachricht ---
Von: "Nick Winter"<EMAIL_ADDRESS>Gesendet: 10. Januar 2015 18:03
An: "codecombat/codecombat"<EMAIL_ADDRESS>Cc: "Gian S."<EMAIL_ADDRESS>Betreff: Re: [codecombat] Comments to code for infinite loops (#1788)
Need to update this code to use the right return syntax per language. Probably want to move the comment logic into SpellView, where we know which language the spell is in and have the comment regex ready and all that.

Reply to this email directly or view it on GitHub:
https://github.com/codecombat/codecombat/issues/1788#issuecomment-69462804

There's no return, but you could add some one-line Clojure at the beginning that would cause it to error out, which would stop the infinite loop, like (.dieEarly this "now") (or something less dumb).

You may close this issue @nwinter, I think the last commit fixed it.


Improved plotting of pre-shaped 2d data

After the predefined shape was added to the dataset non measured data is filled with nans. This updates the 2d pcolormesh plot to handle this.
It does this by bypassing the logic that checks for shape since this is no longer needed. However Matplotlib cannot handle a pcolormesh plot where the x and y coordinates are nans so some logic is needed to ensure this is clipped correctly. There are two use cases to consider. If the data is on a rectilinear grid we can plot all rows and columns that contain non nan setpoints. For the other case of non rectilinear grid we currently fall back to flattening the data again and removing all nans. This may not be the optimal solution but is identical to what we had before introducing shapes.
This furthermore avoids using significant resources to find the right plot type when the plot type is already given.
For shaped data we pass the gridded x and y data directly to matplotlib and avoid having to do any reshaping.
We upgrade the Matplotlib requirements to 3.3 to avoid having to interpolate the edges of the individual patches but rely on Matplotlib to do that.
@ThorvaldLarsen can you check if this resolves #2995

@jenshnielsen Just had a quick look and everything seems to work with the current version. Updated our plotting system and will continue to test this branch in normal operation over the next couple of days. Many thanks for resolving this issue.

@ThorvaldLarsen I ended up doing some more cleanup here. It would be great if you have a chance to test it again

@QCoDeS/core ready for review

@jenshnielsen @trevormorgan tested across our current database and everything has been working great so far. I would say this is ready for merging.
Only minor thing I ran into was for a completely empty dataset (dataset created but cancelled before any data was added) plotting fails with a "keyword error" which could be done more gracefully. This is a very rare case and for an empty dataset we obviously dont care about the plot. I think this has also been the normal behavior from the beginning and I would say perfectly fine to just leave as is.

Only minor thing I ran into was for a completely empty dataset (dataset created but cancelled before any data was added) plotting fails with a "keyword error" which could be done more gracefully. This is a very rare case and for an empty dataset we obviously dont care about the plot. I think this has also been the normal behavior from the beginning and I would say perfectly fine to just leave as is.

@ThorvaldLarsen thanks for the testing and feedback! This looks good to merge now so we can have it in the upcoming release.  I'll make a note of this issue so we can make improvements for a more graceful failure due to an empty dataset but let's handle that in another PR.


How to determine if notification event triggered by user tapping notification?

I have successfully integrated phonegap-plugin-push into my app, but I can't quite get everything working as I would like. I have 4 use-cases that I need to implement:

Notification received, app is in foreground
Notification received, app is in background
User taps notification, app is in foreground
User taps notification, app is in background

By using the data.additionalData.foreground property, I can determine whether the app is in the foreground or background - no problem here. My issue is that I have no way to tell if the event was triggered from a notification being received, or whether it was triggered by the user tapping the notification to open it in the app.
My application is Paragliding Map, an app which displays flying sites around the world. Notifications are sent when someone writes a chat message for a site. Tapping the notification opens the site in the app, but I have to ignore the notifications coming from the server until the user taps it, because otherwise the sites are opened while the user is using the app (which is annoying).  Note that the coldstart property is also not useful in this case, because the app could be open or closed when the users taps the notification (both are valid).
So my question is: how do I know whether the notification event was triggered by the server or by the user tapping the notification?

current no such provision is available.
a quick fix for this is.
Store notification data Every time onNotification called in common variable that you can access from anywhere(I used storage) and process notification click on resume for foreground and ionViewDidLoad for backGround processing and remove notification data after processing it.
few code samples below.
  pushObject.on('notification').subscribe((notification: any) => {
  //current notification here
  this.storage.set('curNotification',notification.additionalData);
  this.events.publish('notification:arrived', {count:1,page:notification.additionalData.page});
  console.log('1noti' + notification.additionalData.notId);
  // this is to avoid double processing
  if(MyApp.notiID!=notification.additionalData.notId) {
  //store notifications in master list here
  }

// this is onResume
private onResumeSubscription: Subscription;
this.onResumeSubscription = platform.resume.subscribe(() => {
// do something meaningful when the app is put in the foreground
console.log('resumed');
if(this.rootPage!=null && this.rootPage!=undefined && this.rootPage!='') {
console.log('in root');
this.storage.get('curNotification').then((page) => {
      if (page != '') {
        this.app.getActiveNav().push(page.page,{data:page});
        this.storage.set('curNotification', '');
      }

    });
  }

});

ngOnDestroy() {
// always unsubscribe your subscriptions to prevent leaks
this.onResumeSubscription.unsubscribe();
}
// this is background processing
ionViewDidLoad(){
this.checked=0;
this.error=0;
this.storage.get('curNotification').then((page) => {
if (page != '') {
this.app.getActiveNav().push(page.page,{data:page});
this.storage.set('curNotification', '');
}
});
this.refresh();

}

@Pigsnuck

if foreground === true, no-op
if foreground === false, re-direct to the correct page
How is this possible?
if foreground === false, re-direct to the correct page

Thanks for your comments.
@macdonst
3. Can happen if I send 2 notifications for 2 different chat messages. The user taps on the first notification which opens the correct page in the app. So far so good.  Now the user swipes down to open the notification center and taps the second notification. Now the app is in the foreground, so according to point 1, no-op (which is incorrect behaviour because the user wants to open the second chat message).  The crux of the matter is point 3, which means I can't just implement point 1.
@Prashant454
Pretty clever. I didn't think of that workaround. ;)

Unfortunately, the fix from @Prashant454 doesn't work, because if the app is not running when the notification is received I can't store an ID.  I also can't use background notifications because according to Apple these should be limited to a maximum of a few per hour (or suffer from throttling).
Is there really no way to add a flag whether the user tapped the notification or not?  I will personally investigate and create a pull-request if I can, but I'm not exactly an Objective-C expert any more. :(

@Pigsnuck I had the same issue and came here looking for a solution. What I've observed is that dismissed is set to true or false in additionalData when you actually tap on the notification. If however you tap on the app icon instead, this flag doesn't exist. So In my code, I'm checking for 'presence' of this attribute - if it exists, it means you started the app by tapping a notification. I haven't tested this thoroughly  though.


SSL error for servers with untrusted certs.

I have internal server and I don't have a "trusted" cert.
Getting the following error stacktrace if I run any command:
Traceback (most recent call last):
File "/usr/local/bin/xserverpy", line 11, in
sys.exit(start())
File "/Library/Python/2.7/site-packages/xserverpy/xserverpy.py", line 21, in start
start_with_args(None)
File "/Library/Python/2.7/site-packages/xserverpy/xserverpy.py", line 32, in start_with_args
handle_bots(args)
File "/Library/Python/2.7/site-packages/xserverpy/xserverpy.py", line 61, in handle_bots
printer = BotsPrinter(b.get_all())
File "/Library/Python/2.7/site-packages/xserverpy/lib/base_service.py", line 15, in get_all
result = self.perform_request(self.endpoint(), "get")
File "/Library/Python/2.7/site-packages/xserverpy/lib/base_service.py", line 52, in perform_request
raise e
requests.exceptions.SSLError: [Errno 8] _ssl.c:507: EOF occurred in violation of protocol

Looks like an issue with the requests library:
https://github.com/kennethreitz/requests/issues/2056
https://github.com/jkbrzt/httpie/issues/315


Remove space-stripping ERB tags from state-pension-through-partner

Description
This replaces all uses of <%= -%> with <%= %>. We don't need the space/newline stripping behaviour and consistently using the same ERB tags leaves us with a slightly simpler system.
We started using <%= -%> when converting from i18n YAML templates to ERB templates. Using -%> to strip trailing spaces/newlines allowed us to exactly replicate the outcomes that were previously generated by the i18n YAML system. This gave us confidence that the conversion was accurate. These are no longer necessary and so I've removed them in favour of consistently using <%= %>.
I ran all regression tests after making these changes. There were no changes to the artefacts, so I'm happy to accept the changes and update the checksums accordingly.
c.f. #2420
External changes
There should be no externally-visible changes - this is just an internal refactoring.

Looks good to me, @floehopper.

I'm going to rebase this against master and (since there are no comments on individual commits) force-push in preparation for merging.


Fixed typos in user guide

Typos corrected in local copy and verified that html user guide could be created accoording to instructions.

Admin, can CI be enabled?

Typo fixes look good but "coercion" has been used on purpose. Is there a semantic difference that would make "conversion" better suited in these cases?

This PR was replaced with #1895 that's already merged. Thanks @vtuomain!


Post with empty body does not return response.

couldn't reproduce

This issue resolved in updated package.


AzureAD must be described for service endpoint GA list

I believe that AzureAD is supported for service endpoint but it can't be found in "General available" list.
Instead ADLS is listed though its resource type name is Microsoft.AzureActiveDirectory.
If this is a document bug, please modify this line.

-Azure Data Lake Store Gen 1 (Microsoft.AzureActiveDirectory): Generally available in all Azure regions where ADLS Gen1 is available.

Best regards,

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

ID: 1eb0407d-f4a5-6059-488d-fd082915c675
Version Independent ID: 7c2fb429-743c-aea0-f1d5-de6dc2e62e8e
Content: Azure virtual network service endpoints
Content Source: articles/virtual-network/virtual-network-service-endpoints-overview.md
Service: virtual-network
GitHub Login: @sumeetmittal
Microsoft Alias: sumi

@tetsuyasodo , thank you for the feedback. We'll review this and get back to you shortly!

Azure AD doesn't support service endpoints itself.. Microsoft.AzureActiveDirectory is used for ADLS SE support..

Thank you for the confirmation @sumeetmittal.
@tetsuyasodo , as mentioned by Sumeet, Azure AD doesn't support service endpoints itself. Microsoft.AzureActiveDirectory is used for ADLS SE support.
We are closing this issue for now. If there are further questions regarding this matter, please reply and we will gladly continue the discussion.


Add code of conduct to contributing guidelines

We are intending to adopt the soon-to-be-announced Open Code of Conduct for all @github projects. This adds it to the contributing guidelines. Let me know if you have any questions or concerns.

:+1:


Moving go to 1.20 to be in sync with rest of the project

closing this as a bump to 1.21 for OSPdO was merged with https://github.com/openstack-k8s-operators/osp-director-operator/pull/1056


lower the open pull request limit for dependabot

Updated the max PR limit so that dependabot doesn't DoS the CI server.

The CI errors are because of unrelated UI tests. Will merge anyways since this 100% doesn't affect the code.


Cannot reboot with firmware version 1.2103.00.0338

The update to firmware version 1.2103.00.0338 has broken the reboot API POST request.

Firmware update added support for multiple iterations of password hashing. In case where no iterations are performed (have not been observed), password is lowercased. Throws Exception should the nonce endpoint request multiple iterations be performed.


[BUG] Chart data disappears depending on the order of objects in the dataset for multiple floating horizontal bars

Expected Behavior
I am plotting multiple floating horizontal bars with a categorical y-axis and a time x-axis.
I expect the bars to be shown independently of the order in the dataset.
Current Behavior
If two entries pointing to the same category are next to each other in the dataset no chart data is displayed. With other orderings the bars are plotted as intended.
Possible Solution

Steps to Reproduce (for bugs)
Here is an example with a "valid" order.
https://codepen.io/luschu/pen/ZEbvvqM
data: [
{x: [new Date('2019-01-05'), new Date('2019-01-06')], y: 'Task 1'},
{x: [new Date('2019-01-10'), new Date('2019-04-10')], y: 'Task 2'},
{x: [new Date('2019-03-15'), new Date('2019-06-10')], y: 'Task 3'},
{x: [new Date('2019-03-05'), new Date('2019-03-08')], y: 'Task 1'},
]

The bug occurs when changing the order of the entries in the dataset so that the two entries for "Task 1" follow each other:
data: [
{x: [new Date('2019-01-05'), new Date('2019-01-06')], y: 'Task 1'},
{x: [new Date('2019-03-05'), new Date('2019-03-08')], y: 'Task 1'},
{x: [new Date('2019-01-10'), new Date('2019-04-10')], y: 'Task 2'},
{x: [new Date('2019-03-15'), new Date('2019-06-10')], y: 'Task 3'},
]

Context
I am working on a Gantt-like chart with multiple entries per category.
Therefore, I was extending this example .
Environment

Chart.js version: Chart.js/3.0.0-alpha
(experiencing the same bug on master https://www.chartjs.org/dist/master/Chart.js)
Browser name and version: Chrome 81.0

Its the barThickness determination that fails.
Setting it explicitly removes the issue: https://codepen.io/kurkle/pen/ExVoRzy

Setting the barThickness works for me, thanks!
I still have two questions: First, how could I know that it is the barThickness that fails, is there a warning in the log that I missed? (I'm pretty new to web programming, so please excuse this maybe newbie question.)
And secondly, I think it should also work with the default setting that the barThickness is not set. Is there a possibility to fix the issue in general?


How Do I deploy a function with python packages in private pip server

Hi everyone,
I’ve been using the serverless framework for a while to deploy functions that use python packages. For that purpose, I have been using the serverless-python-requirements plugin. This all works great. However, I now want to deploy a function that uses a python package that is hosted at a private pip server.
Locally, I add this pip server to my pip.conf file like this:
[install]
extra-index-url = https://$USERNAME:$PASSWORD@$URL/simple/

This works great when I install a package on my own device. However, when I try to deploy my function with the private python package in the requirements.txt, I get the following error:
Error --------------------------------------------------

   Could not find a version that satisfies the requirement
 $PACKAGE_NAME (from -r .serverless/requirements.txt
 (line 11)) (from versions: )
No matching distribution
found for $PACKAGE_NAME (from -r .serverless/requirements.txt
(line 11))

It thus appears to me that the python requirements plugin uses the regular pip server and not the private pip server that I configured and use when I run pip install $PACKAGE_NAME.
Does any of you have an idea on how I can configure serverless so that it uses the private pip server?
Thank you in advance,
Gerben

Are you using the dockerizePip option?

If not, this looks like it might be related to #176 and the use of --isolated.

In that case, try out v4.0.1 which should fix the issue.

Excellent!

I'm getting this error and I have these versions:
{
  "name": "unresponsive",
  "description": "foobar",
  "license": "UNLICENSED",
  "repository": "github:dialoguemd/unresponsive",
  "version": "0.1.0",
  "dependencies": {},
  "devDependencies": {
    "serverless-pseudo-parameters": "^1.6.0",
    "serverless-python-requirements": "^4.0.3",
    "serverless-step-functions": "^1.4.1"
  }
}

Maybe relevant is that:

I am using pipenv
I am adding support for the other index via env var: PIP_EXTRA_INDEX_URL


Prepare to use Rails ActiveJob with a job runner gem solid_queue, for expensive jobs

[x] switch to puma
[x] wait for solid_queue 0.3.0 version to be released

coverage: 94.428%. remained the same
when pulling 0bd8e0f3e1aafa375c6d40d9abee0e5095e1bf9f on activejob-solid-queue
into 065b40796e039e09a5162def5d20f61e9d16af45 on main.


Missing doc on managing sidebar when translation is enabled

📚 Documentation
I've enabled translation on a site and I can browse to different locales of docs from /website/translated_docs/<locale>/ directory. Although I have the contents translated, the sidebar remains in English.
Maybe it's a bug or missing feature, but based on the doc, I could find information on how to get the sidebar translation. I think there should be different copies of sidebar.json for each locales similar to versioned docs, but I'm not sure what the current mechanism is.
Have you read the Contributing Guidelines on issues?
Yes

I am assuming you are not using Crowdin, (in which we recommend and suggest). The sidebar translation is done via .json file. Example: if you are using a chinese language/ zh-CN, crowdin-download will pull out a zh-CN.json.
You can look at this as an example https://github.com/loomnetwork/loom-sdk-documentation/tree/master/website/i18n

You're right. I'm not using Crowdin. I personally do like it but I don't think it's free (please correct me if I'm wrong). I think we need a little bit more flexibility with translation so that we can manage translation even without crowdin.
I thought I had raised a feature request for this, but can't seem to find it now.

From my understanding, crowdin is free only for open source project. Well, technically not using crowdin is possible, but the user need vast understanding of how docusaurus v1 works. I strongly does not recommend managing translation without crowdin in the current version.
I was on leave up until recently, but I'll keep this in mind when we're developing v2 to allow user managing translation without crowdin

Yes, Crowdin is free for open source projects, which is part of the reason why we chose them as a partner for Docusaurus. https://crowdin.com/page/open-source-project-setup-request


Cleanup Travis-CI configuration and install VIPS for image processing

Use package syntax to install packages
Just use yarn to install JavaScript dependencies
Install VIPS from source because Active Storage requires a recent build

Do we know what triggered master going red?
Are there any cons to libvips I should know about? I haven't done my homework there...

I approved Percy, one diff was intermittent (date related) to be fixed and the other was intentional change from Ben on master.

Thijs said the reason for the failure was trying to use NPM And Yarn simultaneously. Not really sure why that would cause libsass to stop building.
Cons for VIPS is that we need a recent version and there is no package on Ubuntu. Speed and less reliance on crufty ImageMagick is the primary reason for switching. The ImageProcessing gem used by Rails 6 can use either so we can always switch back.


Release/1.3.0

Release 1.3.0
This release includes many new features:

Replacing Sout/SErr calls with SLF4J Logging
Added these calls:

refreshBrowserSource
getSourcesList
getSourceFilterVisibility, setSourceFilterVisibility, getSourceFilters, setSourceFilterSettings
setCurrentScene
takeSourceScreenshot
getMute, toggleMute (complements to existing setMute)
playPauseMedia, restartMedia, stopMedia, nextMedia, previousMedia
get/setAudioMonitorType
getSpecialSources
triggerHotkeyByName

Added these events:

PreviewSceneChanged
MediaPlaying, MediaPaused, MediaRestarted, MediaStopped, MediaNext, MediaPrevious, MediaEnded

Changes for development:

Switching from Maven to Gradle
Adding end-to-end testing and test resources
Centralized GSON configuration
Replacing custom callback interfaces with standard Java Consumers, BiConsumers, and Runnables

And also several bug fixes:

#11 Max message size rejects messages and closes connection
#14 Missing a LICENSE file (now under MIT)
#19 NullPointerException on close of connection

Notice: Last 1.X.X Release!
As announced for the Palakis OBS Websocket plugin, Release 4.9.1 will be its last release before 5.X.X. The next major release will introduce breaking changes, overhauling its protocol to make room for many improvements.
For us, this means we will focus on updating this library so that it is compatible. We will also do a small overhaul ourselves to improve maintainability (addressing serialization boilerplate, and lifecycle management).
The next release for websocket-obs-java will be 2.0.0, and all further work on 1.3.0 will stop (except for major bugs/issues).
If you have any questions or comments, please drop them here!

Can someone push 1.3 to maven central? I'm only seeing 1.2 there.

Can someone push 1.3 to maven central? I'm only seeing 1.2 there.

I guess the GH action to publish to maven central failed :/
You can always use the last snapshot version https://oss.sonatype.org/content/repositories/snapshots/net/twasi/obs-websocket-java/1.3.0-SNAPSHOT/


Pull request for markdown

For travis-ci/travis-ci#4328.
Ran tests and found no setuid bits.
See https://travis-ci.org/travis-ci/apt-whitelist-checker/builds/71944413

Oh okay. I didn't know you filed those for me. Thanks!


HTML script tag expansion in Sublime Text 3

After a quick research, it seems to be a long known issue with emmet:
https://github.com/emmetio/emmet/issues/320
Some user mentioned that it's fixed with emmets latest version, but It's still not working for me on sublime text 3.
You can reproduce it with script:src which outputs ==> script:<script type="text/javascript"></script> instead of <script src="js/xyz.js"></script>
I'm using Sublime Text 3 - Build 3103 with the latest version of emmet-sublime

Make sure there’s no autocomplete popup visible when you hit Tab and document syntax is set to HTML. Everything works fine

That doesn't work

And my syntax is set on HTML

emmet doesn't working now... after updating...

+1  sublime 3103

@elbasankadrija it means there’s src snippet expanded by other package. Try to run sublime.log_commands(True) command in ST console and check command name when you press Tab
@mugukamil check ST console for errors and try to restart ST

I have no Idea why, but I think it fixed itself overnight? Did you guys push a update?

fixed by reinstall emmet

Emmet would not expand at all. Reinstall fixed it.

So weird.  I had the same issue, and running "Upgrade/overwrite all packages" didn't fix it.  I uninstalled Emmet, restarted Sublime text, re-installed Emmet, and everything started working dandily.


Scan a QR code

Scan a QR code and present the appropriate screen.
See T9 in the Outstanding Tasks document located in the /docs/source directory.

From Outstanding Tasks document:
Build a screen that is presented when a QR code has been scanned.  Based on
what is found or not found in the database, switch to an appropriate screen.

Box Record Status
Action Taken

No box record
Present new box screen

Box record empty
Present new box screen

Box record filled
Present empty or move box screen

..  table::  Box Record Status and Action Taken
:widths: auto
:align: left
=================  ============
Box Record Status  Action Taken
=================  ============
No box record      Present new box screen
Box record empty   Present new box screen
Box record filled  Present empty or move box screen
=================  ============

Please add enhancement label to this and assign it to me

[ ] Change name of Add Box screen to new box (change viewname, url name, and the title on the page)
[ ] Make the Visible box number-read only (label has been pre-printed and added)
[ ] Remove Box.print_box_number_label field.

I think we can close this one and figure out what subsequent screens should be.

Closing per John's request above.


Get with Digest Auth?

Would you be interested to have a Digest Auth PR similar to basic auth? I will be interested to send one.
iex> response = HTTPotion.get "httpbin.org/basic-auth/foo/bar", [basic_auth: {"foo", "bar"}]

iex> response = HTTPotion.get "httpbin.org/digest-auth/foo/bar", [digest_auth: {"foo", "bar"}]

Seems like erlang library ibrowse is already supporting this, but need to look into detail.
https://github.com/cmullaparthi/ibrowse/blob/master/src/ibrowse_http_client.erl#L936-L939

Of course I'm interested :-)
That function in ibrowse is not digest auth though... If you look a couple lines higher: {"Authorization", ["Basic ", http_auth_digest(U, P)]} And just, like, look at it – it does no hashing ("digest"), just base64.
So you'd have to write it from scratch.
P.S. You should send a pull request to ibrowse that renames it to http_auth_basic!

thanks @myfreeweb . I have given a PR for renaming here: https://github.com/cmullaparthi/ibrowse/commit/e478d010259fcc2558afec7b50712d0507710ed7
and I am working on supporting Digest auth here: https://github.com/cmullaparthi/ibrowse/commit/d8b9331688820d8a05e995d002dc7a0cd1cee339

Nah, you won't need to change their public API. Passing basic_auth to ibrowse is just a convenience thing. Auth is just a header!
Just do it like headers = Dict.put(headers, "Authorization", "Digest ... ... ...")

I see you're working on adding digest auth directly to ibrowse though... Yeah, if they accept that, it'll be even better.

@myfreeweb if this has to go into httpotion, could it be something like https://github.com/shankardevy/httpotion/commit/d2610908472b96ce736064c538ec21be38b5112d
can we have the digest_auth support directly on httpotion until ibrowse supports it?
with the above commit, we would use digest_auth as
 HTTPotion.get "http://localhost:3000/digest", [digest_auth: {"foo", "bar"}]

Sinatra app for running a digest_auth server is available at https://gist.github.com/shankardevy/535f48fb4583425049c3
PS: the commit is still WIP. nonce value needs to be secure, which isn't now.


Creating pull requests failed: HttpError: Validation Failed: {"resource":"PullRequest","code":"custom","message":"not all refs are readable"}

Extension version: v0.22.0
VSCode Version: GitHub Codespace Insiders
OS: Ubuntu 20

Trying to use this extension with GitHub Codespaces (Insiders), gives the following Error when trying to create a pull request for a private repo: Creating pull requests failed: HttpError: Validation Failed: {"resource":"PullRequest","code":"custom","message":"not all refs are readable"}
Creating a pull request for a public repo works fine.

There have been auth changes around private repo in Codespaces. Please comment if you're still seeing this issue!


Fake Payjoin?

Is there any reason not to create fake "payjoin" transactions for better privacy?
It's similar to the fake "coinjoin" feature, but with less outputs so it's better if you want to consolidate your UTXOs (and pay a little bit less fees), and not splinting them, but still get better privacy.

No reason not to. Generally the more entropy in a transaction the better. Transactions with multiple inputs and outputs have more possible interpretations - so long as the basic guidelines of avoiding rounded amounts and multiple script types are followed.

So what about adding it as a feature?

You can already create transactions with multiple inputs and outputs.

How can I force the wallet to add an input, even if it's not "needed"?

Just multiple select from the UTXOs tab.


Revert "AlignDoubleArrowFixer - fix handling of nested array"

This reverts commit f7777cf707b840edb1101eeec43cd6ace5749128.
Fixes #1450.
cc @SpacePossum

:+1:
not all reverts are needed, but I get it :)
(it would be nice to have a test added that proves the revert fixes the issue. It would also prevent breaking (in that way) again in the future,)

it would be nice to have a test added that proves the revert fixes the issue

You have it on #1450. :-)

Ping @keradus this is quite urgent IMO.

No tests to prove the behavior was added, but that was already said by @SpacePossum

No tests to prove the behavior were added, but that was already said by @SpacePossum

Will work on it soon.
I don't understand your code comment about bad changes. I just reverted the commit.

Not all work need to be reverted, then why to throw it away?

Not all work need to be reverted, then why to throw it away?

@SpacePossum said that he doesn't have time to fix it for the moment on proposed to revert the PR.

And I said that not all of the work need to be reverted blindly.

@SpacePossum Could you tell me which changes need to be reverted?

If you won't believe the comments simply add missing tests and it will be clear ;)

@keradus @SpacePossum Here is the proof: https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/1454

the proof should be in THIS PR to prove that this change will fix it.

@keradus added.

Proof fails with and without revert.

Ok. No time to fix it for the moment.
@SpacePossum I let your the liberty to cherry-pick my proof to see where is the problem. :+1:

Closing PR as the revert is not a fix.
If anyone want to work on the fix please start from #1455 and I will be happy to merge it ;)

@keradus I manually tested the revert with my proof tests.
This fix one of them. I think the other (new DummyObject) is unrelated.
Possibly not a bug, or one introduced long time ago.
Will remove this one for the moment. What do you think about it?


Custom Parser not working?

I am trying to resolve default native-color-picker type from storyblok with a custom parser.

This is my parser:
function customParser(key, obj) {
  switch (obj.plugin) {
    case "native-color-picker":
      return {
        [key]: {
          _uid: "string",
          color: "string",
          plugin: "string",
        },
      }
    default:
      return {}
  }
}

And here is my script to call everything:
storyblok-generate-ts source=./components.XXXX.json target=./src/types/component-types-sb customTypeParser=./custom-parser.js
Unfortunately this does not parse anything for me. Also tried to put everything into a seperate node file but then I also get an error storyblokToTypescript is not a function
What am I doing wrong here?
Thanks for help :)

Hi this is an example file of a custom parser, I use it like this for quite some times.
module.exports = function customTypeParser (key, obj) {
  switch (obj.field_type) {
    case 'bootstrap-utility-class-selector':
      return {
        [key]: {
          type: 'object',
          properties: {
            values: {
              type: 'array',
              items: {
                type: 'string'
              }
            }
          }
        }
      }
    case 'vue-color-picker':
      return {
        [key]: {
          type: 'object',
          properties: {
            rgba: {
              type: 'string'
            }
          }
        }
      }
    case 'material-icons-selector':
      return {
        [key]: {
          type: 'object',
          properties: {
            name: {
              type: 'string'
            }
          }
        }
      }
    default:
      return {}
  }
}

I got it working, definitely misunderstood how to use this. But I am curious how you used obj.field_type. I cannot find this property in the JSONSchema4 specification.

basically obj.field_type will be the name of your custom plugin, probably its native-color-picker. With the custom parser you can type the result of that component and that will generate the correct types for your. Its basically a placeholder for custom plugin types where you can define the return type in case values are selected.


Position should be static by default when native behavior is ignored.

By default, position: static should be applied when native behavior is ignored.
Otherwise, there are various scenarios where the element will retain position: sticky regardless of configuration. For example, if the jquery plugin was never applied to an element or if it's effect has later been destroyed, the element will still have position: sticky from the fixedsticky class.

Really sorry this never made it in. Closing all the PRs—this plugin is now deprecated:  https://github.com/filamentgroup/fixed-sticky#-this-plugin-is-deprecated-


Where to get a "static" api key?

Hello, so currently I'm getting my api key from here, but it seems that it resets every like 40 minutes. (Yes, I've linked my Outlook account)
Where do you guys get your key?

Don't believe there is one - but if you find a way, let me know! I just have a celery task running which refreshes the token - for a while I used Google Apps Scripts (free and you can run scheduled tasks ;) ). I keep the token stored in Firebase and just have everything pull the token from there.

I was looking into Google Apps Scripts. Could you explain how you refresh the token? Sorry, I'm still a noob ;)

Make a post request to https://login.microsoftonline.com/common/oauth2/v2.0/token with the payload:
{
refresh_token: token_from_initial_request,
client_id: your_client_id,
client_secret: your_client_secret,
grant_type: refresh_token,
scope: same_scope_you_initially_requested
}

you should get the following back:
{
access_token: 123,
refresh_token: 321
}

Thanks. Will do this later today.


IME-63 To allow Setting up two network devices. These devices can be …

…static or DHCP

@RackHD/corecommitters please review.

The changes will allow user to set up network devices with static or dynamic ip address. it will also allow to create switch devices.
@RackHD/corecommitters @jimturnquist @johren

BUILD on-http #2699 : FAILURE

** BUILD build-config-setup  #131018: SUCCESS
** BUILD unit-tests  #9727: UNSTABLE
** BUILD smoke-test  #3600: FAILURE

BUILD unit-tests  #9727  Error Logs:
Test Name: Services.WebSocket a ws client db resource watch should listen for created items
Error Details: timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.
Stack Trace: Error: timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.


LIFX support completely broken.

LIFX bulb firmware (released this summer) broke the LIFX SDK. Thus the LIFX driver in LampShade needs to be rewritten to use the LIFX web API.

Yesterday I discovered that LIFX made some changes to the their (officially dead) SDK in mid august which appear to fix the major compatibility problems with LIFX bulb firmware 2.0. I've pulled these changes into LampShade version 3.1.3 as a stopgap measure.
Given how long the  LampShade Device Driver rewrite is taking, LIFX support via the web API may not be done in time for 3.2.

Crashing fixed in 3.1.3, so tracking the remaining work with #92


Change Lagrangian sign for consistency

Consistency: JuliaOptimizers/NLPModels.jl#6

Coverage decreased (-2.2%) to 97.207% when pulling f03c14c982139b774d118887e2c10498838f161f on abelsiqueira:fix/lagrangian into e7753aed1eccdd51351f68a091f133978ee68b04 on JuliaOptimizers:develop.

Thank you.


Adds a cache for lower and upper bounds.

Pass all tests. No new tests added, as it just change internals of existing methods in a way that is transparent on purpose.

I did not change the documentation either. It is probably wise to not have users depend on this behavior.

Sorry to bother you @odow, but if you can take a look at it, I would be grateful.

Running the benchmark case I cited in the other PR with version v0.7.6 I get:
-------------------- batch --------------------------
Academic license - for non-commercial use only
  0.666660 seconds (2.34 M allocations: 99.870 MiB, 3.02% gc time)
-------------------- alternating --------------------
Academic license - for non-commercial use only
 24.491731 seconds (1.21 M allocations: 47.774 MiB, 0.04% gc time)

-------------------- second run ---------------------

-------------------- batch --------------------------
Academic license - for non-commercial use only
  0.188990 seconds (1.30 M allocations: 49.313 MiB, 4.78% gc time)
-------------------- alternating --------------------
Academic license - for non-commercial use only
 24.713548 seconds (1.20 M allocations: 47.019 MiB, 0.03% gc time)

With this PR I get:
-------------------- batch --------------------------
Academic license - for non-commercial use only
  0.683119 seconds (2.38 M allocations: 105.173 MiB, 2.83% gc time)
-------------------- alternating --------------------
Academic license - for non-commercial use only
  0.184018 seconds (1.21 M allocations: 50.826 MiB, 10.60% gc time)

-------------------- second run ---------------------

-------------------- batch --------------------------
Academic license - for non-commercial use only
  0.189114 seconds (1.30 M allocations: 52.365 MiB, 6.65% gc time)
-------------------- alternating --------------------
Academic license - for non-commercial use only
  0.167479 seconds (1.20 M allocations: 50.071 MiB, 6.87% gc time)

Awesome work!


Allow create-cwl-wes-template and start-cwl-wes to set outputs into project-name

Using the analysisOutput configuration in the start:CWL post API, this means we can now place outputs into a different project.

Resolved in #252


Update information about default host to ping;

While reading the RealReachability class I've noticed that the default host to ping is not www.apple.com anymore.

My fault. Wrong documentation. In the code the host is www.apple.com. I will update the comments.


Upgrade GoogleAppEngineLauncher.app to v1.9.18

The package here is AppEngine Launcher/SDK, not the AppEngine product, therefore I don't think that changing the homepage to https://cloud.google.com/appengine/ is wise as there's no direct link to download page.
Would you mind modifying the PR, please?

Yes, I think you're right, I've reverted the homepage to the old one.


upgrade dependencies to address security vulnerabilities

Summary
This PR upgrades the following dependencies to address security vulnerabilities:

xml2js
jsonwebtoken
trim-newlines

Thank you


lock.py: handle statuses with no description

Signed-off-by: Dan Mick<EMAIL_ADDRESS>

Refer to this link for build results (access rights to CI server needed):
http://jenkins.ceph.com//job/teuthology-pull-requests/1567/
Tests passed for this pull request.


Small refactoring changes

This is mostly stuff I did just to please pylint while becoming familiar with the code base. I also:

Replaced the deprecated OptionParser with the recommended ArgumentParser module.
Removed COMMANDS, since we can work this out from the Client class.
Added type hints.
Added to a few different docstrings, renamed some variables and moved stuff around.

Hi, that's pretty cool. It's conflicting with my newest commit since I also changed to argparse (with the audio features).
I will resolve the conflicts and merge it tonight.
Thanks :)

I resolved all the conflicts I created. We had the same ideas about ArgumentParser and typings so that's good.
The only thing I did not implement was the check on:
if args.mode is None:a
Since it seems argparse does it by default for positional arguments.
Let me know if I forgot something. Next time I will do my update on a branch instead of the main branch (to avoid conflicts).

I guess significant conflicts are unavoidable since the project is still young. Good point on argparse, somehow I didn't realise this!


[MINOR][site] Updated blogs for October

Change Logs
Adding blogs for october
Impact
site updates
Risk level (write none, low medium or high below)
none
Documentation Update
Describe any necessary documentation update if there is any new feature, config, or user-facing change. If not, put "none".

The config description must be updated if new configs are added or the default value of the configs are changed
Any new feature or user-facing change requires updating the Hudi website. Please create a Jira ticket, attach the
ticket number here and follow the instruction to make
changes to the website.

Contributor's checklist

[ ] Read through contributor's guide
[ ] Change Logs and Impact were stated clearly
[ ] Adequate tests were added if applicable
[ ] CI passed

Tested lcoally!
Blogs pages

Video guides page


Update README.md

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=ru
Description of changes:

"An unexpected error has occurred, could you please contact admins. Your RequestID: 129d13fc-ada9-4666-8c32-6f96cbb86849"


Agent doesn't execute next step after clicking "Continue"

This is with the latest agent installed through apt. This used to work before but now the next step won't execute. Also there's no way to cancel this and the agent is now unusable. Here's the log:
Assigned job 16edbb6c-495b-493a-9911-e8df00663857. Accepting...
2015-06-17 02:36:37 INFO   Starting job 16edbb6c-495b-493a-9911-e8df00663857
2015-06-17 02:36:38 ERROR  Failed to run job: PUT https://agent.buildkite.com/v3/jobs/16edbb6c-495b-493a-9911-e8df00663857/start: 422 This job can't be started while the build is in a `passed` state.
2015-06-17 02:36:41 INFO   Assigned job 16edbb6c-495b-493a-9911-e8df00663857. Accepting...
2015-06-17 02:36:42 INFO   Starting job 16edbb6c-495b-493a-9911-e8df00663857
2015-06-17 02:36:43 ERROR  Failed to run job: PUT https://agent.buildkite.com/v3/jobs/16edbb6c-495b-493a-9911-e8df00663857/start: 422 This job can't be started while the build is in a `passed` state.
2015-06-17 02:36:46 INFO   Assigned job 16edbb6c-495b-493a-9911-e8df00663857. Accepting...

Any idea how to fix this or forcefully cancel the job?

@darkcrux sorry! This is a bug that we're currently fixing with "Click to continue" steps. Email<EMAIL_ADDRESS>or head to https://chat.buildkite.com/, and we'll sort out the builds you need to fix in the mean time!

Hey @darkcrux, this problem has now been fixed. Let us know if you've any other problems!


Use executor app-build-suite, use latest architect-orb

This is a test

Current error output:
failed linting charts: could not unmarshal 'Chart.yaml': yaml: unmarshal errors:
  line 4: cannot unmarshal !!seq into string
ct run failed with exit code 1
Error when running build step for HelmChartToolLinter: Linting failed
Error when running build: Source: 'HelmChartToolLinter', message: Linting failed.. No further build steps will be performed, moving to cleanup.


Add expected performance metrics (benchmarks) for zed products in docs

Preliminary Checks

[X] This issue is not a duplicate. Before opening a new issue, please search existing issues.
[X] This issue is not a question, bug report, or anything other than a feature request directly related to this project.

Proposal
Although documentation is very well written I believe that benchmarking FPS, CPU, GPU usage for depth sensing and positional tracking on  Nvidia NX ( jetson box) ZED BOX for ros-2-wrapper (for example) could provide better estimate of what is expected at runtime. It seems that ZED Sdk processing is quite intensive and leaves little room to do other things (is multi camera setup on xavier NX even possible)?
Clarifications of these sorts of things would help a lot.
Use-Case
No response
Anything else?
No response

Hi @jodusan
interesting request. The problem is that there are so many possible combinations that it is not easy to provide a benchmark for each of them. A short list of the variables involved:

resolution
positional tracking
object detection (AI model, tracking, ...)
3D mapping
Jetson nvpmodel
...

I was just reading through your comments here https://github.com/stereolabs/zed-ros2-wrapper/issues/22 is there a preferred DDS for Jetson boards? or at least configuration of the current one (FastDDS?) (In my case Jetson NX). I'm getting around 100% faster performance with ROS 1 Noetic than with ROS 2 Galactic zed-ros-wrapper

@Myzhar  I'm trying to profile zed_ros2_wrapper node with valgrind to see where the bottleneck is, but when running zed2i.launch.py built with
colcon build --symlink-install --cmake-args=-DCMAKE_BUILD_TYPE=RelWithDebInfo
It just hangs with
"""
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [robot_state_publisher-1]: process started with pid [17922]
[INFO] [zed_wrapper-2]: process started with pid [17924]
[robot_state_publisher-1] Link zed2i_base_link had 1 children
[robot_state_publisher-1] Link zed2i_camera_center had 2 children
[robot_state_publisher-1] Link zed2i_left_camera_frame had 1 children
[robot_state_publisher-1] Link zed2i_left_camera_optical_frame had 0 children
[robot_state_publisher-1] Link zed2i_right_camera_frame had 1 children
[robot_state_publisher-1] Link zed2i_right_camera_optical_frame had 0 children
[robot_state_publisher-1]<PHONE_NUMBER>.409792280 [zed2i.zed_state_publisher] [INFO] got segment base_link
[robot_state_publisher-1]<PHONE_NUMBER>.410137661 [zed2i.zed_state_publisher] [INFO] got segment zed2i_base_link
[robot_state_publisher-1]<PHONE_NUMBER>.410237791 [zed2i.zed_state_publisher] [INFO] got segment zed2i_camera_center
[robot_state_publisher-1]<PHONE_NUMBER>.410313312 [zed2i.zed_state_publisher] [INFO] got segment zed2i_left_camera_frame
[robot_state_publisher-1]<PHONE_NUMBER>.410388417 [zed2i.zed_state_publisher] [INFO] got segment zed2i_left_camera_optical_frame
[robot_state_publisher-1]<PHONE_NUMBER>.410467106 [zed2i.zed_state_publisher] [INFO] got segment zed2i_right_camera_frame
[robot_state_publisher-1]<PHONE_NUMBER>.410528899 [zed2i.zed_state_publisher] [INFO] got segment zed2i_right_camera_optical_frame
[INFO] [zed_wrapper-2]: process has finished cleanly [pid 17924]
"""
Any suggestions?


Require cloud_controller.read access(or equivalent) to access list endpoints.

Thanks for contributing to cloud_controller_ng. To speed up the process of reviewing your pull request please provide us with:

A short explanation of the proposed change:

Require cloud_controller.read access(or equivalent) to access list endpoints.

[x] I have reviewed the contributing guide

[x] I have viewed, signed, and submitted the Contributor License Agreement

[x] I have made this pull request to the main branch

[x] I have run all the unit tests using bundle exec rake

[ ] I have run CF Acceptance Tests

Two things to note:

users with write permissions but not read permissions can no longer read as well in this pr.

unauthenticated users can access marketplace without permissions if the toggle for the marketplace visibility is turned off, unlike other endpoints.

Now it seems to me that this is possibly an oversight brought by interaction between the list endpoint logic and the filtering logic. We have one layer of filters that effects permissions that looks at tokens and one that looks at users. The token logic isn't implemented because we assume that any filtering will happen at the user logic level, and the user logic filtering level doesn't actually effect "public" marketplace values. This means that unauthenticated users can access marketplace values. - Now If I had to guess, we "papered over" this problem with the "allow unauthenticated users" toggle. Given it exists, it seems resonable to honor that contract, but at some point it seems like we should possibly eol that toggle and just make sure that only cf users can access "public"(aka, for all orgs and spaces) information always.

Looking into this sent me down a rabbit hole about the *_with_token methods on the access classes.
In summary, they were first introduced by https://github.com/cloudfoundry/cloud_controller_ng/pull/221 for this story.
It appears the main difference between the two methods is what error is returned: InsufficientScope vs NotAuthorized.