Added failing test for PHP8 attributes

Description
It seems like PHP8 Attributes are not properly serialized. When serializing a closure that was annotated with attributes, those cannot be received using ReflectionFunction::getAttributes() on the deserialized one (as shown by the test).
At the moment, Laravel does not use any attributes to change route behavior, but I can see this being useful in the future (for an example, see "Motivation"). If this is not intended to be supported, I feel like this should be at least documented in the "Caveats"-section of the Readme.
Motivation
I tried to build a package that does something similar to this closed PR on the laravel framework. Basically you configure a middleware, annotate your controller/closure with an Transactional-attribute, and they will automatically be wrapped in a transaction:
// web.php
Route::get('transactional', #[Transactional] function () {
    $a = User::factory()->create();
    $b = User::factory()->create();

    return [$a, $b];
}

This code works fine during development, but as soon as I run php artisan optimize and the route files are cached, the Transactional attribute disappears, and the function is not wrapped inside a transaction anymore. This is due to the behavior shown in the test.

We don't merge failing PRs, so marking as draft until a fix is provided or @nunomaduro can take a look.

Sure, I did not think of marking this as a draft, this should definitely not be merged as is. I just thought it would be more helpful to provide a failing test, rather than opening an issue (which was also suggested in this comment by nuno).

@NiclasvanEyk Can you try https://github.com/laravel/serializable-closure/tree/feat/function-attributes locally, and see if it solves your problem?

@nunomaduro nice, it seems to work 🎉
I rm -rf'd the laravel/serializable-closure version installed by composer and cloned the git repo instead. On the master branch it does not work after php artisan optimizeing, on the new feat/function-attributes one it does!


pallet-mmr: fix offchain db for sync from zero

MMR nodes are saved in off-chain db under fork-resistant keys based on frame_system::block_hash(), as such only nodes added by latest frame_system::BlockHashCount can be accessed that way.
Nodes added by blocks older than frame_system::BlockHashCount are moved by offchain_worker to "canon" (not fork resistant) location - thus being made available regardless of age.
See https://github.com/paritytech/substrate/pull/11594 for more details.
Issue is that offchain_worker doesn't run for blocks imported during initial sync. So for initial syncs > frame_system::BlockHashCount (practically any node syncing from scratch), MMR nodes aren't moved to canon position and access to them is lost.
Solution proposed by this PR: runtime block execution saves node to both fork-resistant and canon locations:

initial sync nodes directly end up in the right location,
for the rest, we do a superfluous offchain_index::set() because it will be overwritten by offchain_worker with canon values anyway.

@andresilva @svyatonik @serban300 @Lederstrumpf please prioritize reviewing this PR as it fixes a not-yet released pallet-mmr. If we're lucky to catch this fix in the same release as the PR introducing the issue we'll avoid needing offchain db migration.

bot merge


Update wrapper async mode docs

Since sync mode has been removed, many of the wrapper methods now return nextTick, which is async and is awaitable. These methods include setValue, setSelected, setChecked, setData, and setProps. Though these methods are async, the documentation has them referenced/used in a sync fashion. I am not sure if this is intentional or just missed with the sync removal, but the use of these methods seems a bit unclear. Hopefully updating the documentation will allow for clearer use. If there are issues with the examples I have updated (esp. likely on the offshoot examples), please let me know!

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactor
[ ] Build-related changes
[x] Other, please describe: Documentation Update

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:

[x] It's submitted to the dev branch.
[x] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[x] All tests are passing: https://github.com/vuejs/vue-test-utils/blob/dev/.github/CONTRIBUTING.md#development-setup
[x] New/updated tests are included

If adding a new feature, the PR's description includes:

[ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

Hey @AtofStryker,
This indeed seemed like an oversight as I learned when writing up issue #1626. I had intended to make these changes myself tomorrow so I will instead do a quick review to see whether you missed anything. Thanks 🎩

@99linesofcode Sorry for the oversight on my end! It was something that has been bothering me for a while and didn't realize we had an open issue for it. Definitely would appreciate a quick review and would love to collaborate on this if there is anything you would like to change or add.

@AtofStryker not at all. I had intended to start making small contributions here and there as I'm fairly new to the Vue ecosteystem. Glad to see you beat me to the punch 😉
I'll double check everything tomorrow morning and will make any changes necessary (if any). Good night 👋

What are you thoughts on some of the test cases not containing an assertion? I noticed they are left out sometimes and I personally think that they could be made more complete. Especially now that you have wrapped them in test cases.

@99linesofcode It definitely does appear a bit inconsistent at times, but we might want to be careful about adding them. I think the general approach to documentation is to be as descriptive as possible on how to use the API over potentially being prescriptive. We definitely could add some assertions to the testing documentation, but we also don't want to be misleading as to suggesting that these assertions are they way individuals should test their vue components. In other words, it might be best to not include the assertions where they are not needed. But I will defer to @lmiller1990 on this one.
Also, welcome to the community and the Vue ecosystem! We are glad to have you.

@AtofStryker I personally like "complete" tests too, include the setup, test and assertion.

@lmiller1990 Sounds good! It might be a good idea, at a minimum, to include the assertions that @99linesofcode is recommending in this PR. Then in a separate effort, attempt to reorganize the docs? Likely an audit is in place to keep things consistent.

Sounds good... I would not recommend any large reorganizing until we have a good outline. @afontcu should be involved, but I would say this is lower priority - I think we should spend time on the V2 docs first, then re-use the structure and content where possible in these docs, too.
The docs for this lib were written a long time ago by many different people without really any review process, so there is not very much consistency or direction. One thing I like with the V2 docs is there is a clear structure: starting with the topic, simple example, complex example, then a conclusion. There is more focus on how to use the lib, and less on the intricacies of JS, test runners and tooling.

@lmiller1990 most definitely. In the meantime, we can find some low hanging fruit to iron out some inconsistencies that could be problematic to those using the 1.x API. While this was on my mind, I figured it was a good idea to make the wrapper-array consistent with the wrapper API as well as the doc changes proposed here. So I opened #1650 to give the wrapper-array API some love (Not sure how often the wrapper-array API is used). We probably want to do the same there as we do here with the documentation (from the assertions convo, not the restructure :smiley: ). @99linesofcode did you want to take the reins on adding the assertions to the docs?

@lmiller1990, while finding my way around testing vue components, I also stumbled upon your vue testing handbook. That resource proved very viable but I noticed some of the examples are also starting to deviate from the 1.x API.
Do you intend to keep that separate as it is a bit opinionated as to how to handle testing or would it perhaps be an idea to combine it with the v2 documentation?

@AtofStryker definitely. I will focus on reviewing your changes and adding the missing assertions first. If there is anything I could do to help align the examples with v2 of the docs, I will gladly do so. If there is already a PR to track those changes, I will see if I can find it.

@99linesofcode I will rewrite that book and have a v2. I will leave the current edition as v1. I should update that for the current v1 API, actually. I will do this right now.

Should we just merge this as-is then? any other changes needed? Clearly this PR is already making improvements, or do you plan to do more?
Up to you!

@lmiller1990
I've added the requested assertions by opening a PR to @AtofStryker's fork. Not sure if thats the way to go?
That said, adding those extra assertions feels a bit redundant considering we are going to backport the v2 docs. Is there a PR that contains an outline for the preferred structure for the new documentation? Can I just look at the docs that are already there and start a new PR to discuss the overhaul of v1?

I agree it might be a bit redundant if we want to overhaul everything.
Maybe we should try and finish writing the docs for V2 and just backport all of that! I have been doing most of it, any submissions of unwritten content would be great - writing good docs in incredibly tiring.
This is where the new docs were planned: https://github.com/vuejs/vue-test-utils-next-docs/pull/19 and the live version is here: https://vuejs.github.io/vue-test-utils-next-docs/guide/conditional-rendering.html#using-get
If you guys want to help out with docs and want direction, let's plan this a bit. What do you think of this:

finish writing the current V2 docs. There is issues for each unwritten article here https://github.com/vuejs/vue-test-utils-next-docs/issues and some others. I think there is more value in preparing for V2 than improving these docs at this point. For this, I'd recommend posting in the relevant issue in the repo, pinging someone if you want guidance, and writing. It takes around 3-4 hours to write an article for docs in my experience.
when we get V2 docs done, we go through each and write the examples with V1 (they should all be guaranteed to work with V2 already). See what does and doesn't port backwards, and modify those articles to work with V1.
Replacing existing docs with new ones

What do you think? @AtofStryker @99linesofcode ? Having some more people on board to help would be great, I'm doing vue-jest + v1 + v2 + docs and it's a lot to handle! Lucky it's OSS so anyone can help with anything.

@lmiller1990 I would definitely love to help! I think it sounds like a solid plan to replace the existing docs. We just need to be aware of the caveats with 1.x when backporting, but to your point, the examples should be guaranteed to work.

@lmiller1990 Sounds like a plan. Lets continue this conversation in vuejs/vue-test-utils-next-docs#19


Recent releases are tagged with the wrong year

They accidentally use 2022 instead of 2021:

1.12.2 (Apr 08, 2022)
1.12.1 (Apr 05, 2022)

@pitbulk this looks quick to handle and close...


Image Size problem with isotope plugin

Hi,
First very nice plugin :)
I have a problem when i use lazysize in the isotope plugin. The size seems incorrect after lazyloading the picture.
If i use an empty src gif but with the right "width" and "height" args
ex : -img src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==" width="600" height="800" data-src="http://placehold.it/600x800" class="lazyload" >
The size is not correctly interpreted. And the masonry function is broken.
Codepen example : http://codepen.io/anon/pen/adrezJ
But If I set the src arg to the right picture, the masonry plugin rendering is correct.
ex : -img src="http://placehold.it/600x800" width="600" height="800" data-src="http://placehold.it/600x800" class="lazyload" >
Codepen example with the working mansonry rendering :
http://codepen.io/anon/pen/yeWmLy
Do you have a workaround for this issue ?
PS : I tried data-sizes=auto but without success.
Thank you.

The solutions are documented here:
https://github.com/aFarkas/lazysizes#tip-specifying-image-dimensions-minimizing-reflows-and-avoiding-page-jumps
Here is also an older issue with isotope, that provides examples with both solutions documented above:
https://github.com/aFarkas/lazysizes/issues/118
Please close if this helped.

Please re-open if it didn't help.

hi,
sorry for the late answer.
I made it work with the following code.
    // init isotope.
var $grid = $('#container').isotope({
    itemSelector: '.item',
    percentPosition: true,
    layoutMode : 'masonry'
  });

//***
// refresh after each picture lazyloading
$('#container').each(function(){
    var $module = $(this);

    var update = (function(){
        $module.isotope('layout');
        //return true;
    });

    this.addEventListener('load', update, true);
});

Hope this help. you can close the issue. thank you.


account create issue

would someone be able to help me fix account create id be willing to pay?
'Not a well formed email address.']
discord-spam-bots-master\bots\misc\account-creator\account_creator.py : Account creation completed!
is the error i am getting i dont this i got this bot set up right if someone could help id be willing to donate to them!
i am looking for account create and channel joins

I can help we’re can I reach u at


Docs improvements

closes #26888
closes #34189
closes #34560

API change check
API changes are not detected in this pull request.


Why are we adding Autotune to the blueprint name?

Whack

We're displaying the name from the blueprint itself, not the one you enter when you create a blueprint. Opened a ticket to fix.


07/09/2018 03:43 : Create Pull Request for branch prTesting_2018070903 -> master

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestCon.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


roundcube: email identity isnt saved properly

I'm using ownCloud 7.0.4 (stable) and your roundcube app version <IP_ADDRESS>. Connecting to the roundcube instance is working but the email identity isnt save properly in mysql. I followed the instructions to log in again after setting credentials, but everytime I start the roundcupe app inside owncloud I'll have to login manually. I checked the mysql tables and it seems that the password field for the email identity I entered is empty. Also everytime I came back to settings page in owncloud to check for the email identity, there is just the username of my owncloud user saved. Any suggestions?

what roundcube version are you using? Can you provide any logs? Go to the admin settings and enable debug logging for owncloud and roundcube and post it here

I'm using Roundcube Webmail 1.0.3. Here are log files:
Error	roundcube	OC_RoundCube_App.class.php->refresh(): Failed to refresh the RC session.	2015-01-23T20:44:11+00:00
Error	roundcube	OC_RoundCube_App.class.php->refresh(): Failed to refresh the RC session.	2015-01-23T20:40:11+00:00
Error	roundcube	OC_RoundCube_App.class.php->refresh(): Failed to refresh the RC session.	2015-01-23T20:36:11+00:00
Error	roundcube	Got the following error code: 10	2015-01-23T20:36:05+00:00
Error	roundcube	Not rendering roundcube iframe view due to errors	2015-01-23T20:36:05+00:00
Error	roundcube	OC_RoundCube_App.class.php->showMailFrame(): RoundCube can not login to roundcube due to a login exception to roundcube	2015-01-23T20:36:05+00:00
Error	roundcube	OC_RoundCube_App.class.php->showMailFrame(): There were login errors	2015-01-23T20:36:05+00:00
Error	roundcube	OC_RoundCube_App.class.php->refresh(): Failed to refresh the RC session.	2015-01-23T20:36:05+00:00
Error	roundcube	Got the following error code: 10	2015-01-23T20:35:58+00:00
Error	roundcube	Not rendering roundcube iframe view due to errors	2015-01-23T20:35:58+00:00
Error	roundcube	OC_RoundCube_App.class.php->showMailFrame(): RoundCube can not login to roundcube due to a login exception to roundcube	2015-01-23T20:35:58+00:00
Error	roundcube	OC_RoundCube_App.class.php->showMailFrame(): There were login errors	2015-01-23T20:35:58+00:00
Error	roundcube	OC_RoundCube_App.class.php->refresh(): Failed to refresh the RC session.	2015-01-23T20:35:58+00:00
Error	roundcube	OC_RoundCube_App.class.php->refresh(): Failed to refresh the RC session.	2015-01-23T20:35:56+00:00
Error	roundcube	OC_RoundCube_App.class.php->login(): : RoundCube can't login to roundcube due to a login error to roundcube	2015-01-23T20:31:17+00:00
Error	roundcube	OC_RoundCube_App.class.php->login(): : RoundCube can't login to roundcube due to a login error to roundcube	2015-01-23T20:30:35+00:00
Error	PHP	Undefined index: password at /var/www/virtual/USER/html/owncloud/apps/roundcube/lib/RoundCubeAuthHelper.class.php#45	2015-01-23T20:30:35+00:00
Error	roundcube	OC_RoundCube_App.class.php->login(): : RoundCube can't login to roundcube due to a login error to roundcube	2015-01-23T20:30:26+00:00
Error	PHP	Undefined index: password at /var/www/virtual/USER/html/owncloud/apps/roundcube/lib/RoundCubeAuthHelper.class.php#45	2015-01-23T20:30:25+00:00
Error	roundcube	RoundcubeLogin.class.php: openUrlConnection: \n URL (url:https://USER.uberspace.de/) open failed.	2015-01-23T20:29:54+00:00
Error	PHP	fopen(https://USER.uberspace.de/): failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden
 at /var/www/virtual/USER/html/owncloud/apps/roundcube/lib/RoundCubeLogin.class.php#496	2015-01-23T20:29:54+00:00
Error	PHP	Uninitialized string offset: 0 at /var/www/virtual/USER/html/owncloud/apps/roundcube/lib/RoundCubeLogin.class.php#387	2015-01-23T20:29:54+00:00
Fatal	core	Invalid OCS content returned for app roundcube

are you using autologin? or did you save the user/password within your user settings?

I tried both ways. First autologin, then saving the email identity. I followed this instructions to make sure that autologin wasn effecting anything:
 DELETE FROM owncloud.oc_appconfig WHERE appid="roundcube";
 DELETE FROM owncloud.oc_preferences WHERE appid="roundcube";
 DROP TABLE owncloud.oc_roundcube;

seems that fopen is not allowed in your setup, see
But you need fopen to be activated. allow_url_fopen is generally set to On. If it is not On, then you can try two things.

Create an .htaccess file and keep it in root folder ( sometimes it may need to place it one step back folder of the root) and paste this code there.
php_value allow_url_fopen On

Create a php.ini file (for update server php5.ini) and keep it in root folder (sometimes it may need to place it one step back folder of the root) and paste the following code there:
allow_url_fopen = On;

Please change your configuration to one of the recommendations above and report back if this solved your problem

Did that, but now I access owncloud only with through my subdomain owncloud.user.de
Hera are the log files:

Debug	roundcube	OC_RoundCube_AuthHelper.class.php: Login error during refresh.exception 'OC_Mail_NetworkingException' with message 'Unable to determine network-status due to technical problems.' in /var/www/virtual/USER/html/owncloud/apps/roundcube/lib/RoundCubeLogin.class.php:422 Stack trace: #0 /var/www/virtual/USER/html/owncloud/apps/roundcube/lib/RoundCubeLogin.class.php(329): OC_RoundCube_Login->sendRequest('/roundcubemail/') #1 /var/www/virtual/USER/html/owncloud/apps/roundcube/lib/RoundCubeLogin.class.php(280): OC_RoundCube_Login->updateLoginStatus() #2 /var/www/virtual/USER/html/owncloud/apps/roundcube/lib/RoundCubeApp.class.php(273): OC_RoundCube_Login->isLoggedIn() #3 /var/www/virtual/USER/html/owncloud/apps/roundcube/lib/RoundCubeAuthHelper.class.php(121): OC_RoundCube_App::refresh('owncloud.trista...', '', '/roundcubemail/') #4 [internal function]: OC_RoundCube_AuthHelper::refresh() #5 /var/www/virtual/USER/html/owncloud/lib/private/backgroundjob/legacy/regularjob.php(14): call_user_func(Array) #6 /var/www/virtual/USER/html/owncloud/lib/private/backgroundjob/job.php(36): OC\BackgroundJob\Legacy\RegularJob->run(Array) #7 /var/www/virtual/USER/html/owncloud/cron.php(126): OC\BackgroundJob\Job->execute(Object(OC\BackgroundJob\JobList), Object(OC\Log)) #8 {main}	2015-01-25T15:24:26+00:00
Error	PHP	fopen(https://owncloud.USER.de/roundcubemail/): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found at /var/www/virtual/USER/html/owncloud/apps/roundcube/lib/RoundCubeLogin.class.php#496	2015-01-25T15:24:26+00:00
Debug	roundcube	OC_RoundCube_App.class.php->refresh(): Trying to refresh RoundCube session under /roundcubemail/	2015-01-25T15:24:26+00:00
Debug	roundcube	OC_RoundCube_AuthHelper.class.php->refresh(): Preparing refresh for roundcube	2015-01-25T15:24:26+00:00
Error	roundcube	Got the following error code: 20	2015-01-25T15:24:24+00:00
Error	roundcube	Not rendering roundcube iframe view due to errors	2015-01-25T15:24:24+00:00
Error	roundcube	OC_RoundCube_App.class.php->showMailFrame(): RoundCube can not login to roundcube due to a network connection exception to roundcube	2015-01-25T15:24:24+00:00
Error	PHP	fopen(https://owncloud.USER.de/roundcubemail/): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found
 at /var/www/virtual/USER/html/owncloud/apps/roundcube/lib/RoundCubeLogin.class.php#496	2015-01-25T15:24:24+00:00
Debug	roundcube	OC_RoundCube_App.class.php->refresh(): Trying to refresh RoundCube session under /roundcubemail/	2015-01-25T15:24:24+00:00
Debug	roundcube	tpl.mail.php: Found valid user login data.	2015-01-25T15:24:24+00:00
Info	roundcube	tpl.mail.php: Preparing pre-check before rendering mail view	2015-01-25T15:24:24+00:00
Debug	roundcube	tpl.mail.php: Opening iframe for RC-host owncloud.USER.de with port	2015-01-25T15:24:24+00:00
Debug	roundcube	OC_RoundCube_App.class.php->checkLoginData(): Found login data for USER	2015-01-25T15:24:24+00:00

looks better now, but can you access https://owncloud.USER.de/roundcubemail/ directly? Did that work?
Because the log says that it did not found the URL

No, I cant reach roundcube at  https://owncloud.USER.de/roundcubemail/. Enabling allow_url_fopen seems to impact a lot of other things. I cant access any services directly anymore, only with subdomains.

so then enter your complete URL of roundcube within the admin settings, see wiki for more details.
Enabling fopen should not affect subdomains. Did you use the .htaccess method?

i see that complete url setup are not documented in the wiki, i forgott to added in lasted editing.. i edit now.. [[Roundcube-OC-Installation-and-usage#subdomain-troubles]] here https://github.com/hypery2k/owncloud/wiki/Roundcube-OC-Installation-and-usage#subdomain-troubles

Hi @mckaygerhard ,
Thanks for the info, but I still don't understand what you mean by "same browser".
IMPORTANT: Keep in mind that this only works if owncloud and roundcube are running on the same browser (Same-Origin Policy!)
By the way, I am getting this error (probably this is not the best place to post it, if so, sorry):
"reqId":"14415907e72373e901a74d4966230ef0","remoteAddr":"<IP_ADDRESS>","app":"roundcube","message":"RoundcubeLogin.class.php: openUrlConnection: \n Opening url http://https://webmail03.bsc.es/roundcubemail-1.1.1/ failed with Could not resolve host: https","level":3,"time":"2015-05-20T10:54:02+00:00"}
I believe this is not true, since from owncloud box I can reach webmail03 without any problem.
My setup is webmail server apart from owncloud server.
Thanks a lot.

umm maybe some typo in the code.. let me try in 6 days and i'll post here..  .. so the i reopen and test.. similar setup.. if i could reproduce or not post any result.. the issue will be closed again..


[Snyk] Upgrade react-select from 3.1.0 to 3.2.0

Snyk has created this PR to upgrade react-select from 3.1.0 to 3.2.0.

As this is a private repository, Snyk-bot does not have access. Therefore, this PR has been created automatically, but appears to have been created by a real user.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 2 versions ahead of your current version.
The recommended version was released 22 days ago, on 2021-01-13.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

 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.


ROS2 Ground Truth Localizer

…ime a function

Will wait until https://github.com/nasa/astrobee/pull/660 is merged such that I can apply the clock_ fix to it


Don't change loading state on resend magic code

Details

Currently, resending a new magic code will change the loading state and show a loading indicator on sign in button. We don't want to show the loading indicator on resending a new magic code.
Fixed Issues

$ https://github.com/Expensify/App/issues/22083
PROPOSAL: https://github.com/Expensify/App/issues/22083#issuecomment-1617731364
Tests

Same as QA Steps

[x] Verify that no errors appear in the JS console

Offline tests

Requires internet connection
QA Steps

Sign out if you are signed in

On the login page, enter your email
Press Next
Wait for 30 seconds
Request a new magic code by pressing "Didn't receive magic code?"
Verify no loading indicator is shown on the "Sign in" button.

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

https://github.com/Expensify/App/assets/50919443/3fc79259-095b-4450-bef9-d57241f8d254

Mobile Web - Chrome

https://github.com/Expensify/App/assets/50919443/41c7303c-3528-4dff-b606-d2babd86e6b3

Mobile Web - Safari

https://github.com/Expensify/App/assets/50919443/c73e244a-83df-46f1-99d3-78f704a4378f

Desktop

https://github.com/Expensify/App/assets/50919443/8d7a7c97-1fa6-4d3f-a0af-aa760d18a3b4

iOS

https://github.com/Expensify/App/assets/50919443/b48639d8-96c0-45bc-ac7f-f1203b8ac082

Android

https://github.com/Expensify/App/assets/50919443/8d3725ea-c446-4b46-9b6c-6b8e0904bdfb

Reviewer Checklist

[X] I have verified the author checklist is complete (all boxes are checked off).
[X] I verified the correct issue is linked in the ### Fixed Issues section above
[X] I verified testing steps are clear and they cover the changes made in this PR

[X] I verified the steps for local testing are in the Tests section
[X] I verified the steps for Staging and/or Production testing are in the QA steps section
[X] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[X] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[X] I checked that screenshots or videos are included for tests on all platforms
[X] I included screenshots or videos for tests on all platforms
[X] I verified tests pass on all platforms & I tested again on:

[X] Android / native
[X] Android / Chrome
[X] iOS / native
[X] iOS / Safari
[X] MacOS / Chrome / Safari
[X] MacOS / Desktop

[X] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[X] I verified proper code patterns were followed (see Reviewing the code)

[X] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[X] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[X] I verified that comments were added to code that is not self explanatory
[X] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[X] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[X] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[X] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[X] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[X] I verified the JSDocs style guidelines (in STYLE.md) were followed

[X] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[X] I verified that this PR follows the guidelines as stated in the Review Guidelines
[X] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[X] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[X] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[X] If a new component is created I verified that:

[X] A similar component doesn't exist in the codebase
[X] All props are defined accurately and each prop has a /** comment above it */
[X] The file is named correctly
[X] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[X] The only data being stored in the state is data necessary for rendering and nothing else
[X] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[X] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[X] All JSX used for rendering exists in the render method
[X] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[X] If any new file was added I verified that:

[X] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[X] If a new CSS style is added I verified that:

[X] A similar style doesn't already exist
[X] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[X] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[X] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[X] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[X] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[X] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[X] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

web.webm

Mobile Web - Chrome

mweb-chrome.webm

Mobile Web - Safari

mweb-safari.webm

Desktop

desktop.webm

iOS

ios.webm

Android

android.webm

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/grgia in version: 1.3.41-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/Julesssss in version: 1.3.41-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
cancelled 🔪

🍎 iOS 🍎
cancelled 🔪

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/grgia in version: 1.3.42-0 🚀

platform
result

🤖 android 🤖
cancelled 🔪

🖥 desktop 🖥
cancelled 🔪

🍎 iOS 🍎
cancelled 🔪

🕸 web 🕸
cancelled 🔪

🚀 Deployed to production by https://github.com/Julesssss in version: 1.3.41-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/jasperhuangg in version: 1.3.42-26 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


feat(Makefile): set docker build flags via environment variable

We decided to revert the docker build behavior to its previous default for developers (use cached layers), and require CI to set the --no-cache flag instead.

Current coverage is 87.29% (diff: 100%)

Merging #1232 into master will not change coverage

@@             master      #1232   diff @@
==========================================
  Files            43         43
  Lines          3826       3826
  Methods           0          0
  Messages          0          0
  Branches        665        665
==========================================
  Hits           3340       3340
  Misses          321        321
  Partials        165        165

Powered by Codecov. Last update c0ac27d...c0d22f1


THRIFT-4902: Swift 4 and 5 compatibility

[x] Did you create an Apache Jira ticket?  (not required for trivial changes)
[x] Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?  (not required for trivial changes)
[x] Did you squash your changes to a single commit?  (not required, but preferred)
[x] Did you do your best to avoid breaking changes?  If one was needed, did you label the Jira ticket with "Breaking-Change"?

This pull request:

keeps compatibility with Swift 3
adds support for Swift 4.0, 4.2, 5.0 and 5.1
fixes the podspec:

the pod name must match the filename in current versions of CocoaPods
requires_arc  = true is already the default in CocoaPods

mutating func removeAtIndex is removed because it wasn't implemented to begin with: it was just calling itself in an infinite loop.

The changes look okay but without cross testing how do we know they work?

From my reputation. 😉
More seriously, with CocoaPods, we have a linter, so it can build the lib for all platforms (ios/macos here) and different Swift versions. Which means that that we can validate this pull request compatibility by running:
pod lib lint --allow-warnings --swift-version=3
pod lib lint --allow-warnings --swift-version=4.0
pod lib lint --allow-warnings --swift-version=4.2
pod lib lint --allow-warnings --swift-version=5.0

I've now added a travis job for that.

But if we only lint we're not checking I/O against other languages, so adding a cross test harness would be a better choice.

I understand, but that's not the scope of this PR: I'm only adding compatibility with current Swift syntax here. Adding cross test support is the purpose of a separate Jira (THRIFT-4547, #1660).
And I guess that it will be easier to add tests now that the code actually builds for all Swift versions.

Travis CI has Swift 4.2 installed, so if you can provide the cross test changes as a separate PR I would appreciate seeing it cross tested.  I'll watch for build completion.

Rebase on master please.  The only known build issue (after what I just merged) in on Xenial, which doesn't affect this since Swift isn't installed on that image.  Thanks.

@jeking3 test passed

@Coeur seems like master is broken for Swift 5. Could you help? :)

@arpwal Can you be more specific? What kind of error do you see? Does any of #2073,  #2069, #2059, #2051, #2047, #2038, #1997 help with the problem?

@arpwal Sorry, I'm not available to help currently. Please check janosvitok pull requests, they are likely to help.


Jupyter extension

Issue Type: Bug
Simply try to open a jupyter notebook
2021.3.658691958/pythonFiles/printEnvVariables.py bash: /Library/Frameworks/Python.framework/Versions/2.7/bin/python: Bad CPU type in executable
Extension version: 2021.3.619093157
VS Code version: Code 1.54.3 (2b9aebd5354a3629c3aba0a5f5df49f43d6689f8, 2021-03-15T11:57:12.728Z)
OS version: Darwin x64 20.1.0

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspyt653:30270858
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstry244:30276681
pythonvsdeb440:30248342
pythonvsded773:30248341
pythonvspyt875:30259475
pythontbcf:30265426
pythonvspyt943cf:30277002
vscoresta800cf:30276762
vspre833cf:30267465
vsdfh931:30275552
vshan820:30276952

Hi @Luismunguiasalas
Could you please provide some additional details on the issue you are experiencing?
Helpful information includes pictures or screen recordings when applicable. (https://www.screentogif.com)

@Luismunguiasalas, support for Python 2.7 is being deprecated. Please install a newer version of Python.


Aircraft switch

Merge functions from the 206simv2 instrument into the 407simv2 instrument. This will simplify future aircraft additions and allow for upgrades to all aircraft interfaces simultaneously.

Switch functions have been tested with 407.
Testing still needed on:
206 switch functions
407 annunciator functions
206 annunciator functions

Testing complete. General cleanup needed.


[DO NOT MERGE] Performance Improvements

Table now defaults to only displaying 50 rows. Is configurable by passing a
limit GET parameter (e.g. ?limit=100).
Removed unnecessary calls to history.replaceState when search params are
identical.
Optimized numerous array conversions.
Removed usage of querystring in front-end code and replace with
URLSearchParams instances.
Optimized getAuthors to only dispatch 1 request per unique author.

Fixes https://github.com/microsoft/bedrock/issues/1335

@samiyaakhtar I've rebased this off your refactor branch -- we can merge after your branch has been merged

@evanlouie thanks Evan! Merging now

Oh wait, first need to be unblocked on https://github.com/microsoft/spektate/pull/105 @andrebriggs

Abandoning do to being annoying to rebase. Submitting new PR based on master


hi

getting error

Error while creating release definition: Tasks with versions 'ARM Outputs:6.*' are not valid for deploy job 'Agent job' in stage Stage 1.

If you are running Demo Generator on a brand new organization, please enable the Third-party application access via OAuth under  Organization Setting >> Policies

Run the demo generator again and try to install the extension needed by the template.
Thanks


Test CIV-9868

Before creating a pull request make sure that:

[ ] commit messages are meaningful and follow good commit message guidelines
[ ] README and other documentation has been updated / added (if needed)
[ ] tests have been updated / new tests has been added (if needed)

Please remove this line and everything above and fill the following sections:
JIRA link (if applicable)
Change description
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ ] No

Having to use this PR, as tasks are not generating on any civil-service PR


PowerApps is not listed.

I have create 4 apps and I am the owner of the application but when I try to add a new tab and try to find PowerApps I cannot see it. The docs says that default apps are shared automatically. So there are many apps but the Powerapps icon is not being shown. We also have Office 365 License. The documentation is not clear on the pre-requisites for the PowerApps icon to show.

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

ID: db05e68d-8708-9ed3-53bc-da3f1781def5
Version Independent ID: f550b297-89a5-98c0-2fd6-0e6a95204436
Content: Add an app to Microsoft Teams - PowerApps
Content Source: powerapps-docs/user/open-app-embedded-in-teams.md
Service: powerapps
GitHub Login: @mduelae
Microsoft Alias: mduelae

@mitulsuthar thank you for your feedback. I am working with our internal team to verify the info in the doc.
In the meantime, do you have any new updates on this?
Thanks,
Mints

@mitulsuthar - I am still waiting for our internal team to review your issue to see how we can update our content. As soon as I hear back, I will update you.
Thanks,
Mints

Hey @mitulsuthar,
I apologize for the wait. There is a construct in Teams called permission policies which decide which apps Teams users can see when they click on the add a Tab button.
If the Teams admin for your Tenant has assigned you a permission policy that does not give you access to the PowerApps app, then you will not see the app in the add a tab modal.
Can you please confirm that this is not the case? If not, then we can explore other solutions.

Thanks for contacting us. Unfortunately, we're unable to handle Support requests for the product here. To contact Support, see here: https://powerapps.microsoft.com/support/
Closing this issue.
Thanks,
Mints


The option to change the "Runner" name in Runner.xcarchive when building a flavor

Use case
It could already be an option, but I can not find any resources about it. Currently there isn't an option to build multiple 'flavors' at the same time or one after the other in bulk. This is because, to my current knowledge, each time you run the flutter build ipa --flavor <flavor-name> for different flavors; the build/ios/archive/Runner.xcarchive-file will be overwritten. The time to validate and distribute is much longer than building a single app flavor (at least in my case).
Proposal
The possibility to change the name of the Runner.xcarchive file when building a specific flavor. The same that $(APP_DISPLAY_NAME) option does in the info.plist for the app-name. It is unclear to me if this is related to issue #9767

Flutter doesn't hardcode this, Xcode derives this from PRODUCT_NAME just like any Xcode project, so set that differently per flavor/configuration.  The flavors example app:
$ flutter build ipa --flavor paid
Archiving com.yourcompany.flavors.paid...
Running pod install...                                           1,414ms
Running Xcode build...
 └─Compiling, linking and signing...                      1,922ms
Xcode archive done.                                         27.7s
Built /Users/m/Projects/flutter/dev/integration_tests/flavors/build/ios/archive/Paid App.xcarchive.

Where TARGET_NAME is Paid App
https://github.com/flutter/flutter/blob/361d416e6abb66bf601c5a6600fbc37706bb6c14/dev/integration_tests/flavors/ios/Runner.xcodeproj/project.pbxproj#L709
https://github.com/flutter/flutter/blob/361d416e6abb66bf601c5a6600fbc37706bb6c14/dev/integration_tests/flavors/ios/Runner.xcodeproj/project.pbxproj#L220


chore(circuits): merge and root rollup cbind msgpack

Overview of changes

Use CBIND macro for merge_rollup__sim and root_rollup__sim
Data structure of the inputs/outputs of these function need to be reconciled between C++ and TS (member names need to match as circuits.gen.ts will require reference to TS data structure generated from the C++ counterparts. In addition, migration from array to TS tuple is required.)
Activate new code path in the upper layer (remove wrapper functions in rollup_wasm_wrapper and directly use mergeRollupSim and rootRollupSim from circuits.gen.ts).

Resolves #2116
Resolves #2117
Checklist:
Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.

[x] If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag.
[x] I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code.
[x] Every change is related to the PR description.
[x] I have linked this pull request to relevant issues (if any exist).

@dbanks12 I added a description summarising the main changes.


Wrong activation/interpretor when running selected line

When opening VS Code, this interpretor is selected:

I click on it to change it, then click "select at workspace level", then click the right one, but the wrong one is still selected on the bottom right toolbar.

I tried with this in my user settings:
"python.condaPath": "C:\\custprog\\miniconda3\\Scripts\\activate.bat",
"python.defaultInterpreterPath": "C:\\custprog\\miniconda3\\envs\\actifs\\python.exe"

This in my workspace settings:
"python.defaultInterpreterPath": "C:\\custprog\\miniconda3\\envs\\actifs\\python.exe",
"python.terminal.activateEnvInCurrentTerminal": true

This in my folder settings:
"python.terminal.activateEnvInCurrentTerminal": true,
"python.defaultInterpreterPath": "C:\\custprog\\miniconda3\\envs\\actifs\\python.exe"

No matter what I try, when I run selected line (shift+enter) in python script, wrong activation file and interpretor is called

What I do is usually exit python and then call the right activation file from miniconda and activate the right environment, but I'm tired of doing that. I wish it would work by default.
Thanks,

Thanks for the bug report! We investigate issues in order based on priority and severity, which includes the impact it has on your ability to use the extension to do productive work, and the number of people affected. If other users come forward and leave a comment demonstrating they are seeing/reproducing the problem then we will raise this issue's priority. Thanks for understanding and the patience!

Select at workspace level only affects the workspace settings, I think your desire is to change the worspace folder settings. Try Python: Clear cache command and choose one of the folders instead of workspace level. If you see still the issue kindly let me know and we'll be happy to reopen.


BUG 2282254: mon: fix bind addr when IPv6 and msgr2 are enabled

When IPv6-only network mode is enabled and when mons are configured to listen only on msgrV2 port, Rook has to add the port to the mon --public-bind-addr in order to force mons to stop listening on the msgrV1 port. This can cause problems for IPv6 clusters where adding ':' to the end of an IP addr looks like a valid IPv6 address.
In IPv6 mode, Rook needs to set this to '[]:' with the brackets to be a non-ambiguous IPv6 address.
In IPv4 mode, Rook needs to keep its existing behavior. IPv4 mode should also continue to be the defualt assumption if the network config isn't specified.
If 'dualStack: true' is specified, Rook is informed that the environment is dual stack, but Rook doesn't know which IP family to expect from the pod IP. In this scenario, it is safest for Rook not to apply the port, since assuming either IPv4 or IPv6 format could be incorrect. In this scenario, mons may still listen on msgrV1 ports, but this is preferable to an environment where mons perpetually crash.
Signed-off-by: Blaine Gardner<EMAIL_ADDRESS>(cherry picked from commit 573a47e736979c7e604eb0536084668bf21efec7) (cherry picked from commit ccafc2b7159a67c7a734f9dda2c62d143d2c0efa)

Checklist:

[ ] Commit Message Formatting: Commit titles and messages follow guidelines in the developer guide.
[ ] Reviewed the developer guide on Submitting a Pull Request
[ ] Pending release notes updated with breaking and/or notable changes for the next minor release.
[ ] Documentation has been updated, if necessary.
[ ] Unit tests have been added, if necessary.
[ ] Integration tests have been added, if necessary.

/approve
/lgtm


ASM output needs to be line-trimmed for diffs

See this example from the beta site
https://godbolt.org/g/h9hVT1
GCC seems to pad the lines with spaces, while ICC does not, so the diff looks bigger than it should.

Right...somewhat of a duplicate of #269 - will update that with this info

Oops, sorry :D


[Bug]: Build Release Candidate stage_docker job fails with out of space error.

What happened?
https://github.com/apache/beam/actions/workflows/build_release_candidate.yml
stage_docker job fails
#13 117.0 --- Logging error ---
4340#13 117.0 Traceback (most recent call last):
4341#13 117.0   File "/usr/local/gcloud/google-cloud-sdk/lib/googlecloudsdk/core/updater/installers.py", line 233, in DownloadAndExtractTar
4342#13 117.0     fp.write(chunk)
4343#13 117.0 OSError: [Errno 28] No space left on device
4344#13 117.0
4345#13 117.0 During handling of the above exception, another exception occurred:
4346#13 117.0
4347#13 117.0 Traceback (most recent call last):
4348#13 117.0   File "/usr/local/gcloud/google-cloud-sdk/lib/googlecloudsdk/core/updater/installers.py", line 362, in _InstallTar
4349#13 117.0     return DownloadAndExtractTar(
4350#13 117.0   File "/usr/local/gcloud/google-cloud-sdk/lib/googlecloudsdk/core/updater/installers.py", line 238, in DownloadAndExtractTar
4351#13 117.0     raise URLFetchError(e)
4352#13 117.0 googlecloudsdk.core.updater.installers.URLFetchError: [Errno 28] No space left on device
4353#13 117.0
4354#13 117.0 During handling of the above exception, another exception occurred:
4355#13 117.0
4356#13 117.0 Traceback (most recent call last):
4357#13 117.0   File "/usr/local/gcloud/google-cloud-sdk/lib/googlecloudsdk/calliope/cli.py", line 987, in Execute
4358Error: No space left on device : '/home/runner/runners/2.308.0/_diag/pages/33207c11-3b7a-47ff-8a8f-ec83a1ce1461_dca69a40-7968-5563-ee53-0628c33d568e_1.log'

Likely due to now building Multi-arch containers. We'll either somehow need runners with more space on them, or rearchitect the action to not be so space hungry.
Issue Priority
Priority: 2 (default / most bugs should be filed as P2)
Issue Components

[ ] Component: Python SDK
[ ] Component: Java SDK
[ ] Component: Go SDK
[ ] Component: Typescript SDK
[ ] Component: IO connector
[ ] Component: Beam examples
[ ] Component: Beam playground
[ ] Component: Beam katas
[ ] Component: Website
[ ] Component: Spark Runner
[ ] Component: Flink Runner
[ ] Component: Samza Runner
[ ] Component: Twister2 Runner
[ ] Component: Hazelcast Jet Runner
[ ] Component: Google Cloud Dataflow Runner

cc: @damccorm for triage

With previous instances of the same problem, we've worked around it by pruning the images in the middle - https://github.com/apache/beam/blob/a3b1d0b4d2c915b5ea261448ae2e8a70f56bcc5c/build.gradle.kts#L597
Now that we're building/pushing multiarch, we probably just need to do that more often


TLS verification should not be disabled

TLS certificate verification should not be disabled in mqtt-to-postgresql & mqtt-to-bridge
https://github.com/united-manufacturing-hub/united-manufacturing-hub/blob/4f7db3d8bccc2319080839aa1777d31bb4e259df/golang/cmd/mqtt-to-postgresql/mqtt.go#L72-L72
https://github.com/united-manufacturing-hub/united-manufacturing-hub/blob/4f7db3d8bccc2319080839aa1777d31bb4e259df/golang/cmd/mqtt-bridge/mqtt.go#L49-L49

No longer relevant, both services are deprecated


pageserver: circuit breakers on pathological amplification, repeated compaction failures

Problem
See ticket: #6738
Under some circumstances, a misbehaving postgres can create problems for the pageserver:

Writing corrupt data can cause pageserver to emit endless warnings when trying to compact
Writing WAL contents that generate pathologically large physical state.

To avoid impact on other tenants on the pageserver, and to help find issues sooner, the pageserver should take action against tenants that are misbehaving in these ways.
Summary of changes

Add enforce_circuit_breakers tenant config.  Defaulting to false for the first deployment of this.  Later we will set it to true by default, and it will only be set to false during an incident if we actively want a particular tenant to be permitted to violate limits.
During tenant compaction, check storage amplification and halt WAL ingress if it violates a threshold (1000x)
Add a CircuitBreaker type for counting failures and disabling an operation after too many failures
Use a CircuitBreaker for tenant compaction, with a policy that after 5 failures we'll give up trying to compact for an hour.

Why not use the failsafe crate? -- it uses a mutex internally, and when we use one of these circuit breakers on e.g. a page request path, that is too much overhead (though we use a mutex in the compaction case, as this is called infrequently)
Checklist before requesting a review

[ ] I have performed a self-review of my code.
[ ] If it is a core feature, I have added thorough tests.
[ ] Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
[ ] If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

[ ] Do not forget to reformat commit message to not include the above checklist

The compaction failure circuit breaker was added in another PR.  The pathological amplification check in this PR is wrong, it would fire on tenants that do a DROP on a big DB because physical size lags synthetic size.


[Fix]: starknet.js integration for cairo 2.3.0

The previous implementation of ContractFunctions type was broken for cairo 2.3.0, I had to rework it to be compatbile with the new ABI changes introduced in 2.3.0

Closes #48


QVD-2022-1680 Spring Cloud Function SpEL Expression Injection Vulnerability

is this real?
https://github.com/hktalent/spring-spel-0day-poc

why is this commit GH-835 Fix RoutingFunction SpEL evaluation been deleted? how to fix the bug?

The releases containing the fix are 3.1.7 and 3.2.3 and are available. The announcement is published and is scheduled to appear shortly - https://spring.io/blog

HI @olegz this is somewhat confusing, the commits related to 3.2.3 does not seem to be related with this fix (only a lambda related commit).
Could it have been some error when releasing 3.2.3?


Autorest Regen Preview to 3.0.0-alpha.20230819.1 by Rodge Fu from refs/pull/3677/head

Triggered from https://github.com/Azure/autorest.csharp/pull/3677

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.ResourceManager.DataFactory


Remove build-module action

Description
Changes proposed in this pull request:

build-module action removed

Related issue(s)

/test all


Adds sample image slider to show_observation page

Coverage remained the same at 83.87% when pulling bf920c4579d65d85ad0f027025962ea162f12d72 on raysuelzer:ror4 into f11e19a05a90a29ff9b66376d6eed14dbde5bc55 on MushroomObserver:ror4.


[IOTDB-260] Make paths can concatenate

https://issues.apache.org/jira/projects/IOTDB/issues/IOTDB-260
For example, you can use
  SELECT status FROM root.ln.wf01.{wt01,wt02}

what if the path contains *, could you handle it correctly?

what if the path contains *, could you handle it correctly?

IoTDB> SELECT * FROM root.ln.wf01.{wt01,wt02}
SELECT * FROM root.ln.wf01.{wt01,wt02}
+-----------------------------------+-----------------------------+-----------------------------+-----------------------------+-----------------------------+
|                               Time|     root.ln.wf01.wt01.status|root.ln.wf01.wt01.temperature|     root.ln.wf01.wt02.status|root.ln.wf01.wt02.temperature|
+-----------------------------------+-----------------------------+-----------------------------+-----------------------------+-----------------------------+
|      1970-01-01T08:00:00.100+08:00|                         true|                         null|                         true|                         null|
|      1970-01-01T08:00:00.200+08:00|                        false|                        20.71|                        false|                        20.71|
+-----------------------------------+-----------------------------+-----------------------------+-----------------------------+-----------------------------+
Total line number = 2
It costs 0.096s

Glad to see this pr :)
Two places you need to take care of:

Add docs!!!
Change the title of this pr to a more appropriate one.

Glad to see this pr :)
Two places you need to take care of:

Add docs!!!
Change the title of this pr to a more appropriate one.

What kind of title do you suggest? I don't think "Make paths can concatenate" is a bad title.

What kind of title do you suggest? I don't think "Make paths can concatenate" is a bad title.

I still insist my opinion. There are many ways to make paths concatenate. For example, when executing select s1,s2 from root.sg.d0, the query executor will concatenate the prefix path root.sg.d0 with the two suffix paths s1&s2. That's why I think `Make paths can concatenate" is not a good title.
If you need suggestions, I would say like "support multiple timeseries selection using curly braces in the WHERE clause".


Run deployment in a single GitHub Actions workflow

We need to run deployment in a single GitHub Actions workflow. This is because we have dependencies between deployment; for example, we might create an SSM variable in Terraform that then needs to be available to be used in the backend deployment. Right now, though, all three deployment tasks can happen in arbitrary order, which can create race cases and necessitate manual deployment / redeployment.
We should instead run deployment in a single workflow, in the following order:

Deploy Terraform
Deploy backend
Deploy frontend

Let's address this later, if needed. For now, we're mostly okay, because Terraform usually happens before backend. Even if deployment happens in the wrong order, we can always rerun the github actions jobs.


Can we add a functionality which can help read existing CoreData, both encrypted and normal one?

Is this the same thing as #2 ?

Yes kind of. Only difference is whether this library is able to read existing encrypted sqlite file managed by core data. So the developer can change one line in Podfile and a few in code to make it work?

duplicate of #2


[WIP] Identify long held locks

This change is

test-me-please

Tests failed due to the following:
Aug 01 02:16:51 runtime cilium-agent[16632]: level=warning msg="Unable to remove proxymap entry after closing connection" error="Unable to delete element from map: %!s(<nil>)" subsys=proxy
Aug 01 02:16:53 runtime cilium-agent[16632]: POTENTIAL DEADLOCK:
Aug 01 02:16:53 runtime cilium-agent[16632]: Previous place where the lock was grabbed
Aug 01 02:16:53 runtime cilium-agent[16632]: goroutine 303333 lock 0xc422071b04
Aug 01 02:16:53 runtime cilium-agent[16632]: /home/vagrant/go/src/github.com/cilium/cilium/pkg/endpoint/bpf.go:644 endpoint.(*Endpoint).regenerateBPF { e.Mutex.Lock() } <<<<<
Aug 01 02:16:53 runtime cilium-agent[16632]: /home/vagrant/go/src/github.com/cilium/cilium/pkg/endpoint/policy.go:718 endpoint.(*Endpoint).regenerate { revision, compilationExecuted, err = e.regenerateBPF(owner, tmpDir, reason) }
Aug 01 02:16:53 runtime cilium-agent[16632]: /home/vagrant/go/src/github.com/cilium/cilium/pkg/endpoint/policy.go:810 endpoint.(*Endpoint).Regenerate.func1 { err := e.regenerate(owner, reason) }
Aug 01 02:16:53 runtime cilium-agent[16632]: Have been trying to lock it again for more than 5s
Aug 01 02:16:53 runtime cilium-agent[16632]: goroutine 304051 lock 0xc422071b04
Aug 01 02:16:53 runtime cilium-agent[16632]: /home/vagrant/go/src/github.com/cilium/cilium/pkg/endpoint/endpoint.go:1660 endpoint.(*Endpoint).HasLabels { e.Mutex.RLock() } <<<<<
Aug 01 02:16:53 runtime cilium-agent[16632]: /home/vagrant/go/src/github.com/cilium/cilium/daemon/endpoint.go:88 main.getEndpointList.func1 { if ep.HasLabels(convertedLabels) { }

This is the block of code which is responsible for holding the mutex for more than 5 seconds:
https://github.com/cilium/cilium/blob/b22cc7c90cc7abda785deb36378139a2fe4c3c3f/pkg/endpoint/bpf.go#L644-L663

@rlenglet Any idea why e.addNewRedirects() and/or e.removeOldRedirects() would take more than 5 seconds? It seems to me that e.proxyStatisticsMutex should not be the reason?

I will look, but I think that we were doing nothing blocking in there.

Could it be just that each change to proxy config dumps the whole LDS config to Envoy? I would think that even if there are many redirects this should still not take 5 seconds.

That would be done asynchronously and wouldn't block anything. We don't wait for an ACK at this point.


Import color constant for red instead of using magic number

Our test output is colorized for readability, and it uses ANSI escape codes to do so. The tests/util.py file has constants for the colors that we use. The tests/lint/trailing_whitespace.py test should import the RED constant from the tests/util.py file instead of hard-coding 31.

There is an open PR for this.

Previous attempt at #381.


Issue with pytorch multiprocessing

Hi I'm running the latest version of the master branch c61edd4, locally.
I kept running into a double free or corruption error and after searching around found that by
installing libtcmalloc-minimal4 and adding it to the LD_PRELOAD prevents the error from occurring again.
sudo apt-get install libtcmalloc-minimal4
export LD_PRELOAD="/usr/lib/libtcmalloc_minimal.so.4"

I'm running this in a nvidia docker container using pytorch 0.3 instead of 2. but otherwise everything else is based on the requirements.txt
this issue has been flagged out both in tensorflow, lightgbm and pytorch
https://github.com/tensorflow/tensorflow/issues/6968
https://github.com/Microsoft/LightGBM/issues/546
https://github.com/ikostrikov/pytorch-a3c/issues/2

@etheleon thanks for the suggestion.
As I understand it solved the problem?
If so I will add it to the wiki.

Yea!
On Tue, Mar 13, 2018, 6:34 PM Jakub<EMAIL_ADDRESS>wrote:

@etheleon https://github.com/etheleon thanks for the suggestion.
As I understand it solved the problem?
If so I will add it to the wiki.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/neptune-ml/data-science-bowl-2018/issues/46#issuecomment-372620109,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACvGemQ6uHXY2_ZXHOhg4PlGpqYQ-7lqks5td6DGgaJpZM4SoIQW
.


Fix unwanted variable expansion

Description:

We should probably fix this in master, but meh, who cares, it's not a major issue. I still hope to roll out v1.4 soon.
found by @maso27
http://stackoverflow.com/questions/27920806/how-to-avoid-heredoc-expanding-variables

I don't think that this is major issue that have to be fixed in master. So far none of the users stumbled on it.

Yep. It's a major problem in dev, since we have that strict mode that exists the script on non-existent variable.

@alexa-pi/team Btw, if you guys feel that any of the open PRs can be merged, don't be shy to share :smile:

im cherry picking all the easy PRs so some can be merged lol

Thanks! In dev with it!


Refactor numbers.dart utils

Part of #3186
Tasks
The below utility methods are refactored to return null as default value.

[x] parseInt
[x] parseDouble
[x] parseBool

See utils/themes.dart for the main motivation behind this refactoring.

Could you check/resolve a conflict here please?


Node-gyp is failing with Node 4.0/4.1 on Linux machines

My heroku deployments are failing for any package that depends on Node-Gyp.
remote: 17426 verbose pkgid<EMAIL_ADDRESS>remote: 17427 verbose cwd /tmp/build_50d076bfbfe3fc826096ebd4213366a7
remote: 17428 error Linux 3.13.0-61-generic
remote: 17429 error argv "/tmp/build_50d076bfbfe3fc826096ebd4213366a7/vendor/node/bin/node" "/tmp/build_50d076bfbfe3fc826096ebd4213366a7/vendor/node/bin/npm" "rebuild"
remote: 17430 error node v4.1.1
remote: 17431 error npm  v2.14.4
remote: 17432 error code ELIFECYCLE
remote: 17433 error<EMAIL_ADDRESS>install: `node-gyp rebuild`
remote: 17433 error Exit status 1
remote: 17434 error Failed at the<EMAIL_ADDRESS>install script 'node-gyp rebuild'.
remote: 17434 error This is most likely a problem with the bufferutil package,
remote: 17434 error not with npm itself.
remote: 17434 error Tell the author that this fails on your system:
remote: 17434 error     node-gyp rebuild
remote: 17434 error You can get their info via:
remote: 17434 error     npm owner ls bufferutil
remote: 17434 error There is likely additional logging output above.

I believe<EMAIL_ADDRESS>isn't compatible, you're going to want<EMAIL_ADDRESS>or whatever dependency is using bufferutil will want it -- so you probably want to upgrade some dependencies to find ones that have been updated, or go hassle them to update.

the same issue

@Jiran Do you have any more verbose output by any chance? If you could stick in a --verbose somewhere and post the output in a gist that would be awesome!

my gist: https://gist.github.com/puzankov/8dd9bba01a87fe62af77

@puzankov You need to use a C++11-capable compiler: g++ 4.8 or newer, or clang++ 3.4 or newer.

@puzankov You need to use a C++11-capable compiler: g++ 4.8 or newer, or clang++ 3.4 or newer.

Correct :)

@ralphtheninja My verbose output from Heroku. https://gist.github.com/Jiran/06f8c294133c3c702d9e
I was having similar issues locally on my Mac until I updated Xcode and command line tools which however my deployment is on Heroku so I don't know what I can do to solve it, as I don't think I can fix compiler issues through Heroku, can I, could it possibly be something else?

People using travis for testing have had the same problems. The compiler has to be up to date to handle c++11. You could try to persuade all the native modules to start creating prebuilt binaries for you so you don't need to handle the compile step.

@ralphtheninja thanks for the help. I realized I was using custom buildpacks that haven't been updated in a while so I used the official Heroku buildpack and I'm back online. Thanks for the help.

Had the same problem, bufferutil is at version 1.2.1 (as of 10/27/2015) but not installing...
Below plugin, purged cache and fixed the problem on heroku
heroku plugins:install https://github.com/heroku/heroku-repo.git
heroku repo:purge_cache -a {your app name}
git push heroku master

Just want to point out that @aug70's fix above worked for me when nothing else did. Thanks so much for that!


Update vmware-azure-troubleshoot-replication.md

Add description and resolution for error 78253

@ankitaduttaMSFT
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

thanks @billthe4th for your contribution, the content for this error has been addressed and will be published shortly.
Closing this PR #please-close


ONNX export for variable input sizes

Fixes and tests for exporting onnx model that supports variable input sizes.

Hi~~ @neginraoof @fmassa
Thanks for the fix of the RPN network. With the patch, I try to export the maskrcnn ONNX model and test with images of various sizes. However, the detection and segmentation results are wrong if the input image has a different size with the image which is used for exporting the maskrcnn model.
When investigating further, I think there are still issues in the roi_heads.py,
Some related fixes:
From ONNX side: https://github.com/onnx/onnx/pull/2544
From PyTorch side: https://github.com/pytorch/pytorch/pull/33161
I want to understand if there are still other blocking issues for making the full support of MaskRCNN ONNX model export from torchvision pre-trained model? (Means we can have the right detection results no matter the size of the input image)
Thanks

@dxxz Thanks for the comment.
So far, you should not see any mismatches when running the model with same size input. Please let us know if this is the case.
However our work for running the model with dynamic input size is still in progress and is pending a couple PRs:
https://github.com/pytorch/pytorch/pull/32587
https://github.com/pytorch/pytorch/pull/33161
I'll update this PR after these changes go in.

@neginraoof Thanks for your reply.
Yes, when running the maskrcnn ONNX model with images with same input size, the detection results are right.
In my local branch, I merge the workaround in this pull: pytorch/pytorch#1840, and try with dynamic input size.
I upload the test script used in the local branch: https://gist.github.com/dxxz/3c40b5059bd5efe939ce96752d628158
The logic is using one image to export the Mask-RCNN ONNX model from pre-trained PyTorch model. Then run inference by Mask-RCNN ONNX model and PyTorch model individually with another sanity check image of different input sizes. Finally, compare the detection results by ONNX model and PyTorch model.
The compared results as follows:
ONNXRuntime inputs:
image
[3, 'height', 'width']
tensor(float)
ONNXRuntime outputs:
boxes
['obj', 4]
tensor(float)
labels
['obj']
tensor(int64)
scores
['obj']
tensor(float)
masks
['obj', 1, 'height', 'width']
tensor(float)
Sanity check the detection shape of pretrained model and ONNX model on the image for export process.
0
arr:     (100, 4)
ort_arr: (100, 4)
1
arr:     (100,)
ort_arr: (100,)
2
arr:     (100,)
ort_arr: (100,)
3
arr:     (100, 1, 426, 640)
ort_arr: (100, 1, 426, 640)
Sanity check the detection shape of pretrained model and ONNX model on the sanity check images.
0
sanity_arr:     (1, 4)
ort_sanity_arr: (4, 4)
1
sanity_arr:     (1,)
ort_sanity_arr: (4,)
2
sanity_arr:     (1,)
ort_sanity_arr: (4,)
3
sanity_arr:     (1, 1, 640, 586)
ort_sanity_arr: (4, 1, 640, 586)
Finish the sanity check process.
From this result, we can see the detection results by ONNX model and PyTorch model in the sanity check image are different.
From my understanding, the fix you mentioned in:
pytorch/pytorch#32587
pytorch/pytorch#33161
are already use the workaround in pytorch/pytorch#1840 to fix, so the RPN network should work fine. However the mask detection and segmentation process still have the problem.
My question is whether there are other problems in the roi_header.py after the about two PR in the pytorch be merged? Because I think the issues fixed here do not solve the problem in the mask detection and segmentation process. I am really appreciate for any comments or guidance you can provide.

When digging further, I found the log of the ONNX export shows the roi_header.py has the problem:
%3201 : Tensor, %3202 : Tensor, %3203 : Tensor, %3204 : Tensor = onnx::Splitaxis=1
%3205 : Float(100) = onnx::Squeezeaxes=[1]
%3206 : Float(100) = onnx::Squeezeaxes=[1]
%3207 : Float(100) = onnx::Squeezeaxes=[1]
%3208 : Float(100) = onnx::Squeezeaxes=[1]
%3209 : Float() = onnx::Constantvalue={0.603774}
%3210 : Float(100) = onnx::Mul(%3208, %3209)
%3211 : Float() = onnx::Constantvalue={0.603774}
%3212 : Float(100) = onnx::Mul(%3206, %3211)
%3213 : Float() = onnx::Constantvalue={0.60375}
%3214 : Float(100) = onnx::Mul(%3207, %3213)
%3215 : Float() = onnx::Constantvalue={0.60375}
%3216 : Float(100) = onnx::Mul(%3205, %3215)
%3217 : Tensor = onnx::Unsqueezeaxes=[1]
%3218 : Tensor = onnx::Unsqueezeaxes=[1]
%3219 : Tensor = onnx::Unsqueezeaxes=[1]
%3220 : Tensor = onnx::Unsqueezeaxes=[1]
%boxes : Float(100, 4) = onnx::Concat[axis=1](%3217, %3218, %3219, %3220) # ~/env/lib/python3.6/site-packages/torchvision/models/detection/roi_heads.py:353:0
I check the local file of roi_heads.py, the problem is from the following function.
def _onnx_expand_boxes(boxes, scale):
# type: (Tensor, float)
w_half = (boxes[:, 2] - boxes[:, 0]) * .5
h_half = (boxes[:, 3] - boxes[:, 1]) * .5
x_c = (boxes[:, 2] + boxes[:, 0]) * .5
y_c = (boxes[:, 3] + boxes[:, 1]) * .5
w_half = w_half.to(dtype=torch.float32) * scale
h_half = h_half.to(dtype=torch.float32) * scale

boxes_exp0 = x_c - w_half
boxes_exp1 = y_c - h_half
boxes_exp2 = x_c + w_half
boxes_exp3 = y_c + h_half
boxes_exp = torch.stack((boxes_exp0, boxes_exp1, boxes_exp2, boxes_exp3), 1)
return boxes_exp

I think the scale parameter is exported as the Constant, so leading the detection from another image will have the wrong results.
The scale which is passed into the function, and calculate when expanding the mask.
Another issue is in the roi_header.py, should the recompute_scale_factor also need to add in the torch.nn.functional.interpolate function to make sure the mask paste operation can be successfully exported to ONNX?
@neginraoof @fmassa

Continue with my latest post, the Constant Value is not the scale factor. The problem comes from the resize_boxes in the torchvision/models/detection/transform.py
Add the print in the resize_boxes.py
def resize_boxes(boxes, original_size, new_size):
# type: (Tensor, List[int], List[int])
ratios = [float(s) / float(s_orig) for s, s_orig in zip(new_size, original_size)]
ratio_height, ratio_width = ratios
xmin, ymin, xmax, ymax = boxes.unbind(1)
print("[Debug]: ratio_width {}, ratio_height {}".format(ratio_width, ratio_height))
xmin = xmin * ratio_width
xmax = xmax * ratio_width
ymin = ymin * ratio_height
ymax = ymax * ratio_height
return torch.stack((xmin, ymin, xmax, ymax), dim=1)

Here is the print info when exporting the MaskRCNN ONNX model.
[Debug]: ratio_width 0.6037735849056604, ratio_height 0.60375
These are the value's be exported as the constant from the MaskRCNN ONNX export log:
%3209 : Float() = onnx::Constantvalue={0.603774}
%3210 : Float(100) = onnx::Mul(%3208, %3209)
%3211 : Float() = onnx::Constantvalue={0.603774}
%3212 : Float(100) = onnx::Mul(%3206, %3211)
%3213 : Float() = onnx::Constantvalue={0.60375}
%3214 : Float(100) = onnx::Mul(%3207, %3213)
%3215 : Float() = onnx::Constantvalue={0.60375}
%3216 : Float(100) = onnx::Mul(%3205, %3215)
@neginraoof @fmassa Can you help confirm whether it is the real problem?
Thanks and hoping for your reply.

@dxxz
Thanks. I just updated this part of the code. Please try out and see. I was able to successfully run this with new input size.

@dxxz Yes, I'm aware of this issue as well. We cannot fix this from onnx export side.
Another idea here would be to provide min_size and max_size as inputs to the model, so that we can calculate scale_factor dynamically from this part of the code:
https://github.com/pytorch/vision/blob/da44102cfe270d5031958c68e71cae112b0b3b23/torchvision/models/detection/transform.py#L84

@lara-hdr
This PR is ready for review. Thanks!
cc @fmassa
I've prepared this PR for review. How ever, this PR does not fix the issue with export for dynamic input sizes.
The problem we are currently facing in transform (resize) module is related to:
https://github.com/pytorch/pytorch/issues/33443
In this part of the code:
https://github.com/pytorch/vision/blob/2937d77d676c604dc071ddf9cf8d8fcd66cc1736/torchvision/models/detection/transform.py#L92
The scale_factor cannot be traced dynamically since it is calculated from the model state parameters (min_size and max_size). Setting these parameters set's the scale_factor as constant in the traced model. However, for variable input sizes, the scale_factor in interpolate op may vary.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@be0ae7e). Click here to learn what that means.
The diff coverage is 0%.

@@           Coverage Diff            @@
##             master   #1840   +/-   ##
========================================
  Coverage          ?   0.43%
========================================
  Files             ?      92
  Lines             ?    7395
  Branches          ?    1113
========================================
  Hits              ?      32
  Misses            ?    7355
  Partials          ?       8

Impacted Files
Coverage Δ

torchvision/models/densenet.py
0% <ø> (ø)

torchvision/ops/misc.py
0% <0%> (ø)

Continue to review full report at Codecov.

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

Thanks @fmassa.
The current code supports export of model for inputs with static scale_factor in "resize" transform.
The problem is that the resize scale factor is calculated from the ratio between input min/max size, and model's min/max size which is determined at initialization (saved as model state).
in resize, we have:
scale_factor = model_min_size / input_min_size
if scale_factor * input_max_size > model_max_size:
scale_factor = model_max_size / input_max_size
In here, model_min and model_max are always constants. So if the ratio model_min_size/input_min_size is different for different input images, there will be a mismatch in output shape.
Let's say with model_min_size, model_max_size = 800, 1600
We cannot export model with input images of size (800, 1200) and (850, 1200)
But we can export images of size (800, 1200) and (850, 1200)
I would rather change the model so that model_min_size and model_max_size could be provided as inputs.

@neginraoof thanks for the explanation!

The current code supports export of model for inputs with static scale_factor in "resize" transform.

Thanks for explaining the issue!
Correct me if I'm wrong, but wouldn't we solve this issue if we split the scale_factor computation into a separate function which is torchscripted? This way, ONNX would export the whole computation graph for the scale_factor, instead of using a fixed version of it, right?
Something in the lines of
@torch.jit.script
def compute_scale_factor(image, self_min_size, self_max_size, training):
        h, w = image.shape[-2:]
        im_shape = torch.tensor(image.shape[-2:])
        min_size = float(torch.min(im_shape))
        max_size = float(torch.max(im_shape))
        if training:
            size = float(torch_choice(self_min_size))
        else:
            # FIXME assume for now that testing uses the largest scale
            size = float(self_min_size[-1])
        scale_factor = size / min_size
        if max_size * scale_factor > self_max_size:
            scale_factor = self_max_size / max_size
        return scale_factor

and using it in resize?
Let me know what you think

After scripting this function, looks like the constant for scalar_factor is not replaced in the jit graph.

So far we have these follow up items:

Check jit trace graph for constants generated from int() and float()
Check constant interpolate scale_factor (this could be due to float(), same as previous item)
Check jit trace graph for constants generated from numel() op

Test failure is in: torchvision/csrc/cpu/DeformConv_cpu.cpp
This is unrelated.


implement conversion from error codes to different http statuses

#385

See https://github.com/yandex/ClickHouse/commit/26646001e378fa219f341a27ac92f31887b187ef


added tinymce.css to public/tinymce dir

Fixes issue referenced in #2379.
Changes proposed in this PR:

add public/tinymce/tinymce.css file

@briri great! But that javascript file should also be updated, and refer to this file, not?

@nicolasfranck, yes good catch.

First time through, got some random postgres failure. Reran and tests all worked.


wot-author show proofs from profile

👋 @thebearjew this incorporates your feedback from https://github.com/keybase/client/pull/23458

Superseded


There is no way for a developer to override the load method

There is no way to let the developer load translations from another source, like a database/server.
There must exists a way to override the load method.

Fixed in the latest release


estimate_size crashes on WASM

Caused by using Account / ring when signing the transaction. See https://github.com/manuelmauro/algonaut/issues/59
Workaround: Instead of signing the transaction, hardcode the additional bytes, like in the Go SDK:
self.to_msg_pack()?.len() as u64 + 75;

The purpose of this function is not entirely clear though - what when it's a multi sig or logic sig?

Could we possibly attach an additional method to signature that's something like "signature byte length"? It'd be internal to the library in case we decide to change it.

Essentially like the NumOfAdditionalBytesAfterSigning constant in the Go SDK? But what about multi sig and logic sig? Transaction doesn't have any information yet about how it will be signed. And multi sig and logic sig have variable sizes (for multi sig it depends on how many accounts are participating, and logic sig on the program's size), so we wouldn't be able to estimate those before having the actual signature.


Fix WhenDecomposer for multiline when codeblocks

I guess you could somehow produce valid clips here but it doesn't seem worth the effort to me.
ast is nil because putting these two lines into an array is not valid syntax.

@r7kamura, could you take a look?

I had overlooked it. Looks good, thanks!

Thank you! Could you take a look at my other open PR as well? 😉


Use xsendfile and/or php proxy

https://tn123.org/mod_xsendfile/
Send file requests through php and/or xsendfile module for nginx/apache.

benefits:

implementing permissions can be done easily

force users to login to download
prevent direct access to file via its link

you can allow all kind of files (even php)

this can be possible to save uploaded file with a random name and download with its original name using Content-Disposition header

they are what I can remember now I guess there's more.

also Nginx, Lighttpd and Apache supports xsendfile:

Lighttpd has this feature and there is a mod_xsendfile for Apache2.


feat: 添加上下切割的 demo

🤔 这个变动的性质是？

[ ] 新特性提交
[ ] 日常 bug 修复
[x] 站点、文档改进
[ ] 演示代码改进
[ ] 组件样式/交互改进
[ ] TypeScript 定义更新
[ ] 包体积优化
[ ] 性能优化
[ ] 功能增强
[ ] 国际化改进
[ ] 重构
[ ] 代码风格优化
[ ] 测试用例
[ ] 分支合并
[ ] 其他改动（是关于什么的改动？）

🔗 相关 Issue

💡 需求背景和解决方案

📝 更新日志

☑ 请求合并前的自查清单
⚠ 请自检并全部勾选全部选项。⚠

[x] 文档已补充或无须补充
[x] 代码演示已提供或无须提供
[x] TypeScript 定义已补充或无须补充
[x] Changelog 已提供或无须提供

Codecov Report

Merging #265 (dbdf4f1) into canary (b540a33) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head dbdf4f1 differs from pull request most recent head 8036fcf. Consider uploading reports for the commit 8036fcf to get more accurate results

@@           Coverage Diff           @@
##           canary     #265   +/-   ##
=======================================
  Coverage   72.59%   72.59%
=======================================
  Files           6        6
  Lines         135      135
  Branches       32       32
=======================================
  Hits           98       98
  Misses         37       37

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Added .editorconfig according to PEP-8

@j-towns

I’m not sure we need this. We use a style that’s pretty similar to PEP-8, i.e. the default python style used by most projects and the default style assumed by most editors, so won’t this file be redundant in most cases?
Also looking at other related projects (JAX and NumPy), they don’t appear to have one of these. Feel free to re-open if you have reason to disagree 🙂.

and the default style assumed by most editors

It's not. Even if it is, it is inacceptible to change editor global settings, if the editor has other settings (I personally prefer tabs).


add device creating exapmle

Signed-off-by: Tomas Karasek<EMAIL_ADDRESS>fixes #17
I took over code from @displague's gist and integrated it to local examples.
It creates a device with early terminationdate, so the device should be removed immediately. Not sure if this is the best way to do cleanup, but it's for sure the simplest.

@t0mk The termination date was added out of necessity.
Without it, the date was submitted incorrectly: https://github.com/go-swagger/go-swagger/issues/2518
I think it's a nice addition for all of our testing infrastructure though.

When I added Features and ProjectSSHKeys I wasn't trying to determine why the devices were not being created.
This was ultimately caused by #18.  We probably don't need to provide empty features and project_ssh_keys for this example.
Looks good, as-is.

@displague I know about the 1970 default for the termination date, and saw your bug report earlier today. It's quite a strange assumption to fill nondeclared datetimes with the beginning of the epoch.
Especially considering that swagger puts boolean pointers to the structs for bool params, but puts a (non-pointer) value for a datetime param.
Anyway, I am merging this PR.


upgrade dependencies to their latest versions

Still looking into

[ ] vue2-filters which has some breaking changes (0.6.1 makes the whole mixin via class component break)

Closes #600

Please make sure the below checklist is followed for Pull Requests.

[ ] All continuous integration tests are green

[ ] Tests are added where necessary

[ ] Documentation is added/updated where necessary

[ ] Coding Rules & Commit Guidelines as per our CONTRIBUTING.md document are followed

I think I found the solution how to update vue2-filters. Will push the required changes later.

Bounty claimed https://opencollective.com/generator-jhipster/expenses/17499/
Thanks @mraible for putting the bounty on https://github.com/jhipster/generator-jhipster/issues/11690! :heart:

@atomfrede You're welcome! Thanks for doing the work. 😀

Luckily I did some parts before already.


Enable the CopyPropagation pass

For now simply run the pass before SemanticARCOpts. This will probably
be called as a utility from within SemanticARCOpts so it can be
iteratively applied after other ARC-related transformations.

Review feedback merged here: https://github.com/apple/swift/pull/35241


bug: operator installed with helm oomkilled

Describe the issue
The default value of operator.resources.limits.memory 30Mi is too low, Kubernetes kills the pod with oomkilled error.
I increased operator.resources.limits.memory to a random value 60Mi as a workaround.
To Reproduce
Install fluent-operator v1.7.0 with Helm.
Get a OOMKilled error in operator pod.
Expected behavior
No OOMKilled issue.
Your Environment
- Fluent Operator version: v1.7.0
- Container Runtime: containerd
- Operating system: NixOS 22.11
- Kernel version: 5.15.78

How did you install fluent operator?
helm chart v1.7.0
Additional context
htop output:
    PID USER       PRI  NI  VIRT   RES   SHR S  CPU%▽MEM%   TIME+  Command
<PHONE_NUMBER>2       20   0  730M 49716 24428 S   0.0  0.1  1:15.24 /manager

Yes, this parameter can be turned up a bit, would you like to contribute a PR for this?


Controller and camera not see in steamvr

Hello there,
i install the last version 1.6.0 :
steam looks detect my camera and psmove controler, but i can't see it on my steamVR  ?
no contraler and cam ??
what is wrong please

do u know how fix this please ?

ok so i remove, all psmovevr with the remove uninstaller
and i reinstall a frehch install
so now i have the camera in the 3d view with vive controleur and not psmove :

and the view is not center of my headset so the controleur is far away from me, and even i push start+select the controleur are not center to my hand
need hepl please

other things, in game i have no 3d model, but when i put button that's works
please help to debug this

That's got me crazy i got all element :

but no way to get working in the 3D view in Steam :/
i have laag and no way to get the good position ?
what is wrong please ?

This my conf :

up again ?


Does updated/before/<NOW> work?

Noticed while working on #498, where updated/before filter with date set to today doesn't work, it filters out all items

Likely what needs to happen is an updated/before should expand to the latest time of the given date, and after should be the earliest time


Refine the error handling and constructor of AuthenticatedChannelClientDriver

What changes are proposed in this pull request?
Refine the error handling and constructor of AuthenticatedChannelClientDriver
Why are the changes needed?
Catching throwable might cause issue when fatal error was thrown
Make the initialization more safe.
Does this PR introduce any user facing changes?
Please list the user-facing changes introduced by your change, including
no

check style? @beinan


fix: fix left menu layout height

This PR adds more layout improvements.
Fixes

Add scrolling when there are many Kustomize or Helm items. Previously it would just act as overflow: hidden.
Fix several of by 1 pixels
Improve consistency across panels

How to test it

Open a project with many Helm charts or Kustomize directories.

Checklist

[x] tested locally
[ ] added new dependencies
[ ] updated the docs
[ ] added a test

I wonder if we should make the file explorer scroll box include the RootFolderText. For template, it makes sense to not include it as you want to be able to interact with the search box but this is not the case for that text. It makes the text disappear at a bit a weird place. What do you think?


Ad UI 9181 bump mantine v7

Proposed Changes
With the new Mantine 7, the come back of the year is here, CSS moddules are back.
Appart from the obvious breaking stuff on a component level, I've added new module.css files to handle the style of every components in /mantine and also for /website.
I've followed the migration guide and the changelog
Migration:
https://mantine.dev/guides/6x-to-7x/
When I saw sx, I changed it to className with a module.
When I saw styles or classes from createStyles I used classNames with module
These were the 2 biggest task of this bump (migration wise).
Changelog:
https://mantine.dev/changelog/7-0-0/
Here is what I think is left to do for this branch (soon to be next):
website:

we used Prism before which is now not used anymore in mantine. It's been replaced for highlight.js, but changing style was very cumbersome and I failed to do so properly. We should either : create our own style for the component or use highlightjs out of the box instead of using it from mantine.
Please review anything you find weird or not right. As I slowly died every day when working on this because I was stuck in golden plating (I have yet to learn about letting it go), there might be some spot with either weird visual OR - and more importantly - bad style applied (or no style applied) on elements.

mantine:
This will probably be more easy to verify once we bump in some packages

TableHeader. It contains a Grid, but I am not able to apply the style properly

This goes for all table headers

Appart from that, the same work applies when we will bump in some packages. Check that everything fits properly and looks good :)
Fun not so side-quest, tests are failing in /package/mantine. I will work on them, hit me up if you want to help so we dont work double.
Potential Breaking Changes

Acceptance Criteria

[ ] The proposed changes are covered by unit tests
[x] The potential breaking changes are clearly identified
[ ] README.md is adjusted to reflect the proposed changes (if relevant)

@elessardCoveo J'ai resolve les comments parce que jme suis fait une branche séparée dans laquelle je fix tous ces trucs la ! (il me reste 1 ou deux commits encore) https://github.com/coveo/plasma/pull/3601