AuthError.Failure: Firebase.FirebaseException: An internal error has occurred. [ 7: ]

Please fill in the following fields:
Unity editor version: 2019.2.5f1
Firebase Unity SDK version: 6.5.0
Firebase plugins in use (Auth, Database, etc.): Auth
Additional SDKs you are using (Facebook, AdMob, etc.): None
Platform you are using the Unity editor on (Mac, Windows, or Linux): Currently Mac.
Platform you are targeting (iOS, Android, and/or desktop): Android
Please describe the issue here:
Trying to take build for our app in 32 bit as well as 64 bit architecture. Its showing an error like the one given below, when I try to do any firebase auth tasks such as signing in a user via email and password. In the earlier firebase sdk version we are getting the error in the link (https://github.com/firebase/quickstart-unity/issues/466) for the 64 bit architecture. where as the 32 bit architecture was working fine. After adding the latest firebase sdk 6.5.0 we are not getting it working correctly even for the 32 bit architecture.
(Please list the full steps to reproduce the issue. Include device logs, Unity logs, and stack traces if available.)
Download the quick start unity project. Add latest firebase sdk 6.5.0 and do a force resolve using the google play resolver and take the build by enabling both 32 bit and 64 bit architecture.  Yes

Hi @tonyjoseph456,
From what I can tell from the log you have provided, error code 7 looks to be kAuthErrorOperationNotAllowed which is most likely caused by not having the authentication method enabled in the Firebase console. Can you please check the configuration for authentication and ensure email/password  Sign-in method is enabled.
Console url should be something like:
https://firebase.corp.google.com/project/[Your Project Id]/authentication/providers

Hi @markchandler-google It was already enabled before testing this. And I had checked it now also. Email/Password signin is enabled for our project.

This issue is fixed now. It's working fine in our project after taking build today.

@tonyjoseph456  can you please explain what did you do to solve it?

@markchandler-google this issue is happening again. Reopening this issue again.

@tonyjoseph456 can you please explain what did you do to solve it?

We didnt do anything. It was fixed 6 days ago automatically somehow. And now today the same issue is happening again and again. So reopened this thread again.

yeah it still happening
On Tue, Sep 24, 2019 at 4:21 PM tonyjoseph456<EMAIL_ADDRESS>wrote:

@markchandler-google https://github.com/markchandler-google this issue
is happening again. Reopening this issue again.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/firebase/quickstart-unity/issues/474?email_source=notifications&email_token=ABWCXIVZRY4EW5COQLHIUYTQLIH4NA5CNFSM4IXBP7K2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7OJD7I#issuecomment-534548989,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABWCXIV3OMTFF2ECJCM6KV3QLIH4NANCNFSM4IXBP7KQ
.

--
Nicholaus N Legnard
Consultant Software Developer
+255 685 097 713

Hi all,
We haven't had any luck reproducing this on our end, and unfortunately that error log comes up when an underlying problem has occurred in the Android layer that we are not aware of, which is why it doesn't have any helpful information in it.
If you could, can you enable more verbose logging, via:
Firebase.FirebaseApp.LogLevel = Firebase.LogLevel.Debug;

Also, have you been seeing this in the quickstart?  If not, make sure to hold on to a reference to the FirebaseApp and FirebaseAuth objects, as the garbage collector could be cleaning those up.

Hi all,
To follow up with @a-maurice, we don't want to abandon this issue but we also need more information to properly debug it.
Can you let us know if you have any solid steps on fixing the issue (ex: keeping an instance to FirebaseAuth.DefaultInstance or FirebaseApp.DefaultInstance across scene boundaries) or additional logs with LogLevel set to Debug as listed above?
--Patrick

Hi
Not sure how much this will help the info regarding this issue but here is what we are experiencing.
Our app has been running fine for many months with all our users able to log in as expected with the
signInWithEmailAndPassword method on FirebaseAuth. However over the last 2 months we have been getting reports of An internal error has occurred. [ 7: ] from random users at random times.
Most of the time a Clear data on the app or device restart seems to remove the error and let the user
then log in. However today I experienced a user with a Tecno Mobile SA7S which simply refused to
get a success on login no matter if we uninstalled, reinstalled, device restart or which account we
tried.
I checked Google Play Services which seemed to be up to date based on the same version being
installed on my Sony Xperia XZ which allowed his user to login.
The stack trace of the Task exception in the on complete listener is below:
2019-10-25 13:40:33.284 11380-11380/com.company.app W/System.err: com.google.firebase.FirebaseException: An internal error has occurred. [ 7: ]
2019-10-25 13:40:33.290 11380-11380/com.company.app W/System.err:     at com.google.firebase.auth.api.internal.zzdx.zza(com.google.firebase:firebase-auth@@19.1.0:18)
2019-10-25 13:40:33.291 11380-11380/com.company.app W/System.err:     at com.google.firebase.auth.api.internal.zzfa.zza(com.google.firebase:firebase-auth@@19.1.0:21)
2019-10-25 13:40:33.291 11380-11380/com.company.app W/System.err:     at com.google.firebase.auth.api.internal.zzet.zza(com.google.firebase:firebase-auth@@19.1.0:34)
2019-10-25 13:40:33.291 11380-11380/com.company.app W/System.err:     at com.google.firebase.auth.api.internal.zzev.zza(com.google.firebase:firebase-auth@@19.1.0:74)
2019-10-25 13:40:33.292 11380-11380/com.company.app W/System.err:     at com.google.firebase.auth.api.internal.zzed.zza(com.google.firebase:firebase-auth@@19.1.0:18)
2019-10-25 13:40:33.292 11380-11380/com.company.app W/System.err:     at com.google.android.gms.internal.firebase_auth.zza.onTransact(com.google.firebase:firebase-auth@@19.1.0:13)
2019-10-25 13:40:33.292 11380-11380/com.company.app W/System.err:     at android.os.Binder.execTransact(Binder.java:723)
We are using Kotlin for the entire app and the standard Android Firebase libs.
I hope this adds some info to the issue.
Regards

Hi @PieterPicup,
Are you using Unity for your project, or doing everything in Kotlin/Android? If the latter, it will help to let that team know either in the Android GitHub repo or to file a support ticket. Since the Unity SDK is built on top of the Android SDK, then a fix there will bubble up here as well.
For @tonyjoseph456, definitely let us know if what @PieterPicup says feels similar to what you're experiencing.
--Patrick

I'm using latest Firebase Auth SDK for Android (19.1.0) for my project in Java and having same issues with pretty big amount of random users:
com.google.firebase.e: An internal error has occurred. [ 7: ]

Got more logs. I have 3 kinds of possible auth errors, not sure they all are related to this:

com.google.firebase.FirebaseException: An internal error has occurred. [ 7: ]
com.google.firebase.FirebaseApiNotAvailableException: Error resolution was canceled by the user, original error message: CANCELED: null
com.google.android.gms.common.api.ApiException: 8: The connection to Google Play services was lost

Hi @patm1987
I am not using unity at all for this project where we are having the issues.
The only reason I posted here was to give some more context on the issue if possible as this was the first and only reasonable open topic on this error. All other posts I have found WRT this issue have been new projects where the console was not setup correctly.
I will look into a Firebase support ticket.
Regards

Full stack stace for error 7:
Exception: com.google.firebase.FirebaseException: An internal error has occurred. [ 7: ]
at com.google.firebase.auth.api.internal.zzdx.zza(zzdx.java:18)
at com.google.firebase.auth.api.internal.zzfa.zza(zzfa.java:21)
at com.google.firebase.auth.api.internal.zzet.zza(zzet.java:34)
at com.google.firebase.auth.api.internal.zzev.zza(zzev.java:74)
at com.google.firebase.auth.api.internal.zzed.zza(zzed.java:18)
at com.google.android.gms.internal.firebase_auth.zza.onTransact(zza.java:13)
at android.os.Binder.execTransact(Binder.java:739)
It happens on all Android versions, GOOGLE_PLAY_SERVICES_STATUS_CODE is 0 which means connection successful and Play Services is up to date.

Hi. Had this error previously but let's say on a different platfrom. Was helped by the previous posts all the rest made me move around in circles for hours and started to look into my code for every possible reason and I found something and it worked. Could it be that there is somewhere in your project where you are saying auth.DefaultInstance.CurrentUser or auth.DefaultInstance.SignOut() instead of auth.CurrentUser or auth.SignOut()?

Hi. Had this error previously but let's say on a different platfrom. Was helped by the previous post having moved around in circles for hours without a clue and started to look into my code for every possible reason and I found something and it worked. Could it be that there is somewhere in your project where you are saying auth.DefaultInstance.CurrentUser or auth.DefaultInstance.SignOut() instead of auth.CurrentUser or auth.SignOut()?

I have the same issue(not in unity). The problem occurs commonly after app comes to foreground after a while. I am using firebase auth 19.0.0 and custom sign in method. The crash happens while executing Tasks.await method. This is how i call firebaseIdToken
FirebaseAuth.getInstance().currentUser?.let {user->
                val task = user.getIdToken(false)
                val tokenResult = Tasks.await(task)
                val idToken = tokenResult.token
}

and crash report from firebase
Caused by java.util.concurrent.ExecutionException: com.google.firebase.FirebaseException: An internal error has occurred. [ 7: ]
at com.google.android.gms.tasks.Tasks.zzb(:61)
at com.google.android.gms.tasks.Tasks.await(:23)
Caused by com.google.firebase.FirebaseException: An internal error has occurred. [ 7: ]
at com.google.firebase.auth.api.internal.zzdx.zza(com.google.firebase:firebase-auth@@19.0.0:18)
at com.google.firebase.auth.api.internal.zzfa.zza(com.google.firebase:firebase-auth@@19.0.0:21)
at com.google.firebase.auth.api.internal.zzet.zza(com.google.firebase:firebase-auth@@19.0.0:34)
at com.google.firebase.auth.api.internal.zzev.zza(com.google.firebase:firebase-auth@@19.0.0:74)
at com.google.firebase.auth.api.internal.zzed.zza(com.google.firebase:firebase-auth@@19.0.0:18)
at com.google.android.gms.internal.firebase_auth.zza.onTransact(com.google.firebase:firebase-auth@@19.0.0:13)
at android.os.Binder.execTransact(Binder.java:739)

Is there a conclusive solution to the raised problem with FirebaseException?

Folks who are replying on here with issues that aren't related to the Unity SDK, I recommend opening up issues with the Android SDK.
For the people who - as far as I can tell - are running into problems with the Unity SDK (which may be due to problems in the Android SDK), i.e @tonyjoseph456 and @nickyrabit did you manage to get things work?  @tonyjoseph456 the behavior you're describing definitely sounds like miconfiguration of the Firebase project, it's probably worth making sure that after updating google-services.json the Firebase plugin is running and regenerating Assets/Plugins/Android/Firebase/res/values/google-services.xml with the updated configuration.
@nickyrabit could you provide more information and validate that your issue occurs our auth sample application in this repo?

I'm also getting this error today.
Phone authentication is enabled in my Firebase console.
I also re updated my google-services.json file. but, it is also happening.
signInWithPhoneAuthCredential: onComplete: com.google.firebase.FirebaseException: An internal error has occurred. [ 7: ]
Is it an internal problem with Google Server?

Yes, it seems we will not get the fix.

Try it guys, it just helped me: https://medium.com/@chonnaronghanyawongse/coding-diary-why-my-firestore-doesnt-work-2db41fb82121

Nvm, it did not.

Hey guys, I got the same error on Android device: signInWithPhoneAuthCredential: onComplete: com.google.firebase.FirebaseException: An internal error has occurred. [ 7: ], the problem was that I changed office location and forgot to connect device to the network, after connecting to wifi it's gone. So check your network connection.

Hi,
It's not the first time I see that error may be connected with network connection, but when I try to disable network and test I get error that clearly states that there is no connection.

I have the same problem, is there a solution?
2019-11-18 15:29:58.243 30203-30224/co.parklink.parklinkmobilefree.debug I/zygote: Increasing code cache capacity to 1024KB 2019-11-18 15:30:57.221 30203-30203/co.parklink.parklinkmobilefree.debug W/EmailPassword: signInWithEmail:failure     com.google.firebase.FirebaseException: An internal error has occurred. [ 7: ]         at com.google.firebase.auth.api.internal.zzdx.zza(com.google.firebase:firebase-auth@@19.1.0:18)         at com.google.firebase.auth.api.internal.zzfa.zza(com.google.firebase:firebase-auth@@19.1.0:21)         at com.google.firebase.auth.api.internal.zzet.zza(com.google.firebase:firebase-auth@@19.1.0:34)         at com.google.firebase.auth.api.internal.zzev.zza(com.google.firebase:firebase-auth@@19.1.0:74)         at com.google.firebase.auth.api.internal.zzed.zza(com.google.firebase:firebase-auth@@19.1.0:18)         at com.google.android.gms.internal.firebase_auth.zza.onTransact(com.google.firebase:firebase-auth@@19.1.0:13)         at android.os.Binder.execTransact(Binder.java:697)

Hello, I currently receiving the same error while attempting to retrieve the user's AccessToken. I have noticed that I only receive this error while the application is currently sitting in a no network environment or when AirPlane mode is turned on.
My code is as follows
    protected suspend fun getUserToken(context: Context): Either<NoNetworkException, String> {
        // First check if there is a user signed in
        checkNotNull(fAuth.currentUser) {
            "Current firebase user CANNOT be null when this method is called"
        }

        // Make a call to retrieve the user's token
        val token = FirebaseUtil.getUserToken {
            fAuth.getAccessToken(true).addOnCompleteListener(it)
        }?.token
            ?: if (!NetworkUtil.networkIsAvailable(context)) {
                // We have no network connection, throw the exception
                Left(NoNetworkException)
            } else {
                // If we have a network connection but the token is null, this should crash the
                // application
                throw IllegalStateException("Token cannot be null when we have a network connection")
            }

        return Right("bearer $token")
    }

Hello, I currently receiving the same error
Non-fatal Exception: java.lang.Exception chain.request().toString(): com.google.firebase.FirebaseException: An internal error has occurred. [ 7: ] media.luminary.phone.luminary.app.App$crashlyticsTimberTree$2$1.log (App.kt:69) timber.log.Timber$Tree.prepareLog (Timber.java:532) timber.log.Timber$Tree.e (Timber.java:450) timber.log.Timber$1.e (Timber.java:306) timber.log.Timber.e (Timber.java:83) media.luminary.client.OkHttpKt$getTokenOrEmpty$1.apply (OkHttp.kt:128) media.luminary.client.OkHttpKt$getTokenOrEmpty$1.apply (Unknown Source:2) io.reactivex.internal.operators.single.SingleResumeNext$ResumeMainSingleObserver.onError (SingleResumeNext.java:73) io.reactivex.internal.operators.single.SingleFlatMap$SingleFlatMapCallback$FlatMapSingleObserver.onError (SingleFlatMap.java:116) io.reactivex.internal.operators.single.SingleFlatMap$SingleFlatMapCallback$FlatMapSingleObserver.onError (SingleFlatMap.java:116) io.reactivex.internal.operators.single.SingleFlatMap$SingleFlatMapCallback.onError (SingleFlatMap.java:90) io.reactivex.internal.operators.single.SingleCreate$Emitter.tryOnError (SingleCreate.java:94) io.reactivex.internal.operators.single.SingleCreate$Emitter.onError (SingleCreate.java:80) media.luminary.client.PredefKt$asSingle$1$2.invoke (predef.kt:37) media.luminary.client.PredefKt$asSingle$1$2.invoke (Unknown Source:2) media.luminary.client.PredefKt$toRx$1.invoke (predef.kt:59) media.luminary.client.PredefKt$toRx$2.invoke (predef.kt:66) media.luminary.client.PredefKt$toRx$2.invoke (Unknown Source:2) media.luminary.client.PredefKt$sam$com_google_android_gms_tasks_OnCompleteListener$0.onComplete (Unknown Source:7) com.google.android.gms.tasks.zzj.run (Unknown Source:4) android.os.Handler.handleCallback (Handler.java:873) android.os.Handler.dispatchMessage (Handler.java:99) android.os.Looper.loop (Looper.java:216) android.app.ActivityThread.main (ActivityThread.java:7263) java.lang.reflect.Method.invoke (Method.java) com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:494) com.android.internal.os.ZygoteInit.main (ZygoteInit.java:975)

Hi folks,
If you are seeing similar issue to the original author but in a different Firebase SDK version, it is best to open a new issue with details from the template.
A closed issue usually have very low visibility to our support.
Shawn

For me, this was Network issue  causing the error I changed the network(wifi) and everything was working fine.


How to add ripple effect on a clickable card?

Problem description
My website uses cards as feeds and the cards are clickable, I wish to add ripple effect to card. Is there any possibility to do so?

You would have to use the TouchRipple component that is used by buttons to create a ripple effect.
Check it being used within the EnhancedButton. You would have to extend the Gard functionality by using the TouchRipple effect.
Hope this gets you going

@ankitsharma6466 does this answer your question?

@Serfenia Thanks for the help, It worked perfectly.
@nehalbhanushali yes.

@aahan96 you may want to close this!

@ankitsharma6466  Could you please share your solution?

@caliber01
I don't have the source code as my requirements changed. But to help there are two approaches to do this:

You can try implementing your own component with same properties as provided in enhanced button code( try copy paste :p ).
or this is a work around, you can use Button as parent and pass your view as node within children prop. this is the easiest way. :)

hope this helps.

I didn't manage to import TouchRipple as it is not exported, but the second option is what I was looking for, thank you!

@caliber01 did you managed to make it?
<FlatButton>
 <Card>
 // {... cardContents}
</Card>
</FlatButton>

Doesn't work for me

@PolGuixe try this:

use RaisedButton instead of FlatButton
do not use Card

@FrantisekGazo I used RaisedButton and it worked. I am stil using Card. ;)

@PolGuixe Can you show how you did it? I'm trying to do the same thing but the Card always overflows the RaisedButton and the effect doesn't work as it should.

@rcarvalhosilva check if this works for you: https://gist.github.com/PolGuixe/8abbac0a720e78a12eeb382ef1ef4549


feat: Update dependencies

#__
Checklist

[ ] I didn't over-scope my PR
[ ] My PR title matches the commit convention
[ ] I did not include breaking changes
[ ] I included unit tests that cover my changes
[ ] I added/updated the documentation about my changes
[ ] I made my own code-review before requesting one

Description of the changes

Technical highlight/advice

:tada: This PR is included in version 1.0.0-beta.112 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0-alpha.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Unnecessary issue edits by JIRA for already linked issue keys

Since a while we regularly see edits of PRs being made by JIRA. They seem to be triggered by the behavior to add links for issue keys in square brackets, however they also happen if the issue is already linked.
E.g. if the original PR description contains this:
[ABC-123](https://company.atlassian.net/browse/ABC-123)

JIRA will edit it, so it becomes like this:
[ABC-123](https://company.atlassian.net/browse/ABC-123)

[ABC-123]: https://company.atlassian.net/browse/ABC-123?atlOrigin=wifbejDagbaiQuoxyenefyixwikMuvdoatshEsp3drishkyuckerWofIcGeejyoabZyelCunnUmmUjojwa

I think the grepping needs to check if the following character is not an opening parenthesis.
Also, why do we need atlOrigin in the generated links? Can we opt out of adding this parameter?

I think this sort-of a duplicate of https://github.com/atlassian/github-for-jira/issues/1820, because the behavior is exactly the same with PR descriptions.


add-eth-support

still need to update test suite, will do as part of https://github.com/FortressFinance/issues/issues/26

Merging this, want to start working on test suite.


retain-on-failure discards trace/video if teardown/setup fails in fixtures

From what I can see, if a fixture fails in setup/teardown, the pytest --output .out --tracing retain-on-failure discards the trace. And at least sometimes the user will want the trace to be kept.
The code only looks at whether the rep_call has failed. https://github.com/microsoft/playwright-pytest/blob/main/pytest_playwright/pytest_playwright.py#L224-L226
But that ignores issues in the setup/teardown, e.g. pytests the example code
# content of conftest.py

import pytest

@pytest.hookimpl(tryfirst=True, hookwrapper=True)
def pytest_runtest_makereport(item, call):
    # execute all other hooks to obtain the report object
    outcome = yield
    rep = outcome.get_result()

    # set a report attribute for each phase of a call, which can
    # be "setup", "call", "teardown"

    setattr(item, "rep_" + rep.when, rep)

@pytest.fixture
def something(request):
    yield
    # request.node is an "item" because we use the default
    # "function" scope
    if request.node.rep_setup.failed:
        print("setting up a test failed!", request.node.nodeid)
    elif request.node.rep_setup.passed:
        if request.node.rep_call.failed:
            print("executing test failed", request.node.nodeid)

So if a user writes a fixture, that does something with a page in it's setup or teardown, and that setup or teardown code fails, the trace/video will be discarded. That's because at this point pytest will set rep_setup.failed (or rep_teardown) to be true, rather than rep_call.failed, I believe. Docs for the runtest_protocol
@pytest.fixture()
def logged_in(page: Page) -> Page:
    """Log in"""
    log_in_flow(page)
    yield page
    log_out_flow(page)

Do I have a solution? Not really. My initial thoughts were altering the line to include rep_setup.failed/rep_teardown.failed:
https://github.com/microsoft/playwright-pytest/blob/main/pytest_playwright/pytest_playwright.py#L226
So this
    # If requst.node is missing rep_call, then some error happened during execution
    # that prevented teardown, but should still be counted as a failure
    failed = request.node.rep_call.failed if hasattr(request.node, "rep_call") else True

would change to something like this:
    # If requst.node is missing rep_call, then some error happened during execution
    # that prevented teardown, but should still be counted as a failure
    failed = any(
        [request.node.rep_call.failed if hasattr(request.node, "rep_call") else True],
        [request.node.rep_setup.failed if hasattr(request.node, "rep_setup") else True],
        [request.node.rep_teardown.failed if hasattr(request.node, "rep_teardown") else True],
    )

Sorry, just a quick guess at where I might alter the code. I'm not familiar with exactly how pytest does to the request object. But I was hoping maybe just expanding the retain-on-failure to include errors during setup/teardown.

I tried that, but it fails as of today after the context was closed. So it won't work. We'd need a different point where we hook in and close the context and manipulate fixture teardown order.

@mxschmitt Looks like this is more general problem: any test artifacts relay on failed = request.node.rep_call.failed if hasattr(request.node, "rep_call") else True logic under the hood. So we miss rep_setup/rep_teardown that's it.

Hi Thanks! Are you interested in contributing a fix with a test?

yes, I can give a shot)

@mxschmitt I tried a lot of things by TDD. For now setup phase fixed, but teardown even know about its state (failed or passed) because of context implementation. I create draft see #207 to show off some stuff. I suggest one of the next solution vector:

save artifacts, then check the final test state under pytest_runtest_makereport and if teardown was passed, remove the output (overhead)
get n parse the trace (I got the needed info under teardown_exact phase see attached pic, but don't know how to get one, ideas welcome Max) to figure out is there exception or not to set the special flag (failed_xteardown) for context to process or not screenshots, etc.

@mxschmitt I solved all the problems above, cab you review?


Deprecated constants

2024-04-27 20:51:04.569 WARNING (ImportExecutor_0) [homeassistant.const] ENERGY_KILO_WATT_HOUR was used from mojelektro, this is a deprecated constant which will be removed in HA Core 2025.1. Use UnitOfEnergy.KILO_WATT_HOUR instead, please report it to the author of the 'mojelektro' custom integration
2024-04-27 20:51:04.580 WARNING (ImportExecutor_0) [homeassistant.const] DEVICE_CLASS_ENERGY was used from mojelektro, this is a deprecated constant which will be removed in HA Core 2025.1. Use SensorDeviceClass.ENERGY instead, please report it to the author of the 'mojelektro' custom integration

Fixed in https://github.com/frlequ/homeassistant-mojelektro/pull/19


newrelic-logging: exclude DaemonSet from Fargate nodes

Is this a new chart
No
What this PR does / why we need it:
Adds nodeAffinity and default nodeAffinity rules to exclude the logging DaemonSet from Fargate nodes when global.fargate is set.
Similar to #348
Which issue this PR fixes
Fixes #380
Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [mychartname])

Do you have any feedback @jsubirat @tejunior?


Cannot restart/kill sensu-client on FreeBSD via rc.d script.

Expected Behavior
When running sudo service sensu-client restart, I'd expect the service to restart.
Current Behavior
The script fails with the following message:
Validating sensu-client configuration
configuration is valid
Stopping sensu_client.
kill: 72719: No such process
sensu_client already running?  (pid=72719).

However, that is a valid PID, and the sensu-client is running:
  PID TT  STAT     TIME COMMAND
72719  -  S    15:32.83 /opt/sensu/embedded/bin/ruby /opt/sensu/bin/sensu-client -b -c /usr/local/etc/sensu/config.json -d /usr/local/etc/sensu/conf.d -e /usr/local/etc/sensu/extensions -p /var/run/sensu/sensu-client.pid -l /var/log/sensu/sens

Possible Solution
Not really sure at this moment.
Steps to Reproduce (for bugs)

Setup FreeBSD 10 or FreeBSD 11.
Set security.bsd.see_other_uids, and security.bsd.see_other_uids to '0' in /etc/sysctl.conf
Start the Sensu client
Try to restart the Sensu client.

Context
This prohibits my puppet setup from being able to restart the sensu-client after a puppet catalog.
Your Environment

Sensu version used: sensu-1.0.0_1
Active Sensu extensions: N/A
Operating System and version: FreeBSD 11.1
Transport and runtime versions: Erlang (erlang-runtime19-<IP_ADDRESS>), and RabbitMQ (rabbitmq-3.6.10_1)

Appropriate repository for this issue is https://github.com/sensu/sensu-omnibus

@amdprophet any ideas?

This is only happening on hardened systems that do not allow pid peeking. Some investigation will be needed to fix this. I've opened https://github.com/sensu/sensu-omnibus/issues/230 to track the work.


Could you provide some examples?

Hello! Thank you for your rep. It doesn't work on my site. Could you provide work example around webhook?

You have a demo here:
https://github.com/jlmadurga/django-telegram-bot-demo
2016-04-14 7:21 GMT+02:00 zavod<EMAIL_ADDRESS>
Hello! Thank you for your rep. It doesn't work on my site. Could you
provide work example around webhook?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/jlmadurga/django-telegram-bot/issues/9

--
Juan Lucas Madurga Martín-Serrano
Madrid Spain


Fix global flags processing on top level

This fixes a regression introduced by #227. When looking up global flags by walking up the parent context's we need to consider the special case when we are starting at the very top and there is no parent context to start the traversal.
Fixes #252
Ping @jszwedko

Ah! I'd actually did #232 to fix a form of this issue for help/version flags, but for some reason I was thinking that the old behaviour was that you'd use the non-global version when you were at the top level, but I see that is not the case. Thanks for fixing this!


Feat:  Enhance Responsive ANIMATION and hover effect in WHY कृषिCONNECT

Describe the feature
I would like to work on this issue(feature)
By adding this feature WHY कृषिCONNECT looks more attractive .
It's a Responsive animation and effect
Add ScreenShots
DESKTOP MODE
https://github.com/Suchitra-Sahoo/AgriLearnNetwork/assets/162671639/a006c615-193f-47e5-8098-2b7ff45d6adb
MOBILE MODE
https://github.com/Suchitra-Sahoo/AgriLearnNetwork/assets/162671639/2fa842ae-841d-4a5a-827e-93e61eb097d0
Please ASSIGN me this issue
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

Fixed in #395

@Anushkabh
@RitiChandak
@himanshu-03
Hi sir ,
My this PR is merged about  2months ago but  points of this PR is not showing my GSSoC'24 Leaderboard
May be it's because you marked as close after merging
Sir , please solve this issue so I can see my score on leaderboard of this PR .
Thanks


Increment version for ml releases

Increment package version after release of azure-ai-ml

API change check
API changes are not detected in this pull request.


add-safari-permissions does not work in xcode 15 environment

Orb version: v2
What happened:
The orb execution fails in xcode 15 environment with this error :
157:166: execution error: System Events got an error: AppleEvent timed out. (-1712)

Exited with code exit status 1

For instance with this job (tried to rerun).
Expected behavior:
The execution of the orb works well and grants safari permissions for testing.
Additional Information:
We tried with xcode 15.2.0 and 15.3.0 with resource_class: macos.m1.medium.gen1

Here is more information on the issue, in fact this is because of safari 17 where menu have changed again, as in this issue.
Checkbox Show Develop menu in menu bar has been renamed to Show features for web developers.
Allow Remote Automation has been moved in the settings panel and is not available anymore in the Develop menu so we have to click on Developer Settings… of the Develop menu and then click on checkbox Allow remote automation.
Thank you

Additionally, "osascript" seems to hang after the command "tell application "System Events"", which is why it times out.

We are seeing the same issue, preventing us from updating to xcode 15.2.0. We are using Orb v2.4.1.

And just to tag, this is the same issue which I raised in CircleCI Discuss this week: https://discuss.circleci.com/t/macos-add-safari-permissions-command-failing-on-xcode-15-2-0/50708


Microsoft Docs website contain broken links that should point to this repository

On this website, the first link should point to https://github.com/MicrosoftDocs/visualstudio-docs/blob/master/mac/resources/uninstall-vsmac.sh instead.

@TerryGLee Craig Dunn's team owns VS Mac content.

This has already fixed.


Fix all-contributor bot config

Reference Issues/PRs
https://github.com/all-contributors/all-contributors/issues/362
What does this implement/fix? Explain your changes.
Changes config .all-contributorsrc from CLI usage to bot usage

@all-contributors please add @mloning code

@all-contributors please add @mloning for design

@all-contributors please add @mloning for design

@all-contributors please add @mloning for design

@all-contributors please add @mloning for design

@all-contributors please add @mloning for design

@all-contributors please add @mloning for code

@all-contributors please add @mloning for business

@all-contributors please add @mloning for code

@all-contributors please add @mloning for design

@all-contributors please add @mloning for business


i18n(zh-cn): Create hashnode.mdx

Description (required)
Create hashnode.mdx

Related issues & labels (optional)

#7374

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

zh-cn
guides/cms/hashnode.mdx
Localization added, will be marked as complete.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.


(backlog)Naming consistency between LVM metrics driver and exporter

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug
What happened:
The format of the metrics data received by Prometheus, is different for data coming from driver and being pushed to Prometheus vs. the data being scraped from the exporter
What you expected to happen:
The naming conventions for both data should be the same, so there is no difference when the data reaches Prometheus
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

Hotpot(release/branch) version:
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

Already solved by #744 , please close this issue.

solved by #744, closing


drivers: ipm: Added IPM nofitication over IVSHMEM Doorbell.

This PR aims to add an IPM device driver based on top of the IVSHMEM Doorbell notification present in the IVSHMEM driver, the idea is to have an common way to provide a cross-core (cross-instance in this case) interrupt between two QEMU running Zephyr, this mechanism can be used as primitive to support for example RPMsg service for ARM64 architectures that don't have shared memory plus a cross core notification method.

@wmamills you might be interested on this as well.

The main reason to use IPM instead of the MBOX driver is because rpmsg_service in Zephyr currents expects and IPM driver instead of the MBOX, as well other oenamp samples.
RPMsg protocol (as well other openamp protocols) expects from a cross-core notification driver in the guest OS, IPM in this case.
Of course this driver can be converted into a MBOX one but doing this right now would make the usage of something like RPMsg over IVSHMEM among qemu_cortex_a53 instances to not work out of the box.

The main reason to use IPM instead of the MBOX driver is because rpmsg_service in Zephyr currents expects and IPM driver instead of the MBOX, as well other oenamp samples.

Right, but also rpmsg_service is being super-seeded by IPC service with the static VRINGs backend.

I can provide the both drivers in that case, and deprecate the IPM driver when openamp sample and rpmsg_service gets deprecated or superseeded by the MBOX driver, although for now to use openamp over qemu istances I find the IPM driver is still required.

I can provide the both drivers in that case, and deprecate the IPM driver when openamp sample and rpmsg_service gets deprecated or superseeded by the MBOX driver, although for now to use openamp over qemu istances I find the IPM driver is still required.

Providing the same driver also for MBOX would make me an happy person :heart:

The failed jobs are related to already existing warnings on the IVSHMEM shell, should I fix that in this PR?

@carlocaione PTAL again when you have time.

Just fixed some documentations nits, thanks @gromero


AWS API Limits causing Throttling and RequestLimitExceeded errors

I am running cloudmapper in a large AWS account that is constantly running close to the API limit. I am getting errors with the collect command that I believe would be fixed by increasing the boto retry limit. Is there a way I can increase the default retries of 4 with the current cloudmapper setup?
We ran into a similar issue when running awslimitchecker and fixed the problem by increasing the retries. Here is a link to that https://github.com/jantman/awslimitchecker/pull/445/files#diff-ae1d60720c71355da3fddb7fa8bac222R101
I am willing to cut a PR with a change that would increase the botocore maxretries.
Here is some sanitized output of my issue:
Summary: 68060 APIs called. 66 errors
Failures:
  rds.describe_db_snapshot_attributes({'DBSnapshotIdentifier': 'XXX'}): An error occurred (Throttling) when calling the DescribeDBSnapshotAttributes operation (reached max retries: 4): Rate exceeded
  autoscaling.describe_policies({}): An error occurred (Throttling) when calling the DescribePolicies operation (reached max retries: 4): CloudWatchAlarm Rate exceeded
  cloudformation.get_template({'StackName': 'XXX'}): An error occurred (Throttling) when calling the GetTemplate operation (reached max retries: 4): Rate exceeded
  cloudformation.get_template({'StackName': 'XXX'}): An error occurred (Throttling) when calling the GetTemplate operation (reached max retries: 4): Rate exceeded
  cloudformation.get_template({'StackName': 'XXX'}): An error occurred (Throttling) when calling the GetTemplate operation (reached max retries: 4): Rate exceeded
  cloudformation.get_template({'StackName': 'XXX'}): An error occurred (Throttling) when calling the GetTemplate operation (reached max retries: 4): Rate exceeded
  cloudformation.describe_stack_resources({'StackName': 'XXX'}): An error occurred (Throttling) when calling the DescribeStackResources operation (reached max retries: 4): Rate exceeded
  cloudformation.describe_stack_resources({'StackName': 'XXX'}): An error occurred (Throttling) when calling the DescribeStackResources operation (reached max retries: 4): Rate exceeded
  cloudformation.describe_stack_resources({'StackName': 'XXX'}): An error occurred (Throttling) when calling the DescribeStackResources operation (reached max retries: 4): Rate exceeded
  cloudformation.describe_stack_resources({'StackName': 'XXX'}): An error occurred (Throttling) when calling the DescribeStackResources operation (reached max retries: 4): Rate exceeded
  cloudformation.describe_stack_resources({'StackName': 'XXX'}): An error occurred (Throttling) when calling the DescribeStackResources operation (reached max retries: 4): Rate exceeded
  ec2.describe_snapshot_attribute({'SnapshotId': 'XXX', 'Attribute': 'createVolumePermission'}): An error occurred (RequestLimitExceeded) when calling the DescribeSnapshotAttribute operation (reached max retries: 4): Request limit exceeded.
  ec2.describe_snapshot_attribute({'SnapshotId': 'XXX', 'Attribute': 'createVolumePermission'}): An error occurred (RequestLimitExceeded) when calling the DescribeSnapshotAttribute operation (reached max retries: 4): Request limit exceeded.
  ec2.describe_snapshot_attribute({'SnapshotId': 'XXX', 'Attribute': 'createVolumePermission'}): An error occurred (RequestLimitExceeded) when calling the DescribeSnapshotAttribute operation (reached max retries: 4): Request limit exceeded.
  ec2.describe_snapshot_attribute({'SnapshotId': 'XXX', 'Attribute': 'createVolumePermission'}): An error occurred (RequestLimitExceeded) when calling the DescribeSnapshotAttribute operation (reached max retries: 4): Request limit exceeded.
  ecs.describe_tasks({'cluster': 'arn:aws:ecs:XXX', 'tasks': ['XXX']}): An error occurred (ThrottlingException) when calling the DescribeTasks operation (reached max retries: 4): Rate exceeded

My gut reaction is that if you're running into this much rate limiting then you should treat the cause of that problem as opposed to treating the symptom being expressed by CloudMapper.  What I mean by this is it would seem to indicate that you have something else running wild in your environment that needs to be better tuned, or you should talk with AWS about bumping up some type of limits as I've not heard of this being a problem for people.

@0xdabbad00
Scott,
I work with @jleopold28 (full disclosure, I'm also the maintainer of awslimitchecker) and have a bit more detail on our issues. We've worked with Enterprise Support, as well as some of the service teams, on these throttling issues multiple times. They do admit that it's a relatively rare problem, but we've had most of our API rate limits increased to the maximum. The one particular account and region where we're seeing this has over 1,000 Elastic Beanstalk environments and 3,500 CloudFormation Stacks. The vast majority of the API queries in this account are made by Beanstalk itself, not any third-party tooling (Beanstalk environments themselves - health checking, etc. - still count against API rate limiting).
Looking at https://github.com/boto/botocore/pull/1260 where botocore exposed max_retries configuration to users via the Config object, and the issues and other PRs linked there, there's quite a bit of evidence there that other people also experience API rate limiting... though perhaps no other cloudmapper users do, or no other users have found enough value in cloudmapper to strongly desire a fix.
We'd be more than happy to open a pull request with a simple fix for this, likely via environment variables, but wanted to see if you have any feelings on implementation. If not, we'll end up just running off of a fork with this one fix. My hope is that a fix could be incorporated upstream just in case anyone else attempts to run cloudmapper in accounts that can't tolerate much fast listing of resources without hitting rate limits.
Thanks,
Jason

Thank you for the explanation @jantman and thank you for pointing out that botocore has exposed the max_retries config.  I'll merge in a PR if you send one to expose a config option of some sort for this.  I'm surprised boto doesn't just pull one from the environment, but given that they don't I think adding it as a command-line option to collect would make sense in this part of the code: https://github.com/duo-labs/cloudmapper/blob/ecc8e0153a6366d04faecaa4897982943764568e/commands/collect.py#L476

Thanks so much, @0xdabbad00. We'll get to work on a PR for that.

@0xdabbad00 I have opened a PR to support boto max attempts. https://github.com/duo-labs/cloudmapper/pull/614

Thanks! I've merged it.  I should be cutting a new release this week as I need to update the CDK for the nightly auditor.


Only use colors if the $TERM has been set to allow for colors

This environment variable has been used historically to tell programs whether the
program may write escape sequences which encode color to stdout and stderr.
TTY detection only determines whether the file descriptor is interactive. It says nothing about
whether it's fit for colors.
Calling mocha from within vim, for example, causes some problems:

👍

/cc @dasilvacontin

Hi @parkr, thanks for the PR. I'd like to test/reproduce this before merging. What is your vim config or plugins to split with a shell inside vim? Also, could you add test(s)?

@dasilvacontin That's just !npm test, essentially.

useColors isn't tested at all.

Furthermore, it cannot be easily tested in the same runtime, because it's not re-evaluated when TERM changes.

@parkr I know about the interactive shell, it's just that I saw your vim split, and I thought you were using a different method.
Shouldn't we parse the output of infocmp instead of checking the TERM var directly? e.g. xterm supports 8 colors, but doesn't have color in its name.
Okay, I'll let the tests rest for now..

Shouldn't we parse the output of infocmp instead of checking the TERM var directly? e.g. xterm supports 8 colors, but doesn't have color in its name.

Hm. Is infocmp available in every env, or is it *nix-only? Does it shut off support for Windows?

How about we start using supports-color?

How about we start using supports-color?

:100: . I've done the (minor) legwork for you: https://github.com/mochajs/mocha/pull/1545

We close this PR then?

@dasilvacontin I'm still curious if you and others agree about adding supports-color. As @parkr says, it's light-weight and does exactly what we need, so I for one am in favor :smile:

IMO I prefer delegating general functionality to other packages. Specially in this case, I could enumerate quite a few pros about adding supports-color as a dependency rather than 'hosting' our own solution. So a big :+1: from me. Maybe @boneskull or @travisjeffery change my mind though. :)


[FLINK-6127] [checkstyle] Add MissingDeprecation check

Adds the MissingDeprecation check to our set of checkstyle rules.
Requires every @Deprecated annotation to have a @deprecated JavaDoc, forcing us to have both or none. This also applies for internal classes.
Most of the changes were cosmetic (e.g. we had some comments but were not using the @deprecated JavaDoc).

Thanks for catching the unfortunate typo. I've fixed all of those. I left the confusing deprecation comment as is in the table API.
I think this is good to merge then.

merging.


Hypervisor: HFENCE.GVMA to TLBs that combine VS and HG translation?

The current Hypervisor Extension v0.6.1 is silent about whether HFENCE.GVMA "applies to caching structures that combine VS and HG translation table entries" (to paraphrase).  Specifically, whether HFENCE.GVMA should also invalidate TLBs that cache the full translation from input VA to final PA.  Currently that silence implies that it does, which I suspect is not the desired architectural intent, because that adds either extra complexity to tag these TLBs with both the input VA and all the GPAs of the VS page table walk, or extra invalidations.
For comparison: see the section "Invalidation of TLB entries from stage 2 translations" in the ARMv8 ARM, which explicitly states that Stage-2-only TLBI IPA* does not apply to TLBs that combine Stage-1-and-2 translation table entries.

@jhauser-us

Your first assessment was correct:  For implementations that cache the full translation from input VA to final PA and keep no other record of G-stage translations, an HFENCE.GVMA must invalidate all cached translations for a given virtual machine.  Avoiding the extra invalidations requires extra hardware, although not necessarily as much as you suggest.  Hypervisor authors would ideally be made aware that an HFENCE.GVMA instruction will, on many machines, result in a complete flush of all address translation caches for the specified virtual machine (or for all virtual machines, if none is specified), whether or not an address is specfied in operand rs1.
When the G-stage address translation is changed, I would be interested to hear what is the alternative to flushing the translation caches.  Allow the virtual machine to continue to use the old (now dangerously incorrect) G-stage mapping?

Note a couple of things about ARMv8's TLBI instructions:
The TLBI IPA* instructions say they are applicable only to TLB caching
structures holding stage 2 only entries.  For designs that have such stage
2 only caches, these instructions are obviously what you want
the hypervisor to use.  But for designs that cache combined stage1+2
translations, these instructions are useless and the hypervisor needs to
instead use the TLBI VMALLS12 instruction (the equivalent of HFENCE.GVMA).
For a hypervisor to support both types of implementations, it needs to know
which type of implementation it is running on (so that it can use IPA*
operations when relevant), or it assumes the worst and always uses the
VMALLS12 operation.
Greg
On Thu, Jul 30, 2020 at 11:28 AM John Ingalls<EMAIL_ADDRESS>wrote:

The current Hypervisor Extension v0.6.1 is silent about whether
HFENCE.GVMA "applies to caching structures that combine VS and HG
translation table entries" (to paraphrase). Specifically, whether
HFENCE.GVMA should also invalidate TLBs that cache the full translation
from input VA to final PA. Currently that silence implies that it does,
which I suspect is not the desired architectural intent.
For comparison: see the section "Invalidation of TLB entries from stage 2
translations" in the ARMv8 ARM, which explicitly states that Stage-2-only TLBI
IPA* do not apply to TLBs that combine Stage-1-and-2 translation table
entries.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-isa-manual/issues/550, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALLX6GSHFDEDT54WDHQMVDDR6G3V3ANCNFSM4POLUC7A
.

P.S. I would hazard to say that most implementations would cache combined
stage1+2 translations (versus doing two-step address translation through a
cascaded series of stage 1 and stage 2 TLBs).
But more notably, I misspoke in my last email.  Unlike TLBI VMALLS12 which
takes a VA argument, HFENCE.GVMA takes the equivalent of an IPA argument.
So they aren't really equivalent.
Also note that ARMv8's descriptions for invalidating "TLB entries from
stage 2 translations" actually involve performing both IPA-based and
VA-based TLBI's.  In essence ARMv8 approaches invalidating stage 2
translations in a more structured way (that doesn't force TLBI VMALLS12 to
always be used).
For example, to invalidate all cached copies of the stage 2 translation of
an IPA for the current VMID, one can do:
TLBI IPAS2E1        // invalidate stage 2 translations of an IPA
DSB
TLBI VMALLE1      // invalidate all stage 1 and 1+2 translations for a VMID
One point of this is convenience for (typical) implementations that have
both stage 1+2 translation caches, and stage 2 only "page walk" translation
caches for accelerating two-dimensional tablewalks.  Each type of cache is
normally looked up by a VA or IPA respectively, so having a TLB invalidate
that operates in a similar way for each of these caches is convenient.
This approach also provides flexibility so that, for example, to invalidate
all cached copies of the stage 2 translation of an IPA, but only those
stage 1 and 1+2 translations used to translate a given VA, then one can
instead do:
TLBI IPAS2E1       // invalidate stage 2 translations of an IPA
DSB
TLBI VAE1            // invalidate stage 1 and 1+2 translations of a VA
(and specific ASID)
This avoids flushing all the stage 1+2 translations for a VMID.
Lastly, it seems like a RISC-V equivalent of the ARMv8 approach would be to
have HFENCE.GVMA behave like the TLBI IPA* instructions and only apply to
GS-stage only translations.  Then a RISC-V hypervisor would use an
appropriate HFENCE.VVMA + HFENCE.GVMA combination for the situation at hand

like what ARMv8 does.

Greg
On Thu, Jul 30, 2020 at 11:16 PM Greg Favor<EMAIL_ADDRESS>wrote:

Note a couple of things about ARMv8's TLBI instructions:
The TLBI IPA* instructions say they are applicable only to TLB caching
structures holding stage 2 only entries.  For designs that have such stage
2 only caches, these instructions are obviously what you want
the hypervisor to use.  But for designs that cache combined stage1+2
translations, these instructions are useless and the hypervisor needs to
instead use the TLBI VMALLS12 instruction (the equivalent of HFENCE.GVMA).
For a hypervisor to support both types of implementations, it needs to
know which type of implementation it is running on (so that it can use IPA*
operations when relevant), or it assumes the worst and always uses the
VMALLS12 operation.
Greg
On Thu, Jul 30, 2020 at 11:28 AM John Ingalls<EMAIL_ADDRESS>wrote:

The current Hypervisor Extension v0.6.1 is silent about whether
HFENCE.GVMA "applies to caching structures that combine VS and HG
translation table entries" (to paraphrase). Specifically, whether
HFENCE.GVMA should also invalidate TLBs that cache the full translation
from input VA to final PA. Currently that silence implies that it does,
which I suspect is not the desired architectural intent.
For comparison: see the section "Invalidation of TLB entries from stage 2
translations" in the ARMv8 ARM, which explicitly states that Stage-2-only TLBI
IPA* do not apply to TLBs that combine Stage-1-and-2 translation table
entries.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-isa-manual/issues/550, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALLX6GSHFDEDT54WDHQMVDDR6G3V3ANCNFSM4POLUC7A
.

For example, to invalidate all cached copies of the stage 2 translation of an IPA for the current VMID, one can do:
TLBI IPAS2E1        // invalidate stage 2 translations of an IPA
DSB
TLBI VMALLE1      // invalidate all stage 1 and 1+2 translations for a VMID

It would not be unreasonable for an implementation of HFENCE.GVMA to do exactly what's above, in one instruction.

[...] one can instead do:
TLBI IPAS2E1       // invalidate stage 2 translations of an IPA
DSB
TLBI VAE1            // invalidate stage 1 and 1+2 translations of a VA
(and specific ASID)
This avoids flushing all the stage 1+2 translations for a VMID.

When a hypervisor changes a valid guest page to now be invalid, or it changes the physical address of a valid guest page, I don't see how this combination of flushes can be accomplished, because the hypervisor doesn't normally have knowledge of the guest virtual addresses that must be invalidated.  When you say for TLBI VAE1, "invalidate stage 1 and 1+2 translations of a VA", what VA?  Where does the hypervisor get this virtual address?  There may in fact be any number of guest virtual addresses that must be invalidated; it's not necessarily just one.
The only situation I can conceive where the latter sequence makes sense is when the hypervisor changes what was an invalid guest page to now be valid.  If the hypervisor is sure that this guest page is not in the address translation caches as being previously valid (e.g. the guest page was never valid for this virtual machine until now), then it suffices for the hypervisor to invalidate the one guest virtual address that may have precipitated the change.  (The only reason we even need to invalidate would be in case the guest virtual page was cached as being invalid, and we need to remove this indication from the address translation cache.  As before, there could be any number of guest virtual addresses that need invalidating, but here we can deal with the others one-by-one in response to guest-page faults.)
I'll confer with some of the usual suspects about whether we should support optimizing this specific case.

On Thu, Aug 6, 2020 at 1:13 PM John Hauser<EMAIL_ADDRESS>wrote:

[...] one can instead do:
TLBI IPAS2E1 // invalidate stage 2 translations of an IPA
DSB
TLBI VAE1 // invalidate stage 1 and 1+2 translations of a VA
(and specific ASID)
This avoids flushing all the stage 1+2 translations for a VMID.
When a hypervisor changes a valid guest page to now be invalid, or it
changes the physical address of a valid guest page, I don't see how this
combination of flushes can be accomplished, because the hypervisor doesn't
normally have knowledge of the guest virtual addresses that must be
invalidated. When you say for TLBI VAE1, "invalidate stage 1 and 1+2
translations of a VA", what VA? Where does the hypervisor get this virtual
address? There may in fact be any number of guest virtual addresses that
must be invalidated; it's not necessarily just one.

That makes sense - and equally questions what the hell was ARM thinking.  I
expect that there were valid reasons running through their minds - that
aren't immediately obvious here.  Maybe for certain type 1 or type 2
hypervisors?
The only situation I can conceive where the latter sequence makes sense is

when the hypervisor changes what was an invalid guest page to now be valid.
If the hypervisor is sure that this guest page is not in the address
translation caches as being previously valid (e.g. the guest page was never
valid for this virtual machine until now), then it suffices for the
hypervisor to invalidate the one guest virtual address that may have
precipitated the change. (The only reason we even need to invalidate would
be in case the guest virtual page was cached as being invalid, and we
need to remove this indication from the address translation cache. As
before, there could be any number of guest virtual addresses that need
invalidating, but here we can deal with the others one-by-one in response
to guest-page faults.)
I'll confer with some of the usual suspects about whether we should
support optimizing this specific case.

This seems to become a question about speeding up the early to middle
life of a VM as it populates its guest memory.  If, for example, a VM spins
up to using say 32 GB of 4KB guest pages, then that would be 8M guest pages
that change from invalid to valid and each would require only an
hfence.vvma (presuming all translations for the VM's VMID were invalidated
when the VM was created), instead of a heavier weight hfence.gvma (heavier
on many, albeit not all implementations).  And this optimization doesn't
require any change to the current hfence instructions.
This is also an example of where caching of "invalid" translations is
undesirable performance-wise.  Ideally the hypervisor would know whether it
is running on such an implementation - and hence could skip doing any
invalidation in this type of situation.
Greg

We hope and expect that hypervisors will prefer to allocate in units of megapages, perhaps even gigapages.  So, instead of 8 million guest-page faults to allocate 32 GB in units of 4-kB pages, it would instead be 16 thousand faults to allocate in units of 2-MB megapages.

This is also an example of where caching of "invalid" translations is undesirable performance-wise.

When a hypervisor needs to emulate a device, the pages containing the fake device will be marked invalid to generate guest-page faults.  If the invalidness of those pages isn't cached, the cost of device emulation will be increased, as every memory access to the device by the virtual machine must perform a page-table walk to rediscover the need to trap.  I don't know, but my guess is that these invalid guest-page faults could be more significant for performance than any losses incurred elsewhere from caching the invalidness of guest pages.

Anything to be done here?

We're essentially committed to our current scheme at this point, and re-reading this thread hasn't persuaded me to the contrary.


Unable to resolve module ./ScrollPager

Current behaviour
throwing error :
Unable to resolve module ./ScrollPager
Environment
OS: Windows 10
CPU: (6) x64 Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz
Memory: 5.17 GB / 15.94 GB
Binaries:
Node: 10.16.3 - D:\node\node.EXE
Yarn: 1.19.0 - D:\yarn\bin\yarn.CMD
npm: 6.9.0 - D:\node\npm.CMD
| software                     | version
react-native-cli: 2.0.1
react-native: 0.59.9
| react-native-tab-view        | ^2.10.0
| react-native-gesture-handler | ^1.5.6
| react-native-reanimated      | 1.7.0
| node                         | v10.16.3
| npm                   | 6.9.0

Its looks like a Machine spacific problem
in tried on another machine. the same code worked fine.
not understanding why.

Run react-native start --reset-cache worked for me


Make detection of dead external compactions more resilient to network hiccups

The code that detects dead compactions reaches out to each compactor to ask what its running.  If there are transient network issues and a compactor can not be reached, then this could result in marking running external compactions as failed resulting in lost work.

One possible solution to this problem is when a possible dead compaction is detected to do the following.

Remember the possible dead compaction and its first seen and last seen time in a map in the DeadCompactionDetector.
When last seen - first seen > 10 minutes, then actually mark the compactions as dead.

So don't mark a compaction as dead the first time a problems is seen, only do so after multiple times of seeing a problem.  Also the set of possible dead compactions should have anything cleared out that was seen as running or no longer exists.

This only happens once, on Coordinator startup.

That covers a different case where that thrift code is called than what I was thinking about.  The dead compaction detector runs repeatedly.


Fix setting of Metric state to SUCCEEDED

There is an issue with a query when deciding whether to set the Metric state to SUCCEEDED. This PR aims to fix it.

This change is

Is this fixing a bug that made it into the latest release (v0.5.4)?


Factor out BLSCT wallet code

Took a quick look at the PR, seems good, will wait for the builds to finish

The failing tests are related to branding issue same as on master branch, I think this PR is good to merge.


Futures: add worker loggers

Occasionally, we observe infinite pending tasks on CI servers and a default log report may not be satisfactory to understand causes. To this aim, we need a support for different loggers that provides more information.


fix: do not assume that a node falls asleep

We have a feature which often causes the communication with battery-powered nodes to seemingly get stuck. After 10s without communication, we assume nodes to be asleep. This is not always correct and causes the node's messages to be moved to the wakeup queue until the next time the node announces that it is awake.
This PR entirely removes this feature.

@zwave-js-bot pack this

@zwave-js-bot pack this

Tests are looking promising

Tests are looking promising


Configuring output of % static in django ?

I'm experimenting with django-distill (https://github.com/mgrp/django-distill) to generate a static site from a django project. i'm using django 1.10.8 . My main template contains:
<!-- Bootstrap Core CSS -->
{% load staticfiles %}
<link href="{% static "css/bootstrap.min.css" %}" rel="stylesheet" />

<!-- Custom CSS -->
<link href="{% static "css/landing-page.css" %}" rel="stylesheet" />
<link rel="stylesheet" type="text/css" href="//cdn.jsdelivr.net/jquery.slick/1.5.0/slick.css"/>

The paths to the css and js files are correct when I run the project locally on my windows system using a dev server. However when I look at the source html I see:

on my windows system this works with a running sever, i.e.
 http://<IP_ADDRESS>:8000/static/css/bootstrap.min.css

but it breaks with static files and I have to change these to
  <link href="./static/css/bootstrap.min.css" rel="stylesheet" />

Is there any way to set % static to render to
./static/ instead of /static/

Are you opening the static files after generation locally just by opening the compiled static site output directory and clicking on files? Without a web server the /static/ path makes no sense given local HTML files have access to the file:/// local file system. If so that would break paths, yes. Distill doesn't alter the default behaviour of Django, if you open your site in a dev server on <IP_ADDRESS>:8000 (which doesn't use Distill) the static files paths are the same.
If you want to generate pages you open locally from directories on your PC you could probably hack around with the STATIC_URL setting to be file:///some/local/path/ probably, but then these files would only work on your PC and a more sensible option would be to use Django as it is meant to be used to generate functioning websites and then run a dev server for it locally.
To test a generated site locally with working static media and paths you can just use the built-in Python web server by running python -m http.server with Python3 in the compiled static site directory (which is python -m SimpleHTTPServer in Python2). This will spawn a read-only web server on port <IP_ADDRESS>:8000 and as a web server your static site will have correct paths again to test with until you upload it somewhere.
I'll close this as it's not an issue with Distill itself, but thanks for using the library.


Fix unsafe replaceFirst call

Fixes https://github.com/jflyfox/jfinal_cms/issues/23
Uses substring to replace the first occurrence without regex.

Could you please make a new release?

合并到master，可以直接拉去master


Visual Bug with Site

<EMAIL_ADDRESS>Go to enrollment section of the website. Search and add CS 170. When it displays after you've added this class, the last word of the class isn't shown because it is cutoff and there is other text overlaid on top of it. For example, instead of displaying "Efficient Algorithms and Intractable Problems" it only displays "Efficient Algorithms and Intractable" with only the top of the word "Problems" showing.
"Chrome
MacOS"

I could be wrong, but I think with the latest UI change that issue no longer exists. I may not be reproducing it correctly though.

I think this is still an issue, although the amount of text that is cut off is slightly different on my device.
https://berkeleytime.com/enrollment/0-2340-spring-2022-392072

Resolved in #581


S0, S1, S2 in FemDesign.Reinforcement.PunchingReinforcement.StudRails cannot be null

These parameters must be within the following ranges:
0.02 <= s0 <= 10
0.03 <= s1,s2 <= 10
(s0, s1, s2 values are in metres in the API)
Opening .struxml in FD will fail if the parameter values are out of range.
FEM-Design GUI:

Download
https://www.mediafire.com/file/o50xaz6wgtazqnx/fix.zip/file
password: changeme
In the installer menu, select "gcc."


tload / tstore support

There are 2 new mnemonics (tload, tstore) as of solidity 0.8.24, related to the transient storage. Wake LSP states the functions aren't found. It would be fine, but the errors prevent using LSP features across the related contracts.

Setting the evm_version works for me. Thank you, didn't realize it can be the case!


Normalized Taylor Diagram

Pull Request Checklist:

[ ] This PR addresses an already opened issue (for bug fixes / features)

This PR fixes #xyz

[x] (If applicable) Documentation has been added / updated (for bug fixes / features).
[ ] (If applicable) Tests have been added.
[x] CHANGELOG.rst has been updated (with summary of main changes).

[x] Link to issue (:issue:number) and pull request (:pull:number) has been added.

What kind of change does this PR introduce?

A new type of Taylor diagram with normalized standard deviation is added

Does this PR introduce a breaking change?

Yes, fg.taylordiagram would return fig, floating_ax, legend instead of just floating_ax

Other information:
See fig.6
Since the std is transformed to be unitless (divided by the reference std), we can now compare taylor diagrams which have a different reference. The code accepts datasets with supplementary dimensions (max. 2).
Regarding the breaking change, it could be avoided. But, as things are right now, it's hard to modify the plot only with floating_ax but fig.legend() is used to generate the legend. I think it makes sense that fg.taylordiagram should return more objects, regardless of fg.normalized_taylordiagram.
Also, fg.normalized_taylordiagram could also just be an option of fg.taylordiagram. But I wanted to allow a new kind of DataArray with this plotting scheme, that is: a da with dimensions taylor_params, [dim_1], [[dim_2]], so two additional dimensions can be given. I just didn't to another type of data in the same mix of fg.taylordiagram and more options to the simpler methods fg.taylordiagram, but it might be better to keep this all in one place

A small artificial example:
import figanos.matplotlib as fg
import xarray as xr
from xclim import sdba
from xclim.testing import open_dataset

ds = open_dataset("sdba/CanESM2_1950-2100.nc").sel(time=slice("1950", "2013"))
ds2 = open_dataset("sdba/ahccd_1950-2013.nc")
ds["pr"] = ds2["tasmax"]
ds2["pr"] = ds["tasmax"]
da = sdba.stack_variables(ds.rename({"pr":"tasmax_2"}))
da2 = sdba.stack_variables(ds2.rename({"pr":"tasmax_2"}))
out = sdba.measures.taylordiagram(ref=da, sim=da2, dim="time")
fg.normalized_taylordiagram(out, markers_dim="location", colors_dim="multivar")

Thanks Eric for the new plotting function!
Do you think it would be possible to incorporate normalized_taylordiagram into taylordiagram by adding an argument normalized=T/F and allowing multi dimensions data in taylordiagram or are the two functions too different?

if extra dimensions (other than taylor_params), then fg.taylordiagram will create more entries in the dictionnary, every distinct coord gets it key. e.g. data = {"da1":da1, "da2":da2} where da1,da2 have an extra loc dim, this will become:

data = {
"da1_loc1":da1.sel(loc="loc1"),
 "da1_loc2":da1.sel(loc="loc2"),
 ...
 "da2_loc1":da2.sel(loc="loc1"),
 "da2_loc2":da2.sel(loc="loc2"),
 ...
}

and if it's not normalized, then we simply get the same error as before, stating that ref_std need to be equal.

colors_key and markers_key indicate what the colors and markers distinguish, this can either be a dimension in the arrays, e.g. markers_key = "loc", or an attribute in the datasets. If nothing is specified, then each key in data get its own marker as before.

There are many ways to use the function now to achieve similar results:
import figanos.matplotlib as fg
from xclim.testing import open_dataset
from xclim import sdba
import xclim
import numpy as np
ds = open_dataset("sdba/CanESM2_1950-2100.nc").sel(time=slice("1950", "2013"))
ds2 = open_dataset("sdba/ahccd_1950-2013.nc")
for v in ds.data_vars:
    ds2[v] = xclim.core.units.convert_units_to(ds2[v], ds[v], context="hydro")
da = sdba.stack_variables(ds)
da2 = sdba.stack_variables(ds2)
out = sdba.measures.taylordiagram(ref=da, sim=da2, dim="time")
out[{"taylor_param":[0,1]}] = out[{"taylor_param":[0,1]}]/ out[{"taylor_param":0}]
# precip gives negatives correlations, just for plotting purposes
out[{"taylor_param":2}] = np.abs(out[{"taylor_param":2}])

# 1, old way of organizing points, with dimensions
fg.taylordiagram(out)

# 2, new way of organizing points, with dimensions
fg.taylordiagram(out, colors_key="multivar", markers_key="location")

# 3,  old way of organizing points, with dict
outs = out.stack(dimm=list(set(out.dims) - set(["taylor_param"])))
dd = {"-".join(v): outs.sel(dimm=v) for v in outs.dimm.values}
fg.taylordiagram(dd)

# 4,  new way of organizing points, with dict
outall = out.stack(dimm=list(set(out.dims) - set(["taylor_param"])))
dd = {"-".join(v): outs.sel(dimm=v) for v in outs.dimm.values}
for k in dd.keys():
    dd[k].attrs["attr_multivar"] = dd[k]["multivar"].values.item()
    dd[k].attrs["attr_location"] = dd[k]["location"].values.item()
fg.taylordiagram(dd, colors_key="attr_multivar", markers_key="attr_location")

# 5,  old way of organizing points, mix dims/dict
dd = {v: out.sel(multivar=v) for v in out.multivar.values}
fg.taylordiagram(dd)
# 6,  new way of organizing points, mix dims/dict
dd = {v: out.sel(multivar=v) for v in out.multivar.values}
for k in dd.keys():
    dd[k].attrs["attr_multivar"] = dd[k]["multivar"].values.item()
fg.taylordiagram(dd, colors_key="attr_multivar", markers_key="location")

which all give:
old way of organizing points

new way of organizing points

I know there's a "spiro.mplstyle" in figanos, should this be used by default when using a figanos plot? I just coded color dimensions as "C0", "C1", ... but it seems to use default python colors and not default figanos colors.

If you run the ouranos matplotlib stylesheet at the start of your code it should automatically use the figanos colors as it overwrites matplotlib default unless you directly write the color in your code.

You could also add your new example to the docs instead of the old taylordiagram!

No i don't remember discussing it with Alexis when he made the function

I have a cheap way of having multiple Taylordiagram together. Just allow fig as an input, and also allow to define subplot_num. I don't think it's a nice way to do things, but still I wanted to showcase what small tweak can achieve, I was using this for my project:
for iloc, loc in enumerate(out.location.values):
    # after first run, use the previous figure
    fig = None if iloc==0 else fig
    fig, ax,_ = fg.taylordiagram(out.isel(location=iloc), subplot_num=131+iloc, fig=fig, fig_kw={"figsize":(14,4)})
    ax.set_title(f"{loc}")

(you can remove the old section taylor diagrams)

oops, I missed that part on my first read. Well, I've modified the already existing example, it's more simple and doesn't use random values, I think it's clean as it is. I like the examples as they are now.

You could also add your multi plot examples in figanos_multiplots

This was just showcasing what I can do with my own custom
fig, ax, leg = fg1.taylordiagram(out1, fig = None, subplot_num=131)
fig, ax, leg = fg1.taylordiagram(out2, fig = fig, subplot_num=132)
fig, ax, leg = fg1.taylordiagram(out3, fig = fig, subplot_num=133)

it doesn't require a lot of changes, but I thought it was a bit hacky for a solution. If fig, subplot_num are not specified, then we have the normal behaviour. Come to think of it, I saw the warning:

        warnings.warn(

            "Only figsize and figure.add_subplot() arguments can be passed to fig_kw when using facetgrid."
        )

in some other functions. Is the figure.add_subplot() supposed to achieve something similar to what I'm doing above?

It works by passing the args to xarray facetgrid.add_subplot() and without facetgrid you can also send it to matplotlib.pyplot.figure.add_subplot(). So if I understood correctly, the end result would be the same, but your subplot_num is more evident and requires less nested dictionaries.

I will try to add a proper FacetGrid support in another PR, this one is mostly ready to go.
I added the possibility with ref_std with ref_std_line (True/False) argument. It takes the same color as the reference marker:

No legend entry for this new line. rmse are a bit less evident, but in this case I think it's clear that the line represents ref_std, yes?
Color: Same a marker for reference

If that's all right I'll merge the branch


Will the support of Dingtalk be considered？

Gitea version (or commit ref):  e22be08
Git version:  git version 2.13.5
Operating system:
Docker / Alpine
Database (use [x]):

[X] PostgreSQL
[ ] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[ ] No
[X] Not relevant

Log gist:

Description
Many companies use Dingtalk in the company, of course, we are also using it. We really hope that Gitea can support it. Recently, Gogs has already supported Dingtalk's Webhook. We have used Gitea as a repository, but it has not yet been supported.
Screenshots
The Gitea webhook menu！

The Gogs webhook menu！

has been resolved via https://github.com/go-gitea/gitea/pull/2777, will release in v1.4


No contact form

Removed the Contact Form. Contact Information is displayed.

Removed the Contact Form. Contact Information is displayed.


Is there a good way to output log events to console?

Currently all the provided options for logging I could find in the Wiki and in the readme are to a separate log file. Is there a built in way to log all event messages to stdout?
Thanks
edit: Im trying to find a good way to differentiate between when a chat message is a bot command and not?  The best I could figure out so far is -
[15:51:04] event - hosting
[15:51:11] event - chat
[15:51:16] event - chat
[15:51:40] event - chat
[15:51:44] event - chat

Thank you for posting this, it is not possible with the current version but I guess we could add this feature for the next version. Currently, the debug option shows which event is being fired (hosting 1 time and chat 4 times in your example).
You said you are trying to differentiate between a chat message or a bot command, why not just checking if the first character is "!" in your chat event ?
client.addListener('chat', function (channel, user, message) {
    if (message.indexOf('!') === 0) {
        // Might be a command..
        //console.log(message);
        var parts   = message.split(' ');
        var command = parts[0];
        if (command === '!hello') {
            // Do something
        }
    }
});

Thanks @Schmoopiie. If I get a chance I may add a pull request so bot responses are also outputted to console.

Sure thing, PR are welcome! Just make sure you send the PR to the 1.1.1b branch.
Thank you!

I'm trying to read through your code. Is there an obvious reason as to why the debug isnt catching what the bot responds with? I would think it would console log every chat message it sees in IRC.

Twitch doesn't really follow the IRC Reference, you would need to modify the socket crlfWrite which is used to send messages to the server (maybe catch PRIVMSG or something..).

There is a callback for most of the commands in the beta, but it was a pain in the *** to do this with Twitch. Most callbacks are sent 250ms late because it is waiting for the JTV response to the command. There is no callback to the .say command because we can't even see our own message, we can only suppose it was sent. Unless we create another connection but it's not a good idea.
Actually the callback of .say is if you can't say something on a channel (any kind of restrictions), but we cannot catch if our own message was sent properly.

I'm dumb, you can actually catch your own message, make sure the messageFrom is equal to the bot's username in the _handleMessage. Use console.log(message); and you will see how we receive messages. It wasn't possible before (when it was node-twitch-irc) but now we can.

That is what I currently do. The problem is if the bots username is also the broadcasters username then all messages are logged to the console. Is there just a way to just console log the message in client.say?
/**
 * Say something on a channel.
 *
 * @params {string} channel
 * @params {string} message
 */
client.prototype.say = function say(channel, message, cb) {
    console.log(message);
    if (this.socket !== null) { this.socket.crlfWrite('PRIVMSG ' + Utils.addHash(channel).toLowerCase() + ' :' + message); }
    if (typeof cb === 'function') { setTimeout(function() { CommandError !== '' && cb(CommandError) && cb(null); }, 250); }
};

/**
 * Say something on a channel (action).
 *
 * @params {string} channel
 * @params {string} message
 */
client.prototype.action = function action(channel, message, cb) {
    console.log(message);
    if (this.socket !== null) { this.socket.crlfWrite('PRIVMSG ' + Utils.addHash(channel).toLowerCase() + ' : \x01ACTION ' + message + '\x01'); }
    if (typeof cb === 'function') { setTimeout(function() { CommandError !== '' && cb(CommandError) && cb(null); }, 250); }
};

I thought you could something like this but it doesn't follow your templating system. It also might make sense to add response event.

The code above produces something like this:
[12:50:14] raw   - 366: #eyeswl
Hey eyeswl! How you doing? Kappa
[12:51:08] chat  - [#eyeswl] eyeswl: !hello

If I just need to get it to follow your templating system and show up in the correct order.

Can you try this update ? I tested it and it works now.. don't forget to add debugDetails: true in your options.

Awesome thank you :+1:

What are you hoping to add in a 1.2 release? If you need any help please let me know.

Right now I am almost done with 1.2.0 .. just waiting for Twitch to make it official with their IRCv3 tags.. I already planned the next version which will offer rates limit support and some kind of a flood protection (an interval for the .say/.action commands) to prevent the bot from spamming.
Anyways, from the changelog: (No links available because I'm not done with the documentation, which will be available on my website instead of GitHub)
v1.2.0

Action command to send action messages. (/me <message>)
Added autoRejoin option to rejoin the exact same channels when reconnected.
Added a command listener. (might be improved in the next version of twitch-irc)
Added debugDetails to show additional debug informations.
Added subanniversay event.
Added mod and unmod listeners.
Better handling of Twitch restrictions/limitations.
Capitalize utils which can also grab the username from the Twitch API for correct capitalization.
Color command to change the color of the username.
Commands listener.
Commands now sends an optional callback.
Custom logger with timestamp and colors.
CLI is now available; the module needs to be installed with --global. (we will improve this in the next version of twitch-irc)
Fixed symbols utils.
IRCv3 tags support.
New function .isMod(channel, username) to find out if username is moderator.
OAuth event listener.
OAuth hostname can now be changed.
OAuth redirect after success/failure is now customizable.
OAuth web template is now customizable.
Optimized the code.
Updated the wiki to provide better documentation.
Removed listeners limit, no more warning.

:+1:

Don't hesitate to post your ideas here or if you want to contribute to this project you're welcome :smile:

Will do.


Add code for different types of dependency injections in an OSGi service.

Test comment.

Need to cover constructor, field and bind methods injection.


[Fix #12876] Fix lockfile parsing if only the gemfile exists

Fixes #12876
If a gemfile exists a lockfile path will be returned, even if no lockfile exists.

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Thanks!


tmt-reboot does not work outside of execute step, i.e. in prepare/finish

tmt-reboot assumes it's running in the context of a test, but that's not true in prepare or finish. Plus there is no code in prepare or finish plugins that would be able to handle reboot and restart the phase.

watching
relates to: VROOM-18747

Isn't this duplicate of #902 ?

Hm, I it, I was unable to find it.


Remix errors when the data-build/routes folder is missing

Details
I'm setting up a new project and I haven't defined any route data yet. Running tsc -b generates the data-build folder, but not the routes subfolder because there are no files yet.
Running npm run dev gives the following error:
[0] Error: ENOENT: no such file or directory, scandir '...project path...\data-build\routes'
[0]     at Object.readdirSync (node:fs:1044:3)
[0]     at visitFiles (...project path...\node_modules\@remix-run\core\routesConvention.js:109:47)
[0]     at Object.defineConventionalRoutes (...project path...\node_modules\@remix-run\core\routesConvention.js:69:3)
[0]     at Object.readConfig (...project path...\node_modules\@remix-run\core\config.js:51:35)
[0]     at Object.run (...project path...\node_modules\@remix-run\core\commands.js:36:31)
[0]     at Object.<anonymous> (...project path...\node_modules\@remix-run\cli\index.js:47:19)
[0]     at Module._compile (node:internal/modules/cjs/loader:1108:14)
[0]     at Object.Module._extensions..js (node:internal/modules/cjs/loader:1137:10)
[0]     at Module.load (node:internal/modules/cjs/loader:973:32)
[0]     at Function.Module._load (node:internal/modules/cjs/loader:813:14)
[0] remix run exited with code 1

From digging into @remix-run/core/routesConvention.js it looks like adding an fs.existsSync(dir) check to visitFiles would be enough to handle the error (and maybe add a console warning to indicate that the directory couldn't be found).

Not applicable anymore


center Click Me button

This is a fix for #89.

I'm abandoning this pull request because it is included in pull request #96.


Add materials bin tests

I was planning to use more Jasmine tests, but I finally I added mainly Cucumber integration tests.
I think in this case integration tests are even more useful, as this feature probably is not expected to be under active development (when small unit tests could help). Cucumber is slower, but I could avoid extensive mocking of everything and simulating browser events in Jasmine. I also couldn't find a pattern that I liked for Jasmine tests in this case - comparing rendered string seems to be pretty inflexible (blocks every single change in component) and has obvious limits, regexp could be too flexible and it's not very handy. I could use jQuery and write manual DOM matchers, but in that case I prefer to use Capybara.

Just an FYI but if you look at the react_helpers.js file I added there is a set of nice React tools for isolated testing, including simulating events.  I basically added shortcuts to these functions:
https://facebook.github.io/react/docs/test-utils.html
The pure string comparison was just there at the start to have something for Jasmine to test to make sure it worked on Travis.

Right, I've noticed your helpers and even used them. But still, React helpers are pretty limited when compared to Capybara (which is not surprising, as they're designed for different scope of testing). For example I mainly wanted to test if given DOM element was rendered, visible and had some text.
Re string comparison - sure, not saying it's bad in general, it's useful in some cases. But it wouldn't work for tests I was imagining. In general I would use Jasmine for unit testing, but here I mostly wanted integration tests.

This is fine to merge from my point of view.

Removed unnecessary 'it', so I'm merging it.


Add autoconfiguration for ReactivePulsarConsumerFactory

DON'T MERGE: need #178 to be merged before

DON'T MERGE: need #175 and #178 to be merged before

@cbornet
The actual changes to here are small (once you rebase on #175 and #178) and from 1st glance looks like it will be merged immediately after its dependencies are.

Closed via https://github.com/spring-projects-experimental/spring-pulsar/commit/75eb350cd059f516dd3d35e8d081195a722cdecf


discoverd: Register

Incremental patch towards getting rid of sdutil.
/cc @titanous

All statements are covered except Addr(), which I added to satisfy the heartbeater interface.

@titanous Everything addressed, also added a test for Addr(), so we now have 100% coverage.

Okay, LGTM. Make sure you've rebased on master before merging.


implement exponential decay curve

This PR introduces a new curve ExponentialDecay in the referenda pallet. For the implementation we rely on Encointer's substrate-fixed, which provides efficient fixed point numbers and implements transcendental functions like exp and log.
Changes at unrelated locations in the code were necessary because substrate-fixed introduces some conflicting impls and  we got errors along the lines of
type annotations needed
multiple impls satisfying usize: PartialOrd<_> found in the following crates: core, substrate_fixed

@shawntabrizi @kianenigma as discussed at parachain summit
full disclosure : I asked @pifragile to implement this PR as a tangible demonstration of substrate-fixed because we would very much like to have the substrate-fixed crate included in the substrate/polkadot codebase or parity-common - and have its primitives supported by ecosystem tools like js/apps
On the topic of this PR: After discussing Gov2 ideas with @joepetrowski, I had the strong feeling that linear curves will not be satisfactory. Non-linear curves for approval and turnout thresholds will be much more powerful and much closer to the behaviour we actually desire.
Of course, piecewise-linear curves are an option, but they offer worse dev experience when setting them up and they naturally come with discontinuities of the first derivative. (Taking the example of bitcoin mining rewards, such discontinuities can cause a lot of unnecessary turbulence).
With this PR, it is possible to define smooth curves with reasonable computational complexity with only few easy-to-understand parameters:

starting point
offset
halving-time (relative to decision period)

@pifragile please fix the reported CI errors

note that I think the first step in this is: https://github.com/paritytech/substrate/issues/12040, and then we can re-export fixed from common or sp-arithmetic.
I am not the best person to judge of the change to the referendum pallet is sensible, but I will have a look.

Waiting for #12509

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:
https://forum.polkadot.network/t/community-suggestions-and-requests-for-the-opengov-model-on-kusama/1179/6

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:
https://forum.polkadot.network/t/community-suggestions-and-requests-for-the-opengov-model-on-kusama/1179/7

not sure how to move on, still waiting for https://github.com/paritytech/substrate/pull/12509

note that I think the first step in this is: #12040, and then we can re-export fixed from common or sp-arithmetic.
I am not the best person to judge of the change to the referendum pallet is sensible, but I will have a look.

As #12040 has been aborted, is there another way to move ahead with substrate-fixed?
If not for this PR, it still would be valuable for us to see support in this codebase and I still believe the implementation is more computationally efficient than the current one, but benchmarking that is an effort we can't currently do.


[Bug]: Kafka container fails to start after upgrade to 1.19.1

Module
Kafka
Testcontainers version
1.19.1
Using the latest Testcontainers version?
Yes
Host OS
Linux
Host Arch
x86
Docker version
Client: Docker Engine - Community
 Cloud integration: v1.0.23
 Version:           24.0.7
 API version:       1.43
 Go version:        go1.20.10
 Git commit:        afdd53b
 Built:             Thu Oct 26 09:08:01 2023
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          24.0.7
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.10
  Git commit:       311b9ff
  Built:            Thu Oct 26 09:08:01 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.24
  GitCommit:        61f9fd88f79f081d64d6fa3bb1a0dc71ec870523
 runc:
  Version:          1.1.9
  GitCommit:        v1.1.9-0-gccaecfc
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

What happened?
I'm trying to upgrade Micronaut Test Resources to test containers 1.19.2.
After this upgrade, one test is failing with:
Unexpected handshake request with client mechanism PLAIN, enabled mechanisms are [] (see https://github.com/micronaut-projects/micronaut-test-resources/actions/runs/6842478040)
This happens whenever on a test which requires to set an environment variable on the container:
https://github.com/micronaut-projects/micronaut-test-resources/blob/e527b06ac452e5c63348418386b5f24b899c377d/test-resources-kafka/src/test/resources/application-custom.yml#L6
So this all behaves as if the environment variable was ignored in 1.19.1. It also happens with 1.19.0, but the test passes with 1.18.3.
Relevant log output
No response
Additional Information
No response

Thanks for the report, @melix. It was fixed in https://github.com/testcontainers/testcontainers-java/pull/7748 and I have also added some tests related to sasl https://github.com/testcontainers/testcontainers-java/pull/7763. This is not released yet, but it will be soon.


Products page

Shehzad bhai this pull request is going to merge with master, instead of master merge with dev

This should have been on dev rather.


Fix 'among' doc link in std.algorithm.searching

I will rebase this to stable, s.t. it will be released on dlang.org soon.


Mention num_occurrences in docs for dimod.Response

It's not clear from the docs how to get num_occurrences, alongside list of samples.
User's comment here.

num_occurrences is a sampler-specific data field, not in general for dimod Samplers. We could consider making is a required data field as it has come up in multiple cases.

Adding something like this to dimod.Response docs would also help:
>>> list(response.data())
[Sample(sample={0: -1}, num_occurrences=52, energy=0.0),
 Sample(sample={0: 1}, num_occurrences=48, energy=0.0)]

@randomir @arcondello
Should we make num_occurrences required for the next backwards compatibility update?
I see the arguments as follows. Making it optional means more flexibility for wrapping solvers and less overhead (no need to compute the histogram). The downside is less uniformity in the responses from different samplers, and that len(response) may or may not be equal to the num_samples/num_reads parameter. One other downside I can think of is that if it is required, the samples returned lose their "time-dependence" which I can see being important for the QPU and maybe other solvers.
While it would be possible to require num_occurrences and then allow the samples to be non-unique (so you could take your existing sampler, and just set num_occurrences=1 for every returned sample), I would argue this will be too confusing as the name and current usage in the ecosystem implies that what's returned is a proper histogram.
I think the best solution is to make num_occurrences required, and to provide a decorator which builds the histogram if the user needs it when making a sampler.
This is perhaps tangential, but I think we should also consider standardizing the num_samples/num_reads parameter. I understand that this parameter does not apply for some solvers, and so should remain optional, but it's such a common parameter that I think there should be just one way to do it. Maybe this just means stating this in the docs for how to make a sampler (i.e. "If your sampler takes an argument that specifies how many samples to return, use num_reads"). Another option could be to have another ABC that requires num_reads.

And while we're on topic of long-term planning/breaking compat/renaming stuff -- why not call that property simply histogram?
:+1: for standardizing names across API (I believe num_reads is inherited from SAPI/QS).
The need for pre/post-processing of parameters/responses from SAPI has already come up several times (e.g. here: https://github.com/dwavesystems/dwave-cloud-client/issues/199), and that seems to be the direction which makes most sense (in terms of API flexibility, unification and faster development).

Made required in #243 .
I agree we should standardise num_reads/num_samples. I think by dint of longevity num_reads is the winner.


Upgrade to Chromium 80.0.3987.162

Chromium 80.0.3987.162 fixes 8 security vulnerabilities. I will let you know once I have a successful build.

My build succeeded. Feel free to merge.


Delete non-ghcide options from coc.nvim example

These options don‘t work with ghcide as far as I can tell. I believe they stem from copying the config used for hie-wrapper. As ghcide does not support hlint yet I believe this infos to be misleading. That‘s why I suggest deleting it.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Update to rule permalinks

This is necessary because of https://github.com/sqlfluff/sqlfluff/pull/6052 (which broke the current links) and relies on https://github.com/sqlfluff/sqlfluff/pull/6066 (to enable rule permalinks).
We should probably do a coordinated release of both the plugin and SQLFluff core so these go live at roughly the same moment. I'm likely to do a SQLFluff release later this week so that might be a good moment.

@alanmcruickshank Sounds good, let me know when you want this merged/released and I can do that

Let's merge it now, but then release shortly after we get the SQLFluff release out. I'll stage that today, and then hopefully get it shipped tomorrow.

@RobertOstermann I've just shipped the relevant core sqlfluff release. Any chance you could cut a new release for the VSCode plugin fairly soon? That will prevent anyone raising a bug over the links not working anymore.

@alanmcruickshank Publishing now with v3.2.0


Update sbt, scripted-plugin to 1.9.9

About this PR
📦 Updates

org.scala-sbt:sbt
org.scala-sbt:scripted-plugin

from 1.7.3 to 1.9.9
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
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 = "org.scala-sbt" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scala-sbt" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, version-scheme:early-semver, commit-count:1

Superseded by #131.


Log window

It would be great if I could make the log window larger. Also would be nice if I could filter the log window in the portal with similar logic that I can use when I am streaming logs in Visual Studio to pick out specific string patterns.

Thanks for the feedback. Something we've definitely talked a bit about already.

Implemented now :)


CAMEL-11531 - set servlet dependency as provided

Merged #1836

Oh this causes the spring-boot starter to fail.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile (default-compile) on project camel-servlet-starter: Compilation failure
[ERROR] /Users/davsclaus/workspace/camel/platforms/spring-boot/components-starter/camel-servlet-starter/src/main/java/org/apache/camel/component/servlet/springboot/ServletMappingAutoConfiguration.java:[43,16] cannot access javax.servlet.http.HttpServlet
[ERROR]   class file for javax.servlet.http.HttpServlet not found
Maybe that starter need some special logic to mark the servlet api as required or something so it can compile

Just a heads up, that I reverted this on master branch until we find a working solution.

i'll reopen the issue and check.

Okay so this works now, then feel free to merge to master