[Request] Ability to eager load relationship counts

Laravel Version: 5.3.10
PHP Version: 7.0.10

Description:
Currently, you can retrieve the count of related models without having to retrieve the models themselves using withCount(), e.g. for an article that is in multiple categories, you can do:
$article = Article::withCount('categories')->find($articleId);
However where you are auto-loading the article model from your route there is no way to specify that you'd like that count to be included in an eager loading manner, e.g.
routes/web.php
Route::get('/article/{article}', 'ArticleController@show');`

ArticleController.php
public function show(Article $article)
{
    // $article will not contain the categories_count and there is no way to
    // request that it should.
}

You can load the count in the controller
public function show(Article $article)
{
    $article = Article::withCount('categories')->find($article->id);
}

However, that causes the following queries to be run in the background:
// Original query caused by the type hinted model class on the controller callback.
select * from `articles` where `id` = 'e1eebb50-54b2-4b77-81d7-7301ecc65f8f' limit 1

// Query generated by the call to withCount()
select *, (select count(*) from `categories` where `categories`.`article_id` = `articles`.`id`) as `categories_count` from `articles` where `articles`.`id` = 'e1eebb50-54b2-4b77-81d7-7301ecc65f8f' limit 1

Note how the article details are being re-loaded by the second query (redundantly really). Any eager loaded relationships will also be re-queried compounding the issue.
It would be good (within the framework) to be able to either:

specify that the count of a relationship is eager loaded by default, and have the subselect added to the original query when the model is first loaded (suggestions: protected $with = ['count.categories'] or protected $with = ['count(categories)'] or similar
be able to access a count without having to retrieve the whole model (incl. eager loaded relationships) again (Suggestion: $model->getCount('categories'))

I think both of these have their place, and could be supported, although for my use case the former would definitely be the thing I'd want to use.

As an alternative suggestion for specifying eager loading of relationship counts - we could introduce a new model property, e.g.
protected $withCounts = ['categories'];

Might be nicer than "magic" interpretation of count.categories / count(categories) on the existing $with property.

Sorry @leewillis77 but we don't look at requests in this repository's issues :) Here we have bug reports only.
For suggestions and feature requests please use the https://github.com/laravel/internals repo.

@themsaid No worries - I'd missed that note in the contributing doc. I'll head over there!


Spaceship fails to initialize when inside the Tmux

Is there an existing issue for this?

[X] Yes, I have searched the existing issues
[X] Yes, I have checked troubleshooting page

The problem
When running inside the normal terminal window on MacOS everything works fine (MacOS 12.5 M1, iTerm2), but when I start Tmux, it immediately fails to initialize with the following errors. It started fairly recently:
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:source:114: no such file or directory: /Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-denysdovhan-SLASH-spaceship-prompt/lib/utils.zsh
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:115: command not found: spaceship::precompile
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:source:114: no such file or directory: /Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-denysdovhan-SLASH-spaceship-prompt/lib/cache.zsh
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:115: command not found: spaceship::precompile
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:source:114: no such file or directory: /Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-denysdovhan-SLASH-spaceship-prompt/lib/hooks.zsh
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:115: command not found: spaceship::precompile
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:source:114: no such file or directory: /Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-denysdovhan-SLASH-spaceship-prompt/lib/section.zsh
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:115: command not found: spaceship::precompile
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:source:114: no such file or directory: /Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-denysdovhan-SLASH-spaceship-prompt/lib/core.zsh
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:115: command not found: spaceship::precompile
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:source:114: no such file or directory: /Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-denysdovhan-SLASH-spaceship-prompt/lib/prompts.zsh
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:115: command not found: spaceship::precompile
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:source:114: no such file or directory: /Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-denysdovhan-SLASH-spaceship-prompt/lib/cli.zsh
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:115: command not found: spaceship::precompile
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:source:114: no such file or directory: /Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-denysdovhan-SLASH-spaceship-prompt/lib/config.zsh
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:115: command not found: spaceship::precompile
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:source:114: no such file or directory: /Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-denysdovhan-SLASH-spaceship-prompt/lib/testkit.zsh
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:115: command not found: spaceship::precompile
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:119: command not found: spaceship::precompile
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:127: command not found: spaceship::deprecated
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:128: command not found: spaceship::deprecated
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:129: command not found: spaceship::deprecated
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:130: command not found: spaceship::deprecated
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:131: command not found: spaceship::deprecated
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:134: command not found: spaceship::deprecated
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:135: command not found: spaceship::deprecated
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:136: command not found: spaceship::deprecated
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:137: command not found: spaceship::deprecated
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:138: command not found: spaceship::deprecated
/Users/user/Library/Caches/antibody/https-COLON--SLASH--SLASH-github.com-SLASH-spaceship-prompt-SLASH-spaceship-prompt/spaceship.zsh:139: command not found: spaceship::deprecated
prompt_spaceship_setup:36: command not found: spaceship::core::load_sections
prompt_spaceship_setup:36: command not found: spaceship::core::load_sections
zsh: prompt_spaceship_precmd: function definition file not found

Relevant Zsh configuration
# Tmux integration
TMUX_AUTOSTART=false
antibody bundle zpm-zsh/tmux

# Theme
SPACESHIP_PROMPT_ORDER=(
  dir           # Current directory section
  git           # Git section (git_branch + git_status)
  hg            # Mercurial section (hg_branch  + hg_status)
  exec_time     # Execution time
  async         # For Spaceship asynchronous jobs
  line_sep      # Line break
  jobs          # Background jobs indicator
  char          # Prompt character
)
SPACESHIP_RPROMPT_ORDER=(
  time			# Current timestamp
  exit_code     # Exit code section
  user          # Username section
  host			# Hostname section
  rust			# Rust version
  haskell		# Haskell (GHC) version
  venv			# Python venv state
)
SPACESHIP_TIME_SHOW=true
SPACESHIP_PROMPT_ADD_NEWLINE=false
SPACESHIP_CHAR_SYMBOL="ℤ"
SPACESHIP_CHAR_SUFFIX=" "

antibody bundle spaceship-prompt/spaceship-prompt

What is version of Spaceship are you using?
v4.3.2
What is version of Zsh are you using?
zsh 5.8.1 (x86_64-apple-darwin21.0)
What operation system are you running?
MacOS 12.5.1 on M1
Do you use any Zsh framework or plugin manager?
antibody
Which terminal emulator do you use?
iTerm2
Additional information
No response

It looks like some kind of a cache issue. I cleaned up the cache, stopped all zsh processes, rebooted the computer (just in case), and reinstalled everything - it works now without any errors! Sorry for the noise.


Scrollable: Refactor CSS + Other Enhancements

Scrollable: Refactor CSS + Other Enhancements

This update refactors Scrollable and ScrollLock to TS with the latest HSDS conventions.
This is to improve the UI/experience of Article/Content modals in Beacon 2.
CloseButton
Minor UI fixes were made in the CloseButton component
propConnect enhancement
propConnect now automatically registers a component to the internal collection when
instantiated. Previously, we had to do this manually by execution namespaceComponent(...)

Pull Request Test Coverage Report for Build 1393

114 of 114 (100.0%)  changed or added relevant lines in 8 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 1392:
0.0%

Covered Lines:
5466

Relevant Lines:
5466

💛  - Coveralls


Update annotator routes

looks good to me, just one question, we still want to keep the /annotator endpoint for compatibility for now, right?

Sure I can mirror it for now


useHead with scripts, how set html attribute to ="true"

Environment
"dependencies": {
"@vueuse/core": "^9.10.0",
"debounce": "^1.2.1",
"graphql": "^16.5.0",
"graphql-request": "^4.3.0",
"lru-cache": "^7.14.0",
"nodemailer": "^6.8.0"
},
"devDependencies": {
"@types/node": "^18.11.18",
"@typescript-eslint/parser": "^5.33.0",
"@vue/cli-plugin-eslint": "^5.0.6",
"@vue/eslint-config-typescript": "^11.0.0",
"autoprefixer": "^10.4.8",
"nuxt": "^3.2.0",
"typescript": "^4.7.4",
"vue-tsc": "^1.0.24"
}
Reproduction
in nuxConfig.ts in a nuxt 3 project
app: {
head: {
script: [{
hid: 'test',
src: 'https://test.com/test.js',
'data-test': 'true',
}],
}
}
Describe the bug
I need to add a custom data script tag in vue3 which has a html attribute set to 'true', this should render as ="true" but renders as ="".
I can see that this is done intentionally https://github.com/unjs/unhead/blob/main/packages/unhead/src/utils/normalise.ts function normaliseProps line 57.
This behaviour changed from nuxt 3 rc11 to rc12 in a useHead refactor. Before that it worked as expected.
Additional context
No response
Logs
No response

Hey @yvess, thanks for the issue :)
It was changed to this as the HTML spec says that they are equivalent, so we opt for the one that is less verbose.
If you're trying to test if these props are truthy client side you should check they exist and aren't false. Is there a specific package that has this logic or is this your code?
I'm open to changing the logic for data attributes. I'll keep the issue open to gather feedback.

I anybody else has the issue, we currently use a workaround with a NitroPlugin with html.head.push() to add html to the header

@yvess I've fixed this in this PR.
I'll likely introduce this in a 1.1 release soon.

@harlan-zw thanks!


Add AWS cloud deployment.

We need to create an AWS configuration for cloud deploy.
I guess, that terraform is a really good way to create infrastructure.
In this thread we must choose the best way to deploy a cloud app. Currently I'm thinking about creating REST Gateway. But maybe someone would like to choose something else.
This feature is planned for release/3.3.0.

Since you're using containers, ECS can be a good option if you drop the Postgres deployment and use RDS instead. I think Terraform would be a good way to set up both ECS and RDS, but still will require some VPC setup which might be outside the scope of this. Otherwise, the kubernetes version should be compatible with EKS just fine.

@s3rius @gpkc
I used Fastapis_template has created my FastAPI app, and I now want to deploy it to AWS.
What should I do to use ECS or Fargate?
Can you help me, or any example projects? Thank you very much for your help

Hi! This template comes with Dockerfile, and you can easily build an image with your application inside. You can deploy this image easily.

Build the image with docker compose build -f deploy/docker-compose.yaml
Get the image name from docker-compose.yaml.
Create a custom tag for your image. docker tag "previous_name:version"  "myregistry.aws/application-name:version"
Upload the image in Some container registry like Dockerhub or your private one using docker push "myregistry.aws/application-name:version"
Deploy it.

thanks your help
This is the example I am currently running.

According to your statement, can I understand that I need to upload vme_server image to the Dockerhub, and then load this image in AWS through methods such as ECS or Fargate? Do I need to upload the actual docker composite.yml to AWS?
Secondly, I am currently using Postgres. Can I package this database through Amazon RDS

I need to upload vme_server image to the Dockerhub, and then load this image in AWS through methods such as ECS or Fargate

Yes

Do I need to upload the actual docker composite.yml to AWS?

No. It's only for local development.

Can I package this database through Amazon RDS

How can you package through RDS? If you just want to use RDS, please deploy RDS, then configure your application to use it. RDS itself is postgresql compatible.

If I only upload vme_ Server image and do not upload composite.yml.
So how does AWS determine that I need to open Redis, DB, and RMQ services?

@vmjcv
If you're deploying to AWS / ECS, there is no reason to use Dockerhub. Simply upload to AWS ECR (Elastic Container Registry). If you want to use Dockerhub, you'd ideally have to make your images private otherwise others will be able to access them, and then it's extra steps on making AWS be able to access it. To upload to ECR you need to configure your AWS CLI to have access to ECR.
There is no special setting you need to do to your fastapi app in order for it to be usable on AWS ECS. If it runs the webserver with uvicorn then it's pretty much good to go.
Once you do that, then run these steps:

create an ECS cluster, set it as fargate
create a task definition and point it to the image you've uploaded to ECR, also setup any environmental variables your container should have access to, for example secrets. There's other extra settings you need to do here such as ports etc. Also set the task definition as fargate
create an ECS service, use launch type as fargate in compute options, select the task definition you created above, here you need to configure also the network with subnets and such, which you have set up as you create your VPC, and also attach a load balancer to the app if you want to have a fixed URL/domain for it

@vmjcv
如果您要部署到 AWS/ECS，则没有理由使用 Dockerhub。只需上传到 AWS ECR（Elastic Container Registry）。如果您想使用 Dockerhub，理想情况下，您必须将映像设为私有，否则其他人将能够访问它们，然后是使 AWS 能够访问它的额外步骤。要上传到 ECR，您需要将 AWS CLI 配置为能够访问 ECR。
您无需对 fastapi 应用程序进行任何特殊设置，即可在 AWS ECS 上使用。如果它使用 uvicorn 运行网络服务器，那么它就很好了。
执行此操作后，请运行以下步骤：

创建 ECS 集群，将其设置为 fargate
创建一个任务定义并将其指向已上传到 ECR 的映像，并设置容器应有权访问的任何环境变量，例如机密。这里还需要进行其他额外设置，例如端口等。同时将任务定义设置为 fargate
创建一个 ECS 服务，在计算选项中使用启动类型作为 Fargate，选择您在上面创建的任务定义，在这里您还需要配置具有子网等的网络，这些子网等是您在创建 VPC 时设置的，如果您想为它提供固定的 URL/域，还需要将负载均衡器附加到应用程序（负载均衡器需要额外付费，但我认为它包含在免费套餐中）

thanks your help, I will try your approach

@vmjcv It seems you're trying to deploy databases to AWS ECS. That's not a good idea, AWS ECS is better suited for stateless services and databases are obviously stateful. You will lose your data.
Also you're having all of that as a single task definition, which means that when you deploy a new version of your app, you will redeploy everything, and for some time they might even run in parallel (a huge mess) because of rollout strategy. In container orchestrators such as ECS and Kubernetes, the unit of work isn't a container. In kubernetes, it's a pod (so each pod should be a service). In ECS it's a task, so each task should be an independent service. So you should have your app alone in a single task, and that will also allow you to scale it if needed.
I also don't recommend having a "migrator" job in general, because:
1- database migrations aren't generally concurrency-safe. If your migrations are all very simple (alter table and such) then it might not be an issue.
2- your migration might run after your app starts running, meaning your app will start with error

@gpkc
Currently, the database is directly deployed to AWS ECS, but I will replace it with AWS RDS in the future.
My step is just to serve as a basic method for those who will find this problem in the future, and how to actually deploy the project generated by the fastAPI template on AWS

Also you're having all of that as a single task definition, which means that when you deploy a new version of your app,

Can I understand that I need to deploy Redis, RMQ, and DB as separate tasks？


FormView - Revise common input styling

Revises the common input styling.

Before
After

Combo

Date

Radio

Switch

Text Multi

Text Single

Love it. Thank you.


Cleanup

Remove unused legacy files
Add linting script ( yarn lint )

@wise-introvert  Could you please rebase your branch.

@manigedit on it.


Add react-intl components to demo pages

Modified from #163 by @sirrodgepodge

I do not really like the idea of having to create a component to make this not look https://github.com/SUI-Components/rosetta ?

That project is in really early stage. But, react-intl is a mature project and ready for production. So, I think it's best to use react-intl at least for now.

@carloscuatin react-intl actually also incudes some pretty convenient components such as  which takes in a Date object and provides for example "a day ago" or "last year", translated into whatever language is currently active, pretty awesome to not have to deal with that, that's what convinced me to use it.
@somus thanks so much for all your integration work, looks awesome :)


how to find what code of OpenSSL libs we are using

Hi Team,
We all know OpenSSL had a high vulnerability notification on Nov 1 and an updated 3.0.7 library package.
My application is from java and we deploy the same docker etc. I want to find  if any openSSL code in my project needs updates with 3.0.7. Is there any specific functionality for cryptography etc? Please suggest.
I can see
if [ -f "/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2" ] ;then
  mv /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 /tmp/

marking as inactive, will be closed at the completion of 3.4 dev without further input


decompressFromUTF16 returns null

i have compressed a JSON in client side using
LZString.compressToUTF16()
and posted the compressed data to the server and used the C# version of
LZString.decompressFromUTF16()
and got null
after some debugging i found out that the decopression was not complete and stops in these lines
if (dictionary.Count - 1 >= c2)
{
entry = dictionary[c2];
}
else
{
if (c2 == dictionary.Count)
{
entry = w + w[0];
}
else
{
return null;
}
}
any ideas?

You can try doing a byte to byte comparison of the received data before passing it to LZstring. In my experience there often is some kind of transformation on some of the bytes by some browsers: https://github.com/pieroxy/lz-string/issues/92
As you can see here, when this happens without sending data through the browsers, it works: https://github.com/jawa-the-hutt/lz-string-csharp/blob/master/tests/LZStringTests.cs#L152
If you can provide a reproduction without browser transfer that could help, though I personally won't be able to take this on. If you do make a reproduction for it, I can give you pointers.
As for the algorithm, it's doing the same as it's JS counterpart, and fails in the same way by design (silently).


Release Types v3.1.1

Dependencies
Issues of this new version should be done before resolving this issue.
Checklist

[x] Upgrade the application's version.
[x] Add a new version in changelog.
[x] Create a release on the repository.

Done.


The list of neighbors are not updated after healing

Checklist

[X]  I am not using Home Assistant. Or: a developer has told me to come here.
[X] I have checked the troubleshooting section and my problem is not described there.
[X] I have read the changelog and my problem is not mentioned there.

Deploy method
PKG executable
Z-Wave JS UI version
8.21.2
ZwaveJS version
11.6.0
Describe the bug
When I heal the network, the list of neighbors is no longer updated for node 1 (controller).
No matter what devices are really neighbors, the list remains the same.
I'm using a 700 series Razberry pro 7 with the current Firmware(SDK 7.20.0).
To Reproduce
Move a node near the controller and heal the network.
Expected behavior
The controller contains the correct list of neighbors
Additional context
No response

Can be closed. This seems to be an issue of the Razberry 7 with 7.38 FW.


DO NOT MERGE

Test for Big Sur Homebrew Python

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
324 unchanged lines in 23 files lost coverage.
Overall coverage decreased (-3.7%) to 76.672%

Files with Coverage Reduction
New Missed Lines
%

src/main/python/pybuilder/pip_utils.py
1
94.22%

src/main/python/pybuilder/pluginloader.py
1
87.1%

src/main/python/pybuilder/terminal.py
1
75.47%

src/main/python/pybuilder/plugins/python/core_plugin.py
2
89.9%

src/main/python/pybuilder/plugins/python/integrationtest_plugin.py
2
45.45%

src/main/python/pybuilder/plugins/python/unittest_plugin.py
2
81.48%

src/main/python/pybuilder/plugins/core_plugin.py
3
89.74%

src/main/python/pybuilder/plugins/python/coverage_plugin.py
4
51.3%

src/main/python/pybuilder/execution.py
5
91.56%

src/main/python/pybuilder/install_utils.py
5
86.32%

Totals

Change from base Build<PHONE_NUMBER>:
-3.7%

Covered Lines:
4798

Relevant Lines:
6075

💛  - Coveralls


how about video reconstruction

Hi,
did you try this method to reconstruct a HDR video from a LDR video? Is it possible? thanks.
one thing is that for the typical video revolutions such as  720p (1280720) and 1080p (19201080), the size is not multiple of 32, there might be issue for the image resize.

Hi! Yes, I have tried that, reconstructing frame by frame. It works fine in some sequences, for example when you have some motion (fire, etc.). However, if you have saturated areas that do not move between frames, you can get a reconstruction that changes from one frame to the other due to small changes in the pixel intensities. Extending the method to handle video without temporal inconsistencies would be an interesting topic for future work.

hope to soon see your new achievement to resolve the video reconstruction issues, :)

from video perspective, the format is usually YUV, while looks that this model accepts RGB format. Is there a way to let the model accept YUV format? thanks.

The trained parameters are for RGB, so you will have to convert the reconstructed images for video encoding. Alternatively, you can use the training script to learn reconstruction in a different color space. In that case, you will have to make sure to use a direct pixel-wise loss instead of the default illuminance/reflectance separated loss (set the flag --sep_loss=false), since the separated loss relies on converting RGB to illuminance + reflectance.


Parse extrude and altitude mode

For simple geometries, set extrude and altitudeMode properties.
For multi-geometries, set extrude and altitudeMode array properties.
Properties of Polygon are handled, but not the ones of LinearRing.
ol.geom.Geometry now inherits from ol.Object.

The PR is ready for review.

@elemoine, I addressed your concern.

I've added a new comment, but otherwise looks good to me.

All the comments were addressed, please merge.


feat: remove frontend for bin deletion

The frontend for deleting a bin confuses people more than it helps them,
multiple report of people asking both "what this token is" and "how do I
remove a bin" shows that the current frontend to delete a bin is not
practical enought. The feature have been removed in the frontend so
people are no more confused. The backend API stays as there are other
frontend (e.g. the discord bot) that uses it without problem.
Partial revert of 7e45897ef00b4130a210cca818545647a4a56a01

At least we tried something 😅


Question foundations/question-099.md needs changes

Describe the issue

There is a duplicated alternative in this question
One of these options should be removed or maybe changed to:

[ ] Close and remove

or another option you consider more appropriated

Confirmed, @CamiCasus

I recommend you replace one of the dups with an alternative here  if you are comfortable creating a PR.

@CamiCasus To be clear, you are free to create a PR. I could create a PR, but the last time I have inadvertently stomped on your PR (sorry!), so this is your opportunity to contribute and up your GitHub stats. :)

Don't worry @rilindo, ok tomorrow I'll make a pull request with the change in the question, thanks


Page outdated for Visual Studio 2022 .Net Projects

This page seems to be outdated for .Net 6 projects under Visual Studio 2022. At least the large graphic showing the project properties is different than what I'm seeing on my .Net 6 console app. It would be nice if there were a link to the other format so I could follow along better. MS info relating to the new format is a bit scanty:
https://devblogs.microsoft.com/visualstudio/revamped-project-properties-ui/

Regards,
John Linstrum

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

ID: 4938a042-e5db-4f9c-2288-930b904e888c
Version Independent ID: 6db1e386-22e4-4940-cc2c-bdeaa5883299
Content: Change the build output directory - Visual Studio (Windows)
Content Source: docs/ide/how-to-change-the-build-output-directory.md
Product: visual-studio-windows
Technology: vs-ide-compile
GitHub Login: @ghogen
Microsoft Alias: ghogen

@jlinstrum
Thanks for pointing that out. I'm updating the image now.


Support for other stable branches (2.x and 3.x)?

It appears that opencv is now maintaining 3 branches (https://opencv.org/releases/): 4.x, 3.x and 2.x.
My group has code mostly written for 3.x and when I upgraded to 4.x we hit some incompatibilities.
I realize you have older packages for 3.x, but since these branches are actively maintained it would be super helpful if you could have wheels for all the actively maintained versions of opencv.

The 2.x branch is pretty much legacy stuff. It would require most likely a full rewrite of the build pipeline to be able to support it and that's not going happen.
I can most likely release 3.4.x minor versions if the build scripts work without major changes. To my understanding these minor releases are mostly focused on bug fixes and most of the active development has moved to 4.x branch.
I think that the incompatibilities between 3.4.x and 4.x are currently pretty minor. If you wish to use new upcoming OpenCV features you should create a plan to migrate to the latest 4.x version.

Mmm, well a simple function like Contours changed significantly from version <IP_ADDRESS> to <IP_ADDRESS>:
In <IP_ADDRESS>
a, contours, hierachy= cv2.findContours(thresh,cv2.RETR_CCOMP,cv2.CHAIN_APPROX_SIMPLE)
Needs to be <IP_ADDRESS>
contours, hierachy= cv2.findContours(thresh,cv2.RETR_CCOMP,cv2.CHAIN_APPROX_SIMPLE)
That may seem minor, but it's a giant headache if your codebase is large and the debugging messages are not that helpful like it's been my experience with opencv
Please let me know when/if you are able to release a 3.4.6 version.
I will try using the package you have for <IP_ADDRESS> which supports python 3.7

@skvark  I think a topic branch with a tagged commit at the end is the optimal solution maintenance-wise.
Basically the same that you do for any other release but don't merge it to master.

That sounds good 👍

I would add +1 to having releases from 3.4.x branch to be published, if that's not too much trouble. I noticed incompatibilities in feature_2d detectors and descriptors between <IP_ADDRESS> and 4.1.0 which prevent me from switching to 4.1.x, but having bug fixes from 3.4.x branch would be quite helpful.

3.4.x releases will be published once I get all the builds working. There's now a new branch https://github.com/skvark/opencv-python/tree/3.4 which tracks OpenCV 3.4.x.

Note that if you create long-term branches, you'll need to backport all commits to them. That's why I suggested one-off topic branches.

The branches do not differ too much so it should be quite easy to keep them in sync.

3.4.6 wheels will be available soon: https://pypi.org/project/opencv-python/<IP_ADDRESS>/
3.4.7 will be released after that.

Thanks a lot! I'll give it a try


REQUEST: move wiki to md

Does anyone know an easy way to grab all of the wiki and move it to one or more md files? I would like to create a Documentation folder off the root and put the current wiki in a Template10.1 subfolder.

/Documentation/Template10.1/{files}

Anyone in @Windows-XAML/template-10-developer-community care to take this on?
PS: my goal will be to disable wiki once we have this worked out. Moving the docs to a pull request-model is going to keep things simpler for me, even if it slows down updates a little.

The wiki is already avail as MD files in a git repos located here https://github.com/Windows-XAML/Template10.wiki.git
It's simple enough to checkout and move to a folder structure.

I can help with this.

I get a 404 error on that link. https://github.com/Windows-XAML/Template10.wiki
As a consumer of Template 10 I'd like to see the documentation remain in the Wiki. It seems easier to organize. And easier for a documentation maintainer. Hopefully there is a mechanism for maintaining the Wiki with pull requests.
And hopefully sometime in the future GitHub will make the Wiki searchable.

Hi @jhalbrecht the link is provided from the wiki page below the right nav menu. I was able to clone it in VS.

Hi @calloncampbell, gret info. I look forward to your Pull Request.

Guess I missed your point, I hear you now. I thought you were providing an answer to Jerry's question re pulling .md files for the wiki. I'm glad to know how to modify the wiki with a pull request rather than just editing for some other projects - thanks for sharing that.

I like https://readthedocs.org. It supports compiling markdown from source.


Html publisher plugin report title on v1.13

New feature has been added in html publisher plugin that allows user to specify title for html files shown in the build html publisher doc. A new property called reportTitles added in the html publisher plugin. In this pull request, new property is added to dsl plugin, so that users uses html publisher can make use of new feature

Thanks!!


improve type flow

I mentioned in https://github.com/felixmariotto/three-mesh-ui/pull/31#issuecomment-647913931 we could make the types better in plain JS.
This refactors mixins and adds JSDoc comments so that property and method types flow from the base classes to the subclasses.
Now you can be in a subclass and run Go to Definition on a method from a base mixin in VS Code, for example.
WIP, the build needs to be updated (f.e. it doesn't handle class field syntax)

This is still better than before: the shape of the code base is the same, for the most part, just that the mixin pattern was modified so that type information flows through the code base (try it out in any editor with TypeScript support, VS Code is the best).

What I suggest is, take the improvement, but if you want to refactor things to make them fit a more compositional pattern, you definitely can still do it, and with or without this pull request, you will still be starting from the same code structure as before (just with or without type intellisense).

In my opinion intellisense and type safety are worth it. That's what this PR added.

Sorry to get this PR back to life, but after diving a bit more into this library, I just want to share some feelings about it.
I won't say that class InlineBlock extends mix.withBase( Object3D )( InlineComponent, BoxComponent, InlineManager, ... ) is either bad nor good. But im clearly not used to.
I started to use this library in october. Already dived at that time, but I stopped asap. Because that code part completely confuse my IDE. I don't know if this is a good habit, but I usually rely A LOT on my IDE ( autocomplete to see methods/properties, navigate from class to inheritance, object structure, etc.... ).
RTFM instead ? Of course, but I wasn't trying to understand how to use it, but rather how I could have "alternative uses" of this library by knowing how its core works.
On october, I was on production, so I didn't want to be mentally overloaded by a new library structure. I already had production issues/problems to solve, and I prefered to stay focus on them.
Now production is on hold during vacations and I had time to dive again, and thanks to my human abilility skills to adapt (Im looking at you IDE!), I succeed to workaround my IDE being confused.
Even it this wasnt too difficult, I could still say that I would be glad to fully rely again on my IDE.
Im neither asking nor proposing some refactors here, but I agree with @trusktr on some points.
The current codebase is not totally IDE friendly, maybe #101 would help to use this library. But not sure it will help to dive into it. Which might even not be an issue.

Well... class InlineBlock extends mix.withBase( Object3D )( InlineComponent, BoxComponent, InlineManager, ... ) is something I personally hate, together with this mix module.
Originally the components where built like this :
import BoxComponent from './core/BoxComponent.js';
import InlineManager from './core/InlineManager.js';
import MeshUIComponent from './core/MeshUIComponent.js';
import MaterialManager from './core/MaterialManager.js';

export default function Block( options ) {

	const block = Object.assign(
		Object.create( new Object3D ),
		BoxComponent(),
		InlineManager(),
		MaterialManager(),
		MeshUIComponent()
	);

Which was really straightforward and standard and used javascript's native features.
I have regretted merging the PR from @trusktr that converted to ES6 classes but created this workaround, and I am planning to revert the changes at some point (which is a lot of work given the number of changes).
I am completely biased on this because in contrast with you two I barely use any of my IDE's features, as I perceive them to be "in the way", and also prefer to force my brain to learn by looking up the doc.

Composition over Inheritance

Don't get me wrong, Im not asking for adding complexity in order to ease my IDE :)
When reading such code as TextManager.js :
export default function TextManager( Base = class {} ) {
    return class TextManager extends Base {

Im clueless at first sight of which class is Base. My IDE cannot help me here neither.
What differs from my IDE, is that, as human, I can learn, read additional documentation, or file source in order to understand what is behind.
After 2-3 weeks, I will probably have forget about what I've learned and I will have to learn it again.
Im not even sure you have to choose some way over another in a big picture, and then redo all the library in this way.
ie: Something like TextManager might progressively dissolve itself by slight enhancements, such as FontClass.
In order to be displayable, a TextComponent requires to have a fontFamily property. Depending on what's behind that property can make all the difference.
For now we can have String|Json.
Switching to a FontClass that implements createText(), getGlyphDimensions() , might remove the need of extending/mixing Text with TextManager. It will also simplify checks on TextType. JSDOCking the fontFamily getter property coupled with index.ts will show a crystal clear path for both human and IDE.
Once again, Im not pushing for FontClass right now. Just used it to illustrate the point that Im not asking for more complexity, rather the opposite.  And it doesn't have to be brutal changes, neither overloading your with numerous changes.

@swingingtom If you have TypeScript installed in your editor, the line
@template {!Constructor<import('three').Object3D>} T

shows you exactly that Base extends from Object3D, and if you hover or try to autocomplete any methods of Object3D, you'll see the tooltips or autocompletion UI.
That information is not missing, and is fully visible to TypeScript (and to you in the JSDoc comment right above).

There's no way this can be worse than before: because before, there was no type intellisense, and knowing what methods were available on this required opening other files and manually piecing it together.
In my opinion, this PR is better than the code that it requests to merge into, as types are much more clear now.
However, the code could also be refactored to use composition (I did not add or remove composition in this PR, I merely improved the existing inheritance).
It is totally fine if you all want to refactor the code to use composition, and if you do, I would recommend that the result should be type-aware.
Again, i did not do anything in this PR except make the existing inheritance clear. By all means, switch to composition, and don't accept the type awareness of this PR. Until you make that switch, the inheritance that currently exists will not be type safe.

Composition over Inheritance

I've read plenty of composition over inheritance articles. Nothing new for me.
Just one more time so it is clear: the only thing I did in this PR is make the existing inheritance clear and type safe.
I 100% support if you want to refactor to use composition, but that's really entirely separate from what this PR does.

Happy holidays! 🎇 😊

With a bit less holidays now, happy holidays too !

It is time! I will soon be continuing to improve on this lib using a fully-typed code base over at https://github.com/lume/three-mesh-ui, and then will be converting the classes into Custom Elements for use in LUME, f.e. <lume-text>, etc, so it has a reactive/declarative API compatible with React, Vue, Svelte, Solid, etc.

FWI @swingingtom is working on a massive update: https://github.com/felixmariotto/three-mesh-ui/pull/223

and then will be converting the classes into Custom Elements for use in LUME, f.e. , etc, so it has a reactive/declarative API compatible with React, Vue, Svelte, Solid, etc.

You mean that you want to do that in LUME not in three-mesh-ui right ?


Added 'cakebrew'

Added 'cakebrew' to Installomator and Labels.

Thank you, it has been included in latest dev 0.5.


perf(storage): upgrade foyer to spawn fetch block in dedicated runtime

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Try to reduce foyer hybrid cache latency.
https://github.com/MrCroxx/foyer/pull/557

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

Thanks for the quick PR. Shall we test this and confirm this is the root cause of the latency issue before merging?

Thanks for the quick PR. Shall we test this and confirm this is the root cause of the latency issue before merging?

Yep, I'm building the docker for it. Let me convert the PR to draft first.

p90 main vs pr

p99 main vs pr

Looks works.

LGTM. Do we need to release foyer 0.9.3 for this feat?

Yep. Let me merge the PR in the foyer side and bump version.

@wangrunji0408 RJGG, need fn handle(&self) -> &Handle for Runtime in madsim. 🥵

GG

RUST_BACKTRACE=1 RUST_LOG=INFO ./risedev sslt --profile ci-sim -- --kill-rate=1.0 --kill "e2e_test/streaming/**/*.slt"

2022-05-03T20:19:33.885569Z ERROR risingwave_storage::hummock::event_handler: LocalInstanceGuard Drop SendError error=channel closed table_id=1 instance_id=6
2022-05-03T20:19:33.885569Z ERROR risingwave_storage::hummock::event_handler: LocalInstanceGuard Drop SendError error=channel closed table_id=5 instance_id=5
2022-05-03T20:19:33.885571Z ERROR node{id=11 name="compute-3"}:task{id=1542}: risingwave_stream::task::stream_manager: actor exit with error actor_id=13 error=Executor error: exchange channel from remote upstream actor 16 closed unexpectedly: gRPC request failed: Unknown error: error reading a body from connection: broken pipe
2022-05-03T20:19:33.885572Z  WARN node{id=5 name="meta-2"}:task{id=130}: risingwave_meta::barrier::rpc: get error from response stream node=WorkerNode { id: 4, r#type: ComputeNode, host: Some(HostAddress { host: "<IP_ADDRESS>", port: 5688 }), state: Running, parallel_units: [ParallelUnit { id: 2, worker_node_id: 4 }, ParallelUnit { id: 3, worker_node_id: 4 }], property: Some(Property { is_streaming: true, is_serving: true, is_unschedulable: false }), transactional_id: Some(2), resource: Some(Resource { rw_version: "1.9.0-alpha", total_memory_bytes:<PHONE_NUMBER>84, total_cpu_cores: 2 }), started_at: Some(1651609140) } err=gRPC request to stream service failed: Unknown error: error reading a body from connection: broken pipe
2022-05-03T20:19:33.885572Z  INFO node{id=5 name="meta-2"}:task{id=130}: risingwave_meta::barrier::rpc: no inflight barrier no node. Ignore error node=WorkerNode { id: 4, r#type: ComputeNode, host: Some(HostAddress { host: "<IP_ADDRESS>", port: 5688 }), state: Running, parallel_units: [ParallelUnit { id: 2, worker_node_id: 4 }, ParallelUnit { id: 3, worker_node_id: 4 }], property: Some(Property { is_streaming: true, is_serving: true, is_unschedulable: false }), transactional_id: Some(2), resource: Some(Resource { rw_version: "1.9.0-alpha", total_memory_bytes:<PHONE_NUMBER>84, total_cpu_cores: 2 }), started_at: Some(1651609140) }
2022-05-03T20:19:33.885574Z ERROR node{id=9 name="compute-1"}:task{id=1564}: risingwave_stream::task::stream_manager: actor exit with error actor_id=19 error=Executor error: exchange channel from remote upstream actor 4 closed unexpectedly: gRPC request failed: Unknown error: error reading a body from connection: broken pipe
2022-05-03T20:19:33.885574Z ERROR node{id=11 name="compute-3"}:task{id=2184}: risingwave_stream::task::stream_manager: actor exit with error actor_id=21 error=actor exited unexpectedly

Backtrace:
   0: anyhow::error::<impl anyhow::Error>::msg
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/anyhow-1.0.86/src/error.rs:83:36
   1: risingwave_stream::executor::actor::Actor<C>::run_consumer::{{closure}}
             at ./src/stream/src/executor/actor.rs:217:39
   2: <tokio::future::maybe_done::MaybeDone<Fut> as core::future::future::Future>::poll
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/future/maybe_done.rs:62:56
   3: risingwave_stream::executor::actor::Actor<C>::run::{{closure}}::{{closure}}::{{closure}}
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/macros/join.rs:126:24
   4: <tokio::future::poll_fn::PollFn<F> as core::future::future::Future>::poll
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/future/poll_fn.rs:58:9
   5: risingwave_stream::executor::actor::Actor<C>::run::{{closure}}::{{closure}}
             at ./src/stream/src/executor/actor.rs:170:17
   6: <tokio::task::task_local::TaskLocalFuture<T,F> as core::future::future::Future>::poll::{{closure}}
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/task/task_local.rs:391:31
   7: tokio::task::task_local::LocalKey<T>::scope_inner
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/task/task_local.rs:217:19
   8: <tokio::task::task_local::TaskLocalFuture<T,F> as core::future::future::Future>::poll
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/task/task_local.rs:387:19
   9: risingwave_expr::expr_context::expr_context_scope::{{closure}}
             at ./src/expr/core/src/expr_context.rs:35:65
  10: <tokio::task::task_local::TaskLocalFuture<T,F> as core::future::future::Future>::poll::{{closure}}
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/task/task_local.rs:391:31
  11: tokio::task::task_local::LocalKey<T>::scope_inner
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/task/task_local.rs:217:19
  12: <tokio::task::task_local::TaskLocalFuture<T,F> as core::future::future::Future>::poll
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/task/task_local.rs:387:19
  13: risingwave_stream::executor::actor::Actor<C>::run::{{closure}}
             at ./src/stream/src/executor/actor.rs:178:10
  14: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-util-0.3.30/src/future/future/map.rs:55:37
  15: <tokio::task::task_local::TaskLocalFuture<T,F> as core::future::future::Future>::poll::{{closure}}
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/task/task_local.rs:391:31
  16: tokio::task::task_local::LocalKey<T>::scope_inner
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/task/task_local.rs:217:19
  17: <tokio::task::task_local::TaskLocalFuture<T,F> as core::future::future::Future>::poll
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/task/task_local.rs:387:19
  18: await_tree::root::TreeRoot::instrument::{{closure}}
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/await-tree-0.2.1/src/root.rs:43:34
  19: <futures_util::future::either::Either<A,B> as core::future::future::Future>::poll
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/futures-util-0.3.30/src/future/either.rs:109:32
  20: core::ops::function::FnOnce::call_once
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/core/src/ops/function.rs:250:5
  21: tokio_metrics::task::instrument_poll
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-metrics-0.3.1/src/task.rs:2530:15
  22: <tokio_metrics::task::Instrumented<T> as core::future::future::Future>::poll
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-metrics-0.3.1/src/task.rs:2430:9
  23: <tokio::task::task_local::TaskLocalFuture<T,F> as core::future::future::Future>::poll::{{closure}}
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/task/task_local.rs:391:31
  24: tokio::task::task_local::LocalKey<T>::scope_inner
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/task/task_local.rs:217:19
  25: <tokio::task::task_local::TaskLocalFuture<T,F> as core::future::future::Future>::poll
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.37.0/src/task/task_local.rs:387:19
  26: madsim::sim::task::Spawner::spawn_inner::{{closure}}::{{closure}}
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/madsim-0.2.29/src/sim/task/mod.rs:638:28
  27: <async_task::runnable::Builder<M>::spawn_local::Checked<F> as core::future::future::Future>::poll
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.4.0/src/runnable.rs:455:26
  28: async_task::raw::RawTask<F,T,S,M>::run
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.4.0/src/raw.rs:563:17
  29: async_task::runnable::Runnable<M>::run
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.4.0/src/runnable.rs:782:18
  30: madsim::sim::task::Executor::run_all_ready::{{closure}}
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/madsim-0.2.29/src/sim/task/mod.rs:280:59
  31: std::panicking::try::do_call
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/std/src/panicking.rs:552:40
  32: std::panicking::try
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/std/src/panicking.rs:516:19
  33: std::panic::catch_unwind
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/std/src/panic.rs:146:14
  34: madsim::sim::task::Executor::run_all_ready
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/madsim-0.2.29/src/sim/task/mod.rs:280:17
  35: madsim::sim::task::Executor::block_on
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/madsim-0.2.29/src/sim/task/mod.rs:240:13
  36: madsim::sim::runtime::Runtime::block_on
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/madsim-0.2.29/src/sim/runtime/mod.rs:129:9
  37: madsim::sim::runtime::builder::Builder::run::{{closure}}::{{closure}}::{{closure}}
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/madsim-0.2.29/src/sim/runtime/builder.rs:141:35
  38: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/std/src/sys_common/backtrace.rs:155:18
  39: std::thread::Builder::spawn_unchecked_::{{closure}}::{{closure}}
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/std/src/thread/mod.rs:528:17
  40: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/core/src/panic/unwind_safe.rs:272:9
  41: std::panicking::try::do_call
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/std/src/panicking.rs:552:40
  42: std::panicking::try
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/std/src/panicking.rs:516:19
  43: std::panic::catch_unwind
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/std/src/panic.rs:146:14
  44: std::thread::Builder::spawn_unchecked_::{{closure}}
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/std/src/thread/mod.rs:527:30
  45: core::ops::function::FnOnce::call_once{{vtable.shim}}
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/core/src/ops/function.rs:250:5
  46: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/alloc/src/boxed.rs:2020:9
  47: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/alloc/src/boxed.rs:2020:9
  48: std::sys::pal::unix::thread::Thread::new::thread_start
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/std/src/sys/pal/unix/thread.rs:108:17
  49: <unknown>
  50: <unknown>

2022-05-03T20:19:33.885575Z ERROR node{id=9 name="compute-1"}:task{id=1087}: risingwave_stream::task::stream_manager: actor exit with error actor_id=5 error=Executor error: exchange channel from remote upstream actor 9 closed unexpectedly: gRPC request failed: Unknown error: error reading a body from connection: broken pipe
2022-05-03T20:19:33.885576Z ERROR node{id=11 name="compute-3"}:task{id=2185}: risingwave_stream::task::stream_manager: actor exit with error actor_id=22 error=actor exited unexpectedly

thread '<unnamed>' panicked at /home/mrcroxx/github/risingwavelabs/risingwave/src/tests/simulation/src/slt.rs:413:33:
stack backtrace:
   0: rust_begin_unwind
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/core/src/panicking.rs:72:14
   2: risingwave_simulation::slt::run_slt_task::{{closure}}
             at ./src/tests/simulation/src/slt.rs:413:33
   3: risingwave_simulation::main::{{closure}}::{{closure}}::{{closure}}
             at ./src/tests/simulation/src/main.rs:268:84
   4: madsim::sim::task::Spawner::spawn_inner::{{closure}}::{{closure}}
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/madsim-0.2.29/src/sim/task/mod.rs:638:28
   5: <async_task::runnable::Builder<M>::spawn_local::Checked<F> as core::future::future::Future>::poll
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.4.0/src/runnable.rs:455:26
   6: async_task::raw::RawTask<F,T,S,M>::run
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.4.0/src/raw.rs:563:17
   7: async_task::runnable::Runnable<M>::run
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.4.0/src/runnable.rs:782:18
   8: madsim::sim::task::Executor::run_all_ready::{{closure}}
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/madsim-0.2.29/src/sim/task/mod.rs:280:59
   9: std::panicking::try::do_call
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/std/src/panicking.rs:552:40
  10: std::panicking::try
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/std/src/panicking.rs:516:19
  11: std::panic::catch_unwind
             at /rustc/4a0cc881dcc4d800f10672747f61a94377ff6662/library/std/src/panic.rs:146:14
  12: madsim::sim::task::Executor::run_all_ready
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/madsim-0.2.29/src/sim/task/mod.rs:280:17
  13: madsim::sim::task::Executor::block_on
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/madsim-0.2.29/src/sim/task/mod.rs:240:13
  14: madsim::sim::runtime::Runtime::block_on
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/madsim-0.2.29/src/sim/runtime/mod.rs:129:9
  15: madsim::sim::runtime::builder::Builder::run::{{closure}}::{{closure}}::{{closure}}
             at /home/mrcroxx/.cargo/registry/src/index.crates.io-6f17d22bba15001f/madsim-0.2.29/src/sim/runtime/builder.rs:141:35
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
context: node=14 "client", task=719 (spawned at /home/mrcroxx/github/risingwavelabs/risingwave/src/tests/simulation/src/cluster.rs:613:21)
note: run with `MADSIM_TEST_SEED=1717603843457124093` environment variable to reproduce this error

cc @wangrunji0408 Seems something wrong with madsim. This PR run fetch() in the runtime of foyer.

Fixed! Thanks, @wangrunji0408 !!! 🥰


Bypass retry in plugin loading if plugin not found.

Retry doesn't make sense if there is not such plugin.
This patch speeds up test case DockerSuite.TestVolumeCliCreate in issue #19425 .
Signed-off-by: Pei Su<EMAIL_ADDRESS>

I don't think this is right.
We do want to keep retrying it the plugin is not found, it just means it may not be ready yet.
This is important for plugins running in a container + daemon restart.

I agree with @cpuguy83. I don't think we should do this.

I agree, this will lead to weird errors :/
@sillyousu feel free to propose another fix

@sillyousu Thanks for looking into this

Thank you for explanation.


Update otel docker-compose to support seach traces

The new docker-compose example supports search traces. So that we do not need to inspect the otel docker log or wasmhost log to get traceID.

Hey @rovast! This is really great! Code changes look straightforward, but I think we just want to test it to double check things. We're all a bit slammed with work right now so it might be a little bit longer than normal to get you a review, but we'll do it as soon as possible.


Icon Toggle disabled not working

Bugs
What vue-mdc-adapter Version are you using?

^0.14.0

What browser(s) is this bug affecting?

Chromium Version 66.0.3359.181 (Official Build) Arch Linux (64-bit)

What OS are you using?

Linux archlinux 4.16.10-1-ARCH #1 SMP PREEMPT Mon May 21 07:57:23 UTC 2018 x86_64 GNU/Linux

What are the steps to reproduce the bug?

See Codepen: https://codepen.io/perqin/pen/yENOrq

What is the expected behavior?

The toggle is disabled and the icon should not change when clicked.

What is the actual behavior?

The icon still changes between toggle-on and toggle-off though the toggle button is gray.

Any other information you believe would be useful?

@perqin
Looks like an MDCWeb issue. not sure it'll be fixed as IconToggle will be deprecated and replace with a new Icon Button component soon.
will investigate if it is worth doing a quick workarrround or if better to go to new  IconButton ...


Reject packages without a Requires-Python

A problem I've come across many times now is that a package will drop support for an old version and they'll even add a python_requires directive to their setup.py, only to cut a release using an old version of setuptools that doesn't actually understand the python_requires directive and thus silently fails. See, e.g. sphinx. This causes a bunch of problems because the erroneously uploaded packages now pollute pip installs of that package unless they are removed from PyPI or a post release is made.
Since there is no good reason to upload a package without explicitly specifying a Requires-Python directive, I think we can assume that this is an error and reject packages that don't have a Requires-Python.
My recommendation for migrating to the "always throw an error" version:

Start throwing a warning when Requires-Python is missing, with a link to the documentation on how to add Requires-Python
Update twine and all tools that upload packages (and setuptools, even though it's deprecated) to automatically transform that warning into an error overridable by --allow-no-python-requires
Add a backwards-compatibility API that allows you to upload packages without Requires-Python by configuring your upload endpoint to something not the default
Upgrade the warning to an error, dropping support for --allow-no-python-requires.

I think we could swap the order of 2 and 3 pretty easily - I'm guessing that updating the upload tools would be easier to do which is why I put them in this order, but 2 could be implemented in terms of 3.
In terms of time frame, I don't know how aggressive you (the Warehouse team) want to be. I think the first 3 can happen as soon as an implementation is available. It's probably a big ask to have all package maintainers switch over in a relatively short period of time, but I think a long deprecation period will be harmful given that it's likely a large number of packages are going to start dropping support for Python 2 soon, which will probably cause a ton of headaches if people aren't including Requires-Python in their metadata. Maybe a 6 months or so?

Since there is no good reason to upload a package without explicitly specifying a Requires-Python directive, I think we can assume that this is an error and reject packages that don't have a Requires-Python.

One use case would be a package that is compatible (or at least, thinks it's compatible) with all versions of Python. What should this field be for those packages, something like Requires-Python: >0?

Start throwing a warning when Requires-Python is missing, with a link to the documentation on how to add Requires-Python

I don't believe displaying a warning for a successful upload is possible at the moment without making changes to twine and the upload API, but this would probably be a beneficial change to make in general.
Worth mentioning that #726 might help with this a bit, because maintainers would be able to verify that the Requires-Python metadata they set actually made it to PyPI.

@di Yes, agreed that #726 would be very helpful.

One use case would be a package that is compatible (or at least, thinks it's compatible) with all versions of Python. What should this field be for those packages, something like Requires-Python: >0?

Presumably python_requires="*.*" or something like that? >0 would also work, though I really doubt there are any packages out there that actually support Python<2.0 anyway.

don't believe displaying a warning for a successful upload is possible at the moment without making changes to twine and the upload API, but this would probably be a beneficial change to make in general.

Hm. That's a bit of a problem, because half the issue here is that people tend to install setuptools or twine once and then never upgrade it. The people with updated versions of twine and setuptools are the least in need of this change.
Other possible options:

Rolling blackouts as was done for TLS and the PyPI.org transition, skipping the "raise a warning" phase entirely.
Send an e-mail to people who upload new packages without a Requires-Python directive (this might be way more e-mail than can be done safely)
Do some verification to check if the source distribution includes a python_requires directive, but the metadata failed to upload and send an e-mail only to those people (with instructions on how to fix it).
Implement the "warning" as a "fail only the first time" - parse the metadata and if it doesn't contain Requires-Python, hash the payload and store it, then return an error explaining why it failed. Uploading the exact same payload a second time would actually allow the upload to proceed.

If #726 is happening soon, option 4 could be implemented as "if you upload and it doesn't have Requires-Python, you must go through the 2-phase upload process and check a big red box that says, "I don't want my packages to properly advertise its requirements" before allowing it to proceed.

It seems that the other half of this issue is "how can we make sure users update setuptools/twine more often?"

Have it send a header with which tool and version. Slowly refuse upload from old-versions, tools that don't set these headers.

We discussed this today in IRC. It sounds like we do want to do this because -- among other things -- it would help with the new pip resolver rollout https://github.com/pypa/pip/issues/6536 and with stuff @techalchemy has to deal with in Pipenv.
I would love stats on how many projects have, as their most recent release, a project whose metadata has no Requires-Python. Is it possible to get that % or number?
Although it would be really nice to have #726 before implementing this, I'm ok with possibly going ahead and doing it without that feature anyway.

Yea that should be doable, I suspect the number is really low though.

it would help with the new pip resolver rollout

I'm not clear how it would help with the new resolver rollout. Can you clarify?
As far as I am aware, Python-Requires is essentially just another dependency that the resolver (new or old) has to deal with. Mandating it doesn't make any difference to pip (other than meaning that we'll now never have a case of a package with no dependencies, which makes a lot of our tests a little bit unrealistic, albeit not in a way that matters in practice 😉)
I'm a bit worried that this proposal will result in projects setting over-strict constraints (requiring only what they test on and support, for example, when older versions may well still work on a "don't come to us if something goes wrong" basis).

@pradyunsg I think you were in that discussion (in IRC today about Python-Requires) and you seemed actively interested in getting Warehouse to mandate it, but maybe I misread you - could you answer @pfmoore's question? If I misunderstood and we don't particularly need this for the resolver work, please do say so and I'll happily back off.

I'm a bit worried that this proposal will result in projects setting over-strict constraints (requiring only what they test on and support, for example, when older versions may well still work on a "don't come to us if something goes wrong" basis).

Well but if you are an advanced user and really want to get this package on an old Python version you probably can figure it out. Though if you are a new user and pip install foo and it does not work you at a loss. So I would see over-enforcing as better than being too lax.
And the all point of Python-Requires is also exactly for those old-python-users not to install a too-recent version of the package. Mostly I implemented it in Warehouse/PIP because IPython wanted to drop 2.x and couldn't without breaking for old user. I would even expect the opposite of you, and have project to drop support ini CI, break on old python, and forget to update Python-Requires.

As far as I am aware, Python-Requires is essentially just another dependency that the resolver (new or old) has to deal with

I have not been part of some of the discussion about the resolver so pardon me if I'm mistaken.  But, unlike the other dependencies, pip cannot change the current version of Python right ?  Requiring Python-Requires may dramatically reduce the search space of the resolver as the Python version is not a variable. It would even be strange to me if the resolver even knows about Python-Requires, wouldn't you just immediately filter out any package that is incompatible with the current Python and give the resulting set to the resolver ?

I think this is closer to "PyPI should have better, more strict metadata checks" than it is to "would help with the dependency resolver".
It'd nice to have this metadata mandatory for making packages actively consider this question prior to publishing, I don't think this directly affects the new resolver's rollout directly but, like all PyPI metadata stuff, this would have an indirect effect on the resolver.

Requiring Python-Requires may dramatically reduce the search space of the resolver as the Python version is not a variable. It would even be strange to me if the resolver even knows about Python-Requires, wouldn't you just immediately filter out any package that is incompatible with the current Python and give the resulting set to the resolver ?

Exactly this -- and without clean and enforced metadata in many cases we may not know which versions of python the uploader intended for their package to work on. As someone who maintains a tool that might run on python 3 but be asked to resolve dependencies against python 2, for example, it is incredibly useful to know whether a package is intended to work in python 3 or python 2 -- sometimes the act of resolution itself requires that you execute the package and in that case I tend to prefer learning from metadata than during failed execution.
To elaborate a but further, in pipenv we create lockfiles which might be compatible with multiple versions of python.  In an ideal universe, you would be able to, using only one runtime, generate a lockfile with a resolved set of packages for multiple versions of python based purely on metadata, simply by reading manifests and including the relevant markers.
And yes, I approach this from the perspective of dependency resolution, but I do also think that having good, robust metadata is important for many reasons.

I don't think this directly affects the new resolver's rollout

Everyone will still have to deal with the world as it is until rules are in place and enforced and there is some useful data to leverage, but my goal when I talk about this is to envision the world as it could be in the future. Just turning the switch on tomorrow won't fix the problem right away, but if we had done it two years ago my life would be significantly easier, even if there were still some old packages without properly populated fields.

my goal when I talk about this is to envision the world as it could be in the future.

Agreed. My point above (which I didn't state well) was that Requires-Python metadata, while useful, can (in the most general sense) only be evaluated at the same time as the other dependency constraints on a package, after we've read the metadata. And making it mandatory doesn't really change that code.
It's true that on PyPI the Requires-Python data is available from the index, and so can reduce the search space - and this is great. But pip (and any other real-world Python resolver) has to handle other indexes, and even local directories containing distribution files. For those, there's no saving and Requires-Python has to be processed in the constraint evaluation phase, not the file selection phase. So we do the check in both places - one for efficiency, the other for correctness.
Don't get me wrong - I'm 100% in favour of better, more strictly enforced, and static metadata. I just don't think having this piece will materially affect how we code the resolver in pip.

But pip (and any other real-world Python resolver) has to handle other indexes, and even local directories containing distribution files.

Ah, thanks I forget to consider this case. Though I'm guessing in these case the number of local packages will be way smaller than PyPI likely...
Warehouse also recently implemented "yank", which I see as a move toward cleaner metadata as you can "yank" packages with incorrect metadata, and publishing crates with incorrect metadata (including Python-Requires)  is part of life, and can be fixed by yank-and publish patch release.
Also I think we can add a step 0 in @pganssle proposal, we can actually get twine and other  packaging tool have warnings even before warehouse does it.

@pfmoore said:

Don't get me wrong - I'm 100% in favour of better, more strictly enforced, and static metadata. I just don't think having this piece will materially affect how we code the resolver in pip.

OK! Thanks for the consensus, pip developers - that helps me know that I should not nudge to try to get this implemented for the resolver work's sake.

The motivating failure mode happened again this week with pyrsistent, impacting many packages that still support Python 2: https://github.com/tobgu/pyrsistent/issues/208


Add ability to use environment variable files

This adds the ability to specify an array of files containing environment variables using Docker's '--env-file' option when running a container. The actual files containing the environment variables are assumed to exist.
docker::run { 'foo':
env_file => ['/etc/foo.env', '/etc/bar.env']
}

+1.  I need to pass in environment variable contents with spaces in it (see https://gist.github.com/lcarstensen/0bae93f196f06232074f for use case) and where that fails today this  PR also addresses that use case.

@mweigel thanks for this, a really useful addition. and thanks to @lcarstensen for testing it out. Much appreciated.


[MM-27198] Add in product notices

Summary

Add in product notices modal
API call for fetching notices is done

On load of webapp
On first socket reconnect for the day

Use Generic modal for displaying notices
Clear data of notices locally when modal is dismissed so when new data is fetched modal will again be mounted.
Mark a notice as read

First notice is always marked as read on load of modal
Other notices are marked as read when user navigates to that notice by clicking on next button of notice.

Add system console settings for enabling/disabling admin notices and user notices

Ticket Link
https://mattermost.atlassian.net/browse/MM-27750
Related Pull Requests
https://github.com/mattermost/mattermost-redux/pull/1234

Need to change branch name, new PR at https://github.com/mattermost/mattermost-webapp/pull/6448


Video Quality and Color Change

Firstly thanks for this program.
I record the screen with 100% quality setting, but the video quality decreases and the colors change.

Captura v8.0.0
Windows 10 TR x64
Intel i5 760
AMD Radeon HD 6870
4 GB DDR3 Ram
ffmpeg version git-2020-02-11-f15007a

Color space(YUV BT.601, YUV BT.709, etc) difference between source image and Video Frame Decode image is suspicious, I think.

I downloaded and installed Lagarith Lossless Video Codec from https://lags.leetcode.net/codec.html
I recorded test video with Captura v8.0.0 SharpAvi / Lagarith.
Test is OK. The recording quality is better and the color change is less.
But when I try to record with Captura v9.0.0-beta4 with Lagarith codec, an error occurs.
An Error Occured:
Error calling wrapped encoder.

Captura v0.0.3502.0
OS: Microsoft Windows 10 Home Single Language|C
64-bit OS
64-bit Process
4 processor(s)
Name: Intel(R) Core(TM) i5 CPU         760  @ 2.80GHz
NumberOfCores: 4
NumberOfLogicalProcessors: 4
Name: Fiziksel Bellek
Capacity:<PHONE_NUMBER>
Name: AMD Radeon HD 6800 Series
AdapterRAM:<PHONE_NUMBER>
Desktop: {X=0,Y=0,Width=1920,Height=1080}
Screen: \.\DISPLAY1: {X=0,Y=0,Width=1920,Height=1080}
Mic: Mikrofon (Realtek High Definition Audio)
Speaker: Hoparlör (Realtek High Definition Audio)
System.Reflection.TargetInvocationException: Error calling wrapped encoder. ---> System.InvalidOperationException: No compatible MPEG-4 encoder found.
at SharpAvi.Codecs.Mpeg4VideoEncoderVcm..ctor(Int32 width, Int32 height, Double fps, Int32 frameCount, Int32 quality, FourCC[] codecPreference)
at SharpAvi.Codecs.EncodingStreamFactory.<>c__DisplayClass2_0.b__0()
at SharpAvi.Codecs.SingleThreadedVideoEncoderWrapper.<>c__DisplayClass15_01.<DispatcherInvokeAndPropagateException>b__0()    --- End of inner exception stack trace ---    at SharpAvi.Codecs.SingleThreadedVideoEncoderWrapper.WrapAndRethrowException(Exception wrappedException)    at SharpAvi.Codecs.SingleThreadedVideoEncoderWrapper.DispatcherInvokeAndPropagateException[TResult](Func1 func)
at SharpAvi.Codecs.SingleThreadedVideoEncoderWrapper..ctor(Func1 encoderFactory)    at SharpAvi.Codecs.EncodingStreamFactory.AddMpeg4VideoStream(AviWriter writer, Int32 width, Int32 height, Double fps, Int32 frameCount, Int32 quality, Nullable1 codec, Boolean forceSingleThreadedAccess)
at Captura.Models.AviWriter.CreateVideoStream(Int32 Width, Int32 Height)
at Captura.Models.AviWriter..ctor(String FileName, AviCodec Codec, IImageProvider ImageProvider, Int32 FrameRate, IAudioProvider AudioProvider)
at Captura.Models.SharpAviItem.GetVideoFileWriter(VideoWriterArgs Args)
at Captura.ViewModels.RecordingModel.GetVideoFileWriterWithPreview(IImageProvider ImgProvider, IAudioProvider AudioProvider, RecordingModelParams RecordingParams)
at Captura.ViewModels.RecordingModel.SetupVideoRecorder(IAudioProvider AudioProvider, RecordingModelParams RecordingParams, IMouseKeyHook MouseKeyHook)

View Details

System. Reflection. TargetlnvocationException
Message
Error calling wrapped encoder.
Stack Trace
at SharpAvi.CodecsSingIeThreadedVideoEncoderWrapper.WrapAndRethrowException(Exception wrappedException)
at func)
at SharpAvi.Codecs.SingIeThreadedVideoEncoderWrapper..ctor(Func'I encoderFactory)
at SharpAvi.Codecs.EncodingStreamFactory.AddMpeg4VideoStream(AviWriter writer, Int32 width, Int32 height Double fps Int32 frameCount, Int32 quality, Nullable•l codec Boolean forceSingIeThreadedAccess)
at Captura.ModeIs.AviWriter.CreateVideoStream(Int32 Width, Int32 Height)
at Captura.ModeIs.AviWriter..ctor(String FileName, AviCodec Codec Ilmageprovider Imageprcwider, Int32 FrameRate, IAudioProvider AudioProvider)
at Captura. Models.SharpAviItem .GetVideoFiIeWriter(VideoWriterArgs Args)
at Captura.ViewModeIs.RecordingModeI.GetVideoFiIeWriterWithPreview(IImageProvider ImgProvider, IAudioProvider AudioProvider, RecordingModeIParams Recordingparams)
at Captura.ViewModeIs.RecordingModeISetupVideoRecorder(IAudioProvider AudioProvider, RecordingModeIParams Recordingparams, IMouseKeyHook MouseKeyHook)
Target Site
Void WrapAndRethrowException(System.Exception)
Source
SharpAvi
HResuIt
-2146232828

@akcansoft Set the color space to rgb24 solves this problem. YUV color space is not suitable for capturing screen.
You can download a modified version of Captura v8.0.0 with only rgb24 color space is added.
https://github.com/SadPencil/Captura/releases/tag/v8.0.0-mod

@SadPencil Do you have a plan to create PR?

@SadPencil Do you have a plan to create PR?

I can't. This modification only works on release-v8.0.0, not on the latest master branch.


Patch not present

Fix #7

Coverage remained the same at 100.0% when pulling 9205809bcdfa9ce2e714155356942b081d886504 on patch-not-present into 895af5d688d575cdafcbb8a2adddb27fa8d41785 on master.


Return early to avoid divide by zero in degenerate case.

Had to make the 0 check very close to the use so clang-analyzer saw it.  Clang-analyzer zero divide case doesn't trigger now.

[approve ci clang-analyzer]


WIP: Updating contributing.md with new driver submission process

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

Closing - Confirmed with Brian that this is dupilicative.


Latest versionfeature

ARM API Information (Control Plane)
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[x] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month. [July]
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month. [July]
By default, Azure SDKs of all languages (.NET/Python/Java/JavaScript for both management-plane SDK and data-plane SDK, Go for management-plane SDK only ) MUST be refreshed with/after swagger of new version is published. If you prefer NOT to refresh any specific SDK language upon swagger updates in the current PR, please leave details with justification here.

Contribution checklist (MS Employees Only):

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[x] Check this box if any of the following apply to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[x] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki. Note that this doesn't apply if you are trying to merge a PR that was previously in the private repository.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If you have any breaking changes as defined in the Breaking Change Policy, request approval from the Breaking Change Review Board.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.
NOTE: To update API(s) in public preview for over 1 year (refer to Retirement of Previews)
Please follow the link to find more details on PR review process.

 Please get a breaking changes approval from Azure Breaking Changes Reviewers<EMAIL_ADDRESS>and ARM can review the changes afterwards.
And please also fix the lint errors.
Once you have the approval and address the lint issues, please remove the "ARMChangesRequested" label from the PR to make the PR visible to the ARM reviewers.


单击“解释计划”按钮：Expected a com.google.gson.JsonObject but was com.google.gson.JsonPrimitive; at path $

Description

DBeaver Version
24.0
Operating System
W10
Database and driver
数据库:Mysql 8.0
驱动包：8.20
Steps to reproduce
No response
Additional context
No response

Hello @baojiahui,
I'm unable to reproduce the issue with the following configuration:

It appears to me that it might be a database issue, considering that the query clearly contains the FORMAT=JSON clause.
Can you please confirm that the database is indeed MySQL, not a fork/clone of some sort?

@ShadelessFox  阿里云分布式数据库PolarDB

Please write in English.
You're using a third-party database with MySQL driver and DBeaver's extended support for MySQL, not PolarDB.
For more information, please refer to the PolarDB docs:
https://www.alibabacloud.com/help/en/polardb/polardb-for-oracle/explain-syntax
If you want to request extended support for PolarDB in DBeaver, please submit a new issue.


Preserve edit state without using beforeunload event

Event beforeunload is not universal and UX isn't ideal.
App should preserve edit state in localStorage instead, that's the best UX.
Historically, it was PITA because corrupted localStorage could break an app silently.
But GraphQL nullability pattern solves it ideally.
Therefore, client edit state must be implemented via Relay client extensions. (And I wish there was a compiler rule enforcing strict nullability. As result, no versioning of client scheme, just evolvement. That would be great.)

Client schema landed in Este, but I don't know how to persist in AsyncStorage correctly yet. We need to defer initial app render until data is loaded. And then again on page change, which I am afraid depends on https://github.com/este/este/issues/1524.
The first real useful use case will be Post selectionStart and selectionEnd. It's easy to implement because it's client side only stuff. draftText is much harder, because we need to decide what should be preferred. Client or server value?
extend type Post {
  draftText: String
  selectionStart: Int
  selectionEnd: Int
}


Error running Blazor File.

Problem encountered on https://dotnet.microsoft.com/en-us/learn/aspnet/blazor-tutorial/install
Operating System: windows
Ifound this error encountered on running the blazor file showing this error : Severity	Code	Description	Project	File	Line	Suppression State
Error	NETSDK1045	The current .NET SDK does not support targeting .NET 8.0.  Either target .NET 7.0 or lower, or use a version of the .NET SDK that supports .NET 8.0.	BlazorApp	C:\Program Files (x86)\dotnet\sdk\7.0.203\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets	144

what do you get if you run dotnet --version and dotnet --info @suju2011 ?

Thanks for your responses,but the Error is resolved now it was an
installation issue.
🙂
On Thu, Jan 4, 2024 at 11:11 PM Tomas Weinfurt @.***>
wrote:

what do you get if you run dotnet --version and dotnet --info @suju2011
https://github.com/suju2011 ?
—
Reply to this email directly, view it on GitHub
https://github.com/dotnet/core/issues/9039#issuecomment-1877510103, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AZNKKEKQ376JZF6KCYAZW3DYM3SVTAVCNFSM6AAAAABBLA2GLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXGUYTAMJQGM
.
You are receiving this because you were mentioned.Message ID:
@.***>


make qms autospawn with microbombs

weewoo

wtf

ah makes sense, guess i'll have to update

"Fuck it we ball" merge


Pipeline caching (testing)

/azp run js - core - ci

What about test templates?
Do you have any data on time differences before and after this change?

Closing this issue since the piepline caching is not adding any improvement to the overall performance  in the build/analyze/test tasks. I have added pipeline caching for just the rush install step. It infact adds a few more seconds to each of the tasks.

Reference build without caching where rush install takes 53 secs- https://dev.azure.com/azure-sdk/public/_build/results?buildId=310762&view=logs&j=3dc8fd7e-4368-5a92-293e-d53cefc8c4b3&t=386f29c8-4681-50e7-ecbc-1b877753e479
Reference build with caching where caching step (upload/download) takes 37 sec + rush install 18 sec + Post job 1sec = total 56 sec - https://dev.azure.com/azure-sdk/public/_build/results?buildId=320516&view=logs&j=3dc8fd7e-4368-5a92-293e-d53cefc8c4b3&t=ddb589bb-b41b-569e-cdee-1308e49f7d64


Fixing squid:S1155 - Collection.isEmpty() should be used to test for emptiness

This pull request is focused on resolving occurrences of Sonar rule
squid:S1155 - “Collection.isEmpty() should be used to test for emptiness”.
You can find more information about the issue here:
https://dev.eclipse.org/sonar/rules/show/squid:S1155
Please let me know if you have any questions.
Artyom Melnikov.

On Tue, Jun 14, 2016 at 8:26 AM, Artyom Melnikov<EMAIL_ADDRESS>wrote:

This pull request is focused on resolving occurrences of Sonar rule
squid:S1155 - “Collection.isEmpty() should be used to test for emptiness”.
You can find more information about the issue here:
https://dev.eclipse.org/sonar/rules/show/squid:S1155
Please let me know if you have any questions.
Artyom Melnikov.

Why are you running these rule checks on Ebean (and other libraries)? How
do these Sonor rules affect your productivity or the execution of your
program? I'm wondering what your motivation is and if it's necessary to
create more work for Rob.
/Daryl

Hi Daryl,  He did ask and I said:

Ok.
Please start with a single small pull request first and we will go from there.
Thanks, Rob.

... we have ended up with a bit more than that but it is ok so far.  If it gets a bit much I'll ask him to slow it down or something.  I personally ran the IntelliJ code analytics against this code base a while back but as you know with these types of tools you do get quite a bit of "false positives" which can be problematic.


Allow users to sort based on multiple columns

Users can sort the displayed results by clicking on the column header. When they click on a different column, we're just replacing the sort criteria to be based on the second column. We want to explore allowing users to sort based on multiple columns in this issue. Both ermrestjs and ermrest support sorting based on multiple columns, and we just need to think about the UI/UX.
The following are different phases involved in this task:
Phase 1
We can implement this like how Google Sheets is doing it. We could add a separate button to the right of the "Displaying ..." text called "Sort by" (or some other labels). Clicking on this button would open a popup.
Similar to Google Sheets, in the popup we should allow users to select however many sort columns that they want. We also should allow them to reorder these columns. That's why we're going to use the same react-beautiful-dnd plugin that we're using for array inputs (with the same "+" and "-" icon to add or remove items).
Each item in this draggable list should have the following elements:

A dropdown to select the column. For now, use the reference.columns to populate this dropdown. Make sure to only allow the ones that are .sortable. So (reference.columns.filter((col) => col.sortable).
A radio button to toggle between ascending and descending.

After changing the sort columns, users would have to click on the "submit" button similar to how our other popups work.
The popup should have three buttons:

Reset: Sort based on the default sort (#2153). It should call the same function to sort, but with an empty array.
Cancel: to cancel changing the sort modifier. It should just close the modal.
Apply: to apply the selected sorts. It should call the sort function and close the modal.

Technical details

Use "react-beautiful-dnd": "^13.1.1" for the draggable list.
The button should be added to table-header.tsx component.
You can find an example of how we're calling sort here. So let's say users pick col1 visible column object with "ascending" and col2 visible column with "descending". Calling sort would be something like thisconst ref = reference.sort([{'column': col1.name, 'descending': false}, {'column': col2.name, 'descending': true}]);

update({ updateResult: true }, { reference: ref }, { cause: LogReloadCauses.SORT });

(In our meeting I talked about using col.sortColumns that's not the case. You should just pass the objects like the example above)
For reset sort, like I mentioned above, pass empty array, so const ref = reference.sort([]);

Phase 2 (customization)
When we're done with the changes described above, we want to make sure this feature is customizable. We need to come up with annotations to allow this, but the following are the customization that we could think of:

Given the performance implications, this feature might not be desirable in some deployments or tables. So we should allow data-modelers to turn this feature off for a specific catalog, schema, or table.
Data-modelers should be able to define the list of choices. The choices might not necessarily be just one column, and might be a combination. So we most probably want to allow them to define a similar object as column_order for each item in the list. This would allow us to support sorting based on hidden columns (#1488).
We should limit the number of different sort columns that users can apply.

Phase 3 (Sort indicator)
Our current UI only supports showing sort indicator for a single column. Even if the sort modifier has multiple columns, we're just showing indicator for the first one. We should improve this. This requires more thought

@RFSH
MOM from todays scrum call:

Move the i icon close to the checkbox label as we are explaining more on how the selection and deselection works
On resize of the textarea the controls on the top(i.e the buttons and checkbox) should also move
Tooltip for checkbox and label should not show once an interaction(i.e a click on checkbox) is made.
Also, in facets we are not making the checkbox label also clickable but in github it is clickable. We have to decide whether we should make it consistent with github or the chaise app

Pending items:

Updating the selection on removing form
Above items from the meeting
A bug which I found: On load one form is selected by default, one deselect of that checkbox is in indeterminate state instead of empty with Select All text

@RFSH
I have explored few options more to compare sort range feature similar to google sheets.

Airtable
This is a better option where we can show the sort criteria as a dropdown instead of a Modal. We have a Sort by label on the top and dropdowns for columns and sort order. We also have a search capability in the column dropdown.

https://github.com/informatics-isi-edu/chaise/assets/133336338/bf9eb5ee-3007-41c7-84ce-88fc8bdc2396

Zoho Sheets
This option is very similar to what we have currently. Attaching screenshot for reference.

Microsoft Excel
This opens up a modal for customized sort with dropdowns for columns and sort order.

https://github.com/informatics-isi-edu/chaise/assets/133336338/573a24f6-9205-46b4-a656-351fd0d8f03b
Overall, Airtable option is more feasible as we have pretty much everything what we need in a neat and clean way. Open to suggestions.

We discussed the previous comment. In summary, we think Airtable implementation is the best, and we will borrow that mostly. A more detailed summary of what we talked about is as follows:

Modal vs. dropdown doesn't make any difference on the recordset page, but on the record page, dropdown is easier to understand. A modal for the whole page would be confusing on the record page when it's just changing the sort of one of the related tables.
We should have the same "Sort by" header with an information icon. This is similar to the icon in range pickers, where hovering over it will explain the feature to users.
We don't need the "sort by" or "then by" labels.
The ascending and descending options should be a dropdown. But we didn't like the labels that Airtable is using. Our labels should be based on the column type (In the following, instead of to we should use the fa-solid fa-arrow-right icon).

For date and timestamp: Earliest to latest and Latest to earliest.
For numbers: Min to max and Max to min
For boolean: false to true and true to false (we should use the actual presentation value instead of true/false. You can use the formatBoolean function in input-utils.ts for this).
Other types: A to Z and Z to A.

Unlike Airtable, we want the drag icon to be on the left. We should continue using the trash icon as well.
Use our secondary style of buttons, "Add another sort" (so with a border).
Use a separator instead of a different background to distinguish the last row in the dropdown. Similar to how we're doing this for the modals.
For the button on the bottom right, let's use our own style and order of buttons.

Things pending for sort task:

dropdown menu for column is hiding below the overlay body
deeplink sort functionality - take the sort criteria from url and apply to the tooltip
Ellipsis tooltip for column dropdown
code cleanup
check for Boolean type column
tooltip going beyond screen in the first render