Don't re-scan unchanged, recently-scanned posts; Add EditWatcher to detect grace period edits

This adds every question which is scanned (or the question for any answers) to a SE WebSocket subscription and monitors the questions/answers for edits. If an edit is detected, then the question (and answers) are added to the BodyFetcher queue.
Changes

Getting the list of SE Site IDs, site_id_dict, [A dependency for DeletionWatcher, EditWatcher, and watching for posts on Meta sites (not in this PR)

Changed from in deletionwatcher.py to datahandling.py
Uses https://meta.stackexchange.com/topbar/site-switcher/all-pinnable-sites instead of https://meta.stackexchange.com/topbar/site-switcher/site-list, as the all-pinnable-sites is in JSON and includes IDs for all Meta sites (enabling watching Meta sites, which isn't in this PR, but should be soon).
The list is cached and updated daily.

Thread safety improvements

Lots of changes to use locks for both reading and writing in many places where they are only used for writing.
Use call_soon_threadsafe() instead of call_soon in Tasks
various in DeletionWatcher
various in BodyFetcher (BF), datahandling for BF

Helper functions

Helper function add_to_global_bodyfetcher_queue_in_new_thread() to enable easier adding to the queue from multiple places and indicating in the thread name from where the item was added.
log_current_thread() to log with the name of the current thread
append_to_current_thread_name()

Main SE WebSocket

When using queue depths of 1, skip pre-testing the 155-questions-active data

EditWatcher

Based on DeletionWatcher, this is an SE WebSocket connection to watch individual questions for edit activity.
It receives question IDs from the main 155-questions-active list, the scanning in BodyFetcher, and posts scanned manually via SD command
When an edit is detected, the question is scheduled for scanning by BodyFetcher

BodyFetcher

Add Recently scanned posts:

This is a list of posts which have been recently scanned. Currently, it keep entries for 60 minutes.
Prior to sending posts to be checked for being spam, it is first check to see if the post is in the recently scanned list and that its title, Markdown body, and username content matches what was previously scanned. If the content is a match, then it's not scanned. In addition to catching grace period edits, it also substantially reduces the number of posts scanned, due to not re-scanning posts many times (currently we rescan SO posts quite significantly, due to always fetching all recent posts, not just posts we know about).

Move some longer operations (e.g. disk operations) into Tasks, so the main scanning is not as impacted.

Don't allow more than one of the same action to be in the Tasks queue at a time for some actions which are identical (e.g. saving data to disk).

Don't perform some operations which are only for flovis when flovis is disabled.
Rewrite the loop for picking a site from the main site posts queue:

Add a determination of current CPU load. If the load is too high (currently >98), prevent having an additional scanning thread.
Add a maximum number of scanning threads per site: currently 5 for SO, 3 for all others
If there are new detections triggered on a post that is edited and rescanned, then report it (currently they are not reported, due to being previously reported).
Prevent multiple scanning threads from scanning the same post at the same time. This can be quite important for posts which take longer to scan. Prior to limiting threads per site and launching threads when already at high CPU load, an example was seen where ~10 threads were testing the same post.
Thread name shows which posts are to be processed and which posts have or are being processed, along with the times for some operations. This is primarily for debugging. However, there's data here that would be nice to surface in response to commands. It's currently a hack and really should be completely re-written.

SD commands

!!/queuestatus now explicitly states the queue is empty, rather than giving no response.

SD operation

core_files updated with missing files, so SD will reboot when non-blacklist files are changed.

Testing on SD for this PR was done in Makyen Test 02 starting about here, but the more interesting results were in later days, with the final operation near the end of testing for this PR.

Shortly prior to me submitting this PR, it was announced by SE that they have changed the requirements for being able to create grace period edits. Now, users with < 10 reputation will have all revisions to their posts recorded (i.e. they won't be able to make "grace period edits" which are unrecorded by the system).
That adjustment changes the urgency for the need for the code contained in this PR. However, changes include here are still desirable to include in SD for the associated changes/fixes which surrounded the addition of EditWatcher. EditWatcher itself is still desirable, as it will detect grace period edits by users with > 10 reputation.

Still very desirable, which is not currently in this PR, is to add CI tests to cover thee areas of functionality. Currently, there's nothing in the CI testing which covers the functionality contained in bodyfetcher.py.

An impressive improvement, by first glance. I don't know when I can review this properly, but with the testing you have done already, I would not be opposed to merging this before that.

The addition of several new threads and multiple new locks is unnerving. We are getting to the place where we should have an architecture diagram or something to provide an overview of these complexities. Not a blocker for this PR, and I'm hesitant to add a separate issue at this point, but noting this for possible further discussion.

Maybe spell out "RS" in the commit messages? I can guess from context but it's probably going to be hard to figure out if it comes up in git blame or etc.

I have reviewed all the commits and added some comments on things which might require some additional polish; but I'm fine with this being merged in its current shape, too.
Please understand, though, that I have a very cursory understanding of the crucial parts of this, and in general the huge ball of hair that is the queue handling around the Stack Exchange API in Smoke Detector (and also Flovis).
It would be nice to have more test cases around this, but the parts which are (to my mind) most likely to fail are probably around deadlock or race condition situations which are quite challenging to create adequate and realistic test coverage for. It should be done, I hope, but I don't think it makes sense to block this PR on requiring that.
In so many words, my approval is based more on trust than understanding.

I agree the addition of new locks is concerning. How much of an impact they were having is one of the reasons I've had the debugging output that's in the currently final commit (it's something that I've been using in testing and kept updating to a single last commit, so I could easily remove it) to show how much time was being spent waiting for locks. In all testing, it's been negligible, always showing as, at most, 0.01 second per lock. The current debugging code puts the current state, including effectively being able to see what lock is being waited for into the thread name, which makes it visible when the !!/threads command is run. [NOTE: I'm rewriting that logging/reporting (it being really hacky is annoying :; ) and planning to have SD commands to provide reporting of more scanning performance data, including being able to see which posts take a long time to scan, retain seeing that information and the post currently being scanned in the !!/threads output.]
I definitely agree there should be better guards against deadlocking and there should be reporting into chat when resources are exhausted for extended periods of time (e.g. CPU, per-site scan threads, etc.). I've intended to have such. I really didn't feel this area of changes was finished, but put them into a PR now due to the, at the time, urgency of getting grace period watching available. Ironically, we were informed about SE eliminating grace period edits for low level users while I was actually in the process of writing the initial comment message on this PR. Given that, now, there's not nearly as much urgency for detecting grace period edits, I have no problem spending the time to add better handling and reporting of such things, even prior to merging these changes.
The locks which are most likely to be exhausted or deadlock are the ones for the maximum number of scan threads per site, which is logged, but not currently reported into chat, which it should be if it lasts for an "extended" period of time. That's fairly important, as it would indicate if some other deadlock has occurred which caused scan threads to stall (or error out without releasing). It's probably even more important, as I'm planning on changing the test_post() code to at least partially run the detections in parallel (at least minimally separate out the tests which are asynchronous in nature, i.e. those making network calls, and run those in parallel, rather than everything sequentially).
Similar to the max per-site threads, when SD doesn't launch a new scanning thread due to CPU exhaustion is logged, but it, also, should be reported into chat if it's happening for an "extended" period of time.

@tripleee Thank you for spending the time to review this, I appreciate it quite a bit.

I agree that a higher level description of the architecture would be helpful. There have been various times when I've had to expend not a small amount of time trying determine from a higher level POV what is supposed to be happening in various areas of SD's code. It would be nice to have it better documented.

CI test cases would be great. There are, currently, none for the entire area of functionality affected by this PR.

@tripleee

Maybe spell out "RS" in the commit messages? I can guess from context but it's probably going to be hard to figure out if it comes up in git blame or etc.

I'm not really sure what you're asking for here.
I agree that it would be helpful to be able to see which, general, area of the code is being affected with each commit when just looking at a list of the commit messages and/or what the commit is doing (e.g. BUGFIX, DEBUG, FIXUP, etc.). At least with userscript repositories where there are multiple separate scripts in the same repository, I've been using a short prefix to commit messages to indicate which script is affected by a commit. I'd be quite happy to adopt something similar for SD to indicate what area of functionality is being affected by a commit. I routinely look at commits as, primarily, just a list of commit messages (with branch threading shown). I'd definitely find it helpful to use something similar here. However, I'm not sure that's what you're inquiring about.

The recent commits add:

import style changes which were requested in review
Chat reporting for extended periods of CPU starvation and/or starvation of per-site scanning threads
Re-implementation of the scan tracking in the thread-name which was considered debug code in prior versions.

The information is displayed in the results of the !!/threads command and in the console output at the "debug" loglevel.
This also changes the !!/stats command to provide more information. See this chat message for an example

:61146836 Posts scanned: 718, Q(398), A(320); Scan time: 776.89; Posts per second: 0.92; Grace period edits: 32; Unchanged posts: 6643, Q(3366), A(3277); No post lock: 11; Errors: 0; Max scan time: 19.17; Max scan time post: stackoverflow.com/72266934; Post processing lock: 0.11; Check unchanged: 0.26; Scan question: 677.96; Scan answer: 96.89

Re-introduced having the scan threads re-check for additional queue entries upon completion of the posts they were invoked to test.
I had this in earlier versions, but it introduced problems, which were probably mostly CPU overloading issues. With the limitation on starting a new site/posts set, having it in there doesn't appear to be causing issues. It does resolve the issue that having queue depths of 1 means we need to be, on average, launching scans much more often.


New command: delete specified subsite

Delete specified subsite

command: spo web remove -u|--webUrl <webUrl> --confirm
webUrl: URL of the subsite to remove
confirm: Do not prompt for confirmation before deleting the subsite

Delete subsite using:
POST <webUrl>/_api/web
accept: application/json;odata=nometadata
X-HTTP-Method: DELETE
x-requestdigest: 0x5AB7E...

Ensure you have access token for the web specified in the `webUrl` option.

Can I work on this one?

All yours! Thank you for reaching out!


env var DOING_PR_CREATE_AUTO_COMPLETE not working

So basically, I want autocompletion to be OFF - I like having control of when I merge (just in case I catch anything embarrassing myself, and also because that's the only way to choose the opt-in rebase, etc.). However, no matter what I do to DOING_PR_CREATE_AUTO_COMPLETE, I can't get it to behave what I want. Currently, I'm using
export DOING_PR_CREATE_AUTO_COMPLETE="False"
But that for sure isn't achieving it. I've also tried several other configurations, but none of them worked. I'm fairly certain I've at least also tried export DOING_PR_CREATE_NO_AUTO_COMPLETE="True", but it's been a while so I could be misremembering. Regardless, as the docs only mention DOING_PR_CREATE_AUTO_COMPLETE, I felt like setting that false should ideally work as expected....?
Is this a user error on my part, or is this var simply not being read properly?

Hi @PaulHofma ,
Thanks for opening an issue on this! The good news is that it works on my machine 😄 I used export DOING_PR_CREATE_AUTO_COMPLETE="False" just like you.
The bad news is we now need to do some more digging to find out why it doesn't work for you:

What version of doing-cli are you running? (doing --version)
What version of python are you running? (python -V)
What version of az are you running? (az --version, lookup 'azure-cli' and ' azure-devops')
What operating system are you running on?

If you're not on the latest version, you can try upgrading (pip install --upgrade doing-cli and az --upgrade).
It might be that you're on windows, and the environment variable is not properly persistent. You can try:

doing pr create --no-auto-complete. If that works:
You can set a command default in the configuration file as well (see docs). In short, update your .doing-cli-config.yml file with:

defaults:
    DOING_PR_CREATE_AUTO_COMPLETE: False

Is this a user error on my part, or is this var simply not being read properly?

Well the difference doesn't really matter, either bad docs or bad code, so a fix is needed anyway. Once we figure out the root cause of the export not working, I need to figure out how to prevent people getting stuck on this!

doing: most recent version (1.1.7)
python: 3.9.4
az: most recent (2.22.1, devops: 0.18.0)
MacOS Catalina 10.15.7

I think I've realised what the issue is, because doing pr create ... works as expected.
Basically, the thing is I never use the plain doing pr create ... command - I really only ever make use of doing workon. However, I then immediately realized two things:

There is no option at all to set/unset autocomplete for workon. (does not take that param)
While many options (used to?) carry over from pr create to workon, as it's calling that under the hood (at least I'm fairly certain that's how it used to work? Haven't really checked out the code in while), this one ceretainly does not.

So I guess, really, that my issue isn't that the option isn't being recognized. It's that the option doesn't exist to begin with :p
As such, I'd turn this into a feature request (I can create a separate issue if you like): can we create a --no-auto-complete option for workon, or, alternatively, track the defaults for pr create when using workon?

On a somewhat related issue, from reading the documentation I thought that I could add pr_create_auto_complete: False to the .doing-cli-config.yml but from what I see from Tim's comment above, it should be
defaults:
    DOING_PR_CREATE_AUTO_COMPLETE: False

When I ran doing pr create ..., auto complete was still on, so I knew I did something wrong :)
The way I interpreted the docs, I thought the env vars should be added to e.g. .bash_aliases and that when adding settings to .doing-cli-config.yml the syntax was different (i.e. small caps, without the DOING_ prefix`).

I've been focussing any spare time on skorecard. Time to revisit this.
It's confusing that doing workon uses doing create pr under the hood, so as suggested by @PaulHofma I've chosen to simply add all options to doing workon as well. Explicit > implicit. You would now have to overwrite defaults twice, but that is probably clearer:
defaults:
    DOING_PR_CREATE_AUTO_COMPLETE: False
    DOING_WORKON_CREATE_AUTO_COMPLETE: False

I also agree with @operte that the docs on config / env vars are somewhat confusing. Refactored the docs, and now have a separate 'config' menu item.

Released [v1.1.9](https://github.com/ing-bank/doing-cli/releases/tag/v1.1.9 that should address this. Let me know :)


Add ColorSlider & ColorPreviewer Primitives

What does the pull request do?

What is the current behavior?

What is the updated/expected behavior with this PR?

How was the solution implemented (if it's not obvious)?

Checklist

[ ] Added unit tests (if possible)?
[ ] Added XML documentation to any related classes?
[ ] Consider submitting a PR to https://github.com/AvaloniaUI/Documentation with user documentation

Breaking changes

Obsoletions / Deprecations

Fixed issues

You can test this PR using the following package version. 0.10.999-cibuild0020131-beta. (feed url: https://nuget.avaloniaui.net/repository/avalonia-all/index.json) [PRBUILDID]

You can test this PR using the following package version. 0.10.999-cibuild0020132-beta. (feed url: https://nuget.avaloniaui.net/repository/avalonia-all/index.json) [PRBUILDID]

You can test this PR using the following package version. 0.10.999-cibuild0020133-beta. (feed url: https://nuget.avaloniaui.net/repository/avalonia-all/index.json) [PRBUILDID]

You can test this PR using the following package version. 0.10.999-cibuild0020147-beta. (feed url: https://nuget.avaloniaui.net/repository/avalonia-all/index.json) [PRBUILDID]

You can test this PR using the following package version. 0.10.999-cibuild0020157-beta. (feed url: https://nuget.avaloniaui.net/repository/avalonia-all/index.json) [PRBUILDID]

@maxkatz6 This is also ready for review. I know you all are busy but if this is merged soon I can get started on the final PR for the full color-picker. That should actually not be too difficult compared to what is already done. The final PR can also be lower priority as it isn't blocking anything.

You can test this PR using the following package version. 0.10.999-cibuild0020159-beta. (feed url: https://nuget.avaloniaui.net/repository/avalonia-all/index.json) [PRBUILDID]

You can test this PR using the following package version. 0.10.999-cibuild0020195-beta. (feed url: https://nuget.avaloniaui.net/repository/avalonia-all/index.json) [PRBUILDID]


Report back, PHP fatal error: dosomething_global_get_language() must be an instance of stdClass

When submitting a test report back the following fatal error is produced;
Recoverable fatal error: Argument 2 passed to dosomething_global_get_language() must be an instance of stdClass, instance of Reportback given, called in /var/www/dev.dosomething.org/lib/modules/dosomething/dosomething_reportback/dosomething_reportback.module on line 846 and defined in dosomething_global_get_language() (line 277 of /var/www/dev.dosomething.org/lib/modules/dosomething/dosomething_global/dosomething_global.module).
The website encountered an unexpected error. Please try again later.

It looks like function dosomething_global_get_language($account, stdClass $node = NULL) is hinted to expect stdClass rather than Reportback class.
This doesn't appear to happen on staging so perhaps I'm behind on my pulls and this has been fixed already?!?

Never mind, this is a bug I created on my dev...


Plotting D3plot does not work

🐛 Describe the bug
Reading a D3plot and plotting it throws an exception.
🔢 To Reproduce
Steps to reproduce the behavior:

Open a d3plot
Plot it

💘 Expected behavior
Browser window with 3D Model should open.
🖥 Setup

lasso-python version: 1.6.0pre
OS: Ubuntu 22

Looks like an issue with a string formatting. Easy to fix. Important though is that a unit test is indeed missing.

Pushed accidentally on develop thus merged.


[bug] element dragging forever

Hello there!
I use the ember-sortable to sort some bootstrap tabs, but i'm having a little bug...
I don't know exactly what triggers this bug since it occurs only some times... but what happens is that i click in a tab and it starts the drag forever, and i'm unable to cancel the drag or click in any element in the current page.
Since we have the "onDragStart" action, maybe i can set a simple click event to cancel the drag. But for this, i just need to know if is there some event, or some other way to cancel the drag.
Thank you very much!
Rael

Hi @raelbr
Thanks for filing an issue. Could you provide code samples so I can get more of a sense of what’s happening, particularly in the onDragStart action handler.

{{#sortable-group
tagName="ul"
direction="x"
classNames="nav nav-tabs"
model=model
onChange="reorderTabs" as |group|
}}
{{#each model.tabs as |tab|}}
{{#sortable-item
  tagName="div"
  model=tab
  group=group
  onDragStart="tabDrag"
  onDragStop="tabDrop"
}}
  <li>
    {{#link-to 'routename' tab.id}}
      {{tab.name}}
    {{/link-to}}
  </li>

{{/sortable-item}}

{{/each}}
{{/sortable-group}}
tabDrag and tabDrop actions have nothing set yet... Maybe the link-to is causing the issue? Just a quick note that it's not always that this bug occur... i really don't know what is causing this bug, if its the way we click or drag the tab, if is while a transition... Couldn't get a cause for this bug yet... Only thing i know is that sometime it happens =(
Sorry about the lack of information... But, if is there someway to force cancel the drag, i think i can solve this problem... is there some action, event, or some other way to turn down the dragging?
Thank you very much!

is there some action, event, or some other way to turn down the dragging

Not yet, but it would be a good thing to add.
We do have some built-in knowledge of when an interaction is not a drag — i.e. when there is very little movement between mousedown and mouseup — but perhaps it is not covering your case.
In the meantime, I would recommend adding a separate element to act as drag handle.

Thank you for your reply @jgwhite .
If i get a solution for this i share here. And if i manage to make an "cancel-drag" event that works fine in the plugin, i send a PR ;)

Hey there... I think i fixed this bug.
I managed to resolve this issue by adding the click event in the cancelStartDragListener inside the _primeDrag method, and also in the _startDrag.
  /**
    @method _primeDrag
    @private
  */
  _primeDrag(event) {
    let handle = this.get('handle');

    if (handle && !$(event.target).closest(handle).length) {
      return;
    }

    event.preventDefault();
    event.stopPropagation();

    let startDragListener = event => this._startDrag(event);

    function cancelStartDragListener() {
      $(window).off('mousemove touchmove', startDragListener);
    }

    $(window).one('mousemove touchmove', startDragListener);
    $(window).one('click mouseup touchend', cancelStartDragListener);
  },

  /**
    @method _startDrag
    @private
  */
  _startDrag(event) {

    if (this.get('isBusy')) { return; }

    let drag = this._makeDragHandler(event);

    let drop = () => {
      $(window)
        .off('mousemove touchmove', drag)
        .off('click mouseup touchend', drop);

      this._drop();
    };

    $(window)
      .on('mousemove touchmove', drag)
      .on('click mouseup touchend', drop);

    this._tellGroup('prepare');
    this.set('isDragging', true);
    this.sendAction('onDragStart', this.get('model'));
  },

Can this change impact someway in the plugins functionality?

@raelbr seems good. Could you submit a pull request with this change. Let’s see what the test suite says :)

Well, i got a FAIL in Travis CI. Is there something i did wrong?

any updates? I think I have a similar issue, where link-to is causing a full page navigation after mouse-up


Implement shader_set_uniform_color

See: #22
This should implement the shader_set_uniform_color function, along with its associated demo.
I built this one on top of #52 to avoid merge conflicts, so please accept that one first.

I have accepted your suggested changes.


refactor: move PrecommitWithOptions to mage.go again

Fixes workaround we introduced one of the earlier PRs
Depends on #54

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 8.125%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
13

Relevant Lines:
160

💛  - Coveralls


External traffic points like app gateway and LB in the hub segment

[A lot of solutions use hub and spoke model. Within this concept, the public IPs that are receiving traffic from internet or private IPs receiving traffic from corporate network act as the Azure subscription hub ingress/egress points .While the Azure AKS App Gw documentation for brownfiled covers show to have App gw in a separate VNET and resource group, however same is not clear for Loadbalancers which might be internal or external.  These scenarios can be added to this document.]

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

ID: 46723a24-75ac-f6e2-c172-d3827ca0b7d6
Version Independent ID: c975744e-e594-5667-14b3-c38824bbe24c
Content: Baseline architecture for an Azure Kubernetes Service (AKS) cluster - Azure Architecture Center
Content Source: docs/reference-architectures/containers/aks/secure-baseline-aks.yml
Service: architecture-center
Sub-service: reference-architecture
GitHub Login: @PageWriter-MSFT
Microsoft Alias: pnp

Thanks for reporting - this issue is under review. This is a Microsoft Internal DevOps Bug ID # 443413

@rp-msft -- Azure Load Balancer is imperatively managed by the AKS cluster as its lifecycle is coupled directly to the instance of the cluster. I'm not sure I follow how that would be addressed further in this document.  You can already isolate what subnet the load balancers materialize in, but it needs to be in the cluster's vnet, and isn't a "hub" resource.  Your hub can certainly handle that ingress traffic with a inbound FW (if desired) and AppGW if desired to be managed at the hub level.  But the AKS-managed load balancer is conceptually an extension (or maybe even implementation detail if you look at it in that regard) of the AKS service itself and is spoke-bound. If you can elaborate a bit more on what additional guidance we might be able to add to address your question, that would be helpful.

Hi @rp-msft - Can you elaborate a bit more on what additional guidance we might be able to add to address your question, that would be helpful. Thanks.

@rp-msft - I am closing this, as we need more guidance from you. Please feel free to open a new issue when you have more guidance.


Twitter and OpenGraph don't work

I've been trying to use the the Twitter & OpenGraph flags, but after tracing back through the dependencies of this repo, it turns out that the code that actually generates the favicons (from itgalaxy/favicons) doesn't generate Twitter or OpenGraph tags.

Merged in develop, will be released soon. Thanks for the PR, sorry for the delay to merge it.


get error with kornia and SamplePadding

ImportError: cannot import name 'SamplePadding' from 'kornia'
(/root/miniconda3/lib/python3.10/site-packages/kornia/init.py)
so, what's wrong?

Can you show more context? What's the kornia version? I recommand you to install kornia 0.4.1.
pip3 install kornia==0.4.1

ImportError: cannot import name 'SamplePadding' from 'kornia' (/root/miniconda3/lib/python3.10/site-packages/kornia/init.py)
so, what's wrong?

Can you show more context? What's the kornia version? I recommand you to install kornia 0.4.1.
pip3 install kornia==0.4.1

from kornia.constants import SamplePadding


Add marker for runs that broke the world record

Add marker for runs that broke the world record
It's easy to see people who LNN live, but not easy to see which people WR-ed live, which
is a cool datapoint to record.
Currently has:

2021: Borealis and pingval's WR's
2022: RB's WR
2023: RB's WR

There's probably other ones I missed, so let me know.

added translations

sorry but it's been really long since this PR and so much has changed about how the site works that it's prolly best to redo this PR another time. Heck, not even those JSON files exist anymore. It's all in a database now.
Basically: is it OK to just close this?

Sure, just hope the records are captured on the site going forward.


Connection terminated at launch

First of all, thank you for the release. It makes the whole process easier now. Regarding the issue:
The connection terminates at launch ( I have only tried using it remotely; I'm sure it's the same for USB as well). Sometimes, the phone reboots.
Attached is the screenshot here.

Device: OnePlus 7T
OS Version: Android 11
Build Number: Oxygen OS <IP_ADDRESS>.HD65AA
Kernel: blu-spark 4.14.190
Magisk Version: 27.0
SELinux: Enforcing
Could it be because of the SELinux status? OxygenOS always had issues with Frida ( I have tried Magisk Frida before and have to run a bunch lot of commands every time to fix). But it works fine with LineageOS 21.

Hey @asad0x01, I wasn't able to use Frida-Server at all on my device while testing. This happened because of a silent update Google pushed to the com.google.android.art package, after uninstalling that it suddenly was working again.
I've found the solution here: https://github.com/frida/frida/issues/2954#issuecomment-2337037812
If it's possible can you try to connect via USB first and if that isn't working please try to solution from the linked comment from the Frida repository.

No response from author, closing this issue.


Make ordered channels more resilient in the face of failing packets

Closes: #3540
Description

PR author checklist:

[ ] Added changelog entry, using unclog.
[ ] Added tests: integration (for Hermes) or unit/mock tests (for modules).
[ ] Linked to GitHub issue.
[ ] Updated code comments and documentation (e.g., docs/).
[ ] Tagged one reviewer who will be the one responsible for shepherding this PR.

Reviewer checklist:

[ ] Reviewed Files changed in the GitHub PR explorer.
[ ] Manually tested (in case integration/unit/mock tests are absent).

The ibcconsumer chain probably needs ccv_consumer to be set to true in its config.

Does this need to be set in the test itself, or in an actual config file?

I actually wonder why this test is run at all using a consumer chain?
@ljoss17 Is that expected? Do we run other ICA tests using CCV chains?

Does this need to be set in the test itself, or in an actual config file?

There are helper methods to bootstrap configurations for CCV chain tests: https://github.com/informalsystems/hermes/blob/master/tools/test-framework/src/util/interchain_security.rs#L18C13-L18C13
This is an example on how to use them:

https://github.com/informalsystems/hermes/blob/master/tools/integration-test/src/tests/interchain_security/ica_transfer.rs#L51
https://github.com/informalsystems/hermes/blob/master/tools/integration-test/src/tests/interchain_security/ica_transfer.rs#L63

@ljoss17 Is that expected? Do we run other ICA tests using CCV chains?

The issue happened when relaying for Stride, so I think it would be nicer to be able to run the test with CCV chains as we already have a job using Stride https://github.com/informalsystems/hermes/blob/master/.github/workflows/integration.yaml#L465. But I don't think it is necessary

Thanks @ljoss17 for reminding me of some outstanding issues with that PR:

After looking more into the ordered channel resilience PR, I found a few issues.

It seems that we enable the packet clearing on start by default with ordered channels, https://github.com/informalsystems/hermes/blob/master/crates/relayer/src/worker.rs#L129. This is a good thing in production but renders the current test ineffective since the clear on start will trigger when the supervisor is spawned for the third packet, thus relaying the second causing the test to pass
It is still possible to test manually the feature by commenting out the || channel_ordering == Ordering::Ordered here: https://github.com/informalsystems/hermes/blob/master/crates/relayer/src/worker.rs#L129

When testing locally with the modified version, the test doesn’t pass because Hermes doesn’t consider the packet relaying as an Error in this match https://github.com/informalsystems/hermes/blob/fdc352bb339033efe9930f9a7df2e80e631b511a/crates/relayer/src/link/relay_path.rs#L653
This can be seen by the submitted log below.
The cause is the following:

https://github.com/informalsystems/hermes/blob/master/crates/relayer/src/link/relay_path.rs#L783 call send_from_operation_data
https://github.com/informalsystems/hermes/blob/master/crates/relayer/src/link/relay_sender.rs#L97 call submit
https://github.com/informalsystems/hermes/blob/master/crates/relayer/src/chain/cosmos.rs#L1048 call send_messages_and_wait_commit
https://github.com/informalsystems/hermes/blob/master/crates/relayer/src/chain/cosmos.rs#L719 call do_send_messages_and_wait_commit
https://github.com/informalsystems/hermes/blob/master/crates/relayer/src/chain/cosmos/batch.rs#L93 call send_batched_messages_and_wait_check_tx
https://github.com/informalsystems/hermes/blob/master/crates/relayer/src/chain/cosmos/retry.rs#L48 call send_tx_with_account_sequence_retry
https://github.com/informalsystems/hermes/blob/master/crates/relayer/src/chain/cosmos/retry.rs#L77 call do_send_tx_with_account_sequence_retry
https://github.com/informalsystems/hermes/blob/master/crates/relayer/src/chain/cosmos/retry.rs#L150 return the response as an Ok() so the error isn’t caught by the relay_path match https://github.com/informalsystems/hermes/blob/fdc352bb339033efe9930f9a7df2e80e631b511a/crates/relayer/src/link/relay_path.rs#L653

2023-11-15T12:44:49.184516Z INFO spawn:chain{chain=ibcconsumer}:client{client=07-tendermint-2}:connection{connection=connection-1}:channel{channel=channel-2}:worker.packet.cmd{src_chain=ibcconsumer src_port=icacontroller-stride1798cf2q3gmw5gkyv0u6wtqfy38fap2darsl0p3 src_channel=channel-2 dst_chain=ibcprovider}:relay{odata=ae8fba35 ->Destination @0-132; len=1}: ibc_relayer::link::relay_path: submitted
2023-11-15T12:44:49.184485Z INFO spawn:chain{chain=ibcconsumer}:client{client=07-tendermint-2}:connection{connection=connection-1}:channel{channel=channel-2}:worker.packet.cmd{src_chain=ibcconsumer src_port=icacontroller-stride1798cf2q3gmw5gkyv0u6wtqfy38fap2darsl0p3 src_channel=channel-2 dst_chain=ibcprovider}:relay{odata=ae8fba35 ->Destination @0-132; len=1}: ibc_relayer::link::relay_sender: response(s): 1; Error with code 21:B139F35FBDBA7EA960F723B9A90510C3FC6D7A6C2F5BDC38E5B165FB570E1AFE target_chain=ibcprovider

From my understanding and a little bit of testing manually, one solution would be to do some code matching around here for a code 21 (out of order packet) here https://github.com/informalsystems/hermes/blob/fdc352bb339033efe9930f9a7df2e80e631b511a/crates/relayer/src/chain/cosmos/retry.rs#L139 and return a new error, e.g. OutofOrderPacket.
This could then be caught here https://github.com/informalsystems/hermes/blob/master/crates/relayer/src/link/relay_sender.rs#L98 and return a new error, e.g. OutOfOrderSend. And this new error could be caught here triggering the packet clearing.
This is the diff I used to play around for this suggestion which is now able to trigger the special clearing, but it gets this error:
2023-11-15T13:46:10.063080Z ERROR spawn:chain{chain=ibcconsumer}:client{client=07-tendermint-2}:connection{connection=connection-1}:channel{channel=channel-2}:worker.packet.cmd{src_chain=ibcconsumer src_port=icacontroller-stride1hleh224w70xp8kmnjaywdfshhy2ek42r283592 src_channel=channel-2 dst_chain=ibcprovider}:relay{odata=5c460800 ->Destination @0-131; len=1}: ibc_relayer::link::relay_path: 5/5 retries exhausted. Giving up

Show diff
diff --git a/crates/relayer/src/chain/cosmos/retry.rs b/crates/relayer/src/chain/cosmos/retry.rs
index 4d0091fc9..5e995b13e 100644
--- a/crates/relayer/src/chain/cosmos/retry.rs
+++ b/crates/relayer/src/chain/cosmos/retry.rs
@@ -137,6 +137,13 @@ async fn do_send_tx_with_account_sequence_retry(
                     Ok(response)
                 }

+                Code::Err(code) if code.get() == 21u32 => {
+                    warn!("packet out of order errror");
+
+                    Err(Error::non_provable_data())
+
+                },
+
                 // Gas estimation succeeded, but broadcast_tx_sync failed with unrecoverable error.
                 Code::Err(code) => {
                     // Do not increase the account s.n. since CheckTx step of broadcast_tx_sync has failed.
diff --git a/crates/relayer/src/link/error.rs b/crates/relayer/src/link/error.rs
index adf8142ec..3ac278a5e 100644
--- a/crates/relayer/src/link/error.rs
+++ b/crates/relayer/src/link/error.rs
@@ -76,6 +76,9 @@ define_error! {
                 format!("chain error when sending messages: {0}", e.event)
             },

+        OutOfOrderSend
+            |_| { "tried to send a packet out of order" },
+
         MissingChannelId
             { chain_id: ChainId }
             |e| {
diff --git a/crates/relayer/src/link/relay_path.rs b/crates/relayer/src/link/relay_path.rs
index a821eb8cb..8cf904111 100644
--- a/crates/relayer/src/link/relay_path.rs
+++ b/crates/relayer/src/link/relay_path.rs
@@ -671,17 +671,18 @@ impl<ChainA: ChainHandle, ChainB: ChainHandle> RelayPath<ChainA, ChainB> {

                     return Ok(reply);
                 }
-                Err(LinkError(error::LinkErrorDetail::Send(e), _)) => {
-                    warn!(
+                Err(LinkError(error::LinkErrorDetail::Send(_), _)) | Err(LinkError(error::LinkErrorDetail::OutOfOrderSend(_), _)) => {
+                    /*warn!(
                         "Determining whether we need to retry in response to: {}",
                         e.event
-                    );
+                    );*/

                     // if on an ordered channel, perform a packet clearing, but only if we
                     // are not in the middle of another packet clearing process
                     if self.ordered_channel() && i == 0 && !odata.tracking_id.is_clearing() {
                         // Do we need to specify the height for the packet clearing?
                         // Probably not, since no progress will have been made on the clearing process
+                        tracing::warn!("special clear");
                         self.relay_pending_packets(None)?;
                     }

@@ -698,6 +699,7 @@ impl<ChainA: ChainHandle, ChainB: ChainHandle> RelayPath<ChainA, ChainB> {
                     }
                 }
                 Err(e) => {
+                    tracing::warn!("other link error: {e}");
                     // Unrecoverable error, propagate up the stack
                     return Err(e);
                 }
diff --git a/crates/relayer/src/link/relay_sender.rs b/crates/relayer/src/link/relay_sender.rs
index c4d29fe91..48fbbe5d0 100644
--- a/crates/relayer/src/link/relay_sender.rs
+++ b/crates/relayer/src/link/relay_sender.rs
@@ -7,6 +7,7 @@ use ibc_relayer_types::events::IbcEvent;

 use crate::chain::handle::ChainHandle;
 use crate::chain::tracking::TrackedMsgs;
+use crate::error::Error;
 use crate::link::error::LinkError;
 use crate::link::RelaySummary;
 use crate::util::pretty::{PrettyCode, PrettyEvents};
@@ -95,9 +96,14 @@ impl Submit for AsyncSender {
     type Reply = AsyncReply;

     fn submit(target: &impl ChainHandle, msgs: TrackedMsgs) -> Result<Self::Reply, LinkError> {
-        let a = target
-            .send_messages_and_wait_check_tx(msgs)
-            .map_err(LinkError::relayer)?;
+        let a = match target
+            .send_messages_and_wait_check_tx(msgs) {
+                Ok(r) => Ok(r),
+                Err(e) if e.detail().to_string() == Error::non_provable_data().detail().to_string() => {
+                    Err(LinkError::out_of_order_send())
+                },
+                Err(e) => Err(LinkError::relayer(e))
+            }?;
         let reply = AsyncReply { responses: a };

         // Note: There may be errors in the reply, for example:
diff --git a/crates/relayer/src/worker.rs b/crates/relayer/src/worker.rs
index 915c49ce6..0c4050a92 100644
--- a/crates/relayer/src/worker.rs
+++ b/crates/relayer/src/worker.rs
@@ -1,6 +1,6 @@
 use alloc::sync::Arc;
 use core::fmt::{Display, Error as FmtError, Formatter};
-use ibc_relayer_types::core::ics04_channel::channel::Ordering;
+//use ibc_relayer_types::core::ics04_channel::channel::Ordering;
 use serde::{Deserialize, Serialize};
 use std::sync::Mutex;
 use tracing::error;
@@ -124,9 +124,9 @@ pub fn spawn_worker_tasks<ChainA: ChainHandle, ChainB: ChainHandle>(

             match link_res {
                 Ok(link) => {
-                    let channel_ordering = link.a_to_b.channel().ordering;
+                    let _channel_ordering = link.a_to_b.channel().ordering;
                     let should_clear_on_start =
-                        packets_config.clear_on_start || channel_ordering == Ordering::Ordered;
+                        packets_config.clear_on_start;// || channel_ordering == Ordering::Ordered;

                     let (cmd_tx, cmd_rx) = crossbeam_channel::unbounded();
                     let link = Arc::new(Mutex::new(link));
diff --git a/tools/integration-test/src/tests/interchain_security/ica_ordered_channel.rs b/tools/integration-test/src/tests/interchain_security/ica_ordered_channel.rs
index 42dd0877d..05b61175c 100644
--- a/tools/integration-test/src/tests/interchain_security/ica_ordered_channel.rs
+++ b/tools/integration-test/src/tests/interchain_security/ica_ordered_channel.rs
@@ -66,6 +66,8 @@ impl TestOverrides for IcaOrderedChannelTest {
         config.mode.packets.clear_on_start = false;
         config.mode.packets.clear_interval = 0;

+        config.mode.clients.misbehaviour = false;
+
         update_relayer_config_for_consumer_chain(config);
     }

Hi @seanchen1991 @romac @ancazamfir
Thanks for the great work @seanchen1991 !
I noticed this PR seems to be inactive for a while. We are now working on adding ICA support in next Cronos upgrade and making ORDERED channel more resilient in hermes is important to us.
May I ask what is the latest progress of this PR? Thank you!


support lsq scheme reset

Fix bugs appear when feature is set to per_tensor_affine but its input data include nums less than 0.

LGTM
@PeiqinSun


How do I fill the executive info?

My UI has come up now but what I see is a blank screen. I am a little confused on where will the executive info come from? How do we feed the executive info of our organisation to the DB so that it reflects on the Dashboard? Please help. This is what I see at the moment:

Hi Team, Please help.

@gauravdasson :
It looks like your Hygieia 3.0 api is may not be up.
Hygieia 3.0 collectors read data from the Hygieia 2.0 database, and generate aggregated metrics per Portfolio for a given metric type depending on the collector, and store the aggregated data into Hygieia 3.0 database.
Here's the documentation for Hygieia 3.0: https://hygieia.github.io/ExecDashboard/Introduction.html. I encourage you to go through this for a better understanding.
In your Hygieia 3.0 application.properties file:
These properties below should point to your Hygieia 2.0 database portfolio.readUriUserName={username}, portfolio.readUriPassword={password}, portfolio.readUriDatabase={host}:{port}/{database name}
And these properties below should point to Hygieia 3.0 DB: dbname={database name}, dbhostport={host}:{port}, dbusername={username}, dbpassword={password}
For now, set these properties below pointing to Hygieia 3.0 DB, these will be refactored and cleaned up soon, so you dont have to set them:
portfolio.writeUri=mondodb://{host}:{port}, portfolio.writeDatabase={database name}
Both the analysis, and the api would each need its own properties file, take a look at the collectors configuration,
and api configuration on the documentation page. Please configure the collector properties file (name it as "analysis.properties") as I explained above.
Configure another properties file (name it as "api.properties" file), and make it point to the Hygieia 3.0 database.
I think this information should be sufficient in addition to the documentation page for you to configure your application.

@gauravdasson - closing this due to inactivity.

In this post #19 there is a solution, inserting manually the data

@gauravdasson :
It looks like your Hygieia 3.0 api is may not be up.
Hygieia 3.0 collectors read data from the Hygieia 2.0 database, and generate aggregated metrics per Portfolio for a given metric type depending on the collector, and store the aggregated data into Hygieia 3.0 database.
Here's the documentation for Hygieia 3.0: https://hygieia.github.io/ExecDashboard/Introduction.html. I encourage you to go through this for a better understanding.
In your Hygieia 3.0 application.properties file:
These properties below should point to your Hygieia 2.0 database portfolio.readUriUserName={username}, portfolio.readUriPassword={password}, portfolio.readUriDatabase={host}:{port}/{database name}
And these properties below should point to Hygieia 3.0 DB: dbname={database name}, dbhostport={host}:{port}, dbusername={username}, dbpassword={password}
For now, set these properties below pointing to Hygieia 3.0 DB, these will be refactored and cleaned up soon, so you dont have to set them:
portfolio.writeUri=mondodb://{host}:{port}, portfolio.writeDatabase={database name}
Both the analysis, and the api would each need its own properties file, take a look at the collectors configuration,
and api configuration on the documentation page. Please configure the collector properties file (name it as "analysis.properties") as I explained above.
Configure another properties file (name it as "api.properties" file), and make it point to the Hygieia 3.0 database.
I think this information should be sufficient in addition to the documentation page for you to configure your application. If you still happen to have questions, let us know. Thanks.

@subodhbattina
When we say Hygieia 2.0 , are you referring to TeamDashboard database (dashboarddb ) ?


potentially unredistributable files in src/rp2_common/pico_btstack/

Hi,
I'm not a lawyer, so there might actually be no problem. I was made aware of this problem by Thorsten Alteholz who reviewed my Debian packaging of pico-sdk. The files inside src/rp2_common/pico_btstack are distributed under the following terms:
 “BlueKitchen” shall refer to BlueKitchen GmbH.
 “Raspberry Pi” shall refer to Raspberry Pi Ltd.
 “Product” shall refer to Raspberry Pi hardware products Raspberry Pi Pico W or Raspberry Pi Pico WH.
 “Customer” means any purchaser of a Product.
 “Customer Products” means products manufactured or distributed by Customers which use or are derived from Products.

 Raspberry Pi grants to the Customer a non-exclusive, non-transferable, non-sublicensable, irrevocable, perpetual
 and worldwide licence to use, copy, store, develop, modify, and transmit BTstack in order to use BTstack with or
 integrate BTstack into Products or Customer Products, and distribute BTstack as part of these Products or
 Customer Products or their related documentation or SDKs.
 [...]

So essentially, the right to copy, store and transmit BTstack is only granted to "Customers" which are defined as "purchaser of a Product". Github.com, which you are using to host this code, probably did not purchase any product, so they are probably not a customer and are thus not granted the permission to copy, store or transmit BTstack.
Or is the copyright information maybe incorrect and other terms apply to it?
Thanks!

Also not a lawyer, but FYI: The license here refers to use of BTstack itself. BTstack is not included in the pico-sdk repository; it is a sub-module (in github) and is licensed with these terms https://github.com/bluekitchen/btstack/blob/master/LICENSE
The files in the src/rp2_common/pico_btstack are not part of BTstack, and are licensed under the regular BSD-3-Clause license of the SDK
cc @ghollingworth @mringwal

Thank you for looking into this! The git submodule is located under lib/btstack. If the files in src/rp2_common/pico_btstack are licensed under BSD, what is the meaning of this LICENSE file?
https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/pico_btstack/LICENSE.RP

I now read that it actually says exactly that in src/rp2_common/pico_btstack/doc.h:

A supplemental license for BTstack (in addition to the stock BTstack licensing terms) is provided here https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/pico_btstack/LICENSE.RP

Closing, because there is no bug, just a misunderstanding about what source code the LICENSE.RP file actually applies to.


Not overwrite some fields in entity when updating (put, patch)

Is the any solution to load data into entity excluding the fields that you don't allow to be overwritten?
`
$body = $request->getParsedBody();
$tarea->clear();
$tarea->data($body);
$resultadoSave = $this->container["spot"]->mapper("App\Modelos\Tarea")->save($tarea);
`
After this code, i don't want that fields 'tar_id' and 'tar_uuid' can be overwritten if user has send it via json post method.

I think it's a bad idea to just pass the userdata to the object without any checks. A more defensive approach would be to explicitly define what keys can be set (along with some validation probably). Could be quite simple:
$body = $request->getParsedBody();

$allowedKeys = ['title', 'content'];

foreach (array_keys($body) as $key) {
    if (!in_array($key, $allowedKeys)) {
        unset($body[$key]);
    }
}

You can do what @willemwollebrants recommended or you can define rules using the integrated Event Emitters. Put something like this in the Entity definition:
// untested code
public static function events(EventEmitter $eventEmitter)
  {
      $eventEmitter->on('beforeSave', function (Entity $entity, Mapper $mapper) {
          $oldUUID = $entity->dataUnmodified('tar_uuid');
          $newUUID = $entity->tar_uuid;
          if ($oldUUID !== null) {
            $entity->tar_uuid = $oldUUID;
          }
      });
  }

This way the user cannot change the tar_uuid after it was first set.

Or ... :) you can define a setter for the fields in your Entity class, something like:
public function setTarUuid($value){
  if (is_null($this->tar_uuid){
    this->tar_uuid = $value;
  }
}

The upside here is that you don't have to wait for the beforeSave event. The tar_uuid becomes fixed after it was first set, whether or not or not the object has been saved.
Getters/setters are not that well documented, but the rules are pretty simple. If there's a function called set + the camel case version of the variable name, it will be called when you set the value for this variable (even if you use the data() method)

Closing this issue, because of the inactivity. Feel free to reopen this if you have more questions regarding this subject.


Fix bad push to upstream

Bad push wiped out changes from PR #1973 and #1974

already approved in #1974 (which my bad push to upstream wiped out)


write_to_model specifying the model does not work unless we manually create the ephemeral

I'm not sure if it's a bug or a feature request.
We have some legacy code that must output three tables instead of the classic just-one.
We haven't found anybody doing this  and there are very little references as to whether is supported.
Anyhow, we've noticed that if we manually create the ephemeral sql it just works.
fal --version: fal 0.7.6
dbt --version: 1.3.1*

sidenote: running that gave us the error AssertionError: fal credentials must have a db_profile property set
Which they do and fal flow and dbt run do work normally so 🤷🏽

Adapter being used:  postgres

How to reproduce
fal model:
dfrefpg = ref("raw_pg")
df_tuturu = ref("raw_tuturu")

write_to_model(dfrefpg)
write_to_model(data=df_tuturu, target_1='tuturu')

Expected behavior
to generate the tuturu table if it doesn't exist.
Actual behavior
RuntimeError: Could not find source 'db_mercat'.'tuturu'
Additional context
on dataframe is the result and another output dataframe is which "products" where used in the calculation.

Hi @polmonso ! Thank you for reporting this. Synced on the Discord community and the issue seems to be resolved. We are working on docs to make things more clear. But let us know if there are particular docs that you'd like to see updated.


Security Checkup (Apama Software management plugin)

Entrance point: CIT-517 Questionare

Heya! You've linked a seemingly internal ticket, can you please update this issue with the information therein or otherwise make it public as right now one cannot access the link.
Thank you!


Generating image with specific attribute

I was wondering if it's possible to generate an image with a specific attribute. For example, generating a red flower, or a person with long hair.

This repository does not support conditional generator.


Fix nightly test matching rustc "warning" output.

https://github.com/rust-lang/rust/pull/69926 changed the warning output from rustc.  https://github.com/rust-lang/cargo/pull/8080 attempted to compensate for it, but missed one of the cases.  I don't think this test needs to be quite so exhaustive about checking the output.

r? @alexcrichton
(rust_highfive has picked a reviewer for you, use r? to override)

@bors: r+

:pushpin: Commit 75e7b41823979d49e4311936a9e5f528abe28b2f has been approved by alexcrichton

:hourglass: Testing commit 75e7b41823979d49e4311936a9e5f528abe28b2f with merge 9def590c3c8b5cd3a9c0d0f5800fc5aadad5dfa1...

:sunny: Test successful - checks-azure
Approved by: alexcrichton
Pushing 9def590c3c8b5cd3a9c0d0f5800fc5aadad5dfa1 to master...


Naggers instead of SingleMessage/DeprecationLogger

Any of the checked boxes below indicate that I took action:

[x] Reviewed the Contribution Guidelines.
[x] Signed the Gradle CLA.
[x] Ensured that basic checks pass: ./gradlew quickCheck

For all non-trivial changes that modify the behavior or public API:

[ ] Before submitting a pull request, I started a discussion on the Gradle developer list,
the forum or can reference a JIRA issue.
[ ] I considered writing a design document. A design document can be
brief but explains the use case or problem you are trying to solve,
touches on the planned implementation approach as well as the test cases
that verify the behavior. Optimally, design documents should be submitted
as a separate pull request. Samples
can be found in the Gradle GitHub repository. Please let us know if you need help with
creating the design document. We are happy to help!
[x] The pull request contains an appropriate level of unit and integration
test coverage to verify the behavior. Before submitting the pull request
I ran a build on your local machine via the command
./gradlew quickCheck :logging:check.
[ ] The pull request updates the Gradle documentation like user guide,
DSL reference and Javadocs where applicable.

This is a followup to pull request #689 - Deprecation warning should print location in build file.
Behavioral change
Deprecation warnings are now showing up more than once.
Incubation warnings are still showing up only once.
It is currently very, very cumbersome to fix deprecation warnings one after the other instead of getting all deprecation warnings with a single build and fixing them all at once.
The previous behavior made sense without stack trace information since multiple messages would have only added more noise with no added information. But pull request #689 changed that.
API change
This PR aims to streamline the API used to nag the user about the usage of either incubating or deprecated features.
SingleMessageLogger and DeprecationLogger should not be used anymore.
Use getDeprecationNagger(), getIncubationNagger() or getBasicNagger() of class org.gradle.internal.featurelifecycle.Naggers instead.
Those return an instance of the DeprecationNagger, IncubationNagger and BasicNagger interface, respectively.
This has the added benefit that one can now search for usages of the above retrieval methods or the interfaces instead of searching for usage of each of the separate static methods.
It will be helpful while kickstarting development of a new major Gradle version since usages of DeprecationNagger will quickly point out all places containing deprecated functionality.
It also makes sense in case of BasicNagger because those methods should only be used by the other nagger implementations or tests.
Details

The "nagging API" of SingleMessageLogger and DeprecationLogger is still unchanged.
calls of those methods are untouched for now to avoid merge conflicts.
no SingleMessageLogger/DeprecationLogger inheritance anymore, so usage of respective static methods can be seen more easily.
Removed getDeprecationMessage() from SingleMessageLogger/DeprecationLogger and made it private in UsageNagger.
nested Naggers.withDisabled(..) calls work as expected. The inner withDisabled call previously reenabled nagging for the outer one.
Renamed DeprecatedFeatureUsage to FeatureUsage since it also handles incubating features.
Deleted DeprecatedFeatureHandler interface. Only one implementation exists and there is no API to switch to a different one.
Renamed LoggingDeprecatedFeatureHandler to LoggingFeatureUsageHandler since it also handles incubating features.
LoggingFeatureUsageHandler is now package-private. It could also be changed to a static inner class of UsageNagger if desired.
Moved setTraceLoggingEnabled/isTraceLoggingEnabled and ORG_GRADLE_DEPRECATION_TRACE_PROPERTY_NAME constant to Naggers.
DeprecationNagger.nagUserOfDeprecated('thing', 'explanation') does not add a '.' to the explanation anymore, bringing the behavior in line with the methods taking an advice. The only usage of that method in DefaultManifest has been changed accordingly.
GradleExecuter/AbstractGradleExecuter can now handle multi-line deprecation and incubation warnings. It previously only supported single-line deprecation warnings.
\n in nagging messages is now always converted to system-specific newline. Newlines in multi-line messages were previously not converted.

Before merging
After discussing the changes introduced by this PR (assuming you like them), I'd add another commit replacing all existing SingleMessageLogger and DeprecationLogger calls with their replacements, get rid of those classes & their tests (corresponding tests for the new API already exist and are more extensive than the existing ones) and switch UsageNagger to package-private.
I'd suggest to do that shortly before merge to minimize the potential of merge conflicts.
./gradlew quickCheck :logging:check works.

I removed the INCUBATION_MESSAGE constant from ParallelForkingGradleHandle for a second time.
It was reintroduced in https://github.com/gradle/gradle/commit/40cb7da009fa43b56ac9355e7fc7cfab553f4e0a . If this is really, really necessary then the constant would now be added to the IncubationNagger interface since UsageNagger (where that constant would be located if it still existed) is supposed to be package-private after all is said and done.
Please holler in that case and I'll change the code accordingly.
Just wanted to explain the rationale behind this to make it more obvious that I'm not just trolling you stubbornly.

Fixed the merge conflict.
Additionally, mocking of the various nagger interfaces is now fully supported and tested.
Printing more than one message per deprecation warning type will become even more important with the new The Task.leftShift(Closure) method has been deprecated and is scheduled to be removed in Gradle 4.0. Please use Task.doLast(Action) instead. warning introduced in Gradle 3.2.

This PR reverts the optimization added in 33f8a0fd3b864c1636eb9dc826e0d95e5f8c1048.
This is OK, though, since a FeatureUsage (formerly DeprecatedFeatureUsage) is now only ever generated at all if it will actually be used.
This means that the The Task.leftShift(Closure) method has been deprecated and is scheduled to be removed in Gradle 4.0. Please use Task.doLast(Action) instead. message will still cause the mentioned performance impact but that price is being paid for seeing all locations that are causing the warning at once. And the negative impact on build performance is gone once the deprecation warnings have been fixed.
Multiple incubation warnings won't cause such a negative impact since they'll still only emit the first occurrence.
I hope you agree that seeing all locations causing a warning at once is worth that price. The prospect of fixing all usages of << one after the other is causing me serious grief and despair...

Regarding the "Before merging" section in the original PR message:
We could also merge this into master and handle the cleanup in a separate PR. This would probably be a good idea if we want to get this into 3.2.

Fixed another merge conflict.
I also took a look at the AbstractTask code since I was wondering how the "Gradle 5.0" part of the << deprecation message was generated.
DeprecationLogger.nagUserWith("The Task.leftShift(Closure) method has been deprecated and is scheduled to be removed in Gradle 5.0. Please use Task.doLast(Action) instead.");

Now I think it would make sense to duplicate all methods in DeprecationNagger with an additional GradleVersion argument. The methods without argument would simply call their corresponding method with GradleVersion.current().getNextMajor(), keeping the current behavior while still giving the option to specify a different Gradle version explicitly if required.
The above code could then be changed to this:
Naggers.getDeprecationNagger().nagUserOfDiscontinuedMethod("Task.leftShift(Closure)",
    "Please use Task.doLast(Action) instead.",
    GradleVersion.version("5.0"));

Added support for
Naggers.getDeprecationNagger().nagUserOfDiscontinuedMethod("Task.leftShift(Closure)",
    "Please use Task.doLast(Action) instead.",
    GradleVersion.version("5.0"));

I know, I know...
https://twitter.com/CodingChick/status/789581067690713088
But trust me on this one.
The Fixing expectDeprecationWarning() calls commit consists largely of actual bug fixes to integration tests that weren't obvious before I added the check whether a test with expectDeprecationWarning() would actually print one.
 Declaring incubation warnings in integration tests is now required.
The above commits (minus the merge conflict fix that I'll push in a moment) have been built and tested in the following environment:

------------------------------------------------------------
Gradle 3.3-20161025000042+0000
------------------------------------------------------------

Build time:   2016-10-25 00:00:42 UTC
Revision:     2b77833dc5c3eb654e051913e78967cfcace8345

Groovy:       2.4.7
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.8.0_112 (Oracle Corporation 25.112-b16)
OS:           Mac OS X 10.12.1 x86_64

I executed a full ./gradlew clean and ./gradlew check.
Everything works (with #814 applied) but I suspect that I didn't catch all existing breakage because some could still lurk in @IgnoreIf tests that don't match my environment. Fixing those should be pretty straight-forward. Let me know if you have questions or need help.

Executed ./gradlew quickCheck :internalIntegTesting:check on the fixed merge conflict.

Holler if you are interested in this contribution. I'll fix the merge conflicts if that's the case.

Thanks for this elaborate pull request and the extent of work you put in. I'd like to see individual aspects addressed separately in individual pull requests. It's almost impossible for me to fully digest the changed code and do a proper code review with 76 files changed.
I see that https://github.com/gradle/gradle/pull/1360 already started with one of the aspects and I will start to review that first. Maybe we can tag on your work as follow up pull requests to that. Just to reassure you: We are definitely interested in some of the changes you proposed. Let's bring them in one by one.


Create Scenario Driven Test

Using the LIGO tale example, create an automated test that can be used for regular monitoring.
Completion criteria:

Automated test
Integrated into monitoring

Duplicate of https://github.com/whole-tale/terraform_deployment/issues/7


test(jest): migrate to new defaults

Summary

use the jest-circus runner, which had no impact except slightly speeding up the build
use the "node" test environment by default, and changing the tests that need it to jsdom

Result

Both of these changes had an impact to make it so that the complete test run (cached) went from ~20 to ~15 seconds on my machine.
Read more on the motivation of these changes here: https://jestjs.io/blog/2021/05/25/jest-27

There's actually a very helpful error given by jest if you try to use window/document etc. in Jest that suggests using jsdom, so I don't think I'd look into the contributing guide, but add the environment automatically. The error looks like this:


Internet Explorer/Edge discards part of the decimal precision

TL;DR
IE/Edge seem to ignore anything after the second decimal place on a percentage background position. Is there an option in svg-sprite to use pixel units instead of percentage?

I just noticed that IE and Edge do not display the sprites correctly. I noticed it when I had a button that changed the sprite icon on hover.
Searching the web I found an issue on stackoverflow that explains the problem: http://stackoverflow.com/questions/6420255/ie-bug-percentages-with-background-position

it seems IE ignores anything after the second decimal place.

So percentage background position does not work well in IE. Using percentage units is one of the best features in svg-sprite, but if IE/Edge need to be supported, it seems necessary to use pixel units instead. Is there an option in svg-sprite to use 'px' instead?
Note: I searched for similar issues, but did not find any so I created this one. If this is a duplicate of an existing issue, I apologize.

@adgoncal Thanks for reporting — but that a real bummer. :(
svg-sprite used to use absolute positions (i.e. pixels), but there's no such option anymore. Of course one could use an alternative rendering template making use of the absolute values (they are still available as variables in the templates), but it's going to be a major pita.
If I understood the problem correctly, an alternative approach would be to create the sprite such that all positions are full percentage value, right? This would possibly increase the sprites overall dimension a little, but that wouldn't matter as long as it's only SVG (it would matter a little for node-iconizr, but support for IE / Edge is probably more important).
In any case, really solving this issue will require some time — which I currently don't have, unfortunately. I'll keep this open and try to work on it as soon as I can. Thanks again for reporting.

FWIW you can supply a custom template to use pixels rather than percentages.
Here is my config:
var svgSpriterConfig = {
  mode: {
    css: {
      dimensions: true, // This causes the library to emit a single css class per sprite rather than two
      render: {
        css: {  template: path.join(__dirname, 'sprite.css.custom.tmpl') }
      }
    }
  }
};

And the custom template file I created:
{{!
This is a mustache template file.
It is a COPY of the css mustache template that is part of svg-sprite.  With a tweak :)
Specifically, it is a copy of this file: node_modules/svg-sprite/tmpl/css/sprite.css
The only tweak is:

The original uses position.relative.xy, we have changed it to be position.absolute.xy.
This causes the generated CSS to use pixles instead of %s for background positions.
E.g. "10px 32px" vs "6.6371681415929205% 39.647577092511014%"
We want to do this for two reasons:

Not a huge deal, but (IMHO) its easier to understand the pixel coordinates.
It seems like there are less two-almost-identical-sprites-rendered-differently-by-one-pixel-at-various-zooms
issues between browsers if we use pixels.
}}
{{#hasCommon}}.{{commonName}} {
background: url("{{{sprite}}}") no-repeat;
}

{{/hasCommon}}{{#shapes}}{{#selector.shape}}{{expression}}{{^last}},
{{/last}}{{/selector.shape}} {
{{#hasCommon}}background-position: {{position.absolute.xy}};{{/hasCommon}}{{^hasCommon}}background: url("{{{sprite}}}") {{position.absolute.xy}} no-repeat;{{/hasCommon}}{{#dimensions.inline}}
width: {{width.outer}}px;
height: {{height.outer}}px;{{/dimensions.inline}}
}{{#dimensions.extra}}
{{#selector.dimensions}}{{expression}}{{^last}},
{{/last}}{{/selector.dimensions}} {
width: {{width.outer}}px;
height: {{height.outer}}px;
}{{/dimensions.extra}}
{{/shapes}}

Thanks for sharing your custom template, @aarondail. This might help others quite a lot!
However, please bear in mind that using pixels instead of percent will make your sprite shapes "non-responsive" — they will be tied to their original dimensions (respectively the generated ones) and you won't be able to style them via CSS to have different dimensions (e.g. background-size: 100% auto isn't possible anymore without all shapes shifting ...). In fact, switching to relative positioning was the improvement between svg-sprite < 1.0 and > 1.0. Just wanted to add this as a kind of reminder — you won't be affected if you use the shapes in only one dimension.
I will try to cater for the precision problem in a later release.

Ahh, good to know!  I hadn't realized that.

Hi
Any news with this issue?

@Chehow Sorry, no news yet. Due to massive overload I won't be able to work on svg-sprite at least until the end of the year. Thanks for your understanding.

Hi @jkphl, any chance that this story would have a higher priority?

@eugef I'm planning to do a major rewrite (including a fix for this bug) for a long time now, but unfortunately im swamped with tasks and completely overloaded these days which won't change at least until end of March. With a bit of luck I might work on svg-sprite then again. On another note, please feel free to send in a PR with a solution!

@jkphl I'd like to, but don't feel confident to dig into.
BTW, the workaround that we are using - is to add 1-2px padding around each icon in the sprite. Then effects of the issue are not so visible  - the icons can be still shifted, but at least they are not truncated or part of next icon is not shown.

Microsoft dropped support for the Internet Explorer.
If you still have this problem in Microsoft Edge - please open a new issue and link this one into it


[Prometheus Receiver] Added test case to validate 'Untyped' metrics

Note: This PR is dependent on prior PR#904 . Changes of this PR are in commit id
9f2b001d7861c8631f4ec96906d1444800d873e8 : Adding testcase for untyped metrics
Description:

Added test case to validate untyped metric with default Prometheus parser.
Used untyped in testdata as metric type, instead of unknown. unknown was applicable for OpenMetrics parser.

Link to tracking Issue:
Issue: 6083

Merged.


Framework compatibility

OpenSans now works when it becomes a framework with CocoaPods 0.36.
Two steps were necessary (based on this CocoaPods blog post):

Used a system import (<OpenSans/UIFont+OpenSans.h>) to import the header.
Created a private class to load the font, as NSBundle +mainBundle needs to be replaced with NSBundle +bundleForClass:, but couldn't do it from a category.

Thanks @marcelofabri!

Thanks @marcelofabri!

:+1:

:+1:


How to use merge strategy for web in v3?

In the v3 docs says that we can use this approach to configure the merge strategy for web version. I tried to use tailwind-merge but it didn't work as expected. Do someone have an example of how to make it work?

I'm guessing that this would be like
if (Platform.OS === 'web') {
  NativeWindStyleSheet.setWebClassNameWebStrategy = twMerge
}

In our index.js/main.js

I'm guessing that this would be like
if (Platform.OS === 'web') {
  NativeWindStyleSheet.setWebClassNameWebStrategy = twMerge
}

In our index.js/main.js

This is the correct answer.
If you update to v4, you can use tailwind-merge as documented in its repo


no json file in 2020 unity

no json file found in build folder，how to use it in react？

Unity 2020 is not supported yet #103


Adoption of ABINet for ms 2.1

Thank you for your contribution to the MindOCR repo.
Before submitting this PR, please make sure:

[ ] You have read the Contributing Guidelines on pull requests
[ ] Your code builds clean without any errors or warnings
[ ] You are using approved terminology
[ ] You have added unit tests

Motivation
(Write your motivation for proposed changes here.)
Test Plan
(How should this PR be tested? Do you require special setup to run the test or repro the fixed bug?)
Related Issues and PRs
https://github.com/mindspore-lab/mindocr/issues/491
(Is this PR part of a group of changes? Link the other relevant PRs and Issues here. Use https://help.github.com/en/articles/closing-issues-using-keywords for help on GitHub syntax)

add ABINet yaml config file path here
https://github.com/mindspore-lab/mindocr/blob/main/tests/ut/test_models.py#L16

add ABINet yaml config file path here https://github.com/mindspore-lab/mindocr/blob/main/tests/ut/test_models.py#L16

已修改


Change HLTB search endpoint

Fix https://github.com/DareFox/HowLongToBeat-Proxy-API/issues/15

Returned "/search" again


Error handling on Server sync streaming

I'm trying to use server-side streaming. But I have questions about how to handle the error.

In server-side, I want to know how to handle when ServerWriter::Write returns false.
In client-side, I want to know if there is required error handling to do.
Can anyone give me some error handling examples or real world projects that using grpc streaming?

If your ServerWriter returns false on Write, consider the stream failed and return from the server handler.
At the client side if the rpc status is not ok, then you need to decide according to application logic. Maybe you want to re-issue the rpc or do something else.

Thanks.


Shim /v3/repos API for actions/checkout

Description
Under condition !ref && !commit, actions/checkout calls out to the GitHub API:
https://github.com/actions/checkout/blob/8eb1f6a495037164bea451156472f35fdd6bafc0/src/github-api-helper.ts#L26
::group::Determining the default branch
Retrieving the default branch name
Not found.

It will fetch /api/v3/repos/[user]/[reponame] which is not available on Gitea's API. I wonder whether we should make some shims specific for this because the action it by far the most commonly action to use.

This was reported in Discord, I asked the user to share more details on how they are running into this issue.

Yes, this section confirms that the affected code is only used when git is not available:
https://github.com/actions/checkout/blob/8eb1f6a495037164bea451156472f35fdd6bafc0/src/git-source-provider.ts#L74

I think we may consider just requiring git in the image. It's only unfortunate that actions/checkout fails with such an confusing error message. Maybe we should validate presence of git itself in act-runner to make the error reason clear.

The only other two API calls I see in this fallback code are here:
https://github.com/actions/checkout/blob/8eb1f6a495037164bea451156472f35fdd6bafc0/src/github-api-helper.ts#L135-L136
These go to /repos/{owner}/{repo}/tarball/{ref} and /repos/{owner}/{repo}/zipball/{ref}. I think this is unversioned API that is likely present on Gitea.

I don't think it's wise to require git after all. There may be more scenarios where it won't be there and I assume GitHub must have had good reasons for adding that fallback download via archive.

This was reported in Discord, I asked the user to share more details on how they are running into this issue.

I guess I should say on this bug; I'm the user who reported it in discord, and #29654 is my report of this.
The details are in #29654, but in short, the actions workflow that I have that runs into this is basically this example; the second repo's ref isn't plumbed in via the normal means.
Manually specifying a ref to check out in the action works around this issue.

Closing in favor of https://github.com/go-gitea/gitea/issues/29654.


Add vf check for name id 25

https://typedrawers.com/discussion/comment/48638/#Comment_48638
https://adobe-type-tools.github.io/font-tech-notes/pdfs/5902.AdobePSNameGeneration.pdf
Should be triggered if "Italic" is part of the file name, or NameID2, or NameID17.
The ticked cases indicates where you can already find it.
Name ID25 is present and "Italic" is appended to the family name (without space)
Adobe recommend the presence of name ID 25 in all variable fonts. We found out it is actually necessary to allow style linking between Upright and Italic variable fonts. According to their documentation, this should be the Font Family Name only. Although, it seems that a bug in Indesign forces us to append "Italic" in the name ID 25 to be able to use properly the fonts. See issue: https://github.com/googlefonts/gftools/issues/297 for more debate on the subject.
This should be a WARN cause comes from a bug in Adobe Indesign, this is controversy but GF tries to enforce it to avoid complains until this bug is resolved. We should check regularly if it got resolved btw, in February 2022 it was not.
Profile

[ ] in google-font profile
~in universal profile~
~in opentype profile~

Format

[ ] in VF check
~in static check~

I assigned this to myself because I would like to try looking into this.

I presume you've not been dealing with this lately, @eliheuer

Yes, I got busy. I moved this to my personal to-do list just in case no one else gets to it soon and I have time.

This is still an issue in Illustrator, as of Illustrator 2024, v28.4.1 (the latest version as of April 26, 2024).


updated to conform with returnExports UMD

Resolves #4

Enables usage
window.axis = require('./axis');


Generate a testcase

Hello,
How can I generate a test case using esfuzz so I can feed to the JS Parser?
Thanks in advance

Is this project is still alive?

It's not dead. You just didn't bother to read the README.


[FPGA] MemoryBuffering Transformation

Extends the StreamingMemory transformation to support memory buffering.
The MemoryBuffering transformation allows reading/writing data from memory
using a wider data format (e.g. 512 bits), and then convert it on the fly to the right data type used by the computation

Compiler error if the following vector types are used: float16, int8, int64

I think that some of the code I added could be replaced by the vectorization transformation once it is complete.


Improve plugins developer experience

Current situation
Right now the plugins can either be developed inside the frontend (in frontend/src/plugin/plugins) or outside which is the recommended way to then ship it externally. The recommended option however, makes for a complicated developer experience, as it's complicated to continuously verify/reload any changes to plugins externally.
Impact
This makes developing plugins a bit clunkier/harder than it should.
Ideal future situation
Developers can continuous develop plugins: see their changes hot-reloaded and extract the plugins into a bundle when ready.
Implementation options

Develop the plugins inside Headlamp's frontend and extract them (into their own bundle) with an easy command;
or 2) Headlamp has a way to import unbundled plugins and hot-reload any changes to them.

Implemented since version v0.3.0.


Update ru.json

Added "FEELS" translation

Please send your pull requests the develop branch.
Don't forget to add the change to CHANGELOG.md.

Note: Sometimes the development moves very fast. It is highly
recommended that you update your branch of develop before creating a
pull request to send us your changes. This makes everyone's lives
easier (including yours) and helps us out on the development team.
Thanks!

Does the pull request solve a related issue?
If so, can you reference the issue?
What does the pull request accomplish? Use a list if needed.
If it includes major visual changes please add screenshots.

Warnings

:warning:

Please include an updated CHANGELOG.md file.This way we can keep track of all the contributions.

  Generated by :no_entry_sign: dangerJS

Please include an updated CHANGELOG.md file. Thanks!


Bug: Romani Ranch boulder is gone if you spawn in Milk Road at the start of day 1 before 6 am

Title is self-explanatory. eedfeede was the first person to find this and I went to test it today in my seed to confirm it with just Dungeon ER and Boss ER active. Basically, if you set your spawn in Milk Road and then do any form of time reset in MM (Song of Time or defeating Majora) when you respawn back in Milk Road, the boulder for Romani Ranch will be gone. This is ER only because your spawn can only be changed with ER enabled so something caused this to happen recently. It will come back if you exit Milk Road and then come back into Milk Road so it's not a flag issue where it's permanently gone.
Clip: https://clips.twitch.tv/PolishedAltruisticPidgeonKappaClaus-6dDw1uHUWUt__24V
Edit: It would appear that this isn't ER-only. If you song of time after getting Milk Road Owl Statue and then reset (when the Song of Time cutscene is playing) and then soar from OOT to Milk Road, the boulder will not be spawned. Likewise, in Owl Shuffle, if you start with the Milk Road Owl Statue and then soar to Milk Road immediately it will also not be present. It's all the same issue, however.

Seems to be caused by simply getting to Milk Road on Day 0, can happen in many ways:

owl shuffe + cross warp (without ever setting foot in MM before)
soft-reset after song of time then warp
altering your spawn MM spawn (ER)

Fixed


boards: raspberrypi: rpi_pico: Remove i2c1 node (again)

Zephyr's default settings usually enable only the minimum of
peripherals, and rpi_pico already has i2c0 enabled.
Remove the i2c1 node configuration.
I've dealt in https://github.com/zephyrproject-rtos/zephyr/commit/a82cc220d1a55c84b3e337f537ff32b8426b9270,
but it was added again by mistake. I'll delete it again.

Actually looking at this again, what was wrong in your opinion with having the nodes present but disabled by default?

Actually looking at this again, what was wrong in your opinion with having the nodes present but disabled by default?

https://datasheets.raspberrypi.com/pico/Pico-R3-A4-Pinout.pdf
In the pinout diagram, UART0, I2C0, and SPI0 are shown in dark colors, and are the general default pinmux. This is generally a shared understanding among users. However, there are no clear defaults for other peripherals, so I think it is better to leave them as they are.


update region to include Asia Pacific

[Enter feedback here]

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

ID: a111eec9-fcfd-8966-ca7b-0177418917fe
Version Independent ID: b9f65c4d-3735-a5a3-c1f8-1e6770e68036
Content: Region availability & data residency in Azure Active Directory B2C
Content Source: articles/active-directory-b2c/active-directory-b2c-reference-tenant-type.md
Service: active-directory
Sub-service: b2c
GitHub Login: @mmacy
Microsoft Alias: marsma

Data resides in Asia Pacific for the following countries/regions:
Afghanistan, Australia, Hong Kong SAR, India, Indonesia, Japan, Korea, Malaysia, New Zealand,  Philippines, Singapore, Sri Lanka, Taiwan and Thailand.

@valnav Thank you for pointing that out. A pull request is already made to fix the document and it should get updated soon.
Thank you.

@valnav @shashishailaj This is not yet available in all portal regions. When it reaches 100% roll-out, I will publish the article. For now, we can close this issue as the information has been gathered and the article update is pending.
#please-close


[DOCU-47] Improving the plugin and OSS install layouts

Review
@tlblessing
Summary

Widened the plugin doc layout
Adjusted the header to match the rest of the site better
Moved plugin version selector into the side nav
Mobile responsiveness stuff
Slight adjustments to the plugin params table styling
Removed unnecessary layout files that are no longer in use
Adjusted OSS install docs (eg docs.konghq.com/install/centos) to work with new header changes

Reason
Main reason is that the plugin docs need to be wider. They contain many reference tables, and those tables are always squished into a narrow column and can be hard to read.
Addresses part of https://konghq.atlassian.net/browse/DOCU-47.
Testing
Take a look at any plugin under https://deploy-preview-2909--kongdocs.netlify.app/hub/
Test that different window sizes (mobile etc) don't break anything.
Without a version dropdown:
https://deploy-preview-2909--kongdocs.netlify.app/hub/optum/kong-service-virtualization/
With a version dropdown:
https://deploy-preview-2909--kongdocs.netlify.app/hub/kong-inc/key-auth/
OSS installation (check that header isn't broken):
https://deploy-preview-2909--kongdocs.netlify.app/install/centos/

I think the plugin version drop down should go, because of all of the confusion it causes.

Sorry if the preview made it look like there were options - I was just showing previews of two possible setups, where the plugins have versions and where they don't. I think ultimately, it would be nice to get rid of the versioned plugin docs, but that's a big decision that I don't want to make in this PR.

In the Jira, there is mention of moving items over to the left to more closely mimic the rest of the site. Was this decided against or is this a first step towards that end? Either way, this is a definite improvement. Thanks Lena!

Nice catch. I was thinking that leaving it on the right currently makes more sense, as it's a page-level nav, and the rest of our docs have page-level navs on the right. I'd like to do a bigger overhaul later where we revisit this, though (for the plugins specifically).


SecretKeyFactory not available when trying to use private_key_file

System information:

Operating system (distribution) and version: Ubuntu 20.04
DBeaver version 7.1.0
Additional extensions

Connection specification:

Database name and version: Snowflake
Driver name 3
Do you use tunnels or proxies (SSH, SOCKS, etc)? No

Describe the problem you're observing:
To use Snowflake with RSA, you need to add private_key_path and private_key_file_pwd. This however does not work with DBeaver.
Steps to reproduce, if exist:

Add snowflake
In driver properties, sue the following:
private_key_file -> /home/you/key.p8
private_key_file_pwd -> mypwd
Test connection, then see below:

Include any warning/errors/backtraces from the logs
Private key provided is invalid or not supported: /home/josh/mykey.p8: 1.2.840.1135<IP_ADDRESS> SecretKeyFactory not available

thanks for the bug report

DBeaver PRO versions support private key authentication:

Or you can try to use a workaround with extra libraries from this message: https://github.com/dbeaver/dbeaver/issues/8946#issuecomment-837243524


connection string with password can not be used

connection string with password can not be used becaused the connection this sink create instead contains a additional '='

ok, i know why, if the connection string ends with ';' then this issue will happen

ok, i know why, if the connection string ends with ';' then this issue will happen


Make code editing live so other can watch as code changes

A cool feature for tinker would be to utilize web sockets to have live code so multiple devs can see the code as it changes.
Thoughts?

Yeah, that would be great indeed. Someone has actually already made a fork and replaced the backend with nodejs in order to enable this. It's not something I'm looking to do very soon, but it's definitely something I would like to have in the future.

+1 for live editing :)


is it possible show all steps?

is possible display all steps at the same time with backdrop?

I believe its not possible as the tour mechanism is made for a single step at a time you can check that method to see how its displaying each step

ok thanks for reply :3


Show render time / download time / latency on header

Hi,
I have noticed that for large JSON files it takes a bit for rendering the JSON visualization.
It would be nice to show in the headers the actual time it took to download the JSON so we don't suspect of server issues.
Ex:
On a 53.1Kb JSON File, it took 1.15 sec for the download to take place of this particular JSON but the plugin kept spinning for about 6 seconds... It would be nice to know the actual time the server took to process it so I don't freak out about performance issues...

Version 0.8.0 is out, it is a lot faster than the previous one. I will close this issue but if you try and it's not good enough I can reopen it.


Landing page

https://github.com/zuri-training/project-Auth_wiki-Team-8/blob/main/frontend/index.html


Error in payout calculation time

Expected behavior
Correct payout time remaining should be displayed
Actual behavior

You can see there is a one hour delay.
How to reproduce
Hover payout in steemit and busy an hour before the real payout occurs

Duplicate of #1062


Update footer colors

In footer.module.css the background color on line 2 should be changed as follows:
Current: background-color: black;
Change: background-color: var(--dark);
In footer.module.css the background color on line 34 should be changed as follows:
Current: color: #00b4d8;
Change: color: var(--primary)

Hey @EmmaDawsonDev assign me this issue.

Please assign me with this issue, this will be my first pr as i m a beginner i can start my journey with this. Thank you.

@EmmaDawsonDev Please assign me. I would like to work on this

Ah @Manujdixit got this one first.

Thanks @EmmaDawsonDev

hi emma , are there any more issues, i would like to contribute.


fix: handle multiple substreams on bitswap

May be related, appeared while using commits from this PR
2022-12-29T19:50:26.704129Z  WARN  tokio-runtime-workers-3 libp2p_kad::handler: New inbound substream to PeerId("12D3KooWC77ZcshYnoVyH6mwEUZX45QaoPXySWdGTVTuRDi263j8") exceeds inbound substream limit. Removed older substream waiting to be reused.
2022-12-29T19:50:26.824132Z  WARN  tokio-runtime-workers-8 libp2p_kad::handler: New inbound substream to PeerId("12D3KooWC77ZcshYnoVyH6mwEUZX45QaoPXySWdGTVTuRDi263j8") exceeds inbound substream limit. Removed older substream waiting to be reused.
2022-12-29T19:50:26.942451Z  WARN  tokio-runtime-workers-8 libp2p_kad::handler: New inbound substream to PeerId("12D3KooWC77ZcshYnoVyH6mwEUZX45QaoPXySWdGTVTuRDi263j8") exceeds inbound substream limit. Removed older substream waiting to be reused.

@dignifiedquire Is there something left to do? I've cherry-picked these commits, tested and it is ok.


Add advanced options for costum tree depth

Could you iterate more on this? @cedoor

I think it was related to the size of the group in the UI. You cannot choose tree depth = 17 now there, there're only 4 options.

I think it was related to the size of the group in the UI. You cannot choose tree depth = 17 now there, there're only 4 options.

Got it. We should change the concept of just three group sizes (S, M, L).

Got it. We should change the concept of just three group sizes (S, M, L).

And add a button "advanced options" with a UI component to select a tree depth. I think there's already a component on Figma.

Got it. We should change the concept of just three group sizes (S, M, L).

And add a button "advanced options" with a UI component to select a tree depth. I think there's already a component on Figma.

Brilliant! :sparkle:

I think that we could also avoid this part and use the LeanIMT to have dynamic depth in the future.

I think that we could also avoid this part and use the LeanIMT to have dynamic depth in the future.

Right! Bandada won't need it, at least for Semaphore groups.


Can't hide Forecast.io Storm Distance

Feature requests should go in the forum: https://community.home-assistant.io/c/feature-requests
Home Assistant release (hass --version):
0.18.2
Python release (python3 --version):
Python 3.4.2
Component/platform:
Raspberry Pi B2
Description of problem:
Forecast.io has an entity sensor.weather_nearest_storm_distance
I wan't to hide it, but I just get an error and hass doesn't start.
Expected:
Customize entry does hide the sensor
Problem-relevant configuration.yaml entries and steps to reproduce:
homeassistant:
  customize:
    sensor.weather_nearest_storm_distance:
      hidden:true

sensor forecast:
  platform: forecast
  api_key: ##############
  monitored_conditions:
    - icon
    - temperature
    - humidity
    - apparent_temperature
    - nearest_storm_distance
    - precip_type

It crashes every time.
Traceback (if applicable):
: Invalid config for [homeassistant]: Value of sensor.weather_nearest_storm_distance is not a dictionary for dictionary value @ data['customize']

Additional info:

You need a space after the colon in: hidden: true

Thanks a lot,
20 lines of Customisation Entities and I oversaw that one.
Greets Jacko


Allow specifying which key optimist uses in acitons

I hoisted up matchesTransaction so it has access to the mapper. Also, real-world 2 uses a custom key, in addition to all the "basic tests". So, custom and default keys are somewhat evenly distributed.
I haven't tested outside of the test suite yet.

I've tested this and found no issues. Would love to get this merged in! @ForbesLindesay @quicksnap

Why is this not merged yet? Would also like to use this.

@ktersius I've forked the repo for the time being and published with these changes https://www.npmjs.com/package/redux-optimist-prime

Any progression on this?

Closing to get it off my PR list. Feel free to reopen and merge if anyone ever wants to!


Add number-mode to math.equation [Better Equation Numbering Pt.4]

...so users can number each line within an equation block.

Closing this for now based on the discussion on Discord.


Removed excessive delay

After short time keyboard stop working.
let event = event::read().with_context(|| "Failed to read event")?;

Can produce ton of terminal events (like mouse movement). With 100ms delay, events are pile up and prevent keyboard from responding.
Bug was introduced by 5013e8f

But wouldn't that mean high CPU usage? just processing events non-stop

Oh, well I completely refactored the whole project, so I don't think we have any delay now. I don't work on this project too much, so I may forget. So if you experience the problem again, you can tell me.


Organize testitems in a tree according to file structure

It seems to me that the discussion in #5 lead to the consensus that testitems should be organized in a tree following the same structure as the filesystem (maybe keeping the possibility to add finer tag-based subdivisions later).
This PR tries to implement this in the non-vscode context, using a tree of nested TestSets to structure the tests. For example, running the tests of TestItemRunner itself now produces the following output:
(TestItemRunner) pkg> test
     Testing TestItemRunner
     [...]
     Testing Running tests...
Test Summary:           | Pass  Total  Time
TestItemRunner          |   18     18  0.1s
  src/TestItemRunner.jl |    9      9  0.1s
    compute_line_column |    9      9  0.1s
  test                  |    9      9  0.0s
    runtests.jl         |    3      3  0.0s
      default_imports   |    1      1  0.0s
      TestSetup         |    2      2  0.0s
    testitemtree.jl     |    6      6  0.0s
      insert_node!      |    2      2  0.0s
      simplify!         |    4      4  0.0s
     Testing TestItemRunner tests passed

In your opinion, would that be a desirable feature ? And a correct implementation of it ?
I feel like the new TestItemTree type introduced in this PR might be useful to structure tests in the same way in the VSCode context, but I'm not sure whether this is actually the case. And if so, I'm not sure where the code could go in order to be useable in both contexts. Do you have any thoughts about this?

Marking this as WIP because the implementation uses (at least) splitpath and only which are not supported in Julia 1.0


fix(userspace): remove 2 event check types not used

What type of PR is this?
/kind bug
Any specific area of the project related to this PR?
/area libsinsp
Does this PR require a change in the driver versions?
No
What this PR does / why we need it:
These 2 check types shouldn't be there, they were moved some time ago here with a different name. We need to remove these 2 old definitions otherwise the sinsp_filter_check_event_fields table will be desynchronized if we append new TYPE_... after these ones
Which issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
NONE

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Andreagit97]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, jasondellaluce
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Andreagit97,jasondellaluce]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 34bd5771817425dd23db8bfef08b47f4f475986d

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, FedeDP, jasondellaluce
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Andreagit97,FedeDP,jasondellaluce]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


No Thread Wall Clock Profile generated ?

Windows 10
It seems that the current release don't support Windows ?
Following the usage and profiled generated, but no Thread Wall Clock Profile ?

Windows 10
It seems that the current release don't support Windows ?
Following the usage and profiled generated, but no Thread Wall Clock Profile ?

版本v2.0.9已支持在windows下产生火焰图，如果还需要的话，可以更新一下版本再试一下