Filter in markers throw exception

Hi,
If you add a filter in markers work, but throw exception in console.
Example with two markers and a filter to show just one: http://jsfiddle.net/3zvthhbb/1/
The same issue with paths.

I'm going to rework&redesign angular-leaflet-directive to be compatible with Leaflet v1.0. It will mantain almost all its functionality, and will be compatible with the current features of the directive, but I must start from a fresh point, so I'm going to close this issue. If you think it must be worked with the new version, please reopen it.


refactor: enhance the metadata validation error messages

Description
This PR enhances how conversion errors are shown to the users for metadata validations. It will show the expected value but also the provided one, which can be very helpful to users for fixing the problem
Type of change
(Please delete options that are not relevant. Remember to title the PR according to the type of change)

[X] Refactor (change restructuring the codebase without changing functionality)
[X] Improvement (change adding some improvement to an existing functionality)

Looks good! Could you open another issue to make sure we apply this (showing the provided value) for other components (names in dataset, fields, questions, etc.) I've encountered this with metadata property names for example in a loop and was difficult debug which field was causing this.


Thanks me for report

/duplicate

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


Delete account

Description
Added the delete account operation
Fixes #374 Delete Account Feature
Type of change

[x] New feature (non-breaking change which adds functionality)

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

Sample Output
https://github.com/UBA-GCOEN/StichHub/assets/86224794/9e09a8cf-e7fc-41a5-b176-5f7f86994f92

Hello @AlfiyaSiddique!
Thank you for submitting this pull request Your pull request will be reviewed by maintainers shortly. Meanwhile make sure you have referenced the respected issue in this pr Your pr will not be merged if it does not have reference to respected issue
please read our Contributing Guidelines https://github.com/UBA-GCOEN/StichHub/blob/main/CONTRIBUTING.md And Code of Conduct https://github.com/UBA-GCOEN/StichHub/blob/main/CODE_OF_CONDUCT.md

Hey @Siddhant-Patil0203, What are these potential problems found by GitHub-code-scanning bot? Do I need to change something in my code?

@Siddhant-Patil0203  ??

Hey @Siddhant-Patil0203, What are these potential problems found by GitHub-code-scanning bot? Do I need to change something in my code?

Hey @AlfiyaSiddique
I will look through and let you know, if there are any necessary changes required.

Hey @AlfiyaSiddique
there are two issues in codeql Scanning
1>missing rate limit
2>Database query built from user-controlled sources
can resolve this one by adding rate limit using express-rate-limiter as below.
const rateLimit = require("express-rate-limit");
// Apply rate limiting middleware for each route
const limiter = rateLimit({
windowMs: 15 * 60 * 1000, // 15 minutes
max: 100, // limit each IP to 100 requests per windowMs
});
router.post('/signin', limiter, signin);
router.post('/register', limiter, register);
router.post('/delete', limiter, deleteAccount);
to adress this issue just add this kind of validation and sanitation
// Validate the email input
if (!isValidEmail(email)) {
throw new Error('Invalid email');
}
// Sanitize the email input (if necessary)
const sanitizedEmail = sanitizeEmail(email);

Hey @AlfiyaSiddique there are two issues in codeql Scanning 1>missing rate limit 2>Database query built from user-controlled sources
can resolve this one by adding rate limit using express-rate-limiter as below. const rateLimit = require("express-rate-limit");
// Apply rate limiting middleware for each route const limiter = rateLimit({ windowMs: 15 * 60 * 1000, // 15 minutes max: 100, // limit each IP to 100 requests per windowMs });
router.post('/signin', limiter, signin); router.post('/register', limiter, register); router.post('/delete', limiter, deleteAccount);
to adress this issue just add this kind of validation and sanitation // Validate the email input if (!isValidEmail(email)) { throw new Error('Invalid email'); }
// Sanitize the email input (if necessary) const sanitizedEmail = sanitizeEmail(email);

Okay, Understood. Will make the changes soon.👍🏻

Hello @Naresh-chandanbatve
Resolved all the issues. 👍🏻

hey @AlfiyaSiddique
all issues is are not solved this approach will consume more time to validate emails
I will suggest to use email validator library to validate emails
here is an example snippet
const validator = require('email-validator');
const isValidEmail = async (email) => {
const isValid = validator.validate(email);
return isValid;
};
const email =<EMAIL_ADDRESS>const result = await isValidEmail(email);
console.log(result); // Output: true

hey @AlfiyaSiddique all issues is are not solved this approach will consume more time to validate emails I will suggest to use email validator library to validate emails
here is an example snippet
const validator = require('email-validator');
const isValidEmail = async (email) => { const isValid = validator.validate(email); return isValid; }; const email =<EMAIL_ADDRESS>const result = await isValidEmail(email); console.log(result); // Output: true

Okay.

Hello @Naresh-chandanbatve
Implemented the requested changes.

Hello @Naresh-chandanbatve
Please review this PR!

Hello @Naresh-chandanbatve
Please review my PRs.

@AlfiyaSiddique
you have added package.json in root folder this should be in /server folder
you have installed express-rate-limit in root folder instread of server folder
please delete package.json from root folder and run  npm install express-rate-limit in the /server folder
also delete package-lock.josn in the root folder it was also added by mistake earlier

@AlfiyaSiddique you have added package.json in root folder this should be in /server folder you have installed express-rate-limit in root folder instread of server folder
please delete package.json from root folder and run npm install express-rate-limit in the /server folder also delete package-lock.josn in the root folder it was also added by mistake earlier

Oh okay, I apologize. Did that by mistake

Did the Changes @Naresh-chandanbatve

Hello @AlfiyaSiddique,
I noticed that your routes do not have authorization for deleting user accounts. It might be a good idea to implement user authorization using middleware such as authCustomer/authTailor. What are your thoughts on this?

Hello @AlfiyaSiddique,
I noticed that your routes do not have authorization for deleting user accounts. It might be a good idea to implement user authorization using middleware such as authCustomer/authTailor. What are your thoughts on this?

Yeah. completely agree with this point. Thanks for pointing this out. Will implement it soon.

Great work @AlfiyaSiddique
Its nice and needed feature and it will be very helpful in development as well to create and delete accounts.
Thanks a lot for your contribution ❤.


Remove Go SDK

I added an entry to the SDKs for the LSP page a long time ago with my attempt at an LSP SDK written in Go. Unfortunately I haven't had much time to implement it, so I thought it'd be a good idea to remove it from the list as to not mislead anybody.
Cheers!

Thanks for getting back.


Update the package version for Regenerate sdk code for resource-2019-10 and subscription-2019-11

This pr is just updating the package version to 3.6.0 for a previous pr: Regenerate sdk code for resource-2019-10 and subscription-2019-11, as re-publish an existing version is not allowed.

@isra-fel, Could you please take a quick look of this small pr? Many thanks.


Add home key for magic-namespace

The key "home" is needed for ci testing, it's missing in this yaml. That sometimes will cause testing failure.

/assign @krancour thanks!

/assign

Closing in favor of #5086
/close


Describe how to re-request a review

What article on docs.github.com is affected?

I think we should update one of the subsections belonging to this main section:
https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/reviewing-changes-in-pull-requests
What part(s) of the article would you like to see updated?

Why should the docs be changed?
I can't find anything in the GitHub docs about re-requesting a review??? I would expect it to be in one of the articles in the Reviewing changes in pull requests section, but I can't find it there at all.
What use cases does it support?
This should be documented somewhere, so that repository maintainers can link to this section to explain how "re-requesting an review" works.
This also exposes this functionality to anyone who reads the GitHub docs, that way they can "stumble into" this functionality.
Expected outcome
There is a section in the GitHub docs that explains that you can click on the refresh icon next to a review, to ping the reviewer for a fresh review.
Additional information

See the image below for an example of the refresh icon that I'm talking about:

👋 @HonkingGoose I don't see anything about re requesting a PR review either! It sounds to me like you're interested in an addition that focuses on a contributor requesting an additional review after they've made changes in an already reviewed PR. Is that right?
The article you linked to above ☝ Reviewing changes in pull requests is aimed at the reviewer, so I don't think that's quite the right place for this information to live.
What about adding it to either About pull request reviews? Or maybe Incorporating feedback in your pull request, since that article focuses on how to apply suggested changes and open an issue for out of scope suggestions?

First of all, thanks for the quick response! :smile:

It sounds to me like you're interested in an addition that focuses on a contributor requesting an additional review after they've made changes in an already reviewed PR. Is that right?

Yes, that's right! :smile:

The article you linked to above :point_up: Reviewing changes in pull requests is aimed at the reviewer, so I don't think that's quite the right place for this information to live.

Agree, it should go somewhere else.

What about adding it to either About pull request reviews?

Sounds good to me, I think I like this place better than " Incorporating feedback in your pull request", as that seems to me more focused on the review feedback. I can see the case for both places though.
I think some keywords should be: "refresh review", "ping for a fresh review", "re-request review", I think things like that are what people would be search for. I know I typed in "re-request review" and "request review" to try to find this documentation.

The hover text says "re-request review," so I think that's what we should use here. I think it'd be beneficial to add the information to both articles. So what we can do is create a new reusable in https://github.com/github/docs/tree/main/data/reusables/pull_requests that includes:

a sentence or two about why someone would want to re-request a review (like after making substantial changes)
a quick explanation of how to re-request a review, using the sync octicon

We can add a new section called "Re-requesting reviews" to the About pull request reviews article after the "Resolving conversations" section with that reusable. We can also add a new section and reusable to Incorporating feedback in your pull request after the procedural, above the "Opening an issue for an out-of-scope suggestion" section.
Anyone is welcome to open a PR implementing that plan if you want to!

I'll go make a PR request for this then. :+1:


feat: migrate to package:web

There are some blocking issues right now:

https://github.com/dart-lang/web/issues/252#issuecomment-2160022045

@ahmednfwela Thanks for starting this effort! Mind if I push commits on top of yours directly?

sure, please go ahead!

@ahmednfwela Can you enable allow "edits to maintainers" as shown here?

since to allow maintainers to edit, the source branch needs to be on a personal account (not an org account), I will recreate the PR.

new PR: https://github.com/angulardart-community/angular/pull/75


fix for AIY Kits Release 2018-11-16

Hi, @senyoltw
The modification of assistant_grpc_demo.py is easier to incorporate snowboy based on the source of 2018-11-16. It works by modifying snowboydecoder.py.
Thanks.

:blush:


[SIL] Add cloneModule

This PR adds the cloneModule() function to SILCloner. cloneModule() returns a deep copy of the originalModule SILModule. The implementation is modeled after llvm::CloneModule().
I wrote this as part of my Alive2 for SIL GSoC project. I'm submitting the PR in case the functionality will be useful to others. An important part of the review process will be deciding if it will in fact be useful to others.
@CodaFi could you review this?

Unfortunately, I don't think I'll be able to follow up on this PR, so I'm going to close it. Thanks to @atrick and @varungandhi-apple for your reviews.


Evaluate "selectionDirection" property

The selectionDirection attribute of a textarea element can be set but according to the spec - http://www.w3.org/TR/html5/forms.html#dom-textarea/input-selectiondirection - this value does not actually do anything from a "setting" perspective, though it does contain a value during text selection to be used in a "getter" perspective.  Do we want to adjust the description of this property at #/demos/sl-textarea to align with this?
This then leads into the next item which is this attribute is set inconsistently across browsers.  Chrome on OS X at least does not have this value populated.  Given this (and other browsers should be tested too) do we even want to expose this property?  What role do we want this library to play?  Normalize across things or provide support pass-though and those environments that do will?
There is a skipped integration test for this component and property that needs to either be removed or built out depending on the outcome of this decision.

https://code.google.com/p/chromium/issues/detail?id=333622 is a bug against Chrome for this so perhaps it is isolated.

My opinion should carry the least weight on something like this.
Pass-through.

Update: tested on IE and returns undefined.

IMO we should not expose this property until it is supported consistently and is testable. We could pass through but it's just more mental overhead for the developer using the library.

I doubt the developer has any real use-case for this property right now.  Going the pass-through route enables us to pass the test and forget about it.  When someone actually has a use-case for it, it will hopefully work in their target browsers.
However, if there's no use-case; why have a test case?
(verified IE not liking this property in any capacity but does support the select event, oddly enough)

New solution to handle present and future.
Instead of binding the ember attribute to the dom property.... Why not set the ember attribute as a computed property based on selectionStart and selectionEnd.  Those tests already pass, just calculate "forward" and "backward" based on selectionStart < selectionEnd.

@SpikedKira Since some web browsers don't support the property, that would seem like a hacky solution to add the desired functionality.

@SpikedKira after some experimentation it seems that we cannot infer the selection direction based on selectionStart and selectionEnd because regardless of direction, the values remain consistent regardless of direction and don't "flip" as one would expect when changing selection direction. http://jsfiddle.net/4k69qyp7/3/

verified (start is always less than or equal to end)
looks like a skip :S


RTL version

Hi
I recently created RTL version of awesome AdminLTE with Persian fonts. hope useful for RTL projects.
here is my repo:
https://github.com/mmdsharifi/AdminLTE-RTL
Demo : https://htmlpreview.github.io/?https://raw.githubusercontent.com/mmdsharifi/AdminLTE-RTL/master/index.html

Thanks for sharing this!
I will add your repo to the documentation for reference.

Added to docs.

you're welcome !
Thank you for adding and your awesome AdminLTE ;)


Get payment page with current lang

Hi,
I'm tryng to display payplug payment page in French lang, but I still have it in English. Is there a configuration I missed ?

Hi @ehibes, apologies for not replying sooner, the automation of notifications for these issues stopped.
Did you manage to find a solution? If not, the language shown for the Payplug payment page usually takes the same one as the browser. Keep us posted to help you if needed.
Thanks


Latest update to Windows-2019 broke our build (again)

Describe the bug
The update from:
Virtual Environment
  Environment: windows-2019
  Version: 20200802.1
  Included Software: https://github.com/actions/virtual-environments/blob/win19/20200802.1/images/win/Windows2019-Readme.md

to:
Virtual Environment
  Environment: windows-2019
  Version: 20200820.1
  Included Software: https://github.com/actions/virtual-environments/blob/win19/20200820.1/images/win/Windows2019-Readme.md

Led to our tests starting to fail because of a missing #include.
To Reproduce
I didn't reduce the code, because the issue is quite simple to fix.
Essentially, just run the build.d script in https://github.com/bpfkorea/agora/tree/9cd2b987593b038caffa43b97c8b69bff4f03e1a/source/scpp with dub build.d.
Expected behavior
I would really, really, really like it if Github offered me a way to freeze which runner image I'm using. CI runs should be reproducible but with the current setup, they are not, and things start to randomly fail (or can't be rebuilt later) when Github decides to update an image.
The failure itself is quite simple: It's a missing #include. While it is an issue with our code this time, not having the ability to control whenever updates are applied. This automatic update process completely negates the benefit of having a containerized environment:

Releases are not reproducible anymore. If I built my release for tag 1.2.3 using windows-2019 10 days ago, and I do it today, I'll get a binary compiled with a different compiler, and different dependencies, with no code change. This is terrible.
Likewise, tests / scripts written under one environment might suddenly start to fail because of a dependency update. The scripts might be poorly written in the first place, but it's not a reason to break them needlessly.
Those failures can be very hard to track down for people not intimately familiar with the CI / project setup, because suddenly things fail for reasons independent of their code. When dealing with a CI, you don't expect your main branch to suddenly turn red without change.

Some links:

Commit before update: https://github.com/bpfkorea/agora/commit/4fc127860126d78610676c92d49fdad55576aa66
Associated action run: https://github.com/bpfkorea/agora/runs/1024853508
Commit after update (which doesn't touch any code and just disables a test): https://github.com/bpfkorea/agora/commit/9cd2b987593b038caffa43b97c8b69bff4f03e1a
Run after update: https://github.com/bpfkorea/agora/runs/1032909322
The fix we needed: https://github.com/bpfkorea/agora/commit/2aab6f9de31a050f176c13bf40b05f8d96c5690b

This is not the first time it happens, but I'd like it if there could be a way to make it the last.

Hi @Geod24,
Thank you for detailed description and for raising this concern.
However, we do not have plans to support image versioning and there are few reasons for it:

It is complicated from the maintenance side to keep and support different images

Image versioning is not solving the initial issue with breaking changes in software updates: it wouldn't be possible to keep every image forever, and sooner or later image update will happen and it will bring a lot more issues that a weekly updated software.
On our side we have a significant amount of tests to catch as many breaking changes as possible, and we are constantly working on improving these tests and coverage but, unfortunately, we cannot test all possible scenarios.

To be aware about upcoming updates we are highly recommending tracking new releases in this repo where we post the upcoming software updates. In order to not miss any release you can subscribe to them to get notifications.

Your issue appeared after upgrading Visual Studio to 16.7 and most likely your build will fail on your local machine as well after this upgrade.
Please, let me know if you have any questions. Thanks!

Thanks for taking the time to write a detailed answer @AlenaSviridenko .
Just to be clear, I originally refrained myself from suggesting a specific approach, as I'm obviously not familiar with the culture or architecture of how things are delivered. However, you raised a few points which seems to be hinting at a specific solution (keeping all weekly images around forever), so I wanted to give some feedback.

It is complicated from the maintenance side to keep and support different images

I assume supporting means "providing security upgrades for old images" ? If so, I was not advocating for it.
I believe a simple "We release a frozen image every 3 months" would be enough to solve this specific issue, at least in my case.

Image versioning is not solving the initial issue with breaking changes in software updates: it wouldn't be possible to keep every image forever, and sooner or later image update will happen and it will bring a lot more issues that a weekly updated software.

The issue here is not so much about breaking changes or not, it's about controlling when it happens. Downstream developers want breakage to their projects to happen on their schedule, not on upstream's. SemVer is such a great framework not because it removes breaking change, but because it introduces specific points at which those needs to be dealt with.
As for keeping images around, we're talking about a few images per year (surely not all images), so I would image it isn't this hard.

To be aware about upcoming updates we are highly recommending tracking new releases in this repo where we post the upcoming software updates. In order to not miss any release you can subscribe to them to get notifications.

This got me a bit confused actually. I see you have a "Rollout progress" percentage in the readme. And the failure started last night (KST), while the offending release was 6 days ago. Which means that even if I was subscribing to this repository, the connection between the failure and the upgrade wouldn't be that obvious.
Which actually leads to a side question: Are runners tied to a project, or freely assigned ? Would it be possible for a project to be assigned one version of a runner for one PR, and another version for another PR, while the image is being deployed ?

Your issue appeared after upgrading Visual Studio to 16.7 and most likely your build will fail on your local machine as well after this upgrade.

My team develop on Linux / Mac, so it didn't.

Please, let me know if you have any questions. Thanks!

What would the JS ecosystem looks like without package-lock.json ?

As for keeping images around, we're talking about a few images per year (surely not all images), so I would image it isn't this hard.

I understand the reason for asking this and your idea, but supporting these images (there are still can be issues with the software even on a frozen images, so it is not only about security patches) and updating them, managing capacity for them and possible fragmentation would bring a lot of pain in maintaining.

And the failure started last night (KST), while the offending release was 6 days ago. Which means that even if I was subscribing to this repository, the connection between the failure and the upgrade wouldn't be that obvious.

Usually image is propagated to all customers in a 3-5 days after release is created.
But the process is built that way that is very unlikely that one PR uses updated version and another one not updated version.

What would the JS ecosystem looks like without package-lock.json ?

We would have to keep in mind all the required versions 🙂

would bring a lot of pain in maintaining.

Well, auto-updating just pushes the pain to consumers.

But the process is built that way that is very unlikely that one PR uses updated version and another one not updated version.

Even something that has one chance in a million to happen will happen pretty frequently with the scale you are dealing with.

We would have to keep in mind all the required versions 🙂

Good thing git commits and tags never go away :)

Since it seems that was already discussed internally, I guess I'll just have to agree to disagree, and I suppose I can work around this issue on my end by having my own runners.


GPU memory issue

Hello, when I reproduce your code during the training process, more and more GPU memory were used, there should be a GPU memory leak, try each epoch after using torch.cuda.empty_cache() effect is not obvious, is there any solution

48G显卡测试确实是能坚持一会儿，到接近60个epoch也会几乎炸掉，我是从14G泄露到47.8G


Write documentation about definition of Cloud Orchestrator and cvdr.

To write a new document under source.android.com, we need a document to define what's Cloud Orchestrator and cvdr. I thought here's the better place than source.android.com.
CWL(Cuttlefish Web Launcher, Page 0) is not scope of this PR for providing detail in public.

I'll submit this tomorrow, to catch a chance to be reviewed by @ser-io or @jemoreira.


Add output for the arn of the service

Do you mind updating the doc with the outputs please? I was hoping that rerunning the pipeline would do it, but it looks like our bot has no permissions to update it.

Hi @ewastempel, not sure what's going on with the docs action - it has been working before!
I'll take a look at it now

@ewastempel all passing now, and the docs bot has run 😄


Adds ability to change logging verbosity and adds more debug telemetry

Description

Adds several logging related features:

Ability to change logging verbosity through a cli arg or environment variable
Adds a unique trace id to all requests via context to link them together
Adds debug logging for upstream requests / responses with a unique request id

Note: at some point in the future it would be good to add headers to the logging, however we have to be careful about logging confidential credentials etc, so I've intentionally left that part out for now.
How Has This Been Tested?

Try this out with a real MR backend deployed to kind and a mock k8s client, e.g.
make run PORT=4000 MOCK_K8S_CLIENT=true MOCK_MR_CLIENT=false LOG_LEVEL=debug
Make some GET / POST / PATCH requests (the ones from the README are fine)
Verify you get the debug logging.
Also verify different log levels work, e.g. try info and verify the debug messages aren't there. Also try running without the LOG_LEVEL param to ensure it defaults to INFO.
Merge criteria:

All the commits have been signed-off  (To pass the DCO check)

[x] The commits have meaningful messages; the author will squash them after approval or in case of manual merges will ask to merge with squash.
[x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[x] The developer has manually tested the changes and verified that the changes work.
[x] Code changes follow the kubeflow contribution guidelines.

If you have UI changes

[ ] The developer has added tests or explained why testing cannot be added.
[ ] Included any necessary screenshots or gifs if it was a UI change.
[ ] Verify that UI/UX changes conform the UX guidelines for Kubeflow.

Yeah, I did think about this - I agree it would be really useful to have the k8s stuff logged too. The hard part is right now there's only a single, global k8s client, I guess if I can pass the trace id through at least we have a way of matching things up to a specific "transaction".
I'll take a look this afternoon, but will just have a quick chat with Eder first to see how the k8s client is likely to change.

I should probably add some documentation too!!!

/hold
We are gonna wait until https://github.com/kubeflow/model-registry/pull/599 is merged.

/unhold

@alexcreasy I think there's still some changes left but you can rebase this safely


ShamanProject: don't write broken repos

We saw several cases where repo file contents were actually small HTML
files containing "502 Bad Gateway" errors. This will cause ShamanProject
to raise an exception if that happens - and not write broken repo files.
Signed-off-by: Zack Cerza<EMAIL_ADDRESS>

Sigh, the circle of life^Wimports strikes again. Will repush shortly

test this please

jenkins test this please


Refactor code for organization and stream settings.

This is a prep PR so that we can reuse organizations settings code in #23013.

First commit is to remove unused handler.
Second commit is to move CSS for save-discard widget to app_components.css.
Third commit is to add id for display and notification settings.
Fourth commit is to refactor code that handles radio-type settings.
Fifth commit is to pass subsection element to get_subsection_property_elements.
Sixth commit is to rename the org-subsection-parent class.
Seventh commit is to refactor stream message retention setting.
Eigth commit is to refactor realm message retention setting (no UI or user-visible changes for now).

Screenshots and screen captures:

Self-review checklist

[ ] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[ ] Each commit is a coherent idea.
[ ] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

Cool, the stream permissions modal looks good to me!
For some reason the tooltip on the pencil icon for it sticks around when it shouldn't; it's still there after I edit the settings and save the changes, even if I'm no longer hovering over the pencil.

Since this is an intermediate state, I assume we shouldn't worry about error handling on the custom retention period for now.

Looks good to me, merged, thanks @sahil839!
@m-e-l-u-h-a-n FYI -- some of these renames may affect your ongoing work on user group settings.


Getting  Error: Command 0x3001a001 not found in bitstream while loading vivado 24.1 generated target for CW340 other project bitstream file

Description
I got the target FGPA board CW340 with me.
I am using the opentitan infrstructure to  be reused for  programing the FPGA with vivado 24.1 generated bitstream.
Here is what I got for the three run's

Opentitan bitstream run
$ ./bazelisk.sh run //sw/host/opentitantool -- fpga load-bitstream /home/lmsm/FPGA_CW340/gitlab/bitstream-latest/chip_earlgrey_cw340/lowrisc_systems_chip_earlgrey_cw340_0.1.bit
INFO: Analyzed target //sw/host/opentitantool:opentitantool (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
INFO: Elapsed time: 0.246s, Critical Path: 0.02s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action
INFO: Running command line: bazel-bin/sw/host/opentitantool/opentitantool fpga load-bitstream /home/lmsm/FPGA_CW340/gitlab/bitstream-latest/chip_earlgrey_cw340/lowrisc_systems_chip_earlgrey_cw340_0.1.bit
[00:00:21] [██████████████████████████████████████████████████████████████████████████████████████████████████████████████████] 34.18 MiB/34.18 MiB

Below is the run for our project1
(0s)lmsm@lalit-HP-PC:~/FPGA_CW340/gitlab/5Jun2024/opentitan$ ./bazelisk.sh run //sw/host/opentitantool -- fpga load-bitstream /home/lmsm/FPGA_CW340/thames/vivado_gui/work/kcu095/thames-fpga-kcu095/thames-fpga-kcu095.runs/impl_1/block_design_wrapper.bit
INFO: Analyzed target //sw/host/opentitantool:opentitantool (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
INFO: Elapsed time: 0.277s, Critical Path: 0.02s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action
INFO: Running command line: bazel-bin/sw/host/opentitantool/opentitantool fpga load-bitstream /home/lmsm/FPGA_CW340/thames/vivado_gui/work/kcu095/thames-fpga-kcu095/thames-fpga-kcu095.runs/impl_1/block_design_wrapper.bit
Error: Command 0x3001a001 not found in bitstream

Below is the run for our project2
$ ./bazelisk.sh run //sw/host/opentitantool -- fpga load-bitstream /home/lmsm/FPGA_CW340/thames/gitlab/pqs-hw-oskar/work/kyber-dilithium-cpkc/fpga/cw340/oskar-fpga-cw340/oskar-fpga-cw340.runs/impl_1/cw340_top.bit
Starting local Bazel server and connecting to it...
INFO: Analyzed target //sw/host/opentitantool:opentitantool (421 packages loaded, 22887 targets configured).
INFO: Found 1 target...
INFO: Elapsed time: 14.203s, Critical Path: 3.79s
INFO: 183 processes: 40 internal, 143 linux-sandbox.
INFO: Build completed successfully, 183 total actions
INFO: Running command line: bazel-bin/sw/host/opentitantool/opentitantool fpga load-bitstream /home/lmsm/FPGA_CW340/thames/gitlab/pqs-hw-oskar/work/kyber-dilithium-cpkc/fpga/cw340/oskar-fpga-cw340/oskar-fpga-cw340.runs/impl_1/cw340_top.bit
Error: Command 0x3001a001 not found in bitstream

Note on Vivado I am using the command to dump the bitstream for my two projects
launch_runs impl_1 -to_step write_bitstream -jobs 4
Any suggestion here what I am doing wrong here. Or if I have to switch to fusesoc

If you are building opentitan's bitstream, you should use the bazel target //hw/bitstream/vivado:fpga_cw340. Your bitstream is likely missing the command to write the USRACCESS register.

Thanks Will, how do I fix this in Vivado saved database to regenerate the bitstream.

Will, I am able to load the updated bitstream using the  bazelisk.sh command.


TAJO-1980: Printout the usage of TajoShellCommand

TajoShellCommand::getUsage() is designed for TajoShellCommand::printHelp() to printout detailed-usage like TajoShellCommand::getDescription(). But, Currently, It's omitted in TajoShellCommand::printHelp(), so TajoShellCommand::getUsage() has no usage.

@blrunner Hi! This PR is related to TAJO-1979.

You need to add some unit test cases to TestTajoCli because this patch will change the result of tsql help command.

@blrunner Thanks for your review. I add unit test.

@blrunner Thanks for your comment! I make test code little bit more simple using entrySet() .

+1
LGTM! :-)


Added ReactionType data type, fixed typing

The following changes have been made:

Added missing messageReaction() method to the TelegramUpdate object
Added information about DTO types Reaction and ReactionType to the documentation
The Reaction object now contains a collection of ReactionType objects rather than an array (added after a similar comment)
Added ReactionType object
In the handleChatReaction method of the WebhookHandler class, changed the typing of the $newReactions and $oldReactions parameters to Collection instead of array.

I apologize for this omission. I noticed it only now 😅
Why are all these changes all in one PR? It's simple! The code to be fixed is firmly bound to its "neighbor" and it's pointless, in my opinion, to create separate PRs that will load each other.

@fabio-ivona, @MarioGattolla, I've poured in improvements and fixes 🤗

@fabio-ivona I think the change of variable from array to collection (newReaction , oldReaction) could be a breaking change. Let me know if I'm wrong

confirm a BC here, @andrey-helldar could you fix?

@MarioGattolla, I was thinking the same thing and didn't expect the previous changes to be released so soon.
But the hope was that the fix would fly in so fast that hardly anyone would notice it :)

@fabio-ivona I can. Let's be more specific: you need to remove collections and return an array?
Also, I created a new data object there called ReactionType. Do I delete it too or can I make an array_map for it?

Ready

@andrey-helldar I agree that the change is fast, maybe we could try to release it as is
@MarioGattolla any thoughts?

@fabio-ivona I too sometimes release new versions and then quickly fix them before they get installed 😅

@andrey-helldar could you rollback the bc fix, I guess there's no harm if we release right now

@fabio-ivona, ok, I'm here

@fabio-ivona, ready

released, thanks guys :raised_hands:


Refactor Formatting For Simplicity and Readability

Awesome-go's formatting features a clean one line description while being uncluttered with links. This is a proposition to emulate that formatting.

...features a clean one line description...

Technically a "single sentence description" but I grok what you're saying. I'm in agreement that the current Awesome Elvish document is overly verbose and would be easier to read if link details were hidden. I suspect the original author chose the current format so the link could by copy/pasted into an Elvish use statement and because of the epm:install example. It's not clear the readability trade-off is worth the ability to copy/paste the package string (as opposed to the link).
Unsurprisingly there is at least one deviation in the Awesome Elvish document from the usual way to write such links: Package zzamboni/elvish-completions should be Package github.com:/zzamboni/elvish-completions to match the other links. That sort of deviation from the norm might be less common if every link of that type were written in [short description](url) form in the markdown document.

I admit I've also never been fully happy with the structure of this list. The main thing is that we have two levels: packages and libraries. A package may contain multiple disparate libraries, so it doesn't always make sense to list them together.
I think maybe a better format would be tables like this:

library
package
description

git
github.com/zzamboni/elvish-modules
Support for persistent aliases and for parsing bash-style alias commands.

That way every library could be listed in its own corresponding section, while still having a link to the package.
This would require some extra work for the initial conversion and for maintenance, but it might be worth it for readability.

FYI: elvish is now on awesome go

I did an extensive reformatting, please let me know what can be improved further!


Segmentation fault(core dumped)

Report error 'Segmentation fault(core dumped)' and interrupted training .What is this problem?

Mostly your tensorflow/python version is not compatible, need more info..

I'm also facing the same issue while I was training with complete OpenImages V5 dataset
how to solve this

Actually I solved it by deleting the old .pkl files which are loading back again try deleting them and train it worked for me.


Replace cache-padded with crossbeam-utils

We are currently planning on deprecating cache-padded and replacing it with crossbeam-utils' CachePadded structure. This PR replaces the usage of cache-padded with crossbeam-utils, which should be a 1-to-1 change.

Excellent, thank you very much!


Fix a couple typos in the Contributing file.

The typo in the project name is actually in the project name.  Have a look at https://github.com/HTBox/crisischeckin/blob/master/crisischeckin/crisicheckinweb/crisicheckinweb.csproj


Is "remove IR pattern" preset supported for model D455?

Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

Consider checking out SDK examples.
Have you looked in our documentations?
Is you question a frequently asked one?
Try searching our GitHub Issues (open and closed) for a similar issue.

All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

Required Info

Camera Model
D455

Firmware Version
<IP_ADDRESS>

Operating System & Version
Ubuntu 18.04.3

Kernel Version (Linux Only)
5.4.0-42-generic

Platform
PC

SDK Version
v2.36.0

Language
None

Segment
None

Issue Description
I have a latest D455, which seems to work fine with realsense viewer v2.36.0 under Ubuntu 18.04.3. However, when I choose the "remove IR pattern" preset, it gives me an error saying "the device doesn't support Remove IR Pattern Preset".
Some previous threads indicate that this functionality only works for D415
(https://github.com/IntelRealSense/librealsense/issues/6248), but I'm wondering is it supported (or any plan for supporting) for the latest model D455? Thanks!

Hi @zc08  Yes, the Left Imager Color w/o IR pattern is for D415 only
https://dev.intelrealsense.com/docs/d400-series-visual-presets#section-preset-table
You can though remove the pattern by disabling the IR Emitter.  In the RealSense Viewer's options side-panel, you can do this by left-clicking on the drop-down menu beside the Emitter Enabled option, under the Stereo Module section, and selecting the Off option from the menu.  To turn it back on, select Laser from the same menu.

Alternatively, the dot pattern can have its visibility reduced without disabling the IR Emitter by reducing the value of the Laser Power option under the Controls category of the Stereo Module options.  The lower the Laser Power value, the less visible the dot pattern will be.  Increasing the value increases the pattern's visibility.  A drawback of this method is that reducing Laser Power can make the depth image more sparse.

Thank you all for the helpful answers!
I'm still wondering when will this function be available (at least in the bleeding-edge repository so I could have a try) ? I'm really in bad need of this. Thank you!

Hi @agrunnet   Was the "remove IR" color correction for D455 included in the new <IP_ADDRESS> firmware please?   Thanks!

Sorry. Not in that version. Coming soon.

Thanks very much for the information @agrunnet !

Hi @zc08   Do you require further assistance with this case, please?   Thanks!

Case closed due to no further comments received

Is this preset still being added?

@bs97  I will ask Intel about your question.  Thanks for your patience!

Hi @bs97  The Remove IR pattern preset was created to address an issue with the projector on the D415 model specifically that does not occur on the D455 model.  The D455 model therefore does not require this preset.

@MartyG-RealSense I'm having the same issue with D435. When collecting images from objects at close range (0.3 m) the depth frame gets distorted if there is too much light in the scene. But, if I reduce the light to remove glare and improve depth the IR pattern shows up on the color image. Any ideas?

Hi @TucoFernandes  The IR pattern should not be leaking through to the color image, though it can happen in very rare cases.  If the scene is well lit then you could try disabling the IR emitter, as RealSense 400 Series cameras can alternatively use ambient light in a scene to analyze surfaces for depth detail instead of analyzing the IR dot pattern.
You could also reduce the visibility of the dot pattern instead of removing it completely by reducing the value of the Laser Power option.
A third possibility would be to fit a thin-film linear polarization filter over the lenses on the outside of the camera to significantly reduce glare from reflections.  These filters can be purchased affordably by searching stores such as Amazon for the term linear polarizing film sheet
Polarizing filters are discussed in section 4.3 of Intel's white-paper guide about using optical filter products with 400 Series cameras.
https://dev.intelrealsense.com/docs/optical-filters-for-intel-realsense-depth-cameras-d400#4-the-use-of-optical-filters
The image below taken from this guide section demonstrates the benefits of using this filter type to negate glare.

@MartyG-RealSense thanks for the fast reply, I will try to buy and try the filter. But do you have any idea why the IR pattern shows for the pyrealsense color image but not for the realsense viewer color image? I had the idea that the D345 had a separate color image and the IR would not show on it.

Yes, D435 has a separate color sensor, and the infrared dot pattern is not supposed to appear on the RGB image.  It is highly rare and not clear why it occurs.
The RealSense Viewer applies a range of post-processing filters by default, whilst self-created scripts do not apply these settings and they have to be manually programmed into a script in order to generate an image that more closely resembles those of the Viewer.  You could try left-clicking on the blue icon next to the Post-Processing option under 'Stereo Module' in the Viewer's options side-panel to disable all post-processing filters and see the effect that this has on the image.

@MartyG-RealSense  I'm generating the camera config json file using the intel realsense viewer and than loading it on my custom code. To me, it looks like some of the parameters are not being loaded. I will check them one by one then.

You are vorrect.  Not all Viewer options are exported to a json file.


[Docs]: State the recommended code editor used by developers (if applicable)

I don't know what the majority of people use, besides itoh with Helix, but I am under the impression most people use VSCode. I know we have VSCode settings as well, it may help new comers to state that we recommend VScode, assuming that we do in fact recommend is as the standard. This can help eliminate questions and help us tailor the documentation to the recommended editor.

This is actually already in the code for the website, so i will close the issue


Fix JS error when edit project column twice and fix empty column title

Reproduce:

click edit project column
click confirm
click edit project column again

And fix column title will be changed if the input is empty

Should this be backport?

Not sure which PR caused this issue.
Tested in 1.22.0-rc1, it works.

Odd. I can't imagine https://github.com/go-gitea/gitea/pull/30723 having caused this which is the only possible related commit not on the branch.

-> https://github.com/go-gitea/gitea/pull/30831/files#r1587965477

Better fix in https://github.com/go-gitea/gitea/pull/30831


ccze build fails on CentOS 6.7

Build output:
==> Downloading http://ftp.de.debian.org/debian/pool/main/c/ccze/ccze_0.2.1.orig.tar.gz
Already downloaded: /home/prologic/.cache/Homebrew/ccze-0.2.1.tar.gz
==> Patching
patching file src/Makefile.in
==> ./configure --prefix=/home/prologic/.linuxbrew/Cellar/ccze/0.2.1 --with-builtins=all
==> make install
Last 15 lines from /home/prologic/.cache/Homebrew/Logs/ccze/02.make:
make[1]: *** [ccze-color.o] Error 1
In file included from ccze-compat.h:28,
                 from mod_distcc.c:26:
/usr/include/errno.h:69: error: two or more data types in declaration specifiersmake[1]: *** [ccze-wordcolor.o] Error 1

make[1]: *** [ccze-compat.o] Error 1
echo "ccze_plugin_load_all_builtins (void)" >>ccze-builtins.c
make[1]: *** [mod_distcc.o] Error 1
echo "{" >>ccze-builtins.c
for p in apm distcc exim fetchmail ftpstats httpd icecast oops php postfix procmail proftpd squid sulog super syslog ulogd vsftpd xferlog ; do \
		echo "  ccze_plugin_add (&ccze_${p}_info);" >>ccze-builtins.c; \
	done
echo "}" >>ccze-builtins.c
make[1]: *** wait: No child processes.  Stop.
make: *** [install] Error 2

Can you post the full brew gist-logs ccze? Thanks!

From an Ubuntu 14.04 machine rather than a CentOS one, but it fails for me too: https://gist.github.com/rwhogg/863370fb3daa96f109de#file-02-make-L31

This error message is weird:
configure:4892: /home/bob/.linuxbrew/bin/gcc-5 -o conftest -Os -w -pipe -march=core2 -isystem/home/bob/.linuxbrew/include -L/home/bob/.linuxbrew/lib -Wl,--dynamic-linker=/home/bob/.linuxbrew/lib/ld.so -Wl,-rpath,/home/bob/.linuxbrew/lib conftest.c -lncurses  >&5
/usr/bin/ld.bfd.real: /tmp/ccOPjUqq.o: undefined reference to symbol 'dlopen@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

https://gist.github.com/rwhogg/863370fb3daa96f109de#file-config-log-L725-L728
If you want to try a workaround that might help:
brew install binutils glibc
brew postinstall gcc
```
If it does help, I really don't know why that should be necessary on Ubuntu 14. It's quite strange.

Never mind. My last comment is a red herring. The following configure check works just fine.
https://gist.github.com/rwhogg/863370fb3daa96f109de#file-config-log-L818
checking for dlopen in -ldl

Maybe this formula just doesn't like gcc 5.3. Try perhaps brew install ccze --cc=gcc-4.8


Add Guardian.Plug.Backdoor

Takes over from #120 by rebasing to latest master.
This pull request also adds the type option to set token type, and new_claims to inject claims into Guardian.Plug.sign_in/4.
Ping @aaronrenner @doomspork.

This is fantastic @jayjun!  @hassox will these changes impact your v1 changes?

It will but that's ok.
I'm not sure that trying to construct all the different parts of a token via the URL is a great way to go though. There are lots of different variations that will be possible in V1 and I'm concerned that trying to construct a token from url params will become tricky at best but impossible in some cases. What about cases where a different secret is used depending on the request etc. I'm also a little concerned about setting the new_claims when the plug is initialized since depending on how you do it it might not be appropriate for all tests but could be set once.
What would you folks think of putting a token into the URL rather than the components? This would let the token contain exactly what you need, be signed by the correct secret (for those using custom secrets) and in V1 allow you to specify exactly which token type you're intending on using.
{:ok, token, _} = Guardin.encode_and_sign(user, :access, new_claims)
navitage_to "/?access_token=#{token}"

I like it, for all the reasons you mentioned. Though I also like modifying User:X directly in the browser when debugging.
I don’t know what token variations are possible in V1, but even passing token components through the URL should still result in calling Guardian.encode_and_sign/3 anyway.
I suggest we go ahead with your suggestion first. If and when we implement constructing a token via URL, it will be a layer added on this work.

Cool... Another thought is that this is really not good to let escape by accident into environments other than dev and test.  Can you put a guard on the call so that we don't do this unless it's the correct environment?
TBH this plug makes me a little nervous :\

I'm not sure where this approach come from, so maybe what I'm going to propose doesn't fit for the needs.
If it's only purpose is testing, what about just creating a test helper to add the session needed for authentication? I've seen this pattern before in other libs and seems less intrusive (you don't have to include a if in your plug pipeline) and you authenticate the user clearly in the test.
What do you think about it?
PS. You are doing a great job in this release mates!

@odarriba It’s inspired by Clearance‘s backdoor for faster tests, and Mislav‘s backdoor hack for faster edit-compile-run cycles.
If I‘m not wrong, a test session can be added in just one call to Guardian.Plug.sign_in/4 without a test helper. That is what this backdoor essentially wraps.
Guardian.Plug.Backdoor is a plug so tests or users can bypass authentication plugs by appending ”magic parameters” to URLs. Alternative tokens can be tested really quickly.
navigate_to "/?as=User:5"        # assert success
navigate_to "/admin/?as=User:5"  # assert failure
navigate_to "/admin/?as=Admin:1" # assert success

As for raising, we’re not supposed to use Mix.env/0 during runtime. Maybe we swap the backdoor for no-op outside test environments?
I’m also happy to scrap this whole idea if risks outweigh benefits.

If there is protection against using it in prod environments, I don't see any issues then!

@odarriba With 7f07ab8, any chance of this bleeding into production is eliminated at compile time.
Really looking forward to seeing this merged 👍

Hello folks, I am in no way involved with this project and came across this PR purely by chance.
However, I couldn't help but notice that you are blacklisting Mix.env() == :prod rather than whitelisting dev and test. So what happens if someone has a custom MIX_ENV, e.g. MIX_ENV=staging or, more worryingly, MIX_ENV=production?

@codesparkle Excellent point! I’ll make the change now.

@jayjun I've been thinking about this behaviour a lot over the last couple of weeks.
I'm not sure that this belongs in Guardian itself. The challenge I have is that it's very focused on a particular use case that - whilst valid - also provides a way to severely compromise security if it's used incorrectly.
I'm hearing the need and like that there is a solution being developed but I'm thinking that a community library would probably be more appropriate.
@jayjun @scrogson @doomspork thoughts?

@hassox I think that's a very valid concern.  We could put this code in the org under Guardian.Test package and try to include some additional test helpers.  Then you could take this a step further by ensuring the dependency is limited to test.

@hassox @doomspork In hindsight, I absolutely agree that this should be a separate community package, either in Guardian.Test or by itself. That way, it can be excluded from production like so,
{:guardian_backdoor, ">= 0.0.0", only: [:test, :dev]}

As for restricting it to tests, I must add that backdoors have been invaluable for rapid development. In fact, not providing a community-vetted package may encourage others to write their own, which could cause more harm.
Having the backdoor in its own package has the benefit of allowing anyone to use it in tests only, or in development too.

@jayjun / @hassox — if we can agree on a package name I'll get the repo put up and the initial project kicked off.

Just so I understand...the point of this is to make it easier to build integration tests with things like Hound and Wallaby? I actually haven't used either of those testing libraries, so I need to educate myself there.

@doomspork I don't have a strong opinion on a name. I think it should be focused on testing though ;)

@scrogson the original PR (and this one) are based on the ideas shared in this ThoughtBot article: https://github.com/thoughtbot/clearance#fast-feature-specs

Cool.
So I'm just thinking of some options here...
I think because this functionality needs to be plugged into the user-land code we can't really rely on mix only including the code in :dev and :test as suggested above.
I would suggest that this code be conditionally included directly by the user-land code. Probably the best place would be in the user's guardian pipeline (v1).
defmodule MyApp.AuthPipeline do
  use Guardian.Plug.Pipeline, otp_app: :my_app

  if Application.get_env(:my_app, :guardian_backdoor) do
    plug Guardian.Plug.Backdoor
  end

  plug Guardian.Plug.VerifySession, claims: ...
  plug Guardian.Plug.VerifyHeader, claims: ...
  plug Guardian.Plug.EnsureAuthenticated
  plug Guardian.Plug.LoadResource, ensure: true
end

Then in config/test.exs:
config :my_app, :guardian_backdoor, true

The config option could be anything really. What do you think?
I realize that this still has the potential for mis-use as the backdoor can just be plugged without the wrapped conditional.

You're right, it can't be conditionally included at the mix level.  Good catch @scrogson!

Maybe instead of the wrapped conditional, we could require the otp_app option to be passed? The plug can check if Application.get_env(:my_app, :guardian_backdoor) returns true. If not, it won't be plugged.
If the otp_app option isn't provided, we blow up at compile time. We could also print a warning when the backdoor is plugged and we're not in the test environment. These should all be determined at compile time.

How about :guardian_backdoor with Guardian.Plug.Backdoor as the module name?

Strange, I wasn’t ignoring you @doomspork @scrogson. Your comments only showed up now despite older timestamps!
Conditional packages typically aren’t controlled at mix.exs alone. It’s idiomatic to add Code.ensure_loaded/1 in userland.
# mix.exs
{:guardian_backdoor, ..., only: [:test]}

# router.ex
if Code.ensure_loaded?(Guardian.Plug.Backdoor) do
  plug Guardian.Plug.Backdoor
end

Yes, it’s still dangerous without the conditional, but at least
{:guardian_backdoor, ..., only: [:test]}

plug Guardian.Plug.Backdoor

can’t even compile outside :test.

@jayjun yep, you are right about that. I like it!
My main concern now is maintaining yet another package.

@jayjun we have decided to move this out of guardian and into it's own package.  I will create the basic project structure in https://github.com/ueberauth/guardian_backdoor if you'd like to move these changes to there  😁


Support Python 3.9 and 3.10

This updates python_requires of the package. It also runs CI on Python 3.8 through 3.10. This triples the number of GitHub Action minutes used, which should hopefully not be a problem.
Fixes #1511

Out of curiosity, any reason why we are not supporting 3.11?

Yes, HELM doesn't work on Python 3.11 yet. I filed a new issue #1913 and added more details there.


RestAssuredMockMvc.standaloneSetup ignores RestAssuredMockMvc.config

I am using the standaloneSetup() in a Spring Boot 2 application to test controllers. I need to configure Jackson 2's ObjectMapper to generate correct timestamps for java.util.LocalDateTime. Therefore, the feature SerializationFeature.WRITE_DATES_AS_TIMESTAMPS shall be disabled.
    RestAssuredMockMvc.standaloneSetup(new NotificationController(notificationServiceMock));

    RestAssuredMockMvc.config = RestAssuredMockMvc.config().objectMapperConfig(objectMapperConfig().jackson2ObjectMapperFactory(
            (cls, charset) -> new ObjectMapper()
                    .findAndRegisterModules()
                    .configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false)));

The config is ignored by the test because the ObjectMapper is created by Spring in org.springframework.test.web.servlet.setup.AbstractMockMvcBuilder called by io.restassured.module.mockmvc.internal.MockMvcFactory#build.

Nearly a year later, I've found myself with the same issue.
You can use MappingJackson2HttpMessageConverter to achieve this.
https://stackoverflow.com/a/35323312/2521685

@cidus worked for me! Thanks a lot for posting this 😄


General discussion

Open topic... what are your thoughts on Unums?  Where are they useful?  When not?  Anything goes...

I don't know enough about the subject to judge if they are a good idea, but I can say that the book was very accessible and that I learned a lot about the topic of floating point numbers that I had trouble understanding before. And the ubit thing looks really elegant to me, but what do I know? I have to admit being biased towards hoping they will work as advertised, because

what is advertised is awesome
I love the idea of witnessing scientific breakthroughs like this, where it is breaking out of a local maximum by doing things differently instead of just faster

What I want should not matter of course, but I just mention it for full disclosure.
Realistically I think it's too early to tell though. There are people who have read the book and think it's great, there are people who really know a lot about the old ways of doing floating point math and traditional interval methods and so far they seem very skeptical, but the intersection between the two seems to be limited for now, so I'm still waiting for the experts to read the book and give feedback with full information on the proposal.

For reference, there's some interesting discussion so far on the julia-users mailing list: https://groups.google.com/forum/#!topic/julia-users/LbFCCeMv76M

Thanks for starting this discussion site, and for the kind words about the idea! I hope to be able to respond quickly to questions about unum arithmetic here.

Thanks John!  As I read the book there were some concepts that just "made sense" to me, and it's great to have a very easy to read book with enough visuals to both stay entertained and not get lost.  I do think that 90% of the value of unums lie in their potential as a great replacement to floats, but that could possibly be lessened with a good software implementation.  I hope I can help with that!

Since it's possible (and probable) for arithmetic on unums to produce ubounds, and ubounds are the objects that are closed under arithmetic, I think it might make sense to make ubounds be the first class objects, and consider alternative representations for the besides a pair of unums.
The main properties of ubounds are:

They represent a contiguous subset of real numbers.
Their endpoints may be independently open or closed.
Their endpoints are rational numbers where the numerator has a specified number of bits, and the denominator is of the form 2^n, where n may be positive or negative, and also has a specified maximum number of bits.
Arithmetic over them operates as specified in Gustafson's book.

It seems like the pair-of-unums representation has some redundancy that might be worth trying to eliminate. Here's one alternative encoding that I think can have the same 4 properties above:

The left endpoint is specified as a unum, and its ubit determines whether that endpoint is open or closed.
The width of the interval is specified by an integer giving the lexicographic distance from the left endpoint to the right endpoint, where "lexicographic" means to layout the the unums with the same utag as the left endpoint in value order, and count them. Every other one of these is open, and if the width causes the right endpoint to land on an open interval, then the right endpoint of the interval is open.

If you used a fixed size for the interval width, this saves you 1 utag. Alternatively, you could use a variable length encoding for the width, and then in the case of small intervals, which I suspect is the most common case, it lets you compress the width by a decent factor.
Since this format represents the same information as the pair-of-unums ubound, it should be possible to implement the same arithmetic on it. I'm not yet sure whether the implementation of that arithmetic would be more or less elegant and efficient than for the pair-of-unums ubound.

Did you read the part of the book about the "unify" and "smartunify" functions? They cover what you are suggesting.

I did read that part of the book. I might have misunderstood something, but I was under the impression that unify and smartunify always return either a single unum, or in the case of smartunify, sometimes the same ubound that was used as input.
It seems useful to me to have a representation for unums that can't be unified to a single ubound (e.g. because they span 0) that is as compact as possible.

Wow!  I have been working on my own unum implementation in julia for the last few weeks and all of a sudden my roommate checks and finds two others!  Ok...  So Tom - One difference between what I'm doing and what you are is that I'm padding my unums to align with architectural word size (a concession to the 'tyranny of the word size' as Gustafson says).  I'm not ready to push to github yet, but perhaps when I have mine up we can come up with some performance tests and see how things look?

Cool... Can you expand on how you are doing padding/alignment differently? If you have any other thoughts on implementation please let me know... It's not set in stone yet.
Just curious... Why aren't you ready to push to github? Most github projects are unfinished (just put a warning in the readme like I do)

On Aug 6, 2015, at 4:28 AM, ityonemo<EMAIL_ADDRESS>wrote:
Wow! I have been working on my own unum implementation in julia for the last few weeks and all of a sudden my roommate checks and finds two others! Ok... So Tom - One difference between what I'm doing and what you are is that I'm padding my unums to align with architectural word size (a concession to the 'tyranny of the word size' as Gustafson says). I'm not ready to push to github yet, but perhaps when I have mine up we can come up with some performance tests and see how things look?
—
Reply to this email directly or view it on GitHub.

Has anyone thought about the implementation of the g-layer yet?
It seems like that is by far the biggest challenge for an efficient software arithmetic implementation. It sounds like implementing some of the fused accumulation operations, like fdotu, will require rather large integer operations in the g layer. It seems like it will be painful to allocate new large storage areas for every arithmetic operation, but maybe there's no getting around it.


nix-repl: remove

The package was removed in 2018 and turned into a throw call. Let's drop it completely.
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

I think we should add a release note entry for the complete removal of this package, since it is technically still a breaking change.

Usually entry is added when package is removed, in this case package was removed in 2018. Users had many years to adjust.
perhaps we can move throw into aliases, but just given how old this is, i don't think its worth it.

Obsoleted by 14b118856b8a40493daf401a32de45f2e03fa8db


boostorg/exception failed due to error LNK2019 on MSVC

Environment:
VS 2017 + Windows Server 2016
Issue description:
Boostorg/exception failed to compile when updating Boost version to 68cc708 on MSVC. Could you please take a look?
log_x64_test_32.log
Reproduce steps:

git clone -c core.autocrlf=true --recursive https://github.com/boostorg/boost.git D:\Boost\src
open a VS 2017 x64 command prompt and browse to D:\Boost\src
.\bootstrap
.\b2 headers variant=release --build-dir=..\out\x64rel address-model=64
.\b2 variant=release --build-dir=..\out\x64rel address-model=64
.\b2 -j4 variant=release --build-dir=..\out\x64rel libs\exception\test

ErrorMessage:
no_exceptions_test.obj : error LNK2019: unresolved external symbol "void __cdecl boost::throw_exception(class std::exception const &,struct boost::source_location const &)" (?throw_exception@boost@@YAXAEBVexception@std@@AEBUsource_location@1@@Z) referenced in function main'

There are very recent changes in throw_exception, under BOOST_NO_EXCEPTIONS you must provide the function you're getting a link error for, one that takes the new boost::source_location as well.

Should be fixed.


Error on Mac: Package 'EPPlus 4.1.0' This package may not be fully compatible with your project.

@volkanceylan How solve this error when build the serene application on mac?
The full error:
Package 'EPPlus 4.1.0' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.

Serene.Core comes with EPPlus .NET core version, you probably installed a .NET framework version.

this worked for me
dotnet nuget locals all --clear


report fixes - continued

This PR contains two left overs from https://github.com/koding/tunnel/pull/31. It leaves code with errchecks complaining only about Close and GoAway, and some minor issues in test.
@rjeczalik after updating the repo we need to press "Refresh" on https://goreportcard.com/report/github.com/koding/tunnel, I hope it can be done with web hook.
BTW the code just went from B to A class ;)

@rjeczalik buffer write check was deleted thanks

@mmatczuk-stratoscale: Thanks, looks good! :-)

@rjeczalik I forgot to switch accounts....

@mmatczuk Yup, I figured it was you :o)


fatal: not a git repository (or any of the parent directories): .git

Steps to Reproduce

Cloned the repository, as per the instructions with the command:
git clone https://github.com/flutter/flutter.git -b stable
Ran 'flutter doctor' as per the instructions.
Receiving error message in the title.

Logs

Logs

I have no log files anywhere that I have been able to find, other than the `flutter --verbose doctor` command.

C:\Users\rickyf\Projects\src\flutter>flutter --verbose doctor
fatal: not a git repository (or any of the parent directories): .git
Building flutter tool...
Running pub upgrade...
[√] Flutter (Channel stable, 2.10.4, on Microsoft Windows [Version 10.0.19044.1586], locale en-US)
    • Flutter version 2.10.4 at C:\Users\rickyf\Projects\src\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision c860cba910 (5 days ago), 2022-03-25 00:23:12 -0500
    • Engine revision 57d3bac3dd
    • Dart version 2.16.2
    • DevTools version 2.9.2

[√] Android toolchain - develop for Android devices (Android SDK version 32.1.0-rc1)
    • Android SDK at C:\Users\rickyf\AppData\Local\Android\sdk
    • Platform android-32, build-tools 32.1.0-rc1
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.11+9-b60-7590822)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Community 2022 17.1.2)
    • Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
    • Visual Studio Community 2022 version 17.1.32319.34
    • Windows 10 SDK version 10.0.19041.0

[√] Android Studio (version 2021.1)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.11+9-b60-7590822)

[√] VS Code (version 1.63.2)
    • VS Code at C:\Users\rickyf\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension can be installed from:
       https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter

[√] Connected device (3 available)
    • Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.19044.1586]
    • Chrome (web)      • chrome  • web-javascript • Google Chrome 99.0.4844.74
    • Edge (web)        • edge    • web-javascript • Microsoft Edge 99.0.1150.55

[√] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

About my environment that might help:

I am working on a domain-joined computer, with my domain-joined account, which is a local and network-wide administrator account.
There are no GPOs affecting the command prompt or anything else that would lead me to believe this is a GPO misconfiguration causing this.
I am the network administrator, so I have full access to check and test anything within the network.
I have tried many different directories for the flutter source, from C:\flutter, to C:\src\flutter, to C:\dev\flutter, to finally, my personal Windows home folder C:\Users\rickyf\Projects\src\flutter -- all of which give the exact same result.
I have tried adding the C:*\flutter\bin\ directory (no matter where I had it installed) to both the system PATH as well as my user-defined PATH. Although I can launch the flutter command from the command prompt (showing the PATH works fine), I still receive the same fatal message.
Our anti-virus software (Sophos Endpoint) has the flutter directory and all contents in it's allow list, so it shouldn't be interfering with the flutter installation.
I have also remove the %APPDATA%\Local\Pub\cache folder as well as the .\flutter\bin\cache\ folder and still, same results.
Trying to launch a new Flutter project in Android Studio (despite still receiving the errors above) fails with the exact same error, and never lets me actually open or create that new project.

I followed the documentation last night at home on my personal computer and everything worked perfectly. This leads me to believe that something within flutter and a domain-joined computer might not be jiving well together? I'm not sure. I have no idea what else to try here. Please help! :)

Also, to point out, the .git folder IS present within the flutter directory, albeit when I clone the repo the .git folder shows up as a hidden folder (it did on my personal machine as well, but it still worked there).


Web http support

Initial support for tracking requests from webHttpBinding-based services (related to https://github.com/Microsoft/ApplicationInsights-SDK-Labs/issues/15)

Wow, thanks for implementing this so quickly!

👍


Lineage Registration: plot or store the angle betwee cell division directions

Currently the Lineage Registration plugin can be used to sort a TrackScheme and create tag sets. These output formats are useful, but the user does not get an idea how well the embryos are actually aligned. By computing and visualizing angles between matched cell division directions the user could get an understanding how well alignment works:

0 or 180 degree -> cell divisions directions are perfectly aligned, embryos develop very stereotypic.
90 degrees -> cell division are poorly aligned, there is no indication of a stereotypic development.

The Lineage Registration Plugin should be extended to output angles between cell division directions. Output formats: as feature in Mastodon, as plot.
Solution

Ask @xulman  and @tinevez how computation results can be stored as a feature inside a Mastodon project. Is it somehow possible to circumvent the FeatureComputer.
The LineageRegistrationAlgorithm computes the scalar production between cell division directions. https://github.com/mastodon-sc/mastodon-tomancak/blob/fcd2d45880cd9be67a3e5ea4276625eee715a0af/src/main/java/org/mastodon/mamut/tomancak/lineage_registration/LineageRegistrationAlgorithm.java#L92. This scalar product could be used to compute angles between cell division. The code should be changed accordingly and the results should be stored as map (from Spot to double) in the LineageRegistrationResults.
The LineageRegistrationDialog should get an additional button, to store the angles as Features in the Mastodon projects. There could also be a button to directly plot the angles over time.

Hello @maarzt
I am not sure we have to workaround the feature framework totally.
 If we can link it to an existing mastodon object then we can use a Feature to store the value. For instance it can be stored in a BranchVertex no?
Also, we don't have to use a FeatureComputer. We can have a generic Mastodon plugin that computes these values and store then in a Feature. Then declares the Feature to the FeatureModel. We just have to be careful about what we do when a branch vertex is deleted or added, but we should be fine.

( I think the discussion continued here: https://imagesc.zulipchat.com/#narrow/stream/327470-Mastodon/topic/Loading.20pre-computed.20feature.20in.20Mastodon )


Testing of datepicker with protractor

Bug, feature request, or proposal:
I'm trying to e2e test with protractor a page containing a angular material datepicker. I'm using the latest version of Angular and Angular material (7). I'm matching the input field
await $('input[placeholder="mytext"]').clear();
await $('input[placeholder="mytext"]').sendKeys("01.01.2011");
The sendkeys works but not the clear. Usually that's the way to clear an input field. I'm using Chrome as a test browser.
What is the expected behavior?
$().clear() should clear the input field.
What is the current behavior?
$().clear() does nothing.
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Angular 7
Typescript 3.1.x
Latest chrome

Any updates here?


insight 的权限角色未找到

Describe the bug
A clear and concise description of what the bug is.
如下图，这几个角色没找到，如”NS Admin “，在全局管理-工作空间没有，全局角色也没有
https://docs.daocloud.io/ghippo/permissions/insight/

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

@justedennnnn  帮忙看看，可以加一些说明或链接，怎么找到这个角色


add istioctl build for ARMv7 and ARM64

[X ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

Hi @dave93cab. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@googlebot I signed it!

I did a make istioctl-all and ARMv7 binary appears to work

@dave93cab: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-test_istio
07ddeb78edfd21330578a90d6988536b9b90e075
link
/test release-test_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@dave93cab: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-test_istio
07ddeb78edfd21330578a90d6988536b9b90e075
link
/test release-test_istio

unit-tests_istio
07ddeb78edfd21330578a90d6988536b9b90e075
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn I found this in the release-builder, bolded where it could be changed to linux-amd64 as I named it in this PR. Or I can revert to amd64 build just being called 'linux' which I think will pass the test. Let me know what makes sense and I can update.

// We build archives for each arch. These contain the same thing except arch specific istioctl
	for _, arch := range []string{"**linux-amd64**", "osx", "win"} {

Do you think it makes sense to have istioctl-linux just build all 3
targets? So you can build individual architectures or run istioctl-linux
and it builds them all
On Sun, Mar 22, 2020, 9:27 PM dave93cab<EMAIL_ADDRESS>wrote:

@howardjohn https://github.com/howardjohn I found this in the
release-builder, bolded where it could be changed to linux-amd64 as I named
it in this PR. Or I can revert to amd64 build just being called 'linux'
which I think will pass the test. Let me know what makes sense and I can
update.
// We build archives for each arch. These contain the same thing except arch specific istioctl
for _, arch := range []string{"linux-amd64", "osx", "win"} {
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/22381#issuecomment-602378375, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXISGCWWQBAHGVPFIPTRI3QMDANCNFSM4LRQ2IJA
.

// Copy the istioctl binary over
istioctlBinary := fmt.Sprintf("istioctl-%s", arch)

and (where standalone istioctls are released)
if err := createStandaloneIstioctl(arch, manifest, out); err != nil {
    return err
}

both take place in a loop over those arches in my previous comment and expect the - suffix.
It wouldn't take much to move the standalone generation out of that loop to create them from their own set of arches, and leave the amd64 arch named as it is
How do you sync up changes to the release builder and the istio repo if changes to both are required?

It's a bit of pain unfortunately. I think you would need to make a
backwards compatible change to istio, update release-builder, then you can
update istio to use the new release builder and remove the backwards
compatibility bit (if needed)
On Sun, Mar 22, 2020 at 9:48 PM dave93cab<EMAIL_ADDRESS>wrote:

// Copy the istioctl binary over
istioctlBinary := fmt.Sprintf("istioctl-%s", arch)
and (where standalone istioctls are released)
if err := createStandaloneIstioctl(arch, manifest, out); err != nil {
return err
}
both take place in a loop over those arches in my previous comment and
expect the - suffix.
It wouldn't take much to move the standalone generation out of that loop
to create them from their own set of arches, and leave the amd64 arch named
as it is
How do you sync up changes to the release builder and the istio repo if
changes to both are required?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/22381#issuecomment-602383540, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXJNHNWVPLLP5KDEQCTRI3S3FANCNFSM4LRQ2IJA
.

/retest

@howardjohn wondering your thoughts on the following:

[istio] add istioctl-linux and istio-linux-amd64 to build (using same arch)
[release-builder] update arch linux -> linux-amd64
[release-builder] add istioctl standalone generator loop (linux-armv7, linux-arm64)
[istio] remove istioctl-linux build

I guess this comes down to whether you want the release package to change from istio-linux to istio-linux-amd64 which may be useful if somebody manages to get the entire istio to build for arm in future

We package istio-X and istioctl-X, but in reality the only difference
between istio-linux and istio-mac is istioctl itself. Everything else is
pretty much just yamls. So we probably want to release an istio-arm and
istioctl-arm for consistency?
On Mon, Mar 23, 2020 at 8:29 AM dave93cab<EMAIL_ADDRESS>wrote:

@howardjohn https://github.com/howardjohn wondering your thoughts on
the following:

[istio] add istioctl-linux and istio-linux-amd64 to build (using
same arch)
[release-builder] update arch linux -> linux-amd64
[release-builder] add istioctl standalone generator loop
(linux-armv7, linux-arm64)
[istio] remove istioctl-linux build

I guess this comes down to whether you want the release package to change
from istio-linux to istio-linux-amd64 which may be useful if somebody
manages to get the entire istio to build for arm in future
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/22381#issuecomment-602675243, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXJ7ZEBZ424Z57RRSXDRI557HANCNFSM4LRQ2IJA
.

Oh I see. So can just modify the arches to include the arm builds then. A modified plan:

[istio] duplicate istioctl-linux with new istioctl-linux-amd64 in build (using same arch)
[release-builder] update arch linux -> linux-amd64
[release-builder] add arches linux-armv7, linux-arm64
[istio] remove istioctl-linux from build

This will result in following linux arches in release:

istio-linux-amd64 (was istio-linux)
istio-linux-armv7
istio-linux-arm64

hi @howardjohn, any thoughts on that plan? I can modify this PR and do the required PR on the release builder if it's a go. Thanks

SGTM, should have another release owner give this a quick look though
@ericvn @sdake @brian-avery @esnible

@howardjohn LGTM. armv7 is a bit off from standards set by other T&R teams within the cloud-native ecosystem. Perhaps just arm would do, although I don't know enough about armv7 to make the qualified judgment.
We also don't need a duplicate istioctl-linux - perhaps that could just be removed later as a followup.
The code itself and plan looks good.

@sdake see this in the go docs regarding arm / armv7 https://github.com/golang/go/wiki/GoArm#supported-architectures

Starting from Go 1.1, the appropriate GOARM value will be chosen if you compile the program from source on the target machine. In cross compilation situations, it is recommended that you always set an appropriate GOARM value along with GOARCH.

and yes the duplication would only be temporary to not break the builder before changing it

/retest

@howardjohn @sdake Added PR to release-builder:
https://github.com/istio/release-builder/pull/179

waiting this release 🙏
good work.

https://github.com/golang/go/wiki/GoArm#supported-architectures

As part of the review, I found this link via google already. It still didn't really answer my statement as to whether arm or arm7 is more appropriate for the binary name.
To dig into the question a little more, is arm sufficient to run on all 32-bit arm architectures, and arm64 sufficient to run on all arm64 architectures, or, do we need:

arm
arm7
arm64

@dave93cab for now, we can punt on the v7 vs not v7 question and handle in a followup.


Update portainer password

USER STORY:
When the portainer password is updated, it is not correctly forward to the container. The only way to do it now is to delete and create the secret again, and to delete the portainer volume.
DEFINITION OF DONE:
When the password of portainer is updated on repo.config and when portainer is restarted, the new password should work.

moved to new ops-repo


Is "bazel-bin/src/envoy/envoy" the binary that was built to be used as istio-proxy ?

Hi ,
We are trying to build istio-proxy from the source code after pulling the code from "https://github.com/istio/proxy" .
a. git checkout -b release-1.6. (We require 1.6 to be build)
b. And installed required prerequisites.
c. cd proxy
d. make
e. make build_envoy
After the above ran successful , we can see the executable below got generated and build messages shown succesfull.
proxy/bazel-bin/src/envoy/envoy
a. Can we assume that we build properly?
b. Would there be any other executable get generate ?
c. Is the "proxy/bazel-bin/src/envoy/envoy" expected binary to be build ?
Thanks,
Pavan

There are also several wasm binaries. You can look at the commands that are executed at istio proxy postsubmit which pushes the needed binaries to GCS bucket: https://prow.istio.io/view/gs/istio-prow/logs/release_proxy_release-1.6_postsubmit/1329618154929786880. Specifically look for the make command executed there.

Thanks for your reply and the quick response..will check that..

I am getting segmentation fault with the built envoy .Can you help here?
bash-4.2# ./envoy --version
Segmentation fault
bash-4.2# pwd
/proxy/bazel-bin/src/envoy
bash-4.2# ls -lrt
total 1466852
drwxr-xr-x 6 root root       4096 Jan  4 11:03 http
-r-xr-xr-x 1 root root     323043 Jan  4 11:05 envoy-2.params
drwxr-xr-x 7 root root       4096 Jan  4 11:06 tcp
-r-xr-xr-x 1 root root        208 Jan  4 11:07 envoy_tar.args
drwxr-xr-x 3 root root       4096 Jan  4 11:07 _objs
-r-xr-xr-x 1 root root<PHONE_NUMBER> Jan  4 11:08 envoy
bash-4.2#

I am getting segmentation fault with the built envoy .Can you help here? bash-4.2# ./envoy --version Segmentation fault bash-4.2# pwd /proxy/bazel-bin/src/envoy bash-4.2# ls -lrt total 1466852 drwxr-xr-x 6 root root 4096 Jan 4 11:03 http -r-xr-xr-x 1 root root 323043 Jan 4 11:05 envoy-2.params drwxr-xr-x 7 root root 4096 Jan 4 11:06 tcp -r-xr-xr-x 1 root root 208 Jan 4 11:07 envoy_tar.args drwxr-xr-x 3 root root 4096 Jan 4 11:07 _objs -r-xr-xr-x 1 root root<PHONE_NUMBER> Jan 4 11:08 envoy bash-4.2#

need more info, os、arch etc.

Here is the info , i am trying to build envoy .
bash-4.2# cat /etc/os-release
NAME="Oracle Linux Server"
VERSION="7.9"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.9"
PRETTY_NAME="Oracle Linux Server 7.9"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:7:9:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://bugzilla.oracle.com/"
ORACLE_BUGZILLA_PRODUCT="Oracle Linux 7"
ORACLE_BUGZILLA_PRODUCT_VERSION=7.9
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=7.9
bash-4.2# uname -a
Linux a7477a64df7b 5.10.76-linuxkit #1 SMP Mon Nov 8 10:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
bash-4.2#

Here is the info , i am trying to build envoy .
bash-4.2# cat /etc/os-release NAME="Oracle Linux Server" VERSION="7.9" ID="ol" ID_LIKE="fedora" VARIANT="Server" VARIANT_ID="server" VERSION_ID="7.9" PRETTY_NAME="Oracle Linux Server 7.9" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:oracle:linux:7:9:server"
bash-4.2# uname -a Linux a7477a64df7b 5.10.76-linuxkit #1 SMP Mon Nov 8 10:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux bash-4.2#

did the make build_envoy completed correct?
as I can remember, envoy support Ubuntu officially in 1.6.

Yes received successful image.

I assume people succesfully built(istio-proxy and envoy) binaries on top of RHEL . Please correct me if my understanding is wrong.

I assume people succesfully built(istio-proxy and envoy) binaries on top of RHEL . Please correct me if my understanding is wrong.

If you just want to build an binary,  use docker is better choice.

Thanks for your patience and the responses.
a. Our requirement was to build istio-proxy and envoy from source code on top of RHEL . And I am stuck at the below steps.

Sucessfully built envoy binary but facing segmentation fault when trying to run the executable.
I dint see any separate istio-proxy binary generated after I ran (make and make build_envoy from source code).

It would be really helpful if you can throw some help/pointers in the above issues.

Ok for debian platform, I see there is one "istio-proxy" is being packaged as part of this target (https://github.com/istio/proxy/blob/release-1.6/tools/deb/BUILD) . So I thought , it might be available for RHEL too.

Ok for debian platform, I see there is one "istio-proxy" is being packaged as part of this target (https://github.com/istio/proxy/blob/release-1.6/tools/deb/BUILD) . So I thought , it might be available for RHEL too.

this vm doc may give you some help.

I built using "make build_envoy_tsan" target , that seem to resolve the issue and I can see no longer segmentation fault . Is it correct ?
bash-4.2# bazel-bin/src/envoy/envoy --version
bazel-bin/src/envoy/envoy  version: 4dc5fec0086ad5c00dba0b397c71ef523424ded5/1.14.5-dev/Modified/DEBUG/BoringSSL
bash-4.2#

I built using "make build_envoy_tsan" target , that seem to resolve the issue and I can see no longer segmentation fault . Is it correct ?
bash-4.2# bazel-bin/src/envoy/envoy --version
bazel-bin/src/envoy/envoy version: 4dc5fec0086ad5c00dba0b397c71ef523424ded5/1.14.5-dev/Modified/DEBUG/BoringSSL
bash-4.2#

@kyessenov maybe you know the diff between make build_envoy_tsan and make build_envoy and why there's no longer segmentation fault.


[Awaiting CI Confirmation] Scheduler workflow perf test app + original workflow perf test app

Updating the workflow perf test to have 2 apps, one for the original workflow test, and one for the workflows using scheduler under the hood. Going to test this in CI rq here

See the successful run of the workflows perf test with this change. Now we test workflows regularly and workflows with scheduler.


Error message risk evaluation i-phone

I had an error message for several days that risk evaluation is not possible (CWA not used for a while). It took very long to find the reason: Obviously a combination of energy saving mode and automatic background updates (in general and for the app) switched off. I think that many users won‘t search for the reason and simply deactivate the app thinking it does not work.
The app should inform the user about the reasons and guide the user exactly what to do.

Are you maybe talking about this issue? https://github.com/corona-warn-app/cwa-app-ios/issues/741

yes, this was the error message and issue (obviously known already). Thank you for the fast reaction!
Von meinem Mobiltelefon gesendet
Am 19.08.2020 um 14:55 schrieb Daniel Frey<EMAIL_ADDRESS>
This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments
Are you maybe talking about this issue? corona-warn-app/cwa-app-ios#741https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcorona-warn-app%2Fcwa-app-ios%2Fissues%2F741&data=02|01|markus.kraus%40eon.com|8b75f80c24794dd2430208d8443f1a97|b914a242e718443ba47c6b4c649d8c0a|0|0|637334385108806538&sdata=1L1ETqtrVa0MgC1cSqNTW0KMDoAFcbpmsDPCWA7kmk8%3D&reserved=0
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcorona-warn-app%2Fcwa-wishlist%2Fissues%2F159%23issuecomment-676307892&data=02|01|markus.kraus%40eon.com|8b75f80c24794dd2430208d8443f1a97|b914a242e718443ba47c6b4c649d8c0a|0|0|637334385108816537&sdata=qnPsKeTYDaJQt46zjifrlex9uwmQ0AVvBwPwbgbMr0s%3D&reserved=0, or unsubscribehttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAQVIFOMQHZWUM32CXU3WTQ3SBPDSXANCNFSM4QEW6WPQ&data=02|01|markus.kraus%40eon.com|8b75f80c24794dd2430208d8443f1a97|b914a242e718443ba47c6b4c649d8c0a|0|0|637334385108816537&sdata=R2eMgo%2B5q2q7UBXQUJOzSCP%2FRsWuTFQz8J%2BvXip4acs%3D&reserved=0.

In the next version we also improved the help text for this issue


audio language sort filter

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

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

Please make sure the question is worded well enough to be understood
I wanna listen to Mr Beast in French. Sometimes it won't be available. In that case, I wanna switch to Spanish. If not both, fallback to English.
In this case, how to use lang filter sort? Is the following right ?
-S "lang:[fr,sp,en]"

Is the following right ?
-S "lang:[fr,sp,en]"

No, with the -S argument, for most fields you can only provide 1 preferred value. For example, -S lang:fr is correct, but it won't accomplish what you want by itself.

I wanna listen to Mr Beast in French. Sometimes it won't be available. In that case, I wanna switch to Spanish. If not both, fallback to English. [...] how to use lang filter sort?

I'd use format filtering like this: -f "bv*+(ba[language=fr]/ba[language=es]/ba[language=?en])/b"

AFAIK no. The example you linked to is a regex pattern, with which you are not able to specify order of preference


TSC / TS language server version mismatch can only be 'ignored' globally

VSCode Version: 1.5.0

The check if the globally installed tsc version matches the TS version has a "Don't check again' message box. If pressed we never check again, even if the user opens another workspace. The reason why I did this is that the tsc is global. Now that I think about it again I am wondering if we should check once per workspace.
@waderyan @egamma opinions?

Let me make sure I understand.
Status quo - We show a message indicating that there is a version mismatch between TSC / TS language server, but only for the globally installed version of tsc. We give the user the option to "Don't check again". If the user clicks "Don't check again" we will never show the message again for any workspace.
The risk with the status quo is that users may have installed tsc locally to their workspace. Users may have different versions of tsc for each workspace. If this is the case then we should check for each workspace and let them know if their is a mismatch.
Proposal - Run the check for each workspace. If a local version of tsc is detected and it is a different version than TS show the message for each workspace. Allow the user the option to "Don't check again." for the workspace. This handles the local tsc installation, but risks showing too many messages.
Is my understanding correct?

No. If there is a local version of the TS installed and used by tsdk setting then we don't perform any checks since we assume that the suer knows what he does (he was adding the setting). If we detect a local installed typescript and it is not used and differs from the version we ship we show a warning. However if the user pressed Don't check again we never check again on any workspace. This one should actually be done per workspace. The tsc check should may be stay globally since the tsc compiler is globally installed.

@dbaeumer thank you for clarifying. My opinion is that the check per workspace makes sense. The message should be "don't check for this workspace" or something to indicate that the check will only be ignored for the workspace.

Discussed with @egamma and we decided to not do something for 1.5.x. For 1.6 we will get settings API and can do much better anyways.

Addressed for 1.6. I also update the settings files. Test plan item is here:  https://github.com/Microsoft/vscode/issues/12680

Verified and also looks like this is part of the test plan item

any steps to make them matching except clicking "don't show again"?