[BUG] Observed NullPointerException while creating VM

Describe the bug
We are migrating to resourcemanager SDK from old azure SDK. In our testing, when we tried to create 300 vms, around 21 VMs failed with NullPointerException.
Exception or Stack Trace
[error] VM creation failed for VM: qanpperf420-088 with reason null
java.lang.NullPointerException
at com.azure.resourcemanager.compute.implementation.VirtualMachineImpl.initializeDataDisks(VirtualMachineImpl.java:2356)
at com.azure.resourcemanager.compute.implementation.VirtualMachineImpl.reset(VirtualMachineImpl.java:1958)
at com.azure.resourcemanager.compute.implementation.VirtualMachineImpl.lambda$createResourceAsync$7(VirtualMachineImpl.java:1842)
at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:113)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249)
at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2398)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onSubscribe(MonoFlatMap.java:238)
at reactor.core.publisher.MonoJust.subscribe(MonoJust.java:55)
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:64)
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:157)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249)
at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:127)
at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:127)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoCollect$CollectSubscriber.onComplete(MonoCollect.java:159)
at reactor.core.publisher.FluxMap$MapSubscriber.onComplete(FluxMap.java:142)
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyInner.onComplete(MonoFlatMapMany.java:260)
at reactor.core.publisher.FluxIterable$IterableSubscription.fastPath(FluxIterable.java:362)
at reactor.core.publisher.FluxIterable$IterableSubscription.request(FluxIterable.java:227)
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyMain.onSubscribeInner(MonoFlatMapMany.java:150)
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyInner.onSubscribe(MonoFlatMapMany.java:245)
at reactor.core.publisher.FluxIterable.subscribe(FluxIterable.java:165)
at reactor.core.publisher.FluxIterable.subscribe(FluxIterable.java:87)
at reactor.core.publisher.Flux.subscribe(Flux.java:8469)
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyMain.onNext(MonoFlatMapMany.java:195)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoCacheTime.subscribeOrReturn(MonoCacheTime.java:151)
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:57)
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:157)
at reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:82)
at reactor.core.publisher.FluxMap$MapSubscriber.onNext(FluxMap.java:120)
at reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onNext(FluxOnErrorResume.java:79)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249)
at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2398)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onSubscribe(MonoFlatMap.java:238)
at reactor.core.publisher.MonoJust.subscribe(MonoJust.java:55)
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:64)
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:157)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249)
at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2398)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onSubscribe(MonoFlatMap.java:238)
at reactor.core.publisher.MonoJust.subscribe(MonoJust.java:55)
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:64)
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:157)
at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.complete(MonoIgnoreThen.java:284)
at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.onNext(MonoIgnoreThen.java:187)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249)
at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2398)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onSubscribe(MonoFlatMap.java:238)
at reactor.core.publisher.MonoJust.subscribe(MonoJust.java:55)
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:64)
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:157)
at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:127)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoCollect$CollectSubscriber.onComplete(MonoCollect.java:159)
at reactor.core.publisher.FluxMap$MapSubscriber.onComplete(FluxMap.java:142)
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyInner.onComplete(MonoFlatMapMany.java:260)
at reactor.core.publisher.FluxIterable$IterableSubscription.fastPath(FluxIterable.java:362)
at reactor.core.publisher.FluxIterable$IterableSubscription.request(FluxIterable.java:227)
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyMain.onSubscribeInner(MonoFlatMapMany.java:150)
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyInner.onSubscribe(MonoFlatMapMany.java:245)
at reactor.core.publisher.FluxIterable.subscribe(FluxIterable.java:165)
at reactor.core.publisher.FluxIterable.subscribe(FluxIterable.java:87)
at reactor.core.publisher.Flux.subscribe(Flux.java:8469)
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyMain.onNext(MonoFlatMapMany.java:195)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoCacheTime$CoordinatorSubscriber.signalCached(MonoCacheTime.java:337)
at reactor.core.publisher.MonoCacheTime$CoordinatorSubscriber.onNext(MonoCacheTime.java:354)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoCollectList$MonoCollectListSubscriber.onComplete(MonoCollectList.java:128)
at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onComplete(FluxMapFuseable.java:150)
at reactor.core.publisher.FluxUsing$UsingSubscriber.onComplete(FluxUsing.java:236)
at reactor.core.publisher.FluxMap$MapSubscriber.onComplete(FluxMap.java:142)
at reactor.core.publisher.FluxFilter$FilterSubscriber.onComplete(FluxFilter.java:166)
at reactor.core.publisher.FluxTakeUntil$TakeUntilPredicateSubscriber.onComplete(FluxTakeUntil.java:121)
at reactor.core.publisher.FluxTakeUntil$TakeUntilPredicateSubscriber.onNext(FluxTakeUntil.java:99)
at reactor.core.publisher.FluxFlatMap$FlatMapMain.drainLoop(FluxFlatMap.java:712)
at reactor.core.publisher.FluxFlatMap$FlatMapMain.drain(FluxFlatMap.java:588)
at reactor.core.publisher.FluxFlatMap$FlatMapInner.onSubscribe(FluxFlatMap.java:955)
at reactor.core.publisher.MonoJust.subscribe(MonoJust.java:55)
at reactor.core.publisher.Mono.subscribe(Mono.java:4400)
at reactor.core.publisher.FluxFlatMap$FlatMapMain.onNext(FluxFlatMap.java:426)
at reactor.core.publisher.FluxRepeatPredicate$RepeatPredicateSubscriber.onNext(FluxRepeatPredicate.java:86)
at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2398)
at reactor.core.publisher.Operators$MultiSubscriptionSubscriber.set(Operators.java:2194)
at reactor.core.publisher.Operators$MultiSubscriptionSubscriber.onSubscribe(Operators.java:2068)
at reactor.core.publisher.FluxJust.subscribe(FluxJust.java:68)
at reactor.core.publisher.InternalFluxOperator.subscribe(InternalFluxOperator.java:62)
at reactor.core.publisher.FluxRepeatPredicate$RepeatPredicateSubscriber.resubscribe(FluxRepeatPredicate.java:120)
at reactor.core.publisher.FluxRepeatPredicate.subscribeOrReturn(FluxRepeatPredicate.java:50)
at reactor.core.publisher.InternalFluxOperator.subscribe(InternalFluxOperator.java:55)
at reactor.core.publisher.FluxUsing.subscribe(FluxUsing.java:114)
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:64)
at reactor.core.publisher.MonoCacheTime.subscribeOrReturn(MonoCacheTime.java:143)
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:57)
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:157)
at reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onNext(FluxOnErrorResume.java:79)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249)
at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2398)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onSubscribe(MonoFlatMap.java:238)
at reactor.core.publisher.MonoJust.subscribe(MonoJust.java:55)
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:64)
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:157)
at reactor.core.publisher.MonoCreate$DefaultMonoSink.success(MonoCreate.java:165)
at com.azure.core.http.okhttp.OkHttpAsyncHttpClient$OkHttpCallback.onResponse(OkHttpAsyncHttpClient.java:191)
at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
Suppressed: java.lang.Exception: #block terminated with an error
at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:99)
at reactor.core.publisher.Mono.block(Mono.java:1707)
at com.azure.resourcemanager.resources.fluentcore.model.implementation.CreatableUpdatableImpl.create(CreatableUpdatableImpl.java:255)
at com.azure.resourcemanager.resources.fluentcore.model.implementation.CreatableUpdatableImpl.create(CreatableUpdatableImpl.java:29)
To Reproduce
We created 300VMs. Provisioninig succeeded for all 300VMs.
We are deleting and creating each VM again one by one. Exception observed for 21 VMs while provisioning in this step.
We use threadpool of size 20 for handling provisioning for 300VMs (Each thread handles a VM).
For these 21 VMs where NPE observed, we see that VMs are actually created in azure portal.
Code Snippet
TokenCredential credentials = new ClientSecretCredentialBuilder().clientId(clientID).clientSecret(key).tenantId(tenantID).build();
AzureProfile profile = new AzureProfile(tenantID, subscription, com.azure.core.management.AzureEnvironment.AZURE);
HttpClient client = new OkHttpAsyncHttpClientBuilder()
.connectionTimeout(Duration.ofMinutes(5))
.readTimeout(Duration.ofMinutes(5)).build();
azureInstance = AzureResourceManager.configure().withPolicy(new RetryPolicy())
.withHttpClient(client)
.withLogLevel(HttpLogDetailLevel.NONE)
.authenticate(credentials, profile)
.withSubscription(this.subscription);
// OS disk and NIC are created before this. Please let me know if you need that code as well.
VirtualMachine machine = azureInstance.virtualMachines().define(newVMName).withRegion(region)
.withExistingResourceGroup(rg).withExistingPrimaryNetworkInterface(nic)
.withSpecializedOSDisk(osDisk, osType).withSize(vmSize)
.withBootDiagnostics(diagStorage)
.withTag(key, value)
.withLicenseType(license).create();
Expected behavior
VMs should be created successfully. 21 desktops failed with same exception.
Screenshots
If applicable, add screenshots to help explain your problem.
Setup (please complete the following information):

OS: [e.g. iOS] Linux
IDE: [e.g. IntelliJ] Not applicable
Library/Libraries: [e.g. com.azure:azure-core:1.16.0 (groupId:artifactId:version)] azure-resourcemanager:2.10.0, azure-core-http-okhttp:1.7.6
Java version: [e.g. 8] 8
App Server/Environment: [e.g. Tomcat, WildFly, Azure Function, Apache Spark, Databricks, IDE plugin or anything special] Akka server
Frameworks: [e.g. Spring Boot, Micronaut, Quarkus, etc]  Play framework

If you suspect a dependency version mismatch (e.g. you see NoClassDefFoundError, NoSuchMethodError or similar), please check out Troubleshoot dependency version conflict article first. If it doesn't provide solution for the problem, please provide:

verbose dependency tree (mvn dependency:tree -Dverbose)
exception message, full stack trace, and any available logs

Additional context
Add any other context about the problem here.
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Bug Description Added
[x] Repro Steps Added
[x] Setup information Added

Hi @Prudvidhard, thank you for reaching out to us on GitHub. Someone from the ARM SDK team will follow up with you shortly.
/cc @weidongxu-microsoft

@XiaofeiCao Please take a look.
@Prudvidhard Do you see any error from Activity Log in Portal?
I see you disabled the logging, but it will definitely help if you have some logging for us on failed VMs.

From current code
https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/resourcemanager/azure-resourcemanager-compute/src/main/java/com/azure/resourcemanager/compute/implementation/VirtualMachineScaleSetVMImpl.java#L721-L723
initializeDataDisks method only access variable managedDataDisks. And that variable is final so it cannot be null.
https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/resourcemanager/azure-resourcemanager-compute/src/main/java/com/azure/resourcemanager/compute/implementation/VirtualMachineScaleSetVMImpl.java#L68

Thanks @weidongxu-microsoft. We upgraded the library to 2.14.0. Still observed NullPointerException.
The number of NPE occurrences was reduced. We tried with 300 vms, and observed the issue for one VM.
About logs, which level of logging do you need? is LogLevel.BASIC enough?
Caused by: java.lang.NullPointerException
at com.azure.resourcemanager.compute.implementation.VirtualMachineImpl.initializeDataDisks(VirtualMachineImpl.java:2556)
at com.azure.resourcemanager.compute.implementation.VirtualMachineImpl.reset(VirtualMachineImpl.java:2140)
at com.azure.resourcemanager.compute.implementation.VirtualMachineImpl.lambda$createResourceAsync$7(VirtualMachineImpl.java:2024)
at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:113)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249)
at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2398)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onSubscribe(MonoFlatMap.java:238)
at reactor.core.publisher.MonoJust.subscribe(MonoJust.java:55)
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:64)
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:157)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249)
at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:127)
at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:127)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoCollect$CollectSubscriber.onComplete(MonoCollect.java:159)
at reactor.core.publisher.FluxMap$MapSubscriber.onComplete(FluxMap.java:142)
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyInner.onComplete(MonoFlatMapMany.java:260)
at reactor.core.publisher.FluxIterable$IterableSubscription.fastPath(FluxIterable.java:362)
at reactor.core.publisher.FluxIterable$IterableSubscription.request(FluxIterable.java:227)
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyMain.onSubscribeInner(MonoFlatMapMany.java:150)
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyInner.onSubscribe(MonoFlatMapMany.java:245)
at reactor.core.publisher.FluxIterable.subscribe(FluxIterable.java:165)
at reactor.core.publisher.FluxIterable.subscribe(FluxIterable.java:87)
at reactor.core.publisher.Flux.subscribe(Flux.java:8469)
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyMain.onNext(MonoFlatMapMany.java:195)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoCacheTime.subscribeOrReturn(MonoCacheTime.java:151)
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:57)
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:157)
at reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:82)
at reactor.core.publisher.FluxMap$MapSubscriber.onNext(FluxMap.java:120)
at reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onNext(FluxOnErrorResume.java:79)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249)
at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2398)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onSubscribe(MonoFlatMap.java:238)
at reactor.core.publisher.MonoJust.subscribe(MonoJust.java:55)
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:64)
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:157)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249)
at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2398)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onSubscribe(MonoFlatMap.java:238)
at reactor.core.publisher.MonoJust.subscribe(MonoJust.java:55)
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:64)
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:157)
at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.complete(MonoIgnoreThen.java:284)
at reactor.core.publisher.MonoIgnoreThen$ThenIgnoreMain.onNext(MonoIgnoreThen.java:187)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249)
at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2398)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onSubscribe(MonoFlatMap.java:238)
at reactor.core.publisher.MonoJust.subscribe(MonoJust.java:55)
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:64)
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:157)
at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:127)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoCollect$CollectSubscriber.onComplete(MonoCollect.java:159)
at reactor.core.publisher.FluxMap$MapSubscriber.onComplete(FluxMap.java:142)
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyInner.onComplete(MonoFlatMapMany.java:260)
at reactor.core.publisher.FluxIterable$IterableSubscription.fastPath(FluxIterable.java:362)
at reactor.core.publisher.FluxIterable$IterableSubscription.request(FluxIterable.java:227)
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyMain.onSubscribeInner(MonoFlatMapMany.java:150)
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyInner.onSubscribe(MonoFlatMapMany.java:245)
at reactor.core.publisher.FluxIterable.subscribe(FluxIterable.java:165)
at reactor.core.publisher.FluxIterable.subscribe(FluxIterable.java:87)
at reactor.core.publisher.Flux.subscribe(Flux.java:8469)
at reactor.core.publisher.MonoFlatMapMany$FlatMapManyMain.onNext(MonoFlatMapMany.java:195)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoCacheTime$CoordinatorSubscriber.signalCached(MonoCacheTime.java:337)
at reactor.core.publisher.MonoCacheTime$CoordinatorSubscriber.onNext(MonoCacheTime.java:354)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoCollectList$MonoCollectListSubscriber.onComplete(MonoCollectList.java:128)
at reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onComplete(FluxMapFuseable.java:150)
at reactor.core.publisher.FluxUsing$UsingSubscriber.onComplete(FluxUsing.java:236)
at reactor.core.publisher.FluxMap$MapSubscriber.onComplete(FluxMap.java:142)
at reactor.core.publisher.FluxFilter$FilterSubscriber.onComplete(FluxFilter.java:166)
at reactor.core.publisher.FluxTakeUntil$TakeUntilPredicateSubscriber.onComplete(FluxTakeUntil.java:121)
at reactor.core.publisher.FluxTakeUntil$TakeUntilPredicateSubscriber.onNext(FluxTakeUntil.java:99)
at reactor.core.publisher.FluxFlatMap$FlatMapMain.drainLoop(FluxFlatMap.java:712)
at reactor.core.publisher.FluxFlatMap$FlatMapMain.drain(FluxFlatMap.java:588)
at reactor.core.publisher.FluxFlatMap$FlatMapInner.onSubscribe(FluxFlatMap.java:955)
at reactor.core.publisher.MonoJust.subscribe(MonoJust.java:55)
at reactor.core.publisher.Mono.subscribe(Mono.java:4400)
at reactor.core.publisher.FluxFlatMap$FlatMapMain.onNext(FluxFlatMap.java:426)
at reactor.core.publisher.FluxRepeatPredicate$RepeatPredicateSubscriber.onNext(FluxRepeatPredicate.java:86)
at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2398)
at reactor.core.publisher.Operators$MultiSubscriptionSubscriber.set(Operators.java:2194)
at reactor.core.publisher.Operators$MultiSubscriptionSubscriber.onSubscribe(Operators.java:2068)
at reactor.core.publisher.FluxJust.subscribe(FluxJust.java:68)
at reactor.core.publisher.InternalFluxOperator.subscribe(InternalFluxOperator.java:62)
at reactor.core.publisher.FluxRepeatPredicate$RepeatPredicateSubscriber.resubscribe(FluxRepeatPredicate.java:120)
at reactor.core.publisher.FluxRepeatPredicate.subscribeOrReturn(FluxRepeatPredicate.java:50)
at reactor.core.publisher.InternalFluxOperator.subscribe(InternalFluxOperator.java:55)
at reactor.core.publisher.FluxUsing.subscribe(FluxUsing.java:114)
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:64)
at reactor.core.publisher.MonoCacheTime.subscribeOrReturn(MonoCacheTime.java:143)
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:57)
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:157)
at reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onNext(FluxOnErrorResume.java:79)
at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1816)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:249)
at reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2398)
at reactor.core.publisher.MonoFlatMap$FlatMapInner.onSubscribe(MonoFlatMap.java:238)
at reactor.core.publisher.MonoJust.subscribe(MonoJust.java:55)
at reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:64)
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:157)
at reactor.core.publisher.MonoCreate$DefaultMonoSink.success(MonoCreate.java:165)
at com.azure.core.http.okhttp.OkHttpAsyncHttpClient$OkHttpCallback.onResponse(OkHttpAsyncHttpClient.java:191)
at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519)
... 3 more
Suppressed: java.lang.Exception: #block terminated with an error
at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:99)
at reactor.core.publisher.Mono.block(Mono.java:1707)
at com.azure.resourcemanager.resources.fluentcore.model.implementation.CreatableUpdatableImpl.create(CreatableUpdatableImpl.java:255)
at com.azure.resourcemanager.resources.fluentcore.model.implementation.CreatableUpdatableImpl.create(CreatableUpdatableImpl.java:29)

@Prudvidhard
I actually referred to a wrong class. VirtualMachine would be here
https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/resourcemanager/azure-resourcemanager-compute/src/main/java/com/azure/resourcemanager/compute/implementation/VirtualMachineImpl.java#L2556
From the code, the storageProfile in service response is null, which should not be, as it should contain at least information about osDisk. (@XiaofeiCao correct me if I am wrong)
Hence, our suspicion is that a few of the VM is not configure correctly by service, or maybe only the response of the service is incorrect.
For logging, if possible, use HttpLogDetailLevel.BODY.
            AzureResourceManager azure = AzureResourceManager
                .configure()
                .withLogLevel(HttpLogDetailLevel.BODY)
                .authenticate(credential, profile)
                .withDefaultSubscription();

@weidongxu-microsoft
If you can confirm just the response is incorrect but VM is configured properly, as a temporary fix on this exception we will make
azureResourceManager.virtualMachines().getByResourceGroup(resourceGroup, vmName) call,
if this call succeeds we will ignore the exception. Please let me know if this is fine.
I will try to reproduce the issue with HttpLogDetailLevel.BODY log level.

@Prudvidhard
This is still to be seen. We have to try to reproduce it to find out.
Does the 21 VM in the first instance, and the 1 VM in the second instance works as expected?

@Prudvidhard

To Reproduce
We created 300VMs. Provisioninig succeeded for all 300VMs.
We are deleting and creating each VM again one by one. Exception observed for 21 VMs while provisioning in this step.
We use threadpool of size 20 for handling provisioning for 300VMs (Each thread handles a VM).
For these 21 VMs where NPE observed, we see that VMs are actually created in azure portal.

I don't quite follow here. From my understanding:

First, you created 300VMs and all of them succeeded with no NPE.
Then you performed: delete VM, create it again(with same name?), for 300 times, using a thread pool of size 20.
In the previous step, you experienced 21 VMs failure with NPE.

Am I correct on the upper procedures? If so, how do you perform the second step(delete and create), can you provide the code snippet please?


Consolidate HttpObjectDecoder default values into constants

Motivation
HttpObjectDecoder and its associated classes make frequent use of
default values for maxInitialLineLength, maxHeaderSize, maxChunkSize,
etc. Today, these defaults are defined in-line in constructors and
duplicated across many classes. This repetition is more prone to error
and inconsistencies.
Furthermore, due to the current lack of builder support, if a user wants
to change just one of these values (e.g., maxHeaderSize), they are also
required to know and repeat the other default values (e.g.,
maxInitialLineLength and maxChunkSize).
The primary motivation for this change is as we are considering adding
another constructor parameter (for multiple content length behavior),
appending this parameter may require some users to have prior knowledge
of the default initialBufferSize, and it would be cleaner to allow them
to reference the default constant.
Modifications

Consolidate the HttpObjectDecoder default values into public constants
Reference these constants where possible

Result
No functional change. Additional telescoping constructors will be easier
and safer to write. Users may have an easier experience changing single
parameters.

/cc @normanmaurer @NiteshKant

@netty-bot test this please

@Bennett-Lynch thanks a lot!

Thank you both.


Add test for Transaction Payment on zero balance account

This adds a test which confirms that an account with zero balance, triggering a transaction with Pays::No, will not trigger any events such as AccountKilled

Found that this test does not actually reveal any issues, but seems like a good enough test to add anyway.


Replace "Mac OS" and "OS X" with "macOS"

OS X has been renamed to "macOS". More details here.

@leo Thanks for this! 🙇
Looks good to me. @atom/feedback should we 🚢 this sooner rather than later to minimize potential merge conflicts caused by the markdown table commit bombs?

:+1: on merging.

There are a few instances of OSX (without the space) left in here – would you mind getting those too? (Except for in .travis.yml, unless Travis CI already updated their config values 😆)

Thanks for doing this! 🚀 🎸


Don't build with stdlib assertions on Linux

Apparently we have been building with stdlib assertions enabled on Linux. A recent change (https://github.com/apple/swift/pull/33390) caused a massive performance regression on Linux, which brought this to light.

@swift-ci smoke test

@swift-ci test centos 7

@swift-ci test centos 7

@swift-ci test centos 7

@swift-ci test centos 7

@swift-ci test centos 7

@swift-ci test centos 7

@swift-ci test amazon linux 2

Build failed
Swift Test Amazon Linux 2 Platform
Git Sha - 27102e2a997d3ccbf1614136692ab29908c206ed

@swift-ci test amazon linux 2

Build failed
Swift Test Amazon Linux 2 Platform
Git Sha - 27102e2a997d3ccbf1614136692ab29908c206ed

@drexin With this change, it looks like none of the Linux bots test the stdlib with assertions enabled. That disables all the swift reflection tests for ELF. Is there a more targeted option, like disabling stdlib-asserts on a subset of the Linux builders?
cc @augusto2112 @adrian-prantl

@vedantk I think the best option would be to configure the bots in question to enable building with stdlib-asserts. Enabling them by default does not seem like the correct thing to do.
/cc @atrick

@vedantk what really does not make sense here is that build-script --assertions enables runtime verification. Now, on top of that, we have a "lightweight_assertions" mixin that also enables runtime verification. That means that almost every time someone reports benchmark results or performance bugs from their own Swift build, the information is misleading until eventually someone wastes time tracking that down, which is often months later. We've had people working on Swift for up to a year without realizing that all their results were bogus. How long was linux being built incorrectly because of this?

@drexin @atrick let me try to explain the problem we're having, and maybe we can come up with a solution together. Basically, we have some runtime functions that return metadata-related information when dealing with Linux (this is due to some constraints in the ELF format). We use these to provide the reflection tests the information they need to run themselves. Because this is used exclusively during testing, and shouldn't do anything on release, these functions have an empty body when assertions are off. So now you see what the problem is from our perspective. Do you have any suggestions on how we can solve this issue?

Yep, the release build obviously should not enable any runtime verification by default. I'm very unhappy with the build-script defaults, but hopefully this PR fixed your specific problem.

@atrick the problem is since stdlib's assertions are off, we can't run the reflection tests, since the function functions we added should only run with assertions on.

Reflection testing would need the build with --stdlib-assertions. There are other stdlib unit tests that also require stdlib asserts enabled.


[BUG] single-node replicaset mongo get pymongo.errors.InvalidOperation: Can only use session with the MongoClient that started it

Describe the bug
I use single-node replicaset mongo for local development with Docker and for test stage in CI.
If I use transactions I got error:
pymongo.errors.InvalidOperation: Can only use session with the MongoClient that started it
To Reproduce
client = AsyncIOMotorClient("mongodb://mongodb:27017/db_name?appName=verse-api&maxPoolSize=100&minPoolSize=1&maxConnecting=2&w=majority&readConcernLevel=majority&readPreference=primary&retryReads=false&retryWrites=false&directConnection=true")
async with await client.start_session() as s, s.start_transaction():
    await SomeModel.find_one(SomeModel.id == some_id).update(
        Set({SomeModel.status: "new_status"}),
        response_type=UpdateResponse.NEW_DOCUMENT,
        session=s,
    )

Dockerfile:
FROM mirror.gcr.io/mongo:8
COPY docker/init-replica.sh /docker-entrypoint-initdb.d/init-replica.sh
RUN chmod +x /docker-entrypoint-initdb.d/init-replica.sh
CMD ["mongod", "--replSet", "rs01", "--bind_ip_all"]

init-replica.sh:
#!/bin/bash

until mongosh --host localhost:27017 --eval 'quit(0)' &>/dev/null; do
    echo "Waiting for mongod to start..."
    sleep 5
done

mongosh --eval 'rs.initiate({_id: "rs01", members: [{ _id: 0, host: "localhost:27017" }]})'

Expected behavior
Transaction success
Additional context
MongoClient from PyMongo and AsyncIOMotorClient from Motor works as expected

Hi, please provide a fully runnable example Python code that reproduces this problem.
Do you call init_beanie() ?

The problem was in cache dependency for FastAPI, which is not updates in each pytest test


Basic rust anyof support

PR checklist

[ ] Read the contribution guidelines.
[ ] Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
[ ] Run the following to build the project and update samples:./mvnw clean package
./bin/generate-samples.sh
./bin/utils/export_docs_generators.sh

Commit all changed files.
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
For Windows users, please run the script in Git BASH.
[ ] File the PR against the correct branch: master (6.0.1) (patch release), 6.1.x (breaking changes with fallbacks), 7.0.x (breaking changes without fallbacks)
[ ] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.


feat: adding samples, tests, documentation

continuing to flesh out basic structure of library: samples, dependences, README, etc.

Please make sure to open a PR against sloth to add this to the list of repos we track :)


Event ordering

These changes ensure that the client sends auth information and subscriptions before attempting to publish. The connect/reconnect event is now emitted before any publish/flush callbacks are called. This also fixes a unit test issue where clients weren't being closed after their tests were finished running, which sometimes failed unrelated tests when reconnect attempts were exhausted.

I encountered a spurious failure in my last PR. Notice the port in the uncaught error is 1423, the port used for the basic test suite, but the error is reported under the binary test suite.

LGTM, had one minor comment on the sendSubscriptions not buffering and sending direct, probably not a big deal.
Do we know how this effects performance if at all?

Thank you BTW, good stuff here.

I ran the benchmarks on a node:5.4-onbuild Docker container and saw very little change. That is what I expected because this is mostly a change in how (re)connection setup works. Do you think it's worthwhile to test reconnection time when the client has boatloads of subscriptions? I can put something together.

I think it should not hold up this PR, but would be a good idea IMO.

Thanks again for the PR!


Bugfix and tests for rgbToHex, new utility rgbToString.

This PR:

Fixes https://github.com/mexitek/phpColors/issues/25 - a bug where rgbToHex has problems converting RGB value '0'.
implements tests for rgbToHex in colorConvert.phpt.
adds utility method rgbToString, to convert an RGB array to its CSS string representation.
fixes whitespace, indentation, & commenting typos.

Thanks for the contribution!

@mexitek: Please also release to packagist!

@strarsis I just added you as a collaborator to this repo. Feel free to help me out. I haven't used PHP in about 6 years now. Feel free to take the reins as much as you'd like.

@strarsis I actually already had an account with packagist, I just forgot. I updated the webhook so changes should be flowing through now.
Thanks for all the contributions!

No worries, thanks for accepting my PR and welcoming me as a contributor 😄


switching to certain tags results in 500

Description
Trying to switch to some tags of linux kernel results in 500. List of affected tags: v2.6.11, v2.6.11-tree (2 first tags, did not find other problematic ones).
Can be seen on gitea.com: https://gitea.com/marktsai0316/linux/src/tag/v2.6.11
Note: repository linked above shows 0 tags but they exist in revision list:

On my instance it shows proper tag amount but the error for those first 2 tags is the same.
Error message: ...ules/context/repo.go:945:func1() [E] [62aa070c] GetTagCommit: object does not exist [id: c39ae07f393806ccf406ef966e9a15afc43cc36a, rel_path: ]
Gitea Version
1.17.0+dev-711-g1fef9a2d6 and  1.17.0+dev-719-gf0ce5470e
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
Locally compiled binary
Database
PostgreSQL

Github lists these as well but 404s: https://github.com/torvalds/linux/tree/v2.6.11-tree


#82 Fix string encyptor injected code with ASCII names

Fix #82 - change non-ASCII injected objects names with ASCII names.
For details see https://github.com/dotnet/runtime/issues/11335

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


LogFactory: SuspendLogging() does not suspend if ResumeLogging() was called before

NLog version: 5.0.0-RC2 (the GitHub code as of 2022-March-01)
Platform: .NET 5

What is the current result?
Multiple (accidental) calls to ResumeLogging() increase the internal _logsEnabled counter to values above 0. It should be 0 maximum.
As a consequence, a call to SuspendLogging() does not suspend.

What is the expected result?
SuspendLogging() should always suspend, no matter how often ResumeLogging() was called before.

Did you checked the Internal log?
No, I checked the source code.

Are there any workarounds?
no

Is there a version in which it did work?
Don't know.

Suggested fix:

        public void ResumeLogging()
        {
            lock (_syncRoot)
            {
                _logsEnabled = Math.Min (0, _logsEnabled + 1);
                if (_logsEnabled == 0)
                {
                    ReconfigExistingLoggers();
                }
            }
        }

Can you help us by writing an unit test?
I could, but this would take much more time than if you wrote it your self. Here's the logic for it:

private static void NLogUnitTest_ResumeLogging_SuspendLogging_1 ()
{
  // ----- arrange -----
  const int maxSuspendDepth = 100;

  var logFactory = NLog.LogManager.LogFactory;

  // ----- act & assert -----
  // check initial state
  Assert.IsTrue (logFactory.IsLoggingEnabled ());

  // suspend and resume once
  logFactory.SuspendLogging ();
  Assert.IsFalse (logFactory.IsLoggingEnabled ());
  logFactory.ResumeLogging ();
  Assert.IsTrue (logFactory.IsLoggingEnabled ());

  // suspend multiple times and resume by the same number
  for (int counter = 1; counter <= maxSuspendDepth; counter++)
  {
    logFactory.SuspendLogging ();
    Assert.IsFalse (logFactory.IsLoggingEnabled ());
  }
  for (int counter = 1; counter <= maxSuspendDepth; counter++)
  {
    Assert.IsFalse (logFactory.IsLoggingEnabled ());
    logFactory.ResumeLogging ();
  }
  Assert.IsTrue (logFactory.IsLoggingEnabled ());

  // resume without suspend; subsequent SuspendLogging() call must still suspend.
  logFactory.ResumeLogging ();
  Assert.IsTrue (logFactory.IsLoggingEnabled ());

  logFactory.SuspendLogging ();
  Assert.IsFalse (logFactory.IsLoggingEnabled ());
  logFactory.ResumeLogging ();
  Assert.IsTrue (logFactory.IsLoggingEnabled ());

  for (int counter = 1; counter <= maxSuspendDepth; counter++)
  {
    Assert.IsFalse (logFactory.IsLoggingEnabled ());
    logFactory.ResumeLogging ();
  }
  logFactory.SuspendLogging ();
  Assert.IsFalse (logFactory.IsLoggingEnabled ());
  logFactory.ResumeLogging ();
  Assert.IsTrue (logFactory.IsLoggingEnabled ());
}

If the current behaviour is intended, I would suggest adding 2 more methods
ResumeLoggingNow(), which sets the internal counter to Math.Max (0, _logsEnabled + 1)
SuspendLoggingNow(), which sets the internal counter to Math.Min (-1, _logsEnabled - 1)
Alternatively, add an overload with bool force to each.
Maybe also a 3rd method
ResetLoggingSuspension(), which sets the internal counter to 0.

Not a big user of SuspendLogging() and ResumeLogging(), but I agree that it can be confusing when calling "ResumeLogging()" too much (maybe as a precaution), and then suddenly first call to SuspendLogging() doesn't have any effect.
Have no issue with adding SuspendLogging() and ResumeLogging() with bool force-parameter. Pull-request are welcome.

Closing issue, due to inactivity.


Fix credential token format validation.

The existing validation incorrectly excluded tab because of a missing backslash. This updates to add the backslash.
This also rewords the comments. I found the current comments to be a little confusing.
This also extends the test to verify more valid inputs.
cc #11600

Nice catch, thanks!
Also thanks for helping the review.
@bors r=hi-rustin

:pushpin: Commit 57264ed433873f56611bcd22520bca220404629e has been approved by hi-rustin
It is now in the queue for this repository.

:hourglass: Testing commit 57264ed433873f56611bcd22520bca220404629e with merge c429784fd5e456705b539ee7752bf6cfbe3f8d00...

:sunny: Test successful - checks-actions
Approved by: hi-rustin
Pushing c429784fd5e456705b539ee7752bf6cfbe3f8d00 to master...


Error messages are inscrutable

This is not a good way to talk to users:

The user doesn't see a field called "handle".

Our users may not know what a "uri" is... we need to tell them what exactly is the problem here that needs to be corrected?


No info text on button

Since there is no description, I do not know what button this is.
When you hover over this icon there is no description showing.

It is found inside the Inspector on the upper right corner within it.

It pops up a list of the recently edited resources and nodes.

:thumbsup:


Include footer note about single-person bottleneck

Generated by ChatGPT https://sharegpt.com/c/mXz5lUG
Prompted by https://github.com/devcontainers-contrib/features/issues/316
Follows up on https://github.com/devcontainers-contrib/.github/pull/10

/re @das-g
Done! 👍 I moved it to the top area.

@danielbraun89 📬

Oops! I was checking for updates and I accidentally closed it. My bad!


Improve and fix problems in geometry generation

This pull request adds functionality to the geometry_generator and fixes several problems:
Additions:

Add version info in geometry file
Add line info in geometry file
Add gui info in readme.md

Fixes:

Wires did not line up at some supertiles
-> This was fixed by introducing a WireConstraints object to
keep track of wires at the border of a tile and making changes
to the geometry generator to take these constraints into account.
However, this should be further tested with larger supertiles.

Wires not ordered correctly at termination tiles
-> This was resolved by changing the order of  the ordering and expanding
steps in the geometry generation

FASM not displayed correctly in FABulator
-> Partially due to the previous problems and additionally to the IO
of ports of bels being inverted. Was resolved by inverting.

I will publish FABulator ( https://github.com/FPGA-Research-Manchester/FABulator )
in the next days. It is currently in its alpha stage and some instabilities and bugs are to be
expected.
Btw, i hope this pull request doesn't cause chaos considering a lot is happening here right now...

Exciting work!
Yeah, there's a lot happening right now :D
Since you touched quite some lines, it probably makes sense to merge this before #163 and reapply the formatter on top of it. What do you think @KelvinChung2000?

I will review this first, then with FABulator and then do #163?
Dirk would like to do a 2.0 release, but I am unsure of the exact plan... We will need to clear up the image at some point; we at least need to know what should be included and what not. Otherwise, the release will be a mess.

FABulator is now public.


Prathi/liftcode

Before issuing a pull request, please see the contributing page.

Add lift code

Add lift code


oem build

I am trying to build the oem module.
I am getting this
~/libo3d3xx/modules/oem/build$ cmake -DCMAKE_INSTALL_PREFIX=/opt/oem/usr -DCPACK_INSTALL_PREFIX=/opt/oem/usr -DCMAKE_TOOLCHAIN_FILE=../../../cmake/toolchains/o3d303.cmake ..
CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
Could NOT find Threads (missing: Threads_FOUND)
Call Stack (most recent call first):
/usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-3.5/Modules/FindThreads.cmake:223 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:63 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/hayden/libo3d3xx/modules/oem/build/CMakeFiles/CMakeOutput.log".
See also "/home/hayden/libo3d3xx/modules/oem/build/CMakeFiles/CMakeError.log".
i can post CMakeError.log and CMakeOutput.log if needed
thoughts

Did you source in the environment file from the Poky SDK prior to running cmake?

Uhhhh noooo :( ..........
its working now
thank you and TGIF


oci-distribution: expose client builder

What this PR does
Allow users to provide a reqwest::ClientBuilder instance when the oci-distribution::Client is created.
Why this is useful
This can be useful for users who want to fine tune the client used to access the remote registry. For example, to add a root certificate to be used when connecting to a registry secured with a self-signed certificate.
Open questions
This is a quick prototype, what I don't like about this solution is:

Break the API of oci-distrubution::Client. The PR fixes the broken code, but what about other users of this crate?
Expose the reqwest::ClientBuilder. Disclaimer, I'm new to Rust, in Go I would propose to use instead an interface as parameter. In Rust I would say we could request a series of traits to be provided by the ClientBuilder, but this would require changes inside of reqwest::ClientBuilder.

I would be interested to know what you think about these drawbacks.

I think this is a good idea. I've had to maintain a separate branch for testing against internal registries without cert validation.
Regarding your questions:

Could we create a new method, called new_with_builder or something similar. This would prevent the API from breaking, and the user would not have to pass a None everywhere when they don't need customization.
I'm not completely sure what your concern is here, but I think it is reasonable to re-export reqwest::ClientBuilde. This is a  pretty typical pattern in Rust and I think it is better than trying to maintain an interface that has feature parity with reqwest::ClientBuilder.

1. Could we create a new method, called `new_with_builder` or something similar. This would prevent the API from breaking, and the user would not have to pass a `None` everywhere when they don't need customization.

I think this is actually a good idea. I've updated the PR to reflect that.

2. I'm not completely sure what your concern is here, but I think it is reasonable to re-export `reqwest::ClientBuilde`. This is a  pretty typical pattern in Rust and I think it is better than trying to maintain an interface that has feature parity with `reqwest::ClientBuilder`.

I just didn't want to expose an internal dependency of this crate to the outside. It's a matter of taste, some people dislike things like that :shrug:
Thanks for the feedback

@bacongobbler I share your concerns, that was what I tried to bring up with my second question.
Thanks for the hint, I think I now know how I could do something clean and idiomatic with rust. I'll come back with an updated PR

@flavio Just wanted to make sure I wasn't missing something here. Were you going to update your PR here or did you want us to merge this for now?

@thomastaylor312 sorry, I've been pretty busy recently. I'll work on this PR tomorrow

No problem! Just wanted to make sure we weren't leaving you hanging

I turned the PR into a draft because I need your feedback on the latest set of changes I submitted.
I took inspiration from what @bacongobbler suggested and I looked into ClientConfig and ClientConfigSource. I added a bunch of generic data types to the ClientConfig struct to handle client security options. I thought that, in the end, all these knobs are related with the Client configuration.
I felt pretty happy about the idea, until I went to change Client::new and I realized I had a problem. The Reqwest::ClientBuilder is returning a Result<Reqwest::Client>, not a Reqwest::Client I temporarily solved the issue by calling unwrap() in a bunch of places :(
I see two possible solutions:

We break the Client::new API by changing the return value to be a Result :unamused:
I move all these extra fields into a new struct (let's say ClientSecurityConfig) and then I create a Client::new_with_security_opts(config: ClientConfig, securityConfig: ClientSecurityConfig) -> anyhow::Result<Self>. I don't like to end up having two different "client configuration" structs, but this won't at least break the API

Do you have other ideas, how do you feel about these changes and options?

ping @thomastaylor312 :)

I'll let @kflansburg and @bacongobbler take a look at this again. Looks like you have some missing fields though that are causing the build failures

Yeah, I didn't bother to fix the tests because I would like to know which path I should follow to implement the change. The code is also callling a couple of unwrap() for the same reason.
I change the PR to a draft one because of that :)

Ping, can someone provide me the information to move forward with this PR?

@flavio It looks like there is one remaining Default that you need to add at crates/kubelet/src/config_interpreter.rs:13:9.

Looks good! In the future, please try to refrain from adding more than what's absolutely necessary to get the work done. I don't recall the TLS certificate code ever being part of the original plan.
That being said, this all looks like a good starting point to move forward. Please mark it as ready for review and we can look into the test failures. Thanks!

@bacongobbler, @kflansburg : I removed the "draft" status from the PR, but I still need your feedback about what I wrote into this comment :pray:
The tests are currently broken because I didn't bother to fix them, I will do that once we agree on I can get rid of the temporary unwrap() calls I left into the code.

new does not have to return Self, although it is convention. A more idiomatic approach might be to implement TryFrom<ClientConfig> for Client, which can return a Result.
https://doc.rust-lang.org/std/convert/trait.TryFrom.html

I've updated the PR to reflect the latest feedback:

I've implemented the TryFrom trait for Client. This can be used by users who want to be 100% sure the reqwest client will obey to their configuration. The function returns a Result object -> users can handle Err returns as they want
The Client::new function still returns a Self object. Internally it attempts to create the Client instance using TryFrom but, when the conversion fails, it will produce a warning message and instantiate the Reqwest client using the default infallible settings.

Since the Client::new API isn't changed, the code using this crate will keep building without changes.
With future PRs we can change the existing Krustlet code to allocate the Client instance using TryFrom, so that we can pull contents from registries secured with self-signed certificates.

The windows build is failing, I'll take a look at that during the weekend

I fixed the build issue on windows. Can someone allow the CI to pick the new code?
cc @kflansburg

I'm sorry, the build on windows failed again because of cargo fmt warnings. I fixed everything and did a force push.
Can you please trigger another build?

The CI system seems to be happy with the changes, plus we got two approvals. Can we merge it? :smiley:


Couple of issues

First of thanks for this library but there are no full Sample for how to use it actually it will be really helpful as from the readme there are some missing things I can't implement the flow from it.

Thanks for the feedback. I hope to find some time to create a sample app. But I think that the use is pretty easy. All you have to do is just start the download by calling
int startResult = DownloaderService.startDownloadServiceIfRequired(this,
                        "downloader-channel",
                        pendingIntent, SALT, BASE64_PUBLIC_KEY);

And then just listen to the download progress with DownloaderClient which has a very simple API (see the readme).
Do you have any specific problem I can help you with?

Thanks for your prompt reply
Steps are. :
1- checking if for " expansionFilesDelivered() "
2- start download with
int startResult = DownloaderService.startDownloadServiceIfRequired(this,                         "downloader-channel",                         pendingIntent, SALT, BASE64_PUBLIC_KEY);
3- and for listening to downloader client using this
`   class DownloaderClient extends BroadcastDownloaderClient {
    @Override
    public void onDownloadStateChanged(int newState) {
        if (newState == STATE_COMPLETED) {
            // downloaded successfully...
        } else if (newState >= 15) {
            // failed
            int message = Helpers.getDownloaderStringResourceIDFromState(newState);
            Toast.makeText(SampleDownloaderActivity.this, message, Toast.LENGTH_SHORT).show();
        }
    }

    @Override
    public void onDownloadProgress(DownloadProgressInfo progressInfo) {
        if (progressInfo.mOverallTotal > 0) {
            // receive the download progress
            // you can then display the progress in your activity
            String progress = Helpers.getDownloadProgressPercent(progressInfo.mOverallProgress,
                progressInfo.mOverallTotal);
            Log.i("SampleDownloaderActivity", "downloading progress: " + progress);
        }
    }
}`

4- you didn't mention how to access this downloaded files or is the normal way as in android guide.

@mhemdan yes, you should access the downloaded files the same way you do it with the official guide. See the getObbDir reference.


Trying to make use of lib.systems.architectures.features

I have looked into lib/systems/architectures.nix and found that the predicates at the bottom of the file are used here.
I have a Ryzen 7 4750u and desire to enable all the available features that GCC can use and/or compile with.
When import nixpkgs, I tried setting localSystem to:
{
  system = "x86_64-linux";
  gcc.arch = "znver2";
}

This results in the following error:
error: a 'x86_64-linux' with features {gccarch-znver2} is required to build '/nix/store/zy4h2yj3ssv8q582lzl613w64zgi5z3m-bootstrap-stage0-glibc-bootstrapFiles.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}

What is the intended usage of these platform feature flags? I could set them individually, but when there's already machinery in place to handle this, well...

You need to set system feature for the nix daemon. So it does not know that it is able to build znver2 things in your case.
That can be archived by setting something like
  nix.settings.system-features = ["gccarch-znver2" "benchmark" "big-parallel" "kvm" "nixos-test"];

Not sure if you need to set everything after gccarch-znver2, possibly that is already set by the system.
After that change is enabled you should be able to bootstrap the system.

You have to set system-features for Nix for localSystem to work correctly, the error message says exactly that. E.g. in configuration.nix:
nix.extraOptions = ''
  system-features = system-features = nixos-test benchmark big-parallel kvm gccarch-znver2
'';

However, it's not guaranteed that an actual -march=znver2 will be used, stdenv.hostSystem.* functions have to be explicitly used in a derivation. An alternative might be to wrap stdenv with wrapCFlags and specify desired ones. See also wiki.
But next time please use https://discourse.nixos.org for support questions.


[bug] Unable to detect clang-cl.exe as compilers installed in C:\Program Files\LLVM\bin\.

There are two types of clang compilers on Windows: clang.exe and clang-cl.exe.
It seems that it can successfully detect both clang.exe and clang-cl.exe installed in Visual Studio.
However, it can ONLY detect clang.exe installed in LLVM.
Screenshots

We are working on a fix for this in this PR #2627


Move sample image handling out of the powershell script and into code

Should be done along with UI controls work.

Landed in #500


C-API export seems to not work correctly

Hey, great to see that a C-style API is now included.
Sadly I don't get it do build correctly. I'm currently using this command
cmake .. -DBUILD_SHARED_LIBS=ON -DSD_BUILD_EXAMPLES=OFF -DSD_CUBLAS=ON
and it builds the dll, but it does not seem to export the functions correctly.
If I change stable-diffusion.h to always include #define SD_API __declspec(dllexport) it works fine.
Is there something I'm missing?
I also noticed, that the K-quants do not work - loading the model works, but calling txt2img prints
GGML_ASSERT: <trimmed>\stable-diffusion.cpp\ggml\src\ggml-cuda.cu:6817: false
then crashes with error code 0xC0000409

https://github.com/leejet/stable-diffusion.cpp/blob/f2e4d9793bbe0ec713c28cc55b123c68afd8db90/stable-diffusion.h#L4-L20
according to the code, both SD_BUILD_SHARED_LIB and SD_BUILD_DLL need to be defined. Both of which don't seem to be exposed as options in cmake (@leejet)

I haven't adapted it for building shared libraries yet.

It's been added now.

Works great, thanks :)

this doesn't work on mac


Storage Drawers API Update

This is a heads up I've made major API upgrades in the 5.2.0 release (alpha release - https://minecraft.curseforge.com/projects/storage-drawers/files/2446485)
I skimmed across your usage of the API and I think I've made it compatible with existing releases.  Most of the carnage was in areas not used by any 1.12 projects.

https://github.com/jaquadro/StorageDrawers/blob/1.12/src/com/jaquadro/minecraft/storagedrawers/api/capabilities/IItemRepository.java
https://github.com/jaquadro/StorageDrawers/blob/1.12/src/com/jaquadro/minecraft/storagedrawers/api/storage/IDrawerGroup.java
https://github.com/jaquadro/StorageDrawers/blob/1.12/src/com/jaquadro/minecraft/storagedrawers/api/storage/IDrawer.java

IItemRepository operations and IDrawer.adjustStoredItemCount may allow you to shorten up the code a bit, as they take into account special cases like voiding, and generally behave like the insert/extract operations in Forge IItemHandler.
IDrawerGroup and IItemRepository are exposed through the capability system.  IDrawerGroup is still implemented on the Tiles too, mainly for back-compat with existing RS releases.  So that will stick around for the remainder of 1.12's lifetime.

Thanks for the heads up, I'll be looking into this later today. And also thanks for the extra BC layer, altough it wasn't needed, I would have no problem in changing my code.

Also I'm loving IItemRepository, ideal for RS purposes, thank you!

I don't think I can use adjustStoredItemCount because it doesn't support simulation (look at StorageItemDrawer#insert)

In the implementation for IItemRepoistory, I do this:
amount = (simulate)
   ? Math.max(amount - drawer.getAcceptingRemainingCapacity(), 0)
   : drawer.adjustStoredItemCount(amount);

Ok @jaquadro done!
Can you validate my changes: https://github.com/raoulvdberge/refinedstorage/commit/f686b3c53be3a51d6a7bb8f3b4eace93e0928120
Some things I've been noticing:

RS can no longer interact with an empty drawer (for insertions, the adjustStoredItemCount wouldn't obviously work there - is that intended or do I need to work around it?)
There is a desync (single player) when getting a void upgrade out of the upgrade slots - I get the upgrade back but the drawer still stays voidable.

You'll have to check if it's empty and set the item.
  Is there a design constraint in RS that prevents you from using it?
https://github.com/jaquadro/StorageDrawers/blob/1.12/src/com/jaquadro/minecraft/storagedrawers/block/tile/TileEntityController.java#L699
If you check the implementation, and look down to line ~726, your insert implementation would look similar to what's happening in the for loop.  But IItemRepository.insert exercises pretty wide latitude in where it places items, ignoring exact slots.

Yes, I can't use IItemRepository since there is a "compare" flag for RS extractions.

IItemRepository.extractItem is guaranteed to return the same stack type you passed it (returns the same object instance in fact), so could you not do your filter check in the group wrapper first, and then call extract?
You could also use IItemRepository for the insert side only.

No, RS supports oredict as well. The oredict lookups would be too slow.
Closing this now, thanks for the heads up about the API change.

I don't follow "the oredict lookups would be too slow".  You're going to incur SD's oredict match cost on every lookup regardless (though now that only happens if the appropriate upgrade inst installed), in addition to your own.
I was just looking through how you use your comparers though, so I can see where there might be a problem.  I considered adding an alternate version of the extract call that would let you pass a custom matcher - would that have been sufficient?

I've got a little more feedback about your first change set.
You should be calling IDrawerGroup.getAccessibleDrawerSlots() to get the order in which you should enumerate drawers.  Otherwise priority is ignored and you might end up populating empty slots instead of adding to a partial drawer elsewhere.
The priority rules are actually a bit more subtle that what can even be done via getAccessibleDrawerSlots which is why IItemRepository is the best insertion endpoint.

Thanks, I guess a predicate would work.
If I were to use IitemRepository at all times I'd still need one method: getCapacity.

If I'm reading this right, getCapacity does not discriminate item type, it's just raw capacity of everything?
This probably causes unexpected behavior if you slap one of the creative upgrades anywhere -- maxCapacity in that cases returns Integer.MAX_SIZE.  And adding anything on top of that will give you a negative result because Java.

It would still care about item type. I just need this for the display on the External Storage GUI.

I think there's something I'm not getting, so I'm copy/pasting StorageItemDrawerGroup.getCapacity():
    @Override
    public int getCapacity() {
        int capacity = 0;

        IDrawerGroup group = groupSupplier.get();

        if (group == null) {
            return 0;
        }

        for (int i = 0; i < group.getDrawerCount(); ++i) {
            IDrawer drawer = group.getDrawer(i);

            if (drawer.isEnabled()) {
                capacity += drawer.getMaxCapacity();
            }
        }

        return capacity;
    }

I don't see anything that checks item type.

Oh, sorry, but I think that method is broken since it indeed doesn't check item type. Does it matter? It's just for display on the GUI.

No, it's fine, it's that current implementation that I didn't understand.  The item-checked version sounds like a reasonable addition to IItemRepository.  I'll put an update together this evening.

Cool, thanks, then I can just use IItemRepository if everything goes right. That should also fix some bugs regarding insertion/extraction order.

Alright, IItemRepository is extended in version 5.2.1.  Most functions have an alternate version that accepts a Predicate entry, which will pass the stored item prototype to you for matching.
As far as SD's implementation is concerned, passing in a predicate will stop it from doing any of its own item matching (so if dirt to diamonds is your thing ...).  Not passing a predicate, or passing one that implements IItemRepository.DefaultPredicate will cause the internal checks to be applied, which is a strict ItemStack match, plus SD's internal ore-dict matching if the conversion upgrade is present.
I didn't do much testing around the predicates so hopefully I didn't do something dumb.
https://github.com/jaquadro/StorageDrawers/blob/1.12/src/com/jaquadro/minecraft/storagedrawers/api/capabilities/IItemRepository.java

Thank you, I will look into it tonight.

@jaquadro Well, felt like coding so I looked into it immediataly.
Can you re-validate? 7669b1929b82a4dcc1a5c0f70a47cd6e623dd454
I removed all the drawers API classes and left IItemRepository.
Relevant code is in StorageItemItemRepository.java.

Two things I see:
In extract(), instead of checking the count first, just try to extract the original size.  You'll get back the same amount.  getStoredItemCount has a similar runtime cost to the extract call itself.
For getCapacity(), I must have misunderstood again the intention.  This implementation will have bad runtime complexity (n^2) and potentially give an inflated answer.  The original IDrawerGroup implementation here would be better, being mindful of the edge case where a call to getMaxCapacity() would give back Integer.MAX_VALUE.

I cannot extract the original size, RS grids for example pass a size of 64 even if the item has 5 stored for example.
Is every IItemRepository guaranteed to be an IDrawerGroup? Currently the code only accounts for a IItemRepository.

Asking the inventory to extract 64 when it only has 5 is fine.  You will get back 5.
It's not really a guarantee, but as a practical matter every tile in SD that exports an IDrawerGroup capability also exports IItemRepository.  Capacity could also be inferred through the IItemHandler interface, though not as fast or straightforward as doing it through IDrawerGroup.

Well, the entire point of these changes is that I would only need IItemRepository.
And no, that didn't happen on my side. I gave it 64 and I got back 64 (while I only had 32). Again, might be a comparer thing I have to account for?

Either the comparer is too broad, or I have a bug (that's probably more likely). The intention is very much that you can request as much as you want and only get back what's available.
If I were to put an inventory-global getCapacity() on IItemRepository, what specifically should that represent?  What is the capacity of a partially filled inventory when some items have a stack size of 64 and some 16, for example, and how are empty slots treated?

That is up to you to decide, I'm the API consumer. It's whatever you want the "capacity" value on the GUI to represent.
The comparer doesn't check for stack size, so I don't know if you expect that SD side.

The comparer is not expected to check stack size.

I've opened a PR with what I think are the final changes needed: https://github.com/raoulvdberge/refinedstorage/pull/1349
First, the extraction problem was a really egregious bug on my side, from trying to be clever with arithmetic.  It would have massively duped with any kind of automation.  Thanks for catching it; I forgot to test extraction.
I switched up the implementation a bit to take advantage of all IDrawerGroups also being ICapabilityProviders, and taking the repo capability off of that.  Should it be absent for some reason (which would be a third party implementor), it should just no-op without harm.  That leaves the slotty IDrawer stuff available where it makes sense.
And lastly I took your recommendation and opened an account on Bintray.  API and jars are now being hosted there, so I updated your build file to point there and remove the embedded API.  Between the multiple crash reports I've had and KingLemming's ranting about the RF API, I'm concluding that the Forge API system is just broken.

Aha, very nice. That means RS no longer includes any API in the jar, thank you! :)

@jaquadro I'm trying to load an existing world with drawers and it crashes like this:
[10:48:12] [Server thread/ERROR]: Failed to create block entity storagedrawers:basicdrawers.1
java.lang.StackOverflowError: null
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawers.hasCapability(TileEntityDrawers.java:640) ~[TileEntityDrawers.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawersStandard$GroupData.hasCapability(TileEntityDrawersStandard.java:225) ~[TileEntityDrawersStandard$GroupData.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawers.hasCapability(TileEntityDrawers.java:640) ~[TileEntityDrawers.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawersStandard$GroupData.hasCapability(TileEntityDrawersStandard.java:225) ~[TileEntityDrawersStandard$GroupData.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawers.hasCapability(TileEntityDrawers.java:640) ~[TileEntityDrawers.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawersStandard$GroupData.hasCapability(TileEntityDrawersStandard.java:225) ~[TileEntityDrawersStandard$GroupData.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawers.hasCapability(TileEntityDrawers.java:640) ~[TileEntityDrawers.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawersStandard$GroupData.hasCapability(TileEntityDrawersStandard.java:225) ~[TileEntityDrawersStandard$GroupData.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawers.hasCapability(TileEntityDrawers.java:640) ~[TileEntityDrawers.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawersStandard$GroupData.hasCapability(TileEntityDrawersStandard.java:225) ~[TileEntityDrawersStandard$GroupData.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawers.hasCapability(TileEntityDrawers.java:640) ~[TileEntityDrawers.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawersStandard$GroupData.hasCapability(TileEntityDrawersStandard.java:225) ~[TileEntityDrawersStandard$GroupData.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawers.hasCapability(TileEntityDrawers.java:640) ~[TileEntityDrawers.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawersStandard$GroupData.hasCapability(TileEntityDrawersStandard.java:225) ~[TileEntityDrawersStandard$GroupData.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawers.hasCapability(TileEntityDrawers.java:640) ~[TileEntityDrawers.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawersStandard$GroupData.hasCapability(TileEntityDrawersStandard.java:225) ~[TileEntityDrawersStandard$GroupData.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawers.hasCapability(TileEntityDrawers.java:640) ~[TileEntityDrawers.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawersStandard$GroupData.hasCapability(TileEntityDrawersStandard.java:225) ~[TileEntityDrawersStandard$GroupData.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawers.hasCapability(TileEntityDrawers.java:640) ~[TileEntityDrawers.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawersStandard$GroupData.hasCapability(TileEntityDrawersStandard.java:225) ~[TileEntityDrawersStandard$GroupData.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawers.hasCapability(TileEntityDrawers.java:640) ~[TileEntityDrawers.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawersStandard$GroupData.hasCapability(TileEntityDrawersStandard.java:225) ~[TileEntityDrawersStandard$GroupData.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawers.hasCapability(TileEntityDrawers.java:640) ~[TileEntityDrawers.class:?]
	at com.jaquadro.minecraft.storagedrawers.block.tile.TileEntityDrawersStandard$GroupData.hasCapability(TileEntityDrawersStandard.java:225) ~[TileEntityDrawersStandard$GroupData.class:?]

Thanks, it's fixed now in 5.2.3.


Docs.rs is generating external dependency links

The source link for https://docs.rs/rand/latest/rand/trait.SeedableRng.html#method.seed_from_u64 links to https://rust-random.github.io/rand/src/rand_core/lib.rs.html#306 instead of https://docs.rs/rand_core/0.6.3/src/rand_core/lib.rs.html#306-335; and https://docs.rs/rand_mt/4.1.1/rand_mt/struct.Mt19937GenRand32.html#impl-RngCore links to https://rust-random.github.io/rand/rand_core/trait.RngCore.html instead of https://docs.rs/rand_core/0.6.3/rand_core/trait.RngCore.html.
IIRC there was some plan on changing how --extern-html-root-url worked when a crate specified its own html_root_url, but there was going to be a flag for docs.rs to keep the previous override behavior.

This is https://github.com/rust-lang/docs.rs/pull/1473, I haven't had time to work on it.


Dispatching exceptions via a delegate

Can you give a hint on when this PR may be merged? Our application enters production state soon and we need this among some other issues solved.

I'm guessing scottoffen has become "busy"? I am several weeks away from a release and am planning to do a release on my own fork for now because depend on some enhancements and fixes. Your changes fit with my program (I like the error log stuff, although I don't understand the need for server tags?).
It may be necessary to create some releases using a fork until fearless leader returns?

The server tags are actually just a plain object you can attach and receive. Slightly more elegant solution to use a singleton to access context stuff. May or may not be useful for others, however, it helps oru case.

Well, I definitely like all of your changes (I think the tag could replace my need for a global method for all the entry points, whether it's useful I have no idea). They merge with minimal conflict (but not automatically?) with the changes I'm proposing. (Still hoping to get some feedback but I find them to greatly simplify my handlers.
ventkaperi's Priority enhancement conflicts with my changes; I'd be happy to merge if mine are accepted. Priority is definitely a feature I would like to see for performance reasons.

Note when merging code: ProcessRequest must not call FireException if FireException throws, unless it then catches the exception. Otherwise the request processor thread will exit, and eventually you will run out of Workers. I will code around this in my merge.
I was wondering: why is there an exception handler in QueueRequest if all it does is immediately propagate up one level to HandleRequests()? Same "must catch all exceptions" issue applies to HandleRequests() as well of course.

I have merged all outstanding PRs as far as I can tell into tekhedd/Interspecific enhancements-merge branch. It seems to work without problems but I am not using most of the new features yet. Whee.

I've been swamped with the day job, just logged in after some time away an noticed the conversations. I'll go through the tickets this week and the PR and see if I can't get a new release out on Nuget this week or next.


Can't connect to the Tavern using node.js version "Upgrade Required"

I'm currently running 1.2.8 version of node.js tavern and it won't allow me to connect to the webui for some odd reason. I tried repairing node.js, and redownloding the original zip of 1.2.8. Nothing helps and it still gives me the blank white page as shown below. How can I fix this?
I want to try running "npm fund" but I don't know where to do it because it won't let me type in that powershell window.

You can safely ignore the funding note.
Are you correctly trying to access the server at http://<IP_ADDRESS>:8000 ?
What browser and version are you running?

There's an issue with the double x-crsf tokenhandlingin 1.2.8, make sure that you are accepting same-site cookies from insecure (http,not https.) local domains, and if you are, remove all existing cookies, kill the browser and ctrl+c the tavern console, and fire them both up fresh...
1.3.1 is out, and already several commits behind Main...

Today I launched the powershell window and it opened the tavernAI UI without any issues, and is working again. Whether it was something you guys did on the backend or this issue resolved itself somehow(I doubt that, it's probably the former). Thank you!


Add support for searching and visualizing OpenAerialMap

References:

https://hotosm.github.io/oam-api
https://docs.openaerialmap.org/api/ap
https://3d.iconem.com/_dev/search-satellite-imagery
https://github.com/Iconem/search-satellite-imagery/tree/main/src/archive-apis

This feature has been implemented. See https://leafmap.org/notebooks/68_openaerialmap/
https://user-images.githubusercontent.com/5016453/222928465-434eb324-1304-43f9-b198-3ba838a658e4.mp4


Cannot find module remix-utils/use-hydrated or its corresponding type declarations.

Describe the bug
I'm getting this feedback in Intellij - although everything works fine, I'm just wondering why I'm getting this feedback.  Tried installing @types/remix-utils but it doesn't exists - and I think not necessary.
Your Example Website or App
n/a
Steps to Reproduce the Bug or Issue
Install the latest version
import { useHydrated } from 'remix-utils/use-hydrated'
Expected behavior
No lint error
Screenshots or Videos

Platform
version 7.5.0
Additional context
No response

Ensure your tsconfig.json has "moduleResolution": "Bundler".
Also see https://github.com/sergiodxa/remix-utils#upgrade-from-remix-utils-v6.

This did the trick - thanks!


FAQ entry: How does dep handle symlinks

Took a first crack at this.

I think it could use more clarification about what we refer to as cwd, and when these checks are made.

@brianstarke thanks for this 😄
I agree with @ibrasho, but I'm gonna merge this as-is. @ibrasho, do you think you could make some improvements wrt cwd in a follow-up PR?

I found some issues while trying to understand what's going on to update the FAQs. I'll submit a new PR with the explanation and the needed changes.


kobuki_ros_interfaces: 1.0.0-1 in 'foxy/distribution.yaml' [bloom]

Increasing version of package(s) in repository kobuki_ros_interfaces to 1.0.0-1:

upstream repository: https://github.com/kobuki-base/kobuki_ros_interfaces.git
release repository: https://github.com/ros2-gbp/kobuki_ros_interfaces-release.git
distro file: foxy/distribution.yaml
bloom version: 0.11.2
previous version for package: null

kobuki_ros_interfaces
* Rename from kobuki_msgs -> kobuki_ros_interfaces, #1 <https://github.com/kobuki-base/kobuki_ros_interfaces/pull/1>
* ROS2 eloquent upgrade, #11 <https://github.com/yujinrobot/kobuki_msgs/issues/11>

Holding for Foxy sync


If you nest ngx-datatable in the ngx-datatable-row-detail,The footer of ngx-datatable-row-detail is automatically assigned to the outer ngx-datatable

If you nest ngx-datatable in the ngx-datatable-row-detail,The footer of ngx-datatable-row-detail is automatically assigned to the outer ngx-datatable

Hello @xiechunyan, can you provide a stackblitz demo to check what is going on?
Cheers!

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.


Maybe all of these scripts could be replaced by Ansible playbooks?

It's only an idea...

Contributions are welcome


Vectorize Trip Updates explode

trip update processing previously utilized the pandas apply method to explode and unwrap trip updates dataframe
using the numpy vectorize feature is a significant performance improvement over pandas apply (over 50% faster)
Asana Task: https://app.asana.com/0/1202841571879768/1203021761496489

LGTM and i got to learn something new.


check root node for animations

Objective
gltf animations can affect multiple "root" nodes (i.e. top level nodes within a gltf scene).
the current loader adds an AnimationPlayer to each root node which is affected by any animation. when a clip which affects multiple root nodes is played on a root node player, the root node name is not checked, leading to potentially incorrect weights being applied.
also, the AnimationClip::compatible_with method will never return true for those clips, as it checks that all paths start with the root node name - not all paths start with the same name so it can't return true.
Solution

check the first path node name matches the given root
change compatible_with to return true if any match is found

a better alternative would probably be to attach the player to the scene root instead of the first child, and then walk the full path from there. this would be breaking (and would stop multiple animations that don't overlap from being played concurrently), but i'm happy to modify to that if it's preferred.

Could you add the "Fixes #8357"?


Added support for .mvn folder which comes with mvn 3.3.3

CAMEL-8778
http://blog.soebes.de/blog/2015/03/17/apache-maven-3-dot-3-1-features/

As per ticket comment:
After some playing around and checking the source, the jvm.config are concatenated with MAVEN_OPTS as per the below commit. The problem this causes is, if the same value is in MAVEN_OPTS and jvm.config, java fails.
I'll raise a ticket with maven to see if this can be improved and discard the PR.
[1] https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=8ed9a1caa8890773b45c6c408a4e40acf4f4b0fd


PermitExpirableSemaphore to be able to make expirable permit to a normal permit

Once a permit is acquired as an expirable permit, there should be a way to remove the expiry and make it to a normal permit.

Also I'm looking for a way to extend a permit that's already being held.
Here's a use-case:

I need expirable permits because our microservice infrastructure could potentially kill services on occasion and we must ensure that semaphores can't be held indefinitely.
I need a semaphore instead of any sort of regular Lock because I have async and/or multi-threaded tasks.
Each task has many items to be processed and needs to hold onto state in between steps in order to efficiently process the items.
Each task must hold an exclusive mutex on a resource while it processes the items so that corruption can't occur
There's no way to know how many items will need to be processed (or how long it will take) until the process begins
If the task gets interrupted in the middle (because its mutex expires) it will have to start over from scratch

So, if I choose a very long expiration time in order to ensure that any potential task can be completed by the end of it I lose most of the safety of using expiring permits. If I choose a short expiration time eventually a task will extend beyond that time. If I attempt to release and re-acquire a permit in the middle of the task I risk losing the permit to another waiter.
I hope this makes sense.  I may attempt to subclass PermitExpirableSemaphore to add a refresh(String existingPermit) method that will return a new permitId as long as the existing one is still valid.

So, I'm looking deeper into this and it looks like this SHOULD work simply by calling ZADD ${timeoutName} XX CH ${newTimeoutDate} ${permitId}
This will change the timeout of the permit if the permit exists and return true if it's updated and false if it's not.
It does have the following characteristics, though:

It will not check to see if the permit already expired, but I don't know if this is important, since the PermitExpirableSemaphore is already "unfair".
It does not check if newTimeoutDate is in the past, but neither do the existing methods.

What do you think?

Done. RPermitExpirableSemaphore.updateLeaseTime method added

Thank you @cherrydev for the addition.
Great work! @mrniko


Power (^) doesn't support decimals.

Power of 2, 3, etc. will work, but anything like 1.7 or 0.5 will do nothing. This means that sqrt() is actually not working.
I have mostly fixed this, but not quite. I can get decimals of 0.5 to work, 0.5, 1.5, etc. will work. Anything like 0.6 or 0.4 will not however.

Another issue with power is that it doesn't support negative powers. The solution is just to divide instead of multiply in the power function, but I'd like to fix this issue before fixing negative powers.

This issue has been fixed. The entire loop has been replaced with first^power, second*power.
I tried this solution before, but it was giving incorrect results and I tossed it.
Turns out its correct, but the way I handle numbers was a problem that wasn't run into before.
Before I believed something like {2.5, 1.3} (2.5 * 10^1.3) just needed to be floored to {2.5, 1} and the answer would be correct. This was never a problem because second was never getting decimals.
This new power solution however would give second with a decimal. And because I was just flooring it out, first was wrong and so I thought it was wrong.
Turns out if you want to get rid of the decimal in second, you multiply first by 10^(second % 1). second % 1 will give us just the decimal of second. 25.532 % 1 = 0.532.
This is the code that uses the above
	first = tonumber(first)

	if second % 1 > 0 then
		first *= 10^(second % 1)
	end

	second = math.floor(second)

This will fix the number correctly (second having decimals is mathematically fine, but the module was built around not allowing it).


Loading chunk failed when scripts are included through another http serve (from angular/angular)

source: https://github.com/angular/angular/issues/23793
I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
[X ] Other... Please describe:

Current behavior

I am running the angular app with ng serve on port 4200 and another http server on port 8080.
Using lazy loading, the chunk tries to load through port localhost:8080
Expected behavior

The chunk should be loaded correctly through port localhost:4200 (the port that the angular-app is being served on)
Minimal reproduction of the problem with instructions

Run ng serve in angular app which has lazy loaded modules. Include
        <script type="text/javascript" src="http://localhost:4200/inline.bundle.js"></script>
        <script type="text/javascript" src="http://localhost:4200/polyfills.bundle.js"></script>
        <script type="text/javascript" src="http://localhost:4200/styles.bundle.js"></script>
        <script type="text/javascript" src="http://localhost:4200/vendor.bundle.js"></script>
        <script type="text/javascript" src="http://localhost:4200/main.bundle.js"></script>

on the html page of another http server. Navigate to the lazy loaded module and see that loading of common.chunk.js and lazy-loaded.module.js has failed
What is the motivation / use case for changing the behavior?

It should load through the correct port depending on what port the angular app is being served from
Environment

Angular version: 5.2.10

Browser:
- [X] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX

For Tooling issues:
- Node version: v8.9.4
- Platform:   Windows

Others:

@rishabh-94

Duplicate of #10781


Keyboard shortcut for "Run Function Definition"

I've been working on migrating from developing in R using Eclipse and the StatET plugin (packaged as Architect at www.getarchitect.io) to VSCode. One of the little niceties that I haven't found a counterpart for so far is a keyboard shortcut that allows you run the function definition of whatever function code block the cursor is in.
Describe the solution you'd like
When your cursor is in an editor window, and inside a block of R code that defines a function (e.g. myFunction <- function(x) {}), have a keyboard shortcut (in StatET it is CTRL-R, CTRL-F) that automatically detects the code that spans the function definition and submits it to the active console. The cursor remains in the editor at the same spot, and the editing window remains the active pane. For functions that are nested in other functions, the outermost function definition is run.
Describe alternatives you've considered
This is inspired by functionality that exists in Eclipse/StatET. The closest I have found in VSCode/R is to select the entire function definition manually and typing CTRL-ENTER to submit the code to the active console.
Additional context
A brief mention of the function in Eclipse/StatET can be found at https://www.r-bloggers.com/2009/10/tips-for-using-statet-and-eclipse-for-data-analysis-in-r/ in the section Options for Running R Code

You might want command "R: Run Selection/Line (Retain Cursor)" (r.runSelectionRetainCursor) which detects the code block if no selection range is specified and does retain the cursor position.

Thank you for the suggestion. I tried that out, and while it's close that doesn't seem to be doing quite what I requested. If I have a function definition like this:
plotme <- function(x, y, color=NULL) {
    plot(x, y, col=if (is.null(color))"black" else color)
}

"R: Run Selection/Line (Retain Cursor)"  works only if I am on the very first line or the very last line of code, but not in the interior line (containing the plot() call). It only seems to work if I'm already on a line that has a block delimiter character like { or }
Using the example from #325
m <- local({
  x <- rnorm(100)
  y <- rnorm(100)
})

The block gets submitted if I'm on line 1 or 4,  but not 2 or 3. So ideally if my cursor was on the x <- rnorm(100) line, then upon submitting the version of the command I have in mind, VSCode would detect the entire (and outermost) R block containing that line, and submit that.
My use case would be that I'm modifying the interior of a (potentially long) function, and want to resend the whole function definition from an interior line, perhaps to do a quick manual test.  In the IDE I'm coming from, this functionality applied specifically to function definitions rather than arbitrary blocks of R code, probably to avoid the chance that you execute code when you think you're just changing a function definition. But either behavior could be valuable (or configurable?). I found this very handy when working with a script containing several functions for modularity. The key difference from the Run Selection/Line (Retain Cursor) command is that it would work on interior lines within a block.
Would such a command be possible? Thanks again.

Then what's the expected behavior of the following:
foo <- function(x, y) {
  bar <- function(a, b) {
    a + b
  }
  bar(x + y, x - y)
}

Modifying the function body of the inner function bar at line a + b. Do you always want the top-level function definition to be sent to terminal?

Yes, always the top-level. Even if I was on the a + b line, I would not want bar in the global workspace when it is intended to be a sub function of foo, so I would want the entire definition of foo resent. If I wanted to override the behavior implied by the nesting and put bar in the global environment, I could always select just the lines of bar and submit those, although that should be rare by design.

Then we could implement a new command that detects the top-level expression range, sends the expression to terminal, and retains the cursor position.

That would be great!
Are you thinking that such a command would be specific to function definitions, or would work with any arbitrary block of code? I'm not sure whether the "protection" of only allowing function definitions is better or worse than enabling it for all blocks of code. Could see it going either way, and either approach would work for my use case.

Working with an arbitrary block of code would be fine, since there could be many ways to define a function.

ok, sounds good! Thank you

Are you interested in implementing this feature? Do you have a way in mind to detect the top-level expression without parsing the entire document?

While not unwilling to help, it's not really in my current skillset. I'm still new to VSCode just as a user, and I don't know the first thing about implementing VSCode extensions.
I think StatET is written in Java, which I also do not know. Not sure how Eclipse/StatET does the detection under the hood, but it works even if the Windows front end is connecting to a remote client (say R running on Linux) through an SSH tunnel, without having to have R installed on the front end. There's an "rJava" package that facilitates communication between the ends. Not sure if they are relying on using the R session itself to aid in parsing, or if the detection is being done solely by the front end client.
If I had to speculate, I'd guess that they are looking for the function R keyword in the doc, and maybe just finding the enclosing block around each instance? Then if the cursor is on a line number within a known block, it knows what range to send?

FWIW, I just tested Eclipse/StatET to verify that it handled nesting the way I remembered. It did for at least 5 levels deep (after which I stopped). In each case, it submitted the very top-most enclosing function definition.
I also spent a bit of time perusing the Java source, but couldn't follow it enough to really know what they are doing. But I was able to determine that they do detect function in the code being edited as a token to keep track of (along with many other R keywords). But how it specifically determines what the topmost expression for a given line of code is, and whether it is a function definition, isn't clear.


Keyboard shortcut doesn't work

Loving the mod, although the keybind to open the map doesn't do anything. I've tried changing it from the default key (M) to any other key but it still doesn't do anything. Also I'm running it on SPT-AKI 3.8.0 if it does matter. Thank you for the mod.

The keyboard shortcut is currently unimplemented, it turned out to be harder than I thought it would be and I forgot to remove the config for it.
Sorry for the confusion.

This should now be mostly resolved with the inclusion of the "Peek at Map" feature added in 0.3.0


Need an option to sync entries when we add a new one.

I’m using the app on several iOS devices & while it’s good to be able to backup the entries for install on a new device I’d like to be able to resync the entries whenever I add a new entry so that it appears on all my devices without resorting to uninstalling the app & re-adding it.
Also having the newly installed app set itself a the main backup after recovering the entries seems to be a strange choice imo, I feel this should not happen & I have to return to another device (my iPad) to choose to sync that as I use it the most so prefer that device to be the main sync device.

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

ID: 74268828-9af5-750f-0195-0cb3e367039f
Version Independent ID: 6c6cae91-9f54-2f50-8b74-b150308d5d2e
Content: Backup and recover info with Microsoft Authenticator - Azure
Content Source: articles/multi-factor-authentication/end-user/microsoft-authenticator-app-backup-and-recovery.md
Service: multi-factor-authentication
Product: unspecified
GitHub Login: @eross-msft
Microsoft Alias: lizross

Hi, thanks for your suggestions. We'll definitely consider adding sync functionality in future versions.
For your second piece of feedback, would you expect your previous device to maintain the backup? Or would you expect a prompt after recovering asking which device you want to be the main backup?
Thanks for using Microsoft Authenticator!

Thanks for your feedback and suggestions! We'll definitely keep this in mind as we design future versions.

@olena-microsoft Thanks for addressing the feedback.
@Goddess-Bastet Please post this as a feedback @ https://feedback.azure.com/forums/169401-azure-active-directory This will allow the community to upvote and for the product team to include into their plans. We also have the "Give Product Feedback" button in our documents now to take you directly to the appropriate feedback page.

I have now done so @MohitGargMSFT   👍

@Goddess-Bastet Thanks. We will now proceed to close this thread. If there are further questions regarding this matter, please open a new issue and we will gladly continue the discussion.


Test pull request 1

see notifications

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