fix: Adjusting margin on copy button for codebox

Summary of Changes
Adjusts margins on copy button of codebox
Include a summary of changes then remove this line
Tests
Manually
What tests did you add or modify and why? If no tests were added or modified, explain why. Remove this line
CheckList
Make sure you have checked all steps below to ensure a timely review.

[ ] PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"

In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

[ ] PR includes a summary of changes, including screenshots of any UI changes.
[ ] PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
[ ] In case of new functionality, my PR adds documentation that describes how to use it.

All the public python functions and the classes in the PR contain docstrings that explain what it does

[ ] PR passes all tests documented in the developer guide

thanks, I assume this is the bug I talk to @allisonsuarez :) ? thanks for the quick fix

It is! Thanks for reporting!


Add the ability to use a git tag instead of commit

Currently we can only specify a commit.
But for releases of projects it'd be better if we could specify a tag.

Published on 0.7.0 with a breaking change !!! It's now git_ref option instead of template_commit option name and is able to understand either a full commit hash or a tag name.


Critical in v5.3.2 Cannot find module @noble/secp256k1

Error: Cannot find module '@noble/secp256k1'
Require stack:

/app/node_modules/tronweb/dist/TronWeb.node.js

ASAP @unicornonea, release v5.3.2 isn't working at all

Please install<EMAIL_ADDRESS>manually.

@start940315 hi i know how to install plugin but its should work without install additional plugins when i make a clear install pkg must work =)

Please try our beta version, it doesn't need to install plugin.

I'm encountering an issue retrieving the USDT (TRC20 token) balance. I've followed the steps outlined in the TronWeb documentation for calling contracts (https://developers.tron.network/docs/smart-contract-interaction), but I'm getting an error message stating "Property 'balanceOf' does not exist on type 'Contract'." This functionality previously worked with TronWeb version prior to 6.0, but no longer functions with the current version.

Was closed without solve problem @unicornonea

I'm encountering an issue retrieving the USDT (TRC20 token) balance. I've followed the steps outlined in the TronWeb documentation for calling contracts (https://developers.tron.network/docs/smart-contract-interaction), but I'm getting an error message stating "Property 'balanceOf' does not exist on type 'Contract'." This functionality previously worked with TronWeb version prior to 6.0, but no longer functions with the current version.

this is a reproducible issue, same here.

I'm encountering an issue retrieving the USDT (TRC20 token) balance. I've followed the steps outlined in the TronWeb documentation for calling contracts (https://developers.tron.network/docs/smart-contract-interaction), but I'm getting an error message stating "Property 'balanceOf' does not exist on type 'Contract'." This functionality previously worked with TronWeb version prior to 6.0, but no longer functions with the current version.

this is a reproducible issue, same here.

Hi there. Got the same issue. Are there any solutions for now?
Here is my related to the issue dependecies for react.js project:
"dependencies": {
"@noble/secp256k1": "^2.1.0",
"@walletconnect/encoding": "^1.0.1",
"@walletconnect/modal": "^2.6.2",
"@walletconnect/sign-client": "2.14.0",
"@walletconnect/types": "2.14.0",
"@walletconnect/universal-provider": "2.14.0",
"@walletconnect/utils": "2.14.0",
"@walletconnect/web3-provider": "^1.8.0",
"bs58": "^5.0.0",
"ethers": "^6.13.2",
"prop-types": "^15.8.1",
"react": "^18.2.0",
"react-dom": "^18.2.0",
"tronweb": "^5.3.2",
"tweetnacl": "^1.0.3",
},
"devDependencies": {
"@daochild/tronweb-typescript": "^1.1.2",
"@types/react": "^18.2.37",
"@types/react-dom": "^18.2.15",
"@vitejs/plugin-react": "^4.2.0",
"env-cmd": "^10.1.0",
"eslint": "^8.53.0",
"eslint-plugin-react": "^7.33.2",
"eslint-plugin-react-hooks": "^4.6.0",
"eslint-plugin-react-refresh": "^0.4.4",
"prettier": "^3.1.0",
"vite": "^5.0.0"
}

@boxexchanger  @LucianoAngel  i have found the reason of this issue for me. Hope, it would be helpful for you. I use "tronweb": "^5.3.2" in my project.
First, you need to correctly add types for tronweb according to the docs: https://github.com/daochild/tronweb-typescript
Second, install "vite-plugin-node-polyfills": "^0.22.0" to devDependencies and add it to configs:
`import { nodePolyfills } from 'vite-plugin-node-polyfills';
// https://vitejs.dev/config/
export default defineConfig({
plugins: [react(), nodePolyfills()],
base: '/',
resolve: {
alias: {
// eslint-disable-next-line no-undef
'@': path.resolve(__dirname, './src'),
},
},
assetsInclude: ['/*.xlsx', '/*.csv'],
});`
This way you avoid the warning "Module "crypto" has been externalized for browser compatibility. Cannot access "crypto.createHash" in client code" and get correctly working balanceOf method.


fix: More types supports cast to LargeList

More types(e.g. LargeUtf8) should also supports cast to LargeList. The only special branch is LargeBinary to LargeList.

Seems that CI is unstable, but I assume it's not related to this change.

Great!


Recents Thumbnails

System isn't saving any thumbnail if you press home and then go to recents menu.
Initial workaround : set old miui Recents menu.

maybe this commit will help you.
https://git.oschina.net/guaiyihu/patchrom_miui8_xiaomi_leo/commit/1a247088786a799887c1f56f98d132264564a220

Thanks, got it fixed.
@GuaiYiHu I will not cherry pick your commit cause cant fetch from oschina, but will give you the credits when commiting.

Fixed with commit #20364b2


Tag some features as opt-in experimental

Description
This is an idea I've considered for a while but never tried. The problem is that many features need extensive testing to be considered complete yet need to exist in the package for a long time in order for that testing to be feasible. Throwing warnings around is not ideal as they can easily be ignored by users. Me personally and repeatedly communicating the nature of these features scales poorly and guarantees that some people aren't informed what is and is not currently trustworthy. Hiding things behind "private" import paths implies a lack of API stability but does not communicate whether or not something is trustworthy and leaves us more or less in the same position as before.
With this changeset, features tagged with an @experimental decorator require an environment variable INTERCHANGE_EXPERIMENTAL=1 to be set. This requires users to explicitly opt-in with a non-negligible hurdle if using one of these features. Power users and heavy testers can set this in their shell profile without their work being interrupted.
Here's what it looks like to use:
In [1]: from openff.interchange._experimental import experimental
   ...:
   ...:
   ...: @experimental
   ...: def f():
   ...:     pass
   ...:
   ...:
   ...: f()

---------------------------------------------------------------------------
ExperimentalFeatureException              Traceback (most recent call last)
Cell In[1], line 9
      4 @experimental
      5 def f():
      6     pass
----> 9 f()

File ~/software/openff-interchange/openff/interchange/_experimental.py:15, in experimental.<locals>.wrapper(*args, **kwargs)
     13 def wrapper(*args, **kwargs):
     14     if os.environ.get("INTERCHANGE_EXPERIMENTAL", "0") != "1":
---> 15         raise ExperimentalFeatureException(
     16             f"\n\tFunction or method {func.__name__} is experimental. This feature is not "
     17             "complete, not yet reliable, and/or needs more testing to be considered suitable "
     18             "for production.\n"
     19             "\tTo use this feature on a provisional basis, set the environment variable "
     20             "INTERCHANGE_EXPERIMENTAL=1.",
     21         )
     23     return func(*args, **kwargs)

ExperimentalFeatureException:
	Function or method f is experimental. This feature is not complete, not yet reliable, and/or needs more testing to be considered suitable for production.
	To use this feature on a provisional basis, set the environment variable INTERCHANGE_EXPERIMENTAL=1.

Thoughts @j-wags @Yoshanuikabundi?
Checklist

[x] Add tests
[x] Lint
[ ] Update docstrings

One risk is that users get used to setting the environment variable for everything

I'm worried about this as well, I thought briefly about having different tiers of danger but I couldn't think of a good way to implement it. Expanding this to multiple different variables seems like a bad idea. I don't love the idea of continuously emitting more warnings/tacking on headers to docstrings and pages but that's the best I can come up with.

Looks good, albeit this is the only case as the others are each hidden behind an underscore:


Refactor local logging

Move the local_rank == 0 check into the logger initialization to simplify code
Adds an option to log all ranks for an experiment.

closes #584

For Log All Ranks I would personally suggest to make this a global setting instead of an experiment setting.

If was going for it initially, but would need updating and passing of an environment variable to train.py. I would suggest that we add it as a global setting for the default value. I can do it in another PR as it perfectly builds upon this one.

Theoretically we could also add the same functionality for cfg.logging._logger.log to also get rid of the if switches there.

Yes, though, most only support single rank logging there, so, I'd suggest we hardcode this in the external logger initialization and don't make it configuarable.


codegen output 8e9394c88ed14011a6a3ba1f32637a8d

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

37 of 93 (39.78%)  changed or added relevant lines in 55 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+1.6%) to 73.994%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

box_sdk_gen/managers/chunked_uploads.py
2
3
66.67%

box_sdk_gen/managers/classifications.py
0
1
0.0%

box_sdk_gen/managers/collaboration_allowlist_entries.py
0
1
0.0%

box_sdk_gen/managers/collaboration_allowlist_exempt_targets.py
0
1
0.0%

box_sdk_gen/managers/file_classifications.py
0
1
0.0%

box_sdk_gen/managers/file_versions.py
1
2
50.0%

box_sdk_gen/managers/file_watermarks.py
0
1
0.0%

box_sdk_gen/managers/folder_classifications.py
0
1
0.0%

box_sdk_gen/managers/folder_watermarks.py
0
1
0.0%

box_sdk_gen/managers/invites.py
0
1
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
1.6%

Covered Lines:
6419

Relevant Lines:
8675

💛  - Coveralls


Fix: Parsing accepts merge commits

Merge commits do not follow the type(scope): Message schema but we can expect merge commits to occur more or less all the time. If merges are not squashed, then leaving the merge commit with the default message is often a good idea as that would serve as a mark that something was merged here. We should therefore identify merge commits and accept them as "valid".

This also applies for Revert commits.


Add new transforms  RFC5646, and Display Name

Is your feature request related to a problem? Please describe.
New transforms as been added (cf. https://developer.sailpoint.com/discuss/t/new-capability-availability-of-new-identity-attributes-default-identity-profile-mapping-and-transforms/60607)
Describe the solution you'd like
Add these transforms to the snippets and transform type.
Additional context
https://developer.sailpoint.com/docs/extensibility/transforms/operations/rfc-5646
https://developer.sailpoint.com/docs/extensibility/transforms/operations/display-name

Implemented. Planned for next release


code for i2t inference

great work! I am wondering can you provide code for i2t inference? There is only code for t2i inference now(scripts/run_t2i.sh)

great work! I am wondering can you provide code for i2t inference? There is only code for t2i inference now(scripts/run_t2i.sh)

The i2t of TokenFlow is built on LLaVA, so you can directly use lmms-eval for inference and evaluation.
Specifically,

First install the i2t environment by following the installation guide. This will install a "llava" pip package.
Then refer to the LLaVA testing instructions in the lmms-eval repository.

Things might need to be modified:

In case lmm-eval can't find the llava package, add a system path in lmms_eval/models/llava.py

from pathlib import Path
sys.path.insert(0, str(Path("/path/to/your/TokenFlow/i2t").resolve()))

Thank you for your reply. Yes, I have used lmms-eval before. I am wondering if there is code available to run inference on a single image of my own?

Thank you for your reply. Yes, I have used lmms-eval before. I am wondering if there is code available to run inference on a single image of my own?

This repo does not support this feature currently. PR is welcomed to enable this.


Added a feature which disables the clear button when nothing is selected.

Fixes Issue #5500
closes #5500

Changes proposed
Currently Clear/Reset button in Map section is active even when no filter is selected, hence a fix to this issue is proposed through my PR which disables the button if no filters are selected.

Before:

After:

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[ ] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

@eddiejaoude the changes you made in the PR has removed the disabled effect, now both when the button is disabled and when not looks similar.
Check it out:

It was supposed to look like this:

Yes, locally it worked for me, see the screenshot, but I didn't get a chance to see why when deployed it didn't work correctly

If you have time, feel free to take a look and submit a PR fix, otherwise I can take a look tomorrow

Yes, locally it worked for me, see the screenshot, but I didn't get a chance to see why when deployed it didn't work correctly

If you have time, feel free to take a look and submit a PR fix, otherwise I can take a look tomorrow

I'll take care of it.

Great, thank you 👍


Sky map

Like the radar compass, but for the sky (both night and day).
The can be the precursor to #1809 as it is much easier to implement - and it may be able to be kept in place (with a view in 3D button).
See #1809 for details on what stars/planets to show.
Add a seekbar to change the time of day (from sunset the day before to sunrise the next day), and a calendar to change the date
If the 3D mode becomes too difficult to implement at first, maybe use a similar approach as the solar panel aligner to help find the star in the night sky.
Show path of sun/moon.

For the watchers, some recent commits are interesting; https://github.com/kylecorry31/Trail-Sense/commit/c79b821c2d74d53ab4936b1b19a1e349d62468f1 for instance.

For the watchers, some recent commits are interesting; c79b821 for instance.

Yup, I started implementing the star catelog for fun :)
In the next release, at night the AR tool will show the top 50 stars + 57 navigation stars (there's a lot of overlap) and a handful of stars in major constellations used for navigation (many of these additions happened behind the scenes in https://github.com/kylecorry31/sol).
I've also been experimenting with #1919, and want to make that happen soon (still verifying the accuracy in the best case scenarios to see if it will even be feasible though). If I can't get that to an accuracy of meters, I'll likely just put it in another app.


[HOLD for payment 2024-07-17] [$250] Prevent requesting money from domain emails

Domain emails are in format +@<domain> like<EMAIL_ADDRESS>Problem
We allow users to request money from domains in newDot. Update the code so we don't allow this action.

Steps to reproduce:

From the global create button, select Split expense.
In the search field enter<EMAIL_ADDRESS>and confirm you are able to select that email as an option.

Solution
Update the code to prevent users from requesting money from domain emails.
Solution
Update the code to prevent users from requesting money from domain emails.
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~014e28879d82637e16
Upwork Job ID:<PHONE_NUMBER>147678962
Last Price Increase: 2024-06-26
Automatic offers:

rayane-djouah | Reviewer | 102895687
nkdengineer | Contributor | 102895688

Issue OwnerCurrent Issue Owner: @isabelastisser

Proposal
Please re-state the problem that we are trying to solve in this issue.
We'd like to prevent requesting money from domain emails
What is the root cause of that problem?
There's no logic to exclude domain emails when getOptions
What changes do you think we should make in order to solve the problem?

Add a param includeDomainEmail to getOptions https://github.com/Expensify/App/blob/57e5d0e7197a9c21e6f221389bed87870c90ef0a/src/libs/OptionsListUtils.ts#L1769, default to true
In https://github.com/Expensify/App/blob/57e5d0e7197a9c21e6f221389bed87870c90ef0a/src/libs/OptionsListUtils.ts#L1915
add
if (Str.isDomainEmail(email) && !includeDomainEmail) {
    return;
}

In the money request participants page, pass includeDomainEmail as false
What alternative solutions did you explore? (Optional)

So, I think all flows should be considered.

Yeah, we want to exclude them from all the flows as as they are not real users.

Whatever we do here, we will ALSO need to update the backend @techievivek

@rayane-djouah this PR is ready for preview

@iwiznia Yeah, backend already handles this exception correctly.

@nkdengineer @techievivek did the PR for this also take care of preventing starting a chat, a group, assigning a task, inviting to a workspace.. basically filtering the domain account out of the participant selector everywhere?

@trjExpensify Yeah, we have handled this for all cases; C+ confirmed this here: https://github.com/Expensify/App/issues/44429#issuecomment-2192166488.

@trjExpensify Yeah, we have handled this for all cases; C+ confirmed this here: #44429 (comment).

Great stuff!

Bump @rayane-djouah to complete the BZ list, thanks!

The payments were processed in Upwork.

I will be OOO tomorrow and next week, so I am reassigning this until I return on July 29. Thanks, @adelekennedy!
Status:

@rayane-djouah needs to complete the BZ list.

The regression test looks good to me; @adelekennedy, can we please get that added? Thanks.

Not overdue, completing the BZ list.

https://github.com/Expensify/Expensify/issues/414452

Thanks, @adelekennedy !


long node ids

64-bit node identifiers have been implemented. Keys in the database are serialized using a variable length encoding of the node identifiers. Identifiers less than or equal to Integer.MAX_INT are encoded in 4 bytes. Identifiers greater than Integer.MAX_INT are encoded in 8 bytes and the most significant bit of the first byte is set as a flag. Keys in a page use delta-encoding from the first key of the page to reduce disk space. Existing hydra jobs can be converted to the new representation. Serialization is managed by the enumerated type PageEncodeType. The interface KeyCoder is the best place to look at the new API. The class has been documented extensively.
This pull request requires https://github.com/addthis/codec/pull/11.

The latest version of this pull request 07ff901f23a18dd2f4b78fba97438f2d1f31a568 has passed the tests in the test cluster.


deps

output of npx standard-version --dry-run:
14.0.0 (2024-05-30)
⚠ BREAKING CHANGES

deps: Requires @angular/core^18.0.0.

Features

deps: angular 18 (dfe9383)

closes https://github.com/kuhnroyal/mat-datetimepicker/issues/555.

see https://github.com/kuhnroyal/mat-datetimepicker/releases/tag/v14.0.0.


Add test verifying that all links in docs are valid.

There should be a CI job that validates that all links in docs are valid to prevent situations like this https://github.com/redhat-developer/odo/pull/6616
/area testing
/priority low
/kind task

Hi @rm3l , @kadel . Can I work on this?

Hi @rm3l , @kadel . Can I work on this?

Sure.

/priority Medium
Bumping the priority of this issue, as broken links have been reported several times. And having this will help detect those links earlier.

/remove-lifecycle stale
/lifecycle frozen


japer-client vs j2f

Just stumbled over this here and was wondering why this exists? Is there a reason why this is separate from the jasper-client project?

This projected started because of distasteful way that contributors were
treated and expelled.
On Wed, Aug 23, 2017 at 11:11 AM Andreas Jantos<EMAIL_ADDRESS>wrote:

Just stumbled over this here and was wondering why this exists? Is there a
reason why this is separate from the jasper-client project?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jasper2fork/j2f/issues/40, or mute the thread
https://github.com/notifications/unsubscribe-auth/AEr2NtPqRiDgjQGYFDA5pCw-KzFhpS6Gks5sbF03gaJpZM4PAUX_
.

Thx for the answer @chrobione, that sucks to hear.

So ours split was based off the dev branch that have multiple language
support started.
If you have any questions please feel free to ask.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jasper2fork/j2f/issues/40#issuecomment-324504522, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEr2NtP6hKdOoOMVtTO5RhemZ3M3Up81ks5sbM3MgaJpZM4PAUX_
.

I was just wondering which repository is better to use at the end? Based on activity and enhancements. I saw that this one here included snowboy and saw a few other differences.

There is effort required for both repos, but I am partial to ours.
On Wed, Aug 23, 2017 at 7:16 PM Andreas Jantos<EMAIL_ADDRESS>wrote:

I was just wondering which repository is better to use at the end? Based
on activity and enhancements. I saw that this one here included snowboy and
saw a few other differences.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jasper2fork/j2f/issues/40#issuecomment-324505119, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEr2NpLMQ0x9lxkI4N-T6kXRBVEaKrZVks5sbM7jgaJpZM4PAUX_
.

I'm closing this issue ...


Azure-mgmt-monitor credential can't get token

Package Name:
azure-mgmt-monitor

Package Version:
1.0.1

Operating System:
Ubuntu 18.04

Python Version:
3.7

Describe the bug
I want to get VM CPU usage,
So I run MonitorClient(credentials, subscription_id).metrics.list()
But get error message:
AttributeError
'coroutine' object has no attribute 'token'

To Reproduce
Steps to reproduce the behavior:

Install package
azure-identity==1.4.0
azure-core==1.8.1
azure-mgmt-monitor==1.0.1

My credentials from ServicePrincipalCredentials

from azure.common.credentials import ServicePrincipalCredentials
credentials = ServicePrincipalCredentials(
           tenant = tenant_id,
           client_id= app_id,
           secret = password
        )

Get monitor_client

from azure.mgmt.monitor import MonitorClient
monitor_client = MonitorClient(credentials, subscription_id)

Call metrics.list()

metrics_data = monitor_client.metrics.list(
            resource_id,
            timespan="{}/{}".format('2020-09-25T00:00:00', '2020-09-25T02:00:00'),
            interval='PT1M',
            metricnames='Percentage CPU',
            aggregation='Average'
        )

Get Error

AttributeError
'ServicePrincipalCredentials' object has no attribute 'get_token'

Change credentials from ClientSecretCredential
Reference by azure-mgmt-monitor/tests/test_cli_mgmt_monitor.py

from azure.identity.aio import ClientSecretCredential
credentials = ClientSecretCredential(
            tenant = tenant_id,
           client_id= app_id,
           secret = password
        )

Run same code in step 2 and 3 again, Get error

AttributeError
'coroutine' object has no attribute 'token'

Expected behavior
Get VM CPU usage
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
All my code:
from azure.mgmt.monitor import MonitorClient
from azure.identity.aio import ClientSecretCredential
credentials = ClientSecretCredential(
            tenant = tenant_id,
           client_id= app_id,
           secret = password
        )

monitor_client = MonitorClient(credentials, subscription_id)
metrics_data = monitor_client.metrics.list(
            resource_id,
            timespan="{}/{}".format('2020-09-25T00:00:00', '2020-09-25T02:00:00'),
            interval='PT1M',
            metricnames='Percentage CPU',
            aggregation='Average'
        )

I found this doc
use from azure.identity import ClientSecretCredential and It work.


PWA shows sometimes a white screen

Library Affected:
"workbox-cacheable-response": "^6.4.1",
"workbox-core": "^6.4.1",
"workbox-expiration": "^6.4.1",
"workbox-google-analytics": "^6.4.1",
"workbox-precaching": "^6.4.1",
"workbox-routing": "^6.4.1",
"workbox-strategies": "^6.4.1",
"workbox-window": "^6.4.1",
"workbox-webpack-plugin": "^6.4.1",
Browser & Platform:
Chrome 96.0.4664.55 on MacOS 12.0.1 Monterey
Issue or Feature Request Description:
I am not exactly sure if i am right here and how to explain it best, but we are experiencing some strange PWA behaviour.
If we open certain url's sometimes our PWA renders a blank screen while the dom is fully loaded like normal, no errors everything looks fine. Devtools is showing the dom like there is no problem, we can even hover over elements (that are in this state invisible to us) and click them and the pwa does it's stuff reloads but it keeps rendering a white screen.
When we used workbox version 6.3.0 it didn't stopped rendering the white screen when we accessed these certain urls even after reopening the pwa.  As i today updated to workbox 6.4.1 this behaviour changed a bit so when the pwa renders a white screen and we now close it and open it again it is now working for some reason.
It's still rendering a white screen on the first load but after closing and reopening it is now working. 🤷♂
This Bug tends to only appear on MacOS desktop using Chrome.
Maybe thats more of an issue of pwa's with chromium but because it has changed a bit after updating workbox i thought to ask here first.
This Chromium issue is looking to be related
https://bugs.chromium.org/p/chromium/issues/detail?id=1239155&q=blank%20screen%20pwa&can=2
The problem is that there is no visible problem log or anything to us. It's not happening if we just use the browser.
I can sometimes see the same thing on twitter's pwa.
Screencast of the bug from Twitters PWA
Maybe someone can point me to the right direction.

My vanilla javascript pwa also shows a white screen sometimes, but on Chrome for Android (fully updated on a Samsung S8).
I can't reproduce the bug consistently, but it seems to appear after the app loses focus sometimes. Like when I turn off the screen of my phone for a while. I don't think the length of time is critical, and neither is losing connection a factor, but I may be wrong here as it happens every other day at random times and I have a hard time remembering what I did prior to the white screen.
Closing the pwa and restarting it removes the problem.
Everything is fine in Chrome dev-tools when I look with chrome://inspect/#devices except for the screen being white.
It registers swipes (which I logged for debugging and forgot to remove), but the buttons is inactive even though the full DOM appears to be there.
As I don't see this problem on the PC I don't think this is down to my code. Especially when no errors is thrown and Lighthouse gives a clean bill.
(The code for my pwa can be found at https://github.com/HappyDustbunny/FuzzyPlan and it is hosted at fuzzyplan.madshorn.dk )

My vanilla javascript pwa also shows a white screen sometimes, but on Chrome for Android (fully updated on a Samsung S8).
I can't reproduce the bug consistently, but it seems to appear after the app loses focus sometimes. Like when I turn off the screen of my phone for a while. I don't think the length of time is critical, and neither is losing connection a factor, but I may be wrong here as it happens every other day at random times and I have a hard time remembering what I did prior to the white screen.
Closing the pwa and restarting it removes the problem.
Everything is fine in Chrome dev-tools when I look with chrome://inspect/#devices except for the screen being white.
It registers swipes (which I logged for debugging and forgot to remove), but the buttons is inactive even though the full DOM appears to be there.
As I don't see this problem on the PC I don't think this is down to my code. Especially when no errors is thrown and Lighthouse gives a clean bill.
(The code for my pwa can be found at https://github.com/HappyDustbunny/FuzzyPlan and it is hosted at fuzzyplan.madshorn.dk )
Edit: I saw a suggestion somewhere else that the white screen could be a lingering theme_color or background_color, but after changing them both to different colors the white screen persist occasionally.

In my React PWA, i also see the blank screen.
Library
workbox 6.4.2
Platform
Chrome Version 97.0.4692.99 MacOS Monterey Version 12.1
When i open install PWA for first time it does show content. When i switch to dark theme, it show me a blank screen.
I'm not sure if someone is facing the same issue in dark mode or not.

Hi there,
Workbox is moving to a new engineering team within Google. As part of this move, we're declaring a partial bug bankruptcy to allow the new team to start fresh. We realize this isn't optimal, but realistically, this is the only way we see it working. For transparency, here're the criteria we applied:

For PRs, we closed everything that doesn't target the current v7 branch.
For Issues, we closed everything that was created before 2024.

Thanks, and we hope for your understanding!
The Workbox team


Feature/request refund payment

Summary by Sourcery
Add support for ad-hoc payment requests for violation tickets, including new GraphQL mutation, input and output types, and necessary updates to the domain API.
New Features:

Introduce a new GraphQL mutation violationTicketAdhocPaymentRequest to handle ad-hoc payment requests for violation tickets.

Enhancements:

Add new input type AdhocPaymentRequestInput and output types PaymentRequest and PaymentRequestResult to the GraphQL schema.
Update the ViolationTicketV1DomainApi interface and its implementation to support the new ad-hoc payment request functionality.

@sourcery-ai review


Close file on time

I don't remember correctly why I used a timer to close a file instead of closing a file on time.
The original code was placed in Warp deeply so I guess that I did not notice the on-time approach is possible.
Currently I believe that closing a file on time has no side-effect and is more elegant than the timer approach.
Unfortunately, this introduces a breaking change.
@edsko What do you think?

We don't use this part of the API, so I don't have any experience with it, but the PR looks reasonable enough to me! :)

Merged.
Thank you for your review!


ppc64le: The MTU size should not be set to 9000 unconditionally.

As per http://www-03.ibm.com/support/techdocs/atsmastr.nsf/002573f7000ac64286256c71006d2e0a/c32b40501f4f76c886257de0004fa1d4/$FILE/Network_Configuration_for_HANA_Workloads_on_IBM_Power_Servers_V7.1.pdf .
However, it would be nice to issue a warning in case it is not set to 9000.

As the default for sap_hana_preconfigure_ppcle_mtu9000_if is '' (empty), no changes will be performed anyway.
Problem solved :-)
Regarding the warning, this is out of scope. We might check and report the MTU size in the sap-hana-preconfigure-assert role.


Add stubs for appeal cost and cost determinator

:+1:, ignoring RCov on CircleCI for now as we're getting things up and running.