pymodule: remove call_function etc.

So on master we renamed PyModule::call to PyModule::call_function etc. in #1467
But this is causing confusion to a user unfamiilar with the project in #1476 .
So I suggest we just remove PyModule::call_function and instead point users to use .getattr(...)?.call(). There's no optimization in PyModule::call_function etc., so I think there's no reason we need to offer these APIs.
I also deprecated PyModule::get because it's just a dumb wrapper around PyAny::getattr, by the same logic.

cc @birkenfeld

Whoops, should have been now "approve" yet.


https://github.com/redex-ai/django-scheduler/issues/11#issuecomment-1834520938

https://github.com/redex-ai/django-scheduler/issues/11#issuecomment-1834520938

https://github.com/redex-ai/django-scheduler/issues/11#issuecomment-1834520938


[Dashboard] Remove tw-components

Problem solved
Short description of the bug fixed or feature added

PR-Codex overview
This PR focuses on refactoring the usage of the Badge component throughout the codebase, transitioning from the tw-components library to a custom Badge implementation with updated styling.
Detailed summary

Removed Badge imports from tw-components in several files.
Replaced Badge component usage with a custom styled Badge.
Adjusted class names for styling consistency.
Cleaned up unnecessary properties in Badge components.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#5370  👈
#5369
#5368
#5367
main

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

Join @kien-ngo and the rest of your teammates on  Graphite


Backmerge release 3.53.0

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.08%) to 31.692%

Totals

Change from base Build<PHONE_NUMBER>:
0.08%

Covered Lines:
13031

Relevant Lines:
14791

💛  - Coveralls


Use in docker-compose.yml isn't showing and color in the output

Is there a way to ensure color in the output when used with Docker?

These lines are in my test/test_helper.rb:
require "minitest/reporters"
Minitest::Reporters.use! Minitest::Reporters::SpecReporter.new(color: true)

I just needed to add tty: true to my docker-compose.yml service definition.


Add bioinformatics kmers example

Changes included in this PR

Adds a bioinformatics example that reads "fasta" files and combines the data into a CSV file.
Testing strategy

Tested it manually. Will be tested as part of nightly example tests.
User facing changes

A new example.
Checklist

[N/A] Pipelines passed before requesting review. To run CI you must include [run CI] in your commit message.
[x] I am familiar with the Contributing Guide
[x] I have installed + ran pre-commit hooks.

Ran great for me, and was faster even with the smaller fasta files. Approving PR, and will check on publicising.


Delete before replace sns topic

After https://github.com/pulumi/pulumi-aws/pull/3235 creating an sns topic with the name of one which already exists will fail.
This means that replacing a topic fails now.
We need DeleteBeforeReplace to be the default in order for replacement to work by default.

After https://github.com/pulumi/pulumi-aws/pull/3235 creating an sns topic with the name of one which already exists will fail.

Perhaps we can revert 3235 while we sort this out?

Perhaps we can revert 3235 while we sort this out (and release a patch if we released that change)?

Thanks for the suggestion, I've raised https://github.com/pulumi/pulumi-aws/pull/3272 until we sort out the issue here.
@iwahbe suggested re-merging it as a warning instead of an error since the current behaviour causes the topic to disappear silently at the end of the replacement. So still not a great user experience.


Crash with Glide No super method apply(Lcom/bumptech/glide/request/RequestOptions;)

I don't know where is the wrong. I think it was in glide dependency. But the logical said that crash caused at com.github.irshulx.GlideOptions.apply(GlideOptions.java:605). When I downgrade the version to 2.3.2 (used Picasso), it's going normal again. But some feature can't be use and also cause crash.
this is my code that call Glide dependency :
Glide.with(imageView.getContext()).load(image).apply(bitmapTransform(new RoundedCorners(4))).into(imageView);
this is my logcat :
E/CustomActivityOnCrash: App has crashed, executing CustomActivityOnCrash's UncaughtExceptionHandler
    java.lang.NoSuchMethodError: No super method apply(Lcom/bumptech/glide/request/RequestOptions;)Lcom/bumptech/glide/request/RequestOptions; in class Lcom/bumptech/glide/request/RequestOptions; or its super classes (declaration of 'com.bumptech.glide.request.RequestOptions' appears in /data/app/id.inovativo.bmi_sukses-1/split_lib_dependencies_apk.apk)
        at com.github.irshulx.GlideOptions.apply(GlideOptions.java:605)
        at com.github.irshulx.GlideRequests.setRequestOptions(GlideRequests.java:170)
        at com.bumptech.glide.RequestManager.<init>(RequestManager.java:136)
        at com.bumptech.glide.RequestManager.<init>(RequestManager.java:94)
        at com.github.irshulx.GlideRequests.<init>(GlideRequests.java:38)
        at com.bumptech.glide.GeneratedRequestManagerFactory.build(GeneratedRequestManagerFactory.java:19)
        at com.bumptech.glide.manager.RequestManagerRetriever.supportFragmentGet(RequestManagerRetriever.java:441)
        at com.bumptech.glide.manager.RequestManagerRetriever.get(RequestManagerRetriever.java:134)
        at com.bumptech.glide.manager.RequestManagerRetriever.get(RequestManagerRetriever.java:116)
        at com.bumptech.glide.Glide.with(Glide.java:716)
        at id.inovativo.bmi_sukses.viewmodel.FontBinding.setImg(FontBinding.java:30)
        at id.inovativo.bmi_sukses.databinding.LayoutSliderBindingImpl.executeBindings(LayoutSliderBindingImpl.java:127)
        at android.databinding.ViewDataBinding.executeBindingsInternal(ViewDataBinding.java:471)
        at android.databinding.ViewDataBinding.executePendingBindings(ViewDataBinding.java:443)
        at android.databinding.ViewDataBinding$7.run(ViewDataBinding.java:195)
        at android.databinding.ViewDataBinding$8.doFrame(ViewDataBinding.java:289)
        at android.view.Choreographer$CallbackRecord.run(Choreographer.java:792)
        at android.view.Choreographer.doCallbacks(Choreographer.java:607)
        at android.view.Choreographer.doFrame(Choreographer.java:574)
        at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:780)
        at android.os.Handler.handleCallback(Handler.java:739)
        at android.os.Handler.dispatchMessage(Handler.java:95)
        at android.os.Looper.loop(Looper.java:135)
        at android.app.ActivityThread.main(ActivityThread.java:5304)
        at java.lang.reflect.Method.invoke(Native Method)
        at java.lang.reflect.Method.invoke(Method.java:372)
        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:912)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:707)

I've updated glide to 4.9.0. Please try again. #72

I have this error too on 4.9.0

I'm also getting this error:
Glide version: com.github.bumptech.glide:glide:4.9.0
This library version: com.github.irshulx:laser-native-editor:3.0.3

I'm also getting this error:
Glide version: com.github.bumptech.glide:glide:4.9.0
This library version: com.github.irshulx:laser-native-editor:3.0.3

change com.github.irshulx:laser-native-editor:3.0.3 to com.github.irshulx:laser-native-editor:3.0.4
And use force fix com.github.bumptech.glide:glide:4.9.0 in you gradle file

I'm also getting this error:
Glide version: com.github.bumptech.glide:glide:4.9.0
This library version: com.github.irshulx:laser-native-editor:3.0.3

worked for me


Quote launch paths when necessary

Fixes https://github.com/OmniSharp/omnisharp-vscode/issues/5099.

Starting OmniSharp server at 21.03.2022, 13:00:03
    Target: c:\code\<some_path>\build\Build.sln

OmniSharp server started with .NET 6.0.300-preview.22154.4
.
    Path: c:\Users\<username>\.vscode\extensions\ms-dotnettools.csharp-1.24.2\.omnisharp\1.38.1-net6.0\OmniSharp.dll
    PID: 7684

Could not execute because the specified command or file was not found.
Possible reasons for this include:
  * You misspelled a built-in dotnet command.
  * You intended to execute a .NET program, but dotnet-"c:\Users\verysimplenick\.vscode\extensions\ms-dotnettools.csharp-1.24.2\.omnisharp\1.38.1-net6.0\OmniSharp.dll" does not exist.
  * You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.

ms-dotnettools.csharp-1.24.2\.omnisharp\1.38.1-net6.0\OmniSharp.dll exists.
"omnisharp.loggingLevel": "trace", doesn't give more information, but looks like it could be related
to this PR.
I will try to rollback to 1.24.1

yes, especially this looks very suspicious
dotnet-"c:\Users\<username>\.vscode\extensions\ms-dotnettools.csharp-1.24.2\.omnisharp\1.38.1-net6.0\OmniSharp.dll"

Hmm. I'm not sure where that - is coming from: this PR certainly doesn't add it in. I'm also not able to reproduce this on windows myself: 1.24.2-beta1 starts just fine for me. Can you share your omnisharp.path, and/or would you be willing to debug your installation a bit?

omnisharp.path isn't overridden (default value).
"omnisharp.useModernNet": true
dotnet --info:
.NET SDK (reflecting any global.json):
 Version:   6.0.300-preview.22154.4
 Commit:    1eb22793b6

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22000
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.300-preview.22154.4\

Host (useful for support):
  Version: 6.0.3
  Commit:  c24d9a9c91

.NET SDKs installed:
  6.0.300-preview.22154.4 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

would you be willing to debug your installation a bit?

I didn't try to debug the omnisharp's vscode extension before. I can send any debug info that you need and maybe I will try to debug this by myself at the weekend.

yes, especially this looks very suspicious
dotnet-"c:\Users\<username>\.vscode\extensions\ms-dotnettools.csharp-1.24.2\.omnisharp\1.38.1-net6.0\OmniSharp.dll"

It is like System.CommandLine is parsing the omnisharp assembly path as a command name instead of a file argument. dotnet-* is the fallback for the dotnet CLI uses to invoke global tools as if they were subcommands of the CLI.
I cannot reproduce this behavior when trying to invoke with the same launch arguments from a command line.

Even better. Passing shell: true in the spawn options causes the path to be parsed correctly. Opened https://github.com/OmniSharp/omnisharp-vscode/pull/5125

Also, validated launching .NET Framework O# on Windows and system install of Mono work with the added quotes.

Confirmed, beta 3 with https://github.com/OmniSharp/omnisharp-vscode/pull/5125 works fine.


Use SB/SF milestone libs for M1 release

Made the following TEMPORARY changes to appease downgrading to SB/SF milestones:

Removed AsynTaskExecutor.submitCompletable (only in SF snaphot)
Revert b188436ab5db56faf713d39593a67e2999864c2e (auto-generated auto-config imports file only in SB snapshot)

Added SpringBootTest sanity test to catch when auto-config is not in place.

@alpreu @sobychacko

LGTM. Merging.


Supporting Multiple Servers

See #8.

:+1:

@kentaroi could you merge this pull request please ? That would be great :-)


Amplify.Auth.signInWithWebUI immediately loads redirect URL

Describe the bug
I am using the Amplify SDK with a manually configured amplifyconfiguration.json file, as our AWS resources are being provisioned via Terraform by a separate team. Calling Amplify.Auth.signInWithWebUI doesn't show the login screen, but rather immediately loads our sign-in redirect page.  My configuration is as follows:
{
    "auth": {
        "plugins": {
            "awsCognitoAuthPlugin": {
                "CognitoUserPool": {
                    "Default": {
                        "PoolId": "***",
                        "AppClientId": "***",
                        "Region": "***"
                    }
                },
                "Auth": {
                    "Default": {
                        "OAuth": {
                            "WebDomain": "***",
                            "AppClientId": "***",
                            "SignInRedirectURI": "https://***/",
                            "SignOutRedirectURI": "https://***/",
                            "Scopes": ["email", "openid"]
                        },
                        "authenticationFlowType": "USER_SRP_AUTH"
                    }
                }
            }
        }
    }
}

Our user pool is configured with Apple/Google social sign-in as well as SAML-federated IdPs. I've been able to get the entire authentication flow working -- including the callback to the app via Universal Link, by just manually constructing the login URL and presenting it in a SafariViewController --  so I don't think it's an issue with the way our user pool is configured. As this is proving to be quite frustrating, I may choose to just continue with this approach instead of signInWithWebUI, but would I still be able to leverage Amplify to handle session management/token refresh?
On a related note: I'm finding the documentation extremely lacking in general for using Amplify with pre-existing AWS resources. I understand the primary use case is to allow mobile app developers to easily spin up backend resources without needing any ops experience, but we don't fall under this category. Is Amplify still the recommended approach given our circumstances, or should we revert back to using the AWSMobile SDK (which, as I understand, is being deprecated in favour of Amplify)?
To Reproduce
Steps to reproduce the behavior:

Execute the following:

Amplify.Auth.signInWithWebUI(presentationAnchor: self.view.window!)
            .resultPublisher
            .sink {
                if case let .failure(authError) = $0 {
                    print("Sign in failed \(authError)")
                }
            }
            receiveValue: { _ in
                print("Sign in succeeded")
            }
            .store(in: &bindings)

Web view is presented modally with the sign-in redirect page loaded. The login page is never displayed and the callback does not occur.

Expected behavior
The login web UI is displayed:

Screenshots
If applicable, add screenshots to help explain your problem.
Environment(please complete the following information):

Amplify Framework Version: 1.5.2
Dependency Manager: Cocoapods
Swift Version : 5.0

Device Information (please complete the following information):

Device: iPhone 11 Simulator
iOS Version: 14.3
Specific to simulators: No

Additional context
Add any other context about the problem here.

Hi @blau2,
Using Amplify with existing resources is supported. There's no specific requirement that you use the CLI to provision your backend resources or generate your configuration files, as long as the end configuration meets the requirements of what would have been generated using the CLI. The complication is that the CLI sets up a lot of resources and configurations, and encodes recommended best practices into those setups. Maintaining accurate documentation on each of those in their various permutations would be challenging, as I'm sure you can imagine.
My best advice would be to use the Amplify CLI to set up a set of test resources that mimics your setup, and then to compare the resources to ensure that the ones set up in your other workflow includes all the relevant info. In particular, I'd recommend paying special attention to the user pool configuration, Hosted UI setup, associated IAM policies, and the callback URL generated by Amplify, to make sure that your configs are wired up correctly.
I wouldn't recommend reverting to the AWS Mobile SDK since the HostedUI use case you describe is supported in Amplify.

Hi @palpatim, thanks for the quick response. I've taken your advice and used the Amplify CLI to generate a config file with test resources and have adapted it to our project.

Hi @palpatim, thanks for the quick response. I've taken your advice and used the Amplify CLI to generate a config file with test resources and have adapted it to our project.


Remove default list padding from nav lists?

I guess the $default-nav-list-style is none because you assume navigation lists should not be styled as lists. Do we not have to remove the default (left-)padding too then?
nav ol,
nav ul {
	list-style: $default-nav-list-style;
    padding-left: 0;
}

Is this already covered?

Doh! Obviously.
I guess I'm not really used to that 'nuclear reset' anymore ;)
(It might be a bit too nuclear for my taste b.t.w. see also https://twitter.com/kilianvalkhof/status/578610583114756097)

That is a tangent from this issue, but you are welcome to open a new issue for this if you like. I don’t agree that the user agent pre-aligned vertical rhythm is necessary or desired out of the box. The default spacing rhythm is a kind of theme, and many css libraries ditch the defaults in order to assign their own spacing rhythms. For example, both Bootstrap and Foundation do this.


Read unicode data in a compatible way

Fixes #14.

Thanks for this PR! I will accept it, but currently have other work in the queue. Please be patient for some more days. I will follow up on pytypes soon.