Indicate the actual connection mode being used for a session

Hello
Can we deploy local live share servers so we can use our own servers in our work environment for a faster connection?

@hmdhasani We do not have a local server option, but the good news is Live Share will actually automatically attempt to use a peer-to-peer connection before falling back to an internet relay to optimize performance. You can read more about the different connection modes Live Share supports here: https://aka.ms/vsls-connectivity

thank you @Chuxel
Is there any way to find out whether the current connection is P2P or not?

@hmdhasani You can force "direct" mode if you want so it won't use the relay. Instructions are in https://aka.ms/vsls-connectivity

OK that's good but as a feature request I think it will be useful if we can see the connection type somewhere to be sure that the connection type is in the best mode (and for example for some network configuration issues it did not take the internet server)

Closing this due to low activity and lack of significant customer interest. We can re-open it if/when we begin to hear more feedback 👍


refactor(solid-query): Ensure correct type inference when using skipToken in createQueries

While writing test code for solid-query, I discovered that type inference fails when a skipToken is present, as shown in the attached photo below. Unlike react-query, it does not correctly infer types. I have made modifications to createQueries to ensure accurate type inference.

react-query
solid-query

Codecov Report

Merging #7221 (33e9413) into main (93674fe) will decrease coverage by 0.34%.
Report is 53 commits behind head on main.
The diff coverage is 100.00%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7221      +/-   ##
==========================================
- Coverage   41.42%   41.08%   -0.34%
==========================================
  Files         184      183       -1
  Lines        7331     7355      +24
  Branches     1531     1534       +3
==========================================
- Hits         3037     3022      -15
- Misses       3889     3925      +36
- Partials      405      408       +3

Components
Coverage Δ

@tanstack/angular-query-devtools-experimental
∅ <ø> (∅)

@tanstack/angular-query-experimental
86.46% <0.00%> (ø)

@tanstack/eslint-plugin-query
85.29% <100.00%> (ø)

@tanstack/query-async-storage-persister
49.20% <ø> (ø)

@tanstack/query-broadcast-client-experimental
∅ <ø> (∅)

@tanstack/query-codemods
0.00% <0.00%> (ø)

@tanstack/query-core
93.29% <95.12%> (+0.03%)
:arrow_up:

@tanstack/query-devtools
3.92% <0.00%> (-0.02%)
:arrow_down:

@tanstack/query-persist-client-core
57.73% <ø> (ø)

@tanstack/query-sync-storage-persister
82.50% <ø> (ø)

@tanstack/react-query
92.77% <100.00%> (ø)

@tanstack/react-query-devtools
10.71% <ø> (ø)

@tanstack/react-query-next-experimental
∅ <ø> (∅)

@tanstack/react-query-persist-client
100.00% <ø> (ø)

@tanstack/solid-query
81.62% <54.54%> (-0.65%)
:arrow_down:

@tanstack/solid-query-devtools
∅ <ø> (∅)

@tanstack/solid-query-persist-client
100.00% <ø> (ø)

@tanstack/svelte-query
62.68% <100.00%> (ø)

@tanstack/svelte-query-devtools
∅ <ø> (∅)

@tanstack/svelte-query-persist-client
100.00% <100.00%> (ø)

@tanstack/vue-query
71.04% <90.47%> (+0.23%)
:arrow_up:

@tanstack/vue-query-devtools
∅ <ø> (∅)

is this similar to:

https://github.com/TanStack/query/pull/7189

?


Add gcp-hosted-github-runner

Hi,
The last few days I've been working on gcp-hosted-github-runner. This is a GitHub webhook-based solution with ephemeral runners hosted by Google Cloud. The deployment is done with Terraform. The project is only 16 days old and does not yet have any contributors or stars.

thank you, merged


Issue #98: Adding page and page_size parameter to export_text_analysis

adding page and page_size as parameters to export_text_analysis
some documentation
(no tests): appear to be too cumbersome, instead tested it with a live product (see comment: https://github.com/averbis/averbis-python-api/issues/98#issuecomment-988057715)

Codecov Report

Merging #99 (4724208) into dev (44d78a5) will decrease coverage by 0.04%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##              dev      #99      +/-   ##
==========================================
- Coverage   91.29%   91.25%   -0.05%
==========================================
  Files          16       16
  Lines        1838     1840       +2
==========================================
+ Hits         1678     1679       +1
- Misses        160      161       +1

Impacted Files
Coverage Δ

averbis/core/_rest_client.py
85.42% <66.66%> (-0.08%)
:arrow_down:

Continue to review full report at Codecov.

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

Ready to be reviewed.


Error when remove user from group

I am trying to remove some users from a group but when run the apply I am getting an error from the provider that cannot find the user info.
I tried with different groups and users getting the same result. Not sure if there is a problem with the query in checkIfUserExists
module.aws-redshift.redshift_group.this["group_name"]: Modifying... [id=44633053]
2022-09-16T13:34:16.670+0200 [ERROR] vertex "module.aws-redshift.redshift_group.this[\"group_name\"]" error: error reading info about user: %!s(<nil>)
╷
│ Error: error reading info about user: %!s(<nil>)
│
│   with module.aws-redshift-data-redshift.redshift_group.this["group_name"],
│   on modules/aws-redshift/main.tf line 85, in resource "redshift_group" "this":
│   85: resource "redshift_group" "this" {
│
╵
´´´

Which version of the provider are you using?
I believe this has been fixed in the latest v1.0.2 release (https://github.com/brainly/terraform-provider-redshift/releases/tag/v1.0.2)

I was using 1.0.1, I have updated and it worked.
Thank you


only top-level classes have this restriction

Inner classes can be private

Good catch, and an important distinction to make. Thanks!


Update components list

Background
Some components are missing from the preview list on /beta/checkout-extensions/components on Shopify.dev.
I'm orienting myself to the repositories for checkout-extensions, so apologies if I've updated the incorrect content
Solution
Added links to the content, for /beta/checkout-extensions
🎩
Tested the links and they resolve as expected

Checklist

[ x] I have :tophat:'d these changes
[x ] I have updated relevant documentation

being exposed in the public package

The "public" package is still hidden and the docs too, right? If so, I'm good with that change. Note that the list of components will continue to evolve as we get closer to Beta, and this package will most likely change multiple times.

would you mind also opening a PR to fix it there

@rennyG I have a PR already open that adds new component to checkout-ui-extension, so I'll add these at the same time.

These will be entirely hidden, as I'm shipping this to a develop branch for the checkout work, not to main. When I do ship to main, I'll gate this content behind a feature flag that I set up recently. Happy to share more details, if you want, but the short answer is nothing's being published publicly until the June Edition


Always deploy Licensify using deployment master

This mirrors the way all of our other apps are deployed.

👍


Possible to use localhost for ROS and define an external IP?

I am willing to start the multimaster at boot, but the network (Zerotier VPN) is not ready so roscore fails.
The VPN conncets to the internet via a 4G module, meaning that it takes at least 1 minute to be "ready".
I guess the master sync is using the ros master server directly, so it does not allow to use localhost to start and listen to/advertise another IP?

Using localhost for communication between master_sync and roscore is not the problem. But if you use localhost in ROS_MASTER_URI it can lead to problems in communication to remote ROS nodes.
Is it possible to delay start of ROS nodes until VPN es ready?

The VPN is a "virtual interface" so the systemd triggers are not working; The network is not ready when the virtual device wakes up.
Which of the following solutions would be best:

Create a new FKIE application which first waits for the interface then run the main function of the original application
Create an application that waits and returns when the interface has an IP, then run the normal roslaunch
Isn't it possible to use default_cfg_fkie to run the next one once the first app returns?

Does the ROS Master start if VPN is not ready?
If yes: it would be better to wait in the main function of FKIE application until VPN is ready.
if no: you need an external script or something else what trigger a roslaunch start after VPN is ready.
default_cfg_fkie can delay a start of nodes or start these after a defined publisher topic is available.
Each node in roslauch needs follow parameter:
    <param name="default_cfg/autostart/required/publisher" value="topic_name" />

No, the master will not start before the IP is set. I'll go for the script checking the interface and starting the roslaunch as soon as ready

For future reference, this it the solution I chose:
Service file: /lib/systemd/system/robot.service
[Unit]
Description=Robot bringup for the universe app manager and multimaster

[Service]
User=alexis
Group=alexis
ExecStart=/usr/share/bringup.sh

[Install]
WantedBy=multi-user.target

Bringup script: /usr/share/bringup.sh
#!/bin/bash

# Wait until zerotier network is ready using python one-liner
FOUND_IP=$(python -c "import socket; import fcntl; import struct; from time import sleep

def get_ip_address(ifname):
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    return socket.inet_ntoa(fcntl.ioctl(
        s.fileno(),
        0x8915,  # SIOCGIFADDR
        struct.pack('256s', ifname[:15])
    )[20:24])

while True:
  try:
    print get_ip_address('ztuzethfie')
    break
  except:
    sleep(0.1)")
# End of python

bash -c "source /home/alexis/rossetup.bash && ROS_IP=$FOUND_IP ROS_HOSTNAME=$FOUND_IP ROS_MASTER_URI=http://$FOUND_IP:11311 stdbuf -oL roslaunch umd_platform bringup_robot.launch"

@AlexisTM thank you for sharing!


Fixed description of the custom gate example

The custom gate is a cx between 0 and 2, using 1 to intermediate. The original described it as a cx between 0 and 1, using 1 to intermediate.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


fill in LIP3

thanks @aching! updated

Looks good for draft.  I do hope the source of truth for this set of protocols can live in the specifications (https://github.com/libra/libra/tree/master/specifications).  This is an informational LIP about a specification IMO.


Remove this line and add a new one with the logging package

https://github.com/AlvaroRodriguezGallardo/src-brokering/blob/a3e7af82dfbba7263f3cff65653650fab12b6cfe/example-fn/exercise_fn.py#L60

Done! However, in Dockerfile it is had '-/' folder as default, so it may not enter in that condition

Okay! Done


CSD-2: Add coverage testing in the pipeline with badge

This PR adds a test coverage report as an artefact in the pipeline plus a coverage percentage badge to the README file. Coverage percentage is the percentage of the main branch only (it is not updated in branches from main). Test coverage percentage will be shown in the pipeline job (and detailed coverage report can be accessed as an artefact from here).

I should also note that the CSV test has been updated as part of this PR since that was failing in the pipeline (it had previously been passing on my local machine since I had files present that are not part stored in Git).


curl: add SecureTransport for darwin

Is your feature request related to a problem? Please describe.
On MacOS/darwin, the (private) certificates are typically managed in the system via Keychain (in a corporate environment the certificates are injected there by the enterprise admins).
curl on nix/darwin does not lookup certificates in Keychain by default, such that all MacOS/darwin users with nix need to devise a manual stopgap; in the end exporting all needed certificates into $NIX_SSL_CERT_FILE which a) is a temporary solution, and b) reduces the security posture.
Otherwise (without the stopgap), users of nix on MacOS/darwin observe the strangest error messages such as
OpenSSL/3.0.10: error:16000069:STORE routines::unregistered scheme

coming from all types of tools (like git) that somewhere rely on/ use curl in their tool-chain.
Describe the solution you'd like
in pksg/tools/networking/curl, add the default configuration flag --with-secure-transport  for compiling curl if isDarwin.
Notice the missing SecureTransport feature in comparison to curl provided by Apple:
~/.nix-profile/bin/curl -V
curl 8.1.1 (aarch64-apple-darwin22.4.0) libcurl/8.1.1 OpenSSL/3.0.10 zlib/1.2.13 brotli/1.0.9 zstd/1.5.5 libidn2/2.3.4 libssh2/1.11.0 nghttp2/1.51.0
Release-Date: 2023-05-23
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

/usr/bin/curl -V
curl 8.1.2 (x86_64-apple-darwin22.0) libcurl/8.1.2 SecureTransport (LibreSSL/3.3.6) zlib/1.2.11 nghttp2/1.51.0
Release-Date: 2023-05-30
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL threadsafe UnixSockets

Describe alternatives you've considered
Abandon curl from nix and fallback to curl from Apple.
Priorities
The end-user is forced to investigate/debug to find out that curl is the issue, as most of the tools typically do not offer further information.

Any update on this? I am currently going to fall back to the described alternative (stop installing curl from nixpkgs and rely on the system-provided one for now) but I'd appreciate the ability to install a curl from nixpkgs that uses the system keychain for certs.


Set up code coverage CI

User Story
When a developer makes a pull request against any branch, ISBAT see code coverage
Acceptance Criteria
GIVEN
A developer making a pull request
WHEN
Github actions are run
THEN
Code coverage check should be run, and flag any PR that has less than 90% coverage

Don't want to block PR's by arbitrary code coverage

Don't want to block PR's by arbitrary code coverage


Mat_GetDir takes an infinite time to return values

tested on windows matio 1.5.18
test_suites.zip
  char** variableNames = Mat_GetDir(matfile, &nVars);

mat contains a struct 'B' with many others struct as field.

@tbeu :  any advice (workaround) to speed up reading of this file ?

Can reproduce. Mat_GetDir is badly implemented and leads to performance loss for structs/cells.

Similar (?) thing here. Using matio 1.5.18 (current master) on windows in python (using ctypes).
As it turns out, I have different versions of Visual Studio on my machine and on our CI server (thanks, VS Update...):
My Machine:
-- The C compiler identification is MSVC 19.27.29112.0
-- The CXX compiler identification is MSVC 19.27.29112.0
CI:
-- The C compiler identification is MSVC 19.24.28319.0
-- The CXX compiler identification is MSVC 19.24.28319.0
When calling Mat_GetDir on my machine (using the newer compiler), everything works as expected. Some Unit tests that call Mat_GetDir work as expected. On the CI server on the other hand (same build script, same Unit test) the function starts an infinite loop. By building with Debug information (RelWithDebInfo) I could find out that this loop does not stop:
            mat->num_datasets = 0;
            do {
                matvar = Mat_VarReadNextInfo(mat);
                if ( NULL != matvar ) {
                    if ( NULL != matvar->name ) {
                        if ( NULL == mat->dir ) {
                            dir = (char**)malloc(sizeof(char*));
                        } else {
                            dir = (char**)realloc(mat->dir,
                                (mat->num_datasets + 1)*(sizeof(char*)));
                        }
                        if ( NULL != dir ) {
                            mat->dir = dir;
                            mat->dir[mat->num_datasets++] = strdup(matvar->name);
                        } else {
                            Mat_Critical("Couldn't allocate memory for the directory");
                            break;
                        }
                    }
                    Mat_VarFree(matvar);
                } else if ( !feof((FILE *)mat->fp) ) {
                    Mat_Critical("An error occurred in reading the MAT file");
                    break;
                }
            } while ( !feof((FILE *)mat->fp) );

Mat_VarReadNextInfo seems to not stop here. This only occurs in 64bit.
As I said, updating the MSVC compiler seems to solve this...

@jnjaeschke I cannot image that the difference in behaviour is due to the difference in compiler version. Could you please provide your MAT file, too?

Matio_issue_157_compiler_versions.zip
@tbeu  In the zip file you find the test file (I think it was created using matio a while ago) as well as a working matio DLL (RelWithDebInfo, built on my machine) and the not working matio DLL built with the older compiler, also in RelWithDebInfo. The binaries are x64 and built using CMake.
I also noted a difference in file size (250kb <-> 251kb @ RelWithDebInfo, 159 <-> 162 kb @ Release), so there definitely is a difference...

@jnjaeschke Your reported issue is different from the original issue reported by @Nelson-numerical-software. Whereas the original issue is a performance problem of large and nested structures (of v5 or v7.3 MAT files), your issue (of v4 MAT files) is more critical and can lead to undefined behaviour (such as infinite loops). Please confirm if 289c586 fixes your reported issue in your environments. I will need to release a new version afterwards in case of positive feedback. Thanks.

@tbeu That fixed the issue. Thank you very much!

Fixed by 274dfef.


FindStringRef return nullptr

Hi!
I'm unsure if this is the right place for support.
I'm trying to generate mappings for a game demo (UE5.0.3) not an actual game. Is that even possible?
When running the .exe and injecting the dll, this is the error i get.
I can send the demo if need be. But i do not know how to write code myself.
My discord is Extile#3247

Fixed it and sent you the mappings. Enjoy!

Having the same error on a 5.1 game, any hints on what was the problem as I don't see a commit related to the issue?
Thanks :)


Fix ANIMATESHEET for custom particle effect

https://forum.babylonjs.com/t/cpu-particlesystem-with-custom-fragmentshader/38090/4

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

Snapshot stored with reference name:
refs/pull/13533/merge
Test environment:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/13533/merge/index.html
To test a playground add it to the URL, for example:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/13533/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/13533/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/13533/merge
https://gui.babylonjs.com/?snapshot=refs/pull/13533/merge
https://nme.babylonjs.com/?snapshot=refs/pull/13533/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/13533/merge#BCU1XR#0


Faulty Progress Bar on Mac

I am using VS Code in MacOS
When I use python interactive window, the progress bar doesn't function properly.
This is my code
from rich.progress import track
import time
months = ['January','February','March']
for month in track(months):
    time.sleep(1)

Would you mind post a screenshot so I know what is wrong.

@nellorebhanuteja Can you elaborate more on what exactly do you mean by "progress bar not updating properly"? Is it stuck or what exactly is the behavior you are experiencing?

@acbokade

Well, the progress bar is stuck (doesn't progress), while other print statements are executing fine.
Some times progress bar keeps blinking.
When I run the script in terminal, progress bar is at the bottom of all logs always. Here its on the top and doesn't move.  This makes it difficult to track progress esp. when there are many logs.

@acbokade

Well, the progress bar is stuck (doesn't progress), while other print statements are executing fine.
Some times progress bar keeps blinking.
When I run the script in terminal, progress bar is at the bottom of all logs always. Here its on the top and doesn't move.  This makes it difficult to track progress esp. when there are many logs.

Try running it on Terminal Emulator and see if result is same. Also check VS Code's terminal settings. See if it supports ANSI

@UltraStudioLTD
It is working fine in Terminal Emulator.
Yes, VS code supports ANSI.
Its working fine in VS Code integrated terminal also.
The above behaviour exists in VS Code Python Interactive window.

@nellorebhanuteja I gather you are using Jupyter notebooks in VS Code (you might want to lead with that next time).
This works fine in Jupyter outside of VSCode. Could be a bug in VS Code. We will investigate.

FYI I believe notebooks support very few sequences, ie. it's not using [xterm.js](https://github.com/xtermjs/xterm.js like the main integrated terminal). cc @rebornix

We've managed to reproduce this in VS Code only, but it appears to be intermittent.
Running the code you supplied in VS Code works sometimes, and sometimes it doesn't. However, when we run this in Jupyter outside of VS Code it works consistently.
We suspect it's a bug in VS Code, so there's nothing we'll be able to do here I'm afraid. Sorry we can't be of more help.


It is posibble to save chat just like chatGPT does?

Describe the feature or improvement you're requesting
I like to use the api to ask question, but you know the chatGPT will save the chat conversation, next time you ask a question in the chat, it will answer based on the chat conversations. But this api of the openai library using seems did not save the chat.
here is the test:

Here is the chatGPT did.

Additional context
I dont know why it did not save that chat as chatGPT does,  because its free account or something else?
I can pay for the api that can save chat and then response just like chatGPT did. I need help. Thanks.

With GPT3 you will always be limited to 4k tokens / prompt. You could sumarize previous answers and add this to the prompt.

With GPT3 you will always be limited to 4k tokens / prompt. You could sumarize previous answers and add this to the prompt.

@ezzcodeezzlife  Thanks.  In my bussness there are lot of information and the api need to memorize that informations.  In this case the 4k tokens are too small for ur bussess is there any way to obtain more tokens? I can pay for that, I search in the openAi doc there is no way to pay for obtain more tokens.

Same requirements and pain points on my side.
And I also can not give it 4k tokens, it will fail if I give it more than 2k tokens.
#52

do you find way to remember something ?

I had the same problem

I fixed this problem by sending the context with the message, so I could send the context with the prompt, The sample can refer to https://platform.openai.com/examples/default-chat.
But I still have a question. What do openai's interfaces do when max_tokens is exceeded

I solved this problem. Chatgpt sends the context record together with the message. So you can send the context information together with the prompt. For an example, please refer to https://platform.openai.com/examples/default-chat. But I still have a problem, how to deal with the interface of openai when max_tokens is exceeded

Simply put, it is to send all the records of the current session together

For anyone interested on this problem, I just published a NPM library to solve this: https://www.npmjs.com/package/gpt3_plus

Some tips for how to accomplish this are available in this thread: https://github.com/openai/openai-node/issues/149
We may add convenience methods to help with this in the future.


ImportError: cannot import name 'patterns'

I now get this error when I updated my packages. It appears Django 1.10 removed patterns.
File "/home/adam/env/updated_packages_env/lib/python3.5/site-packages/djangocms_youtube/cms_plugins.py", line 88, in get_plugin_urls
from django.conf.urls import patterns, url
ImportError: cannot import name 'patterns'`

So I got all fired up to fix the issue and it was already fixed in the last PR merged. Would you kindly update the pip package and version?

i have this error too

I have the same problem.

I just haven't got round to fixing this. Sorry!


RuntimeError: Not compiled with GPU support

I get this error when running testcuda.py on Linux server.
I test torch.cuda.available() and get True.
My cuda version: 10.1
My torch version: 1.4
My python version: 3.6.9
It seems built successfully:
copying build/lib.linux-x86_64-3.6/_ext.cpython-36m-x86_64-linux-gnu.so ->
▽
#!/bin/bash
Creating /NAS/home01/tanzhenwei/.pyenv/versions/3.6.9/envs/tzwpy/lib/python3.6/site-packages/DCNv2.egg-link (link to .)
DCNv2 0.1 is already the active version in easy-install.pth
▽
Installed /NAS/project01/rzimmerm_substitles/FairMot_compressing/src/lib/models/networks/DCNv2_new
Processing dependencies for DCNv2==0.1
Finished processing dependencies for DCNv2==0.1
But get error when testing
True /usr/local/cuda
Traceback (most recent call last):
File "/NAS/project01/rzimmerm_substitles/FairMot_compressing/src/lib/models/networks/DCNv2_new/testcuda.py", line 255, in
example_dconv()
File "/NAS/project01/rzimmerm_substitles/FairMot_compressing/src/lib/models/networks/DCNv2_new/testcuda.py", line 175, in example_dconv
output = dcn(input)
File "/NAS/home01/tanzhenwei/.pyenv/versions/tzwpy/lib/python3.6/site-packages/torch/nn/modules/module.py", line 532, in call
result = self.forward(*input, **kwargs)
File "/NAS/project01/rzimmerm_substitles/FairMot_compressing/src/lib/models/networks/DCNv2_new/dcn_v2.py", line 128, in forward
self.deformable_groups)
File "/NAS/project01/rzimmerm_substitles/FairMot_compressing/src/lib/models/networks/DCNv2_new/dcn_v2.py", line 31, in forward
ctx.deformable_groups)
RuntimeError: Not compiled with GPU support (dcn_v2_forward at /NAS/project01/rzimmerm_substitles/FairMot_compressing/src/lib/models/networks/DCNv2_new/src/dcn_v2.h:35)
frame #0: c10::Error::Error(c10::SourceLocation, std::string const&) + 0x33 (0x7f5f96ec4193 in /NAS/home01/tanzhenwei/.pyenv/versions/tzwpy/lib/python3.6/site-packages/torch/lib/libc10.so)
frame #1: dcn_v2_forward(at::Tensor const&, at::Tensor const&, at::Tensor const&, at::Tensor const&, at::Tensor const&, int, int, int, int, int, int, int, int, int) + 0x157 (0x7f5f91a755d7 in /NAS/project01/rzimmerm_substitles/FairMot_compressing/src/lib/models/networks/DCNv2_new/_ext.cpython-36m-x86_64-linux-gnu.so)
frame #2:  + 0x17504 (0x7f5f91a82504 in /NAS/project01/rzimmerm_substitles/FairMot_compressing/src/lib/models/networks/DCNv2_new/_ext.cpython-36m-x86_64-linux-gnu.so)
...
Could you help me solve this or give some ideas?

I have the same problem. Did anyone fix it?

Were you able to solve this issue? I am facing the same problem with pytorch 1.4.0-py3.6_cuda101_cudnn7_0 and torchvision 0.5.0-py36_cu101. It is invoked by _backend.dcn_v2_forward where _backend should be _ext built from make.sh. I'm not sure if _ext refers to this _ext.cp36-win_amd64.pyd file. Not sure how to proceed from here.

@wenjiey2 @SharifElfouly Hi, I have fixed it. The situation for me is that I was using a virtual env and try to run it in the computing node by submitting a task to the server. But I install the env when using nodes without GPU and get this error.
Therefore, I solved it by installing everything, including the virtual env, in the node with GPU and it works.

@XiaoSanGit ..thank-you can you please explain in detail how to solve this issue?

I resolved this issue by forcing script go through https://github.com/CharlesShang/DCNv2/blob/c7f778f28b84c66d3af2bf16f19148a07051dac1/setup.py#L34-L42

After some research, I understood that the problem was that I actually did not have CUDA installed.
You can find it out by doing: nvcc –V
If nothing is returned it means that you did not install CUDA
I followed all this:
https://docs.nvidia.com/cuda/cuda-installation-guide-linux/
And I installed CUDA with the following official link
https://developer.nvidia.com/cuda-downloads?target_os=Linux&target_arch=x86_64&Distribution=Ubuntu&target_version=20.04&target_type=deb_local
After what's explained above, I did installed the nvidia-development-kit simply with
sudo apt install nvidia-cuda-toolkit
Then you can do:
export CUDA_HOME=/usr/local/cuda-11
(before doing it you should check that this is the folder in which CUDA has been installed on your machine)
I hope this helps someone else in the same situation.

I am in something deeper, can you help?
$ nvcc -V
Command 'nvcc' not found, but can be installed with:
sudo apt install nvidia-cuda-toolkit

$ conda activate compvis36
$ nvcc -V
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2021 NVIDIA Corporation
Built on Sun_Aug_15_21:14:11_PDT_2021
Cuda compilation tools, release 11.4, V11.4.120
Build cuda_11.4.r11.4/compiler.30300941_0

With/without the environment active when I type in
$ sudo apt install nvidia-cuda-toolkit
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 nvidia-cuda-toolkit : Depends: nvidia-cuda-dev (= 10.1.243-3) but it is not going to be installed
                       Recommends: nsight-compute (= 10.1.243-3)
                       Recommends: nsight-systems (= 10.1.243-3)
E: Unable to correct problems, you have held broken packages.

Any tips on how can I get the nvidia-cuda-toolkit for version 11.4.? Those listed on https://packages.ubuntu.com/search?keywords=nvidia-cuda-toolkit are of lower version.

I fixed this by reinstalling cuda 11.4 using run file from nvidia. but now I am facing different issues which are reported on the repo. Like import error for _ext. Switching to different issue threads now.

For orthers coming later, remember to set CUDA_HOME environment variable.
export CUDA_HOME=/path/to/your/cuda/

ould check that this is the folder in which CUDA has been installed on your machine)

I did following this  and  it works, thanks

I resolved this issue by forcing python setup.py build develop go through
https://github.com/CharlesShang/DCNv2/blob/c7f778f28b84c66d3af2bf16f19148a07051dac1/setup.py#L34-L42

I works for me. thanks


Send a more accurate count of requests/minute

stot corresponds to the cummulative connections which is different than
the number of HTTP requests (e.g. HTTP keep alives). We now send the
requests/s * 60 to get an accuarte RPM.
Closes #48

+1

+1


2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add scene.good_morning as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add scene.good_night as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add scene.goodbye as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add scene.i_m_back as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add scene.open_garage_door as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add scene.turn_on_modem_if_off as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add scene.watch_tv as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add climate.dont_use_my_flair_hvac_kitchen as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add climate.my_flair_hvac_kitchen as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add climate.my_flair_hvac_living_room as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add cover.garage_door_opener as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add cover.garage_door_opener_2 as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add light.spectrum_modem as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add remote.harmony_hub as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add select.harmony_hub_activities as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.2nd_floor_east_room_temperature as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.3rd_floor_room_temperature as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.2nd_floor_west_room_temperature as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.3rd_floor_energy_current as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.2nd_floor_east_humidity as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.3rd_floor_humidity as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.2nd_floor_west_humidity as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add climate.2nd_floor_east as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add climate.3rd_floor as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add climate.2nd_floor_west as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add switch.sonoff_100139390d as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.sonoff_100139390d_temperature as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.sonoff_100139390d_rssi as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.shop_123_1min as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.blue_house_123_1min as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.white_house_123_1min as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.green_559f0_123_1min as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.371_2nd_fl_123_1min as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.371_1st_fl_123_1min as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.purple_house_123_1min as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.well_bkup_ht_123_1min as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.629_123_1min as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.well_pump_a_1_1min as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.breaker_5_3_1min as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.well_pump_b_6_1min as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.breaker_3_8_1min as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.629_balance_1min as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.well_house_123_1min as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.shop_123_1mon as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.blue_house_123_1mon as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.white_house_123_1mon as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.green_559f0_123_1mon as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.371_2nd_fl_123_1mon as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.371_1st_fl_123_1mon as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.purple_house_123_1mon as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.well_bkup_ht_123_1mon as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.629_123_1mon as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.well_pump_a_1_1mon as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.breaker_5_3_1mon as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.well_pump_b_6_1mon as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.breaker_3_8_1mon as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.629_balance_1mon as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.well_house_123_1mon as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.shop_123_1d as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.blue_house_123_1d as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.white_house_123_1d as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.green_559f0_123_1d as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.371_2nd_fl_123_1d as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.371_1st_fl_123_1d as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.purple_house_123_1d as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.well_bkup_ht_123_1d as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.629_123_1d as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.well_pump_a_1_1d as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.breaker_5_3_1d as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.well_pump_b_6_1d as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.breaker_3_8_1d as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.629_balance_1d as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.well_house_123_1d as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add switch.switch_well_bkup_ht as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.flair_puck_lr_41a1 as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.flair_puck_kitchen_3ba8 as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.flair_puck_lr_41a1_light_level as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.flair_puck_kitchen_3ba8_light_level as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.flair_structure_blue as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add climate.flair_room_living_room as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add climate.flair_room_kitchen as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add binary_sensor.large_bedroom_motion as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.large_bedroom_temperature_measurement as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add climate.shop_2 as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add climate.well_ecobee_2 as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.371_2nd_floor_ecobee_smartsensor_3_temperature_measurement_2 as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add binary_sensor.371_2nd_floor_ecobee_smartsensor_3_motion_2 as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add device_tracker.jrs_iphone as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add sensor.jrs_iphone_battery_state as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 WARNING (MainThread) [homeassistant.components.homekit] Cannot add binary_sensor.blueiris_alerts as this would exceed the 150 device limit. Consider using the filter option
2022-01-26 12:45:47 INFO (MainThread) [pyhap.accessory_driver] Starting accessory HASS Bridge on address <IP_ADDRESS>, port 21064.
2022-01-26 12:45:49 INFO (MainThread) [pyhap.hap_protocol] ('<IP_ADDRESS>', 54892): Connection made to HASS Bridge
2022-01-26 12:45:49 INFO (MainThread) [pyhap.hap_protocol] ('<IP_ADDRESS>', 54893): Connection made to Harmony Hub
2022-01-26 12:45:49 INFO (MainThread) [custom_components.hacs] Stage changed: HacsStage.RUNNING
2022-01-26 12:46:11 INFO (MainThread) [custom_components.blueiris.api.blue_iris_api] Updating data from BI Server (BlueIris)
2022-01-26 12:46:11 INFO (MainThread) [custom_components.blueiris.managers.entity_manager] Entity BlueIris Alerts restored | binary_sensor.blueiris_alerts
2022-01-26 12:46:11 ERROR (MainThread) [homeassistant.components.binary_sensor] Platform blueiris does not generate unique IDs. ID blueiris-binary_sensor-MAIN-BlueIris Alerts is already used by binary_sensor.blueiris_alerts - ignoring binary_sensor.blueiris_alerts
2022-01-26 12:46:14 WARNING (SyncWorker_4) [urllib3.connectionpool] Connection pool is full, discarding connection: aic-service.lgthinq.com. Connection pool size: 1
2022-01-26 12:46:14 WARNING (SyncWorker_8) [urllib3.connectionpool] Connection pool is full, discarding connection: aic-service.lgthinq.com. Connection pool size: 1
2022-01-26 12:46:17 INFO (SyncWorker_0) [custom_components.flair.sensor] Refreshing device state
2022-01-26 12:46:17 INFO (SyncWorker_3) [custom_components.flair.sensor] Refreshing device state
2022-01-26 12:46:18 INFO (SyncWorker_1) [custom_components.flair.sensor] Refreshing device state
2022-01-26 12:46:18 INFO (SyncWorker_7) [custom_components.flair.sensor] Refreshing device state
2022-01-26 12:46:19 INFO (SyncWorker_8) [custom_components.flair.sensor] Refreshing puck state
2022-01-26 12:46:41 INFO (MainThread) [custom_components.blueiris.api.blue_iris_api] Updating data from BI Server (BlueIris)
2022-01-26 12:46:44 WARNING (SyncWorker_8) [urllib3.connectionpool] Connection pool is full, discarding connection: aic-service.lgthinq.com. Connection pool size: 1
2022-01-26 12:46:44 WARNING (SyncWorker_5) [urllib3.connectionpool] Connection pool is full, discarding connection: aic-service.lgthinq.com. Connection pool size: 1
2022-01-26 12:46:45 INFO (MainThread) [custom_components.emporia_vue] Integrating minute data into day sensors
2022-01-26 12:46:47 INFO (SyncWorker_2) [custom_components.flair.climate] Refreshing room state
2022-01-26 12:46:47 INFO (SyncWorker_4) [custom_components.flair.sensor] Refreshing device state
2022-01-26 12:46:47 INFO (SyncWorker_6) [custom_components.flair.sensor] Refreshing device state
2022-01-26 12:46:47 INFO (SyncWorker_8) [custom_components.flair.climate] Refreshing room state
2022-01-26 12:46:48 INFO (SyncWorker_3) [custom_components.flair.sensor] Refreshing device state
2022-01-26 12:46:48 INFO (SyncWorker_1) [custom_components.flair.sensor] Refreshing device state
2022-01-26 12:46:49 INFO (SyncWorker_7) [custom_components.flair.sensor] Refreshing puck state
2022-01-26 12:47:11 INFO (MainThread) [custom_components.blueiris.api.blue_iris_api] Updating data from BI Server (BlueIris)
2022-01-26 12:47:14 WARNING (SyncWorker_8) [urllib3.connectionpool] Connection pool is full, discarding connection: aic-service.lgthinq.com. Connection pool size: 1
2022-01-26 12:47:14 WARNING (SyncWorker_1) [urllib3.connectionpool] Connection pool is full, discarding connection: aic-service.lgthinq.com. Connection pool size: 1
2022-01-26 12:47:17 INFO (SyncWorker_7) [custom_components.flair.sensor] Refreshing device state
2022-01-26 12:47:17 INFO (SyncWorker_6) [custom_components.flair.sensor] Refreshing device state
2022-01-26 12:47:18 INFO (SyncWorker_0) [custom_components.flair.sensor] Refreshing device state
2022-01-26 12:47:18 INFO (SyncWorker_4) [custom_components.flair.sensor] Refreshing device state
2022-01-26 12:47:19 INFO (SyncWorker_1) [custom_components.flair.sensor] Refreshing puck state

Please attach the file instead of posting the content or this thread become unreadable!!

Thank you.
Attached
HA log 1-26-2022 13-19.txt
.

Unfortunately with only JSON info I'm not able to determinate if your models support or not power usage sensor.
I suspect that multi-split system does not, but you should enable debug for integration and provide me the log with debug so that I can analyze the devices payload.
It is also quite strange the log message about the connection pool full. Connection pool should be greater than 1, but I see that you have a lot of custom integration, may be one of this is doing "bad thing" resizing the connection pool. You should try to temporary disable some of them to see what happen.

Debug log attached.
Thank you so much for all your help!
I don't know how, but I will research and try to temporarily disable some integrations.
HA Log debug 1-27-2022.txt

I disabled most of the integrations, as shown below:

Still have the pool limit error:

Can you give details about your environment (hw, OS, versions, etc.)?

Of course. Does the attached provide enough info?
HA Info 1-27-2022.txt

Related to the energy, that information is available only on the payload from your 3rd floor device, so I cannot do nothing:
3rd floor:
2022-01-27 06:07:55 DEBUG (SyncWorker_3) [custom_components.smartthinq_sensors.wideq.core_v2] thinq2_get after: {'resultCode': '0000', 'result': {'appType': 'NUTS', 'modelCountryCode': 'WW', 'countryCode': 'US', 'modelName': 'DUCT_626301_WW', 'deviceType': 401, 'deviceCode': 'AI04', 'alias': '3rd floor', 'deviceId': '8bc54a05-3019-1899-b4c0-402f869e47ae', 'fwVer': '', 'imageFileName': 'home_sac_img.png', 'ssid': 'SpectrumSetup-77', 'softapId': '', 'softapPass': '', 'macAddress': '', 'networkType': '02', 'timezoneCode': 'America/New_York', 'timezoneCodeAlias': 'USA/New_York', 'utcOffset': -5, 'utcOffsetDisplay': '-05:00', 'dstOffset': -4, 'dstOffsetDisplay': '-04:00', 'curOffset': -5, 'curOffsetDisplay': '-05:00', 'sdsGuide': '{"deviceCode":"AI04"}', 'newRegYn': 'N', 'remoteControlType': 'REMO_DUCT_WIRED_CRC', 'userNo': 'US2112316000895', 'tftYn': 'N', 'deviceState': 'E', 'snapshot': {'airState.windStrength': 6.0, 'airState.tempState.limitMin': 32.0, 'airState.tempState.unit': 0.0, 'airState.diagCode': 0.0, 'airState.ductZone.state': 0.0, 'mid': 230820025.0, 'airState.energy.onCurrent': 39.0, 'airState.wMode.airClean': 0.0, 'airState.quality.sensorMon': 0.0, 'airState.tempState.target': 21.0, 'airState.humidity.current': 0.0, 'airState.operation': 1.0, 'airState.wDir.swirl': 0.0, 'airState.wDir.vStep': 0.0, 'timestamp':<PHONE_NUMBER>226.0, 'airState.powerSave.basic': 0.0, 'airState.wDir.upDown': 0.0, 'airState.quality.PM10': 0.0, 'airState.powerSave.hum': 0.0, 'static': {'deviceType': '401', 'countryCode': 'US'}, 'airState.tempState.hotWaterCurrent': 0.0, 'airState.tempState.current': 22.0, 'airState.miscFuncState.extraOp': 0.0, 'airState.wDir.leftRight': 0.0, 'airState.miscFuncState.dRED': 0.0, 'airState.tempState.limitMax': 60.0, 'airState.reservation.sleepTime': 0.0, 'airState.miscFuncState.autoDry': 0.0, 'meta': {'allDeviceInfoUpdate': False, 'messageId': 'SrlmdtwvRG2T8gkqtI51-g'}, 'airState.quality.PM1': 0.0, 'airState.quality.PM2': 0.0, 'online': True, 'airState.opMode': 4.0, 'airState.filterMngStates.maxTime': 2400.0, 'airState.filterMngStates.useTime': 2067.0, 'airState.tempState.twoSetState': 0.0}, 'online': True, 'platformType': 'thinq2', 'area': 334505, 'regDt':<PHONE_NUMBER>1407.0, 'blackboxYn': 'Y', 'modelProtocol': 'STANDARD', 'receipeVersion': 0, 'activeSaving': 'OFF', 'smartCareV2': 'OFF', 'order': 0, 'nlpAlias': 'none', 'drServiceYn': 'N', 'regDtUtc': '20220109171407', 'regIndex': 0, 'groupableYn': 'Y', 'controllableYn': 'Y', 'combinedProductYn': 'N', 'masterYn': 'Y', 'initDevice': False, 'firebaseLogKey': 'P:SD', 'upgradableYn': 'N', 'autoFwDownloadYn': 'N', 'tclcount': 0}}

2nd floor East:
2022-01-27 06:07:54 DEBUG (SyncWorker_2) [custom_components.smartthinq_sensors.wideq.core_v2] thinq2_get after: {'resultCode': '0000', 'result': {'appType': 'NUTS', 'modelCountryCode': 'WW', 'countryCode': 'US', 'modelName': 'DUCT_626301_WW', 'deviceType': 401, 'deviceCode': 'AI04', 'alias': '2nd floor East', 'deviceId': '832dd45c-44c5-1643-aae1-402f86603b34', 'fwVer': '', 'imageFileName': 'home_sac_img.png', 'ssid': 'SpectrumSetup-77', 'softapId': '', 'softapPass': '', 'macAddress': '', 'networkType': '02', 'timezoneCode': 'America/New_York', 'timezoneCodeAlias': 'USA/New_York', 'utcOffset': -5, 'utcOffsetDisplay': '-05:00', 'dstOffset': -4, 'dstOffsetDisplay': '-04:00', 'curOffset': -5, 'curOffsetDisplay': '-05:00', 'sdsGuide': '{"deviceCode":"AI04"}', 'newRegYn': 'N', 'remoteControlType': 'REMO_DUCT_WIRED_CRC', 'userNo': 'US2112316000895', 'tftYn': 'N', 'deviceState': 'E', 'snapshot': {'airState.windStrength': 6.0, 'airState.tempState.limitMin': 32.0, 'airState.tempState.unit': 0.0, 'airState.diagCode': 0.0, 'airState.ductZone.state': 0.0, 'mid': 228061727.0, 'airState.wMode.airClean': 0.0, 'airState.quality.sensorMon': 0.0, 'airState.tempState.target': 21.0, 'airState.humidity.current': 50.0, 'airState.operation': 1.0, 'airState.wDir.swirl': 0.0, 'airState.wDir.vStep': 0.0, 'timestamp':<PHONE_NUMBER>649.0, 'airState.powerSave.basic': 0.0, 'airState.wDir.upDown': 0.0, 'airState.quality.PM10': 0.0, 'airState.powerSave.hum': 0.0, 'static': {'deviceType': '401', 'countryCode': 'US'}, 'airState.tempState.hotWaterCurrent': 0.0, 'airState.tempState.current': 19.0, 'airState.miscFuncState.extraOp': 0.0, 'airState.wDir.leftRight': 0.0, 'airState.miscFuncState.dRED': 0.0, 'airState.tempState.limitMax': 60.0, 'airState.reservation.sleepTime': 0.0, 'airState.miscFuncState.autoDry': 0.0, 'meta': {'allDeviceInfoUpdate': False, 'messageId': 'sjF610QDTqSZZ8Y6dy8yhQ'}, 'airState.quality.PM1': 0.0, 'airState.quality.PM2': 0.0, 'online': True, 'airState.opMode': 4.0, 'airState.filterMngStates.maxTime': 2400.0, 'airState.filterMngStates.useTime': 2172.0, 'airState.tempState.twoSetState': 0.0}, 'online': True, 'platformType': 'thinq2', 'area': 334505, 'regDt':<PHONE_NUMBER>0823.0, 'blackboxYn': 'Y', 'modelProtocol': 'STANDARD', 'receipeVersion': 0, 'activeSaving': 'OFF', 'smartCareV2': 'OFF', 'order': 0, 'nlpAlias': 'none', 'drServiceYn': 'N', 'regDtUtc': '20220109170823', 'regIndex': 0, 'groupableYn': 'Y', 'controllableYn': 'Y', 'combinedProductYn': 'N', 'masterYn': 'Y', 'initDevice': False, 'firebaseLogKey': 'P:SD', 'upgradableYn': 'N', 'autoFwDownloadYn': 'N', 'tclcount': 0}}

2nd floor West:
2022-01-27 06:07:55 DEBUG (SyncWorker_8) [custom_components.smartthinq_sensors.wideq.core_v2] thinq2_get after: {'resultCode': '0000', 'result': {'appType': 'NUTS', 'modelCountryCode': 'WW', 'countryCode': 'US', 'modelName': 'DUCT_626301_WW', 'deviceType': 401, 'deviceCode': 'AI04', 'alias': '2nd floor west', 'deviceId': 'ba1da520-c0dc-132f-9878-402f869e4742', 'fwVer': '', 'imageFileName': 'home_sac_img.png', 'ssid': 'SpectrumSetup-77', 'softapId': '', 'softapPass': '', 'macAddress': '', 'networkType': '02', 'timezoneCode': 'America/New_York', 'timezoneCodeAlias': 'USA/New_York', 'utcOffset': -5, 'utcOffsetDisplay': '-05:00', 'dstOffset': -4, 'dstOffsetDisplay': '-04:00', 'curOffset': -5, 'curOffsetDisplay': '-05:00', 'sdsGuide': '{"deviceCode":"AI04"}', 'newRegYn': 'N', 'remoteControlType': 'REMO_DUCT_WIRED_CRC', 'userNo': 'US2112316000895', 'tftYn': 'N', 'deviceState': 'E', 'snapshot': {'airState.windStrength': 6.0, 'airState.tempState.limitMin': 32.0, 'airState.tempState.unit': 0.0, 'airState.diagCode': 0.0, 'airState.ductZone.state': 0.0, 'mid': 228364990.0, 'airState.wMode.airClean': 0.0, 'airState.quality.sensorMon': 0.0, 'airState.tempState.target': 20.5, 'airState.humidity.current': 0.0, 'airState.operation': 1.0, 'airState.wDir.swirl': 0.0, 'airState.wDir.vStep': 0.0, 'timestamp':<PHONE_NUMBER>420.0, 'airState.powerSave.basic': 0.0, 'airState.wDir.upDown': 0.0, 'airState.quality.PM10': 0.0, 'airState.powerSave.hum': 0.0, 'static': {'deviceType': '401', 'countryCode': 'US'}, 'airState.tempState.hotWaterCurrent': 0.0, 'airState.tempState.current': 22.0, 'airState.miscFuncState.extraOp': 0.0, 'airState.wDir.leftRight': 0.0, 'airState.miscFuncState.dRED': 0.0, 'airState.tempState.limitMax': 60.0, 'airState.reservation.sleepTime': 0.0, 'airState.miscFuncState.autoDry': 0.0, 'meta': {'allDeviceInfoUpdate': False, 'messageId': 'XJKSi0kgTyOCmtpgaUlmGg'}, 'airState.quality.PM1': 0.0, 'airState.quality.PM2': 0.0, 'online': True, 'airState.opMode': 4.0, 'airState.filterMngStates.maxTime': 2400.0, 'airState.filterMngStates.useTime': 1635.0, 'airState.tempState.twoSetState': 0.0}, 'online': True, 'platformType': 'thinq2', 'area': 334505, 'regDt':<PHONE_NUMBER>1133.0, 'blackboxYn': 'Y', 'modelProtocol': 'STANDARD', 'receipeVersion': 0, 'activeSaving': 'OFF', 'smartCareV2': 'OFF', 'order': 0, 'nlpAlias': 'none', 'drServiceYn': 'N', 'regDtUtc': '20220109171133', 'regIndex': 0, 'groupableYn': 'Y', 'controllableYn': 'Y', 'combinedProductYn': 'N', 'masterYn': 'Y', 'initDevice': False, 'firebaseLogKey': 'P:SD', 'upgradableYn': 'N', 'autoFwDownloadYn': 'N', 'tclcount': 0}}

I think that multi-split device do not provide this info in the payload, probably because energy cannot be calculated for single split.
Related to the warning, first af all keep in mind that this is not a problems, just means that the connection is not keep in the cache.
I do not understand why your pool size is limited to 1 because default value is 10 and I do not change this value at all. The only possible reason is that in some place the constant DEFAULT_POOLSIZE is overwritten, but I have no idea on who could do this. It is also true that in this case just disable others integrations probably is not enough, because code is loaded in memory in any case. If possible you should do a test on a clean environment to see if problem occurs without others integrations, and than add others at step to identify who could generate the problems.

Thank you very much -- that explains it.
Disappointing that I cannot get either the running state or the energy consumption via LG's API.
Wouldn't know where to start looking for DEFAULT_POOLSIZE, so I'll just ignore it.
Thank you again very much for your help -- and for the great integration.

Fine.👍 I close this issue.


Patch vulnerabilities

Patch vulnerabilities found by Snyk.

@Sayyare
This is ready for testing 👩🔬
-----------------------------
| Platform     | Web        |
| Version      | 0.2.21     |
| Commit | f5f76d9 |
| Environment  | Test       |
-----------------------------

Tested Fly Web App in test environment, working good as expected. 🐱👤
The user is able to share/add other user to the existing process, and both user are able to update and see the updated contents. Deep link, feedback and other features are working good as well. @dansvend
Moving the task to QA.

Thank you so much for testing 🙏 Good job, @Sayyare 💪
This has been built to QA and is ready for testing 👩🔬
-----------------------------
| Platform     | Web        |
| Version      | 0.2.21     |
| Commit       | f5f76d9    |
| Environment  | QA       |
-----------------------------

Thanks for testing @Sayyare 🙏
We're ready to deploy upgrade from ADAL to MSAL for the authentication on the API and a security patch to the frontend.
Our tester, @Sayyare , have tested the changes in both test and QA environments and it's working as expected, but it never hurts having more eyes on it. Would you like to do some testing in the QA environment as well @askbulle and @knudsvik before we release? 🚀

LGTM (not too sure what I am looking for, but the app behaviour is as expected) :)

Thanks for testing @knudsvik 👌
New authentication method have been implemented in the API in addition to packages being upgraded to newer versions to patch vulnerabilities.
If everything seems to work as expected we can release this to production after coordinating this with @anheri so that we can deploy both the API and frontend. This will mean there will be some downtime when we release.

This has been released to production in 0.2.22 the 11th January 2022🚀 I'm moving it to ✅ Done.


Data Factory Integration test

This introduce a new Vagrant VM with the required definition to run both
the DF as well as the Query Engine at the same time, both managed
through Marathon.
At this point the functionality of the DF pipelines has not been tested in this context, but Airflow is running and presenting the following:

The label in red point to:

This change is

 thanks for adding this integration test

Reviewed 11 of 11 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Detecting Tiny Faces

Hi,
How should I change the architecture of network to make it robust to hard cases (small faces). In my scenario faces are mostly tiny.
I reduced param_bbox_small_list and param_bbox_large_list and retrained the network but I'm getting no detections at all.

Could you please elaborate a bit more, for instance, what are the shapes of hard case faces in your dataset(just the bounding boxes), and what are the different param_bbox_list values you have tried?
Did you try changing feature_map_size list?
Input shape of your image and if possible share your configuration file so that I can try to help you.

Most of the faces in my dataset are no larger than (30,30)... the quality of the image itself is not good too so lot of hard cases.
I tried changing param_bbox_small_list = [10, 20, 40, 80, 160] to param_bbox_small_list = [10, 20, 30, 40, 50]
and the upper bound from param_bbox_large_list = [20, 40, 80, 160, 320] to param_bbox_large_list = [20, 30, 40, 50, 60]
input shape of my image is either 360x360 or 320240 or 240320.
I didn't change any other thing.
and I don't want to train it on my dataset. I just want to train it on WIDERFACE in a way which can get more robust to tiny faces.

What I detect is the face in the picture of about 100*200,and most of the faces in my dataset are  no larger than (30,30).Did you find a good solution in the end, or use other model training?


Reduce unneeded Docker image builds

Currently every push to a branch, every pull request build, every merge to master and every git tag results in the Linux build on travis making a new Docker image. That is a challenge because DockerHub is now rate-limiting the number of images it builds; this cause apparent build failures on intense days. Also unneeded images rapidly build up.
The travis instructions are in the .travis.yml at the top level.
It might be that we should not build branches Docker images at all unless the $TRAVIS_COMMIT_MESSAGE has CreateDocker in it.
We should also probably stop creating pull request Docker images if the $TRAVIS_COMMIT_MESSAGE has NoDocker in it.

This has been resolved. Docker images are now being built on demand with a script bdock, and not in travis after #1853


better auto generation of summaries

Handles partial urls, youtube videos, learn more, buy, etc...

What about when when both youTubeId and imageUrl are defined, we get:

Right.... that's a rendering bug. Will fix.

https://github.com/Microsoft/pxt/pull/5272


transfer GraphNeuralNetworks.jl to JuliaGraphs org

updating the repo after the transfer
https://github.com/JuliaGraphs/GraphNeuralNetworks.jl

@goerz could you merge this PR along with  #120436 and #120431 ?

I don't have merge permissions. You'll have to find a registry maintainer on Slack.

For old versions to remain installable, the history needs to contain all the old versions of the code. Please run this code to verify the old versions are present: https://github.com/JuliaRegistries/General/blob/master/CONTRIBUTING.md#appendix-checking-if-a-repository-contains-all-registered-versions-of-a-package

Thanks @ericphanson. I run the linked code and it seems to be fine for all the 3 packages I transferred:
julia> check_package_versions("GraphNeuralNetworks", "https://github.com/JuliaGraphs/GraphNeuralNetworks.jl.git");
Cloning into '/tmp/jl_vtb4pS'...
remote: Enumerating objects: 30296, done.
remote: Counting objects: 100% (6593/6593), done.
remote: Compressing objects: 100% (1701/1701), done.
remote: Total 30296 (delta 3130), reused 6239 (delta 2906), pack-reused 23703 (from 1)
Receiving objects: 100% (30296/30296), 47.65 MiB | 15.48 MiB/s, done.
Resolving deltas: 100% (15865/15865), done.
GraphNeuralNetworks: v0.1.0 found
GraphNeuralNetworks: v0.1.1 found
GraphNeuralNetworks: v0.1.2 found
GraphNeuralNetworks: v0.2.0 found
GraphNeuralNetworks: v0.2.1 found
GraphNeuralNetworks: v0.2.2 found
GraphNeuralNetworks: v0.2.3 found
GraphNeuralNetworks: v0.3.0 found
GraphNeuralNetworks: v0.3.1 found
GraphNeuralNetworks: v0.3.2 found
GraphNeuralNetworks: v0.3.3 found
GraphNeuralNetworks: v0.3.4 found
GraphNeuralNetworks: v0.3.5 found
GraphNeuralNetworks: v0.3.6 found
GraphNeuralNetworks: v0.3.7 found
GraphNeuralNetworks: v0.3.8 found
GraphNeuralNetworks: v0.3.9 found
GraphNeuralNetworks: v0.3.10 found
GraphNeuralNetworks: v0.3.11 found
GraphNeuralNetworks: v0.3.12 found
GraphNeuralNetworks: v0.3.13 found
GraphNeuralNetworks: v0.3.14 found
GraphNeuralNetworks: v0.3.15 found
GraphNeuralNetworks: v0.4.0 found
GraphNeuralNetworks: v0.4.1 found
GraphNeuralNetworks: v0.4.2 found
GraphNeuralNetworks: v0.4.3 found
GraphNeuralNetworks: v0.4.4 found
GraphNeuralNetworks: v0.4.5 found
GraphNeuralNetworks: v0.5.0 found
GraphNeuralNetworks: v0.5.1 found
GraphNeuralNetworks: v0.5.2 found
GraphNeuralNetworks: v0.6.0 found
GraphNeuralNetworks: v0.6.1 found
GraphNeuralNetworks: v0.6.2 found
GraphNeuralNetworks: v0.6.3 found
GraphNeuralNetworks: v0.6.4 found
GraphNeuralNetworks: v0.6.5 found
GraphNeuralNetworks: v0.6.6 found
GraphNeuralNetworks: v0.6.7 found
GraphNeuralNetworks: v0.6.8 found
GraphNeuralNetworks: v0.6.9 found
GraphNeuralNetworks: v0.6.10 found
GraphNeuralNetworks: v0.6.11 found
GraphNeuralNetworks: v0.6.12 found
GraphNeuralNetworks: v0.6.13 found
GraphNeuralNetworks: v0.6.14 found
GraphNeuralNetworks: v0.6.15 found
GraphNeuralNetworks: v0.6.16 found
GraphNeuralNetworks: v0.6.17 found
GraphNeuralNetworks: v0.6.18 found
GraphNeuralNetworks: v0.6.19 found
GraphNeuralNetworks: v0.6.20 found
GraphNeuralNetworks: v0.6.21 found

julia> check_package_versions("GNNlib", "https://github.com/JuliaGraphs/GraphNeuralNetworks.jl.git");
Cloning into '/tmp/jl_rYE54V'...
remote: Enumerating objects: 30296, done.
remote: Counting objects: 100% (6593/6593), done.
remote: Compressing objects: 100% (1701/1701), done.
remote: Total 30296 (delta 3130), reused 6239 (delta 2906), pack-reused 23703 (from 1)
Receiving objects: 100% (30296/30296), 47.65 MiB | 16.86 MiB/s, done.
Resolving deltas: 100% (15870/15870), done.
GNNlib: v0.1.0 found
GNNlib: v0.2.0 found
GNNlib: v0.2.1 found
GNNlib: v0.2.2 found

julia> check_package_versions("GNNGraphs", "https://github.com/JuliaGraphs/GraphNeuralNetworks.jl.git");
Cloning into '/tmp/jl_yxwsT2'...
remote: Enumerating objects: 30296, done.
remote: Counting objects: 100% (6593/6593), done.
remote: Compressing objects: 100% (1701/1701), done.
remote: Total 30296 (delta 3130), reused 6239 (delta 2906), pack-reused 23703 (from 1)
Receiving objects: 100% (30296/30296), 47.65 MiB | 16.02 MiB/s, done.
Resolving deltas: 100% (15865/15865), done.
GNNGraphs: v0.1.0 found
GNNGraphs: v1.0.0 found
GNNGraphs: v1.0.1 found
GNNGraphs: v1.1.0 found
GNNGraphs: v1.2.0 found
GNNGraphs: v1.2.1 found

Ok, great! All 3 are merged. I wanted to double check since when moving a pkg into a subdir, sometimes the history isn’t transferred properly, but all good here.


Issue #13 🎫: Game class

🚩I have made the following changes to complete Issue #13
Here is a summary of what has been done
Type of files changed/added

In this new Branch, I have ➕ADDED➕ the succeeding *📂 folders and/or **📄 files to complete this ticket's requirements
*📂 root/

*📂 lib/

**📄 game.rb ➕

I have added all the attributes and methods required.

@demesameneshoa  ❗Please consider reading the comments on the game.rb file it would be great to have a second opinion 🙏🏼.

Thank you for taking the time to review this PR ⭐

If you need additional information or have any questions, please don't hesitate to contact me on Slack as Arturo (Arthur) Emanuel Guerra Iturres. I'll be happy to help you out. 🎯

@demesameneshoa Thank you Demes! 🥳


Added spec and fix for Router implicit binding through IoC

If a Model has been bound to another one though $this->app->bind('Model1', 'Model2'), the implicit binding for the old model in the controllers still resolves to the old model rather than the one it's bound to.
This fixes it.

Why do you have an Eloquent model aliased to another model name?

I was building a core Laravel application as a package. This core application is to be used in other applications which should be able to override the features provided by the package.
To allow overriding (extending) the package's Models by the application and use the extended one inside the package, I was using dependency injection and IoC container. It is working everywhere except at implicit model bindings in the controllers.


[BUG] torch==2.0.0 torch.cuda.is_available() return False in latest docker image

after docker pull and python -m get:
Warning: CUDA initialization: Unexpected error from cudaGetDeviceCount(). Did you run some cuda functions before calling NumCudaDevices() that might have already set an error? Error 804: forward compatibility was attempted on non supported HW (function operator())

Thanks for your question! Could provide more details about your hardware, such as driver version.

The default cuda version in docker is CUDA 11.8,  you can try to upgrade your driver.

It looks like a problem with your cuda driver.   You can refer to https://docs.nvidia.com/deploy/cuda-compatibility/#deployment-consideration-forward to install a newer driver. 515 is not a stable version.


Simple example to log URDF models to Rerun

See:

https://docs.ros.org/en/humble/Tutorials/Intermediate/URDF/Building-a-Visual-Robot-Model-with-URDF-from-Scratch.html

Would benefit from: https://github.com/rerun-io/rerun/issues/1361 since these are models that URDF supports.
Should include example of subscribing to the robot-state publisher and use it to update transforms of the linkages.

That feels done?
https://github.com/rerun-io/rerun-loader-python-example-urdf


Add more architectural documentation?

I think you guys have done an excellent job with this software, and the instructions right now are fairly easy to follow if you're the developer type and already know quite a bit about Solo. However for a new user just getting into Solo (or just getting into Open Solo, anyway) I think it would be helpful to have some explanation about what exactly Open Solo is going to change when they install it. Something similar to the "architectural overview" diagram on the old 3DR dev guide, except maybe a little higher level. Just to introduce the users to the concepts of all the different individual devices involved in this, and make sure they understand what they're getting into.
I've got a copy of MS Visio I could use to make some nice looking diagrams, and I understand the general idea of how the Solo's parts fit together, but some more information on the network communication would be very helpful. What ports does the controller use to talk to the Solo? What ports does the app use? If someone can explain that a little for me I will try and put together a couple diagrams this week.
Thanks again for your hard work on this! This is a big step for Solo owners.

If you draw-up some diagrams that will be helpful to the community, we're happy to accept them as  PR to the repo.


Open an Additional Monitor Doesn't Work

Type: Bug Report
Open an Additional Monitor Doesn't Work

OS and Version: Macos 13.5.1
VS Code Version: 1.82.2
Serial Monitor Extension Version: v0.10.0
Target embedded device: ARM-M
Other extensions you installed (and if the issue persists after disabling them): unknown

Repro:

Press "Open an Additional Monitor". Nothing appears to happen.
Press two more times, and this error will show, suggesting instances were loaded, but the GUI is not showing a tab bar.

@orlyprofili Could you please screen record or take a screenshot of your entire VS Code screen when trying to use the "Open an additional monitor" feature?
I've found that it can be very easy to not realize that the new monitor did in fact open. Please let me know and I'll work to help investigate.

here you go.  Open vscode, clicking on "open an additional monitor" 3 times, see error.
https://github.com/microsoft/vscode-serial-monitor/assets/18429800/f6360bf1-1c46-453f-bc59-08f248d84d71

I just tested and this seems to work on  my machine. My guess is that it's opening but in a non-obvious location that maybe you previously put them in?
Either way, and easy way to tell, is to type the following into the command pallete
"View: Focus on Serial Monitor" and the following should come up and you can select which view you want to focus on:

If the three views don't show up in the dropdown, then it is confirmed that you're right, something is wrong.
Looking forward to hearing from you.

thanks! this, and then right-click "reset view" did the trick, and it's persisting after relaunch of vscode

@orlyprofili Great! I'm glad that fixed your issue.


⚠ Mobitopup has degraded performance

In 59876c7, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 3649 ms

Resolved: Mobitopup performance has improved in 3229e94 after 7 minutes.


WRKLDS-1309: Fix some of bundle image preflight check failures

Preflight checks against bundle image includes some errors and this PR fixes some of them. After this PR, bundle image's preflight checks are passing.

/override ci/prow/e2e-aws-operator

/override ci/prow/e2e-aws-operator

/override ci/prow/e2e-aws-operator

/override ci/prow/e2e-aws-operator

/lgtm

/override ci/prow/e2e-aws-operator


Integration test against final artefact through wrangler.

Added an extra CI step to conform example README instruction work by locally deploying the script in wrangler.
I confirmed failing the test also fails the job here https://github.com/tomlarkworthy/cloudworker-proxy/actions/runs/6135617088/job/16649542963?pr=3
fixes https://github.com/markusahlstrand/cloudworker-proxy/issues/129
Now that we have end to end testing against a final artefact we can consider switching to bun build and moving all source code to typescript, and we can test the final JS bundle works after building by using this integration test.
While I was here I switched to bun install over npm install as its much faster, removing the package-lock in preference to the binary bun.lockb. Bun has reached v1! https://bun.sh/blog/bun-v1.0

base branch https://github.com/markusahlstrand/cloudworker-proxy/pull/125

This is really cool! I've been wanting to do this but never got around to it. Looking forward to see how it works in practice.


Only clone to depth 1

Currently we tell the user to clone the entire repository, which is 141Mb, using --depth=1 reduces this to 28Mb.
From git:

Create a shallow clone with a history truncated to the specified number of commits

It also only clones the master branch, so for people adding new things such as presets, do they really need 36 extra branches that will not be used?
cc @bhousel

I like having the deep history but not everyone needs it.. If you want to add a note about this to the README, that's ok.


Penv 213 process jetdrop

- What I did
- How I did it
- How to verify it
- Description for the changelog

Codecov Report

Merging #24 into master will increase coverage by 3.56%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #24      +/-   ##
==========================================
+ Coverage   57.63%   61.19%   +3.56%
==========================================
  Files          28       29       +1
  Lines        1159     1201      +42
==========================================
+ Hits          668      735      +67
+ Misses        424      400      -24
+ Partials       67       66       -1

Impacted Files
Coverage Δ

etl/types/types.go
66.66% <ø> (ø)

etl/processor/processor.go
86.90% <100.00%> (+23.52%)
:arrow_up:

testutils/canonical.go
100.00% <100.00%> (ø)

testutils/generators.go
96.61% <100.00%> (+0.24%)
:arrow_up:

instrumentation/belogger/logger.go
59.18% <0.00%> (+6.12%)
:arrow_up:

etl/models/models.go
100.00% <0.00%> (+100.00%)
:arrow_up:

Continue to review full report at Codecov.

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


New PR to test SignCLA at 2019-04-18 16:21:52.034075315 -0400 EDT m=+4.887568510

Body of PR

unsigned-fail-staging: test succeeded


Fixing inv initdb for python3

A working solution, but you were reinventing the wheel. I suggest to use six.text_type() instead of writing your own function ensureUtf().


fix: Ensure back button updates visualization

Prior to this change, the browser 'back' button would always update the
URL, but the visualization would typically not change if you were going
from one scope URL (/?name=Blah&...) to another.
This PR remedies the situation by watching for route changes in the
Scope view, and reloading the new visualizer and sequence into the
specimen already being viewed. Implementing this tactic requires the
ability to completely change the sequence and visualizer of a specimen,
which previously did not exist.
The change also enables delaying specimen initialization from Vue setup()
time to just before the component is mounted. As a result, the Vue setup
is not asynchronous, so the experimental Vue <Suspense> tag is no longer
needed.
Adds a test that the back button actually took effect, to the existing
test that changes a parameter. (The extended test definitely failed in
ui2 prior to this PR.)
Uses the router to redirect from an empty URL to the last-viewed specimen,
rather than the Scope component; this change avoids reloading that specimen
when the URL is updated to reflect what specimen is being viewed.
Finally, fixes a small previously-existing bug in which the Differences
visualizer could never display more terms than were available in its last
parameter settings, even if you changed the parameters to make more
terms available.
Resolves #414.
Given the large number of internal changes to Specimen.ts, please
in review do play with a veriety of visualizations to make sure all seems
to be working well.

By submitting this PR, I am indicating to the Numberscope maintainers that I have read and understood the contributing guidelines and that this PR follows those guidelines to the best of my knowledge. I have also read the pull request checklist and followed the instructions therein.

You said in the desc: "this change avoids reloading that specimen
when the URL is updated to reflect what specimen is being viewed"
Can you elaborate?  If I'm looking at Thue Trellis and I delete the URL back to the base URL (http://localhost:5173), it does indeed restart the visualizer (the Thue Trellis turtle restarts the path).

Ok there's definitely a performance issue on my machine.  To reproduce, first try this in ui2 and then try it in this PR and see the difference:
(1) go to polyfactors, and scrub the mouse watching the immediate response of the mouseover highlight/info
(2) go to gallery and load vfib
(3) go to gallery and load thue trellis
(4) go to gallery and load wait for it
(5) go to gallery and load beatty dna
(6) return to polyfactors, and scrub the mouse watching the response.  In this PR the response is laggy at this point.
Is it possible that some visualizers are not being destroyed as well as they used to be?  So that the cpu is still trying to deal with all those webgl specimens?

Can you elaborate? If I'm looking at Thue Trellis and I delete the URL back to the base URL (http://localhost:5173), it does indeed restart the visualizer (the Thue Trellis turtle restarts the path).

Yes, I agree. The difference is that in ui2, when you visit the base URL, whatever the current query is gets loaded twice (in quick succession, so the first one may not be noticeable). Now it only happens once, because only one URL ever gets to the scope -- the one with the query filled in.

Is it possible that some visualizers are not being destroyed as well as they used to be? So that the cpu is still trying to deal with all those webgl specimens?

I agree something is up. Will investigate.

@katestange can you verify that the performance hit does not occur if rather than going through the Gallery, you just cut and paste the proper URLs into the address bar in turn?
I am pretty stymied to know what is going on here. Everything seems to be cleaning itself up in the scope. I can't get any draws that shouldn't be happening to console.log(), and if I add a message in the scope cleanup it seems always to be printed. So now I am wondering if it could be the Gallery itself that is causing the performance gap...

Trying to follow up on the idea that maybe the Gallery is the problem, Kate can you check whether if you start from a polyfactors that is responding OK, and then go to the Gallery and hit the back button (i.e., don't do a different scope), click on Gallery again and then do a back button, etc maybe 3 or 4 cycles, are you then seeing a performance hit when you get back to polyfactors after say 4 roundtrips? Thanks for letting me know. Have not had any success in tracking this down yet.

Kate can you check whether if you start from a polyfactors that is responding OK, and then go to the Gallery and hit the back button (i.e., don't do a different scope), click on Gallery again and then do a back button, etc maybe 3 or 4 cycles, are you then seeing a performance hit when you get back to polyfactors after say 4 roundtrips?

Yes, I am definitely seeing a hit when I do this, but I see a similar hit doing this in ui2.

@katestange can you verify that the performance hit does not occur if rather than going through the Gallery, you just cut and paste the proper URLs into the address bar in turn?

Yes, I can verify this.

(1) go to polyfactors, and scrub the mouse watching the immediate response of the mouseover highlight/info
(2) go to gallery and load vfib
(3) go to gallery and load thue trellis
(4) go to gallery and load wait for it
(5) go to gallery and load beatty dna
(6) return to polyfactors, and scrub the mouse watching the response. In this PR the response is laggy at this point.

If I do all this except that I return to polyfactors by loading the URL instead of clicking the gallery icon, I don't have the performance problem.

except that I return to polyfactors by loading the URL instead of clicking the gallery icon, I don't have the performance problem.

Oh that makes it hard to debug because I guess changing the url manually in the url bar must be akin to doing a reload, which of course releases all the phantom visualizers (if indeed that is what's causing the performance issue). I will start by seeing if the Gallery seems to be leaving behind a mess, and if so, clean that up, and then take things from there.

Indeed, the Thumbnails in the Gallery were leaving behind a mess of visualizers, because their canvases were being removed from the DOM before the onUnmounted call was occurring, so the handle the code was using for the visualizer.depart() call was no longer valid at that time. Worked around this by saving a valid handle elsewhere.
And yes, this problem was present in ui2, but all of the reloading that was being triggered every time the specimen changed was masking it.
Correcting that leak of active visualizers fixes all the performance issues for me. You?

Yes!  The performance issues are gone!!  I wonder if this will correct other performance issues elsewhere that we've come across.  Excellent!  I've tested this pretty extensively now, so I'm ready to merge.


cleanup of migration tests

During #1719, the migration command tests broke my test database several times to the point where I had to reset the database. My fault, obviously, but they are written very Ctrl+C/Ctrl+V, and quite fragile. Got frustrated and cleaned them up.

Hmpf, phpstan complains about completely unrelated files. Weird.
Fixed those errors in #1721


GitHub PR Status not updated when rebuilding VSTS build

https://github.com/Microsoft/vsts-tasks/issues/7408
Steps to reproduce:

Create a PR in GitHub
Wait for VSTS build to complete (pass/fail does not matter)
Rebuild the VSTS build (Queue new build..)
The GitHub PR status is not updated with the build status of VSTS (its still
showing as completed).
We have to close the PR and open it up once again.

@d3r3kk cc

This is a shortcoming of VSTS's usage of the Github API/their specific integration, not much we can do about it. I'd like to verify the exact pattern, but I'm positive it isn't working the way TravisCI and AppVeyor integrate with Github today.

I'm going to close this since VSTS needs to update their stuff for this to work and I don't think anyone is going to run across this and wonder what's going on.


[FLINK-5484] [serialization] Revert Chill version update

This PR reverts the Twitter Chill dependency update. The version updates breaks backwards compatability for savepoints which contain user types that were serialized with Kryo, because Chills adds new default serializers that change the class IDs.
In Flink 1.1 the default next available class ID was X and registered user types got IDs assigned starting at X. In Flink 1.2, the newly added serializers in Chill got assigned IDs starting at X before the user types are registered, which can lead to user types trying to be deserialized with the wrong serializer.
I've verified that this with a savepoint (the one that triggered this issue) and furthermore added a test that checks that the default registration map does not change between versions. Once we have proper serializer versioning, that test will become obsolete.
I would like to merge this to: release-1.1, release-1.2, and master.

Good fix and test
+1 to merge this!


Upgrading dwarf-fortress (0.43.01 to 0.43.04) deletes all saved game data

This should not happen. Game data is stored in data/save relative to the game root, which is the package's /libexec. Other packages with data that survive between versions (e.g. python3) manage to symlink folders to common locations, like /usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages to /usr/local/lib/python3.5/site-packages, so that their contents persist between upgrades.
There isn't even a warning or caveat in the dwarf-fortress package that upgrading it can delete all game data.

Sorry you lost data!  If the data directory can be reconfigured, we could put it in pkgshare instead so it persists across upgrades.
Interested in opening a PR?  Take a look at https://github.com/Homebrew/brew/blob/master/share/doc/homebrew/How-To-Open-a-Homebrew-Pull-Request-(and-get-it-merged).md and let us know if you have questions!

Are you sure that your saved game isn't in one of the previous versions? When you perform a brew upgrade <package> it will create a new version folder in /usr/local/Cellar/dwarf-fortress/<version> and it's a pretty simple process to move your saved games between versions (as long as your save is compatible between versions). Are you sure that your saved game data was deleted from the previous version?

@jakofranko Yes it was in the previous version's data/save, but that's the problem. After upgrading a package, it should be safe to immediately run brew cleanup without losing any user data.

Oh I see what you are saying. Hmmm, an interesting problem.

We'll accept a PR for this in homebrew/core where this formula now lives.


feat(gui): Add ref params to homepage links in menu

This adds a ref param to the URLs in the menu,
in order to see where page views are coming from.
Change-Type: patch

Looks like the lint tests are causing the CI builds to fail?
node scripts/html-lint.js
Scanning...
3 errors at lib/gui/app/index.html
  [17:69] An element with the attribute “tabindex” must not appear as a descendant of the “button” element.
  [24:59] An element with the attribute “tabindex” must not appear as a descendant of the “button” element.
  [31:68] An element with the attribute “tabindex” must not appear as a descendant of the “button” element.
Total: 7/8
make: *** [lint-html] Error 1


Do not deploy metrics and tracing Helm charts by default

Feature Request
Proposal
Currently, the metrics and tracing sub-charts are deployed by default on Maesh installation. The purpose of the Helm chart is to install Maesh and to provide the necessary configuration options to be able to use supported metrics and tracing libraries, and not to provide production-ready stacks for metrics and tracing.
Therefore, the metrics and tracing sub-charts must not be deployed by default but should be kept for testing and demonstration purposes.

Prometheus and Grafana each have an operator to configure them.
You can maybe offer the possibility to deployed grafana dashboard and prometheus job as CRD, in case of the user have installed Prometheus and Grafana with operators.


signoutpromise broken (iOS)

I think signout promise never resolves, because you're listening for disconnect events.
If just doing a sign out, the user will only be signed out locally and the disconnect events never raise.
Just calling .signOut doesn't work either, as this is dispatched async on iOS, so the function returns before the user is signed out.
For my own workaround, I've removed the async dispatch in signOut https://github.com/YousefED/react-native-google-sign-in/blob/master/ios/RNGoogleSignIn/RNGoogleSignIn.swift. Not sure this is the correct solution, but seems to be working for our use case now

I've experienced this too. My UI hangs on awating the Promise to resolve. Tapping the button again signs the user out

same problem,
thanks @YousefED for quick-fix

@joonhocho what's your view on this?

@YousefED If you remove async, are you saying it will raise disconnect event and thus resolved?

@joonhocho honestly this is a while ago, I see we also made the following change to resolve this issue: https://github.com/YousefED/react-native-google-sign-in/commit/8227feb237d3aecaa4860038093814fc76fb1db1. Don't remember 100% but looks related :)

@joonhocho the core of the issue is, is that:
await signOutPromise()
never resolves on iOS. the onDisconnect / onDisconnectError handlers are never called.
Do you have a suggested fix?

experiencing the same issue, signOutPromise never resolve (nor reject)

@YousefED @jasonnathan @frozenxis @RalfNieuwenhuizen @calcal12
This issue has been fixed with new version.
Just upgraded to the latest Google SignIn SDK for iOS. (npm version 1.0.16)
Please follow new instructions carefully.
https://github.com/joonhocho/react-native-google-sign-in#ios
Also refer to ExampleApp if something is not working. I've tested ExampleApp and is working fine.
Feel free to reopen this issue if you cannot get it working.

FYI, signout should never call 'disconnect' events. disconnect should raise disconnect events. I fixed it accordingly.


Important box changes to specify Storage Acct types

In trying to configure logging/audit for SQL Server, the account I tried using was of Kind:BlobStorage and this would not work with Audit - this should get called out in the doc - I upgraded to StorageV2 and was able to enable audit.  Adding the Storage Account types this works with would clarify this further  -> Also - I tried to submit a pull request to update the doc and my changes would not save - there was an nginx error so I am logging an issue instead.

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

ID: 0c27fe13-a824-84a5-e314-892a27c1dec5
Version Independent ID: 510b5427-c927-84df-563f-31dfe13fc771
Content: Get started with Azure SQL database auditing
Content Source: articles/sql-database/sql-database-auditing.md
Service: sql-database
GitHub Login: @giladm
Microsoft Alias: giladm

@derekschauland Thanks for your feedback. At a minimum, it appears the screen capture needs to be updated as there is no longer a 'Blob' versus 'Table' storage option:

Only storage v1 and v2 are supported by auditing.
When you create a storage account as part of the auditing policy creation, you are only able to choose a storage account type that is supported.
If you try using a storage account that was not created as part of the audit policy creation, and this account is of an unsupported kind, you are notified by the portal notification system that this account type is unsupported.
As suggested, we will also document this in the upcoming documentation update.

Fixed
#please-close

@giladmit We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.