text:
JabbaInstallationSupplier does not work with ZuluOpenJDK

Expected Behavior
zulu@1.11.0-9 will be picked up and used.
Current Behavior
zulu@1.8.265 is picked up and used.
Context
#14118
Steps to Reproduce
$ jabba ls
$ jabba install zulu@1.8.265
Downloading zulu@1.8.265 (https://cdn.azul.com/zulu/bin/zulu8.48.0.53-ca-jdk8.0.265-macosx_x64.tar.gz)
107794643/107794643
Extracting /var/folders/ml/kc6p75v14cx4r3n8f2d62cw40000gq/T/jabba-d-026785643 to /Users/dev/Library/jabba/jdk/zulu@1.8.265
zulu@1.8 -> /Users/dev/Library/jabba/jdk/zulu@1.8.265
default -> /Users/dev/Library/jabba/jdk/zulu@1.8.265
$ jabba install zulu@1.11.0-9
Downloading zulu@1.11.0-9 (https://cdn.azul.com/zulu/bin/zulu11.43.21-ca-jdk11.0.9-macosx_x64.tar.gz)
195024247/195024247
Extracting /var/folders/ml/kc6p75v14cx4r3n8f2d62cw40000gq/T/jabba-d-927452550 to /Users/dev/Library/jabba/jdk/zulu@1.11.0-9
$  jabba ls
zulu@1.11.0-9
zulu@1.8.265
$ echo $JABBA_HOME
/Users/dev/Library/jabba
$ ls $JABBA_HOME/jdk
default		zulu@1.11.0-9	zulu@1.8	zulu@1.8.265
$ jabba use zulu@1.11.0-9
$ jabba current
zulu@1.11.0-9
$ echo $JAVA_HOME
/Users/dev/Library/jabba/jdk/zulu@1.11.0-9/Contents/Home
$ /usr/libexec/java_home
Unable to find any JVMs matching version "(null)".
No Java runtime present, try --request to install.
$ mkdir /tmp/gradle-toolchain-jabba && cd $_ && gradle init --type java-library --dsl kotlin --test-framework junit-jupiter --project-name=gradle-toolchain-jabba --package=org.gradle.example.toolchain

> Task :init
Get more help with your project: https://docs.gradle.org/6.6.1/userguide/java_library_plugin.html

BUILD SUCCESSFUL in 881ms
2 actionable tasks: 2 executed
$ ./gradlew wrapper --gradle-version 6.7 --distribution-type=all

BUILD SUCCESSFUL in 727ms
1 actionable task: 1 executed
$ printf 'java {toolchain {languageVersion.set(JavaLanguageVersion.of(11))}}\ntasks.compileJava {options.release.set(11)}' >> build.gradle.kts
$ cat build.gradle.kts
/*
 * This file was generated by the Gradle 'init' task.
 *
 * This generated file contains a sample Java Library project to get you started.
 * For more details take a look at the Java Libraries chapter in the Gradle
 * User Manual available at https://docs.gradle.org/6.6.1/userguide/java_library_plugin.html
 */

plugins {
    // Apply the java-library plugin to add support for Java Library
    `java-library`
}

repositories {
    // Use jcenter for resolving dependencies.
    // You can declare any Maven/Ivy/file repository here.
    jcenter()
}

dependencies {
    // This dependency is exported to consumers, that is to say found on their compile classpath.
    api("org.apache.commons:commons-math3:3.6.1")

    // This dependency is used internally, and not exposed to consumers on their own compile classpath.
    implementation("com.google.guava:guava:29.0-jre")

    // Use JUnit Jupiter API for testing.
    testImplementation("org.junit.jupiter:junit-jupiter-api:5.6.2")

    // Use JUnit Jupiter Engine for testing.
    testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine:5.6.2")
}

val test by tasks.getting(Test::class) {
    // Use junit platform for unit tests
    useJUnitPlatform()
}
java {toolchain {languageVersion.set(JavaLanguageVersion.of(11))}}
tasks.compileJava {options.release.set(11)}
$ ./gradlew -v

------------------------------------------------------------
Gradle 6.7
------------------------------------------------------------

Build time:   2020-10-14 16:13:12 UTC
Revision:     312ba9e0f4f8a02d01854d1ed743b79ed996dfd3

Kotlin:       1.3.72
Groovy:       2.5.12
Ant:          Apache Ant(TM) version 1.10.8 compiled on May 10 2020
JVM:          11.0.9 (Azul Systems, Inc. 11.0.9+11-LTS)
OS:           Mac OS X 10.15.7 x86_64

$ ./gradlew build --stacktrace

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':compileJava'.
> Could not resolve all dependencies for configuration ':compileClasspath'.
   > Failed to calculate the value of task ':compileTestJava' property 'javaCompiler'.
      > Unable to configure Java installation, probing failed with the following message: A problem occurred starting process 'command '/Users/dev/Library/jabba/jdk/zulu@1.8.265/bin/java''

* Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Exception is:
org.gradle.api.internal.tasks.TaskDependencyResolveException: Could not determine the dependencies of task ':compileJava'.
        at org.gradle.api.internal.tasks.CachingTaskDependencyResolveContext.getDependencies(CachingTaskDependencyResolveContext.java:69)
        at org.gradle.execution.plan.TaskDependencyResolver.resolveDependenciesFor(TaskDependencyResolver.java:46)
        at org.gradle.execution.plan.LocalTaskNode.getDependencies(LocalTaskNode.java:160)
        at org.gradle.execution.plan.LocalTaskNode.resolveDependencies(LocalTaskNode.java:128)
        at org.gradle.execution.plan.DefaultExecutionPlan.doAddNodes(DefaultExecutionPlan.java:163)
        at org.gradle.execution.plan.DefaultExecutionPlan.addEntryTasks(DefaultExecutionPlan.java:133)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph.addEntryTasks(DefaultTaskExecutionGraph.java:147)
        at org.gradle.execution.TaskNameResolvingBuildConfigurationAction.configure(TaskNameResolvingBuildConfigurationAction.java:49)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.configure(DefaultBuildConfigurationActionExecuter.java:55)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.access$000(DefaultBuildConfigurationActionExecuter.java:26)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter$1.proceed(DefaultBuildConfigurationActionExecuter.java:63)
        at org.gradle.execution.DefaultTasksBuildExecutionAction.configure(DefaultTasksBuildExecutionAction.java:45)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.configure(DefaultBuildConfigurationActionExecuter.java:55)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.access$000(DefaultBuildConfigurationActionExecuter.java:26)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter$1.proceed(DefaultBuildConfigurationActionExecuter.java:63)
        at org.gradle.execution.ExcludedTaskFilteringBuildConfigurationAction.configure(ExcludedTaskFilteringBuildConfigurationAction.java:48)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.configure(DefaultBuildConfigurationActionExecuter.java:55)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.lambda$select$0(DefaultBuildConfigurationActionExecuter.java:42)
        at org.gradle.internal.Factories$1.create(Factories.java:26)
        at org.gradle.api.internal.project.DefaultProjectStateRegistry.withMutableStateOfAllProjects(DefaultProjectStateRegistry.java:141)
        at org.gradle.api.internal.project.DefaultProjectStateRegistry.withMutableStateOfAllProjects(DefaultProjectStateRegistry.java:128)
        at org.gradle.execution.DefaultBuildConfigurationActionExecuter.select(DefaultBuildConfigurationActionExecuter.java:40)
        at org.gradle.initialization.DefaultTaskExecutionPreparer.prepareForTaskExecution(DefaultTaskExecutionPreparer.java:38)
        at org.gradle.initialization.BuildOperationFiringTaskExecutionPreparer$CalculateTaskGraph.populateTaskGraph(BuildOperationFiringTaskExecutionPreparer.java:117)
        at org.gradle.initialization.BuildOperationFiringTaskExecutionPreparer$CalculateTaskGraph.run(BuildOperationFiringTaskExecutionPreparer.java:68)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:56)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$run$1(DefaultBuildOperationExecutor.java:71)
        at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.runWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:45)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:71)
        at org.gradle.initialization.BuildOperationFiringTaskExecutionPreparer.prepareForTaskExecution(BuildOperationFiringTaskExecutionPreparer.java:56)
        at org.gradle.initialization.DefaultGradleLauncher.prepareTaskExecution(DefaultGradleLauncher.java:235)
        at org.gradle.initialization.DefaultGradleLauncher.doClassicBuildStages(DefaultGradleLauncher.java:169)
        at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:150)
        at org.gradle.initialization.DefaultGradleLauncher.executeTasks(DefaultGradleLauncher.java:126)
        at org.gradle.internal.invocation.GradleBuildController$1.create(GradleBuildController.java:72)
        at org.gradle.internal.invocation.GradleBuildController$1.create(GradleBuildController.java:67)
        at org.gradle.internal.work.DefaultWorkerLeaseService.withLocks(DefaultWorkerLeaseService.java:178)
        at org.gradle.internal.invocation.GradleBuildController.doBuild(GradleBuildController.java:67)
        at org.gradle.internal.invocation.GradleBuildController.run(GradleBuildController.java:56)
        at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:31)
        at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
        at org.gradle.launcher.exec.BuildOutcomeReportingBuildActionRunner.run(BuildOutcomeReportingBuildActionRunner.java:63)
        at org.gradle.tooling.internal.provider.ValidatingBuildActionRunner.run(ValidatingBuildActionRunner.java:32)
        at org.gradle.tooling.internal.provider.FileSystemWatchingBuildActionRunner.run(FileSystemWatchingBuildActionRunner.java:67)
        at org.gradle.launcher.exec.BuildCompletionNotifyingBuildActionRunner.run(BuildCompletionNotifyingBuildActionRunner.java:41)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner$3.call(RunAsBuildOperationBuildActionRunner.java:49)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner$3.call(RunAsBuildOperationBuildActionRunner.java:44)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:76)
        at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:76)
        at org.gradle.launcher.exec.RunAsBuildOperationBuildActionRunner.run(RunAsBuildOperationBuildActionRunner.java:44)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.lambda$execute$0(InProcessBuildActionExecuter.java:54)
        at org.gradle.composite.internal.DefaultRootBuildState.run(DefaultRootBuildState.java:87)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:53)
        at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:29)
        at org.gradle.launcher.exec.BuildTreeScopeLifecycleBuildActionExecuter.lambda$execute$0(BuildTreeScopeLifecycleBuildActionExecuter.java:33)
        at org.gradle.internal.buildtree.BuildTreeState.run(BuildTreeState.java:49)
        at org.gradle.launcher.exec.BuildTreeScopeLifecycleBuildActionExecuter.execute(BuildTreeScopeLifecycleBuildActionExecuter.java:32)
        at org.gradle.launcher.exec.BuildTreeScopeLifecycleBuildActionExecuter.execute(BuildTreeScopeLifecycleBuildActionExecuter.java:27)
        at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:104)
        at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:55)
        at org.gradle.tooling.internal.provider.SubscribableBuildActionExecuter.execute(SubscribableBuildActionExecuter.java:64)
        at org.gradle.tooling.internal.provider.SubscribableBuildActionExecuter.execute(SubscribableBuildActionExecuter.java:37)
        at org.gradle.tooling.internal.provider.SessionScopeLifecycleBuildActionExecuter.lambda$execute$0(SessionScopeLifecycleBuildActionExecuter.java:54)
        at org.gradle.internal.session.BuildSessionState.run(BuildSessionState.java:67)
        at org.gradle.tooling.internal.provider.SessionScopeLifecycleBuildActionExecuter.execute(SessionScopeLifecycleBuildActionExecuter.java:50)
        at org.gradle.tooling.internal.provider.SessionScopeLifecycleBuildActionExecuter.execute(SessionScopeLifecycleBuildActionExecuter.java:36)
        at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:36)
        at org.gradle.tooling.internal.provider.GradleThreadBuildActionExecuter.execute(GradleThreadBuildActionExecuter.java:25)
        at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:59)
        at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:31)
        at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:55)
        at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:41)
        at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:47)
        at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:31)
        at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:65)
        at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:39)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:29)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:35)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.create(ForwardClientInput.java:78)
        at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.create(ForwardClientInput.java:75)
        at org.gradle.util.Swapper.swap(Swapper.java:38)
        at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:75)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.LogAndCheckHealth.execute(LogAndCheckHealth.java:55)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:63)
        at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:84)
        at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
        at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
        at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:52)
        at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:297)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: org.gradle.api.artifacts.ResolveException: Could not resolve all dependencies for configuration ':compileClasspath'.
        at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver.wrapException(ErrorHandlingConfigurationResolver.java:104)
        at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver.resolveBuildDependencies(ErrorHandlingConfigurationResolver.java:65)
        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.lambda$resolveGraphForBuildDependenciesIfRequired$6(DefaultConfiguration.java:730)
        at org.gradle.api.internal.project.DefaultProjectStateRegistry$CalculatedModelValueImpl.update(DefaultProjectStateRegistry.java:361)
        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.resolveGraphForBuildDependenciesIfRequired(DefaultConfiguration.java:726)
        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.access$1600(DefaultConfiguration.java:139)
        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.visitDependencies(DefaultConfiguration.java:1232)
        at org.gradle.api.internal.tasks.CachingTaskDependencyResolveContext$TaskGraphImpl.getNodeValues(CachingTaskDependencyResolveContext.java:112)
        at org.gradle.internal.graph.CachingDirectedGraphWalker$GraphWithEmptyEdges.getNodeValues(CachingDirectedGraphWalker.java:213)
        at org.gradle.internal.graph.CachingDirectedGraphWalker.doSearch(CachingDirectedGraphWalker.java:121)
        at org.gradle.internal.graph.CachingDirectedGraphWalker.findValues(CachingDirectedGraphWalker.java:73)
        at org.gradle.api.internal.tasks.CachingTaskDependencyResolveContext.getDependencies(CachingTaskDependencyResolveContext.java:67)
        ... 114 more
Caused by: org.gradle.api.internal.provider.AbstractProperty$PropertyQueryException: Failed to calculate the value of task ':compileTestJava' property 'javaCompiler'.
        at org.gradle.api.internal.provider.AbstractProperty.finalizeNow(AbstractProperty.java:239)
        at org.gradle.api.internal.provider.AbstractProperty.beforeRead(AbstractProperty.java:230)
        at org.gradle.api.internal.provider.AbstractProperty.calculatePresence(AbstractProperty.java:56)
        at org.gradle.api.internal.provider.AbstractMinimalProvider.isPresent(AbstractMinimalProvider.java:74)
        at org.gradle.api.plugins.JavaBasePlugin.lambda$determineCompatibility$8(JavaBasePlugin.java:326)
        at org.gradle.util.GUtil.uncheckedCall(GUtil.java:442)
        at org.gradle.internal.extensibility.ConventionAwareHelper$2.doGetValue(ConventionAwareHelper.java:82)
        at org.gradle.internal.extensibility.ConventionAwareHelper$MappedPropertyImpl.getValue(ConventionAwareHelper.java:128)
        at org.gradle.internal.extensibility.ConventionAwareHelper.getConventionValue(ConventionAwareHelper.java:110)
        at org.gradle.api.tasks.compile.JavaCompile_Decorated.getTargetCompatibility(Unknown Source)
        at org.gradle.api.plugins.jvm.internal.DefaultJvmPluginServices.lambda$configureDefaultTargetPlatform$4(DefaultJvmPluginServices.java:211)
        at org.gradle.internal.Actions$CompositeAction.execute(Actions.java:116)
        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.preventFromFurtherMutation(DefaultConfiguration.java:953)
        at org.gradle.api.internal.artifacts.ivyservice.moduleconverter.DefaultLocalComponentMetadataBuilder.createConfiguration(DefaultLocalComponentMetadataBuilder.java:74)
        at org.gradle.api.internal.artifacts.ivyservice.moduleconverter.DefaultLocalComponentMetadataBuilder.addConfiguration(DefaultLocalComponentMetadataBuilder.java:48)
        at org.gradle.api.internal.artifacts.ivyservice.moduleconverter.DefaultRootComponentMetadataBuilder.addConfiguration(DefaultRootComponentMetadataBuilder.java:100)
        at org.gradle.api.internal.artifacts.ivyservice.moduleconverter.DefaultRootComponentMetadataBuilder.getRootComponentMetadata(DefaultRootComponentMetadataBuilder.java:94)
        at org.gradle.api.internal.artifacts.ivyservice.moduleconverter.DefaultRootComponentMetadataBuilder.lambda$buildRootComponentMetadata$0(DefaultRootComponentMetadataBuilder.java:84)
        at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.fromMutableState(DefaultProjectStateRegistry.java:265)
        at org.gradle.api.internal.artifacts.ivyservice.moduleconverter.DefaultRootComponentMetadataBuilder.buildRootComponentMetadata(DefaultRootComponentMetadataBuilder.java:82)
        at org.gradle.api.internal.artifacts.ivyservice.moduleconverter.DefaultRootComponentMetadataBuilder.toRootComponentMetaData(DefaultRootComponentMetadataBuilder.java:68)
        at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.toRootComponentMetaData(DefaultConfiguration.java:1070)
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.DefaultArtifactDependencyResolver$DefaultResolveContextToComponentResolver.resolve(DefaultArtifactDependencyResolver.java:219)
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.builder.DependencyGraphBuilder.resolve(DependencyGraphBuilder.java:137)
        at org.gradle.api.internal.artifacts.ivyservice.resolveengine.DefaultArtifactDependencyResolver.resolve(DefaultArtifactDependencyResolver.java:137)
        at org.gradle.api.internal.artifacts.ivyservice.DefaultConfigurationResolver.resolveBuildDependencies(DefaultConfigurationResolver.java:136)
        at org.gradle.api.internal.artifacts.ivyservice.ShortCircuitEmptyConfigurationResolver.resolveBuildDependencies(ShortCircuitEmptyConfigurationResolver.java:76)
        at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver.resolveBuildDependencies(ErrorHandlingConfigurationResolver.java:63)
        ... 124 more
Caused by: java.lang.IllegalStateException: Unable to configure Java installation, probing failed with the following message: A problem occurred starting process 'command '/Users/dev/Library/jabba/jdk/zulu@1.8.265/bin/java''
        at org.gradle.jvm.toolchain.internal.JavaInstallationProbe$ProbeResult.assertOk(JavaInstallationProbe.java:136)
        at org.gradle.jvm.toolchain.internal.JavaInstallationProbe$ProbeResult.getJavaHome(JavaInstallationProbe.java:99)
        at org.gradle.jvm.toolchain.internal.JavaToolchain.<init>(JavaToolchain.java:47)
        at org.gradle.jvm.toolchain.internal.JavaToolchainFactory.newInstance(JavaToolchainFactory.java:41)
        at org.gradle.jvm.toolchain.internal.JavaToolchainQueryService.asToolchain(JavaToolchainQueryService.java:86)
        at org.gradle.jvm.toolchain.internal.JavaToolchainQueryService.query(JavaToolchainQueryService.java:68)
        at org.gradle.jvm.toolchain.internal.JavaToolchainQueryService.lambda$findMatchingToolchain$0(JavaToolchainQueryService.java:56)
        at org.gradle.api.internal.provider.DefaultProvider.calculateOwnValue(DefaultProvider.java:66)
        at org.gradle.api.internal.provider.AbstractMinimalProvider.calculateValue(AbstractMinimalProvider.java:103)
        at org.gradle.api.internal.provider.TransformBackedProvider.calculateOwnValue(TransformBackedProvider.java:64)
        at org.gradle.api.internal.provider.AbstractMinimalProvider.calculateValue(AbstractMinimalProvider.java:103)
        at org.gradle.api.internal.provider.MappingProvider.calculateOwnValue(MappingProvider.java:55)
        at org.gradle.api.internal.provider.AbstractMinimalProvider.calculateValue(AbstractMinimalProvider.java:103)
        at org.gradle.api.internal.provider.AbstractMinimalProvider.withFinalValue(AbstractMinimalProvider.java:151)
        at org.gradle.api.internal.provider.DefaultProperty.finalValue(DefaultProperty.java:133)
        at org.gradle.api.internal.provider.DefaultProperty.finalValue(DefaultProperty.java:25)
        at org.gradle.api.internal.provider.AbstractProperty.finalizeNow(AbstractProperty.java:236)
        ... 151 more

* Get more help at https://help.gradle.org

BUILD FAILED in 758ms

@sdavids thanks for the report. Would you be able to run with --info or --debug for me? I've tried using the same JDK and it is detected properly. But I'll try some more combinations here in the meantime.
It would also be useful to know what happens if you use the javaToolchains task with a recent nightly and see what it detects.

Did you try the exact steps as above?
Especially
$ jabba current
zulu@1.11.0-9
$ echo $JAVA_HOME
/Users/dev/Library/jabba/jdk/zulu@1.11.0-9/Contents/Home
$ /usr/libexec/java_home
Unable to find any JVMs matching version "(null)".

jabba.log

Same result:
$ ./gradlew wrapper --gradle-version=6.8-20201101230034+000
$ ./gradlew --stop
Stopping Daemon(s)
1 Daemon stopped
$ ./gradlew --version

------------------------------------------------------------
Gradle 6.8-20201101230034+0000
------------------------------------------------------------

Build time:   2020-11-01 23:00:34 UTC
Revision:     ea650c049886424271b3583cc57ba260458f68c0

Kotlin:       1.4.10
Groovy:       2.5.12
Ant:          Apache Ant(TM) version 1.10.8 compiled on May 10 2020
JVM:          11.0.9 (Azul Systems, Inc. 11.0.9+11-LTS)
OS:           Mac OS X 10.15.7 x86_64

$ ./gradlew build

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':compileJava'.
> Could not resolve all dependencies for configuration ':compileClasspath'.
   > Failed to calculate the value of task ':compileTestJava' property 'javaCompiler'.
      > Unable to configure Java installation, probing failed with the following message: A problem occurred starting process 'command '/Users/dev/Library/jabba/jdk/zulu@1.8.265/bin/java''

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 874ms

Thanks @sdavids, I can reproduce this now. Interestingly, if you use the originally downloaded JDK, the layout is as expected. If you let jabba install that jdk, it wraps it additionally in the MacOS layout (Contents/Home). I think we so far we only tried jabba on Linux.

authors: bmuskalla sdavids

repo: gradle/gradle


text:
Investigate how to apply DependencyAdder pattern to "modifiers"

Expected Behavior
Ecosystems can add dependency modifier methods without having to understand all possible dependency notations.
Current Behavior
testFixtures, platform and enforcedPlatform all require multiple methods to be implemented properly.
Context
With DependencyAdder, ecosystems are not expected to implement a method for every "dependency notation".
With dependency modifiers, like testFixtures or platform, we expect plugin authors/ecosystems to be able to introduce their own. Currently, they need to implement ~4 methods and understand different dependency notations.
POC https://github.com/gradle/gradle/pull/21937
In this POC, all notations are handled by Gradle code and the ecosystem only needs to implement one method that accepts a Dependency. We still need to figure out how to wire the implementation of the modifier in a way that doesn't require a lot of magic.

FYI @octylFractal, we can talk about this more when I'm back

source: gharchive/issue

license_type: permissive

license_source: github-api


text:
Remove the announce plugin

Remove the deprecated announce plugin.

Thanks, @jjohannes!  I've fixed those - I also removed osgi from .teamcity/Gradle_Util/buildTypes too since we missed that when removing that plugin.

source: gharchive/pull-request


text:
Take all Javadoc options into account as task inputs

Previously the type of Javadoc’s options property was MinimalJavadocOptions, which declared a few nested properties. However, the real value was a StandardJavadocDocletOptions, which contains several other properties that are not declared as inputs. Now these are taken into account as well.
This commit also stops the Javadoc task from modifying its inputs during execution.
Any of the checked boxes below indicate that I took action:

[ ] Reviewed the Contribution Guidelines.
[ ] Signed the Gradle CLA.
[ ] Ensured that basic checks pass: ./gradlew quickCheck

For all non-trivial changes that modify the behavior or public API:

[ ] Before submitting a pull request, I started a discussion on the Gradle developer list,
the forum or can reference a JIRA issue.
[ ] I considered writing a design document. A design document can be
brief but explains the use case or problem you are trying to solve,
touches on the planned implementation approach as well as the test cases
that verify the behavior. Optimally, design documents should be submitted
as a separate pull request. Samples
can be found in the Gradle GitHub repository. Please let us know if you need help with
creating the design document. We are happy to help!
[ ] The pull request contains an appropriate level of unit and integration
test coverage to verify the behavior. Before submitting the pull request
I ran a build on your local machine via the command
./gradlew quickCheck <impacted-subproject>:check.
[ ] The pull request updates the Gradle documentation like user guide,
DSL reference and Javadocs where applicable.

I've added a test for changing windowTitle makes the task out-of-date now.

@big-guy please take another look

This is already released in 3.4-rc-1, shouldn't the milestone be adjusted?

Thanks @Vampire for noticing this.

authors: Vampire lacasseio lptr


text:
Move 'Using the Build Cache' into user manual

Content taken from https://guides.gradle.org/using-build-cache/
The content is mostly kept in place with minor updates:

Samples are integrated in snippet structure and updated to be idiomatic
Split into multiple chapters reachable from the nav bar, following the split of 'adoc' files that was already done in the guides repo.

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test this

OK, I've already cancelled the old build and triggered a new ReadyForMerge build for you.

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

authors: bot-gradle jjohannes


text:
Add ResolveTaskMutationsBuildOperationType

to capture task parameter resolution which happens as part of resolving mutations. This allows for attributing the resolution of nested input properties to a task.
This is particular interesting for capturing the progress events for Java toolchains, see #21281.

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test and merge

OK, I've already triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

OK, I've already triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

OK, I've already triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

OK, I've already triggered a build for you.

authors: alllex bot-gradle wolfs


text:
Update jmh plugin version

This fixes overlapping outputs between jmhRunBytecodeGenerator and
jmhCompileGeneratedClasses.

Seems to work: https://e.grdev.net/s/amyejt2nfeekk/timeline?task=q6qe5ap6gg6ou&taskFilter=jmh


text:
Improve configuration attributes matching strategy

Please do not merge this PR yet. This is for internal review only.
See gradle/performance#86 for discussion.

Closed in favor of #827


text:
CVE-2021-27219 in Glib for Grafana Operator 3.8.1

Describe the bug
CVE-2021-27219:
https://www.cvedetails.com/cve/CVE-2021-27219/
Version
This is in the integreatly grafana operator of 3.8.1 and is affected the Glibc. https://quay.io/repository/integreatly/grafana-operator?tab=tags&tag=v3.8.1

@esn89 This version is actually very old is not meant to be used nowadays. I haven't checked if operator was built with CGO disabled in that release, but if that's the case, system packages don't really have any effects in terms of vulnerabilities. In any case, you can always rebuild image with updated system packages if you wish. Though, I'd still recommend to opt for the newer versions.

Since version 3 is very out of support, I will close this issue.

authors: NissesSenap esn89 weisdd

repo: grafana-operator/grafana-operator


text:
Alloy fmt use "space" instead of "tab" for indentation

Request
Is it possible to change indentation from "tab" to "space" when i use alloy fmt please ?
Use case
In Kubernetes, when i create ConfigMap from file,  \n... are prints instead of a newline. It's hard to edit or consult ConfigMap with this formatting.
Today:
apiVersion: v1
data:
  test.alloy: "test.example \"xxx\" {\n\foo = \"bar\"\n}\n"
kind: ConfigMap
metadata:
  name: alloy
  namespace: grafana-alloy

Expected :
apiVersion: v1
data:
  test.alloy: |
    test.example "xxx" {
      foo = "bar"
    }
kind: ConfigMap
metadata:
  name: alloy
  namespace: grafana-alloy

I think this maybe cause by the terminator is '\n'?  maybe it need to add terminator judge for '\t'
https://grafana.com/docs/alloy/latest/concepts/configuration-syntax/syntax/#:~:text=Terminators,as you want.

repo: grafana/alloy


text:
Alerting functionality

It would be helpful to allow for alerts/notifications based on thresholds to be sent out.

😭

repo: grafana/clock-panel

license: MIT


text:
fix: update all OTel dependencies

Why

#467 updated just @opentelemetry/instrumentation-document-load leading to duplicated versions of @opentelemetry/instrumentation for all dependents
What

I just update all other @opentelemetry/* packages as well.
I really wish the OTel project would get off 0.x 😅
Links
N/A

Checklist

[ ] Tests added
[x] Changelog updated
[ ] Documentation updated

Hey @SimenB We released a new Faro version today.
Took a bit to release your contribution because we initially planned to add another feature but it takes a few more days to finish the docs. So we did a qol release today to not wait to long to get the deps upgrade out.
Thanks  again and cheers, till next time :)

Thanks!

authors: SimenB codecapitano

repo: grafana/faro-web-sdk


text:
Expose AzureAuthEnabled (azure_auth_enabled) value in settings

This is required as part of Prometheus decoupling/externalisation. We rely on this value in https://github.com/grafana/grafana/blob/6dea3102cb04ddde8e3a4e269a2d80023593150e/pkg/tsdb/prometheus/client/transport.go#L41
In order to read the value it must be exposed.

 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.

authors: CLAassistant itsmylife

repo: grafana/grafana-azure-sdk-go


text:
Result does not sort correctly with Multiple OrderBy

1. Steps:
    1. Select a component, and enter property group / selected properties / filter.
    2. Add multiple order by and run query
2. Error:
    1. Response on the plugin is not sorted based on the order of the OrderBy.
    2. Example add first order as x and second order as Y.
    3. Display on the panel order is based on Y but not on X.
    4. We need to add a logic sort based on the order of the OrderBy.

closing this one. as far as i can tell this seems to be an API bug. here's the request the plugin is sending:
{
    "componentName": "TabularComponent",
    "entityId": "<redacted>",
    "maxResults": 200,
    "propertyGroupName": "tabularPropertyGroup",
    "selectedProperties": [
        "total",
        "crit"
    ],
    "tabularConditions": {
        "orderBy": [
            {
                "order": "ASCENDING",
                "propertyName": "total"
            },
            {
                "order": "ASCENDING",
                "propertyName": "total"
            }
        ]
    }
}

here's a truncated response:
{
    "propertyValues": {},
    "tabularPropertyValues": [
        [
            {
                "crit": {
                    "integerValue": 4
                },
                "total": {
                    "integerValue": 0
                }
            },
            {
                "crit": {
                    "integerValue": 5
                },
                "total": {
                    "integerValue": 0
                }
            },
            {
                "crit": {
                    "integerValue": 4
                },
                "total": {
                    "integerValue": 0
                }
            }
        ]
    ]
}

scratch that, i think i found the issue. it seems to be a state issue on the frontend that is causing duplicate property names to be sent in the request:
           {
                "order": "ASCENDING",
                "propertyName": "total"
            },
            {
                "order": "ASCENDING",
                "propertyName": "total"
            }

AP response.pdf

fixed by #129

authors: divya-sea toddtreece

repo: grafana/grafana-iot-twinmaker-app


text:
allow forcing a new ssh key pair

Currently the pdc-agent uses an existing SSH key pair and certificate if they exist and are valid. We should allow users to force a new ssh key pair and certificate to be generated.
Implement a --force-key-file-overwrite flag that generates a new SSH key pair and requests a new certificate using the new public key.

Please make it somehow automaticly regenerate certificate if it fails to use already existing.
My current workaround is to add -ssh-key-file parameter that is differ from default, for example /home/pdc/.ssh/grafana_pdc_v1

Please make it somehow automaticly regenerate certificate if it fails to use already existing.

@Hronom What is the reason that the existing key fails? There is already logic for refreshing if the cert is no longer valid, so I'm wondering what the other failure modes are.

@dafydd-t hello, I'm using version 0.0.13 of dcoker image. After some time I get this error:
level=info caller=keymanager.go:52 msg="starting key manager"level=info caller=keymanager.go:52 msg="starting key manager"level=info caller=keymanager.go:52 msg="starting key manager"level=info caller=keymanager.go:156 msg="new certificate required: certificate validity has expired"level=info caller=keymanager.go:204 msg="generating new certificate"level=info caller=keymanager.go:156 msg="new certificate required: certificate validity has expired"level=info caller=keymanager.go:204 msg="generating new certificate"level=info caller=keymanager.go:156 msg="new certificate required: certificate validity has expired"level=info caller=keymanager.go:204 msg="generating new certificate"level=error caller=client.go:177 msg="unknown response from PDC API" code=502level=error caller=ssh.go:102 msg="could not check or generate certificate" error="failed to generate new certificate: key signing request failed: internal error"level=error caller=client.go:177 msg="unknown response from PDC API" code=502level=error caller=ssh.go:102 msg="could not check or generate certificate" error="failed to generate new certificate: key signing request failed: internal error"level=error caller=client.go:177 msg="unknown response from PDC API" code=502level=error caller=ssh.go:102 msg="could not check or generate certificate" error="failed to generate new certificate: key signing request failed: internal error"

If I restart containers it starting to work.
Is it fixed in 0.0.15 I see it released 2 days ago?

@Hronom 0.0.14 introduces some retries for the key signing request. This helps in some cases, but we've also identified a change required internally. That should get sorted in the next day or two.

Thanks @dafydd-t , just a side note, we found this approach (grafana-pdc-agent) very usefull and very easy to connect with Grafana Cloud, interested in active development of this and adding new datasource in it. Thanks for this great tool!

authors: Hronom dafydd-t

repo: grafana/pdc-agent


text:
Add (some) environment variable overrides

Attempting to address (some of) https://github.com/grafana/pdc-agent/issues/102.
Laying out the pattern to override these, happy to fill in "the rest" of them if this pattern seems alright (and more than willing to rename these envvars if there's a specific pattern in mind).
My first shot attempts to address the values specifically called out in this page of the documentation.
An unrelated change which I think erroneously snuck in to the .gitignore - As currently configured, the .gitignore line which has been removed ignores changes to cmd/pdc/* as well as pkg/pdc/*. This seems wrong, so I updated .gitignore as well. Feel free to revert that change if that was in fact intentional.
I don't write a ton of go in general, so if this isn't at all accurate I'm happy to rework it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Anthony Cicchetti seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@anthonycicc When developing locally, please remember to run the tests with go test ./... - that way you'll catch the kinds of build failures that happened here.
Also useful is to build the binary with go build ./cmd/pdc to see if it compiles at all.

@anthonycicc When developing locally, please remember to run the tests with go test ./... - that way you'll catch the kinds of build failures that happened here.
Also useful is to build the binary with go build ./cmd/pdc to see if it compiles at all.

Ah - Couldn't find the test/lint incantation, tried a bunch of variants with shell wildcards but not with a bunch of .s.
I'll address PR feedback tonight or tomorrow, thanks for the review(s) y'all!

I think all of the PR notes are addressed in 60f92b8 - let me know if I need another pass

Thanks @anthonycicc ! please can you add a description of the new env vars and their behaviour to the README?

One extra addition I'd like please is a section in the README which describes how these env vars are consumed (e.g. flags take precedent over env vars), and a table showing the mapping between flags and env vars.

@dafydd-t - can I get another review at your earliest convenience?

@dafydd-t any chance I could get another review on this?

authors: CLAassistant anthonycicc dafydd-t hairyhenderson


text:
Datadog direct metrics

Metrics collection is tightly coupled to statsd, which is a great decision in environments that can host an aggregator like dogstatsd or statsd_exporter nearby. Serverless environments might lack this facility.
This PR introduces metrics.DatadogClient as an alternative implementation of metrics.Client that submits metrics directly to Datadog via the metrics submission API. Moving from a local UDP aggregator to remote TCP is a notable but accepted performance regression in this iteration, and the reason this functionality is opt-in.

@googlebot I consent

@ooq this is another ~feature sized PR that we'd like to confirm before merging.
If this lands, are you open to us tagging and releasing v2.6.0?

Tagging a new release makes sense! I'm for it. @thepwagner

My only comment is that can you update the documentation to reflect this change? Particularly on the configuration differences between the local statsd mode and direct datadog mode?

Good shout! Given the existing documentation doesn't mention statsd at all and I've introduced a bit of documentation debt by adding SOPS with only a sample configuration, I'll address documentation in another PR, also before v2.6.0.

The implementation in https://github.com/grafeas/voucher/pull/37/commits/03478c200ebad1591eb4471190aa81061401cbb2 tested great in our staging environment 👍 .
But the lack of aggregation meant metrics went sideways when we promoted to production 👎 . I've added aggregation and async submission to do a better job of mocking dogstatsd in-process.

authors: dani-santos-code ooq thepwagner

repo: grafeas/voucher

license_source: bigquery


text:
suggested corrections for 4 Mixtec varieties [first batch]

Are you submitting a comment in regards to more than 10 data-points? If so, please complete this form and attach a spreadsheet with columns for feature ID number, language name/glottocode and a comment field. You can find a blank Grambank coding sheet here. Please fill in Feature and Language ID for the relevant datapoints. *
Yes, 16 data points so far. Spreadsheet is named gb1_mixtec_corrections1.tsv

Have you read the Grambank wiki article for the features that you want to suggest a change for? If not, please visit our wiki .
Yes, I read them.

What language or dialect would you like to suggest a change in coding for? Please give the Name and/or glottocode. (If more than 10 data-points, please just refer to the spreadsheet.)*
concerns 4 languages so far (alac1244, magd1235, sant1436, tezo1238)

What features do you want to suggest a change for? (If more than 10 data-points, please just refer to the spreadsheet.)*
see gb1_mixtec_corrections1.tsv

What is the reason behind this change?*
corrections to current coding

What is your expertise in regards to this language or dialect?*
I do documentation on one Mixtec variety and have experience working with all documented Mixtec varieties from a historical perspective

What sources do you have in regards to this change in coding?*
The corrections are based on the same sources as were used originally.

Archive.zip

@SAuderset
A quick qustion regarding GB023 (Are there postnominal articles?) for sant1236.
The examples with the definite article ma are prenominal. Did you find any examples with postnominal ma?

Let me check. That does sound wrong... I'm wondering if I accidentally copied in the wrong feature ID. Sorry about that, will try to get back asap with more info.

No worries and no rush.
All your other suggestions and comments that I've reviewd so far are improvements to Grambank - thank you!

Here is a list of the Mixtec languages already in Grambank raw (i.e. the continued data after grambank 1.0)
  filename Glottocode                         Name

1:  JE_atat1238   atat1238            Atatláhuca Mixtec
2:  JE_ayut1236   ayut1236                Ayutla Mixtec
3:  JE_coat1241   coat1241            Coatzospan Mixtec
4:  JG_sanm1295   sanm1295  San Miguel El Grande Mixtec
5:  MM_magd1235   magd1235     Magdalena Peñasco Mixtec
6: RHE_alac1244   alac1244         Alacatlatzala Mixtec
7: RHE_sant1436   sant1436 Santa María Zacatepec Mixtec
8: RHE_tezo1238   tezo1238             Tezoatlán Mixtec

We also have five Mixtec in the to do-list:
These are assigned to @johnaell
Diuxi-Tilantongo Mixtec | diux1235
Jamiltepec Mixtec | jami1235
These are currently unassigned:
Ocotepec Mixtec | ocot1243
Silacayoapan Mixtec | sila1250
Yosondúa Mixtec | yoso1239

@yafinka I checked and it is a copy error on my side - oops! so GB023 in my spreadsheet is GB022, or in other words, there are prenominal articles.

Hello @SAuderset!
It took me a while to decide what to code for GB020 (Are there definite or specific articles?) for alac1244 and sanm1244. After consulting with Michael on this one, I decided to code '?' for both, since the deictic function in the examples provided cannot be ruled out. Michael thinks that the function of demonstratives in the Mixtec languages may be evolving under the influence of Spanish.
Do you have any further suggestions for corrections? If not, I will submit the changes and close this issue.
Thanks again for your help!
Olga

Right now that's all I have. I'm not sure when I will make it through the rest of the features, so probably best to close it. Thanks!

authors: HedvigS SAuderset yafinka

repo: grambank/grambank


text:
Mergesort

[x] verify project, git branch, and file names
[x] create mergesort function

[x] test output variations
[x] document function

[ ] stretch goals

[ ] optimize for sorted input

Coverage increased (+0.2%) to 95.795% when pulling 12313b345fc81bf7d31b28fc301662cb924f99a3 on mergesort into 86694b1b9b447fcd7ef8e17f66a5a6b14b9af210 on master.

authors: coveralls grandquista


text:
article.cleaned_text is null

Not getting cleaned_text
>>> article = g.extract("http://vocamus.net/dave/?p=1602")
>>> article.cleaned_text

+1 I also encounter the same problem that the extractor just gets the null cleaned_text. The web page is very simple text page. I don't know what happened. Could you please help me solve the problem? @grangier
`>>> from goose import Goose

g = Goose({'use_meta_language': False, 'target_language':'en'})
content = g.extract(url='https://www.sec.gov/Archives/edgar/data/20/000095012310024631/c97665e10vk.htm')
print content.title
Form 10-K
print content.author
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'Article' object has no attribute 'author'
print content.authors
[]
content.cleaned_text
''
`

authors: harikt infinitywings

repo: grangier/python-goose


text:
Misleading changelog for tag v1.2.0

Hey guys,
I was really excited when I saw the first bullet point in the changelog for release v1.2.0, because I waited for this feature to come for quite some time now. Turns out, the linked issue #428 has only been closed but not merged and the feature isn't there at all, neither via dedicated argument nor via context.
Could we please just pick one approach or start a community vote which route they want to pick? It would really ease up some of our schemas and loaders if we would have this information upfront.
Please this discussion is going on for years now.

Hi @sGy1980de
Thank you for reporting this. It was my mistake 🤦♂ I'll try to merge the proper change and will fix it this weekend. My intention was to add this feature.

Hey @pavelnikolov,
happy to hear this. Really looking forward to this and let me thank for the precious work you guys do here.
Bye

I've removed the misleading feature. I'll add it with the next release soon. Thank you for reporting.

repo: graph-gophers/graphql-go


text:
Separate resolvers for each operation

This PR allows having fields in the schema with the same name in different operations. For example, consider the schema below:
schema {
	query: Query
	mutation: Mutation
	subscription: Subscription
}

type Query {
	hello: String!
}

type Mutation {
	hello: String!
}

type Subscription {
	hello: HelloEvent!
}

type HelloEvent {
	msg: String!
}

Before this PR it was not possible to have more than one operation with the same field name. This PR resolves the problem in a backwards compatible way.

You can update the PR description to say this fixes https://github.com/graph-gophers/graphql-go/issues/145

authors: nicksnyder pavelnikolov


text:
Allow multiple queries/mutations in one SE

It would be easier to deploy, and easier to reuse (helper) functions, if multiple queries/mutations would be allowed in a schema extensions. For inline functions, this can easily be done because multiple module.exports are allowed (I tested this before it was disabled).
For external webhooks, this could be solved by passing the name of the query/mutation in either the URL or header for a webhook.

This will besolved by #543, so closing it 🙂

authors: kbrandwijk marktani

repo: graphcool/graphcool


text:
Speed is 0 for low speed edges using motorcycle

If you use the motorcycle profile and the curvature weighting and read an OSM way with a low maxspeed, for example maxspeed=2, the speed of the edge will be 0. An example way can be found here.
java.lang.IllegalStateException: Calculating time should not require to read speed from edge in wrong direction. Reverse:false, fwd:false, bwd:false
	at com.graphhopper.routing.weighting.AbstractWeighting.calcMillis(AbstractWeighting.java:44)
	at com.graphhopper.routing.weighting.FastestWeighting.calcMillis(FastestWeighting.java:83)
	at com.graphhopper.routing.Path.processEdge(Path.java:242)

When I think about this a bit more: this is kind of expected as we set access to false for speed==0 and so if speed is rounded downwards the result can be access==false. The only other solution would be a different rounding strategy if close to 0. But having speed==0 and access==true does not make sense.

But the question is why there is a path going through if access==false for both directions.

But the question is why there is a path going through if access==false for both directions.

I think I found the issue here. The CurvatureWeighting has no clause if(speed==0) return Double.POSITIVE_INFINITIVE.

This is a more general problem that we always had problems with.
For motorcycle we could solve it consistent: we could make the access-check dependent on speed==0 and do not use separate access bits as we have one speed value for every direction.
But for other vehicles like car or foot we only want to use speedBits+2 instead speedBits*2 and so we need two separate access bits.
In the latest branch #1447 we could try to solve this via creating a special "combined" speed+access EncodedValue that handles this on the lowest level and switches to speedBits*2 without any access bits if the speed value should be stored for both directions.

authors: boldtrn karussell

repo: graphhopper/graphhopper


text:
Bringing isochrone_open_source branch up-to-date

Re #1237, this:

Brings the PR branch up-to-date with current master and its changes to versioning since Dec
Checks off the first of the five todos, renaming the 'reach' packages to 'isochrone'

Thanks, LGTM. Do you think we should rename Reachability into Isochrone(Algorithm)?

Any preferences here @willcohen?

I think the renames make sense. Apologies for the delay -- as I was giving the refactor a shot I also noticed that the ContourBuilder says it's an adaptation of org.opentripplanner.common.geometry.DelaunayIsolineBuilder, which is LGPL, which means that even if JTS and the other pieces get their license issues resolved, the broader issue will still remain once isochrones get merged in. Does it make sense to try to base this feature off of a different algorithm instead? Sextante is a little old but has a bunch of MIT-licensed GIS algorithms, including some Isolines from TIN. The canonical home for Sextante is here, but I just haven't gotten through adapting this to JTS's object types yet.

LGPL is not a huge problem for now if we document which parts are which license in the NOTICE file. We can solve this later step by step. E.g. in 0.8 we were free of LGPL and we might be free of LGPL in 0.11 again, but this is not a big problem on the server side and on mobile only Android is affected due to the "merging".

Does it make sense to try to base this feature off of a different algorithm instead?

This would be really cool, also to see other advantages (and also disadvantages). Still I would prefer this in a separate PR to avoid further delay.

Okay -- I think I got the rest of the reach -> isochrone renames with this latest commit

Thanks!

authors: karussell willcohen


text:
refactor: improve logging (add tracing crate)

Switch to using tracing instead of println!() for logging.
Next steps:

Add support for Prometheus (check out this guide)

things left to do:

enable debug log level
pass in log level to WakuNodeConfig

repo: graphops/graphcast-sdk


text:
graphviz with asciidoctor

I use graphviz with asciidoctor, but I can't set double quoted string as ID.
Thanks

@GSebastian-Adil Thanks for this question!
This project will automatically quote and escape any identifiers as needed. This means that simple integers/floats will be exported without quotes in the DOT output, whereas all other string values will automatically be quoted. Note that there's no semantic difference between both variants, it's merely a matter of making it "more readable" (https://graphviz.gitlab.io/_pages/doc/info/lang.html).
I hope this helps!

This file Example_Diagram.txt shows exactly my problem:

Please change the extension to (.adoc)
Open it with a browser

And you will that the second diagram don't work just because I changed the (ID=G) to (ID="Reflux Gastro Oesophagien") a double quotted string.
I am not a programmer.
Thanks

I'm not sure I follow the exact problem you're seeing, so here's my best guess:
If you want to assign the root graph ID or name, this is supported as of #28 like this:
$graph = new Fhaculty\Graph\Graph();
$graph->setAttribute('graphviz.name', 'G');
$graph->createVertex('first');

Note that #28 will only be released as part of the upcoming v0.3.0, so you may have to use the current master branch in the meantime.
I hope this helps :+1:

But did you try my example. my example has two diagrams:
`==========
[graphviz]
..........
digraph G {
"Reflux Gastro \n Oesophagien" -> "Oesophagite \n Peptique" -> "Stenose \n Peptique"
}
..........
[graphviz]
..........
digraph "Reflux Gastro Oesophagien" {
"Reflux Gastro \n Oesophagien" -> "Oesophagite \n Peptique" -> "Stenose \n Peptique"
}
..........
==========`
If you save this example in file (.adoc) and you open it with a browser(I use Firefox), the first diagram works, but the second has an error message because I changed the diagram's name(ID) to a quoted string.

The way I understand this problem it looks like you're asking for help in the wrong project. This project deals with using GraphViz to render graphs created with GraPHP.
Both your example graphs look good to me, so I can only assume there's some problem in one of the other programs you're using. Perhaps use StackOverflow or reach out to asciidoctor support channels for help?
I hope this helps :+1:

authors: GSebastian-Adil clue

repo: graphp/graphviz

license: mit


text:
Refactor create-subgraph-hosted.mdx

:zap: This PR would refactor create-subgraph-hosted.mdx to fix the template string error. Just a suggested change. If I need to effect the change in another way, I would do so.

Simon has fixed the issue here. We can close this PR.

Okayy

repo: graphprotocol/docs


text:
Gas errors on the network

A number of subgraphs on the network have hit the default gas limit, so indexers must configure a larger one. We should look into these with the purpose of adjusting gas costs that may be overestimated. These subgraphs have been reported as going over the limit:
QmTiKBqwDjDtjAoCNgKLFjyg9UmwyFkVMFRVzBdnFmwYEi, QmayVPFDjZ4PP8rsKiNsZ3bZsqrQo4RTaeMm966wQsjP7R, QmWd8mE5nedM5smvzQhDYmsWEcgiAtdqccdZ2XCsvCdVEK.
The Eden Network (QmWd8mE5nedM5smvzQhDYmsWEcgiAtdqccdZ2XCsvCdVEK, source link case has more details. It fails with:
May 11 12:44:54.957 ERRO Subgraph failed with non-deterministic error: failed to process trigger: block #13807949 (0x0bf6…ac4c), transaction 0229c81e816101dbb7f5ecfb4ea3a0eb2c82083f10123e0a504a1dbd7063eaa1: Gas limit exceeded. Used: 10000016722787	wasm backtrace:	    0: 0x2235 - <unknown>!~lib/@graphprotocol/graph-ts/index/Value#toArray	    1: 0x2891 - <unknown>!src/network/stakeUnstake	    2: 0x271f - <unknown>!src/network/stakeUnstake~anonymous|5	    3: 0x292b - <unknown>!src/network/stake	    4: 0x29d2 - <unknown>!~lib/internal/memory/memcmp	, retry_delay_s: 1800, attempt: 651, sgd: 101, subgraph_id: QmWd8mE5nedM5smvzQhDYmsWEcgiAtdqccdZ2XCsvCdVEK, component: SubgraphInstanceManager
May 11 12:44:54.955 INFO Done processing trigger, gas_used: 0, data_source: EdenNetwork, handler: stake, total_ms: 62643, transaction: 0x0229…eaa1, address: 0x9e33…c453, signature: Stake(indexed address,uint256), block_hash: 0x0bf6b37adec469650eeac0d9dea4add97fcf9acbc37c3412accf40b96399ac4c, block_number: 13807949, sgd: 101, subgraph_id: QmWd8mE5nedM5smvzQhDYmsWEcgiAtdqccdZ2XCsvCdVEK, component: SubgraphInstanceManager

Probably due to iterating over a large collection, the network.stakers array might be as large as 4.5k entries.

thanks @leoyvens - we should investigate whether the gas costs are miscalibrated, but also consider if the subgraphs themselves could be optimised, or if more gas-efficient affordances are required for developers (i.e. there is no available optimisation based on the current graph-node feature set)

Still relevant.

Ran into this too

Does anyone know how to manually increase such limit?

@songhobby that's a different issue, on eth_call gas, the fix will be rolled out to hosted tomorrow.

authors: azf20 leoyvens songhobby

repo: graphprotocol/graph-node


text:
Hosted Service Subgraph Not Returning All Records

Do you want to request a feature or report a bug?
bug
What is the current behavior?
not all records are returned
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
Create a counting entity.
Then create another entity that increments id whenever a new event occurs, and update the counting entity accordingly.
Make ~200 records.
Make a call to get all the created records.
Notice that not 200 records are returned, a good chunk of them are missing.
What is the expected behavior?
have all records returned when making an API call to the hosted service subgraph
Please let me know if this is just user error

Hi - can you provide a more specific example, including the query you are making?

Sure!
Can't really share the backend because it's a private repo
But i have a feeling that it's the query because the counter goes way up and the query records records that seem to skip specific ID numbers. Makes me feel that they just aren't returned with the query
{
  liquidations() {
    id
  }
}

By default only 100 records are returned, update to:
{
  liquidations(first:1000) { id }
}


text:
log additional information in exchanges

When we move money between Gittip and the outside world we call that an "exchange" and we record each such event in the exchanges table. Here's its schema:
=> \d exchanges
                                     Table "public.exchanges"
┌─────────────┬──────────────────────────┬────────────────────────────────────────────────────────┐
│   Column    │           Type           │                       Modifiers                        │
├─────────────┼──────────────────────────┼────────────────────────────────────────────────────────┤
│ id          │ integer                  │ not null default nextval('exchanges_id_seq'::regclass) │
│ timestamp   │ timestamp with time zone │ not null default now()                                 │
│ amount      │ numeric(35,2)            │ not null                                               │
│ fee         │ numeric(35,2)            │ not null                                               │
│ participant │ text                     │ not null                                               │
│ recorder    │ text                     │                                                        │
│ note        │ text                     │                                                        │
└─────────────┴──────────────────────────┴────────────────────────────────────────────────────────┘
Indexes:
    "exchanges_pkey" PRIMARY KEY, btree (id)
Foreign-key constraints:
    "exchanges_participant_fkey" FOREIGN KEY (participant) REFERENCES participants(username) ON UPDATE CASCADE ON DELETE RESTRICT
    "exchanges_recorder_fkey" FOREIGN KEY (recorder) REFERENCES participants(username) ON UPDATE CASCADE ON DELETE RESTRICT

The relationship between amount and fee is complicated and should be cleaned up. That's #2442.
The recorder and note fields are used when an admin manually enters an exchange.
What we need here is more information recorded during an exchange in order to aid debugging, e.g. on #2372. Exchanges involve API calls to Balanced (etc.). We should record detailed information about what API call was made and what the result was. We should also record what funding instrument was involved so that whether or not there is a failure we can make our reporting more accurate (#1681).

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/2387872-log-additional-information-in-exchanges?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github).

Added to the Balanced shutdown milestone.

if we're comfortable trusting Balanced as our datastore

:disappointed:

If we want to fix those we'll have to do lots of Balanced API queries to retrieve the information.

I downloaded all transactions in JSON format on https://github.com/gratipay/inside.gratipay.com/issues/308 and uploaded them to https://github.com/gratipay/logs/tree/master/misc/308/raw/balanced/transactions.

We should also record what funding instrument was involved so that whether or not there is a failure we can make our reporting more accurate (#1681).

That's the route column, which we have now and need to use properly in #3839, which is blocked on #2779, which is blocked on #3822.

What we need here is more information recorded during an exchange in order to aid debugging, e.g. on #2372. Exchanges involve API calls to Balanced (etc.). We should record detailed information about what API call was made and what the result was.

This is the new ref column that was added in #3810 and should be cleaned up alongside route.
Closing this as done with ref.


text:
Come up with a more concise way to express repeated, scope-specific information

When writing docs, we often need to use ScopedBlocks to make small items of information appropriate for a particular scope. One example is the address of the Teleport Proxy Service. Our docs often use the address teleport.example.com for self-hosted clusters and mytenant.teleport.sh for Teleport Cloud tenants.
I think we should come up with a way to make this repeated edition-specific information more concise in docs pages. Currently, we need to copy every code block in a separate ScopedBlock to change a small item of information for users of different scopes. This makes pages more difficult to read and maintain.
For example, in the Server Access getting started guide, we need to duplicate the teleport start command example only to change the address of the Proxy for each scope.
Some possible solutions:

Allow ScopedBlocks to be child elements of Code (not sure if this is possible) so we don't need to copy a whole code block for each scope.

Add support for scoped template variables in the Code component, so the Code component would check its content for, e.g., {{ "cloud": mytenant.teleport.sh, ["oss", "enterprise"]: teleport.example.com }} and replace the template variable depending on the scope.

Closing since we can use the Var component to stand in for the Proxy Service address. This fixes the question that inspired this issue. For more specific ScopedBlocks challenges, we can open further issues.

repo: gravitational/docs


text:
fix not finding netclient binary (introduced in #613)

Describe your changes
fix finding binary in docker startup script
Provide testing steps
Start docker container (without this fix) so you see, that it cannot find the netlink binary so it is not working at all.
With this fix the binary ist found again.
Checklist before requesting a review

[x] My changes affect only 10 files or less.
[x] I have performed a self-review of my code and tested it.
[ ] If it is a new feature, I have added thorough tests, my code is <= 1450 lines.
[x] If it is a bugfix, my code is <= 200 lines.
[x] My functions are <= 80 lines.
[ ] I have had my code reviewed by a peer.
[ ] My unit tests pass locally.
[x] Netclient & Netmaker are awesome.

closing this PR as these changes are not required

repo: gravitl/netclient


text:
WIP: #221 - Added function to add token from context to requests

#221 - Added function to add token from context to requests

Closed in favor of #229

authors: LucasPaganini olivier-gravwell

repo: gravwell/js-client


text:
feat(cart): wait for cart resolution in cart guards

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/graycoreio/daffodil/blob/master/CONTRIBUTING.md#commit
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Cart guards will emit immediately, possibly before the cart has been resolved.
What is the new behavior?
Cart guards will wait for a defined cart ID before evaluating the prescence of the cart field and emitting.
Does this PR introduce a breaking change?
[ ] Yes
[x] No

Other information

/azp run

repo: graycoreio/daffodil


text:
feat(core,driver)!: rename DaffApolloCacheableOperationLinkGenerator -> DaffApolloLinkGenerator

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/graycoreio/daffodil/blob/develop/CONTRIBUTING.md#commit
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

Does this PR introduce a breaking change?
[x] Yes
[ ] No

DaffApolloCacheableOperationLinkGenerator has been renamed to DaffApolloLinkGenerator
Other information

/azp run

/azp run

/azp run

/azp run


text:
fix(design): fix bug where qty-dropdown had no validation

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/graycoreio/daffodil/blob/master/CONTRIBUTING.md#commit
[x] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?
[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

Fixes: https://github.com/graycoreio/daffodil/issues/295
Does this PR introduce a breaking change?
[ ] Yes
[x] No

@lderrickable I don't think these changes make too much sense. Firstly, this component is super awkward and requires the use of dom-selectors. I think this component needs to be refactored to implement the ControlValueAccessor.
I also think that it makes more sense to prevent bad inputs (actually blocking the change of the value) instead of not emitting on bad changes.

ok. I don't think we should do the refactor right now, because we agreed to table most design changes with v0.0.2.
I'll look into the other changes though

on second thought, I do actually block the change of the value as well as not emit any changes. But in demo, you're still going to run into the problem where if the user enters "-1" they can still add the product to the cart unless demo uses the "valid" flag.

Closing in favor of #330

authors: damienwebdev lderrickable


text:
Upgrade to Angular 8

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/graycoreio/daffodil/blob/master/CONTRIBUTING.md#commit
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Fixes: N/A
What is the new behavior?
Does this PR introduce a breaking change?
[ ] Yes
[ ] No

Other information

@lderrickable @xelaint I've rebased this off current develop.

lgtm


text:
False Positive on Malwarebytes (MachineLearning hit, Reported to Malwarebytes)

Malwarebytes reports ChiaPlotStatus as Anomalous based on a guess by a neural network: VirusTotal
Reported on Malwarebytes forum

Hi,
This is detected by our MachineLearning engine, which helps to protect even better against 0day threats. Unfortunately, as this is a heuristic engine, it's possible False Positives happen. Also see here for more explanation: https://forums.malwarebytes.com/topic/238670-machinelearninganomalous-detections-and-explanation/
Thanks for reporting these, as this helps to finetune the engine, so these won't be detected in the future anymore.
This should be fixed by now. Please give it some time (max 10 minutes) in order to have it populate, so detection won't happen anymore.

- miekiemoes (Malwarebytes employee) Posted 30 minutes ago
VirusTotal is not yet updated, still reports it

Still a false positive, reported it on their forum again

The attached file is not detected by the consumer or commercial versions of Malwarebytes.
The engine format and configuration in VirusTotal is different than the consumer and corporate products’ default configuration. In VirusTotal Malwarebytes uses a command-line engine with different configuration and detection techniques/heuristics which might detect more than the commercial product. There are also false-positive suppression mechanisms in the commercial product which are not present in the command-line engine in VirusTotal.
This will eventually fix itself in Virustotal as well, as Malwarebytes has no control over this. Virus Total is having trouble reaching Malwarebytes cloud.

- Porthos (Malwarebytes employee)

New release setup.exe no longer triggers false positives on VirusTotal.
Chrome Browser blocks both Setup and Zip file anyway.
This is getting annoying really fast.

Chrome Browser decided to stop blocking the Setup, but not the Zip file

No longer addind the zip file to the releases. It gets blocked on every release and the setup is not.
VirusTotal got the malwarebytes update.
BlackBerry Cyber Security  Cylance is reporting the Setup. Reported to cylancefilesubmit@cylance.com

Funny, no its microsoft, but only on VirusTotal again. Windows Defender locally did not care.
Submitted a repot...
Cylance is still on it.
Maybe I should do this false positives reporting business every time before I publish the release. Would mean I cannot react to users problems soon enough.

Microsoft removed the false positive.

Submission ID: 3563a365-29a0-4b84-b223-e244acab0b22
Status: Completed
Submitted: May 4, 2021 14:59:07
User Opinion: PuaFalse
PositiveAnalyst comments:
We have removed the detection. Please follow the steps below to clear cached detection and obtain the latest malware definitions.

Open command prompt as administrator and change directory to c:\Program Files\Windows Defender
Run “MpCmdRun.exe -removedefinitions -dynamicsignatures”
Run "MpCmdRun.exe -SignatureUpdate"

Alternatively, the latest definition is available for download here: https://www.microsoft.com/en-us/wdsi/definitions
Thank you for contacting Microsoft.

New Version is without false positives.

setup.exe
Submission ID: 08b519c3-cfe9-4353-b429-7bc8d774e41d
Status: Completed
Submitted: May 11, 2021 20:50:54
User Opinion: Incorrect detection
Analyst comments:
We’ve reviewed your submission and we've confirmed that the submitted files are clean. Windows Defender Antivirus doesn't report them as malware.
The message you observed is a notification from Windows Defender SmartScreen indicating that the application does not have known reputation in our system. Application reputation warnings are meant to inform end users when applications do not have known positive reputation. This doesn’t mean that the application is malicious, only that it is “unknown”. Please note that users can still proceed to download and run the application.

Chia Plot Status uses the Avalonia Library to build a GUI that runs on Windows, Linux and Mac.
The Avalonia library got flagged as a Trojan by Windows Defender yesterday (version 0.10.3) and today (version 0.10.4). Spoiler: it was safe and clean all along.
Multiple developers using Avalonia and the users of those developers apps got the scares.
It was manually checked by malwarebytes and microsofts analysts as part of the checks of Chia Plot Status Setup.exe before, got a clean mark, then got flagged as a Trojan yesterday, got submitted for manual analalysis by experts, got another clean mark, was no longer reported as Trojan, then got flagged again, then re-submitted for yet another analysis.
Only Windows Defender and no other Anti Virus flagged the file. The whole time VirusTotal showed the files as absolute clean with no warning what so ever.
Now seems to be viewed as clean again.
Had to add a notice to the download section explaining what happened and that it is an external library, not Chia Plot Status that is flagged.
Issues involved in this among duplicates: #50 #47

Today the entire Avalonia Incident repeated itself, see #91 for details.
As of now, the files are deemed safe and are no longer reported by Windows Defender if virus signature database is up to date.
Users of Chia Plot Status were and still are safe the whole time.

repo: grayfallstown/Chia-Plot-Status


text:
How much RAM program needs to fully parse current size of blockchain?

I've tried at run it with 4GB of ram, and still got out of memory exception.

That depends on how many addresses are stored in the database.
I strongly suggest to use the --lowmem option. It uses on disk database rather then in RAM dictionary, it is slower but tackles memory issues. It takes about 1 hour on my 2ghz 6Gb ntb (with oldish ssd).
Please let me know if it resolved your problem.

authors: PaulGregor graymauser


text:
gateware.usb.usb2.request: USBRequestHandler defines managed requests

This commit adds a handled() method to USBRequestHandler. This method takes a SetupPacket as an argument and returns an Amaranth boolean indicating whether a request has been taken care of.
These signals from the various request handlers are subsequently combined to trigger a stall for unhandled cases.
Merge in block with:

https://github.com/greatscottgadgets/luna/pull/226
https://github.com/greatscottgadgets/apollo/pull/22
https://github.com/greatscottgadgets/cynthion/pull/23

Hi @mndza,
@miek and I don't think this one depends on the other PRs mentioned. Do you see a reason for this PR to wait for the rest?
@zyp how do you feel about this change from the point of view of OrbTrace, or other downstream users?

From an Orbtrace perspective, this would be a welcome improvement. We've got interface handlers that'll stall nonexistent requests on the interfaces they handle, but nothing that'll stall requests that's not directed to any of the handled interfaces.

Hi @mndza,
@miek and I don't think this one depends on the other PRs mentioned. Do you see a reason for this PR to wait for the rest?

I agree that this PR should be independent. I'm removing any references to the other PRs. Let me know if there are any other concerns or adjustments needed.

It'd be nice to have a request dispatcher that you could just register request handlers with, automatically generating both the handled logic and the dispatch logic in elaborate.

I've just pushed a different approach for this PR.
Instead of a handled method, there's a new claim signal in RequestHandlerInterface.
When a USBRequestHandler wants to manage an incoming request, it must assert this signal. This lets the handler  drive the rest of interface outputs.
It makes the logic in USBRequestHandlerMultiplexer simpler, and introduces a fallback mechanism for unhandled requests: when no handler claims a request, or more than 1 does, the multiplexer selects this fallback.

authors: martinling mndza zyp

repo: greatscottgadgets/luna


text:
Make a demo with CSS generation in frontend land

Girouette, Instaparse and Garden are all written in CLJC, which means that it should be possible to generate the CSS content while running in the browser.
That could be a good development setup, as it would be independent from the various build tools which the Clojure community enjoys.

Very interesting!  I am curious to see this approach. Could be useful so the user of an app could customize the site theme dynamically. Just regenerate the css based in the config file.

There are many ways to collect the list of the CSS classes used in a webapp:

By traversing the DOM tree dynamically.
By using a macros which collect the CSS classes statically or dynamically.
By explicitly providing a generated sequence of CSS classes to Girouette.

I understand that.  I still want to generate a default list for now.
On Wed, Nov 24, 2021, 2:28 AM Vincent Cantin @.***>
wrote:

There are many ways to collect the list of the CSS classes used in a
webapp:

By traversing the DOM tree dynamically.
By using a macros which collect the CSS classes statically or
dynamically.
By explicitly providing a generated sequence of CSS classes to
Girouette.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/green-coder/girouette/issues/26#issuecomment-977362651,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACS2CGU7PXO3GLVAFS3N2LTUNQ5VJANCNFSM4WEB4EMQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

repo: green-coder/girouette


text:
Inconsistend values in display-results and get-measurement if I add manually

@dan-mm
The results of display-results and get-measurement could diverge if some code happens between its call and get-measurement. I think this is unneeded.
I would argue that the calculation is done on the same basis of data, so that they always show the same values  or not at all.
An implementation for the latter could be to not re-run the ML model but just take whatever is in the /tmp/eco-ci/energy-total.txt at this point in time
What do you think?

Its been refactored to work like this, closing this issue

authors: ArneTR dan-mm


text:
eco-ci-output.txt is empty for GitLab pipeline

Hi guys, I'm trying to measure a GitLab job like this, but the resulting eco-ci-output.txt is empty.
image: ubuntu:22.04

services:
  - openjdk:11-jre-buster

include:
  remote: 'https://raw.githubusercontent.com/green-coding-berlin/eco-ci-energy-estimation/main/eco-ci-gitlab.yml'

stages:
  - build

build:
  stage: build
  script:
    - apt-get update
    - apt-get install default-jdk -y
    - export ECO_CI_LABEL="build"
    - !reference [.initialize_energy_estimator, script]
    - !reference [.start_measurement, script]
    - chmod +x ./gradlew
    - ./gradlew check assemble
    - !reference [.get_measurement, script]
    - !reference [.display_results, script]
  artifacts:
    paths:
      - eco-ci-output.txt

Here's the console output:
...
$ echo 'running eco-ci start script' # collapsed multi-line command
running eco-ci start script
⚠ Unknown model model name	: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
model name	: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
model name	: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
model name	: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz for estimation, running default ...
$ chmod +x ./gradlew
$ ./gradlew check assemble
Starting a Gradle Daemon (subsequent builds will be faster)
> Task :compileJava
> Task :processResources
> Task :classes
> Task :bootJarMainClassName
> Task :bootJar
> Task :jar
> Task :compileTestJava
> Task :processTestResources
> Task :testClasses
> Task :test
> Task :check
> Task :assemble
BUILD SUCCESSFUL in 2m 37s
8 actionable tasks: 8 executed
$ echo 'running eco-ci measure script'
running eco-ci measure script
$ repo=$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME # collapsed multi-line command
38.38 32.23 17.45 8.14 8.12 12.92 4.24 5.53 5.53 11.05 10.00 4.96 12.04 30.50 54.75 58.46 60.90 58.75 81.42 59.45 64.65 60.15 62.53 61.90 62.56 48.48 38.89 40.70 72.50 50.51 40.46 99.50 99.50 58.19 57.89 61.10 62.96 81.27 81.30 58.69 71.54 67.34 69.00 72.39 35.13 27.66 21.88 24.23 14.73 10.31 9.14 17.01 13.40 13.33 19.49 53.52 53.79 53.02 52.76 53.88 52.63 52.90 53.16 48.74 60.45 73.30 65.49 74.00 84.38 70.28 92.11 90.50 87.68 89.90 88.35 88.24 90.45 90.00 86.40 88.80 84.74 86.22 87.82 83.59 66.67 50.89 46.08 40.61 53.03 53.25 51.13 48.36 55.42 43.25 50.00 44.16 57.18 78.48 67.17 78.59 56.96 52.79 74.25 65.91 76.59 77.27 62.53 61.21 60.86 64.82 72.98 67.34 63.61 60.00 61.15 61.77 66.08 94.71 76.32 60.45 56.53 70.43 67.51 61.27 65.49 62.28 70.85 64.91 60.05 61.46 57.68 78.50 71.07 73.37 74.37 59.19 61.65 86.65 70.85 84.79 97.24 82.78 82.16 62.03 56.64 59.75 61.62 54.27 83.17 73.05 60.10 79.35 37.75 0.00 8.50 1.25 36.00
$ echo 'running eco-ci display script'
running eco-ci display script
$ FORMAT_CLR="\e[44m" && TXT_CLEAR="\e[0m" # collapsed multi-line command
cat: /tmp/eco-ci/output-short.txt: No such file or directory
$ echo -e "$FORMAT_CLR$(cat /tmp/eco-ci/output.txt)$TXT_CLEAR"
$ cp /tmp/eco-ci/output.txt ./eco-ci-output.txt
section_end:1689932512:step_script
section_start:1689932512:archive_cache
Saving cache for successful job
Creating cache default...
WARNING: /tmp/eco-ci/venv/: no matching files
Archive is up to date!
Created cache
section_end:1689932512:archive_cache
section_start:1689932512:upload_artifacts_on_success
Uploading artifacts for successful job
Uploading artifacts...
eco-ci-output.txt: found 1 matching files and directories
Uploading artifacts as "archive" to coordinator... ok
section_end:1689932513:upload_artifacts_on_success
section_start:1689932513:cleanup_file_variables
Cleaning up file based variables
section_end:1689932514:cleanup_file_variables
Job succeeded

Hey @NatalieZava , nice that you are trying out the Eco-CI to measure your pipelines!
What I see in the debug is that the CPU is not found, which is suprising as we are currently not aware that Gitlab Shared runners are using different CPUs than the AMD Epyc ones.
=> Are you running on Gitlab shared runners or in a self hosted instance?

@dan-mm Could you look into the error that /tmp/eco-ci/output-short.txt does not exist and thus 'eco-ci-output.txt' cannot be popuplated?

Hi @dan-mm and @ArneTR - Thanks! It's working now 🤩

Hey @NatalieZava : Do you still have a reply for us if you are using a shared runner or a self-hosted one?
We have never seen this line before and are curious where the unknown CPU is coming from:
Unknown model model name	: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz

authors: ArneTR NatalieZava


text:
Handling for not being initialized yet, to not throw exceptions

Uncaught TypeError: Cannot read property 'clearRect' of undefined
This happens if you try to empty() the thing before it has been added to a map, and thus before it has assigned itself a canvas. Work around this if feasible, or else throw a proper descriptive exception.

Commit 503558b fixes this, throwing a proper exception if you try to empty() it before adding to a map.

Commit 7a605f0 expands upon this, adding a proper exception to the draw() method, in case someone adds markers and does a redraw... having never set it to a map anyway.

repo: greeninfo/MapSpotlight


text:
Line width

It would be nice to be able to set line width, just like point size, to draw thicker lines.
I can see that gl.lineWidth follows window.devicePixelRatio when CSS is selected. When I zoom in with cmd/ctrl + + DPR increases and so does the line width.
Is it possible to return a line width per vertex or at least set it globally?
Maybe the easiest is to add a few options to Navitve/CSS called 2x, 3x, 4x to get the same effect as a higher DPR on all screens.

line width is no longer a feature of webgl.
Browsers needed to switch to the OpenGL 4+ core profile to support WebGL2 and the OpenGL 4+ core profile does not support line widths greater than 1. From the OpenGL 4.0+ spec, section E.2.1

E.2.1 Deprecated But Still Supported Features

The following features are deprecated, but still present in the core profile. They may be removed from a future version of OpenGL, and are removed in a forward compatible context implementing the core profile.

Wide lines - LineWidth values greater than 1.0 will generate an INVALID_VALUE error.

authors: greggman johanberonius

repo: greggman/vertexshaderart


text:
[BUG] when MSAA disable gl.SAMPLES return 1 and gl.SAMPLE_BUFFERS return 0 drawingBuffer should have no resolve texture

when gl.SAMPLES return 1 && gl.SAMPLE_BUFFERS return 0,  it should have no resolve texture
https://github.com/greggman/webgl-memory/blob/a8ea6ed1909a2b1f914fd408e3293b9048775627/src/utils.js#L122
return size * colorSize + size * (smaples === 1 ? 0 :  smaples) * colorSize + size * depthStencilSize;

My understanding is that WebGL is always double buffered (having implemented WebGL in Chrome). One texture is given to the compositor. The other is the one you're rendering too. Otherwise, you could end up drawing on the buffer that's being used by the compositor. Since the compositor runs other threads or even another process that's unacceptable.

@greggman this resolve strategy still works when WebGL runs in mobile device which GPU is tile based rendering? it should be resolve per tile to minimize resolve texture

canvas rendering texture + (resolve texture)? + compositor texture + depth stencil texture

the resolve texture is the compositor texture
There is no guarantee what happens in the browser. It could be quadruple buffereed. It's up to the browser. All we know is that it's supposed to act as though it's double buffered and, if the canvas is multisampled then it may be resolved and that resolve might be directly into the 2nd buffer.
So, ideally it's one of 2 situations

double buffered
canvas's drawingBuffer is swapped with the compositor's displayBuffer

copied
canvas's drawingBuffer is copied to the compositor's displayBuffer

"resolve" is the same as copy so this is situation 2. resolve the drawingBuffer into the compositor's displayBuffer
Whether the compositor is double or triple buffering its displayBuffer's is unknowable from the webpage. So from the POV of WebGL. There are always 2 textures. One may be multisampled or not. The other is not.

@greggman it seems drawing buffer is not including the compositor texture in OpenGL
should compositor texture included in WebGL?
and compositor texture cannot be seen as resolve texture which doesn't exist when no MSAA

I'm not sure what point you're trying to make about no resolve texture.
OpenGL is not double buffered by default. WebGL is double buffered by default. WebGL is higher level than OpenGL because it includes the canvas. Where as OpenGL doesn't include a drawing buffer at all. It leaves that to EGL.
At a minimum there are 2 textures in WebGL (not OpenGL)

The drawing buffer (this may or may not be multi-sampled)
The compositor's display buffer (this is not multi-sampled)

The "resolve target" is (2) if (1) is multi-sampled but there are still only 2 textures and there are always at least 2 textures, whether or not a "resolve" happens. "resolve" is just in a sense just fancy word for "copy" (copy with filtering).  We can copy (1) -> (2). We can "resolve" (1) -> (2). We can also swap (1) with (2).
There may be cases were there are 3 or 4 textures but we can't know that. We can only know there are at least 2.

@greggman thanks for explain

authors: deepkolos greggman

repo: greggman/webgl-memory