Where is the rest api for azure cost recommendations ?

What is the rest api endpoint for azure cost recommendations ?
https://learn.microsoft.com/en-us/azure/advisor/advisor-reference-cost-recommendations
I see https://learn.microsoft.com/en-us/rest/api/advisor/recommendations/list?source=recommendations&tabs=HTTP
How to list recommendations in the RG level ?

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

ID: 9a8bd5c1-bdc5-34ba-9b18-2783f5239228
Version Independent ID: 172d0699-eb3f-18b0-340b-d40a6a6aa823
Content: Cost recommendations - Azure Advisor
Content Source: articles/advisor/advisor-reference-cost-recommendations.md
Service: advisor
GitHub Login: @ikhapova
Microsoft Alias: ikhapova

@baoj-dfo
Thanks for your feedback! We will investigate and update as appropriate.

@baoj-dfo Appreciate your patience in this matter. From the document link below, you can filter on a specific RG within a subscription - $filter=Category eq 'Cost' and ResourceGroup eq 'MyResourceGroup'
Also, I would suggest that you consider using the Azure Resource Graph if you need to query across multiple subscriptions or across an entire AAD tenant.
•	Azure Resource Graph sample queries for Azure Advisor - Azure Advisor | Microsoft Learn
•	Quickstart: Your first REST API query - Azure Resource Graph | Microsoft Learn
One thing to note is that not ALL recommendations have an associated RG (namely Reservation recos)

@baoj-dfo Thanks for confirming. Closing this for now, as there is no action required.


[Bug] Doesn't work on my wife's phone.

Short summary 📝
The status card is not completely loaded on an other device
Detailed description 📋
At my wife's home assistant account the card is not loaded properly. On my account it works fine.
This card shows up with only battery and fuel states, picture and map under my wife's account. The other like indicators and button and card doesn't show up.  Se pictures in the logs and screenshots
Version 📌
V1.3.1
Environment 🌐
Safari on iPhone and Chrome (ARC) on macbook
Logs and screenshots 📂
This warning we both get:
Warning:
vehicle-status-card.js?hacstag=859371663131:72 Swiper Loop Warning: The number of slides is not enough for loop mode, it will be disabled and not function properly. You need to add more slides (or make duplicates) or lower the values of slidesPerView and slidesPerGroup parameters
JS where this thrown:
function le(t) {     try {         return void console.warn(t)     } catch (t) {} }
Console logs gives the following errors if I am logged in as my wife, i don't get these:
3 times these errors:
Post error on api/template:
fetch-with-auth.ts:20  POST http://homeassistant.thuis:8123/api/template 401 (Unauthorized)
vehicle-status-card.js?hacstag=859371663131:2624 Uncaught (in promise) Error: Error evaluating template: [object Object]     at bn (vehicle-status-card.js?hacstag=859371663131:2624:1989)     at async yn (vehicle-status-card.js?hacstag=859371663131:2624:2239)     at async so._getSingleIndicators (vehicle-status-card.js?hacstag=859371663131:2877:6452)     at async Promise.all (index 0)     at async so._handleFirstUpdate (vehicle-status-card.js?hacstag=859371663131:2877:6349)
The JS where the error is thrown:
async function bn(t, e) {     if (!t || !e)         return "";     try {         return await t.callApi("POST", "template", {             template: e         })     } catch (t) {         throw new Error(Error evaluating template: ${t})     } }
My view:

My Wifi's view (same card):

I also get the invalid authentication error like in the mentioned issue. But I've tracked it down to this card. Maybe it is related somehow.

Hi @Ferrox85, the fix is ready. The new version will be ready after the weekend. 😄

Damn, missed that. That is quick!
Hopefully it fixes the invalid login errors to.

Yes, login error is associated with it, so fixed.

Btw, what kind of car is that? It looks cool

Haha, thats a Lynk & Co 01 plugin hybrid. Very populair in holland right now. And a fine car. It is based on a volvo xc40.

Hi @Ferrox85, I added this fix in the last release. Can you please confirm if this problem is solved? 😄

Yes it did, but it Mixed up the fonts?

When I edit the dashboard it is working correct again. But reopening home assistant and it is back again. I am not sure whether it is an cache issue. Restarting home assistant does not help either.

@Ferrox85 That's strange, I didn't modify any css changes. Can you copy here the config for the button where the problem occurs?

btw any problem with the frontend, that means dashboard lovelace is not solved by restarting HA, but by clearing the cache in the browser. Or reset the frontend cache in the mobile app.
How to Clear Cache for a Specific Page in Popular Browsers

Safari

Open Safari and navigate to the specific page you want to clear the cache for.
Click on Safari in the top menu bar and select Preferences (or press Command + ,).
Go to the Privacy tab and click Manage Website Data.
Use the search bar to find the specific site or page.
Select the site from the list and click Remove.
Confirm by clicking Done.

Google Chrome

Open Chrome and go to the page you want to clear the cache for.
Click the three-dot menu in the top-right corner and select More Tools > Developer Tools (or press Ctrl + Shift + I / Command + Option + I).
In the Developer Tools panel, right-click on the refresh button (🔄) in the toolbar.
Choose Empty Cache and Hard Reload.

Mozilla Firefox

Open Firefox and navigate to the page you want to clear the cache for.
Click the three-line menu (hamburger icon) in the top-right corner and select Settings (or Options).
Go to the Privacy & Security section.
Scroll down to Cookies and Site Data and click Manage Data.
Search for the specific site in the search bar.
Select the site and click Remove Selected.
Confirm by clicking Save Changes, then Remove.

for companion app
In the iOS app.
Sidebar > setting > companion app  > debugging> reset frontend cache

there will be something similar for android

On my mac this problem isn't there. In incognito it goes correct to, so It is weird that flushing the cache on the compagnion app doesn't work properly apperently.


Clicking on the copy button doesn't notify the user

After clicking the button to copy the new url nothing changes in the UI to notify me that the link has been copied.

Hey @Judge-Paul, if you wanted to work on this issue go ahead, or I will fix that later. Thanks for noticing.

@abhijeetnishal Okay I'll work on it
Also there is no padding on the actual input text unlike the placeholder text

Hey @Judge-Paul, please try to fix whatever you think it's good for website.

Fixed by PR #4


AIP exports could produce invalid mets.xml file

Describe the bug
The AbstractMETSDisseminator uses the bitstream's sequenceID as fileID in the METS.
Due to the fact that the sequenceID (see linked issue) could be potentially duplicated in an item these could lead to an invalid mets
To Reproduce
Steps to reproduce the behavior:

force two bitstreams in the same item to have the same sequence ID
run the export aip script with the validate parameter or the trasmit-aip curation task of the replication task suite

Expected behavior
The fileID should be guarantee to be unique. The bitstream uuid can be used for this purpose
Related work
https://github.com/DSpace/DSpace/issues/8466

Per today's discussion in DevMtg, we decided this is a high priority bug & to move to the 7.4 board (waiting on a volunteer).

We'd recommend removing sequence ID from AIP exports/creation (so that new AIPs will no longer have a sequence ID)
However, for AIP import (restore) we will need to continue to support sequence ID because previously exported AIPs may have a sequence ID... so if they are used in a restore action, that sequence ID in the AIP should also be restored (to ensure we are preserving/persisting any old bitstream URLs).


Update swift tools version to 5.5

Motivation:
Xcode warning
Conversion to Swift 5 is available
Modifications:
package.swift
Update swift tools version
Result:
No warnings in Xcode when using SPM

I'm inclined not to merge this directly but to go back to Swift 5.4, to match the NIO project.

thanks for the PR @makleso6 we are deliberately supporting as-old-as-possible versions of Swift in these core API packages. The Xcode "help" message in question sounds like a bug on Xcode side, as the package explicitly declares that it wants to support older versions of Swift.


Enable transactions look-up by signatures

TL;DR
Implemented signature lookup for transactions and improved query filtering.
What changed?

Activated signature lookup in GetTransactionsByContractAndSignature function
Exported ExtractFunctionSelector function
Updated ClickHouse queries to include function selector for transactions
Generalised signature clause handling for both logs and transactions in ClickHouse queries

How to test?

Make a GET request to /{chainId}/transactions/{to}/{signature} endpoint with a valid contract address and function signature

curl --location 'http://localhost:3000/660279/transactions/0x6e55472109e6abe4054a8e8b8d9edffcb31032c5/setMinDstGas(uint16,uint16,uint256)?limit=1' \
--header 'Authorization: Basic ...'

Verify that the returned transactions are filtered correctly based on the provided signature

{
    "meta": {
        "chain_id": 660279,
        "address": "0x6e55472109e6abe4054a8e8b8d9edffcb31032c5",
        "signature": "0xdf2a5b3b87f900bae4c01587a04a2d9f5990f0066e443e87fe88cf2ce9974ff0",
        "page": 0,
        "limit": 5,
        "total_items": 5,
        "total_pages": 0
    },
    "data": [
        {
            ...
            "to_address": "0x6e55472109e6abe4054a8e8b8d9edffcb31032c5",
            "value": 0,
            "gas": 52119,
            "gas_price":<PHONE_NUMBER>,
            "data": "0xdf2a5b3b00000000000000000000000000000000000000000000000000000000000000af00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000030d40",
            "function_selector": "0xdf2a5b3b",
            ...
        }
    ]
}

Why make this change?
This change enables more precise filtering of transactions based on function signatures, improving the ability to query specific contract interactions. It also aligns the transaction querying capabilities with those already available for logs, providing a more consistent and powerful API for data retrieval.

#117  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @catalyst17 and the rest of your teammates on  Graphite

Merge activity

Oct 28, 1:35 PM EDT: A user started a stack merge that includes this pull request via Graphite.


Sweeps: Default tt-smi args in CI will only reset device 0

In tests/sweep_framework/tt_smi_util.py we have it set so that the reset command for tt-smi-metal always uses the flags -r 0.
This will not work for multi-device testing in CI sweep workflows (right now this does not exist)
This approach is based on the /opt/tt_metal_infra/scripts/ci/{arch}/reset.sh script which also naively resets device 0 only. If we have in future some logic to detect which active devices are on a CI run, we can adapt the sweeps workflow to allow for auto resetting of multiple devices.

cc: @xanderchin @tt-rkim

You should assume the reset scripts are able to reset the machine as expected. For example, we have special reset scripts for T3000 and Galaxy. This is what conftest.py:reset_tensix does because it knows that the reset script is correct for the machine. If it's not correct, then we set it up wrong. I can explain further how exactly we know which reset script to install, if you'd like. The install method is quite automated.
Are there machines that you see that have multiple devices that aren't reset properly by the reset.sh?
cc: @TT-billteng


[FLINK-8278] [doc] Fix the private member init problem for Scala examples in docs

What is the purpose of the change
This PR fixes the improper initialization problem for Scala private members in docs.
Brief change log

Assigns the private members with the proper value _.

Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

Hi @fhueske, I wonder if you could have a look at this PR when you are convenient.
Thanks, Xingcan

thanks for the fix @xccui.
Merging

Hi @xccui, I forgot to close the PR while merging. Can you please close the PR?
Thanks, Fabian

Thanks for looking into this @fhueske. I'll close this PR.


vimPlugins.haskell-with-unicode-vim: init at 2022-09-11

Description of changes
vimPlugins.haskell-with-unicode-vim: init at 2022-09-11
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 190784 run on x86_64-linux 1

7 packages built:

gnvim
neovim-qt
neovim-remote
nvimpager
spacevim
tests.vim.test_vim_with_vim_nix
vimPlugins.haskell-with-unicode-vim


SDK-1536,SDK-2073 Update protobuf files

Changed

Protobuf files after regeneration (for Identity Profile requirements)
use "google.golang.org/protobuf" instead of "github.com/golang/protobuf/proto" (latter is deprecated)

Where are the actual .proto files kept?

Where are the actual .proto files kept?

There are kept private, in the sdk-protobuf repo. We don't want to expose these to the public


Added experiments in the experiment folder

Change Log

Tensorflow 2.0 MNIST experiment

Prepare dataset
Select an optimizer
Define the loss functions
Train the neural net
Test the neural net

Backpropagation using numpy

Added Sigmoid and Relu with their derivatives

Decent work. We have to make sure, however, that we don't end up just copy pasting stuff without understanding it. Nobody wants that...

added another example. please review

added test cases for activation functions today and organized activation functions into a module of their own

started constructing main Model classes with forward and backward functions.

Cool stuff. Do you want to merge it?


Update jsoniter-scala-core, ... to 2.13.16

Updates

com.github.plokhotnyuk.jsoniter-scala:jsoniter-scala-core
com.github.plokhotnyuk.jsoniter-scala:jsoniter-scala-macros

from 2.13.10 to 2.13.16.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.github.plokhotnyuk.jsoniter-scala" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequest = { frequency = "@monthly" },
  dependency = { groupId = "com.github.plokhotnyuk.jsoniter-scala" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #413.


[d3d8] Add a config option to hide programmable shader caps

Thought it would be a nice to have option for people who want to experience some d3d8 games as they looked on d3d7-capable hardware (first generation T&L), since most will have a fixed function fallback for this type of situation. I think some early d3d9 games may also have such fallbacks, but they would be notably more rare (and rather bizarre at that point), so I've kept this as a d3d8-only config option.
I guess it could also be used for debugging in some cases, for example NFS High Stakes 2 currently has broken fog with programmable shaders, but its fixed function fallback path renders fog correctly (albeit fixed function reflections and other effects are more primitive than their programmable counterparts).

Non-essential. I'll perhaps consider revisiting it upstream.


use Token in SessionStorage/LocalStorage from your maui blazor code

I have made some updates to your code in the class Auth0AuthenticationStateProvider to allow users to remain logged in after closing their browser in the maui blazor application.Specifically, I updated the method GetAuthenticationStateAsync to include the functionality of storing the token in  localstorage/sessionstorage. Here is the updated code for your reference:
`public override async Task<AuthenticationState> GetAuthenticationStateAsync()
{
    string jsonWebToken = null;
    if (await _localStorageService.ContainKeyAsync(authEntrykey)) {
        jsonWebToken = await _sessionStorageService.GetItemAsStringAsync(authEntrykey);
    }

    if (jsonWebToken == null)
    {
        return new AuthenticationState(currentUser);
    }
    else
    {
        return new AuthenticationState(new ClaimsPrincipal(currentUser));
    }
}

`
In addition, I updated the LogIn method as follows to ensure the user is redirected to the correct page after logging in:
`private async Task LogIn(MouseEventArgs args)
{
    await ((Auth0AuthenticationStateProvider)AuthenticationStateProvider).LogInAsync();
    var authenticationState = await AuthenticationStateProvider.GetAuthenticationStateAsync();

    if (IsConnected(authenticationState) && UserIsAdmin(authenticationState))
    {
        _defaultRedirectUrl = "/dashboard";
    }
}
`

and it doesn't seem to be working. Would it be possible for you to retest and correct the code updated so that all users can benefit from this new functionality? Thank you for your assistance.

@MOAnfaDaniel922, thanks for the feedback and your code snippets. Unfortunately because of time constraints I have not been able to focus on the MAUI project as I hoped and have set it aside for the time being. I do intend getting back to it at some point and will pick up your suggestions then.


HBASE-24646 Set the log level for ScheduledChore to INFO in HBTU

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 28s
Docker mode activated.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
4m 49s
the patch passed

+1 :green_heart:
compile
1m 17s
the patch passed

+1 :green_heart:
javac
1m 17s
the patch passed

+1 :green_heart:
shadedjars
6m 42s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 49s
hbase-server in the patch failed.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 37s
master passed

+1 :green_heart:
checkstyle
1m 32s
master passed

+1 :green_heart:
spotbugs
2m 39s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 24s
the patch passed

+1 :green_heart:
checkstyle
0m 22s
hbase-common: The patch generated 0 new + 2 unchanged - 3 fixed = 2 total (was 5)

+1 :green_heart:
checkstyle
1m  8s
The patch passed checkstyle in hbase-server

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
11m 11s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
2m 54s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 26s
The patch does not generate ASF License warnings.

35m 48s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1987/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1987

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux 3d68e7c2c002 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / af49b87367

Max. process+thread count
94 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 49s
the patch passed

+1 :green_heart:
compile
1m 44s
the patch passed

+1 :green_heart:
javac
1m 44s
the patch passed

+1 :green_heart:
shadedjars
6m 47s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 18s
hbase-common in the patch failed.

-0 :warning:
javadoc
0m 50s
hbase-server in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
2m 10s
hbase-common in the patch passed.

+1 :green_heart:
unit
219m 50s
hbase-server in the patch passed.

255m 17s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1987/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1987

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 37f786efb94b 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / af49b87367

Default Java
2020-01-14

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1987/2/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1987/2/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1987/2/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1987/2/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1987/2/testReport/

Max. process+thread count
2974 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1987/2/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 33s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 22s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  8s
master passed

+1 :green_heart:
compile
1m 26s
master passed

+1 :green_heart:
shadedjars
6m 16s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 59s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m  1s
the patch passed

+1 :green_heart:
compile
1m 24s
the patch passed

+1 :green_heart:
javac
1m 24s
the patch passed

+1 :green_heart:
shadedjars
6m 10s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 56s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 37s
hbase-common in the patch passed.

+1 :green_heart:
unit
234m 27s
hbase-server in the patch passed.

265m 39s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1987/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1987

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 0e226b84ddde 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / af49b87367

Default Java
1.8.0_232

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1987/2/testReport/

Max. process+thread count
2855 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1987/2/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.


It might be too early to enable Mail Hole in Enigmail

TorBirdy 2.3 sets extensions.enigmail.protectHeaders = true, enabling Mail Hole for all sent emails. However, Mail Hole significantly degrades UX for non-Mail Hole recipients, for example by setting a static subject ("Encrypted Message") and breaking threading by dropping In-Reply-To.
If TorBirdy is designed to only be interoperable with other TorBirdy users, then this makes sense, but if communication with non-TorBirdy users is a use case, then Memory Hole cannot be enabled in this shape, IMHO.

(In fact I recommend a quick 2.3.1 that disables this -- me and another Tails contributor has already been affected by this, having had to resend multiple emails to confused recipients.)

On Fri 2017-08-18 11:52:35 +0000, fred-a-kemp wrote:

TorBirdy 2.3 sets extensions.enigmail.protectHeaders = true, enabling Mail Hole for all sent emails. However, Mail Hole significantly degrades UX for non-Mail Hole recipients, for example by setting a static subject ("Encrypted Message") and breaking threading by dropping In-Reply-To.

I am surprised to hear that the initial implementation of memory-hole
drops either In-Reply-To: or References: header.  Has anyone reported
that as a problem upstream?
setting the static subject (and having the actual subject inside the
e-mail, viewable by non-memory-hole clients) is a clear improvement,
not a degradation.  Please don't drop that advancement in torbirdy.
--dkg

I am surprised to hear that the initial implementation of memory-hole drops either In-Reply-To: or References: header. Has anyone reported that as a problem upstream?

When Memory Hole is enabled I think protecting In-Reply-To and References makes sense since those otherwise would leak thread activity. So not a bug/problem IMHO.

setting the static subject (and having the actual subject inside the
e-mail, viewable by non-memory-hole clients) is a clear improvement,
not a degradation.  Please don't drop that advancement in torbirdy.

I agree that Memory Hole is a huge improvement, but only when all participants use it. Those that lack support will unquestionably have a worse UX given the loss of Subject and threading. Or am I missing something? If not, then I argue that we should wait until Memory Hole support is more wide-spread; I fear enabling it now will be counter productive given that it makes OpenPGP even more inconvenient to use and adopt than it already is. (Case in point: we've already had some inconvenience within the Tails project, and if us cryptonerds have problems, I think it's safe to assume average users will as well.)

Tails ticket: https://labs.riseup.net/code/issues/13649
Since this repo isn't used any more I propose we move the discussion there.

I am surprised to hear that the initial implementation of memory-hole drops either In-Reply-To: or References: header. Has anyone reported that as a problem upstream?
When Memory Hole is enabled I think protecting In-Reply-To and References makes sense since those otherwise would leak thread activity. So not a bug/problem IMHO.

A few clarifications and updates:

I've never heard about Memory Hole protecting the two headers that have been discussed here (like it does with the Subject). So far the claim has been that it dropped them.
I've just tested on Debian sid (Enigmail 1.9.9-2) and I see that with Memory Hole enabled, no In-Reply-To and References header is added to an email composed by clicking the "Reply" button. Moreover, any such existing header (in the email being replied to) is dropped. This effectively breaks threads. But I have good news! This is fixed with 2.0~beta1-1 from Debian experimental that preserves these headers and updates them as expected => with this beta version threading works fine :)

Moved this discussion to https://trac.torproject.org/projects/tor/ticket/28493 and added a few updates.


Bioenv fails if 0 variance columns are left after dropping rows with empty cells

Bug Description
If bioenv gets any 0 variance numerical columns, it errors. There is currently a safeguard in place to prevent 0 variance columns from ever reaching the stage where they become an issue; however, after this safeguard we drop all rows containing any empty cells. If any column becomes 0 variance after dropping these rows, we still get the error.

Screenshots

Computation Environment

OS: Linux Mint 19.3 (forum user was using virtual box)
QIIME 2 2020.2

References

Forum post that prompted this.
Ancient forum post in regards to the same thing.
Ancient PR discussed in that forum post that seems to have been superceded.

Again on the forum


File name '[name].ts' differs from '[name].d.ts' only in casing when using --build

TypeScript Version:  3.1.0-dev.201xxxxx
Search Terms:
build
forceConsistentCasingInFileNames
3.0
Code
Example project: https://github.com/nicojs/typescript-3-build-demo
After npm install, use npm run build (or npx tsc --build src/server).
Expected behavior:
Compile without error.
Actual behavior:
Results in error:

src/server/main.ts:2:26 - error TS1149: File name 'C:/z/github/nicojs/typescript-3-build-demo/src/shared/Customer.ts' differs from already included file name 'C:/z/github/nicojs/typescript-3-build-demo/dist/shared/Customer.d.ts' only in casing.

Related Issues: None that I could find that address this issue.

Seems to work like a charm now. Thanks!


Improve readability of last updated repository field

Is your feature request related to a problem? Please describe.
In the Repositories section, each repository has a last updated field. This field shows the last time the repository received changes. Currently the updated_at data is filtered directly into the field, but this data is not very intuitive.
Describe the solution you'd like
It would be best to compare the updated_at data with the current date and have an approximation of when the repository was last updated. For example, if the updated_at data was "2023-02-22T19:57:18Z" and the current date was February 23rd, the last updated field would be better showing "Updated yesterday." There could be separate approximations like "Updated 3 days ago," "Updated a week ago," and "Updated 2 months ago." This work should be done in the Repositories component.
Describe alternatives you've considered
I have considered not including the last updated field, but the field is very important to get an understand of how often a repository is updated.
Additional context

Above is an example of the last updated field. The data in this instance is the string "2023-02-22T19:57:18Z." Although the date can be deduced, it would be far easier for users to be shown that it was updated yesterday.

Commit b59507f solves this issue.


Remove unneeded & incomplete check for ambiguous member

@gavinking if you think this code is good, I can add the test, just let me know where.
TL;DR: the call cd.foo() in the middle of the code below should be allowed.

Presumably this check was in place to detect (and reject) unrelated or
sibling classes or interfaces that both define a member with a name that
we are looking for. But it does not account for:

The likelihood that the "unrelated" types inherit a common supertype that declares the member

The likelihood that whatever type inherits these types has already been proven to unambiguously inherit or override the member, and in any event, the member is ok to reference so long as we can find a common declaration for it.

Further, if a test for ambiguous inheritance of the member by the types
passed as arguments to this method were needed, the current test would
be incomplete, as it only considers shared inherited declarations: the
arguments to this method may be completely ambiguous WRT the criteria in
ways not detectable by this code.

Test code:
interface I { shared formal String foo(); }
interface J satisfies I { shared default actual String foo() => "foo"; }
interface K satisfies I { shared default actual String foo() => "foo"; }
interface L satisfies I { shared default actual String foo() => "foo"; }

class C() satisfies J & K { shared default actual String foo() => "foo"; }
class D() satisfies J & K { shared default actual String foo() => "foo"; }
class E() satisfies L & K { shared default actual String foo() => "foo"; }
class F() satisfies L     { }

C|D cd = C();
cd.foo(); // error but should be allowed (resolve to I.foo())

J|K jk = C();
jk.foo(); // allowed (resolves to I.foo())

C|E ce = C();
ce.foo(); // allowed (resolves to K.foo()), so why isn't cd.foo()!

C|F cf = C();
cf.foo(); // allowed (resolves to I.foo()), so why isn't cd.foo()!

Can one of the admins verify this patch? (see README)

@jvasileff I agree that the error in your test code is a false positive.
But I wonder what other cases your fix affects. Does it introduce new false negatives?

I can't say 100%.
But I believe the check is out of scope for this method, and if it were in scope, it would be ineffective.
For subtyping, I don't think the removed code did anything, since with == criteria, result and std would be the same.
For member lookup, it's always safe to reference a declaration that is declared in a supertype of all cases of a union, and this is certainly preserved.
I think that leaves whatever the typechecker does to make sure you override ambiguously inherited members, but I doubt this code matters for that.

@c881c15 is my proposed fix for this issue.

Force pushed new WIP algorithm after discussion at https://github.com/ceylon/ceylon/commit/c881c15

Rebased and optimized trivial cases. @gavinking, your turn.

OK, merged. Done. Thanks @jvasileff!


Cypress junit report does not parse

When I try to use the action with JUnit reports generated by Cypress I get the message "Result: No test results found!".
Using github actions diagnostics, I can see that the glob is correct and the files can be found:
##[debug]Parsing file /home/runner/work/storefront-nextjs-commercetools/storefront-nextjs-commercetools/cypress/results/test-results-de2cfd939bed9e965b767146fd91b3ad.xml
##[debug]Parsing file /home/runner/work/storefront-nextjs-commercetools/storefront-nextjs-commercetools/cypress/results/test-results-e429e254acdc8ead134925554b8b9954.xml
##[debug]Parsing file /home/runner/work/storefront-nextjs-commercetools/storefront-nextjs-commercetools/cypress/results/test-results-e5f1d2757fdc43272213019c4d69984f.xml
##[debug]Parsing file /home/runner/work/storefront-nextjs-commercetools/storefront-nextjs-commercetools/cypress/results/test-results-e677927f161cfe9a081de1bdde4314cb.xml
##[debug]Parsing file /home/runner/work/storefront-nextjs-commercetools/storefront-nextjs-commercetools/cypress/results/test-results-ed6ac31ad4e97ef6ab0445f5f78f58c7.xml
##[debug]Parsing file /home/runner/work/storefront-nextjs-commercetools/storefront-nextjs-commercetools/cypress/results/test-results-f61adec6c4583a5aa716cb0f08c7a340.xml
##[debug]Parsing file /home/runner/work/storefront-nextjs-commercetools/storefront-nextjs-commercetools/cypress/results/test-results-fd2679bddacfec22ded957a31f30e845.xml
Result: No test results found!

The problem seems to happen because of the empty testsuite element in the report:
<?xml version="1.0" encoding="UTF-8"?>
<testsuites name="Mocha Tests" time="3.2190" tests="3" failures="0">
  <testsuite name="Root Suite" timestamp="2020-12-23T15:22:55" tests="0" file="cypress\tests\catalog\viewsize.spec.js" time="0.0000" failures="0">
  </testsuite>
  <testsuite name="View size" timestamp="2020-12-23T15:22:55" tests="3" time="3.2190" failures="0">
    <testcase name="View size show 9 hits shows 9 products" time="1.4850" classname="show 9 hits shows 9 products">
    </testcase>
    <testcase name="View size show 12 hits shows 12 products" time="1.1490" classname="show 12 hits shows 12 products">
    </testcase>
    <testcase name="View size show 15 hits shows 15 products" time="0.5850" classname="show 15 hits shows 15 products">
    </testcase>
  </testsuite>
</testsuites>

Altough the generated JUnit report looks a bit weird, maybe the action could be more forgiving?

I think this Cypress issue is related: (https://github.com/cypress-io/cypress/issues/8237)(https://github.com/cypress-io/cypress/issues/8237)

If you'd love to add support to this special junit case please feel free to open a PR :) Please also add one of the demo formats to the tests so we can ensure it functions as expected

@mikepenz Thanks for the reply. I realize that this is an issue with the generated report. As a workarround I created a nodejs script that fixes the report. I will close the issue.

Thank you so much. Please let me know if we can do something in the action to be more flexible for such edge cases.


Track provenance information

There is a push in the IPCC to track provenance information for the figures and tables it publishes in its assessment reports. In WGI, ESMValTool and Climate4R have implemented provenance tracking mechanisms around the PROV standard (Climate4R has defined an extension to the stock ontology called metaclip, see metaclip.org for an example). I was wondering if pyam developers had considered similar mechanisms?

Thanks @huard for raising this important topic!
pyam used for recent IPCC reports
For completeness, let me first point to how we handled this in recent work related to IPCC reports.
For the IPCC SR15, the open-source Jupyter notebooks (using pyam) to create a number of figures, tables and statements in the report are available in rendered format and on GitHub.
(doi: 10.22022/SR15/08-2018.15428)
The data used in these notebooks is available via the IAMC 1.5°C Scenario Explorer, with references to the underlying manuscripts on the About page and via individual data panels.
(doi: 10.22022/SR15/08-2018.15429)
For the recently published IPCC SRCCL, @kvcalin used pyam for some of her scenario assessment with an updated version of the same data. She may still publish a suite of notebooks for reproducibility and transparency (time permitting, I guess).
Comment: If such notebooks could be published in parallel and cross-referenced in future reports, that would be a (admittedly low-key, unsophisticated, unstructured) way to increase transparency and show provenance information.
The data model in pyam
A pyam.IamDataFrame consists of a data table containing timeseries information and a meta table containing qualitative and quantitative indicators. One could see the "source" of a scenario as a meta-indicator, using df.set_meta() to mark a certain set of scenarios as originating from a particular manuscript or project. See cells 61-64 in this notebook for a rather clumsy way of using this feature to map scenarios to source manuscripts for the SR15 assessment.
Going forward
Adding an RDF to pyam for tracking entities, agents and activities on an IamDataFrame and embedding it in resulting figures would be feasible in principle (using the Python package prov, for example), but I don't see the resources to implement this in a realistic timeframe. Publishing notebooks together with a graph/figure or table seems, to me, like the more realistic way forward for the time being.

Thanks @danielhuppmann for the detailed answer and your view on what is realistically achievable.

Hi all - FWIW, we employ semantic versioning, continuous integration, and
deploy installable packages via pip and conda. As this is a two to three
person operation at the moment without any funding mechanism, I do not
suspect we will go further without additional resources.
On Mon, Oct 7, 2019 at 4:30 PM David Huard<EMAIL_ADDRESS>wrote:

Thanks @danielhuppmann https://github.com/danielhuppmann for the
detailed answer and your view on what is realistically achievable.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/IAMconsortium/pyam/issues/272?email_source=notifications&email_token=AAKUAELYBNSSAWSI3I7UNFTQNNBZFA5CNFSM4I5PIXA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAQRTAI#issuecomment-539040129,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKUAEOVTM537CGJRYID2GDQNNBZFANCNFSM4I5PIXAQ
.


Trust file by actual location not by path string

Issue Type: Feature Request
I have a path added to my trusted folders list but files located in the folder this path poins to are not truested if they are opened via a directoy junction path.
Directory of C:\Users
15.10.2020  10:24         ltomuta [C:\Users\lucian]
30.07.2021  09:17              lucian
Trusted folder:
C:\Users\lucian\ownCloud\WIP
Untrusted file:
C:\Users\ltomuta\ownCloud\WIP\test.txt
I can fix this by duplicating the paths in the trust settings but I'd hope VSCode would rather resolve all file paths to a unique/real one and rezolve iits trustiness regardless of which path was inputed as.
VS Code version: Code 1.59.1 (3866c3553be8b268c8a7f8c0482c0c0177aa8bfa, 2021-08-19T11:56:46.957Z)
OS version: Windows_NT x64 10.0.19043
Restricted Mode: Yes

This is quite some work since the renderer does not know how to resolve symlinks. We have already introduced the workaround to allow adding both versions of trust in the workspace trust editor.

Isn't this a security risk though? If one manages to place a directory junction in a trusted folder, pointing to an untrusted location, one extends the trust to that location as well. And if junction's target location is the root of the drive...
As long as trust is given by file location the that file location has to be trustworthy in the way it's address is resolved and the items trusted should be uniquely identifiable
Say a symlink is found in a trusted folder. Should you asume that the user knows it is there and what it is pointing to? Or should you prompt to extend (or not) trust to the target folder as well, explicitly? i'd say the later. What if said junction is changed to point somewhere else after it was reviewed and marked trusted for a previous location?


Need to remove and readd DS4 after each reboot (Windows 10)

Hi,
I find it very annoying when I have to "Remove device" the DS4 Controller (named "Wireless Controller") from the Bluetooth menu and then add it by pressing both the PS button and Share at the same time, the process repeating after each reboot. Why is that? Is it the OS, the bluetooth dongle, driver, what is it?
Thanks a lot in advance

same here. would be great to have this fixed (or maybe there is a solution for this issue?)

Same here, does not happen every time but quite often...playing dark souls 2 sotfs


transformIndexHtml hook params ctx add full request param

Description
I'm a little curious why the current ctx only retains the originalUrl instead of the complete req.
it looks like it's technically possible.
for me if can access full req in transformIndexHtml hook is very useful. eg.
I have a vite plugin and use transformIndexHtml hook to transform html and return it, just like
  name:'vite-plugin-xxxx',
  async transformIndexHtml(html, ctx) {
      const res = await axios.get("xxx") // I need like ctx.req.host or headers to submit a request, we use Whistle to proxy to dev, anyway, just show there is indeed we need.
      return replacer(html,res);
    }

I fully know that transformIndexHtml is only work in vite dev server mode
Suggested solution
https://github.com/vitejs/vite/blob/536631a2f54ce3f90105fc586a2c1a5b477eff5f/packages/vite/src/node/server/middlewares/indexHtml.ts#L335
https://github.com/vitejs/vite/blob/536631a2f54ce3f90105fc586a2c1a5b477eff5f/packages/vite/src/node/server/middlewares/indexHtml.ts#L57
Alternative
No response
Additional context
If this is indeed a potential requirement, willing to submit a PR. thanks!
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

The likely reason is that the entire req object isn't entirely related to transforming an html. Usually you'd only need to know which path to the html you're transforming. The request related information are kept for server middlewares instead.
So I'm not sure if it fits to expose the entire req here. Would the config values from resolvedConfig.server.host and resolvedConfig.server.headers be enough for your case?

@bluwy wanted to contribute another use case which may motivate exposing req and res as command-specific properties on ctx passed to transformIndexHtml... I'm working on a CSP plugin for Vite, which has the following minimal example of generating CSP nonces (https://stackblitz.com/edit/vitejs-vite-pckfyp?file=vite.config.js):
let lastNonce;

const cspNonceDevPlugin = {
  name: 'csp-nonce',
  apply: 'serve',

  configureServer(server) {
    server.middlewares.use(
      util.callbackify(async (req, res) => {
        lastNonce = (await randomBytes(16)).toString('base64url');
        res.setHeader(
          'Content-Security-Policy',
          `script-src 'self' 'nonce-${lastNonce}'`
        );
      })
    );
  },

  transformIndexHtml(html) {
    const jsdom = new JSDOM(html);
    for (const script of jsdom.window.document.querySelectorAll('script')) {
      script.nonce = lastNonce;
    }
    return jsdom.serialize();
  },
};

Two drawbacks with the above implementation:

Since the middleware does not know whether this request is for an HTML file, it ends up applying Content-Security-Policy for all requests, not just HTML ones, even though Content-Security-Policy doesn't have any effect on, for example, image responses.
If there was a way to access res within transformIndexHtml, the middleware logic can be moved there.
Since Vite already does the work to determine whether a request is for an HTML file,
https://github.com/vitejs/vite/blob/0fed2104ad07f0de4dbf29ed8d6047b6918c7db3/packages/vite/src/node/server/middlewares/indexHtml.ts#L379-L401
reimplementing the same within middleware doesn't seem like a good solution.

Since there is no way to ensure that middleware and transformIndexHtml correspond to the same request, passing data using a global variable (lastNonce) seems unsafe. What if async requests are interleaved?

Request A (url: /) calls async middleware and sets lastNonce
Request B (url: /@vite/client) calls async middleware and overwrites lastNonce
Request A calls transformIndexHtml, which consumes lastNonce from (ii) instead of (i)

Even though req.originalUrl in middleware corresponds to ctx.originalUrl in transformIndexHtml, not all requests are HTML requests, so storing data keyed by req.originalUrl which is never consumed by transformIndexHtml also seems unworkable.

Circling back to the original ask, since transformIndexHtml already exposes context-specific parameters
https://github.com/vitejs/vite/blob/0fed2104ad07f0de4dbf29ed8d6047b6918c7db3/packages/vite/src/node/plugins/html.ts#L926-L939
it doesn't seem like such a bad idea to also expose req and res in vite dev and vite preview modes. WDYT?

The context provided in transformIndexHtml today balances how you transform the HTML during dev and build, which in dev you have access to server and originalUrl, in build you have access to bundle and chunk.
req and res are geared much towards dev, and it could be misleading that req and res would also be set when you run your app in prod, which they don't.

Since the middleware does not know whether this request is for an HTML file, it ends up applying Content-Security-Policy for all requests, not just HTML ones

You can inject a post-middleware (return a function from configureServer) and check for req.url?.endsWith('.html') and it should also work. The indexHtml plugin you linked runs near the post-phase too.

Since there is no way to ensure that middleware and transformIndexHtml correspond to the same request, passing data using a global variable (lastNonce) seems unsafe. What if async requests are interleaved?

I don't have much experience with CSP. But if Vite does provide req and res today, how would you handle them in prod too? If prod does have a CSP middleware to handle it, I think it could also only be a middleware in a Vite plugin.
e.g. you can patch res.end = () => { /* do something and call res.end again */ } and inject your CSP handling there too.

Thanks for getting back @bluwy!

req and res are geared much towards dev, and it could be misleading that req and res would also be set when you run your app in prod, which they don't.

Indeed, and my hope is that documentation could remediate any confusion about which parameters are available during which commands. Presently, this is covered in the documentation in the sentence

The context exposes the ViteDevServer instance during dev, and exposes the Rollup output bundle during build.

If any additional context-specific parameters were to be added, they would be optional and it could hopefully be clear which command they apply to. (Also, happy to contribute PR(s) to help with this if the time comes.) 😃

You can inject a post-middleware (return a function from configureServer) and check for req.url?.endsWith('.html') and it should also work. The indexHtml plugin you linked runs near the post-phase too.

Nice! Since this relies on post-middleware being run for HTML file requests, I hope that after #14690 is resolved by #14756, vite preview does the same; otherwise, this approach won't work for vite preview.

I don't have much experience with CSP. But if Vite does provide req and res today, how would you handle them in prod too? If prod does have a CSP middleware to handle it, I think it could also only be a middleware in a Vite plugin.

I wouldn't handle them in prod! 😅 At least for the approach I've taken with CSP, there are two distinct plugins which implement CSP differently—an apply: 'serve' plugin which uses nonces (useful in dev), and an apply: 'build' plugin which computes JS hashes (useful to minimize transformation in production server), injects integrity attributes to <script> tags, and emits a full set of hashes to a separate file (to be consumed by the production server). This separation seems to make sense because during vite dev, Vite is doing the serving, but in vite build, the serving is done by the production server (e.g., Express, GitHub Pages, etc.), so there is a natural asymmetry around which entity is responsible for emitting HTTP response headers in either case.
But if one is forced to use use nonces in production, I believe the plugin must emit a placeholder during build in transformIndexHtml (e.g., <script nonce="__NONCE_PLACEHOLDER__">)—which requires only the html parameter; no other context required. When the Vite build output is served to customers, the HTML files must be transformed at serve time to inject the nonce generated by the server.

e.g. you can patch res.end = () => { /* do something and call res.end again */ } and inject your CSP handling there too.

This is an interesting hack/patch! Will need to try it.

(Also to be clear, I'm not opposed to adding it yet. Trying to understand its usecase as transformIndexHtml also has many caveats today)

Thanks for clarifying your present feeling on the matter! I believe I may have run into one such caveat with transformIndexHtml in my implementation of the apply: 'build' plugin which computes hashes... As it turned out, transformIndexHtml runs before some final JS transformations during build—namely postImportMapHook():
https://github.com/vitejs/vite/blob/055d2b86b0543a7c1a2a4d5bc7298af62bc51fa7/packages/vite/src/node/plugins/html.ts#L288-L293
As a result, if the JS chunk referenced from HTML were to be hashed in transformIndexHtml, its content would be different from the final output, and therefore the hashes wouldn't match. To work around this, the plugin uses a generateBundle hook with order: 'post' to defer hashing JS chunks until after postImportMapHook() runs.
Zooming out a bit, the original thought behind exposing req and res within transformIndexHtml was not to upset the balance between build and serve modes, but rather to attempt to improve the ergonomics of working with the current request/response during vite dev/preview only, without having any effect on vite build. By contrast, during build, Vite already runs the rich set of Rollup hooks, so the ergonomics of working with the current module/chunk/bundle already seem quite flexible and extensible by comparison (e.g., given the generateBundle example above).

Thanks for the explanation! That clears things up and I can see how it's useful here now. One thing to also note with transformIndexHtml is that it doesn't work with most SSR frameworks at the moment. Vite plugins can only run at build-time (and transform html in build time). SSR only generates the html in runtime so its too late then. This has hit a lot of Vite plugins that want to support many frameworks today.
But even so, I think this could be worth considering. I'll put this on the team board for discussion, though our backlog is kinda packed so it might take a while. Feel free to send a PR if you'd like too, it seems like a simple change.

One thing to also note with transformIndexHtml is that it doesn't work with most SSR frameworks at the moment. Vite plugins can only run at build-time (and transform html in build time). SSR only generates the html in runtime so its too late then. This has hit a lot of Vite plugins that want to support many frameworks today.

Good to know, thanks for the callout! The SSR example made me think of something I didn't consider before—if req/res are added to the set of parameters passed in ctx of transformIndexHtml hook, what should happen when the hook is invoked via ViteDevServer.transformIndexHtml? On the one hand, ViteDevServer.transformIndexHtml could be extended to take req/res pass them through to transformIndexHtml hook, treating them as opaque values which default to undefined. On the other hand, it might be making an assumption about the SSR server being Express-like. What do you think?
From my perspective, the former seems to minimize any asymmetry, and may make sense if ViteDevServer.transformIndexHtml is primarily used for SSR in development mode.

But even so, I think this could be worth considering. I'll put this on the team board for discussion, though our backlog is kinda packed so it might take a while. Feel free to send a PR if you'd like too, it seems like a simple change.

Thanks again! 🙌 I would love to make a PR for this.

if req/res are added to the set of parameters passed in ctx of transformIndexHtml hook, what should happen when the hook is invoked via ViteDevServer.transformIndexHtml?

I think it should be fine as the middlewares Vite provides in SSR are connect-like (requires req and res), so setting up a SSR framework like hapi with Vite would already not work well.
But it is something also think about though, the added req and res parameters passed to ViteDevServer.transformIndexHtml would not look great, that makes it 5 params. Unless maybe the third parameter is made an optional object.

I think it should be fine as the middlewares Vite provides in SSR are connect-like (requires req and res), so setting up a SSR framework like hapi with Vite would already not work well.

Got it, thank you. 👍

But it is something also think about though, the added req and res parameters passed to ViteDevServer.transformIndexHtml would not look great, that makes it 5 params. Unless maybe the third parameter is made an optional object.

Took your advice and in #14797 made the last parameter an optional object.


Using default values does not work as expected on non-nullable types

When using the HasDefaultValue() method on fields that are non-nullable, EF does not behave as expected. When explicitly providing a different value for a non-nullable field, the provided value is overridden by the default value. Changing the field to be nullable does however work as expected.
Please make sure to include this in the documentation or possibly file a bug report.

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

ID: 97d622b2-1e4b-4d76-b3df-fefaa5ba99cb
Version Independent ID: ec833af2-275e-981f-689f-8c65edfc00cd
Content: Generated Values - EF Core
Content Source: entity-framework/core/modeling/generated-properties.md
Product: entity-framework
Technology: entity-framework-core
GitHub Login: @AndriySvyryd
Microsoft Alias: avickers

@antonthomas Currently the default value is used whenever the property is set to the CLR default. Configuration of this is tracked by https://github.com/dotnet/efcore/issues/701. Please vote for that issue if this is something you need.


mdx-bundler production type check conflict

What version of Remix are you using?
1.1.1
What version of Node are you using? Minimum supported version is 14.
16.13.1
Steps to Reproduce

Clone https://github.com/zslabs/zslabs-remix
npm i
npm run dev
Visit /about
You'll notice content pulled-in from content/posts/hello-world.mdx that is parsed via mdx-bundler inside of app/routes/about.tsx
Stop server
Run npm run type:check
Remix complains about duplicated mdx exports. Confused about the issue ❓

Expected Behavior
npm run type:check completes successfully
Actual Behavior
Running npm run type:check produces the following:
> zslabs-remix@ type:check /Users/zach/Sites/zslabs-remix
> tsc --project tsconfig.json --pretty --noEmit

node_modules/@remix-run/dev/modules.d.ts:35:20 - error TS2300: Duplicate identifier 'default'.

35     export default Component;
                      ~~~~~~~~~

  node_modules/@types/mdx/index.d.ts:76:14
    76     export { default } from '*.mdx';
                    ~~~~~~~
    'default' was also declared here.

node_modules/@types/mdx/index.d.ts:76:14 - error TS2300: Duplicate identifier 'default'.

76     export { default } from '*.mdx';
                ~~~~~~~

  node_modules/@remix-run/dev/modules.d.ts:35:20
    35     export default Component;
                          ~~~~~~~~~
    'default' was also declared here.

node_modules/mdx-bundler/dist/types.d.ts:197:36 - error TS2304: Cannot find name 'MDXContentProps'.

197   default: React.FunctionComponent<MDXContentProps>
                                       ~~~~~~~~~~~~~~~

Found 3 errors.

Adding "skipLibCheck": true to my tsconfig.json file did the trick
https://www.typescriptlang.org/tsconfig#skipLibCheck
It'd still be nice to know if this would be a recommended setting moving forward we should add to Remix, or if there's still something I'm missing on my end.

I get 22 errors with conflict between node_modules/typescript/lib/lib.dom.d.ts and node_modules/typescript/lib/lib.webworker.d.ts

This seems to be due to the fact that both Remix and @types/mdx are declaring types for all *.md/*.mdx files. Apart from setting skipLibCheck to false which I agree doesn't seem ideal, I'm not sure how best to deal with this. Either way I don't think this is something we can deal with on the Remix side. Since mdx-bundler doesn't seem to need any global types set, maybe you could raise this as an issue upstream?


Restarting bridge. Error: rpc::rpc_error during call in function get_sensor_token

Describe the bug
Hello,
when executing the bridge.py it spams this error multiple times a second:
WARNING: Version mismatch detected: You are trying to connect to a simulator that might be incompatible with this API
WARNING: Client API version     = 43b5e70-dirty
WARNING: Simulator API version  = 0.9.13
Restarting bridge. Error: rpc::rpc_error during call in function get_sensor_token

this occurs when executing either ./start_openpilot_docker.sh or ./bridge.py and ./launch_openpilot.sh
My efforts to make the Client API version match the Simulator API version were unsuccessful.
Using an older docker image, seems to work as a workaround (from 30 days ago)
I have not tested which version exactly introduces the breaking changes.
OS Version
Ubuntu 20.04.6 LTS
openpilot version or commit
f911e5f02869475acfb634a058771390fb2273c7
Additional info
In Version 9.2.0 (release commit)
Hash: 89f68bf0cbf53a81b0553d3816fdbe522f941fa1
The same error occurs when executing ./start_openpilot_docker.sh but not when executing ./bridge.py and ./launch_openpilot.sh.
This leads me to believe that the latest docker image of openpilot_sim might be a/the reason for this. (Please correct me if im wrong.)

same question, ubuntu 22.04, run sim

Hello guys,
Please, I need your help on how to run this simulation. I'm novice.
I have already downloaded the dataset.

After some more fooling around with the situation, it seems to me like the version change to Python 3.11 broke the client API compatibility.
In this pr #28843 the carla client version is defined to be exactly this:
https://github.com/commaai/openpilot/blob/21802265bec5ede0eaf4093ba0cd2c4c5be3b1af/pyproject.toml#L68C1-L68C1
carla = { url = "https://github.com/commaai/carla/releases/download/3.11.4/carla-0.9.14-cp311-cp311-linux_x86_64.whl", platform = "linux", markers = "platform_machine == 'x86_64'" }

Which seems to be made for carla version 0.9.14, yet the file tools/sim/start_carla.sh specifically uses 0.9.13.
After updating tools/sim/start_carla.sh to use carla 0.9.14 the error disappears, only the version warning remains (makes sense).
This seems like a great opportunity to try make my first contribution.

THANKS SO MUCH THIS FIXED MY PROBLEM!


POC: Sigstore verification in ilab download

Changes
Which issue is resolved by this Pull Request:
Resolves #
Description of your changes:
This POC requires https://github.com/instructlab/instructlab/pull/1181.
Now, the ilab download command will search for a Sigstore bundle present in the remote Huggingface repository and attempt to verify the downloaded model against it, much like the new ilab verify command added in #1181.

marked as a Draft while it's marked as a POC


tell voicemail users about incoming line

It isn't fully polished, but I think it's ready enough to tell the horde of voicemail users!
After creation, tell them incoming number before dropping them into voicemail, similarly to how we tell them password.
Have a voicemail info option in the main voicemail menu which tells them number and explains voicemail basics

added basic info to the voicemail menu, which is good enough for now


Make README.md more inviting to contributors

The README.md previously stated non CODEOWNERS could not contribute. This
is in violation of the spirit of the Istio project. Correct that problem by
making the README.md more inviting.
Our goal is to build a team. The code is a byproduct of that effort.
The MVP was a little difficult to parse and used an ordered list. Simplify the
wording of the MVP such that it is a little more vague, but a little less wordy.
Finally remove the ordering of the MVP feature set since all requirements are
of equivalent value.

I agree re the MVP - the goals are not clear.  I simply rewrote the existing goals in a more concise format.  We should have further discussion about what the MVP is, but I didn't change anything that wasn't already in the doc :)

Thanks for taking a stab at this @sdake. A couple of things:

could we hold this off for a couple more days while I wrap up the outstanding PR's? They are getting close and I was able to merge several today. I think having those in there will create a much more meaningful starting point for other contributors.
I'm not sure if there's much value anymore in even mentioning the MVP. We can give an overview of the operator goals and architecture and leave it at that? I'm not sure we have to publicly announce whatever decision we reach in the WG.

Thanks for taking a stab at this @sdake. A couple of things:

could we hold this off for a couple more days while I wrap up the outstanding PR's? They are getting close and I was able to merge several today. I think having those in there will create a much more meaningful starting point for other contributors.
I'm not sure if there's much value anymore in even mentioning the MVP. We can give an overview of the operator goals and architecture and leave it at that? I'm not sure we have to publicly announce whatever decision we reach in the WG.

sounds reasonable.  I think it makes sense to let the folks that know the current arch and implementation provide the architecture overview and feature set.  I'll hold off on the PR until sometime early next week if that is sufficient time.
Cheers
-steve

I agree re the MVP - the goals are not clear. I simply rewrote the existing goals in a more concise format. We should have further discussion about what the MVP is, but I didn't change anything that wasn't already in the doc :)

makes sense

PTAL at https://github.com/istio/operator/pull/61.
If we're happy with that, let's close this.


SAMBRO:remove blank lines from HTML + add the text back to the label + CAP: update, cancel and clear msg type

@flavour Please merge

I don't have the time right now to review everything, so just commenting on the most critical things.
Will review again once you've fixed these.


core: Handle address lookup and bind errors more gracefully (fixes #136 and #164)

Addresses which fail to resolve are handled more gracefully in the two most common cases: the hostname doesn't resolve or the port is unknown (like "http" or "https" on a system that doesn't support those port names). If the hostname doesn't resolve, the host is served on the listener at host <IP_ADDRESS>. If the port is unknown, we attempt to rewrite it as a number manually and try again.
/cc @wmark and @coolaj86 - would you please take a look at this and see if this will do?

Well, that's interesting - the tests passed locally. I'll look into this further...


fix: rightClick with ctrl or command key

fix: rightClick with ctrl or command key out of section
refactor: improve getting whether the cursor is in the selection
feat: alert on some operation with multi-section

LGTM

LGTM


Version CRD's by apiVersion and then product version and remove use of weblogic.resourceVersion label

The initial intention of this change was to support versioning the CRD both based on apiVersion and then by operator product version. Before this change, the CRD was versioned based on the apiVersion (e.g. "v7") and on a not-well-defined "weblogic.resourceVersion" that never changed. The problem with this pattern is that while the "v1beta1" version of CRD's just have one schema even as you support multiple apiVersions, the newer "v1" CRD's must provide a schema for every supported version and this quickly exceeds the maximum size of a CRD (because of etcd limitations).
Therefore, I want a pattern that lets us stay at apiVersion "v8" for as many releases as possible. It is reasonable to stay at the same apiVersion if from operator release to release we only add to the schema new, optional fields.
I thought about using this "weblogic.resourceVersion" label, but that would require defining an ordering on the values of this field and it seemed clearer just to use the semantic version ordering of our product release numbers.
Since we are also going to 3.0.0 and many of these "weblogic.resourceVersion" label values contained "v2", I decided to just remove these.

I noticed below 2 doc files with label "weblogic.resourceVersion: domain-v2" and was wondering if label reference should be removed from these?
weblogic-kubernetes-operator/site/v2.0.1/config-overrides.md
weblogic-kubernetes-operator/site/v2.0/config-overrides.md

@ankedia, I left these files alone because they are doc from the 2.0.1 and 2.0 releases of the operator. At some point, we should probably just delete all of the saved doc. from these very own releases. In general though, when fixing doc., we don't go back and fix the doc from older versions unless it's critical.


Add support for non-multipolygon relations (routes, etc).

This pull requests allows to create tables from relation and relation members.
This allows to insert full relation metadata into multiple tables.

[ ] extend tests
[x] extend documentation
[x] rename relation_member_*

Documentation is available at http://imposm.org/docs/imposm3/latest/relations.html
Tests are present, but could still be extended.


feat: update page parsing due to npmjs.com HTML changes

npmjs.org appears to have changed their HTML which is preventing the Sonatype Platform Browser Extension for working on all components in NPM.

:tada: This PR is included in version 2.12.0 :tada:
The release is available on:

Chrome Web Store
v2.12.0
GitHub release

Your semantic-release bot :package::rocket:


OCI namespaces docs addition/clarification

Issue #, if available:
#6418
Description of changes:
OCI namespaces docs addition/clarification on having at least one entry for public.ecr.aws
Documentation added/planned (if applicable):
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve
/lgtm


Consider changing the gem name

Hi @bokmann,
I don't really expect this to sway you, but oh well, I'll try.
I just started using this gem at work. I found out what the gem name references, and it's not super professional and could be reasonably alienating (making people not very comfortable at work).
I know it's technically super annoying to change the gem name (maybe publish to two gem names on rubygems? another hassle, I know).
I say all this as a one-time very tired/thankless OSS dev/maintainer. You made this gem, I didn't, and I get that. If anything, please just give this idea a couple minutes of thought.
-Alan

This gem existed for more than a year before I even knew the pop culture reference you're making existed.  This gem was not named after that song, it was named solely for the purpose it served in the business logic from which it was extracted.  I was kinda annoyed when I first found out about it; I hate making references that might not fit in professional contexts.
As far as 'not being super professional', Really, any name can be co-opted by a pop culture reference (just ask the poor guy in 'Office Space' named 'Michael Bolton'!), and I don't want to change the name to avoid one that I wasn't referencing in the first place.

Hey @bokmann,
I really appreciate the response!
For whatever reason, I am much happier knowing the (non-)origins to the gem name.
-Alan


WIP adopting manifests and signing classes

WIP do not merge
This is my first draft of adopting the new signing and manifest primitives for actual signature creation and serialization to disk. For now the idea is to use BytesSigner to sign the contents of the manifest payload and provide verification material. That can then be stored on disk together with the signed payload as a tuple of (SigstoreBundle, Manifest).
@mihaimaruseac PLMK what you think about this approach

If you want to see the entire work to convert manifests to in-toto, #267 (I split it into a series of PRs with various in-toto payloads to ease reviews - every PR should just look at the last commit).

Sorry, just saw this.
I was working on this area too, as said via chat. I'll push my PR shortly, once I clean it. But I think we can go directly to in-toto now, we don't need to replicate the manifest once more

ok, I'll leave it at that and stop trying to contribute for now.

That wasn't my intention :(


Readme

Please update readme, missing an explanation of how the tool works and usage in general.

The issue is now fixed and the README is updated


Why does the rochpcg result show that the data transportation capacity is higher than the bandwidth?

I ran rochpcg program with 560 280 280 60 parameters, and the results are as follows:
GB/s Summary=
GB/s Summary::Raw Read B/W=1208.45
GB/s Summary::Raw Write B/W=279.154
GB/s Summary::Raw Total B/W=1487.6
GB/s Summary::Total with convergence and optimization phase overhead=1476.61
GFLOP/s Summary=
GFLOP/s Summary::Raw DDOT=180.169
GFLOP/s Summary::Raw WAXPBY=76.0718
GFLOP/s Summary::Raw SpMV=158.515
GFLOP/s Summary::Raw MG=212.227
GFLOP/s Summary::Raw Total=196.268

However I notice that the bandwidth of MI100 is up to 1.2TB/s according the instinct-mi100-brochure.pdf, why the GB/s of rochpcg is nearly 1.5TB/s which can be  higher than the bandwidth 1.2TB/s ?

Those numbers are computed by the HPCG benchmark. They are corresponding to the standard implementation which differs from rocHPCG and therefore the numbers are not reflecting the actual bandwidth of the GPU.
We cannot modify or adjust those numbers, as they are part of the reference code.


JavaServer ping() always fails? ("did not respond with any information")

ping doesn't seem to work for any servers I've tested, most of which return:
OSError: Server did not respond with any information!

Traceback (most recent call last):
  File "/home/rina/progs/mcstatus/mcstatus/__main__.py", line 104, in <module>
    main()
  File "/home/rina/progs/mcstatus/mcstatus/__main__.py", line 100, in main
    args.func(server)
  File "/home/rina/progs/mcstatus/mcstatus/__main__.py", line 11, in ping
    print(f"{server.ping()}ms")
             ^^^^^^^^^^^^^
  File "/home/rina/progs/mcstatus/mcstatus/server.py", line 94, in ping
    return self._retry_ping(connection, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/rina/progs/mcstatus/mcstatus/utils.py", line 67, in sync_wrapper
    raise last_exc  # type: ignore # (This won't actually be unbound)
    ^^^^^^^^^^^^^^
  File "/home/rina/progs/mcstatus/mcstatus/utils.py", line 63, in sync_wrapper
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/home/rina/progs/mcstatus/mcstatus/server.py", line 100, in _retry_ping
    return pinger.test_ping()
           ^^^^^^^^^^^^^^^^^^
  File "/home/rina/progs/mcstatus/mcstatus/pinger.py", line 63, in test_ping
    response = self.connection.read_buffer()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/rina/progs/mcstatus/mcstatus/protocol/connection.py", line 319, in read_buffer
    length = self.read_varint()
             ^^^^^^^^^^^^^^^^^^
  File "/home/rina/progs/mcstatus/mcstatus/protocol/connection.py", line 257, in read_varint
    part = self.read(1)[0]
           ^^^^^^^^^^^^
  File "/home/rina/progs/mcstatus/mcstatus/protocol/connection.py", line 549, in read
    raise IOError("Server did not respond with any information!")
OSError: Server did not respond with any information!

For example:
poetry run python -m mcstatus mc.hypixel.net ping
poetry run python -m mcstatus mccentral.org ping
poetry run python -m mcstatus demo.mcstatus.io ping
poetry run python -m mcstatus play.purpleprison.net ping

Note, this was tested through the CLI but I can't see why it would be CLI specific.

After poking in Wireshark, I can't find a problem. The Python is sending the handshake and ping packet correctly. The server is closing the connection without sending any bytes, and the Python is handling that closure.

can reproduce

Is a status packet required before ping? Wiki.vg says no, but performing a status first in the connection seems to fix it. I don't know if this caused by the protocol or a socket bug.

Apparently, we already saw this bug in https://github.com/py-mine/mcstatus/pull/491. worth looking for why it wasn't already fixed on the server implementations side
Not closing this, because we should probably add a note to docs about this.

I see, would it be a good idea to implement ping in using status, then? Maybe ping can automatically fallback to status.
I imagine this is what the vast majority of users would prefer. For ping, you could abort the connection after reading the status response ID to avoid deserialising the whole response.

Closing as a duplicate of #491
Use latency from status object or your own timings as a workaround. We are not able to help with all the non-vanilla implementations behave differently.

I don't see a point in clinging onto a function that works on only a fraction of active servers? Regardless of technical correctness, this is a disaster for the user experience, and at the very least needs an easily discoverable warning.

I do agree that we can add a note/warning to the ping docstring, as it can be weird to users that it doesn't work when the server is up and status does work. However, this really is an issue with the upstream server implementations. It is them who don't follow the spec properly.
Making an additional status request before ping is very wasteful from our side and using status packet instead of ping for the ping method makes no sense, at that point, just use status. At most, we could add a bool arg that would make this extra status request in ping, ignore it and then perform ping. But I don't love that idea.
We already manually count the time it took for the server to respond when you're using status, so you can just use the latency parameter from that if you need it.
We could also consider deprecating ping entirely and just keeping status, considering it contains the latency anyways.

I'd support implementing ping() entirely in terms of status(). I don't see a need to remove ping() and push this task onto every user of the library.
With an implementation as status().latency, the basic ping would depend on the well-formedness of the status response which might not be desirable. This is why I suggested a ping sends a status packet but ignores the data payload of the response, thus acting in a different way to status().latency.
Finally, there is a rare possibility, mentioned in #491, where a server might support ping and not status. It would be useful to keep the real ping accessible for such cases (either through a flag or different method name).

Reopening this, since discussion is not over and we definitely have to add a note/warning to docs about this.
Anyway, I agree with ItsDrike, it's server implementations who don't follow the spec, and appropriate bug report should be opened at their repos. ping() is designed to be as simple as possible, and there is no need to over design it with status().

Yeah, that is even better solution. If I won't forget, I will create a PR for this

I also agree it would be wasteful to request full status from the server and not use it, hence ping should be separate and standalone. Adding the documentation tag for this, but I have concern that this particular OSError is indistinguishable from legitimate cases where the server crashes or a firewall drops the response.

Sure, you could report to the user "if ping fails but status succeeds, it is likely .....".

You can check against error message


request: update to v14

Is there an existing issue or pull request for this?

[X] I have searched the existing issues and pull requests

Feature description
Update to discord.js v14
Desired solution
Make a branch and start updating codebase to v14 as soon as Sapphire supports v14
Alternatives considered
None
Additional context
Blocked by Sapphire v4 release

Will Re-Open when v4 arrives


🐛 Add cluster to scheme and rbac

Unsure how we missed this, but we are seeing the following error from the controller
E0417 17:55:21.003315       1 logr.go:279] "controller-runtime/source: kind must be registered to the Scheme" err="no kind is registered for the type v1beta1.Cluster in scheme \"pkg/runtime/scheme.go:100\""

This PR addresses this bug by adding Cluster to the scheme and RBAC role.

@flawedmatrix What are the cluster objects beings used for?
From this https://github.com/telekom/cluster-api-ipam-provider-in-cluster/blob/1144752b5b72118d13c4e9f9539af6c468ca2def/internal/controllers/ipaddressclaim.go#L70-L89, seems like we are adding a watch on the Cluster object, and any update on the Cluster object is requeuing all the IPAddressClaims for the Cluster (irrespective of any relevant changes on the pool/claims themselves)
My suggestion is to remove the watch altogether and continue using the other watches to reconcile the claims. @schrej wdyt?

We've added a feature that pauses claim reconciliation when a cluster is paused. The watch is there to reconcile again once the cluster is unpaused. If we want to keep the feature, we need to keep the watch as well.
I somehow missed this PR and opened another one just now :D


why the params size of b0 model is 20M rather than 5.3M

Hi, @rwightman ~
Thank you for sharing your code.
But I have a question.  The paper said that the Params size of the efficientnet-b0 model is 5.29M，but the size of pretrained model what you offered is 20.3M,
and then I test it through torchsummary, which also shows that Params size (MB): 20.17, why?

#torchsummary code:
import timm
modelBody = timm.create_model('efficientnet_b0', pretrained=True).to(device)
from torchsummary import summary
summary(modelBody, input_size=(3, 224, 224))

#result
Total params: 5,288,548
Trainable params: 5,288,548
Non-trainable params: 0
Input size (MB): 0.57
Forward/backward pass size (MB): 124.93
Params size (MB): 20.17
Estimated Total Size (MB): 145.68

the params are float32, float32 is 4 bytes, 5288548 × 4 / 1024^2 = 20.17


Update pipeline-service in development/staging

Create pipelines-scc SecurityContextConstraint via ArgoCD.
Disable the pipeline service account

Turn off creation of RBAC resources
Add job to create the service certificate authority for Chains, which was provided by the OpenShift Pipelines Operator RBAC feature (not documented!)

Disable image signing test

/hold
I have a few concerns:

Image signing test is disabled, this means we are not verifying that chains is working properly end to end.
We are using a job to re-create the ca-bundle for chains to access the internal registry (I believe this is why we need it?). This might be prone to a race condition between the operator and ArgoCD.

@adambkaplan

The test was deactivated in pipeline-service, but my understanding is that there is a test in the e2e suite.
Is it that the job might be run before the old cabundle has been deleted? Could it be solved by moving the job to another sync-wave, or do we have to be smarter about it?

@adambkaplan I've opened https://github.com/openshift-pipelines/pipeline-service/pull/645 to address #2.

/lgtm

/lgtm


Could not read template 'true,module'

Running dts-gen seems to prepend "true," to any template provided preventing a new module from being created.
e:\_git\DefinitelyTyped>dts-gen -dt --name webpack-ts-loader --template global-modifying-module
Invalid arguments: Could not read template 'true,global-modifying-module'. Expected one of:
global-modifying-module, global-plugin, global, module-class, module-function, module-plugin, module

Try removing the 't' from the '-dt', that worked for me.


Fix fonts

Details
cc @Luke9389 Fixes font paths
Fixed Issues
$ https://expensify.slack.com/archives/C07J32337/p1670008137700449
PROPOSAL: GH_LINK_ISSUE(COMMENT)
Tests

Checkout this branch and run npm i
Open the App
Verify that the fonts are ExpensifyNeue

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

Offline tests
N/A
QA Steps
Same as tests

[ ] Verify that no errors appear in the JS console

PR Author Checklist

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

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

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

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

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

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product was added in all src/languages/* files
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

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

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

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

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

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

I tested this PR on web and it works, but I've also undone the change and that works too...
Does that make any sense to you @roryabraham?

I think this is coming from storybooks webpack config. Should we just remove the font from storybook to fix the errors right now and then add it to storybook later?

Pretty sure we are looking in the wrong place and need to fix this in the CSP:

I think this is the PR we'll need to fix web fonts on staging and production: https://github.com/Expensify/Cloudflare-Workers/pull/44
It sounds like storybook might be having a separate problem, but the CSP issue is the most important rn because it fixes a deploy blocker

Closing in favor of https://github.com/Expensify/Cloudflare-Workers/pull/44


feat: add entities:rename command

:tada: This PR is included in version 1.4.0-beta.4 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 3.0.0-beta.1 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


How to define the initial scale of the jump distribution?

I may have missed it in the documentation: is there a way to define the scale of the initial jump distribution? This would be useful because the parameters may have very different orders of magnitude (which is often know from the prior).
Thanks for the great package!

Thanks for a good question. I had not thought about this use case at all, but it can certainly help the initial mixing and adaptation if you provide a good starting value for the adapted scale/shape matrix.
To make this slightly more ergonomic, I added a possibility to provide keyword arguments to the Adaptive MCMC algorithm constructors. Here's an example with the new interface, which uses RAM with given initial shape (rather than default identity):
using AdaptiveMCMC, LinearAlgebra

log_p(x) = -100x[1]^2 - x[2]^2 - 0.01x[3]^2
x0 = zeros(3)
S0 = cholesky(diagm([0.01,1,100]))
ram_state = RobustAdaptiveMetropolis(x0; S_init = S0)
default_init = adaptive_rwm(x0, log_p, 1000)
good_init = adaptive_rwm(x0, log_p, 1000; algorithm = [ram_state])

Thanks a lot!


editoria11y v1 plugin is no longer working; remove since updated wagtail includes accessibility checking

Here's John Jameson's write-up about editoria11y v2
https://editoria11y.princeton.edu/2023/03/towards-v2/
And here is the documentation for setup https://itmaybejj.github.io/editoria11y/
It looks like the path and configuration have changed; probably not too difficult to update.

update: newer versions of wagtail include accessibility checking built on axe tools, so we can just remove editoria11y

editora11y v1 removed in #414


Fixing IllegalArgumentException in ForbiddenMethodCall rule for Inter…

…section type parameters
PR fixing issue reported in #3546.

@schalkms Do you maybe know why one of the check failed?
I have looked at it but unfortunately I don't understand how may change may have caused this failure.


Check log length is not zero

@ptnapoleon:
Passed cassci build.
http://cassci.datastax.com/view/Dev/view/smccarthy788/job/smccarthy788-cassandra-3.0-dtest/12/

+1


Promote CronJobTimeZone to stable

Adds documentation for:

https://github.com/kubernetes/enhancements/issues/3140
https://github.com/kubernetes/kubernetes/pull/115904

/assign @sftim

Looks ready for tech review.

/assign @atiratree
for tech review from sig-apps

/approve

/approve

/lgtm


'utf-8' codec can't decode byte 0x80 in position 7: invalid start byte

I installed all the requeriments but when i try to run te comand python main.py i get this error:
` File "C:\Users\Braian\bot\League-Bot\main.py", line 292, in
fail_safe()
File "C:\Users\Braian\bot\League-Bot\main.py", line 250, in fail_safe
open_client()
File "C:\Users\Braian\bot\League-Bot\main.py", line 90, in open_client
if process_exists(client_process):
File "C:\Users\Braian\bot\League-Bot\main.py", line 60, in process_exists
output = subprocess.check_output(call).decode()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 7: invalid start byte`
Can you help?

I solve this just adding a utf-8 ignore.
in the method process_exist:
replace
output = subprocess.check_output(call).decode()
for
output = subprocess.check_output(call).decode('utf-8', 'ignore')


Segmentation fault (core dumped)

Dear all,
thank you for the great work.
I am using IterativeSolvers.jl in some recent work. In particular, I called it from the QuantumOptics.jl toolbox, the function https://docs.qojulia.org/api/#QuantumOptics.steadystate.iterative which is a wrapper around a method from here.
This works fine for a system up to a certain size (takes about 10 min to converge), but when increasing the size a little more I get the segfault core dumped and Julia exits. Any idea how this comes?
I am using Julia 1.6.3 on an Ubuntu. From watching system monitor, it doesn't look like I'm running out of RAM
EDIT: in Julia 1.8 it runs fine-at least for this system size.  Possibly trouble occurs again at larger sizes

This would need a clear reproducer - and perhaps needs to be filed in QuantumOptics.


How to prevent "Ctrl + V" from adding new tags

Hello.
Thank you guys for this awesome lib.
I integrated it and things went well :+1:
Then I realize it would be more convenient if users can paste from a clipboard, edit a bit then submit the tag. By now, when users  "Ctrl V", the tag will be added automatically.
Is there any way I could prevent that?
Thank you and have a nice day

You are talking about something like https://github.com/prakhar1989/react-tags/pull/455 ?

Thank you for looking up the PR @ad1992 ,

You are talking about something like #455 ?

It seems to be. But I'm not familiar enough to know if it would prevent CtrlV from auto submitting or not.
Thank you and have a wonderful day :)

I went through the PR but couldn't determine if this is what would help me.
@ad1992 : can you provide your input or guide me in the right direction ?

@jontycool what are you looking for, could you elaborate?

Currently when users do "Ctrl + V" and paste something in the input field, it creates a tag automatically. Is there any way to stop it so that the user can edit the pasted content and then click Enter or "," or any other delimiter key to create the tag.

@ad1992 : I know you might be busy, but any help on this issue would be very helpful.

@Nogias9x : Any chance, you have managed to bypass this ?

@Nogias9x : Hi, I dug deeper into the code a bit and I found this prop called "allowAdditionFromPaste". All you have to do is add this prop and set it to false. This will solve this particular issue.
@ad1992 : I think you can close this issue now.

@jontycool glad to know that allowAdditionFromPaste will resolve the requirement but we should definitely document it so its not a hidden prop anymore. Will close once its documented. Thanks a lot for pointing this out!

:tada: This issue has been resolved in version 6.7.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

Awesome @ad1992 !
Thank you so much for the work <3


Update readmeFile.

Coverage remained the same at 100.0% when pulling da2ec526da366259765ac67824837887882091f4 on reorganizeReadmeFile into 1fa23d4af5466d8bf501892d052c7375ff0e023d on master.