OHIF study listing hanging: For some reason we could not list the studies

I am having trouble listing the studies that I have in my orthanc db. When I start the viewer, I get the UI, but no studies, just the word Loading and a spinning circle. This issue seems a bit similar to #113, but I don't think that the problem is with the orthanc dicom plugin. Full disclosure:  I am using docker-compose for this effort.  The OHIF docker is version travis-829. I'm using jodogne/orthanc-plugins:latest and mongo:latest as well. Lot's of config/results below: Thanks in advance for any assistance, I'm a little stumped.
Howard
Here's a bit of what I get from the orthanc server when I try it directly:

which looks OK to me.
I've also got an nginx reverse proxy server configured: it looks like this
  location /orthanc/ {
      proxy_pass http://orthanc:8042;
      proxy_set_header HOST $host;
      proxy_set_header X-Real-IP $remote_addr;
      rewrite /orthanc(.*) $1 break;
      add_header 'Access-Control-Allow-Credentials' 'true';
      add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
      add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
      add_header 'Access-Control-Allow-Origin' '*';
   }

Here's what I have in the web console:

Here's my config script (minus the hotkeys for brevity)
window.config = {
  // default: '/'
  routerBasename: '/',
  extensions: [],
  showStudyList: true,
  // default: ''
  relativeWebWorkerScriptsPath: '',
  servers: {
    dicomWeb: [
      {
        name: 'Orthanc',
        wadoUriRoot: '/orthanc/wado',
        qidoRoot: '/orthanc/dicom-web',
        wadoRoot: '/orthanc/dicom-web',
        qidoSupportsIncludeField: false,
        imageRendering: 'wadors',
        thumbnailRendering: 'wadors',
        requestOptions: {
          requestFromBrowser: true,
        },
      },
    ],
  },

Here's the error from the terminal where I start the docker:
viewer      | { Error: request failed
viewer      |     at XMLHttpRequest.request.onreadystatechange (/app/bundle/programs/server/npm/node_modules/meteor/ohif_studies/node_modules/dicomweb-client/build/dicomweb-client.js:391:29)
viewer      |     at XMLHttpRequestEventTarget.dispatchEvent (/app/bundle/programs/server/npm/node_modules/meteor/ohif_studies/node_modules/xhr2/lib/xhr2.js:64:18)
viewer      |     at XMLHttpRequest._setReadyState (/app/bundle/programs/server/npm/node_modules/meteor/ohif_studies/node_modules/xhr2/lib/xhr2.js:354:12)
viewer      |     at XMLHttpRequest._onHttpRequestError (/app/bundle/programs/server/npm/node_modules/meteor/ohif_studies/node_modules/xhr2/lib/xhr2.js:544:12)
viewer      |     at ClientRequest.<anonymous> (/app/bundle/programs/server/npm/node_modules/meteor/ohif_studies/node_modules/xhr2/lib/xhr2.js:414:24)
viewer      |     at emitOne (events.js:116:13)
viewer      |     at ClientRequest.emit (events.js:211:7)
viewer      |     at Socket.socketErrorListener (_http_client.js:387:9)
viewer      |     at emitOne (events.js:116:13)
viewer      |     at Socket.emit (events.js:211:7)
viewer      |     at emitErrorNT (internal/streams/destroy.js:64:8)
viewer      |     at _combinedTickCallback (internal/process/next_tick.js:138:11)
viewer      |     at process._tickDomainCallback (internal/process/next_tick.js:218:9)
viewer      |   request:
viewer      |    XMLHttpRequest {
viewer      |      onloadstart: [Function],
viewer      |      onprogress: null,
viewer      |      onabort: null,
viewer      |      onerror: null,
viewer      |      onload: null,
viewer      |      ontimeout: null,
viewer      |      onloadend: [Function],
viewer      |      _listeners: {},
viewer      |      onreadystatechange: [Function],
viewer      |      _anonymous: undefined,
viewer      |      readyState: 4,
viewer      |      response: null,
viewer      |      responseText: '',
viewer      |      responseType: 'json',
viewer      |      responseURL: '',
viewer      |      status: 0,
viewer      |      statusText: '',
viewer      |      timeout: 0,
viewer      |      upload:
viewer      |       XMLHttpRequestUpload {
viewer      |         onloadstart: null,
viewer      |         onprogress: null,
viewer      |         onabort: null,
viewer      |         onerror: null,
viewer      |         onload: null,
viewer      |         ontimeout: null,
viewer      |         onloadend: null,
viewer      |         _listeners: {},
viewer      |         _request: [Circular],
viewer      |         _contentType: null,
viewer      |         _body: <Buffer > },
viewer      |      _method: 'GET',
viewer      |      _url:
viewer      |       Url {
viewer      |         protocol: 'http:',
viewer      |         slashes: true,
viewer      |         auth: null,
viewer      |         host: 'pacsip:8042',
viewer      |         port: '8042',
viewer      |         hostname: 'pacsip',
viewer      |         hash: null,
viewer      |         search: '?limit=25&offset=0&includefield=all',
viewer      |         query: 'limit=25&offset=0&includefield=all',
viewer      |         pathname: '/dicom-web/studies',
viewer      |         path: '/dicom-web/studies?limit=25&offset=0&includefield=all',
viewer      |         href: 'http://pacsip:8042/dicom-web/studies?limit=25&offset=0&includefield=all' },
viewer      |      _sync: false,
viewer      |      _headers:
viewer      |       { Accept: 'application/dicom+json',
viewer      |         Authorization: 'Basic b3J0aGFuYzpvcnRoYW5j',
viewer      |         Connection: 'keep-alive',
viewer      |         Host: 'pacsip:8042',
viewer      |         'User-Agent': 'Mozilla/5.0 (Linux x64) node.js/8.10.0 v8/6.2.414.50',
viewer      |         'Content-Length': '0' },
viewer      |      _loweredHeaders: { accept: 'Accept', authorization: 'Authorization' },
viewer      |      _mimeOverride: null,
viewer      |      _request: null,
viewer      |      _response: null,
viewer      |      _responseParts: null,
viewer      |      _responseHeaders: null,
viewer      |      _aborting: null,
viewer      |      _error: null,
viewer      |      _loadedBytes: 0,
viewer      |      _totalBytes: 0,
viewer      |      _lengthComputable: false },
viewer      |   response: null,
viewer      |   status: 0 }

@HowardLander, that is not a recent image. We have not used travis or meteor since version 1. Our latest released docker publish, while on v2, is a bit old. I have on my list to restore the automated publishing. I'll try to clear up the tags as well when I do to make thing clearer. I should have an update for you tonight/tomorrow.

@dannyrb Thanks much.  I'll plug in the new version and let you know what happens as soon as you publish it.
Howard

@HowardLander, that is odd. At the very least, this repository's master branch shouldn't be publishing to docker at the moment (especially using travis). Maybe an odd PR snuck into the pinned v1 branch and kicked off the process?

@dannyrb Yeah, I guess that could be.  In any case, just let me know when you are ready and I'll pull down another image to try.
Howard

@dannyrb Any progress on this issue?  Is it possible for me to build the docker myself? I cloned https://github.com/OHIF/Viewers.git but I wasn't sure which, if either of
./platform/viewer/.recipes/OpenResty-Orthanc/dockerfile
./platform/viewer/.recipes/OpenResty-Orthanc-Keycloak/dockerfile

I wanted to use. Those were the only dockerfiles I saw...
Howard

Just merged: https://github.com/OHIF/Viewers/pull/952
Docker Hub: https://cloud.docker.com/u/ohif/repository/docker/ohif/viewer
Recent tags:

ohif/viewer:latest
ohif/viewer:v<IP_ADDRESS>08 (vBREAKING.FEATURE.PATCH.BUILD)

Lots of ways to achieve your desired setup. We have a rough guide here:

https://docs.ohif.org/deployment/recipes/nginx--image-archive.html
./platform/viewer/.recipes/OpenResty-Orthanc/dockerfile

The docker files for those recipes need updated slightly to account for the monorepo build steps, but the dockerfile, docker-compose.yml, and nginx.conf should still serve as good learning pieces.

Hi @dannyrb
I inserted your new docker (v<IP_ADDRESS>08) into my docker compose file and did an up. The viewer came up as expected, but is getting its data from https://server.dcmjs.org/.  I have to admit I've been unable to get it to find my ortha server.  I have this in the ohif viewer section of my docker compose file:
      volumes:
         - ${VIEWER_CONFIG:-./config/renci.js}:/usr/share/nginx/html/config/default.js
         - ${NGINX_CONFIG:-./config/nginx-with-proxy.conf}:/etc/nginx/conf.d/default.conf
      environment:
         - MONGO_URL=mongodb://mongo:27017/ohif
         - APP_CONFIG=/usr/share/nginx/html/config/default.js

with the thought that this would map my renci.js file in place of docker_openresty-orthanc.js, but while the renci.js file is where I expected and the ENV variable is set, I am still getting the test data. When I log into the running ohif viewer docker, I can't find a file called docker_openresty-orthanc.js, nor do I seem to find an openresty dir.  So that's confusing.  Any help you can offer would be greatly appreciated.
Thanks
Howard

@HowardLander:
Here is the directory that contains recipes:

https://github.com/OHIF/Viewers/tree/master/platform/viewer/.recipes

The viewer config is at a new location. The change actually came up in a recent issue.

Previous location: /usr/share/nginx/html/config/default.js
New location: /usr/share/nginx/html/app-config.js

This change is largely due to some clean-up in our Progressive Web App's output. We used to copy everything from platform/viewer/public, but we're now a bit more deliberate.
You can find example app config files here:

https://github.com/OHIF/Viewers/tree/master/platform/viewer/public/config

Hopefully that's a little more helpful. Please keep me updated! It seems like you're close.

Hi @dannyrb
Yeah, changing the correct config file helped a lot. No surprise there!
I've still got some issues, getting the data from orthanc over to the viewer. Which version of orthanc are you using?  I've tried both latest and 1.5.6, but I'd like to try whatever you are using.  One other thing: how do I set the "studyListDateFilterNumDays" property?
Thanks
Howard

https://github.com/OHIF/Viewers/blob/master/platform/viewer/.recipes/OpenResty-Orthanc/docker-compose.yml#L37
Is the image we use. It comes with the DicomWeb plugin.
What issues are you having connecting? Does any of the advice spelled out here help?
https://github.com/OHIF/Viewers/issues/965

I'll have to look more on Monday.  We are using 1.5.6 so that's good. We have a working proxy config and I'm not sure that's the problem either.  I was wondering if maybe the issue is that our studies are more than 25000 days old, which is why I was asking about studyListDateFilterNumDays.  The funny thing is that if I go to orthanc:latest I can get the studylist, but the data only comes across sporadically (like some timeout value is being set!).  I thought I could just not have a date range in the UI, but when I try to do that, the viewer does not seem to generate another request...
Howard

That's odd. How much data do you have? I know that DicomWeb doesn't support paging, so the date range (or other filters) help limit the size and time it takes to receive a response.

We have a lot of data and, for privacy reasons, it all has the same date. Jan 1 1900! Si.com web does , I think, support the count parameter, but maybe I'm wrong?
Howard

From: Danny Brown<EMAIL_ADDRESS>Sent: Friday, September 27, 2019 5:44:37 PM
To: OHIF/Viewers<EMAIL_ADDRESS>Cc: Lander, Howard Michael<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [OHIF/Viewers] OHIF study listing hanging: For some reason we could not list the studies (#943)
That's odd. How much data do you have? I know that DicomWeb doesn't support paging, so the date range (or other filters) help limit the size and time it takes to receive a response.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/OHIF/Viewers/issues/943?email_source=notifications&email_token=AAJUNLK3UN4XZVUPLGE7W4TQLZ5ELA5CNFSM4IZSUIF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD72FKBA#issuecomment-536106244, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAJUNLNKJ76UD5T27THB7Z3QLZ5ELANCNFSM4IZSUIFQ.

Hmm.. How do you normally seek/find/filter your studies? We could show none by default, and initiate queries after X number of letters in the "name" filter? I'll double check on Monday -- if there is a count parameter, a reasonable default limit might make sense, so long as we indicate one is applied somewhere.

There is no normally yet really, as this is a system under development.  The target audience is, at least to some degree, researchers as opposed to practicing physicians.  They will probably use some sort of external tool to develop a cohort listing.
So I now have it all connected up and working. I would still like a way to control the default date range, but  once the user hits the x in the study dates area, the studies do appear. The biggest issue I have now is performance and I'm not sure that it's an OHIF problem  The metadata for the selected studies once I select a particular study is taking 20 or 30 seconds to appear.  When I look at the docker log, it seem to be executing a query like this:
GET /orthanc/dicom-web/studies/<IP_ADDRESS>5<IP_ADDRESS>.220.20081114.92724.6800289/metadata

and that query seems to be taking an inordinate amount of time to complete.  I confirmed this by doing a curl at the command line. Once the metadata is received and the images start to load, the  performance is great.  Have you seen this issue before? BTW, I am using orthanc:latest, whose performance was much better than that of 1.5.6
Thanks for all the help
Howard

@HowardLander, I know there are a number of things both you and we can do to improve the performance for large studies. If you're using nginx to proxy requests, you can:

Enable gzip compression (significant performance boost)
Make sure you're using http2
Depending on your requirements, cache metadata requests for a short period of time

On our end, this in-progress PR aims to split the metadata requests by series so you can begin viewing much more quickly while the remaining data loads in the background:
https://github.com/OHIF/Viewers/pull/953
We have thoughts around additional enhancements, but that alone appears to provide a pretty good boost.

@dannyrb Thanks for the pointers and #953 does look promising.  Each of our studies has 4 series, so we could potentially see a significant drop in perceived latency. Any idea when that might be available to try?
We are, in fact, using an nginx proxy.  I'll have a look at each of your suggestions!
Thanks
Howard

If the query is taking a long time to complete via cURL, that's an issue with Orthanc or your proxy set up. 20-30 seconds to retrieve metadata is very long and absolutely not normal. Maybe try their PostgreSQL database option? Or add some caching once the metadata bundle has been created? In terms of study size, how many instances are in these studies? Are you using an SSD? What type of VM is this on?
#953 has been merged, could you update and take a look again and let us know if you are still seeing performance issues? What is the average time it takes for Orthanc to return a WADO-RS series metadata bundle for your series?

Hi @swederik
I am using the PostgreSQL plugin and the db is on an SSD, so those two things are covered.  This is an Amazon EC2 instance with 8 CPUS and 32 Gb of memory. Load average is  not a problem. As far as the study size, typically each study has 4 series with between 400 and 700 images per, so the studies are not small.  One thing worth mentioning is that this is run with docker-compose. I wondered if the docker to docker network performance is an issue, so I ran the curl command from inside the docker image running orthanc.  Still way too slow.  So I am now leaning towards the idea that whatever optimization is to be done should start on the orthanc side. I will still try #953, however I'm going to pound away at orthanc for a bit first!
Thanks to both you and @dannyrb for your help.  Maybe we should keep the issue open long enough for me to find the resolution and post it for the next person?
Howard

Are you tied to Orthanc?  Other DICOMweb servers might be faster.

Possibly not. Which other DICOMWeb servers do you like? One thing is that this is an academic project which means it has to be fairly low cost/free.

Well, we typically use dcm4chee and have good luck.  At least as of a few years ago it was known to have a more efficient DICOMweb interface (don't know if that's still true but might be worth comparing).
My sentimental favorite is the one we are developing here: https://github.com/dcmjs-org/dicomweb-server. It's definitely still a work in progress, but I'm able to host a pretty good sized dataset and serve it to OHIF.  It would be interesting to know if it works for your use case - it has a lot of headroom for scalability and customization.

Is there a docker build for dicomweb-server?

We don't provide a Dockerfile, but you can get a couchdb docker and then dicomweb-server is just a single node server.

#953 has been merged, could you update and take a look again and let us know if you are still seeing performance issues. What is the average time it takes for Orthanc to return a WADO-RS series metadata bundle for your series?

@swederik : Is there a docker label I should be using to get the #953 functionality?
Howard

Since I promised to update this issue:
So as of now, it looks like the speed issue with the metadata call is the following: it turns out when you load files into the Orthanc database, you are only loading metadata.  That makes sense.  But apparently the dicom-web call to get the metadata needs more metadata than is loaded  into the database. So the code has to open every file in the study to get additional metadata, so depending on how many files comprise the study and on what technology they are stored, the query can slow down.  In our case the data is stored on an Amazon EFS drive, which has many virtues, but speed isn't one of them...
Howard

@swederik : Is there a docker label I should be using to get the #953 functionality?

It's in ohif/viewer:latest now that it has been merged to master. The CI publishes an updated docker image on each merge, assuming all the end-to-end tests pass.
For anyone else arriving at this issue, here is the relevant discussion on the Orthanc / DICOMweb endpoint performance questions:
https://groups.google.com/forum/#!topic/orthanc-users/y1N5zOFVk0M


Long help text wraps too narrowly

First Check

[X] I added a very descriptive title to this issue.
[X] I used the GitHub search to find a similar issue and didn't find it.
[X] I searched the Typer documentation, with the integrated search.
[X] I already searched in Google "How to X in Typer" and didn't find any information.
[X] I already read and followed all the tutorial in the docs and didn't find an answer.
[X] I already checked if it is not related to Typer but to Click.

Commit to Help

[X] I commit to help with one of those options 👆

Example Code
@app.command()
def start(

    # Strategy assets
    id: str = typer.Option(None, envvar="id help="Here we have a very long long long help text that wraps")
)

Description
The long help text does not respect the terminal width and wraps too early.
Here is an example screenshot of Ubuntu Linux terminal where you can see the Typer help text do not utilize the full terminal width, making the options harder to read.

I assume this is an underlying click issue, but I am filing the issue here, as I am a Typer user and I could not help regarding this issue in Github, Google or StackOverflow.
For a comparison, here is a screenshot of Go console program and it seems to be able to the wrapping fine:

Operating System
Linux
Operating System Details
Tested on

Ubuntu Linux
macOS

Typer Version
0.4.2
Python Version
3.10
Additional Context
No response

This is how the width is calculated:
https://github.com/pallets/click/blob/c65c6ad18471448c0fcc59ef53088787288c02cc/src/click/formatting.py#L122-L131
So the best option is to provide max_width:
app = typer.Typer(context_settings={
    "max_content_width": 120,
})

Is there an option to make this depend on the terminal width, like other UNIX software seems to be doing?

Yes, but if you set the max width big enough it's the same.
import shutil
...
"max_content_width": shutil.get_terminal_size().columns
...

Thank you @meirdev - works like a charm!

@meirdev I'm not having luck with the solution you suggested. I have a subcommand and also use a callback for top-level common options. Setting context_settings at the typer.Typer() level does not seems to have any effect, and unlike what is described in #365, doing that on the subcommand also does not have an effect of either. Do you happen to know if this is a known limitation currently?

It doesn't look like you were using rich, but if you are the Console used to generate helps does not respect the max_content_width context setting that click uses. It does respect the  TERMINAL_WIDTH environment variable.
Seems like any relevant click settings should probably make their way to the Console constructor.


Security: Login & Logout

Scenario: Guest User
Given: I am a guest
When: I access any page (other than login) in queue-triage platform
Then: I am redirected to login page
Scenario: Logging in
Given: I am a guest
And: I am at the login page
When: I enter correct credentials (username & password)
Then: I am redirected to the dashboard
Scenario: Logging out
Given: I am a logged in user
When: I click in the logout link in the menu
Then: I am redirected to the login page
And: I cannot access any page (other than login)
For the login feature we need integration with LDAP

I thought it would be sensible to start on this issue now, rather than trying to retro fit it later

The following endpoints will be left unsecured:

/login
/static/*

PR #44 created.


GSSOC '23: Added Drum Playing Game(Issue: #1622)

PR Description 📜
Added drum playing game ubder GSSOC '23
Fixes #1622

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have added screenshot for website preview in assets/images
[x] I have added entries for my game in main README.md
[x] I have added README.md in my folder
[x] I have added working video of the game in README.md (optional)
[x] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @sujanrupu ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

@kunjgit please review

Hey @sujanrupu !! we are already having this game on GameZone 👀

Thank you  @sujanrupu , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀


Django 1.7 support

With Django==1.7.2 the following Warnings show up when running ./manage.py validate:
System check identified some issues:

WARNINGS:
billing.PinCharge.success: (1_6.W002) BooleanField does not have a default value.
	HINT: Django 1.6 changed the default value of BooleanField from False to None. See https://docs.djangoproject.com/en/1.6/ref/models/fields/#booleanfield for more information.
billing.PinRefund.success: (1_6.W002) BooleanField does not have a default value.
	HINT: Django 1.6 changed the default value of BooleanField from False to None. See https://docs.djangoproject.com/en/1.6/ref/models/fields/#booleanfield for more information.

System check identified 2 issues (0 silenced).

The past few commits have been to support django 1.7. Please let us know if they are working fine on your end.

Closing this as it seems to be working fine with django 1.7. Please feel free to reopen the ticket if not so.


Add beautyline-icons

This package most likely can't be upstreamed due to another package already existing. This one however uses another repository as the source and does not contain Candy icons either.

sourceroot did in fact turn out to be wrong and wasn't needed anyways. We should be ready for merging now.


Repo sync working branch

  Caution: Large pull request
This public repo applies limits on the number of files that can be merged in a single pull request (PR):

Warning Warning message and ability to unblock PR using the Merge large pull request* label - 30
Block Block message and PR is blocked - 100

This pull request will change 36 files, which exceeds the warning limit of 36.
Before this pull request can be merged, you must review the list of files it contains and their changes to confirm they are correct and intentional. This includes files you did not change and/or do not own. If there are changes you aren't familiar with, contact the individuals who submitted the commits included in this pull request and review the changes with them.
The individual who merges this pull request is responsible for ensuring the changes included in it are correct, and for resolving any issues that might result in merging it.
To merge this pull request
If you have determined that the changes in this pull request are correct, add the Merge large pull request* label to it, wait for the max/pr-file-count check to pass, and then click Merge. To add a label, click the gear icon next to Labels and then select Merge large pull request*.

To reject this pull request
If you can't confirm the changes in this pull request are correct, click Close pull request at the bottom of this page to close it without merging. Work with your team to revert any changes that aren't correct.
* You must have write or triage access to this repo to add labels.


Ordering of the tutorial links is flipped

The first two tutorials in the list (below) assume you have completed the Launching Virtual Machines tutorial. I believe these are supposed to be ordered the opposite way.
Launching and connecting

Rebooting, Deleting, Rebuilding, Resizing
Access using SSH and VNC
Launching Virtual Machines

Yeah you're right. We moved to listing these dynamically and it has resulted in poor ordering.
Thanks for reporting.


remove hardcoded env variables for run handler

This allows for the customized invoker with an SPI to send more variables in the run handler
@eweiter could you review this PR.

@vvraskin ,@csantanapr Had asked me to review this, the logic looks clear and correct.  Please merge when you can.


DO NOT MERGE: CRM457-2154: add 'high value' filter to search

Description of change
Link to relevant ticket

It has the do not merge label, doesn't need it in the title otherwise it'll accidentally go into the commit.


[msal-common] Fix caching for multiple resources

offline_access scope was causing all scope sets to intersect, meaning all access tokens were being cached under the same entry with new scopes appended in the cache key. This PR aims to address this by ignoring offline_access when attempting to determine if we are adding or updating an access token in the cache.
This will fix: #1487

Coverage decreased (-0.008%) to 79.825% when pulling a4a29b9b320f4815c5de6224254f62a42e0d14f9 on fix-multiple-resource-bug-2.0 into 4e0a4c6c15dc6eb6df62acecc5fa6b307e19232a on dev.

In general looks good can we add a test to validate different scope scenarios ?


fix: reduced the call for fetchPublishedPage action to single

Description
There were multiple calls for fetchPublishedPage action which was disturbing the sequence of data tree evaluations and clearing cache resulting in the error message of action failing. Making it a single call restricts the cache being cleared before the evaluations as the call was non blocking.
Fixes #14141
Type of change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
Test Plan
Cypress

[ ] [Test Case] : Execute actions should get called once for every page change

Jest

[ ] [Test Case] : Testing Init Saga for execution of multiple action calls in a specified sequence

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes

Test coverage results :test_tube:
:green_circle: Total coverage has increased
// Code coverage diff between base branch:release and head branch: fix/14141-action-failed

Status
File
% Stmts
% Branch
% Funcs
% Lines

:green_circle:
total
56.72 (0.01)
38.67 (0)
36.23 (0)
56.97 (0.01)

:green_circle:
app/client/src/sagas/InitSagas.ts
50.56 (1.9)
36.67 (2.82)
58.33 (0)
53.95 (2.38)

:red_circle:
app/client/src/utils/autocomplete/TernServer.ts
52.71 (-0.23)
40.83 (-0.84)
36.21 (0)
56.74 (-0.25)

Is there a way to automate tests here?

/ok-to-test sha=4eec6aa

/ok-to-test sha=b17372d

/ok-to-test sha=d7279f3

/ok-to-test sha=11acafc

/ok-to-test sha=6e11061

/ok-to-test sha=25e1fee

/ok-to-test sha=5f0677c

/ok-to-test sha=4a5f696

/ok-to-test sha=4a5f696

/ok-to-test sha=f013589

/ok-to-test sha=e722bfe

/ok-to-test sha=4b47f5d

/ok-to-test sha=bfc79d4


Specify comment ratio script

Here is the output when run on the master branch:

Comments size
Spec size
Comments-Spec Ratio
Spec-Comments Ratio
Filename

0\t10\t0\t100.00\t./theories/VLSM/Lib/Itauto.v

0\t165\t0\t1650.00\t./theories/VLSM/Core/Equivocation/MsgDepFixedSetEquivocation.v

0\t21\t0\t210.00\t./theories/VLSM/Lib/ListFinSetExtras.v

100\t197\t.50\t1.96\t./theories/VLSM/Core/Equivocation/WitnessedEquivocation.v

102\t255\t.39\t2.49\t./theories/VLSM/Core/ByzantineTraces/FixedSetByzantineTraces.v

111\t240\t.46\t2.16\t./theories/VLSM/Core/TraceableVLSM/MinimalEquivocationTrace.v

113\t115\t.98\t1.01\t./theories/VLSM/Core/ByzantineTraces.v

113\t481\t.23\t4.25\t./theories/VLSM/Core/ELMO/MO.v

132\t417\t.31\t3.15\t./theories/VLSM/Core/Validator.v

13\t250\t.05\t19.08\t./theories/VLSM/Lib/StdppExtras.v

148\t334\t.44\t2.25\t./theories/VLSM/Core/Equivocators/Composition/LimitedEquivocation/FixedEquivocation.v

153\t866\t.17\t5.65\t./theories/VLSM/Core/ELMO/ELMO.v

156\t370\t.42\t2.37\t./theories/VLSM/Core/Equivocation/FixedSetEquivocation.v

160\t551\t.29\t3.44\t./theories/VLSM/Core/MessageDependencies.v

166\t703\t.23\t4.23\t./theories/VLSM/Core/Composition.v

18\t227\t.07\t12.54\t./theories/VLSM/Core/VLSMProjections/VLSMInclusion.v

18\t4\t4.39\t.22\t./theories/VLSM/Lib/EquationsExtras.v

1\t15\t.06\t13.63\t./theories/VLSM/Lib/FinExtras.v

1\t2\t.47\t1.81\t./theories/VLSM/Core/ELMO/AllELMO.v

1\t2\t.47\t1.81\t./theories/VLSM/Lib/SsrExport.v

1\t36\t.02\t32.72\t./theories/VLSM/Lib/Temporal.v

1\t58\t.01\t52.72\t./theories/VLSM/Lib/Measurable.v

1\t60\t.01\t54.54\t./theories/VLSM/Lib/StdppListFinSet.v

1\t78\t.01\t70.90\t./theories/VLSM/Lib/FinSetExtras.v

201\t608\t.33\t3.02\t./theories/VLSM/Core/ELMO/UMO.v

20\t219\t.09\t10.89\t./theories/VLSM/Core/EquivocationProjections.v

211\t1332\t.15\t6.30\t./theories/VLSM/Core/Equivocation.v

22\t98\t.22\t4.43\t./theories/VLSM/Core/Equivocators/Composition/LimitedEquivocation/LimitedEquivocationSimulation.v

24\t116\t.20\t4.81\t./theories/VLSM/Core/VLSMProjections/VLSMPartialProjection.v

26\t142\t.18\t5.44\t./theories/VLSM/Core/Equivocation/TraceWiseEquivocation.v

273\t1224\t.22\t4.48\t./theories/VLSM/Core/VLSM.v

27\t229\t.11\t8.45\t./theories/VLSM/Lib/ListSetExtras.v

27\t60\t.44\t2.21\t./theories/VLSM/Core/ReachableThreshold.v

28\t67\t.41\t2.38\t./theories/VLSM/Core/Equivocation/FullNode.v

2\t18\t.11\t8.57\t./theories/VLSM/Lib/RealsExtras.v

2\t29\t.06\t13.80\t./theories/VLSM/Lib/FinFunExtras.v

2\t83\t.02\t39.52\t./theories/VLSM/Lib/StdppListSet.v

33\t234\t.14\t7.06\t./theories/VLSM/Core/Equivocators/Composition/SimulatingFree/FullReplayTraces.v

33\t330\t.09\t9.96\t./theories/VLSM/Lib/TraceProperties.v

34\t162\t.20\t4.75\t./theories/VLSM/Core/Equivocators/MessageProperties.v

36\t179\t.20\t4.95\t./theories/VLSM/Core/Plans.v

38\t166\t.22\t4.35\t./theories/VLSM/Core/Equivocators/Composition/LimitedEquivocation/LimitedStateEquivocation.v

39\t273\t.14\t6.98\t./theories/VLSM/Lib/Preamble.v

3\t123\t.02\t39.67\t./theories/VLSM/Lib/SortedLists.v

3\t194\t.01\t62.58\t./theories/VLSM/Core/VLSMProjections.v

3\t32\t.09\t10.32\t./theories/VLSM/Lib/TraceClassicalProperties.v

40\t266\t.15\t6.63\t./theories/VLSM/Core/Equivocators/Composition/EquivocatorsComposition.v

41\t186\t.22\t4.52\t./theories/VLSM/Core/Equivocation/LimitedMessageEquivocation.v

43\t126\t.34\t2.92\t./theories/VLSM/Core/Equivocation/NoEquivocation.v

45\t262\t.17\t5.80\t./theories/VLSM/Core/ProjectionTraces.v

49\t130\t.37\t2.64\t./theories/VLSM/Core/Equivocators/Composition/SimulatingFree/SimulatingFree.v

52\t388\t.13\t7.44\t./theories/VLSM/Core/VLSMProjections/VLSMEmbedding.v

55\t570\t.09\t10.34\t./theories/VLSM/Core/VLSMProjections/VLSMTotalProjection.v

55\t98\t.56\t1.77\t./theories/VLSM/Core/Equivocators/Composition/LimitedEquivocation/FixedEquivocationSimulation.v

56\t165\t.33\t2.94\t./theories/VLSM/Core/ByzantineTraces/LimitedByzantineTraces.v

57\t299\t.19\t5.23\t./theories/VLSM/Lib/StreamFilters.v

58\t668\t.08\t11.49\t./theories/VLSM/Core/Equivocators/Composition/EquivocatorsCompositionProjections.v

58\t781\t.07\t13.44\t./theories/VLSM/Lib/ListExtras.v

5\t328\t.01\t64.31\t./theories/VLSM/Lib/StreamExtras.v

5\t80\t.06\t15.68\t./theories/VLSM/Core/Equivocators/EquivocatorReplay.v

63\t415\t.15\t6.57\t./theories/VLSM/Core/VLSMProjections/VLSMStutteringEmbedding.v

68\t284\t.23\t4.17\t./theories/VLSM/Lib/TopSort.v

6\t201\t.02\t32.95\t./theories/VLSM/Core/AnnotatedVLSM.v

71\t287\t.24\t4.03\t./theories/VLSM/Core/ELMO/BaseELMO.v

7\t142\t.04\t20.00\t./theories/VLSM/Lib/NeList.v

7\t318\t.02\t44.78\t./theories/VLSM/Core/Equivocation/MsgDepLimitedEquivocation.v

7\t52\t.13\t7.32\t./theories/VLSM/Lib/NatExtras.v

82\t713\t.11\t8.68\t./theories/VLSM/Core/SubProjectionTraces.v

85\t411\t.20\t4.82\t./theories/VLSM/Core/Equivocators/EquivocatorsProjections.v

89\t563\t.15\t6.31\t./theories/VLSM/Core/Equivocators/Equivocators.v

8\t143\t.05\t17.65\t./theories/VLSM/Core/VLSMProjections/VLSMEquality.v

98\t282\t.34\t2.87\t./theories/VLSM/Core/TraceableVLSM.v

9\t45\t.19\t4.94\t./theories/VLSM/Lib/Traces.v

@TeodorescuIoan The output you posted is a malformed. It seems you have \t where | should be for the table to render correctly.

@wkolowski I was just showcasing the output of the script as it is, as it stands it now is not useful for a command line user. If I do that change it is only useful for .md files. Wouldn't it be more useful to make it as a csv file?

@TeodorescuIoan can we add some script option to allow output as Markdown or csv on command? Both are useful in different contexts.

@TeodorescuIoan nice table, but can you sort it so that highest ratio is on top and then descend to lowest ratio? Easiest if you replace the unsorted comment.


Caddyfile?

Does anyone have information about how to set up a Caddyfile to work with pico?
I can get the basic index HTML serving with this:
:80 {
        root * /var/www/html/pico
        php_fastcgi unix//run/php-fpm/www.sock
        file_server
}

But static files are NOT served (e.g. css).
Presumably the .htaccess file needs to have a Caddyfile equivalent, but how?
[UPDATE:] on further investigation, this should work but for some reason Picocms is referencing files with the wrong URL.
I think this is because the URL's are not quite as caddy expects. For example, in the source of the page generated by the CMS is this:
   <link rel="stylesheet" href="https://www.argital.info:80/themes/default/css/style.css" type="text/css" />
    <link rel="stylesheet" href="https://www.argital.info:80/themes/default/css/droidsans.css" type="text/css" />
    <link rel="stylesheet" href="https://www.argital.info:80/themes/default/css/fontello.css" type="text/css" />

However it is the :80 that's breaking things. If I take that URL and remove the :80, I can browse to it, e.g.
https://www.argital.info/themes/default/css/fontello.css

I don't know what's adding the :80 but it's definitely not Caddy that's doing that. Any idea how to make it stop?

This provided some clues: https://github.com/picocms/Pico/issues/486
And the solution was to install Caddy server v2.5 (as this behaviour was due to a bug in earlier versions).

Hi there. 👋🏻
The port number issue also creeps up a lot when using Pico in a reverse-proxy environment, since Pico has trouble determining what its base_url should be.
If you have any more trouble with it, you can try specifying your base_url in config.yml (eg base_url: https://example.com).  You should see the port number disappear as it's probably just a side effect of Pico trying to determine the correct url (though, that's usually for ports other than 80).
Getting some Caddy examples in the Docs is something I'd like to do in the future too.  It sounds like you've got it working for now (minus the base_url issue).
Just keep in mind that in our Apache and Nginx examples, we deny public access to sensitive folders, like config, plugins, etc.  This should be possible with Caddy as well, I just don't have any examples to link you to at the moment. 😓
Anyway, let me know if you have any further issues.  I'm usually pretty on top of things here, though I've been a bit sluggish lately. 😅


fix: add java to blocked filetypes for semantic token auto_brackets

I think JDTLS already has built in auto-bracket support, but setting this seems to make stuff behave as it should on my part, and these docs suggested creating a PR.

Thanks!


Mac/Windows: Check if daemon able to serve after it starts

This PR add time limit (15 sec) to make sure daemon able to serve
the requests after it is start because sometimes just after start
it takes time to serve.
fixes: #3148

/hold
Not considered as release blocker during discussion.

/retest

e2e failure is not related to the changes in this PR

/unhold

Do we know why the 'daemon running' check needs to wait up to 15s? What is taking so long before it's ready?


Multiple queries no longer display all results.

The following used to work:
select * from myFunction(x1,y1);
select * from myFunction(x2,y2);
select * from myFunction(x3,y3);

Now I only get results when I do a single query in the query pane.
select * from myFunction(x1,y1);
Any more than one produces a blank response.
The only workaround at the moment is to have something like this, which produces the desired result:
(select * from myFunction(x1,y1))
union all
(select * from myFunction(x2,y2))
union all
(select * from myFunction(x3,y3));

Info about version:

Hi @Chumbaloo - Unfortunately displaying multiple query results was a bug of sorts. SQLPad is designed to handle a single query at a time. Multiple result sets are unsupported at this time.


Allow to delete contact using rawContactId

In some cases, we need to allow deleting contact by rawContactId. This PR allows deleting the contact in the old way (providing an object with recordID) or by providing the object with rawContactId.
rawContactId is supported only on Android.
The real use case:
Our app creates raw contacts using the data from the cloud server. Sometimes Android automatically links it to existing native contacts (created by user in native contacts app). In some circumstances, we need to delete the contacts which were created by our app, but we don't want to affect native contacts that existed before. When we delete using recordID, we delete all raw contacts associated with this contact (including both created by our app and by the user in his contacts app). If we support deleting by rawContactId we can delete only contact data created by our app and remaining other contact data.
If you'd agree to this change, I will be happy to add a documentation note as well.

sounds good. Document in the readme and demo in the example app.


single image test

Hello.
Thanks for code.
I want to test single image to get the collision rate.
The weird thing is that usual grayscale image is (1, 200, 200).
However your model require "outs = model.predict_on_batch(cv_image[None])"
the "input_1 to have 4 dimensions"
Could you point out which part should I look into it. I do not have much experience with keras. I know tensorflow little bit.
Thank you.

I solve the issue that I manually change the central img call back part
img = img[(240 - 200):(240),(160 - 100): 160+100]
and then it is working.
Do you know why it is work?


chore: use table examples for demo app

Based off #11112
Updates the table page on the demo app to depend more on table examples. Still would like to migrate the remaining ones over

@andrewseguin looks like this has real failures on CI

Note, not merge ready until #11112 is in

@andrewseguin needs rebase now that the dependency is in

Thanks, rebased


office 365 group primary domain

Office 365 group primary domain is not selectable via the Office 365 group wizard. This feature would be make it even better

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

ID: d36ccf55-c8e6-e4a2-c99d-1feeb9e0b7ca
Version Independent ID: 24e94600-1f0d-9d8b-abae-73690a4a633d
Content: Create an Office 365 group in the admin center
Content Source: Office365-Admin/create-groups/create-groups.md
Service: o365-administration
GitHub Login: @MikePlumleyMSFT
Microsoft Alias: mikeplum

@SvenBell - Thank you for engaging with the community here for the docs.
I know the product teams are always looking for user feedback and feature request on how to make Office 365. They keep a close tab on user feedback and it would be awesome if you could add your voice in UserVoice.
You might find others have made a similar request that you can add to, or you can open a new one. Let us know here if you do so we can up-vote your request.
Thank you for your contribution to make the docs better! Much appreciated!


How to make query with project fields?

I finally managed to integrate your plugin with grafana OSS. I was able to make basic queries using the MongoDb Compass way to making queries. I was wondering if there are other query methods it accepts such as the cli way?
I can't seem to show only certain columns when making the query, it gives all of the columns. In MongoDb examples it seems possible by using the Project filter . like so:  { item: 1, status: 1, "instock.qty": 1 } .  but I'm not sure how I can achieve this using the plugin.

Thank you @adil659 for using the Grafana plugin and for your question!
Regarding the current state, it's returning all entries, but it's possible to only select fields that have a specific value by using {"field": "value"} in the query zone.
The current implementation is doing find operations, and provides the query as the query parameter (first one), see reference here: https://www.mongodb.com/docs/manual/reference/method/db.collection.find/#mongodb-method-db.collection.find
In the future, I might add other fields to allow the user to set the projection, options, and also add support for other methods to query data than find.

oh okay, thankyou!


small docs fixes

Hey, I really dig your kafka library! I made some small docs fixes

thanks a lot!
The leading spaces inside the triple backquotes are no longer needed
could you help to unify this?

Ok fixed it.


Make storage part of MTPD plus rename and have explicit one

A simple pass to maybe make example sketches a little cleaner.
Renamed MTPD class to MTP_class like most of the usb classes are of names like:
usb_keyboard_class.
Defined  a standard object: MTP_class MTP
Removed MTPStorage from being a top level object and instead an object contained withing the MTP object.
Moved the Record structure to be contained within the MTPStorage class
Also made the constructor to be constexpr
Added a few wrappers  to have top level MTP.addFileSystem that calls through to the storage one.
added storage() to return pointer to it...
Note: the storage() method may be temporary as we should provide top level object methods for doing
all of the standard functionality.  We may decide to remove it or only use it for non-standard things
like debug functions for dumping the current indexl list.
created keywords.txt file
Updated library.properties file to only include the main header.  This may also be temporary
as this may be automaticaly included when a proper USB type is choosen.
Updated a few of the sketches to use these updates:
Update Example_2_simple_t41_qflash
Update Example_3_simple_SD.ino
Update ssimple_t41_qflash sketch to use this updated stuff.
Added Probably temporary - added my hardware fs class sketch

Did the merge work?  I'm not seeing these changes on the main branch.

Don't think the merge worked. Still seeing this in the example qflash
MTPStorage storage;     // TODO: storage inside MTP instance, not separate class
MTPD    MTP(&storage);  // TODO: MTP instance created by default

I punted that merge… look at 25.  I rebased first…
From: Paul Stoffregen @.>
Sent: Friday, January 07, 2022 10:46 AM
To: KurtE/MTP_Teensy @.>
Cc: KurtE @.>; State change @.>
Subject: Re: [KurtE/MTP_Teensy] Make storage part of MTPD plus rename and have explicit one (PR #24)
Did the merge work? I'm not seeing these changes on the main branch.
—
Reply to this email directly, view it on GitHub https://github.com/KurtE/MTP_Teensy/pull/24#issuecomment-1007648403 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAL4MQF3YICHA5N5OVRB7M3UU4YGHANCNFSM5LPL6QWA .
You are receiving this because you modified the open/close state.  https://github.com/notifications/beacon/AAL4MQBA4SQGGIG7NCUS7ZTUU4YGHA5CNFSM5LPL6QWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHQHX5EY.gif Message ID: @.*** @.***> >


Add closing command

A closing command was added analogous to example 2. Closes #67 .

@HannahRomberg : Feel free to merge ;)


boards: st: stm32h745i_disco: Use PLL1Q as FDCAN clock source

With this configuration of the device tree, we use 64 MHz as a FDCAN bus clock. This configuration allows to pass the tests.
$ ./zephyr/scripts/twister -p stm32h745i_disco/stm32h745xx/m7 --device-testing --device-serial /dev/ttyACM0 -v -t can
ZEPHYR_BASE unset, using "/media/jurenat/data/zephyrproject/zephyr"
Renaming output directory to /media/jurenat/data/zephyrproject/twister-out.1
INFO    - Using Ninja..
INFO    - Zephyr version: v3.6.0-4042-ge2db06649d88
INFO    - Using 'zephyr' toolchain.
INFO    - Building initial testsuite list...
INFO    - Writing JSON report /media/jurenat/data/zephyrproject/twister-out/testplan.json

Device testing on:

| Platform                        | ID   | Serial device   |
|---------------------------------|------|-----------------|
| stm32h745i_disco/stm32h745xx/m7 |      | /dev/ttyACM0    |

INFO    - JOBS: 16
INFO    - Adding tasks to the queue...
INFO    - Added initial list of jobs to queue
INFO    - 2590/2605 stm32h745i_disco/stm32h745xx/m7 tests/drivers/can/api/drivers.can.api.nxp_s32_canxl.non_rx_fifo SKIPPED (runtime filter)
INFO    - 2591/2605 stm32h745i_disco/stm32h745xx/m7 tests/net/socket/can/net.socket.can                PASSED (device 12.816s)
INFO    - 2592/2605 stm32h745i_disco/stm32h745xx/m7 tests/drivers/can/shell/drivers.can.shell          PASSED (device 7.864s)
INFO    - 2593/2605 stm32h745i_disco/stm32h745xx/m7 tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_64 PASSED (device 13.532s)
INFO    - 2594/2605 stm32h745i_disco/stm32h745xx/m7 tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance PASSED (device 12.942s)
INFO    - 2595/2605 stm32h745i_disco/stm32h745xx/m7 tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_32 PASSED (device 12.602s)
INFO    - 2596/2605 stm32h745i_disco/stm32h745xx/m7 samples/net/sockets/can/sample.net.sockets.can.two_sockets PASSED (device 5.173s)
INFO    - 2597/2605 stm32h745i_disco/stm32h745xx/m7 tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.unused PASSED (device 12.946s)
INFO    - 2598/2605 stm32h745i_disco/stm32h745xx/m7 samples/drivers/can/babbling/sample.drivers.can.babbling PASSED (device 1.875s)
INFO    - 2599/2605 stm32h745i_disco/stm32h745xx/m7 tests/drivers/can/api/drivers.can.api              PASSED (device 4.322s)
INFO    - 2600/2605 stm32h745i_disco/stm32h745xx/m7 tests/drivers/can/timing/drivers.can.timing        PASSED (device 2.426s)
INFO    - 2601/2605 stm32h745i_disco/stm32h745xx/m7 tests/subsys/canbus/isotp/implementation/canbus.isotp.implementation PASSED (device 18.263s)
INFO    - 2602/2605 stm32h745i_disco/stm32h745xx/m7 samples/drivers/can/counter/sample.drivers.can.counter PASSED (device 2.247s)
INFO    - 2603/2605 stm32h745i_disco/stm32h745xx/m7 samples/subsys/canbus/isotp/sample.subsys.canbus.isotp PASSED (device 2.977s)
INFO    - 2604/2605 stm32h745i_disco/stm32h745xx/m7 tests/drivers/can/api/drivers.can.api.rtr          PASSED (device 4.113s)
INFO    - 2605/2605 stm32h745i_disco/stm32h745xx/m7 samples/net/sockets/can/sample.net.sockets.can.one_socket PASSED (device 5.167s)

INFO    - 2809 test scenarios (2605 test instances) selected, 2590 configurations skipped (2589 by static filter, 1 at runtime).
INFO    - 15 of 2605 test configurations passed (100.00%), 0 failed, 0 errored, 2590 skipped with 0 warnings in 162.47 seconds
INFO    - In total 251 test cases were executed, 14213 skipped on 1 out of total 2 platforms (50.00%)
INFO    - 15 test configurations executed on platforms, 0 test configurations were only built.

Hardware distribution summary:

| Board                           | ID   |   Counter |
|---------------------------------|------|-----------|
| stm32h745i_disco/stm32h745xx/m7 |      |        15 |
INFO    - Saving reports...
INFO    - Writing JSON report /media/jurenat/data/zephyrproject/twister-out/twister.json
INFO    - Writing xunit report /media/jurenat/data/zephyrproject/twister-out/twister.xml...
INFO    - Writing xunit report /media/jurenat/data/zephyrproject/twister-out/twister_report.xml...
INFO    - Run completed

@henrikbrixandersen It can be done with a small change to the clock tree. Should I change it to 80 MHz?

@henrikbrixandersen It can be done with a small change to the clock tree. Should I change it to 80 MHz?

When doing so, please check that this won't have impact on other users of the selected domain clock

@henrikbrixandersen It can be done with a small change to the clock tree. Should I change it to 80 MHz?

When doing so, please check that this won't have impact on other users of the selected domain clock

I am using CubeMX to validate the clock tree and so far it looks fine, but I will double-check.

@henrikbrixandersen It can be done with a small change to the clock tree. Should I change it to 80 MHz?

If possible.

Rebased and changed clock to 80 MHz.
./zephyr/scripts/twister -p stm32h745i_disco/stm32h745xx/m7 --device-testing --device-serial /dev/ttyACM0 -v -t can
ZEPHYR_BASE unset, using "/media/jurenat/data/zephyrproject/zephyr"
Renaming output directory to /media/jurenat/data/zephyrproject/twister-out.11
INFO    - Using Ninja..
INFO    - Zephyr version: v3.6.0-4136-g420ad8e2c2e5
INFO    - Using 'zephyr' toolchain.
INFO    - Building initial testsuite list...
INFO    - Writing JSON report /media/jurenat/data/zephyrproject/twister-out/testplan.json

Device testing on:

| Platform                        | ID   | Serial device   |
|---------------------------------|------|-----------------|
| stm32h745i_disco/stm32h745xx/m7 |      | /dev/ttyACM0    |

INFO    - JOBS: 16
INFO    - Adding tasks to the queue...
INFO    - Added initial list of jobs to queue
INFO    - 2591/2606 stm32h745i_disco/stm32h745xx/m7 tests/drivers/can/api/drivers.can.api.nxp_s32_canxl.non_rx_fifo SKIPPED (runtime filter)
INFO    - 2592/2606 stm32h745i_disco/stm32h745xx/m7 tests/net/socket/can/net.socket.can                PASSED (device 3.686s)
INFO    - 2593/2606 stm32h745i_disco/stm32h745xx/m7 tests/drivers/can/shell/drivers.can.shell          PASSED (device 14.457s)
INFO    - 2594/2606 stm32h745i_disco/stm32h745xx/m7 samples/drivers/can/babbling/sample.drivers.can.babbling PASSED (device 3.811s)
INFO    - 2595/2606 stm32h745i_disco/stm32h745xx/m7 samples/subsys/canbus/isotp/sample.subsys.canbus.isotp PASSED (device 3.033s)
INFO    - 2596/2606 stm32h745i_disco/stm32h745xx/m7 samples/net/sockets/can/sample.net.sockets.can.one_socket PASSED (device 5.196s)
INFO    - 2597/2606 stm32h745i_disco/stm32h745xx/m7 tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_32 PASSED (device 12.636s)
INFO    - 2598/2606 stm32h745i_disco/stm32h745xx/m7 samples/net/sockets/can/sample.net.sockets.can.two_sockets PASSED (device 5.162s)
INFO    - 2599/2606 stm32h745i_disco/stm32h745xx/m7 tests/drivers/can/api/drivers.can.api.rtr          PASSED (device 4.155s)
INFO    - 2600/2606 stm32h745i_disco/stm32h745xx/m7 tests/drivers/can/api/drivers.can.api              PASSED (device 4.329s)
INFO    - 2601/2606 stm32h745i_disco/stm32h745xx/m7 tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance PASSED (device 12.925s)
INFO    - 2602/2606 stm32h745i_disco/stm32h745xx/m7 tests/drivers/can/timing/drivers.can.timing        PASSED (device 2.421s)
INFO    - 2603/2606 stm32h745i_disco/stm32h745xx/m7 samples/drivers/can/counter/sample.drivers.can.counter PASSED (device 2.258s)
INFO    - 2604/2606 stm32h745i_disco/stm32h745xx/m7 tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.unused PASSED (device 12.948s)
INFO    - 2605/2606 stm32h745i_disco/stm32h745xx/m7 tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_64 PASSED (device 12.630s)
INFO    - 2606/2606 stm32h745i_disco/stm32h745xx/m7 tests/subsys/canbus/isotp/implementation/canbus.isotp.implementation PASSED (device 18.269s)

INFO    - 2810 test scenarios (2606 test instances) selected, 2591 configurations skipped (2590 by static filter, 1 at runtime).
INFO    - 15 of 2606 test configurations passed (100.00%), 0 failed, 0 errored, 2591 skipped with 0 warnings in 198.60 seconds
INFO    - In total 251 test cases were executed, 14217 skipped on 1 out of total 2 platforms (50.00%)
INFO    - 15 test configurations executed on platforms, 0 test configurations were only built.

Hardware distribution summary:

| Board                           | ID   |   Counter |
|---------------------------------|------|-----------|
| stm32h745i_disco/stm32h745xx/m7 |      |        15 |
INFO    - Saving reports...
INFO    - Writing JSON report /media/jurenat/data/zephyrproject/twister-out/twister.json
INFO    - Writing xunit report /media/jurenat/data/zephyrproject/twister-out/twister.xml...
INFO    - Writing xunit report /media/jurenat/data/zephyrproject/twister-out/twister_report.xml...
INFO    - Run completed

You can probably enable full bitrate testing for this board, then, similar to https://github.com/zephyrproject-rtos/zephyr/blob/main/tests/drivers/can/timing/boards/stm32h735g_disco.conf

@darkmoon32 Please fix compliance checks

@darkmoon32 Please fix compliance checks

Sure, how about now?


run: set required permissions for OpenDKIM

OpenDKIM by default requires strict permissions on both the directory
of the key files as well as the key files themselves.
If the DKIM key is volume mounted (e.g. not created by run), then it
may not have the correct permissions. To fix this, we can always reset
the permissions with chown each time run is invoked.
Alternatively, we could use RequireSafeKeys false in opendkim.conf
so that the mail is sent regardless of permissions, but this is a less
secure option.

Let me add that I have been somewhat unhappy with this particular change, not because it is incorrect (it does fix an issue with OpenDKIM failing to deliver mail due to loose file permissions for pre-made keys), but rather because it interacts poorly with git.
For example, in my usage, I have an opendkim directory in my repo with a committed README.md that describes how to create DKIM keys and use them in my application. This directory is then volume mounted in the postfix-relay container and it is then chown'd to the container's opendkim user. As a result, I no longer have ownership of the opendkim directory, and if -- for example -- I try to switch between branches that rewind the commit that contains opendkim/README.md, I get an error.
This is not a deal-breaker because it can be fairly easily worked around, but it does have a perhaps unintuitive interaction with the local filesystem. How important is it that we favor security over convenience? Should we consider using RequireSafeKeys false instead?

Thanks for all the details! It's a bit late here so will read your comments and change more carefully tomorrow

And thanks for the other PRs. I use the docker image for a private tiny project and it does what it should for m.e But it seems like lots of other are using so feel a bit responsible keeping it nice and tidy

Hmm ok that is messy yes. Guess some documentation would be nice... but what should be default? have to meditate over 😄

@wader same here, this issue is intended to be fixed ?

Hello! @hemberger @kimsible sorry for the delay, forgot about it. I've tested and thought about the change a bit more now and dont think it's much different from the ower chown the image already does.
I've rebased, cleaned up a bit, tested and merge into master

Let me know if there is anything more to do

And thanks for the fix @hemberger

Thanks !


Switch to dynamic linking.

Switch cmake to shared third-party dependencies. Enable also shared build of
gtest in standalone thirdparty dependencies and add LD_LIBRARY_PATH to point
into standalone thirdparty libraries directory.
Dynamic linking is important for proper distribution, where components should not be bundled. It is even more important for libraries, where there would conflict symbols from several versions of libraries (for example static thrift in hs2client vs. dynamically linked another thrift by the software using hs2client library).

I disagree. What we need to do is add visibility macros and potentially a symbol map to hide the statically linked Thrift symbols from users (and use LINK_PRIVATE). See https://github.com/apache/parquet-cpp/commit/f97042d9bab10fffdb5e532fcc21a9ccc27f4f1c

I don't understand why is the static linking of thift needed here at all? Maybe it could be optional, so dynamic linking of it could be achieved without patching.

Why should users of this library be forced to install the Thrift dynamic libraries?

It's fine with me to add a cmake option for users who want to install all of the transitive dependencies of the project. Static linking in general helps prevent version incompatibilities. A user may have a different version of Thrift installed than the one used to build a binary (I work with a lot of users who aren't building all their own packages).

I don't know cmake much, so I probably won't create patch for optional usage. Maybe there is no option needed at all: "-L$(THRIFT_HOME)/lib -lthrift" will use the static or the shared version as needed and all use-cases will be supported. If the thift is static, it must be compiled with position independent flags to use it in the shared library - the build flag is already there in the third-party build script.
Users who want to compile hs2client have the third-party directory. Which is very good actually - no code bundling, not forcing users to use it, but helps in the case when user just want to compile hs2client.

What we need is a cmake option to select either the dynamic or static Thrift library for linking into the shared lib. I do not think this will be difficult to achieve. We would need to modify FindThrift.cmake to also set a variable for the shared library.


Balena bootloader support for the raspberrypicm4-ioboard-sb device

@resin-jenkins retest this please

Passed:

test-raspberrypi3-64
test-raspberrypi4-64
test-raspberrypi4-unipi-neuron
test-rt-rpi-300

Failed:

test-revpi-connect
test-raspberrypi3
test-raspberrypi0-2w-64
test-raspberrypi

These changes only refer to the raspberrypicm4-ioboard-sb - even though some DTs tests have not passed I am merging to unblock related work.


”Bunila”, ”Alun”, ”Cernișoara Florese”, ”Poienița Voinii”, ”Vadu Dobrii” are listed in the drop-down menu

Description:
When user writes ”Bunila”, ”Alun”, ”Cernișoara Florese”, ”Poienița Voinii”, ”Vadu Dobrii” the locations appear in the drop-down menu next to the comune and the county which is a part according to the law.
Precondition:
The website is up an running.

Step 1
Write in the search bar "Bunila"

Expected results
The location appears in the drop-down menu as "Sat Bunila, HUNEDOARA (Bunila)".

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 3
Write in the search bar "Alun"

Expected results
The location appears in the drop-down menu as "Sat Alun, HUNEDOARA (Bunila)".

Step 4
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 5
Write in the search bar "Cernișoara Florese"

Expected results
The location appears in the drop-down menu as "Sat Cernișoara Florese, HUNEDOARA (Bunila)".

Step 7
Write in the search bar "Poienița Voinii"

Expected results
The location appears in the drop-down menu as "Sat Poienița Voinii, HUNEDOARA (Bunila)".

Step 8
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 9
Write in the search bar "Vadu Dobrii"

Expected results
The location appears in the drop-down menu as "Sat Vadu Dobrii, HUNEDOARA (Bunila)".


Update README.md

Small grammar correction

Thanks, sorry it took so long for me to get around to this!


Struct with named fields can be deserialized from sequence

When I derive Deserialize for a struct containing named fields, I expect that in any format that has a way of expressing named fields (i.e. pretty much every ordinary format except Bincode), it will always be expressed as a map containing named fields. To my surprise, it can also be deserialized from a sequence of field values without field names, even in formats where this is not correct, such as JSON and YAML.
Accepting invalid data is a security risk as well as risk of causing people to rely on an unintended implementation details. This also risks having different implementations that differ in what data they accept, which is also a security risk. Further it bloats programs with visitor methods for parsing invalid data, which would otherwise automatically be removed by the compiler.
In this example, I'd like deserialization to fail, but it incorrectly parses invalid data into a structure. (Playground)
use serde_derive::Deserialize;

#[derive(Debug, Deserialize)]
struct Person {
    first_name: String,
    last_name: String,
}

fn main() {
    eprintln!("{:#?}", serde_json::from_str::<Person>(r#"["John","Doe"]"#));
}

Maybe this is due to implementations of various formats not taking proper care in what data they accept after deserialize_struct is called, or maybe it is because of Serde itself having an ambiguous purpose of the visit_seq method, and there needs to be a different visitor method that is used only for formats that don't use field names (e.g. Bincode), with a default implementation that delegates to visit_seq. Deriving Deserialize for structs would then implement this method, but not the visit_seq method which also applies to JSON sequences.

Do we have any solution for this yet? I also landed into this problem today where by my json is getting wrongly deserialized.
I have 2 types of values in a Container enum. The first is a struct containing String as field and the second is a Vector of String values.

pub enum Container {
String(Wrapper),
StringList(Vec),
}
pub struct Wrapper {
value: String
}

While deserializing json!(["abc"]) I get result as String(Wrapper { value: "abc" }) instead of StringList(["abc"])
Here is the code link: Playground

Would a #[serde(strict)] attribute be an acceptable solution for you? I imagine it would omit all the fallback implementations from the Visitor implentation the macro generates.
Fwiw, there's nothing stopping you from writing a Deserialize implementation that does this yourself: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=dc9fbffd94d47da2153a6308a30f5c88

Is there any way to enforce this without giving up #[derive(Deserialize)] at the present moment? What would it take to implement a #[serde(strict)] attribute like that?

I implemented the serde(strict) attribute as I interpreted it: #2639
The naming is intentionally left undecided. I would appreciate some feedback :)


dummy list  1   testing Task list

[x]  #74
[x] #75
[x] #76
[x] This
[x] That

Wait for Tasklist to be released,  dont use task list


Disable YouTube

Checklist

[X] I'm asking a question and not reporting a bug or requesting a feature
[X] I've looked through the README
[X] I've verified that I'm running yt-dlp version 2<IP_ADDRESS> (update instructions) or later (specify commit)
[X] I've searched the bugtracker for similar questions including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue

Question
Is there any option to disable download YouTube video?
Some site use YouTube video embed frame in their site and if I use that site URL in yt-dlp then that YouTube video downloads. I want to disable this type of video download.
In short, If YouTube video URL found in webpage, then skip download.
If this is doable, then please guide me.
Verbose log
No response

--match-filter 'extractor!~=youtube'

@flashdagger Thank you very much.
It is working as expected.


Where found Keyboard Manager

Hi,
I have the version 16.1 installed, but cannot found the Keyboard Manager :(
Where can I found it ?
Thanks a lot by advance

@ysoudy
the Keyboard Manager hasn't been released yet.

Should be in 0.18 release :)

how Can I download the beta version ? ;)

if you want to compile a work in progress, the branch is https://github.com/microsoft/PowerToys/tree/dev/build-features
first external available build will be 0.18 in May
This is very much a work in progress so please be warned


Remove --from-address for health.email integrations, as there is now a good API default

Closing in favour of #915


Clean up semantics for updating counter for deleted tweets

Currently, there are two places where we have checked for deleted tweets. One is the -tweet.deletedIdsFile option passed into IndexCollection and the other one is when the delete field is detected in the JSON string when parsing each tweet document in TweetCollection using Jackson.
As mentioned by @lintool , since we have to comply with Twitter API usage agreement, we have to use the deleted tweets file. So we will get rid of checking for deleted tweets in JSON parsing in TweetCollection and let TweetGenerator checks for deleted tweets and update the counters.skipped counter, preventing updating the skipped counter twice.
@Peilin-Yang Thoughts?

Additional clarification - we don't actually index the stream live - the JSON messages are always captured in a file first. So we do another pass to gather up all the JSON delete messages into a file that we pass to tweet.deletedIdsFile in the indexing code.

As part of working on #916 - rereading this issue - I think this can be closed.


App Crash in Release Build --- FATAL EXCEPTION: create_react_context

Description
I can build in debug mode, it works fine, but when I get release build, it gets build, but the application breaks, you can see the error output here.
React Native version:
"react-native": "0.62.2",
##Error
Name
FATAL EXCEPTION: create_react_context
Reason
java.lang.RuntimeException: Unable to load script. Make sure you're either running a Metro server (run 'react-native start') or that your bundle 'index.android.bundle' is packaged correctly for release.
Stacktrace
FATAL EXCEPTION: create_react_context
Process: com.seeandsign.papilon, PID: 27990
java.lang.RuntimeException: Unable to load script. Make sure you're either running a Metro server (run 'react-native start') or that your bundle 'index.android.bundle' is packaged correctly for release.
at com.facebook.react.bridge.CatalystInstanceImpl.jniLoadScriptFromAssets(Native Method)
at com.facebook.react.bridge.CatalystInstanceImpl.loadScriptFromAssets(Unknown Source:2)
at com.facebook.react.bridge.JSBundleLoader$1.loadScript(Unknown Source:10)
at com.facebook.react.bridge.CatalystInstanceImpl.runJSBundle(Unknown Source:18)
at com.facebook.react.q.q(Unknown Source:180)
at com.facebook.react.q.b(Unknown Source:0)
at com.facebook.react.q$e.run(Unknown Source:68)
at java.lang.Thread.run(Thread.java:764)

@grkemtneri
I faced same issue so I changed gradle plugin version in project gradle from 4.1.1 to 4.0.1
Then clean, rebuild and generate apk and now it is working fine

@grkemtneri
I faced same issue so I changed gradle plugin version in project gradle from 4.1.1 to 4.0.1
Then clean, rebuild and generate apk and now it is working fine

thank you for your reply.  I found solution  npx react-native bundle --platform android --dev false --entry-file index.js --bundle-output android/app/src/main/assets/index.android.bundle

thank you for your reply.  I found solution  npx react-native bundle --platform android --dev false --entry-file index.js --bundle-output android/app/src/main/assets/index.android.bundle

@grkemtneri This is not a good solution, you are generating code (index.android.bundle) inside source folder (android/app/src/) during build phase...
react.gradle tasks will generate it in build folder (build/generated/assets/react/...). But like @rahulson says, with latest version of com.android.tools.build:gradle, index.android.bundle is not copied inside APK. I downgraded to 'com.android.tools.build:gradle:4.0.2' & it's works too.

@grkemtneri This is not a good solution, you are generating code (index.android.bundle) inside source folder (android/app/src/) during build phase...
react.gradle tasks will generate it in build folder (build/generated/assets/react/...). But like @rahulson says, with latest version of com.android.tools.build:gradle, index.android.bundle is not copied inside APK. I downgraded to 'com.android.tools.build:gradle:4.0.2' & it's works too.

thank you so much. I will try

thank you so much. I will try

@grkemtneri Hi. Have you solve this issue? Currently running with the same problem.

@grkemtneri This is not a good solution, you are generating code (index.android.bundle) inside source folder (android/app/src/) during build phase...
react.gradle tasks will generate it in build folder (build/generated/assets/react/...). But like @rahulson says, with latest version of com.android.tools.build:gradle, index.android.bundle is not copied inside APK. I downgraded to 'com.android.tools.build:gradle:4.0.2' & it's works too.

@giovankabisano you can try this

I have the same issue today but downgrading com.android.tools.build:gradle:4.0.2 gives me an error:
 No version of NDK matched the requested version
I am using com.android.tools.build:gradle:4.1.0
App build is successful but the app crashes upon start, app opens then close right away.
what to do?

it;s a known issues that is fixed on RN version 0.63.4 https://github.com/react-native-community/releases/blob/master/CHANGELOG.md#v0634
Here is the commit with changes
https://github.com/facebook/react-native/commit/53f55001afbf07494de0df064a92dfdd42f37c98
If. you don't want to upgrade RN version just copy react.gradle file in your project and apply that instead of the one from RN

@grkemtneri
I faced same issue so I changed gradle plugin version in project gradle from 4.1.1 to 4.0.1
Then clean, rebuild and generate apk and now it is working fine

@rahulson Thank you for your solution :). This worked for me. I did the same and it worked.

Still exists in RN 0.64.2.
buildToolsVersion = "29.0.3"
minSdkVersion = 21
compileSdkVersion = 29
targetSdkVersion = 29
ndkVersion = "20.1.5948944"

classpath("com.android.tools.build:gradle:4.1.0")

enableHermes: true

Log:
2021-06-24 11:07:58.748 1007-5213/? E/ActivityTaskManager: Checking for the Active launch isDataCleared :false, isAutoRunBlocked : true
2021-06-24 11:07:58.814 15692-15692/? E/.*****.app: Not starting debugger since process cannot load the jdwp agent.
2021-06-24 11:07:58.850 1007-5176/? E/PkgPredictorService-Collector: record changed bt=0  wifi=1 screen=0
2021-06-24 11:07:58.888 15692-15692/? E/SoLoader: couldn't find DSO to load: libjscexecutor.so caused by: dlopen failed: library "libjsc.so" not found: needed by /data/app/~~8NygCsdZ2mcU-SK5ss4onA==/com.*****.app-Kpu6H-gmP1-P0kwqnSKSOA==/lib/arm64/libjscexecutor.so in namespace classloader-namespace result: 0
2021-06-24 11:07:58.943 15692-16083/? E/SoLoader: couldn't find DSO to load: libhermes-executor-debug.so caused by: dlopen failed: cannot locate symbol "_ZN8facebook6hermes13HermesRuntime11getDebuggerEv" referenced by "/data/app/~~8NygCsdZ2mcU-SK5ss4onA==/com.*****.app-Kpu6H-gmP1-P0kwqnSKSOA==/lib/arm64/libhermes-executor-common-debug.so"... result: 0
2021-06-24 11:07:58.998 601-647/? E/HYPER-HAL: [Request.cpp]acquire(): Request:: id : 526870, No Resource to set
2021-06-24 11:07:59.012 15692-16083/? E/AndroidRuntime: FATAL EXCEPTION: create_react_context
    Process: com.*****.app, PID: 15692
    java.lang.RuntimeException: Unable to load script. Make sure you're either running Metro (run 'react-native start') or that your bundle 'index.android.bundle' is packaged correctly for release.
        at com.facebook.react.bridge.CatalystInstanceImpl.jniLoadScriptFromAssets(Native Method)
        at com.facebook.react.bridge.CatalystInstanceImpl.loadScriptFromAssets(CatalystInstanceImpl.java:234)
        at com.facebook.react.bridge.JSBundleLoader$1.loadScript(JSBundleLoader.java:29)
        at com.facebook.react.bridge.CatalystInstanceImpl.runJSBundle(CatalystInstanceImpl.java:263)
        at com.facebook.react.ReactInstanceManager.createReactContext(ReactInstanceManager.java:1293)
        at com.facebook.react.ReactInstanceManager.access$1100(ReactInstanceManager.java:131)
        at com.facebook.react.ReactInstanceManager$5.run(ReactInstanceManager.java:1023)
        at java.lang.Thread.run(Thread.java:923)

my log is the same from @1280103995

I have been facing this issue since 0.63.2. Recently upgraded to 0.64.2, still the issue persist. Using classpath("com.android.tools.build:gradle:4.1.0") in android/gradle.build. Same source code, same building method results in app crash / successful launch.
Knowledge sharing:
For the moment, I'm doing manual check on every .aab file built to ensure the file does not cause any app crash.
bundletool build-apks --bundle=app-release.aab --output=release.apks && Bundletool install-apks --apks=release.apks --device-id=${replaceWithYourDeviceID}

How to get your device-id?

Connect your device to machine
Run adb devices at terminal
You'll see your devices

@grkemtneri
I faced same issue so I changed gradle plugin version in project gradle from 4.1.1 to 4.0.1
Then clean, rebuild and generate apk and now it is working fine

I was facing the issue on React Native 0.60.4. Downgraded gradle to 4.0.2 and worked!
Thanks!!

thank you for your reply. I found solution  npx react-native bundle --platform android --dev false --entry-file index.js --bundle-output android/app/src/main/assets/index.android.bundle

Oh, it fixes the bundle problem, but the pics inside the project has gone, no local pics has been bundled into release apk....


Bring support for nRF54H20 IPC

This PR brings:
https://github.com/zephyrproject-rtos/zephyr/pull/69303
https://github.com/zephyrproject-rtos/zephyr/pull/69477
https://github.com/zephyrproject-rtos/zephyr/pull/69481
https://github.com/zephyrproject-rtos/zephyr/pull/69487
(and a few other changes required to apply clean patches or fix issues like eg. https://github.com/teslabs/sdk-zephyr/commit/e5d14c682136832652c74b2c054c91e203b04950)

The following west manifest projects have been modified in this Pull Request:

Name
Old Revision
New Revision
Diff

hal_nxp
https://github.com/zephyrproject-rtos/hal_nxp/commit/69046233b7a7fac3138ae4dd5bcf6158e82529bb
https://github.com/zephyrproject-rtos/hal_nxp/commit/0463d6aa0de62761fb9ae56e3521c61b0e490374
<EMAIL_ADDRESS>

Note: This message is automatically posted and updated by the Manifest GitHub Action.

Note: compliance check is not reported upstream, we likely miss a patched checkpatch here, so ignore those.


DBZ-1227 Upgrade to Kafka 2.2.0

https://issues.jboss.org/browse/DBZ-1227

Applied; thanks, @Naros!


runtine: Add cluster.proxy-url to kubeconfig allow fields

Fix: #746
Fix: https://github.com/fluxcd/kustomize-controller/issues/1042

Please signoff your commit and force push, docs here: https://github.com/fluxcd/pkg/pull/747/checks?check_run_id=23046074271

Hi @stefanprodan - Apologies for not including it in the original request - I believe the check should now be ok.

@garyhodgson we've fixed the CI issues in main, please rebase and force push.


Add mutation instrumentation

Brings mutation score to 84.85% on currently instrumented functions. Macros were left out because of infeasible number of tests required to kill mutants at each defined array size. Will add additional mutation instrumentation and tests after const generic refactor.

Codecov Report

Merging #4 (0760d7a) into master (bc8e5c2) will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master       #4      +/-   ##
==========================================
+ Coverage   99.61%   99.64%   +0.03%
==========================================
  Files           1        1
  Lines         259      282      +23
==========================================
+ Hits          258      281      +23
  Misses          1        1

Impacted Files
Coverage Δ

src/lib.rs
99.64% <100.00%> (+0.03%)
: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 bc8e5c2...0760d7a. Read the comment docs.


enable offline mode

I can't figure out how to enable this feature. I cruise a lot and internet isn't active most of the time so I need the offline mode enabled.  Thank You

Just go into the screensaver's preferences, enable the caching feature and click "Download Now".  This will allow you to run the screensaver when you are offline.

@BJTHEIS Did you get the videos cached?

Thank you very much
I believe it did:)

On Jan 28, 2016, at 3:56 PM, Alistair McMillan<EMAIL_ADDRESS>wrote:
@BJTHEIS https://github.com/BJTHEIS Did you get the videos cached?
—
Reply to this email directly or view it on GitHub https://github.com/JohnCoates/Aerial/issues/182#issuecomment-176439570.

Glad to hear it. :)


Fix #4 - templates revision: remove subtree.

I suggest to remove templates subtrees. Actually this is not mandatory, and that generates an issue.

thank you for the PR and I apologize for the delay.


⚠ Bofrost.hr has degraded performance

In 9ecc078, Bofrost.hr (https://www.bofrost.hr) experienced degraded performance:

HTTP code: 200
Response time: 4403 ms

Resolved: Bofrost.hr performance has improved in 42a0573 after 15 minutes.


JTAG SBCS advertises access sizes that fail on ICCM

SBCS register value is 0x2000040f
Bits 3:0 indicate 64, 32, 16, and 8 bit system bus accesses are supported.
Reads and writes to ICCM with data size smaller than 32 bits fail with sberror = 2
Based on the width of the ICCM address signals I would expect for 8bit access to fail but for 16 bit accesses to work.
logic [pt.ICCM_BITS-1:1]    iccm_rw_addr;
For SW breakpoints (either directly in OpenOCD or in GDB) ICCM may be accessed using 16 bit reads at 16 bit aligned addresses because of compressed instructions. After system bus access fails it falls back to abstract access which succeeds and allows break points to function.
In contrast, DCCM accesses work so long as the address is naturally aligned to the access size.

el2_dma_ctrl.sv:314: (dma_mem_addr_in_iccm & ~((dma_mem_sz_int[1:0] == 2'b10) | (dma_mem_sz_int[1:0] == 2'b11)))                 |    // ICCM access not word size
el2_dma_ctrl intentionally rejects (sets dma_alignment_error) for ICCM reads or writes that aren't 32 or 64 bits in length.
Regarding SBCS, the system bus does support 8 and 16 bit accesses on ROM and DCCM which both work. Only ICCM doesn't support them.

Rejecting as the behavior is expected. While the errors are confusing software breakpoints do function on ICCM addresses.


There is a vulnerability in the library that Opencv-python depends on.

Expected behaviour
I use opencv-python to do some image and video processing
Actual behaviour
Write here what went wrong.
Steps to reproduce

CentOS
x86
opencv-python==<IP_ADDRESS>
libpng 1.5.13 CVE-2014-9495 CVE-2015-8540 CVE-2016-10087 CVE-2015-0973 CVE-2015-8472 CVE-2013-7353
ffmpeg 4.3.2 CVE-2021-38291 CVE-2020-22042 CVE-2020-22038 CVE-2020-22019 CVE-2020-22037
openssl 1.1.1g CVE-2021-3711 CVE-2021-23840 CVE-2021-3712 CVE-2020-1971 CVE-2021-23841 CVE-2021-3449

Issue submission checklist

[ ] This is not a generic OpenCV usage question (looking for help for coding, other usage questions, homework etc.)

[ ] I have read the README of this repository and understand that this repository provides only an automated build toolchain for OpenCV Python packages (there is no actual OpenCV code here)

[ ] The issue is related to the build scripts in this repository, to the pre-built binaries or is a feature request (such as "please enable this additional dependency")

[ ] I'm using the latest version of opencv-python

Hi @Norman416!
I have updated a docker image to use the latest releases of these libraries:

libpng 1.6.37
ffmpeg 4.4.1
openssl 1.1.1m

Could you tell me, how I can check a package on a vulnerability?

The tool I use is woodpecker.
https://woodpecker.co/vulnerability-disclosure-program/

Done with releases <IP_ADDRESS> and <IP_ADDRESS>.


pynndescent update warning

Hi,
I ran a fresh pip install of openTSNE and got the following warning :
/usr/local/lib/python3.8/dist-packages/openTSNE/nearest_neighbors.py:331: UserWarning: `pynndescent` has recently changed which distance metrics are supported, and `openTSNE.nearest_neighbors` has not been updated. Please notify the developers of this change.

With the following error (not sure if it is related, I'm fairly new to Python) :
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.8/dist-packages/openTSNE/tsne.py", line 1189, in fit
    embedding = self.prepare_initial(X)
  File "/usr/local/lib/python3.8/dist-packages/openTSNE/tsne.py", line 1235, in prepare_initial
    affinities = PerplexityBasedNN(
  File "/usr/local/lib/python3.8/dist-packages/openTSNE/affinity.py", line 137, in __init__
    self.knn_index, self.__neighbors, self.__distances = build_knn_index(
  File "/usr/local/lib/python3.8/dist-packages/openTSNE/affinity.py", line 319, in build_knn_index
    neighbors, distances = knn_index.build(data, k=k)
  File "/usr/local/lib/python3.8/dist-packages/openTSNE/nearest_neighbors.py", line 394, in build
    self.index = pynndescent.NNDescent(
TypeError: __init__() got an unexpected keyword argument 'algorithm'

I am running :

openTSNE 0.4.4
pynndescent 0.5.1
Python 3.8.5
Ubuntu 20.04.1 LTS (Singularity image)

My code is :
import numpy
from openTSNE import TSNE
from openTSNE.callbacks import ErrorLogger

# Parse CSV
cpm = numpy.genfromtxt('out/CPM_0.975.tsv', delimiter='\t', names=True)

# Initialize TSNE model
model = TSNE(
    perplexity = 10,
    metric = "correlation",
    n_jobs = 8,
    random_state = 42,
)

# Run TSNE
tsne = model.fit(cpm)

Best,
Sylvain

This is already fixed in the Github version but is unfortunately not on pip/conda yet. You can either download and install from Github, or wait until it's released on pip/conda (but I don't know how long @pavlin-policar), or manually replace nearest_neighbors.py in your installation with the Github version. This is the only affected file.

Hi Dmtry,
It works replacing the file you mention with the version in Github, and the error was not related. Thanks a lot !
Best,
Sylvain

I'm going to try to release a new version with the fix in the next few days. I was waiting for Py39 to be available on the Windows VMs on Azure pipelines, where we build our wheels. They're available now. I just have to fix some bug with LLVM that just started popping up.


VertexAttributes func caching last values

Calling AddVertex() with VertexAttribute() functions will sometimes cache the last value on all vertices. I've been unable to reproduce this via your unit tests, but this shows the issue:
package main

import (
	"bytes"
	"fmt"
	"github.com/dominikbraun/graph"
	"github.com/dominikbraun/graph/draw"
)

var (
	hashingFunction = func(d someVertex) string { return d.Name }
	redVertexAttr   = graph.VertexAttributes(map[string]string{"color": "red"})
	dotBuffer       bytes.Buffer
)

type someVertex struct {
	Name string
}

func main() {

	g := graph.New(hashingFunction, graph.Directed())

	for i, name := range []string{"foo", "bar", "baz"} {
		vertex := someVertex{Name: name}

		label := fmt.Sprintf("%s [%d]", name, i)
		fmt.Printf("adding someVertex{Name: %s} with label %s\n", name, label)

		_ = g.AddVertex(
			vertex,
			redVertexAttr,
			graph.VertexAttribute("label", label),
		)

		// read the new vertex back
		newVertex, newVertexProps, _ := g.VertexWithProperties(vertex.Name)
		fmt.Printf("new Vertex %s: %#v\nProps: %#v\n\n", vertex.Name, newVertex, newVertexProps)
	}

        fmt.Println("Here be issues:")

	fooVertex, fooProps, _ := g.VertexWithProperties("bar")
	fmt.Printf("Vertex bar: %#v\n", fooVertex)
	fmt.Printf("Vertex bar properties: %#v\n", fooProps)

	if dotErr := draw.DOT(g, &dotBuffer); dotErr != nil {
		panic(dotErr)
	}

	fmt.Printf("\n%s", dotBuffer.String())
}

---

adding someVertex{Name: foo} with label foo [0]
new Vertex foo: main.someVertex{Name:"foo"}
Props: graph.VertexProperties{Attributes:map[string]string{"color":"red", "label":"foo [0]"}, Weight:0}

adding someVertex{Name: bar} with label bar [1]
new Vertex bar: main.someVertex{Name:"bar"}
Props: graph.VertexProperties{Attributes:map[string]string{"color":"red", "label":"bar [1]"}, Weight:0}

adding someVertex{Name: baz} with label baz [2]
new Vertex baz: main.someVertex{Name:"baz"}
Props: graph.VertexProperties{Attributes:map[string]string{"color":"red", "label":"baz [2]"}, Weight:0}

Here be issues:
Vertex bar: main.someVertex{Name:"bar"}
Vertex bar properties: graph.VertexProperties{Attributes:map[string]string{"color":"red", "label":"baz [2]"}, Weight:0}

strict digraph {

        "baz" [ color="red", label="baz [2]",  weight=0 ];

        "foo" [ color="red", label="baz [2]",  weight=0 ];

        "bar" [ color="red", label="baz [2]",  weight=0 ];

}

Each vertices' Attributes map contains the Attributes of the last created vertex. Am I creating these VertexProperties functions incorrectly, or mis-using them?

Attributes map of all VertexProperties share the same map declared in the line of:
    redVertexAttr   = graph.VertexAttributes(map[string]string{"color": "red"})

This was a bug of the library, and I fixed it in PR https://github.com/dominikbraun/graph/pull/179, cc. @dominikbraun


Add a pixi project feature to add, remove, list, and edit features.

Problem description
Using the CLI, it's possible to add, remove, list, and edit environments, but you can't do the same for features.
You can only manage features by editing the manifest file directly, but you can associate an environment to a feature in with the pixi project environments add  --features  flag.

It looks like pixi task add --feature test test "pytest" will implicitly create a feature if it doesn't exist which is interesting.

So I think you would like an extra CLI under pixi project? :)

Yes. Just rounding out some of the things you can use the CLI to edit in the toml. Nearly everything is accessible except “features”.

Got it! We should actually also add the pypi-options there :)


In debug mode the map is not loaded? (WhiteScreen)

Hey there. Module works fine with release apk (signed), but when i am using the debug.apk on emulator as well as on real device i don´t see any Map...Any ideas?
Running on Mac / ReactNative 0.20 / GenyMotion emulator / Sony Xperia Z5

Same Problem

You need to make sure that your debug keystore SHA1 has been added to the Google API console.
To find it use Terminal.app and type:
keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android

Add the SHA1 shown here, and it should then work.

@benvium Great job thanks!!! Works. I had it for release apk but of course not for debug.keystore. I thought it would have the same SHA1 key

@BigPun86 @benvium  I tried using the debug.keystore I generated inside my app,but had no luck. How is the debug keystore in .android and my app folder different?


Merging $_GET and $_POST

https://github.com/PatrickLouys/http/blob/master/src/HttpRequest.php#L19
As you may as well know, you merged the $_GET and $_POST. I think you shouldn't merge them. Why? Imagine this scenario:
Lets say you have a $_GET parameter of key "foo", and at the same time, you submit a form with POST with the same key "foo", and once you merge them, don't you think either one of them will be lost? Therefore, I'd recommend you to split them.
Credits: @samayo for finding out and submitting this argument. I posted this on behalf of him because he is busy.

I am aware of that. It was a design choice made on purpose at the time. Mixing GET and POST is not a good idea anyway, especially with the same parameter name. In the end it's just a bunch of parameters that you send to the application.
I'll close this for now. If you have other arguments for a split of the parameters let me know :)


Turn one source label into multiple target labels

Proposal
Hey
So, we have the usecase that we have one central prometheus instance and developers do not have access to the prometheus configuration. We are scraping consul for our metrics targets. While applications can provide their own labels, there is also certain data that the application doesn't know of, for example its (dynamic) id in our deployment system. What we'd like to be able to do, is to have some generic consul tag where can extract promtheus labels from.
For example with this config:
      - source_labels: [__meta_consul_tags]
        regex: "(?:^|.*?,)prom_label__(.+?)=(.+?)(?:$|,.*?)"
        action: replace
        target_label: $1
        replacement: $2

Given these consul tags:
a=b,b=c,prom_label__f=g,t=e,prom_label__z=l,l=o

I'd expect these labels in prometheus for the given target:
f=g,z=l

The workaround would be to manually list the labels for all services, which could be quite a lot.
I've already looked at the code and guess that we can easily change the regex code to use multiple matches instead of just one set of submatches. Adjusting the tests is an easy feat as well. This should imo not be a breaking change.

Hello,
There is too much risk that this creates an avalance of labels and therefore we have always said that it is better not to use this options for users. This could lead to many many cardinality issues.

The issue arises from the "problem" that both consul and nomad provide their labels as a single comma separated list. I guess an alternative solution for this particular case would be to have an option in the SD implementation to split the labels before passing them into relabeling.

Yes


Updated to work with changes/deprecations to Chome Web Microphone API

The previous version wasn't working. Looked into the WebAudio API and made the changes necessary to make this work again.

Hey, thanks for the pull request. I'll take a look at it shortly.


Conversational Memory

opensearch-project/ml-commons#1150
Here's a repo for the conversational plugin! See the README for current state of the project

Still to do in conversational memory:

Security
Deletion ops
Probably more QA
Build against 2.9.0 (Currently 2.8.0 - probably not much needs to change)
Port to pre-2.7 (XContent changed slightly)


Don't send duplicate mark as read calls

Add some bookkeeping to stop sending mark as read for the same msgid over and over
@keybase/react-hackers
cc: @mmaxim

The service ignores most of these anyway if it knows the thread is already fully read. Will be nice though to not have this traffic going on all the time though. Thanks!

Yeah this is just to clean up the logs and traffic
On Wed, Oct 25, 2017 at 8:12 AM Mike Maxim<EMAIL_ADDRESS>wrote:

The service ignores most of these anyway if it knows the thread is already
fully read. Will be nice though to not have this traffic going on all the
time though. Thanks!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/keybase/client/pull/9195#issuecomment-339309619, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAfhU7gKNMUUn-lyTkKIiS_vNHL8wH_Xks5svyWvgaJpZM4QEhWi
.