CompletableFuture DeadlineExceededException

Hello!
I hesitate to file this report as I'm mostly looking for guidance on ways to mitigate this error or avoid it altogether.
I am creating an ExecutorService fixed thread pool and submitting CompletableFuture objects to it. These CompletableFutures each may create their own GoogleAdsClient via the newBuilder() method.
Skeleton code:
final ExecutorService rsPool = Executors.newFixedThreadPool( 3 );
final List<CompletableFuture> futures = Lists.newArrayList();
futures.add( CompletableFuture.completedFuture( rsFuture ).thenComposeAsync( this::processFuture, rsPool ) );
futures.forEach(  CompletableFuture::join );
final GoogleAdsClient googleAdsClient = GoogleAdsClient.newBuilder()
.setCredentials( credentials )
.setDeveloperToken( devToken )
.setLoginCustomerId( loginCustomerId )
.build();
I am not able to replicate the error with any sort of regularity, but sometimes these futures fail with the following error:
Caused by: com.google.api.gax.rpc.DeadlineExceededException: io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: deadline exceeded after<PHONE_NUMBER>000ns. [buffered_nanos=63573020, buffered_nanos=96300251, remote_addr=googleads.googleapis.com/<IP_ADDRESS>:443]
Full stack trace pasted at the bottom of this report.
These GoogleAdsClient instances always create GoogleAdsServiceClient objects via the try-with-resources mechanism.
Should I be caching and re-using ( for a short time frame ) the constructed GoogleAdsClient objects?
Any other best practices to help sidestep this error?
Thanks
Pete
Which version of the client library are you using?
com.google.api-ads:google-ads:5.1.0
Which version of Java are you using?
openjdk version "1.8.0_201"
OpenJDK Runtime Environment (build 1.8.0_201-b09)
OpenJDK 64-Bit Server VM (build 25.201-b09, mixed mode)
Which operating system (Linux, Windows, ...) and version?
Linux ip-172-31-154-182 4.14.133-88.105.amzn1.x86_64 #1 SMP Thu Jul 11 00:44:15 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Caused by: com.google.api.gax.rpc.DeadlineExceededException: io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: deadline exceeded after<PHONE_NUMBER>000ns. [buffered_nanos=63573020, buffered_nanos=96300251, remote_addr=googleads.googleapis.com/<IP_ADDRESS>:443]
at com.google.api.gax.rpc.ApiExceptionFactory.createException(ApiExceptionFactory.java:51)
at com.google.api.gax.grpc.GrpcApiExceptionFactory.create(GrpcApiExceptionFactory.java:72)
at com.google.api.gax.grpc.GrpcApiExceptionFactory.create(GrpcApiExceptionFactory.java:60)
at com.google.api.gax.grpc.GrpcExceptionCallable$ExceptionTransformingFuture.onFailure(GrpcExceptionCallable.java:97)
at com.google.api.core.ApiFutures$1.onFailure(ApiFutures.java:68)
at com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1039)
at com.google.common.util.concurrent.DirectExecutor.execute(DirectExecutor.java:30)
at com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:1165)
at com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:958)
at com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:749)
at io.grpc.stub.ClientCalls$GrpcFuture.setException(ClientCalls.java:520)
at io.grpc.stub.ClientCalls$UnaryStreamToFuture.onClose(ClientCalls.java:495)
at io.grpc.PartialForwardingClientCallListener.onClose(PartialForwardingClientCallListener.java:39)
at io.grpc.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:23)
at io.grpc.ForwardingClientCallListener$SimpleForwardingClientCallListener.onClose(ForwardingClientCallListener.java:40)
at com.google.ads.googleads.lib.logging.LoggingInterceptor$1$1.onClose(LoggingInterceptor.java:111)
at io.grpc.PartialForwardingClientCallListener.onClose(PartialForwardingClientCallListener.java:39)
at io.grpc.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:23)
at io.grpc.ForwardingClientCallListener$SimpleForwardingClientCallListener.onClose(ForwardingClientCallListener.java:40)
at io.grpc.internal.CensusStatsModule$StatsClientInterceptor$1$1.onClose(CensusStatsModule.java:700)
at io.grpc.PartialForwardingClientCallListener.onClose(PartialForwardingClientCallListener.java:39)
at io.grpc.ForwardingClientCallListener.onClose(ForwardingClientCallListener.java:23)
at io.grpc.ForwardingClientCallListener$SimpleForwardingClientCallListener.onClose(ForwardingClientCallListener.java:40)
at io.grpc.internal.CensusTracingModule$TracingClientInterceptor$1$1.onClose(CensusTracingModule.java:399)
at io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:510)
at io.grpc.internal.ClientCallImpl.access$300(ClientCallImpl.java:66)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.close(ClientCallImpl.java:630)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl.access$700(ClientCallImpl.java:518)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInternal(ClientCallImpl.java:692)
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:681)
at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)

It's most likely that you're getting DEADLINE_EXCEEDED from the API because the RPC is timing out. Our default deadline is 60 minutes. What operations are you running here? Are they long running?

You can also override the deadline by specifying a GrpcCallContext on each API call. For example:
try (CampaignBudgetServiceClient campaignBudgetServiceClient =
        googleAdsClient.getLatestVersion().createCampaignBudgetServiceClient()) {
      MutateCampaignBudgetsResponse response =
          campaignBudgetServiceClient
              .mutateCampaignBudgetsCallable()
              .call(
                  request,
                  GrpcCallContext.createDefault()
                      .withCallOptions(
                          CallOptions.DEFAULT.withDeadline(Deadline.after(10, TimeUnit.HOURS))));

Hi Nick,
In this instance all of the operations are GoogleAdsServiceClient search requests. None of the operations are long running.
try ( final GoogleAdsServiceClient googleAdsServiceClient = googleAdsClient.getLatestVersion().createGoogleAdsServiceClient() ) {
            final GoogleAdsServiceClient.SearchPagedResponse searchPagedResponse = googleAdsServiceClient.search( request );

            return Lists.newArrayList( searchPagedResponse.iterateAll());
        }

Pete

It's very possible to have a search request take longer than 1 hour to complete. It might be a good idea to check how long these requests actually take to execute. Is it possible that you have some query + account combinations that exhibit worst-case behavior? The GAS.search() server will first materialize the entire result set, prior to returning the response.
Also consider whether you actually need all the data that you're requesting. Adding a filter for e.g. LAST_7_DAYS could considerably speed up your queries.
As an aside, it's worth considering switching these over from the paging API -> streaming API. This includes useful primitives for running async/non-blocking processing.

I can say with 100% certainty that the queries we're running do not take over an hour to complete.
This problem only arose when we migrated to the async / thread pool implementation.
I'll look into the streaming API
Thanks
Pete

It could also be that there's an ongoing outage on our side. I'd suggest starting a thread on the forum to check.
I'm guessing if this is related to threading issues, that the streaming API should solve this. However, there shouldn't be any issue with reusing the GoogleAdsClient across threads, as you mention. Nor should there be any issue with creating many new GoogleAdsServiceClients. Please let me know if one of these actually fixes the problem, since this would point towards there being an issue with our library.

Nick,
I've implemented the Streaming API and will report back after a few days of data collection.
This async process is part of a job that runs overnight for thousands of distinct CIDs and our DeadlineExceeded error rate before was about 4.7%.
Does the following code adhere to current best practices? We're not interested in working with subsets of the complete data which is why we iterate, add to collection, and then return the entire dataset.
final List<GoogleAdsRow> rows = Lists.newArrayList();

final ServerStream<SearchGoogleAdsStreamResponse> stream = googleAdsServiceClient.searchStreamCallable().call( request );

for( final SearchGoogleAdsStreamResponse response : stream ) {
    rows.addAll( response.getResultsList() );
}

return rows;

Thanks
Pete

Yes, what's there looks good. I can't see the creation of the googleAdsServiceClient, so FYI this should be (1) closed via AutoClosable and (2) reused between threads.
I'd like to take a look at the requests on our server to see if there's anything clearly broken there. Could you share a couple of the CIDs that you were seeing deadline exceeded errors on please?
Also, you can enable full logging from the gRPC stack by setting the level for io.grpc=ALL. Can you take a look there and see if there's anything to explain this? Be careful if you post anything here since this will contain unredacted credentials.

When getting the CIDs for you I noticed that all the stack traces I inspected were coming from code where we are searching for Campaign Criterion or AdGroup Criterion. This is something I missed when reporting the original "bug".
Here are 3 CIDs that failed with DeadlineException on 6/19/2020 between the hours of 1am EST and 4am EST.
2519278641
3001010842
2513464472

Regarding the code, we are grabbing the GoogleAdsServiceClient via try-with-resources so yes should be AutoClosable.
try ( final GoogleAdsServiceClient googleAdsServiceClient = googleAdsClient.getLatestVersion().createGoogleAdsServiceClient() ) {
    //
    streamCallable.call( request )
    //

}

However, regarding "(2) reused between threads", our GoogleAdsClient is newly constructed each time we make it to this point in the code.
Broadly:
final ExecutorService rsPool = Executors.newFixedThreadPool( ASYNC_POOL_SIZE );
final List<CompletableFuture> futures = Lists.newArrayList();
futures.add( getsCampaigns )
futures.add( getsAdGroups )
futures.add( getsAdGroupNegativeKeywords )
futures.forEach( CompletableFuture::join );
async( getCampaigns -> get new GoogleAdsClient().getLatestVersion().createGoogleAdsServiceClient() )
async( getAdGroups -> get new GoogleAdsClient().getLatestVersion().createGoogleAdsServiceClient() )
async( getAdGroupNegativeKeywords -> get new GoogleAdsClient().getLatestVersion().createGoogleAdsServiceClient() )
We're not re-using the same GoogleAdsClient between threads.
Going back to the fact that the problem seems to be stemming from Campaign Criterion and AdGroup Criterion searches, those queries are a bit gross from our side, in that we're asking for many / most fields across 4 different resources: Campaign, UserInterest, UserList and CampaignCriterion.
The queries are not different when using the paging API vs the streaming API, and I've only witnessed this error when doing the calls asynchronously, but perhaps this is some additional color that will give a better picture of what's going on.
I'll see if logging io.grpc=ALL turns up anything, but I probably won't have data back on that for at least a day or two as I have not been able to replicate this problem working locally and not in big batches.
Thanks
Pete

I checked our logs and don't see any evidence of DEADLINE_EXCEEDED being returned from the server side. In fact, the longest request was ~ 2 seconds (per page).
CampaignCriterion and AdGroupCriterion can potentially be very large queries. There can easily be millions of rows returned, and more if segments are used (linear in number of distinct fields in segments). It would be worth checking if the query actually executes server side, i.e. if you actually get rows back before the deadline is hit. Similarly, it would be good to check if 1 hour actually elapses between when you send the request and when the deadline is hit.
I've reported an issue with the middleware folks (GAX) to check if there's any best practices we're not following for multi-threading.

Nick,
I appreciate your continued effort to resolve this with us.
Using the Streaming API our DeadlineExceeded error rate last night was 0.5%. This compares to a 4.7% error rate on the Paging API the night before. The same accounts and the same queries were issued both nights.
4140203075 is a CID with a DeadlineExceeded error last night.
I did confirm that the error does throw 1 hour after the request is issued:
2020-06-23 07:15:05,394 INFO  Asynchronous : Ad Schedules
2020-06-23 08:15:05,430 ERROR
java.util.concurrent.CompletionException: java.lang.RuntimeException: java.lang.RuntimeException: com.google.api.gax.rpc.DeadlineExceededException: io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: deadline exceeded after<PHONE_NUMBER>897ns. [buffered_nanos=63037051, buffered_nanos=78498570, remote_addr=googleads.googleapis.com/<IP_ADDRESS>:443]

I should note here that after the async call for Ad Schedules ( Campaign Criterion ) at 07:15 was issued, there were other async search calls for the same CID ( but different queries ) issued afterwards that did respond successfully in a timely manner.
All search queries construct a new GoogleAdsClient that in turn makes the try-with-resources createGoogleAdsServiceClient() call.
The following is munged down, but with minimal and irrelevant hand waving. Every search call goes through:
public List<GoogleAdsRow> search( final Long ourCustomerId, final Long googleCID, final String query ) {

    final ApiCredentials apiCredentials = getApiCredentialsByCustomerId( ourCustomerId );

    final Credentials googleCredentials = UserCredentials.newBuilder()
            .setClientId( apiCredentials.getClientId() )
            .setClientSecret( apiCredentials.getClientSecret() )
            .setRefreshToken( apiCredentials.getRefreshToken() )
            .build();

    final GoogleAdsClient googleAdsClient =  GoogleAdsClient.newBuilder()
            .setCredentials( googleCredentials )
            .setDeveloperToken( apiCredentials.getDeveloperToken() )
            .setLoginCustomerId( googleCID )
            .build();

    final SearchGoogleAdsStreamRequest request = SearchGoogleAdsStreamRequest.newBuilder()
            .setQuery( query )
            .setCustomerId( googleCID.toString() )
            .build();

    try ( final GoogleAdsServiceClient googleAdsServiceClient = googleAdsClient.getLatestVersion().createGoogleAdsServiceClient() ) {

        final List<GoogleAdsRow> rows = Lists.newArrayList();

        final ServerStream<SearchGoogleAdsStreamResponse> stream = googleAdsServiceClient.searchStreamCallable().call( request );

        for( final SearchGoogleAdsStreamResponse response : stream ) {
            rows.addAll( response.getResultsList() );
        }

        return rows;
    }
}

Thanks
Pete

So the comment from Igor on the GAX bug is very helpful. He points out that by running in this paradigm, we're effectively creating a new gRPC connection every time a service client is requested. This is bad for a number of reasons, but perhaps most importantly because if you create enough connections in parallel, it will be detected as a DOS attack and the packets will be dropped. This would explain why I didn't see any DEADLINE_EXCEEDED errors in the ads API logs -they could be dropped before getting to us.
A gRPC connection can handle 100 parallel requests. If you need more requests, you should create a new client. In your case, this translates to calling googleAdsClient.getLatestVersion().createGoogleAdsServiceClient(). Creating multiple GoogleAdsClients should be fine, it is creating the service clients which will open a new gRPC connection.

Nick,
Couple points of confusion here.
If we're to reuse the GoogleAdsServiceClient instances, how are to use the try-with-resources paradigm on googleAdsClient.getLatestVersion().createGoogleAdsServiceClient()?
If we don't have to use try-with-resources when creating the GoogleAdsServiceClient instances, is there a suggested TTL we should monitor on the cached GoogleAdsServiceClient instance?
Also, since the AccessToken is created on the GoogleAdsClient itself, and we're effectively disjoining the GoogleAdsClient and the GoogleAdsServiceClient instances by caching the GoogleAdsServiceClient instance, isn't there the possibility of us running into an OAuth issue if we run over the AccessToken expiry? I don't believe I have access to the AccessToken value on the GoogleAdsClient object so if I wanted to use that as part of my cache key I would be out of luck.
Thanks
Pete

Couple points of confusion here.
Apologies.

If we're to reuse the GoogleAdsServiceClient instances, how are to use the try-with-resources paradigm on googleAdsClient.getLatestVersion().createGoogleAdsServiceClient()?

No need to use try-with-resources. Just make sure you call GoogleAdsServiceClient.close() when you're done with the client.

If we don't have to use try-with-resources when creating the GoogleAdsServiceClient instances, is there a suggested TTL we should monitor on the cached GoogleAdsServiceClient instance?

The client should be good for the life of the process.

Also, since the AccessToken is created on the GoogleAdsClient itself, and we're effectively disjoining the GoogleAdsClient and the GoogleAdsServiceClient instances by caching the GoogleAdsServiceClient instance, isn't there the possibility of us running into an OAuth issue if we run over the AccessToken expiry? I don't believe I have access to the AccessToken value on the GoogleAdsClient object so if I wanted to use that as part of my cache key I would be out of luck.

It looks like you're using a refresh token. This will automatically regenerate an access token once the grant expires (every 60 minutes). gRPC will call Credentials.getRequestMetadata() which will request a new access token when the old one expires.
    final Credentials googleCredentials = UserCredentials.newBuilder()
            .setClientId( apiCredentials.getClientId() )
            .setClientSecret( apiCredentials.getClientSecret() )
            .setRefreshToken( apiCredentials.getRefreshToken() )
            .build();

OK cool ... and just to clarify the following:

No need to use try-with-resources. Just make sure you call GoogleAdsServiceClient.close() when you're done with the client.
The client should be good for the life of the process.

... that's essentially a green light to reuse the GoogleAdsServiceClient instances for very long times like days / weeks?
We don't enter situations where we need more than 100 concurrent gRPC requests, so essentially 1 GoogleAdsServiceClient instance to 1 CID would be our use case.
And lastly, what state do we enter if we have a bad shutdown or some other circumstance that doesn't allow us to GoogleAdsServiceClient.close()? On app restart and new googleAdsClient.getLatestVersion().createGoogleAdsServiceClient() instantiation we'd be good to go?
Thanks
Pete

So you have a separate credential for each customer ID? Then you effectively need O(num CIDs) clients since the credential is bound to the channel. In the example you gave earlier you'd save 3x client creation, is that going to be enough to meaningfully reduce the number of clients being created?

We do not have separate credentials for each customer ID, but we do have many credentials.
I intend to cache the serviceClient using the following key:
final String key = keyJoiner.join(
            googleAdsClient.getLoginCustomerId(),
            googleAdsClient.getDeveloperToken(),
            googleAdsClient.getCredentials().toString()
        );

The toString on the UserCredentials object includes the following details:
@Override
  public String toString() {
    return MoreObjects.toStringHelper(this)
        .add("requestMetadata", getRequestMetadataInternal())
        .add("temporaryAccess", getAccessToken())
        .add("clientId", clientId)
        .add("refreshToken", refreshToken)
        .add("tokenServerUri", tokenServerUri)
        .add("transportFactoryClassName", transportFactoryClassName)
        .toString();
  }

Ok, so that should bring the scale of the problem down. We should probably keep thinking about how to best handle the "worst case" scenario, but I'm guessing that if you have a relatively small number of credentials compared to the number of requests, this should bring your QPS back into the safe zone.
Worth mentioning that Igor points out that we can override the credentials on a per call basis. This should mean we can at least mitigate this entirely on the client side.

Cool. I will start in on this strategy.
A couple of out loud thoughts:
We received a DeadlineExceeded exception whereas it looks like it may have been the result of a QPS infraction. Is there client library work that could be done to make the true cause clearer?
We saw the same method calls ( search CampaignCriterion, search AdGroupCriterion ) as the origin points for every instance of this exception. The same list of search requests were put into the futures jobs in the same order each night, so perhaps when it got to those method calls we just happened to be at the QPS tipping point each time, but that seems a bit too tidy of an explanation.
In conjunction with that, we were making createGoogleAdsServiceClient() calls immediately before and immediately after the futures jobs for search CC and search AGC were joined and they returned fine. Wouldn't it be likely those would trigger QPS as well? Are there different limits for different resources?
Speaking of limits, this is interesting:
https://developers.google.com/google-ads/api/docs/best-practices/quotas

By default gRPC has a maximum message size of 4 MB. It's possible to exceed this limit; for example, a search request that includes a very high number of fields may generate a response that exceeds 4 MB in size

Requests that violate this limitation will not generate a GoogleAdsError. They will generate an error at the gRPC error with a 429 Resource Exhausted error.

"a very high number of fields" is definitely what I alluded to earlier with the fields / resources we request for the CC and AGC searches.
And finally, if it was a QPS issue, are you able to see that infraction on your end in the logs to put any other theories to bed?
Thanks for your persistence on this Nick.
Pete

Forgot to mention earlier... I think you want to tweak your cache key to be related to the refresh token, rather than the whoe credential.

@Override
  public String toString() {
    return MoreObjects.toStringHelper(this)

These fields will both contain the access token, which means that the cache will be invalidated every hour.:

    .add("requestMetadata", getRequestMetadataInternal())
    .add("temporaryAccess", getAccessToken())

These are fine, I would suggest considering avoiding converting the refresh token back to a string from a security point of view, e.g. what happens if this ends up in compromised log file? How about a hash of clientId + refreshToken instead?

    .add("clientId", clientId)
    .add("refreshToken", refreshToken)
    .add("tokenServerUri", tokenServerUri)
    .add("transportFactoryClassName", transportFactoryClassName)
    .toString();

}

Cool. I will start in on this strategy.
A couple of out loud thoughts:
We received a DeadlineExceeded exception whereas it looks like it may have been the result of a QPS infraction. Is there client library work that could be done to make the true cause clearer?

So quota related errors are handled by the ads API, and will come back with ResourceExhausted.

We saw the same method calls ( search CampaignCriterion, search AdGroupCriterion ) as the origin points for every instance of this exception. The same list of search requests were put into the futures jobs in the same order each night, so perhaps when it got to those method calls we just happened to be at the QPS tipping point each time, but that seems a bit too tidy of an explanation.

In conjunction with that, we were making createGoogleAdsServiceClient() calls immediately before and immediately after the futures jobs for search CC and search AGC were joined and they returned fine. Wouldn't it be likely those would trigger QPS as well? Are there different limits for different resources?

Hmm, it's certainly odd. Although these requests are more likely to run slowly, hence there could be more open TCP connections. There's more logs that we can pull from gRPC if the issue persists (see thread on GAX re. opencensus).

Speaking of limits, this is interesting:

https://developers.google.com/google-ads/api/docs/best-practices/quotas

By default gRPC has a maximum message size of 4 MB. It's possible to exceed this limit; for example, a search request that includes a very high number of fields may generate a response that exceeds 4 MB in size

Requests that violate this limitation will not generate a GoogleAdsError. They will generate an error at the gRPC error with a 429 Resource Exhausted error.

"a very high number of fields" is definitely what I alluded to earlier with the fields / resources we request for the CC and AGC searches.

We override this to 64MB already.

And finally, if it was a QPS issue, are you able to see that infraction on your end in the logs to put any other theories to bed?

Sorry, not a QPS issue per se. It's a too many TCP connections issue. There's no sign of QPS limits for your developer token on our side over the last 3 days.

Forgot to mention earlier... I think you want to tweak your cache key to be related to the refresh token, rather than the whoe credential.
These are fine, I would suggest considering avoiding converting the refresh token back to a string from a security point of view, e.g. what happens if this ends up in compromised log file? How about a hash of clientId + refreshToken instead?

Noted and implemented.
 Would you recommend we implement the same strategy for all BackgroundResources? ie. CampaignServiceClient for mutates etc.
Thanks
Pete

Yes, ideally you would create the gRPC client at the start of the process and retain it for the duration. Also you can use GoogleAdsService to send mutates for the vast majority of operations (using only one service client).

Implemented cache on the GoogleAdsServiceClient and have not seen DeadlineExceeded issues in days.
Closing issue.


AKS engine image mapping for V0.60.1 lists 18.04-LTS twice, and not 16.04-LTS

The table for #aks-engine-and-corresponding-image-mapping for version V0.60.1 lists AKS Base Ubuntu 18.04-LTS twice, but the sample Linux API model sample shows "distro": "aks-ubuntu-16.04"...
V0.60.1
AKS Base Ubuntu 18.04-LTS Image Distro, 2021 Q1 (2021.01.28),
AKS Base Ubuntu 18.04-LTS Image Distro, 2021 Q1 (2021.01.28),
AKS Base Windows Image (17763.1697.210129)	1.16.14, 1.16.15, 1.17.17, 1.18.15	Linux, Windows
Related to this commit from @mattbriggs
https://github.com/MicrosoftDocs/azure-stack-docs/commit/95bb37c5fe1bf31102891adca73fa14b197b3247
If aks-engine V0.60.1 is still compatible with "aks-ubuntu-16.04" base image, please update the table

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

ID: e69382e4-c307-4dfe-9885-92d2436ef858
Version Independent ID: 135ea653-550b-039d-121c-95f2e7c93f10
Content: Release notes for Azure Kubernetes Service (AKS) engine on Azure Stack Hub - Azure Stack Hub
Content Source: azure-stack/user/kubernetes-aks-engine-release-notes.md
Service: azure-stack
Sub-service: azure-stack-hub
GitHub Login: @mattbriggs
Microsoft Alias: mabrigg

@alexsmithMSFT Thanks for pointing this out. I updated in this pull request after touching bases with Walter. https://github.com/MicrosoftDocs/azure-stack-docs-pr/pull/8563
Here is the AKS engine topic this is based on: https://github.com/Azure/aks-engine/blob/master/docs/topics/azure-stack.md#aks-engine-versions

#please-close

Cool, thanks @mattbriggs !


Sometimes bullets won't render

Hi, I am using Swiper 4.0.6. and most of the time the bullets won't appear.
After initialising the script, the classes ,,swiper-pagination-bullets" are being added to the pagination element, but the actual bullets appear only on approximately every 5th load.
Any ideas what is causing this issue and how to solve it?
Here is the initialisation code bellow...
 var options = {
                loop: true,
                effect: 'fade',
                fadeEffect: {
                    crossFade: true
                },
                autoplay: {
                    delay: 2400,
                    disableOnInteraction: false
                },
                slidesPerView: '1',
                centeredSlides: true,
                spaceBetween: 0,

                pagination: {
                    el: '.swiper-pagination'
                },
            }

     this.mySwiper = new Swiper(this.$el, options)

Thank you!

Live example or JSFiddle?

It's caused by delayed response from the main script, but here's the solution...
wrap your initialization code in a time out function... like this
setTimeout(function(){
new Swiper(".swiper-container", {
//options here...
});
}, 100); //time can be any number the lower the better
This solution can solve almost all the problems with the slider.
enjoy...

It's caused by delayed response from the main script, but here's the solution...
wrap your initialization code in a time out function... like this
setTimeout(function(){
new Swiper(".swiper-container", {
//options here...
});
}, 100); //time can be any number
This solution can solve almost all the problems with the slider.
enjoy...


No errors displayed when expected

I just started using ols with VS Code and noticed some cases where the code can't compile but no error appears on screen:
#+private
package odin_test

main :: proc() {
  return 1
}

No error appears but odin check shows:
odin-test/main.odin(7:10) Error: No return values expected
        return 1
               ^

If I change the signature of main to return an int:
#+private
package odin_test

main :: proc() -> int {
  return 1
}

There won't be any errors on the screen but odin check shows:
odin-test/main.odin(4:1) Error: Procedure type of 'main' was expected to be 'proc()', got proc() -> int
        main :: proc() -> int {
        ^

If I call a procedure that doesn't exist, it won't appear on intellisense (obviously) but no error or warning appears saying I'm calling something that isn't real:
#+private
package odin_test

main :: proc() {
  foo()
}

odin check shows:
odin-test/main.odin(5:3) Error: Undeclared name: foo
        foo()
        ^~^

The same thing happens to "calling methods" or trying to access inexistent fields:
#+private
package odin_test

import "core:fmt"

main :: proc() {
  x := 0
  x.foo()
  x->bar()
  fmt.println(x.etc)
}

odin check shows:
odin-test/main.odin(8:3) Error: 'x' of type 'int' has no field 'foo'
        x.foo()
        ^

odin-test/main.odin(9:3) Error: 'x' of type 'int' has no field 'bar'
        x->bar()
        ^

odin-test/main.odin(10:15) Error: 'x' of type 'int' has no field 'etc'
        fmt.println(x.etc)
                    ^

I can't reproduce it. You will have to describe the exact project configuration. Your ols.json for odin check configuration. How you call the odin check manually.
Ideally to get the exact same odin check you need to set up in ols.json:
"profile": "default",
"profiles": [
		{ "name": "default", "checker_path": ["src/main.odin"]}
]

I can reproduce the second example. All the others work as expected now and I tested with the same config as before (I didn't delete the directory).
 All other files shouldn't affect how ols behaves because it's just some vscode settings to change what files are displayed in the explorer and a .gitignore file.


ci(lint): enable unparam linter

Signed-off-by: Matthieu MOREL<EMAIL_ADDRESS>

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

7 of 7 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 55.388%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
4040

Relevant Lines:
7294

💛  - Coveralls


I tried Radio/Search but no input area appeared (Windows 10)

Reported in https://forums.slimdevices.com/showthread.php?115472-Fiona-Music-app-for-Windows&p=1039112&viewfull=1#post1039112

More info from https://forums.slimdevices.com/showthread.php?115472-Fiona-Music-app-for-Windows&p=1039512&viewfull=1#post1039512
I tried the commands
fiona -s <IP_ADDRESS>
fiona -s <IP_ADDRESS> -p 9000
fiona -s <IP_ADDRESS>
fiona -s <IP_ADDRESS> -p 9000
I repeated the above commands using an elevated cmd prompt plus with the firewall disabled.
For info, if I run Fiona on another windows 11 PC on my lan, it works, but not on the windows 11 PC where LMS is running.


Set the pyarrow version upper bound again.

Seems still unstable with PyArrow 0.15. Let me set the upper bound again for now.

Codecov Report

Merging #1108 into master will decrease coverage by 0.37%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1108      +/-   ##
==========================================
- Coverage   95.21%   94.83%   -0.38%
==========================================
  Files          35       35
  Lines        6954     6954
==========================================
- Hits         6621     6595      -26
- Misses        333      359      +26

Impacted Files
Coverage Δ

databricks/koalas/missing/__init__.py
92.3% <0%> (-7.7%)
:arrow_down:

databricks/koalas/__init__.py
82.97% <0%> (-4.26%)
:arrow_down:

databricks/koalas/utils.py
95.7% <0%> (-2.46%)
:arrow_down:

databricks/koalas/exceptions.py
80.95% <0%> (-2.39%)
:arrow_down:

databricks/conftest.py
96% <0%> (-2%)
:arrow_down:

databricks/koalas/window.py
95.45% <0%> (-1.66%)
:arrow_down:

databricks/koalas/plot.py
93.33% <0%> (-0.96%)
:arrow_down:

databricks/koalas/indexes.py
95.35% <0%> (-0.85%)
:arrow_down:

databricks/koalas/groupby.py
90.77% <0%> (-0.62%)
:arrow_down:

databricks/koalas/generic.py
95.47% <0%> (-0.46%)
:arrow_down:

... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 332c3b0...aaa3d41. Read the comment docs.

I'd merge this for now since the tests passed.


Support configuring signature_algorithms_cert extension which differ from signature_algorithms extension

Hi,
we are currently using the  BCJSSE provider via the JSSE API for establishing mTls connections and have the need to specify signature algorithms for signature_algorithms_cert which differ from those in signature_algorithms. Currently (Version 1.78.1) signature_algorithms_cert is always set to same list as signature_algorithms.
Would it be possible for you to support a BC specific configuration like org.bouncycastle.jsse.client/sever.SignatureSchemesCert"? (This was shortly mentioned here https://github.com/bcgit/bc-java/issues/1456 )
I just checked if a JSSE property for signature_algorithms_cert is available now but couldn't find one.
Thanks.

Yeah, in principle we can add those. I'll just need to find some time.

There's a new 1.79 SNAPSHOT available here: https://downloads.bouncycastle.org/betas/ .
It supports two new system properties:

org.bouncycastle.jsse.client.SignatureSchemesCert
org.bouncycastle.jsse.server.SignatureSchemesCert

BCSSLParameters also has support for [get/set]SignatureSchemesCert methods.

Hi,
thanks a lot! I just tested the new version using the system properties and it works.

We'll leave it open for now in case people find any problems.

@peterdettman as 1.79 has been released, can this ticket be closed now?


FB login bug

login box pops up sometimes when pressing New Event button

Wontfix because the FB login is removed for now


Mismatch of testapp and ffmpeg/zscale results

I'm comparing the outputs of colorspace conversoin using testapp vs. ffmpeg/zscale:
./testapp colorspace --width 192 --height 108 --fullrange-in --fullrange-out --peak-luminance 10000 \
<EMAIL_ADDRESS>\
<EMAIL_ADDRESS>\
rgb:st_2084:2020 \
ictcp:st_2084:2020

./ffmpeg -f rawvideo -pix_fmt rgb48le -s:v 192x108 -i SCD_192x108.rgb48.rgb -vf zscale=rangein=full:range=full:npl=10000:matrixin=input:transferin=smpte2084:primariesin=2020:matrix=ictcp:transfer=smpte2084:primaries=2020,format=yuv444p16le -f rawvideo SCD_192x108.rgb48.plr.ffmpeg.yuv

The two commands above produce somewhat mismatched results (PSNR 72.192, 60.994, 55.346 for the three channels). Visual inspection suggests that the ffmpeg/zscale result has blockiness, potentially due to poor resampling:

(left hand side is ffmpeg/zscale; right hand side is testapp)
I also tried to specify filter or dither flag in ffmpeg/zscale, but neither seem to have any effect.
Does anyone have an explanation on this?
The input videos can be found in the link below:
https://drive.google.com/drive/folders/1Ia_y-IgSYDU_raLnFO7SJyoESEf_wlhg?usp=sharing
The output videos can be found below:
https://drive.google.com/drive/folders/1wpc4p_7s3gBm0XsvWM2xb712y_UoakJa?usp=sharing

The difference is that FFmpeg uses a LUT approximation for the gamma function (--lut in testapp). Are these artifacts visible when the image is viewed on an HDR monitor?

The difference is that FFmpeg uses a LUT approximation for the gamma function (--lut in testapp). Are these artifacts visible when the image is viewed on an HDR monitor?

SCD_192x108.zip
Ok. Try these input files.
I tested ffmpeg with agamma off:
./ffmpeg -f rawvideo -pix_fmt rgb48le -s:v 192x108 -i SCD_192x108.rgb48.rgb -vf zscale=agamma=0:rangein=full:range=full:npl=10000:matrixin=input:transferin=smpte2084:primariesin=2020:matrix=ictcp:transfer=smpte2084:primaries=2020,format=yuv444p16le -f rawvideo SCD_192x108.rgb48.plr.ffmpeg.yuv

It gives slightly different result but the blocky artifact persists.
I haven't tried it on a HDR display yet.

SCD_192x108.zip
Ok. Try these input files.
I tested ffmpeg with agamma off:
./ffmpeg -f rawvideo -pix_fmt rgb48le -s:v 192x108 -i SCD_192x108.rgb48.rgb -vf zscale=agamma=0:rangein=full:range=full:npl=10000:matrixin=input:transferin=smpte2084:primariesin=2020:matrix=ictcp:transfer=smpte2084:primaries=2020,format=yuv444p16le -f rawvideo SCD_192x108.rgb48.plr.ffmpeg.yuv

It gives slightly different result but the blocky artifact persists.
I haven't tried it on a HDR display yet.

I couldn't see the same artifact from the images you have generated. (btw, I was using a tool called vooya to visualize and calculate PSNR, and the reason why you saw a different color is that i set the colorspace wrong. Below you can see the comparison side by side (left: testapp, right: ffmpeg) viewed as 709:

Could this be an ffmpeg-only issue? Are we guaranteed that ffmpeg is using exactly the same code path as testapp?

I couldn't see the same artifact from the images you have generated. (btw, I was using a tool called vooya to visualize and calculate PSNR, and the reason why you saw a different color is that i set the colorspace wrong. Below you can see the comparison side by side (left: testapp, right: ffmpeg) viewed as 709:

Could this be an ffmpeg-only issue? Are we guaranteed that ffmpeg is using exactly the same code path as testapp?

I will investigate the FFmpeg code next. They should be exercising the same code, but there may be some auto-inserted swscale steps causing the issue.

I will investigate the FFmpeg code next. They should be exercising the same code, but there may be some auto-inserted swscale steps causing the issue.

I found that there are auto-inserted swscale steps when using format rgb48le. Can you reproduce with gbrp16le?

I found that there are auto-inserted swscale steps when using format rgb48le. Can you reproduce with gbrp16le?

I ran your first command:
./ffmpeg -v debug -f rawvideo -pix_fmt rgb48le -s:v 192x108 -i SCD_192x108.rgb48.rgb -vf format=gbrp16le,zscale=rangein=full:range=full:npl=10000:matrixin=input:transferin=smpte2084:primariesin=2020:matrix=ictcp:transfer=smpte2084:primaries=2020,format=yuv444p16le -f rawvideo FFMPEG_ICTCP_SCD_192x108.rgb48.plr.ffmpeg.yuv

and I can reproduce the artifacts:

Were you saying you couldn't, and this is a build issue?

Please share your workflow to visualize the image. I used the provided commands to render the result back to RGB24 with FFmpeg.

Please share your workflow to visualize the image. I used the provided commands to render the result back to RGB24 with FFmpeg.

After the first step to generate FFMPEG_ICTCP_SCD_192x108.rgb48.plr.ffmpeg.yuv, I use the "vooya" player to visualize it, which you can download from here:
https://www.offminor.de/
Display setting is as follows:

I also tried your three steps to generate the final .bmp file. It seems that the blockiness got washed out after the second step, making it much less visible in the .bmp.

After the first step to generate FFMPEG_ICTCP_SCD_192x108.rgb48.plr.ffmpeg.yuv, I use the "vooya" player to visualize it, which you can download from here:
https://www.offminor.de/
Display setting is as follows:

I also tried your three steps to generate the final .bmp file. It seems that the blockiness got washed out after the second step, making it much less visible in the .bmp.

If the image is in the ICtCp space, why do you visualise it as Rec.709? I can indeed reproduce the artifacts in the VOOYA application with your settings, but this visualisation does not represent the actual data. I tried setting VOOYA to ICtCp space, but it just produces a blank screen.

If the image is in the ICtCp space, why do you visualise it as Rec.709? I can indeed reproduce the artifacts in the VOOYA application with your settings, but this visualisation does not represent the actual data. I tried setting VOOYA to ICtCp space, but it just produces a blank screen.

I don't trust vooya' ICtCp visualization, so I didn't even try that.
But the key point is, if you just treat the videos as 709 Y'Cb'Cr', the
content is still visually meaningful. And in this setting, if you compare
the two videos (one produced by testapp and one by ffmpeg) there is a
clearly numerical difference in the values. I am wondering why that
happens. You mentioned that it may be because of auto-inserted swscale
steps. I curious if this can be avoided.
On Tue, Jan 5, 2021 at 6:10 PM sekrit-twc<EMAIL_ADDRESS>wrote:

If the image is in the ICtCp space, why do you visualise it as Rec.709? I
can indeed reproduce the artifacts in the VOOYA application with your
settings, but this visualisation does not represent the actual data. I
tried setting VOOYA to ICtCp space, but it just produces a blank screen.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/sekrit-twc/zimg/issues/138#issuecomment-755029915,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AECVVEEBTAXVFE66MLVFAGLSYPBAFANCNFSM4VTOLVBQ
.

I don't trust vooya' ICtCp visualization, so I didn't even try that.
But the key point is, if you just treat the videos as 709 Y'Cb'Cr', the
content is still visually meaningful. And in this setting, if you compare
the two videos (one produced by testapp and one by ffmpeg) there is a
clearly numerical difference in the values. I am wondering why that
happens. You mentioned that it may be because of auto-inserted swscale
steps. I curious if this can be avoided.
On Tue, Jan 5, 2021 at 6:10 PM sekrit-twc<EMAIL_ADDRESS>wrote:

If the image is in the ICtCp space, why do you visualise it as Rec.709? I
can indeed reproduce the artifacts in the VOOYA application with your
settings, but this visualisation does not represent the actual data. I
tried setting VOOYA to ICtCp space, but it just produces a blank screen.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/sekrit-twc/zimg/issues/138#issuecomment-755029915,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AECVVEEBTAXVFE66MLVFAGLSYPBAFANCNFSM4VTOLVBQ
.

Ah. Didn't see your EDIT section from the email thread. This explains it! Now I know how to avoid this. Thanks for digging!

Ah. Didn't see your EDIT section from the email thread. This explains it! Now I know how to avoid this. Thanks for digging!

Quick follow-up: do you know why swscale introduces the artifacts for rgb48le-gbrp16le conversion? This looks crappy as it's just bit re-arrangement.
What tool did you use to do the conversion? Does zscale offer a repalcement for this conversion?

Quick follow-up: do you know why swscale introduces the artifacts for rgb48le-gbrp16le conversion? This looks crappy as it's just bit re-arrangement.
What tool did you use to do the conversion? Does zscale offer a repalcement for this conversion?

Without looking, I would not be surprised if FFmpeg roundtrips to YCbCr silently when converting between the two (it's happened before...).
As for packing/unpacking, there is libp2p (https://github.com/sekrit-twc/libp2p) among others.

Without looking, I would not be surprised if FFmpeg roundtrips to YCbCr silently when converting between the two (it's happened before...).
As for packing/unpacking, there is libp2p (https://github.com/sekrit-twc/libp2p) among others.

Without knowing more about swscale, I suspect it is because there is no special-case "unscaled conversion" (sws_unscaled.c?) for rgb48/gbrp16.  I created the GBRP image by using dd. Unfortunately, there is probably no workaround in FFmpeg without fixing the underlying code.

Without knowing more about swscale, I suspect it is because there is no special-case "unscaled conversion" (sws_unscaled.c?) for rgb48/gbrp16.  I created the GBRP image by using dd. Unfortunately, there is probably no workaround in FFmpeg without fixing the underlying code.

FFmpeg roundtrips to YCbCr silently when converting between the two

Oh, there are at least two open issues about that in ffmpeg: https://trac.ffmpeg.org/ticket/3345 yuv 10 bit to 8 bit
https://trac.ffmpeg.org/ticket/979 Infamous bgr24->yuv issue that is not present when you do rgb24->yuv (yes, LOL, rgb to bgr is lossless). Can be that second one.

FFmpeg roundtrips to YCbCr silently when converting between the two

Oh, there are at least two open issues about that in ffmpeg: https://trac.ffmpeg.org/ticket/3345 yuv 10 bit to 8 bit
https://trac.ffmpeg.org/ticket/979 Infamous bgr24->yuv issue that is not present when you do rgb24->yuv (yes, LOL, rgb to bgr is lossless). Can be that second one.

You need to use :format=yuvxxxx not ,format=yuv4xxxxx, okay, see https://trac.ffmpeg.org/timeline?from=2019-11-29T12%3A35%3A22%2B02%3A00&precision=second

You need to use :format=yuvxxxx not ,format=yuv4xxxxx, okay, see https://trac.ffmpeg.org/timeline?from=2019-11-29T12%3A35%3A22%2B02%3A00&precision=second


docs: add status codes documentation

Pull Request Test Coverage Report for Build<PHONE_NUMBER>5
Details

0 of 0   changed or added relevant lines in 0 files are covered.
4 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.04%) to 80.193%

Files with Coverage Reduction
New Missed Lines
%

crates/watcher/src/lib.rs
4
92.71%

Totals

Change from base Build<PHONE_NUMBER>2:
-0.04%

Covered Lines:
6810

Relevant Lines:
8492

💛  - Coveralls


Move @testing-library/react to dev dependencies

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1317

Relevant Lines:
1814

💛  - Coveralls


[🐞] azure-swa adaptor not executable

Which component is affected?
Starters / CLI
Describe the bug
running npm run qwik add azure-swa faile during CLI input validation
Reproduction
none
Steps to reproduce
No response
System Info
System:
    OS: macOS 12.6
    CPU: (10) arm64 Apple M1 Max
    Memory: 364.83 MB / 64.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.13.0 - /var/folders/34/mgxs4kqs24s8kl0jfxg9jng00000gn/T/fnm_multishells/27977_1671135389685/bin/node
    Yarn: 1.22.18 - /var/folders/34/mgxs4kqs24s8kl0jfxg9jng00000gn/T/fnm_multishells/27977_1671135389685/bin/yarn
    npm: 8.1.0 - /var/folders/34/mgxs4kqs24s8kl0jfxg9jng00000gn/T/fnm_multishells/27977_1671135389685/bin/npm
  Browsers:
    Brave Browser: <IP_ADDRESS>
    Chrome: 108.0.5359.124
    Chrome Canary: 110.0.5479.0
    Firefox: 107.0.1
    Safari: 16.0
    Safari Technology Preview: 16.4
  npmPackages:
    @builder.io/qwik: 0.15.2 => 0.15.2
    @builder.io/qwik-city: 0.0.128 => 0.0.128
    vite: 3.2.4 => 3.2.4

Additional Information
error
npm run qwik add azure-swa

❌ Error: Invalid integration: azure-swa

npm run qwik add [integration]

  Adaptors
    cloudflare-pages  Cloudflare Pages
    netlify-edge  Netlify Edge Functions
    vercel-edge  Vercel Edge Functions
    express  Express.js server
    static  Static Site Generator

  Features
    react  Use React components into your Qwik app
    playwright  Use Playwright to run E2E tests into your Qwik app
    styled-vanilla-extract  Zero-cost CSS-in-JS for Qwik
    tailwind  Use Tailwind in your Qwik app
    vitest  Use Vitest into your Qwik app
    partytown  Use Partytown in your Qwik app
    ```

just recognized that the implementation was merged but not yet released. the docs are ahead in this case.


Several improvements to Spanish translation.

[x] I have read the contributing guidelines and I agree with the Code of Conduct
[x] Have you checked that there aren't other open pull requests for the same changes?
[ ] Have you tested that the committed code can be executed without errors?

Updated Spanish translation. Added several missing keys. Updated terminology to be more friendly to both Spain and Latin America. Made tone consistently "tuteo". Changed several main screen texts from imperative to infinitive. Fixed several mistakes and typos.

Hello @uKER,
I will merge this PR, but please follow the guide on how to contribute to translations, because if not integration breaks.
Thank you!

Oh, sorry about that.
I just signed up at Tolgee with this address @.***)
Can you hook me up?
I just saw that the changes are already live, and noticed there's a couple more that aren't entirely right, and there's a couple non-translated strings in the About page.

De: Martí Climent @.>
Enviado: jueves, 12 de octubre de 2023 15:53
Para: marticliment/WingetUI @.>
Cc: uKER @.>; Mention @.>
Asunto: Re: [marticliment/WingetUI] Several improvements to Spanish translation. (PR #1488)
Hello @uKERhttps://github.com/uKER,
I will merge this PR, but please follow the guide on how to contribute to translationshttps://github.com/marticliment/WingetUI/wiki#translating-wingetui, because if not integration breaks.
Thank you!
—
Reply to this email directly, view it on GitHubhttps://github.com/marticliment/WingetUI/pull/1488#issuecomment-1760203042, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACAFCHKCSHRIFG3RW6ITFHTX7A4EDANCNFSM6AAAAAA547FTWE.
You are receiving this because you were mentioned.Message ID: @.***>

GitHub is censoring your email

Huh? What do you mean?
I just logged in with no issue.
What error are you getting exactly?

De: Martí Climent @.>
Enviado: viernes, octubre 13, 2023 8:42:06 a. m.
Para: marticliment/WingetUI @.>
Cc: uKER @.>; Mention @.>
Asunto: Re: [marticliment/WingetUI] Several improvements to Spanish translation. (PR #1488)
GitHub is censoring your email
—
Reply to this email directly, view it on GitHubhttps://github.com/marticliment/WingetUI/pull/1488#issuecomment-1761376153, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACAFCHLYMSWSWY3GVBBEY3LX7ESIVANCNFSM6AAAAAA547FTWE.
You are receiving this because you were mentioned.Message ID: @.***>

I cannot see your personal email if you post it here, github blocks it

Oh.
It's uker at outlook.com

From: Martí Climent @.>
Sent: Friday, October 13, 2023 9:00:19 AM
To: marticliment/WingetUI @.>
Cc: uKER @.>; Mention @.>
Subject: Re: [marticliment/WingetUI] Several improvements to Spanish translation. (PR #1488)
I cannot see your personal email if you post it here, github blocks it
[image]https://user-images.githubusercontent.com/53119851/274894401-26bd05ad-51b8-45c2-9f8c-e31e315f81a5.png
—
Reply to this email directly, view it on GitHubhttps://github.com/marticliment/WingetUI/pull/1488#issuecomment-1761399187, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACAFCHP6NF77HNXQYPIZLBTX7EUNHANCNFSM6AAAAAA547FTWE.
You are receiving this because you were mentioned.Message ID: @.***>

You will receive an email from the Tolgee Platform with an invitation link! (Please check your spam folder)
Thank you!

I'm already in!
Cheers!

From: Martí Climent @.>
Sent: Friday, October 13, 2023 9:03:49 AM
To: marticliment/WingetUI @.>
Cc: uKER @.>; Mention @.>
Subject: Re: [marticliment/WingetUI] Several improvements to Spanish translation. (PR #1488)
You will receive an email from the Tolgee Platform with an invitation link! (Please check your spam folder)
Thank you!
—
Reply to this email directly, view it on GitHubhttps://github.com/marticliment/WingetUI/pull/1488#issuecomment-1761403655, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACAFCHKSFFLLJ5FSQRZNNGDX7EU2LANCNFSM6AAAAAA547FTWE.
You are receiving this because you were mentioned.Message ID: @.***>

Hey there!
I just submitted some more corrections.
That said, there's still this text in the About screen that doesn't seem to be internationalized, as I'm not seeing it in Tolgee.

De: Martí Climent @.>
Enviado: viernes, 13 de octubre de 2023 9:03
Para: marticliment/WingetUI @.>
Cc: uKER @.>; Mention @.>
Asunto: Re: [marticliment/WingetUI] Several improvements to Spanish translation. (PR #1488)
You will receive an email from the Tolgee Platform with an invitation link! (Please check your spam folder)
Thank you!
—
Reply to this email directly, view it on GitHubhttps://github.com/marticliment/WingetUI/pull/1488#issuecomment-1761403655, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACAFCHKSFFLLJ5FSQRZNNGDX7EU2LANCNFSM6AAAAAA547FTWE.
You are receiving this because you were mentioned.Message ID: @.***>

Which string do you mean?
Translations do get updated automatically in 24/48h

I attached a screenshot in my previous email.

De: Martí Climent @.>
Enviado: viernes, 13 de octubre de 2023 15:03
Para: marticliment/WingetUI @.>
Cc: uKER @.>; Mention @.>
Asunto: Re: [marticliment/WingetUI] Several improvements to Spanish translation. (PR #1488)
Which string do you mean?
Translations do get updated automatically in 24/48h
—
Reply to this email directly, view it on GitHubhttps://github.com/marticliment/WingetUI/pull/1488#issuecomment-1761959141, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACAFCHODXVGUZXFXBVWJB5LX7F66BANCNFSM6AAAAAA547FTWE.
You are receiving this because you were mentioned.Message ID: @.***>

Email-attached screenshots are not recognized by github. they must be uploaded direclty on GH

https://i.imgur.com/DZWVzek.jpg
[https://i.imgur.com/DZWVzek.jpg]

De: Martí Climent @.>
Enviado: viernes, 13 de octubre de 2023 15:11
Para: marticliment/WingetUI @.>
Cc: uKER @.>; Mention @.>
Asunto: Re: [marticliment/WingetUI] Several improvements to Spanish translation. (PR #1488)
Email-attached screenshots are not recognized by github. they must be uploaded direclty on GH
—
Reply to this email directly, view it on GitHubhttps://github.com/marticliment/WingetUI/pull/1488#issuecomment-1761968130, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACAFCHPWGB7NSGQDCG4MQM3X7F75FANCNFSM6AAAAAA547FTWE.
You are receiving this because you were mentioned.Message ID: @.***>

They are now on Tolgee

And translated.

De: Martí Climent @.>
Enviado: viernes, 13 de octubre de 2023 15:24
Para: marticliment/WingetUI @.>
Cc: uKER @.>; Mention @.>
Asunto: Re: [marticliment/WingetUI] Several improvements to Spanish translation. (PR #1488)
They are now on Tolgee
—
Reply to this email directly, view it on GitHubhttps://github.com/marticliment/WingetUI/pull/1488#issuecomment-1761993464, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACAFCHNDLGW22CKCDICM6PTX7GBNJANCNFSM6AAAAAA547FTWE.
You are receiving this because you were mentioned.Message ID: @.***>

Here's some more non-internationalized strings.
https://i.imgur.com/YI9OKzN.png
[https://i.imgur.com/YI9OKzN.png]

De: Martí Climent @.>
Enviado: viernes, 13 de octubre de 2023 15:24
Para: marticliment/WingetUI @.>
Cc: uKER @.>; Mention @.>
Asunto: Re: [marticliment/WingetUI] Several improvements to Spanish translation. (PR #1488)
They are now on Tolgee
—
Reply to this email directly, view it on GitHubhttps://github.com/marticliment/WingetUI/pull/1488#issuecomment-1761993464, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACAFCHNDLGW22CKCDICM6PTX7GBNJANCNFSM6AAAAAA547FTWE.
You are receiving this because you were mentioned.Message ID: @.***>

Those ones are not translatable yet

Hey! Just saw the latest changes made it into the app.
I just submitted 3 very minor changes, but I think it's looking real good now.
BTW, is there any chance I can get my name listed among the contributors?
Cheers!

De: Martí Climent @.>
Enviado: sábado, 14 de octubre de 2023 11:23
Para: marticliment/WingetUI @.>
Cc: uKER @.>; Mention @.>
Asunto: Re: [marticliment/WingetUI] Several improvements to Spanish translation. (PR #1488)
Those ones are not translatable yet
—
Reply to this email directly, view it on GitHubhttps://github.com/marticliment/WingetUI/pull/1488#issuecomment-1762928915, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACAFCHNKMHEHIW2JQBMRXG3X7KN45ANCNFSM6AAAAAA547FTWE.
You are receiving this because you were mentioned.Message ID: @.***>

Hello @uKER,
You can add your name or github username on a special entry. It used to appear at the top, but it seems as if it broke. Please search for "{0} {0} {0}" and you will find it.

Well, I added myself to that one but that does not look like the list shown in the About dialog.
Am I doing anything wrong?

De: Martí Climent @.>
Enviado: lunes, 16 de octubre de 2023 10:16
Para: marticliment/WingetUI @.>
Cc: uKER @.>; Mention @.>
Asunto: Re: [marticliment/WingetUI] Several improvements to Spanish translation. (PR #1488)
Hello @uKERhttps://github.com/uKER,
You can add your name or github username on a special entry. It used to appear at the top, but it seems as if it broke. Please search for "{0} {0} {0}" and you will find it.
—
Reply to this email directly, view it on GitHubhttps://github.com/marticliment/WingetUI/pull/1488#issuecomment-1764465992, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACAFCHKOZ37IKKHWD6MKX2DX7UXTPAVCNFSM6AAAAAA547FTWGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRUGQ3DKOJZGI.
You are receiving this because you were mentioned.Message ID: @.***>

Well, I added myself to that one but that does not look like the list shown in the About dialog.

This list will only be updated on the readme, and will be updated on WingetUI on the next version:


UX of character counter

Should the character counter be labeled, or is a number self-evident? If it should be labeled, is there a way to do it without translatable language?
Should the counter go up from 0 to infinity or down from (Xitter max or Mastodon max or whatever max) to 0?

@mathieu-william , this is a continuation of the thread in the ideas you posted on Tuesday (https://github.com/lucasgonze/sQratch/issues/29)


Hovering Over Buttons Issue

When hovering over buttons, the descriptions are not instantly displayed. I believe there is an opportunity to enhance this interaction for a smoother and more immediate experience.
https://github.com/excalidraw/excalidraw/assets/127772255/ee944931-fc35-41a8-ab6b-fffc58e4fde6

I think this was intentionally made that way. If a user wants to know details they hover a little longer or else it is not required to show them details every time. This seems like a decent feature to me.


CrewAI doesn't support gpt-3.5-turbo model

I was super pumped or happy to use CrewAI in my project but unfortunately it doesn't support gpt-3.5-turbo. Here is the code I used to change the base model which I guess is Gpt-4 to gpt-3.5-turbo "OpenAIGPTModel = ChatOpenAI(
model_name='gpt-3.5-turbo',   # Loading GPT-3.5-turbo
temperature=0.1
)" but it doesn't work out. It gave this error in the terminal " I encountered an error while trying to use the tool. This was the error: Error code: 404 - {'error': {'message': 'The model gpt-4 does not exist or you do not have access to it.', 'type': 'invalid_request_error', 'param': None, 'code': 'model_not_found'}}.
Tool Delegate work to co-worker accepts these inputs: Delegate work to co-worker(coworker: str, task: str, context: str) - Delegate a specific task to one of the following co-workers: ['YouTube Manager', 'YouTube Research Manager', 'Email Creator', 'Title Creator', 'Description Creator']
The input to this tool should be the coworker, the task you want them to do, and ALL necessary context to exectue the task, they know nothing about the task,
so share absolute everything you know, don't reference things but instead explain them." Please help me out incase there is an alternative method to use gpt-3.5-turbo

why dont u use 'gpt-4' ?

Thanks for getting in touch @AdovaX . There is a restriction on payment card in my country. I have a dollar prepaid card but OpenAI doesn't accept a dollar prepaid card but a credit card which I don't have at the moment.

Can you try - gpt-3.5-turbo-0125 as your model and also also how have you setup your API key?

I used this code: OpenAIGpt = ChatOpenAI {
model_name: "gpt-3.5-turbo",
temperature: 0.1

Hi @Mampha . It seems that the llm doesn't work as it should. At least I also have encountered this bug, while setting up the name of the model by creating ChatOpenAI instance and using in agents.
There is a brief information in the documentation: It dynamically fetches the model name from the OPENAI_MODEL_NAME environment variable.
I have set up the env variable in my file as I don't want to use the GPT-4 (too expensive for testing)
os.environ['OPENAI_MODEL_NAME'] = 'gpt-3.5-turbo-0125'
This worked for me.


Added Alerts designs.

Fixed some links in index.html
Added Alerts to the design button list in index.html
» Has Info, Danger, Success, Dark & Warning alerts with respective colors and icon.
» Has a Go Back button to go to the main page.

Follows the same style as the main page.

While waiting for the other PR to be merged, got to work and did some new Alerts :)

It looks dope and has been merged.


Reduce/eliminate casts

Typing is good, and it does catch errors, but we shouldn't be so strict about casting as to take performance hits in critical areas. Casts are noops, but they aren't without overhead, function calls, even ones that do nothing, have overhead and are not optimized out.

There are some casts that, for some reason, mypy is not telling us are no longer necessary, these should be removed.
There are some casts that we can remove by minor restructuring.
There are some casts where we can clearly see there is no issue, but mypy can't, some of these, especially if in critical areas, we can just ignore.

The biggest offender is our "algebra" lib. This is because Matrices are difficult for mypy to know their depth, so it never knows if an index contains a Matrix, Vector, or a float. We have to constantly tell it. This may be the trickiest part to reduce the casts, but if we can, especially in things like dot we may be able to gain some more speed.

Just as an example, we can see real overhead for a function call when casting.
➜  coloraide git:(chore/cast) ✗ python3 -m timeit -n 1000 -s "from typing import cast" "a = 3 + 3"
1000 loops, best of 5: 8.43 nsec per loop
➜  coloraide git:(chore/cast) ✗ python3 -m timeit -n 1000 -s "from typing import cast" "a = cast(float, 3 + 3)"
1000 loops, best of 5: 36.3 nsec per loop

Even if we remove all casts, we are likely not to see an extremely noticeable difference in performance, but every bit helps. It will definitely clean up the code as well.

We've removed all casting outside of "algebra".
There were many cases where we could simply remove the cast without any side effects. The rest just required some slight restructure, a few more still required us to cave and tell mypy that a specific local variable was Any. Mypy just isn't always smart enough to tell everything that is going on, so sometimes, for speed, we just need to say, okay, don't worry about this one variable.
There was only one case where an ignore was absolutely necessary, and that was in our logic for indexing color channels. Even if you set up all the @overload methods describing that if one input is a given type, then the other has to be a specific type, and you do an isinstance check to verify that the first is as expected, mypy will not assume the other value is what you think.  isinstance checks are not cheap, so sometimes you just have to ignore if you are in a commonly called area such as this.
Algebra on the other hand is dealing with Matrix objects. And there is no good way to tell it what a Matrix even is. It is a list of lists of floats, but it could nest lists forever. There is no way to represent this properly, so we do our best. When indexing these, mypy is constantly confused as to when we are getting a float out of the Matrix or a Vector, so casting or ignoring is the only way to have it know what is going on. Either that or all of "algebra" should work with Any or I guess they could all work with a generic concept of Array. While working with only an array would help remove ambiguity with Matrix and Vector, it would still get confusing when you can access a float or not.
Anyways, we may have to sprinkle ignores all throughout algebra, at least in very commonly accessed functions.  Some functions can probably keep cast as they won't be used very often.

We may do this in stages


"Download scene" button in Model Editor is broken

Description
The "Download scene" button in the Model Editor no longer initiates a download. I used the Model Editor last week to download the scene and it worked fine, but for some reason the download button is no longer working this week. I've tried downloading a scene that I've previously downloaded. I've also tried downloading a sample scene provided in the Model Editor. Nothing seems to work.
This is the link I'm using to access the Model Editor:
https://modelviewer.dev/editor/
Version
The version that is running on the Model Editor site.
Browser Affected

[x] Chrome, version: 92.0.4515.159
[ ] Edge
[ ] Firefox
[ ] IE
[x] Safari

Thank you for jumping on this so quickly @elalish. I can confirm that it is now working! Thanks again 🙌


Fix import error: No module named multiq

At first, thank you very much for a pytorch implementation!
I've faced some import errors, when importing multiq package and changed all files to import tqc.
Could be related to your changes introduced in d6554ba4cf152fc756ba6d119bad0778141ff625, in which you removed multiq from python path.

Hello.
Looks like we did this mistake when we renamed the package. Thank you for the fix!


fix: Support Markdown tables.

The current Google AIP-160 already uses them.
Related to googleapis/aip#562.

Proof it is sufficient:


Does not compile against 9.1 & 9.2

Compiling against 9.1 and 9.2 fails.
➜  dump_fdw git:(master) USE_PGXS=1 make
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv -fpic -I. -I. -I/usr/local/pgsql_9.1.18/include/server -I/usr/local/pgsql_9.1.18/include/internal -D_GNU_SOURCE   -c -o dump_fdw.o dump_fdw.c
dump_fdw.c:32:33: error: access/htup_details.h: No such file or directory
dump_fdw.c:130: error: expected declaration specifiers or ‘...’ before ‘AcquireSampleRowsFunc’
dump_fdw.c: In function ‘dump_fdw_handler’:
dump_fdw.c:152: error: ‘FdwRoutine’ has no member named ‘GetForeignRelSize’
dump_fdw.c:153: error: ‘FdwRoutine’ has no member named ‘GetForeignPaths’
dump_fdw.c:154: error: ‘FdwRoutine’ has no member named ‘GetForeignPlan’
dump_fdw.c:161: error: ‘FdwRoutine’ has no member named ‘AddForeignUpdateTargets’
dump_fdw.c:162: error: ‘FdwRoutine’ has no member named ‘PlanForeignModify’
dump_fdw.c:163: error: ‘FdwRoutine’ has no member named ‘BeginForeignModify’
dump_fdw.c:164: error: ‘FdwRoutine’ has no member named ‘ExecForeignInsert’
dump_fdw.c:165: error: ‘FdwRoutine’ has no member named ‘ExecForeignUpdate’
dump_fdw.c:166: error: ‘FdwRoutine’ has no member named ‘ExecForeignDelete’
dump_fdw.c:167: error: ‘FdwRoutine’ has no member named ‘EndForeignModify’
dump_fdw.c:171: error: ‘FdwRoutine’ has no member named ‘ExplainForeignModify’
dump_fdw.c:174: error: ‘FdwRoutine’ has no member named ‘AnalyzeForeignTable’
dump_fdw.c: In function ‘dumpGetForeignRelSize’:
dump_fdw.c:334: error: ‘RelOptInfo’ has no member named ‘fdw_private’
dump_fdw.c: In function ‘dumpGetForeignPaths’:
dump_fdw.c:361: error: too many arguments to function ‘create_foreignscan_path’
dump_fdw.c: In function ‘dumpGetForeignPlan’:
dump_fdw.c:383: warning: implicit declaration of function ‘make_foreignscan’
dump_fdw.c:387: warning: return makes pointer from integer without a cast
dump_fdw.c: At top level:
dump_fdw.c:630: error: expected declaration specifiers or ‘...’ before ‘AcquireSampleRowsFunc’
dump_fdw.c: In function ‘read_int’:
dump_fdw.c:647: warning: ISO C90 forbids mixed declarations and code
dump_fdw.c: In function ‘read_str’:
dump_fdw.c:667: warning: ISO C90 forbids mixed declarations and code
dump_fdw.c: In function ‘read_toc’:
dump_fdw.c:764: warning: ISO C90 forbids mixed declarations and code
dump_fdw.c:768: warning: ISO C90 forbids mixed declarations and code
dump_fdw.c:775: warning: ISO C90 forbids mixed declarations and code
dump_fdw.c:778: warning: ISO C90 forbids mixed declarations and code
dump_fdw.c:784: warning: ISO C90 forbids mixed declarations and code
dump_fdw.c:790: warning: ISO C90 forbids mixed declarations and code
dump_fdw.c:799: warning: ISO C90 forbids mixed declarations and code
dump_fdw.c: In function ‘field_cb’:
dump_fdw.c:906: warning: ISO C90 forbids mixed declarations and code
dump_fdw.c:917: warning: ISO C90 forbids mixed declarations and code
make: *** [dump_fdw.o] Error 1

It seems fixing the issue or changing the docs are both valid solutions.

Hey, Matt. Thanks for the feedback. 9.3/9.4 was our primary usage. I'll get this fixed this weekend. Thanks again!


Updates for latest closure linter warnings

Have you looked into the IE compatibility? Since we're not transpiling, my understanding is this will not work on IE 10 or earlier. I don't think that matters.

Have you looked into the IE compatibility? Since we're not transpiling, my understanding is this will not work on IE 10 or earlier. I don't think that matters.

Agreed; I don't think we need to worry about this right now.


par spacing compatible with typst 0.12.0

Old way of setting it got deprecated, here I updated it to the new way
Compiles without issues on typst 0.12.0

Only apply https://github.com/csskevin/typst-iaik-bachelor-thesis-template/pull/1/commits/b18fbf9b19513f62f9d0a3d995830dd04e875ba7 I forgot and continue development in my branch.
Just git cherry pick that one

Closed in favor of https://github.com/csskevin/typst-iaik-bachelor-thesis-template/commit/f662d78b2b85c70c3a97d44d038ce28709aadf80


Regression in 3.0.0 for Pydantic models defined using inheritance

We've encountered what seems like a regression in the behavior of the latest version of py-avro-schema when Pydantic models are defined via inheritance (e.g. to DRY up definitions where models have common fields). A minimal test case which passes in 2.2.1 but fails in 3.0.0:
def test_model_inheritance():
    class PyTypeCustomBase(pydantic.BaseModel):
        field_a: str

    class PyType(PyTypeCustomBase):
        field_b: str

    expected = {
        "type": "record",
        "name": "PyType",
        "fields": [
            {
                "name": "field_a",
                "type": "string"
            },
            {
                "name": "field_b",
                "type": "string"
            },
        ],
    }
    assert_schema(PyType, expected)

A potential fix may be as simple as the following :man_shrugging:  :
--- a/src/py_avro_schema/_schemas.py
+++ b/src/py_avro_schema/_schemas.py
@@ -835,7 +835,7 @@ class PydanticSchema(RecordSchema):
         # Pydantic 2 resolves forward references for us. To avoid infinite recursion, we check if the unresolved raw
         # annoation is a forward reference. If so, we use that instead of Pydantic's resolved type hint. There might be
         # a better way to un-resolve the forward reference...
-        if isinstance(self.raw_annotations[name], (str, ForwardRef)):
+        if isinstance(self.raw_annotations.get(name), (str, ForwardRef)):

Cool, let me review that.

WIP PR here: #49
Many thanks for the reproducable test @rnathuji!

This does highlight how fragile the forward reference "unresolving" logic is we us :cry: . For now, I am happy to accept that we are not supporting forward references in Pydantic base classes... I have added a (failing) test to make that explicit.

@rnathuji Will let you know once merged.

Released as version 3.0.1. Thanks @rnathuji


⚠ Fortnite has degraded performance

In da0f3fc, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1664 ms

Resolved: Fortnite performance has improved in 5d764f9.


temp file for stat table not deleted after successful export

I have this file HedvigLettersSerif-Regular[opsz].ttf.stat.yaml in the variablefont directory each time after export. In https://github.com/RosaWagner/HedvigLetters/commit/2cd282da2077b297b69cf16758144342ed11e32c
Also instances_ttf is not removed after successful export of (only) otf-cff fonts.

This is something which will get fixed when builder2 lands, as builder2 is more conscientious about putting temporary files in the temporary directory.


Fix Let's Split SVG

This PR addresses some of the issues mentioned on https://github.com/qmk/qmk.fm/issues/50
Most of the issues have been addressed. The only outstanding one is number 4 from that list, which I am happy to work on given some guidance on it.

Is there any other changes required in this issue?

Hey @jackhumbert any chance to take a look at this PR? Quite straight forward :)


IMDS: Adding Swagger spec for 2019-04-30 version.

Contribution checklist:

[x] I have reviewed the documentation for the workflow.
[ x Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

Can one of the admins verify this patch?

Automation for azure-sdk-for-go

Automation for azure-sdk-for-python

Automation for azure-sdk-for-java

There is already a version of 2019-06-01, does this version necessary? Thanks.

@yaohaizh , yes, this version is necessary even though it's seemingly identical to the 2019-06-01 version. IMDS has several different providers, and they all share the same versions: The 2019-04-30 version is required by the attested provider for a new subscription ID field.


i18n(fr): Adding configuring-astro.md translations

Adding guides/configuring-astro.md into the french translation.
Open and ready for review !

Just a ping @Chrissdroid @Olyno because this one has been hanging around for a few days! Have you come to an agreement on some of these?  :)

not yet, I haven't got the info concerning the opinion of the other translators on this, and to know what we would do with it

Added new comments on previous reviews

Alright, I'll just wait for the checks to merge!  🥳

Oops. I didn't notice that this had been merged. Sorry about that.

I think we will make another pr to fix some stuff you said. A lot of things you said are right changes to do, and i think it should be fix @jbrains


ci(upload-charm): use charmcraft from latest/candidate

Use charmcraft from latest/candidate in upload-charm in order to unify the channel used during integration tests and publishing.
Ref canonical/bundle-kubeflow#993

Closing since this was opened by accident by the canon run.


Obtain best textbooks

Obtain some best-practices books from Bell Laboratories to aid in reducing coding mistakes thereby saving time when debugging enters into the development cycle.

These are the books:

K&R 1978
K&R 1988 (second edition)
C Pitfalls 1988
M6809 Assembly language programming
8080 Assembly language programming


not working on window OS

Issue Summary
HI All,
Hoping someone might be able to help me,  I have inherited a couple of PHP websites to look after at work and we shutting down our exchange server soon, so I need to update the websites to use sendgrid to send out the emails.  I have download the sendgrid-php library and copy the folder into the root directory of the website,  as we not using Composer.
I have then try to send an email using the Quick Start - Hello Email example but each time i get the following response
0
Array
(
[0] =>
)
i have successfully send an email using curl and powershell so i know i'm not getting block by firewall.  But i can't send an email through using PHP.  Any information on how to fix this would be greatly appericated
Many Thanks
Stefen
Technical details:

Windows 2008 R2 SP1
sendgrid-php Version: 7.3.0
PHP Version: 5.6.16  (as of July 03, 2019)

Hello @stefen-hasselberg ,
Have you tried this solution?
Thanks!
With best regards,
Elmer


675 well metadata updates

Closes #675
Currently fails tests due to #707 . Will also need to address #707 to handle this.
Based on changes in #709
Checklist before merging

[x] I added an appropriate entry to CHANGELOG.md

@tcompa Whenever you have a chance to review, it's ready from my side

The current logic of _get_matching_ref_cycle_path_heuristic doesn't work, as two branches out of four (the second and third) look unreachable. Let's review the expected behavior:
HEURISTIC_CASES = [
    (["0", "0_illum_corr"], "1_illum_corr", "0_illum_corr"),  # this works, in the current version
    (["0", "0_illum_corr"], "1", "0"),  # this works, in the current version
    (["0", "0_illum_corr", "0_registered"], "1_illum_corr", "0_illum_corr"),  # this is identical to the first line, in the current version
    (["0", "1", "2", "3"], "0_cycle2", "0"),  # this works, in the current version
    (["0", "1", "2", "3"], "1_cycle2", "1"),  # I am adding this one now, but it would fail in the current version
]

@pytest.mark.parametrize("path_list, path, expected_match", HEURISTIC_CASES)
def test_get_matching_ref_cycle_path_heuristic(
    path_list: list[str], path: str, expected_match: str
):
    match = _get_matching_ref_cycle_path_heuristic(
        path_list=path_list, path=path
    )
    assert match == expected_match

Apart from defining the expected behaviors for _get_matching_ref_cycle_path_heuristic, we also need to determine what is assumed about path_list. A quick fix is to replace for p in path_list with for p in sorted(path_list), but it's TBD whether other order-related edge cases may appear.
The general solution for the ordering problem is to qualify the matching scenarios in a descending-priority order, so that we can make a pass of the list for each one of them.

Thanks for spotting the edge-cases of the _get_matching_ref_cycle_path_heuristic. We should not rely on OME-Zarr filenames in general. But I don't think we'd have general & consistent metadata needed in the OME-Zarr to reliably get this info. e.g. we don't know based on OME-Zarr metadata whether an image has been illumination corrected.
As we don't see a clear other choice for the moment, we get the _get_matching_ref_cycle_path_heuristic. If we can simplify it, all the better!
It's main scope should be handling this case;
(["0", "0_illum_corr", "0_registered"], "1_illum_corr", "0_illum_corr")
If it can also handle the case of having some versions of FOVs saved as separate OME-Zarrs (e.g. your new proposed test case (["0", "1", "2", "3"], "1_cycle2", "1")), that's valuable. But we don't have a clear definition of how names would be handled in all those cases, so we shouldn't get too complex there.

(["0", "0_illum_corr", "0_registered"], "1_illum_corr", "0_illum_corr"),  # this is identical to the first line, in the current version

The purpose here is to test that it handles multiple different suffices & selects the right one.

I was a bit confused, but now I understand that the test case
["0", "1", "2", "3"], "1_cycle2" --> "1"

is only relevant for when FOVs are not fused, which is not currently in scope (ref #707).
For the record, this can be covered with the following logic
    # First matching rule: a path with the same suffix
    for p in sorted_path_list:
        # Split the list path into base and suffix
        p_base, p_suffix = _split_base_suffix(p)
        # If suffices match, it's the match.
        if p_suffix == suffix:
            return p
    # Second matching rule: a path with the same base
    for p in sorted_path_list:
        # Split the list path into base and suffix
        p_base, p_suffix = _split_base_suffix(p)
        # If suffices match, it's the match.
        if p_base == base:  # and maybe some other condition?
            return p
    ...

but I cannot easily understand if this will introduce false positives. Thus I'd rather not include it in the test cases (or, if we do, we should also find the appropriate additional test cases).

Without adding any currently-unsupported match scenario, I introduced some other minor changes (which I can revert if needed) ti make the function more robust:

I dropped unreachable branches, without changing tests.
I am enforcing sorting of path_list, so that ["0", "1", "2", "3"], "0_cycle2" --> "0" and ["1", "0", "2", "3"], "0_cycle2" --> "0" both work.
I am excluding path from path_list (if present), so that ["0", "1", "2", "3"], "3" --> "0".

This sounds good to me and I'm fine to not expand on it more for this PR, let's return when we have actual example data of this needed.
I reviewed the changes and they look good to me. Let's merge! :)


⚠ GitLab Server has degraded performance

In 3a254ee, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 12447 ms

Resolved: GitLab Server performance has improved in 4bdbc03.


Create pull_request_template.md

Adding PR template

@istoga I just saw this, could you  pull off main and integrate this into the team procedures and make a new PR
https://github.com/istoga/Team-Alpha-Vets-Hackathon/blob/main/docs/team-procedures.md


[PE-D][Tester C] Find command feature flaw when searching for common words.

Searching command words such as inputting "find com" into the user command box will return all contacts which may affect the functionality of the product should you be looking for someone whose name happens to be Com as the "com" will highly likely appear in almost every if not all the emails of the students in the contact list. This may severely affect the functionality of the product despite the low likelihood of such a coincidence. As seen in the screenshot below, all the contacts in my contact list were listed out when a "find com" command was given.

Labels: type.FeatureFlaw severity.Medium
original: leehuiyulaura/ped#3

The find feature is designed to search for a particular keyword. Users should use the find feature for their needs - if they are searching for a topic, search for the topic's keyword and not a generic keyword like "com".


[GNB] Inconsistent Continuation interaction with overcap features

Version: <IP_ADDRESS>
AoE Combo with Overcap
Executing Fated Circle via the Demon Slice button (AoE combo overcap) presents Continuation on the same button if the Fated Circle > Fated Brand feature is active.
Expected: Demon Slice > Fated Circle > Fated Brand > Demon Slaughter
Observed: Demon Slice > Fated Circle > Fated Brand > Demon Slaughter
Single Target Combo with Overcap
Executing Burst Strike via the Keen Edge combo (single target overcap) does NOT present Continuation on the same button even if the Burst Strike > Hypervelocity feature is active.
Expected: Keen Edge > Brutal Shell > Burst Strike > Hypervelocity > Solid Barrel
Observed: Keen Edge > Brutal Shell > Burst Strike > Solid Barrel
Note that the respective Continuation options do appear on the associated buttons themselves. In this example, Hypervelocity is presented on the Burst Strike button, but not the Keen Edge button even if overcap is enabled, which is not consistent with AoE button behavior.
WrathDebug.txt

Sorry, I'm failing to understand the issue with AOE. Are you essentially just asking for a Continuation option for AOE?

https://github.com/user-attachments/assets/a0fce855-d8ee-4805-a5c8-883c767296bb
At 0:06 in the video, I used Burst Strike from the Keen Edge button. Hypervelocity does NOT show up on the Keen Edge button the way it should. Instead, it only appears on Burst Strike.
At 0:14 in the video, I used Fated Circle from the Demon Slice button. Fated Brand correctly shows up on both buttons.


chore: updated java to 1.6.0

Upgraded java agent to 1.6.0, based on the aws-otel-java-instrumentation changes: https://github.com/aws-observability/aws-otel-lambda/pull/150
NOTE: We should block merging this PR til we figure out what to do about metrics.

NOTE: We should block merging this PR til we figure out what to do about metrics.

Did this get resolved by adding the OTEL_METRICS_EXPORTER env var?

@NathanielRN yes thank you for calling that out


I2C does not send read when Wire.requestFrom(...)

Boards
AMB82-mini
External Hardware
Saleae Logic8 attached to pin 12, pin 13 (I2C).
Hardware Configuration
satel-vl53l7cx modified to bypass onboard regulator, so SB1 short and SB2 open, then AVDD=IOVDD (sensor pin - AMB82-mini pin):

SDA - pin 12
SCL - pin 13
GND - GND
IOVDD - VDD33

(Note: fully functional and tested with a few STM32 boards, ESP32, and similar)
Version
v4.0.8
IDE Name
Arduino IDE 2.3.3
Operating System
WIndows 10, Windows 11, Ubuntu 22.04
Auto Flash Mode
Disable
Erase All Flash Memory (16MB)
Disable
Standard Lib
Arduino_STD_PRINTF
Upload Speed
2000000
Description
When I checked If sensor initializes properly, I found, that I2C Write is OK but I2C Read writes only the address but never start read. The read part is totally missing. I do not have other I2C readable sensors that have simple code. So I will not provide code sample to reproduce, but it should be any read attempt.

Sketch
//code of functions I will use:

typedef struct
{
  TwoWire *port; //== &Wire
  uint16_t address; //== 0x52
} VL53L7CX_Platform;

uint8_t VL53L7CX_RdByte(
  VL53L7CX_Platform *p_platform,
  uint16_t register_address,
  uint8_t *p_value)
{
  uint8_t status = 0;
  p_platform->port->beginTransmission(p_platform->address>>1);
  p_platform->port->write(highByte(register_address));
  p_platform->port->write(lowByte(register_address));
  p_platform->port->endTransmission();
  p_platform->port->requestFrom(p_platform->address>>1, 1U);
  *p_value = p_platform->port->read();
return status;
}

uint8_t VL53L7CX_WrByte(
  VL53L7CX_Platform *p_platform,
  uint16_t register_address,
  uint8_t value)
{
  uint8_t status = 0;
  p_platform->port->beginTransmission(p_platform->address>>1);
  p_platform->port->write(highByte(register_address));
  p_platform->port->write(lowByte(register_address));
  p_platform->port->write(value);
  status =  p_platform->port->endTransmission();
  return status;
}

//Initialization send these messages:

...
/* SW reboot sequence */
status |= VL53L7CX_WrByte(&(p_dev->platform), 0x7fff, 0x00);
status |= VL53L7CX_WrByte(&(p_dev->platform), 0x0009, 0x04);
status |= VL53L7CX_WrByte(&(p_dev->platform), 0x000F, 0x40);
status |= VL53L7CX_WrByte(&(p_dev->platform), 0x000A, 0x03);
status |= VL53L7CX_RdByte(&(p_dev->platform), 0x7FFF, &tmp);
status |= VL53L7CX_WrByte(&(p_dev->platform), 0x000C, 0x01);
...

//As seen on the logic analyzator image, there is Write(index,data) [ADDR(W), 0x00, 0x01, 0x03, STOP],
//then Write(index)/Read(data) [ADDR(W), 0x7F, 0xFF] but missing Read(data) part which should be
//[ADDR+1(R), DATA]. It continues with another Write(index, data) [ADDR, 0x00, 0x0C, 0x01].

//There is expected missing Read part where data is received from slave buffer.

[X] I confirm I have checked online documentation, FAQ, GitHub Wiki and existing/closed issues.

I tried various implementation of the same Write and Read/Write functions and all do the same output on logic analyzer. The Read section is totally missing.

Hi @eLEcTRiCZiTy,
Please add a delay right after the Wire.requestFrom(...) API.
Thank you.


Zero-copy send support for the netlrts machine layer

Original issue: https://charm.cs.illinois.edu/redmine/issues/1459

In the netlrts machine layer, it's pretty easy to stream data from an arbitrary address to a remote recipient on request. We can use this to implement zero-copy sends for the memory footprint reduction, and to take copying time overhead off the worker threads and onto the comm thread.

Original date: 2017-05-09 00:18:41

The current netlrts layer (UDP) in machine-eth.c sends a Datagram header with every packet it sends.
For every packet, it creates a header at (char *ptr - DGRAM_HEADER_SIZE) and sends it over. The receiver uses the packet information to assemble packets together.
I am guessing that we’re able to use the DGRAM_HEADER_SIZE bytes before the packet ptr because of two reasons:

We know that the previous packet has been delivered? (using acks)
It is the Charm++ owned copied buffer and free from user intervention and will be freed after the message send.

But, if we’re to send a user buffer using this scheme, how do we send a header with every packet? (as we can’t touch it to send the header info at a negative offset)

Original date: 2017-05-09 00:28:05

We could do the packetization in a set aside buffer that we copy the user's data through as we send it. The key is to tightly constrain the size of that buffer, making it just large enough to get full network bandwidth. If the packet injection is synchronous, then that buffer only needs to hold 1 packet.

What is the current level of support for zero copy in netlrts?

There hasn't been any work to support Zcpy in netlrts. It currently uses the copy based generic layer.


[Bug] Wrong touch behavior with annotation tools

Describe the Bug
In the example page stackManipulationToolsTouch, changing the default tool, WindowLevelTool for an annotation tool like LengthTool doesn't work as mentioned in the docs.
For example, in this example page it explains that each tool separated by gestures with one or two or three fingers should work correctly, and it does, but only with the WindowLevelTool, if I replace this tool with LengthTool it works only occasionally.
Here is an example video, trying to zoom with two fingers.
https://github.com/cornerstonejs/cornerstone3D/assets/24579681/68b6544b-ea19-4d6f-8f2d-e9a8f89811e2
My investigation leads me to sometimes the system only captures one finger when i physically put two fingers and then when I start to drag the system recognizes my two fingers, but it doesn't work because the system already started the LengthTool process, here is an image when I'm testing this described behavior.

I'm working on figuring out how to fix this and open for you a pr with the solution, but if you know where I should be looking, it would be great.
Steps to Reproduce

open the example page stackManipulationToolsTouch
replace WindowLevelTool for LengthTool
start the example yarn example stackmanipulationtoolstouch
try to drag with two fingers in any phone or tablet

The current behavior
Currently, when it's active an annotation tool with one (finger / click) and it's active a (move / zoom) tool with two fingers, the two fingers behavior only works occasionally.
The expected behavior
To work as described in the docs, different tools separated by (gestures / numTouchPoints) should work fine always, not occasionally.
OS
Any os
Node version
18.16.0
Browser
Any browser

I solved this, identifying the touchpoints of the users and then canceling the action in the _dragCallback function of tool classes


Relax the SLSA Provenance schema validation

Chains is not populating the invocation.configSource.uri attribute correctly, due to https://github.com/tektoncd/chains/issues/934
This change relaxes the schema validation until the issue in Chains is fixed and widely adopted.
Ref: RHTAPBUGS-857

codecov you're drunk.


Remove unnecessary containers constraint from stack.yaml

We used to need a slightly in-the-future version I think, but now we've updated
the resolver we get one with what we need.

Pull Request Test Coverage Report for Build 702

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.05%) to 64.275%

Files with Coverage Reduction
New Missed Lines
%

src/Clapi/TextSerialisation.hs
1
97.98%

Totals

Change from base Build 700:
-0.05%

Covered Lines:
1317

Relevant Lines:
2049

💛  - Coveralls


gcsfuse: 0.23.0 -> 0.28.1

Motivation for this change
fixing @r-ryantm updates
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @
[1 built, 0.0 MiB DL]
https://github.com/NixOS/nixpkgs/pull/68250
1 package were build:
gcsfuse

nix-review builds for me macos 10.13, binary gives me --help options fine.


Concept page – aggregated identifiability rating

Concept page shows an aggregated idetificability rating for the items that make up that concept
As a researcher
I want to see an aggregated identifiability rating for the items that make up that concept
in order to understand how identifiable the concept is and therefore how it might affect my application
Scenarios
Given I am an anonymous user
And I'm viewing the FSMP6Y concept page
When I review the content
Then I see an aggregated identifiability rating for the items in that concept
NEEDS CONSIDERATION: is it possible for the items in a concept to have different identifiability ratings? How do we show that if possible?

Just for clarity, this is not an attribute on concept, it's derived from the data items contained within it.

Query over how we show a concept's aggregated ID rating when there may be more than one. Many ways we can slice it including making CIN\CLA\ETC a different category. We will know more when the data is loaded into F&E. Paused for now.


Debrand the client

There are additional places like installation path etc. which I also changed in the update branch (see #1753)

@micheljung how did you create the splash screen initially that needs to be changed as well. I see the png and psd files