text:
Is there a mirror image in China that can completely download project related dependencies

I've tried many methods. There are always some dependencies that can't be downloaded. Who can help me?

Thank you for your interest in Gradle!
Please ask such a usage question on https://discuss.gradle.org or https://stackoverflow.com where to get answers by the community of Gradle users.
If, after investigation, it turns out to be a Gradle bug or missing feature, please file another issue describing the problem or use case and add a reproducer.

source: gharchive/issue

authors: kimonic ljacomet

repo: gradle/gradle

license_type: permissive

license_source: github-api


text:
Daemon log fills with less than useful information when daemon is idle

When a daemon becomes idle, we reset the logger to DEBUG.  Since we have some periodic checks that run while the daemon is idle (like memory monitoring), this produces messages like this in the daemon log:

15:50:43.268 [DEBUG] [org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 17179869184, Free: 5623406592}
15:50:43.268 [DEBUG] [org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 17179869184, Free: 5623406592}
15:50:43.268 [DEBUG] [org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 2058354688, Committed: 2064121856}
15:50:48.269 [DEBUG] [org.gradle.process.internal.health.memory.MemoryManager] Emitting OS memory status event {Total: 17179869184, Free: 5624094720}
15:50:48.269 [DEBUG] [org.gradle.launcher.daemon.server.health.LowMemoryDaemonExpirationStrategy] Received memory status update: {Total: 17179869184, Free: 5624094720}
15:50:48.269 [DEBUG] [org.gradle.process.internal.health.memory.MemoryManager] Emitting JVM memory status event {Maximum: 2058354688, Committed: 2064121856}
15:50:48.777 [DEBUG] [org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
15:50:48.778 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
15:50:48.778 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
15:50:48.779 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
15:50:48.779 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
15:50:48.779 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
15:50:48.780 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
15:50:48.780 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
15:50:48.780 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
15:50:48.781 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.

It would be nice to limit this, possibly by increasing the logging level in an idle daemon to INFO or better.

The logging isn't too crazy right now. We're producing ~1MB an hour.

@big-guy did you find any solution? please help

authors: JankiGohel-Inteloom big-guy


text:
Analyze Gradle API usage in popular plugins

In preparation to the provider API migration let's figure out what sort of API usages affect task and other properties in popular plugins.
@jvandort did something similar already:

Its not PR ready yet but here’s the branch: https://github.com/gradle/gradle/compare/jvandort/testing/scanner-plugin
There’s a mix of concepts here but this should work if you run ./gradlew :scanner-plugin-resolver:analyzeAllPlugins and find the output file in the /subprojects/scanner-plugin-resolver/build directory.

cc: @gradle/bt-execution

Prototype of analyzer tool: https://github.com/lptr/gradle-plugin-analyzer


text:
Gradle 8.6-rc-1 can't build Spring Boot 2.x based projects

Current Behavior
Given a project that uses Spring Boot 2.x and Gradle 8.6-rc-1, when trying to produce a boot jar, the build fails with:
Caused by: org.gradle.api.GradleException: Failed to get permissions
        at org.springframework.boot.gradle.tasks.bundling.BootZipCopyAction$Processor.getPermissions(BootZipCopyAction.java:426)
        at org.springframework.boot.gradle.tasks.bundling.BootZipCopyAction$Processor.getFileMode(BootZipCopyAction.java:416)
        at org.springframework.boot.gradle.tasks.bundling.BootZipCopyAction$Processor.processDirectory(BootZipCopyAction.java:235)
        at org.springframework.boot.gradle.tasks.bundling.BootZipCopyAction$Processor.process(BootZipCopyAction.java:216)
        at org.gradle.api.internal.file.copy.NormalizingCopyActionDecorator.maybeVisit(NormalizingCopyActionDecorator.java:108)
        at org.gradle.api.internal.file.copy.NormalizingCopyActionDecorator.lambda$execute$0(NormalizingCopyActionDecorator.java:74)
        at org.gradle.api.internal.file.copy.DuplicateHandlingCopyActionDecorator.lambda$execute$0(DuplicateHandlingCopyActionDecorator.java:65)
        at org.gradle.api.internal.file.copy.CopyFileVisitorImpl.processFile(CopyFileVisitorImpl.java:68)
        at org.gradle.api.internal.file.copy.CopyFileVisitorImpl.visitFile(CopyFileVisitorImpl.java:52)
        at org.gradle.api.internal.file.collections.FilteredMinimalFileTree$2.visitFile(FilteredMinimalFileTree.java:95)
        at org.gradle.api.internal.file.collections.GeneratedSingletonFileTree.visit(GeneratedSingletonFileTree.java:109)
        at org.gradle.api.internal.file.collections.FilteredMinimalFileTree.visit(FilteredMinimalFileTree.java:84)
        at org.gradle.api.internal.file.collections.FileTreeAdapter.visit(FileTreeAdapter.java:110)
        at org.gradle.api.internal.file.CompositeFileTree.visit(CompositeFileTree.java:108)
        at org.gradle.api.internal.file.copy.CopySpecActionImpl.execute(CopySpecActionImpl.java:43)
        at org.gradle.api.internal.file.copy.CopySpecActionImpl.execute(CopySpecActionImpl.java:25)
        at org.gradle.api.internal.file.copy.DefaultCopySpec$DefaultCopySpecResolver.walk(DefaultCopySpec.java:841)
        at org.gradle.api.internal.file.copy.DefaultCopySpec$DefaultCopySpecResolver.walk(DefaultCopySpec.java:843)
        at org.gradle.api.internal.file.copy.DefaultCopySpec$DefaultCopySpecResolver.walk(DefaultCopySpec.java:843)
        at org.gradle.api.internal.file.copy.DefaultCopySpec.walk(DefaultCopySpec.java:560)
        at org.gradle.api.internal.file.copy.CopySpecBackedCopyActionProcessingStream.process(CopySpecBackedCopyActionProcessingStream.java:42)
        at org.gradle.api.internal.file.copy.DuplicateHandlingCopyActionDecorator.lambda$execute$1(DuplicateHandlingCopyActionDecorator.java:47)
        at org.gradle.api.internal.file.copy.NormalizingCopyActionDecorator.lambda$execute$1(NormalizingCopyActionDecorator.java:67)
        at org.springframework.boot.gradle.tasks.bundling.BootZipCopyAction.writeArchive(BootZipCopyAction.java:151)
        at org.springframework.boot.gradle.tasks.bundling.BootZipCopyAction.writeArchive(BootZipCopyAction.java:138)
        at org.springframework.boot.gradle.tasks.bundling.BootZipCopyAction.execute(BootZipCopyAction.java:127)
        at org.gradle.api.internal.file.copy.NormalizingCopyActionDecorator.execute(NormalizingCopyActionDecorator.java:66)
        at org.gradle.api.internal.file.copy.DuplicateHandlingCopyActionDecorator.execute(DuplicateHandlingCopyActionDecorator.java:47)
        at org.gradle.api.internal.file.copy.CopyActionExecuter.execute(CopyActionExecuter.java:47)
        at org.gradle.api.tasks.AbstractCopyTask.copy(AbstractCopyTask.java:153)
        at org.springframework.boot.gradle.tasks.bundling.BootJar.copy(BootJar.java:126)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:125)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:58)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:51)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:29)
        at org.gradle.api.internal.tasks.execution.TaskExecution$3.run(TaskExecution.java:247)
        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$2.execute(DefaultBuildOperationRunner.java:66)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:47)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:68)
        at org.gradle.api.internal.tasks.execution.TaskExecution.executeAction(TaskExecution.java:232)
        at org.gradle.api.internal.tasks.execution.TaskExecution.executeActions(TaskExecution.java:215)
        at org.gradle.api.internal.tasks.execution.TaskExecution.executeWithPreviousOutputFiles(TaskExecution.java:198)
        at org.gradle.api.internal.tasks.execution.TaskExecution.execute(TaskExecution.java:165)
        at org.gradle.internal.execution.steps.ExecuteStep.executeInternal(ExecuteStep.java:105)
        at org.gradle.internal.execution.steps.ExecuteStep.access$000(ExecuteStep.java:44)
        at org.gradle.internal.execution.steps.ExecuteStep$1.call(ExecuteStep.java:59)
        at org.gradle.internal.execution.steps.ExecuteStep$1.call(ExecuteStep.java:56)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:199)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:73)
        at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:56)
        at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:44)
        at org.gradle.internal.execution.steps.CancelExecutionStep.execute(CancelExecutionStep.java:41)
        at org.gradle.internal.execution.steps.TimeoutStep.executeWithoutTimeout(TimeoutStep.java:74)
        at org.gradle.internal.execution.steps.TimeoutStep.execute(TimeoutStep.java:55)
        at org.gradle.internal.execution.steps.PreCreateOutputParentsStep.execute(PreCreateOutputParentsStep.java:50)
        at org.gradle.internal.execution.steps.PreCreateOutputParentsStep.execute(PreCreateOutputParentsStep.java:28)
        at org.gradle.internal.execution.steps.RemovePreviousOutputsStep.execute(RemovePreviousOutputsStep.java:67)
        at org.gradle.internal.execution.steps.RemovePreviousOutputsStep.execute(RemovePreviousOutputsStep.java:37)
        at org.gradle.internal.execution.steps.BroadcastChangingOutputsStep.execute(BroadcastChangingOutputsStep.java:61)
        at org.gradle.internal.execution.steps.BroadcastChangingOutputsStep.execute(BroadcastChangingOutputsStep.java:26)
        at org.gradle.internal.execution.steps.CaptureOutputsAfterExecutionStep.execute(CaptureOutputsAfterExecutionStep.java:64)
        at org.gradle.internal.execution.steps.CaptureOutputsAfterExecutionStep.execute(CaptureOutputsAfterExecutionStep.java:42)
        at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:40)
        at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:29)
        at org.gradle.internal.execution.steps.BuildCacheStep.executeWithoutCache(BuildCacheStep.java:189)
        at org.gradle.internal.execution.steps.BuildCacheStep.lambda$execute$1(BuildCacheStep.java:75)
        at org.gradle.internal.Either$Right.fold(Either.java:175)
        at org.gradle.internal.execution.caching.CachingState.fold(CachingState.java:59)
        at org.gradle.internal.execution.steps.BuildCacheStep.execute(BuildCacheStep.java:73)
        at org.gradle.internal.execution.steps.BuildCacheStep.execute(BuildCacheStep.java:48)
        at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:44)
        at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:33)
        at org.gradle.internal.execution.steps.SkipUpToDateStep.executeBecause(SkipUpToDateStep.java:76)
        at org.gradle.internal.execution.steps.SkipUpToDateStep.lambda$execute$2(SkipUpToDateStep.java:54)
        at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:54)
        at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:36)
        at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:65)
        at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:36)
        at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:37)
        at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:27)
        at org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:76)
        at org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:37)
        at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:106)
        at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:55)
        at org.gradle.internal.execution.steps.AbstractCaptureStateBeforeExecutionStep.execute(AbstractCaptureStateBeforeExecutionStep.java:64)
        at org.gradle.internal.execution.steps.AbstractCaptureStateBeforeExecutionStep.execute(AbstractCaptureStateBeforeExecutionStep.java:43)
        at org.gradle.internal.execution.steps.AbstractSkipEmptyWorkStep.executeWithNonEmptySources(AbstractSkipEmptyWorkStep.java:125)
        at org.gradle.internal.execution.steps.AbstractSkipEmptyWorkStep.execute(AbstractSkipEmptyWorkStep.java:61)
        at org.gradle.internal.execution.steps.AbstractSkipEmptyWorkStep.execute(AbstractSkipEmptyWorkStep.java:36)
        at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsStartedStep.execute(MarkSnapshottingInputsStartedStep.java:38)
        at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:36)
        at org.gradle.internal.execution.steps.LoadPreviousExecutionStateStep.execute(LoadPreviousExecutionStateStep.java:23)
        at org.gradle.internal.execution.steps.HandleStaleOutputsStep.execute(HandleStaleOutputsStep.java:75)
        at org.gradle.internal.execution.steps.HandleStaleOutputsStep.execute(HandleStaleOutputsStep.java:41)
        at org.gradle.internal.execution.steps.AssignMutableWorkspaceStep.lambda$execute$0(AssignMutableWorkspaceStep.java:35)
        at org.gradle.api.internal.tasks.execution.TaskExecution$4.withWorkspace(TaskExecution.java:292)
        at org.gradle.internal.execution.steps.AssignMutableWorkspaceStep.execute(AssignMutableWorkspaceStep.java:31)
        at org.gradle.internal.execution.steps.AssignMutableWorkspaceStep.execute(AssignMutableWorkspaceStep.java:22)
        at org.gradle.internal.execution.steps.ChoosePipelineStep.execute(ChoosePipelineStep.java:40)
        at org.gradle.internal.execution.steps.ChoosePipelineStep.execute(ChoosePipelineStep.java:23)
        at org.gradle.internal.execution.steps.ExecuteWorkBuildOperationFiringStep.lambda$execute$2(ExecuteWorkBuildOperationFiringStep.java:66)
        at org.gradle.internal.execution.steps.ExecuteWorkBuildOperationFiringStep.execute(ExecuteWorkBuildOperationFiringStep.java:66)
        at org.gradle.internal.execution.steps.ExecuteWorkBuildOperationFiringStep.execute(ExecuteWorkBuildOperationFiringStep.java:38)
        at org.gradle.internal.execution.steps.IdentityCacheStep.execute(IdentityCacheStep.java:36)
        at org.gradle.internal.execution.steps.IdentityCacheStep.execute(IdentityCacheStep.java:26)
        at org.gradle.internal.execution.steps.IdentifyStep.execute(IdentifyStep.java:47)
        at org.gradle.internal.execution.steps.IdentifyStep.execute(IdentifyStep.java:34)
        at org.gradle.internal.execution.impl.DefaultExecutionEngine$1.execute(DefaultExecutionEngine.java:61)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:145)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:134)
        at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
        at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:51)
        at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
        at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:74)
        at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:199)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:73)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
        at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:42)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:331)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:318)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.lambda$execute$0(DefaultTaskExecutionGraph.java:314)
        at org.gradle.internal.operations.CurrentBuildOperationRef.with(CurrentBuildOperationRef.java:80)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:314)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:303)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:463)
        at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:380)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
        at org.gradle.internal.concurrent.AbstractManagedExecutor$1.run(AbstractManagedExecutor.java:47)
Caused by: java.lang.IllegalAccessException: Class org.springframework.boot.gradle.tasks.bundling.BootZipCopyAction$Processor can not access a member of class org.gradle.api.internal.file.copy.NormalizingCopyActionDecorator$ParentDirectoryStub with modifiers "public"
        at org.springframework.boot.gradle.tasks.bundling.BootZipCopyAction$Processor.getPermissions(BootZipCopyAction.java:422)
        ... 148 more

Expected Behavior
Gradle 8.6-rc-1 should be able to to work with Spring Boot 2.x plugin versions.
While I understand that Spring Boot 2.x oss support ended in Nov 2023, the commercial support still until 2025 per https://endoflife.date/spring-boot
I suspect this could be a regression in Gradle that is a breaking change.
Context (optional)
No response
Steps to Reproduce
Sample build scan: https://scans.gradle.com/s/fyw35smuojp2i
Reproducible repo: https://github.com/rpalcolea/spring-boot-2x-gradle-issue

Clone repository
run ./gradlew build

Gradle version
8.6-rc-1
Build scan URL (optional)
https://scans.gradle.com/s/fyw35smuojp2i
Your Environment (optional)
Operating system | macOS 13.0 (aarch64) |
CPU cores | 12 cores |
Max Gradle workers | 12 workers |
Java runtime | Azul Zulu OpenJDK Runtime Environment 1.8.0_382-b05 |
Java VM | Azul Zulu OpenJDK 64-Bit Server VM 25.382-b05 (mixed mode) |

Tracked this down to https://github.com/spring-projects/spring-boot/issues/38718
Unfortunately, the fix is only available in Spring Boot 3.2.x and I wouldn't expect Spring Team to address 2.x as it is not maintained anymore in OSS.
However, I'm wondering if there is something that can be done from Gradle side as this could be a big blocker for everyone out there using Spring Boot 2.x that haven't been able to either upgrade to JDK17+ or Spring Boot 3.x and this could hold them from continue evolving their build tooling

Thanks for the report, we are looking into options and will make a decision before releasing 8.6 RC2.

Fixed by #27642

authors: ljacomet rpalcolea


text:
Files block in module metadata file is not (well) ordered.

Current Behavior
When doing what should be a pure-refactor change, we see a change in the order of entries in the files [ block in the .module metadata file.
Also, VariantFiles.filesOf is a Set, though the current implementation happens to be an ordered subtype.
The gradle module metadata spec says a files block is an "array".
Expected Behavior
Gradle builds are 100% reproducible and not fragile to configuration ordering.
Alternatively, the maven-publish plugin should register files in a more consistent order.
Also, all outputs of gradle builds should be ordered types, by API guarantee and not just implementation. Right now, a hashset implementation could be permitted by API but could break gradle build reproducibility.
The gradle module metadata spec and relevant gradle APIs should match better.
Context (optional)
The change where we observe this is a migration from one version of the Android Gradle Plugin to another. A lot happens under the hood here.
The code on our side where we add additional files is
libraryAndroidComponentsExtension.onVariants { variant ->
if (variant.buildType == DEFAULT_PUBLISH_CONFIG) {
...
configurations.configureEach { config ->
        if (config.name in publishingVariants) {
            // Register the sample source jar as an outgoing artifact of the publishing variant
            config.outgoing.artifact(copySampleJarTask.flatMap { it.destinationJar })

In our plugin's apply { block.
I don't think anything is happening here that might affect the order of plugin application. The other file (normal output jar) is registered by maven-publish afaik, and likely attached to the creation of these publishing configuration and variants.
Separately, from an API standpoint, reproducible builds require a non-unordered set from filesOf, and the use of a set does not coincide with the metadata spec document.
If the order here does not matter because a consuming gradle will always resolve all files in this block into an unordered set, then the simplest way to ensure reproducible builds here would be to sort the files blocks before writing them.
Related: https://github.com/gradle/gradle/issues/20011
Self-contained Reproducer Project
I think this is an API problem in gradle, evident from looking at source and spec.
If the order of files in the files blocks is supposed to matter, there is likely a separate bug on AGP. If it does not matter, files blocks should be sorted for reproducibility.
Gradle version
8.10.2
Build scan URL (optional)
No response
Your Environment (optional)
No response

The issue is in the backlog of the relevant team and is prioritized by them.

authors: abstratt owengray-google


text:
Regression: Kotlin classes from project dependency of multi module project not included in compile classpath. Worked in Gradle 5.2, stopped working in Gradle 5.3.

A multi module project with Kotlin source code, which used to work, stops working after upgrading to Gradle 5.3, because the Kotlin classes from the compile project('other-module') dependency are not found.
Expected Behavior
The Kotlin classes in the compile project('other-module') dependency should be found.
Current Behavior
The Kotlin classes in the compile project('other-module') dependency are not found:
e: /Volumes/git/projects/gradle/multi/greeter/src/main/kotlin/use/some/kkk/User.kt: (3, 8): Unresolved reference: some
e: /Volumes/git/projects/gradle/multi/greeter/src/main/kotlin/use/some/kkk/User.kt: (7, 9): Unresolved reference: Thang

Context

Works in Gradle 5.2.
Doesn't work in Gradle 5.3

Steps to Reproduce
See https://github.com/viktornordling/gradle-multimodule-kotlin-bug

Your sample uses org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.0. If I replace this dependency versions 1.3.0 with any more recent version, like 1.3.10 or above, the problem disappears.
So while I understand it is not great to having such breaking changes, there is a workaround.

Thanks @ljacomet . I'm happy to close this issue then, hopefully someone else who gets caught on this can find this issue and spend less time than I did.. 😊

I also encountered this problem, but using your way of change, still did not succeed.

Bug Project addr is https://github.com/houshuai0816/gradle-multimodule-kotlin-bug

@viktornordling @ljacomet

@houshuai0816 , in my case I can clearly show this worked with Gradle 5.2 but not with Gradle 5.3. Can you show that this once worked (with some version of Gradle)?
If not, it's probably not a regression and probably not related to this issue in any way.

authors: houshuai0816 ljacomet viktornordling


text:
Documentation: enhance IvyVariantDerivationRule to avoid project references

Context
https://docs.gradle.org/current/userguide/variant_model.html#sub:ivy-mapping-to-variants example uses injection for ObjectFactory.
When this happens, it holds a reference to the Project transitively causing memory leak

Found by @DanielThomas
This updates the docs for the Ivy rule example
Contributor Checklist

[x] Review Contribution Guidelines
[x] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[x] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[x] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[ ] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[ ] Provide unit tests (under <subproject>/src/test) to verify logic
[x] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[x] Ensure that tests pass sanity check: ./gradlew sanityCheck
[x] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Gradle Core Team Checklist

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation
[ ] Recognize contributor in release notes

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.

source: gharchive/pull-request

authors: DPUkyle bot-gradle rpalcolea


text:
Do not require Task#usesService() if service has no constraints

Issue: #30989
Reviewing cheatsheet
Before merging the PR, comments starting with

❌ ❓must be fixed
🤔 💅 should be fixed
💭 may be fixed
🎉 celebrate happy things

@bot-gradle test RFN

I've triggered the following builds:

Ready for Nightly (Trigger) (Check)

Build Scan

The following builds have passed:

Ready for Nightly (Trigger) (Check)

Build Scan

We are not going ahead with this at this time. However, we are relaxing the requirement for all cases in the short term.
See: #31419

authors: abstratt bot-gradle


text:
Add upgrade guide section for test aggregation changes

A number of breaking changes were made to the test report aggregation plugin and jacoco report aggregation plugin in https://github.com/gradle/gradle/pull/31706/files
Reviewing cheatsheet
Before merging the PR, comments starting with

❌ ❓must be fixed
🤔 💅 should be fixed
💭 may be fixed
🎉 celebrate happy things

@bot-gradle test bd

I've triggered the following builds:

Build Distributions (Pull Request Feedback)

Build Scan

The following builds have passed:

Build Distributions (Pull Request Feedback)

Build Scan

authors: bot-gradle jvandort


text:
Add debug support to TestLauncher

Here is the second round on adding debug support to the TestLauncher interface.
There are 2 remaining TODOs in this PR. The first one is one missing cross-version test; I'm working on it. The second is whether there's a better way to handle backward compatibility than the try-catch block in TestExecutionRequestAction.

@big-guy I think this PR is ready for another round of review.

@big-guy I've fixed most of your review items. Here's my list of the remaining features:

Deprecation message when custom -agentlib: argument supplied (waiting your response)
Documentation: release notes, user guide, DSL
Make use of the Property API
I'm running out of time today but I'll continue tomorrow.


text:
No support for multiple outh.gitlab block

Is your feature request related to a problem? Please describe.
No support for multiple configuration options of auth.gitlab like role_attribute_path, role_attribute_strict makes this simply useless to have.
(If applicable)If your feature request solves a bug please provide a link to the community issue
Describe the solution you'd like
Add full set of params from gitlab spec for auth.gitlab
Describe alternatives you've considered

We guess that you mean is that role_attribute_path is missing from the crd?
We are happy to get PR:s around this.
You could also try to set any values that you want in the ini file customJsonData
https://github.com/grafana-operator/grafana-operator/blob/master/documentation/api.md#grafanadatasourcespecdatasourcesindex
And don't define any of the gitlab ini configs in the CR and then I think it will do the job.

@ndemeshchenko just to clarify it a bit:
Grafana's config contains hundreds of different fields. There's no automated syncing between the grafana-operator and grafana codebase, so the fields get normally added whenever someone raises a PR or an issue. The fact that the current version of the operator does not have the requested fields only tells me that such integration is not something that many of our users have cared about so far. At the same time, it does not necessarily make the block "useless to have", because without role_attribute_path and role_attribute_strict defined, the users will be mapped to the Viewer role by grafana, which is often enough given the GitOps-like nature of the deployment.

authors: NissesSenap ndemeshchenko weisdd

repo: grafana-operator/grafana-operator


text:
Make EBPF tracer config visible

Before we expose the tracer config in Alloy (https://github.com/grafana/beyla/issues/1217), we need to make this property visible in Beyla, at an API level.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 53.03%. Comparing base (fb3b304) to head (0649f5f).

:exclamation:  There is a different number of reports uploaded between BASE (fb3b304) and HEAD (0649f5f). Click for more details.
HEAD has 2 uploads less than BASE

Flag
BASE (fb3b304)
HEAD (0649f5f)

k8s-integration-test
1
0

integration-test
1
0

Additional details and impacted files
@@             Coverage Diff             @@
##             main    #1222       +/-   ##
===========================================
- Coverage   79.78%   53.03%   -26.76%
===========================================
  Files         137      137
  Lines       11483    11483
===========================================
- Hits         9162     6090     -3072
- Misses       1781     4997     +3216
+ Partials      540      396      -144

Flag
Coverage Δ

integration-test
?

k8s-integration-test
?

unittests
53.03% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: codecov-commenter mariomac

repo: grafana/beyla


text:
add Column macro and update version

I am not sure if there is a better way to make a frontend macro when we need the results of the adhoc filter.

Perhaps a bit more context/description as to why we need this....or the issue this relates to.

https://github.com/grafana/clickhouse-datasource/pull/135#issuecomment-1161703207

repo: grafana/clickhouse-datasource


text:
page_id is not displayed when url has #

What happened?
When entering the Frontend option, selecting any registered frontend application and going to the session option, the value is not being displayed in the page_id field when the url contains #
What did you expect to happen?
I expect the page_id value to be displayed.
Example:
It looks like this:
page_id: /
page_url: https://abcd.com/#/sesion
I want:
page_id: /#/sesion     or       /sesion
page_url: https://abcd.com/#/sesion

We use Angular 16, the configuration to integrate our application with Grafana Lighthouse is:
=====================================================================
import { InternalLoggerLevel, getWebInstrumentations, initializeFaro } from '@grafana/faro-web-sdk';
import { TracingInstrumentation } from '@grafana/faro-web-tracing';
import { diag, DiagConsoleLogger, DiagLogLevel } from '@opentelemetry/api';
import { environment } from '../../../environments/environment';
export function faroInitializer(): Function {
return () => {
const env: any = environment
initializeFaro({
url: env.grafanaFaro.url,
app: env.grafanaFaro.app,
internalLoggerLevel: InternalLoggerLevel.VERBOSE,
instrumentations: [
...getWebInstrumentations({
captureConsole: true,
captureConsoleDisabledLevels: []
}),
      new TracingInstrumentation({
        resourceAttributes: {
          'app-code': 'NN',
          'app_group': "NNNN"
        },
        instrumentationOptions: {
          propagateTraceHeaderCorsUrls: []
        },

      }),
    ]
  });
  diag.setLogger(new DiagConsoleLogger(), DiagLogLevel.VERBOSE);
}

}

Hi @JeyGD - we released a new rule in Grafana Cloud that compiles hash-based routes into distinct page ids:
example.com/products/123#/my-route/568 should now become /products/*#/my-route/* - please let us know if that works out for you.

@JeyGD is this now working for you as expected so we can close the issue?

authors: JeyGD cedricziel codecapitano

repo: grafana/faro-web-sdk


text:
Cloud settings in Grafana Azure SDK

This PR aggregates all cloud-specific settings (endpoints, audiences etc.) into the Grafana Azure SDK, so they could be managed from the single place.
This would allow datasources to pull endpoints etc. from the SDK rather than hardcoding them in the datasource code.
AzureSettings structure gets two new methods:

Clouds() []AzureCloudInfo returns a list of available clouds (canonical name and display name)
GetCloud(cloudName string) (*AzureCloudSettings, error) returns settings for the given cloudName.

See https://github.com/grafana/grafana/pull/80187 for reference.

I resolved the comments.

@aangelisc I cannot merge myself for some reason

repo: grafana/grafana-azure-sdk-go


text:
Needed to maintain listing in k6 Extensions Registry

We've recently updated the requirements for maintaining an extension within the listing on our site. As such, please address the following items to maintain your listing within the registry:

needs to build with a recent version of k6; minimum v0.43 but v0.45 would be great...

For more information on these and other listing requirements, please take a look at the registry requirements.

https://github.com/grafana/xk6-amqp/pull/30

authors: javaducky kempsterc


text:
Invalidating all sizes of cached images

We had trouble seeing avatars updating properly when they're changed, because they weren't being invalidated from the cache.  This change invalidates all possible sizes of a cached image if the size isn't specified on the cache invalidate call.

Closing due to inactivity

repo: grantmcconnaughey/django-avatar

license_source: bigquery


text:
[BUG] holtWintersConfidenceBands throws for small enough season_length

Describe the bug
If season_length is < 2 after this calculation
https://github.com/graphite-project/graphite-web/blob/e7d08e6af65c47c5a5dd6421c5b352d7ac3d381c/webapp/graphite/render/functions.py#L4007
then one of these two lines will throw IndexError: list index out of range during the first iteration of the for loop:
https://github.com/graphite-project/graphite-web/blob/e7d08e6af65c47c5a5dd6421c5b352d7ac3d381c/webapp/graphite/render/functions.py#L4057-L4058
This can happen if the series.step is big enough or the seasonality small enough.
The problem comes from the fact that 2 values from the last season are needed on each iteration. So if season_length < 2, this is impossible.
To Reproduce
Run the docker image:
docker run -d  --name graphite  --restart=always  -p 80:80  -p 2003-2004:2003-2004  -p 2023-2024:2023-2024  -p 8125:8125/udp  -p 8126:8126  graphiteapp/graphite-statsd

Query with the following
curl  -G --data-urlencode "format=json" --data-urlencode "target=holtWintersConfidenceBands(summarize(randomWalk('foo'), '30d'), 3)" -H "Accept: application/json"  http://localhost:80/render

Graphite encountered an unexpected error while handling your request.

Please contact your site administrator if the problem persists.

Traceback (most recent call last):
  File "/opt/graphite/lib/python3.9/site-packages/django/core/handlers/exception.py", line 34, in inner
    response = get_response(request)
  File "/opt/graphite/lib/python3.9/site-packages/django/core/handlers/base.py", line 115, in _get_response
    response = self.process_exception_by_middleware(e, request)
  File "/opt/graphite/lib/python3.9/site-packages/django/core/handlers/base.py", line 113, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/opt/graphite/webapp/graphite/errors.py", line 101, in new_f
    return f(*args, **kwargs)
  File "/opt/graphite/webapp/graphite/render/views.py", line 130, in renderView
    data.extend(evaluateTarget(requestContext, targets))
  File "/opt/graphite/webapp/graphite/render/evaluator.py", line 34, in evaluateTarget
    result = evaluateTokens(requestContext, target)
  File "/opt/graphite/webapp/graphite/render/evaluator.py", line 67, in evaluateTokens
    return evaluateTokens(requestContext, tokens.expression, replacements)
  File "/opt/graphite/webapp/graphite/render/evaluator.py", line 120, in evaluateTokens
    return func(requestContext, *args, **kwargs)
  File "/opt/graphite/webapp/graphite/render/functions.py", line 4148, in holtWintersConfidenceBands
    analysis = holtWintersAnalysis(series, seasonality)
  File "/opt/graphite/webapp/graphite/render/functions.py", line 4057, in holtWintersAnalysis
    last_seasonal = getLastSeasonal(i)
  File "/opt/graphite/webapp/graphite/render/functions.py", line 4019, in getLastSeasonal
    return seasonals[j]
IndexError: list index out of range

Note: the point of the summarize(..,'30d')` here is to make the step of the series big enough for the exception to happen.
Expected behavior
I am not familiar enough with the holtWinters method to propose an expected behavior. But clamping the season_length so it's not lower than 2 fixes the exception
Environment:

Graphite-web version 1.2.0 (docker image)

Hi @npazosmendez
Looks legit, thanks!

Sould be fixed in #2787

authors: deniszh npazosmendez

repo: graphite-project/graphite-web


text:
Improve GraphcastMessage typing and signing

Problem statement

Grapchast message takes optional radio payload because of prost::Message implication to take an Optional field; this doesn't make sense since the point of Graphcast message is to send radio payload message. Investigate ways to provide payload without making it optional
Graphcast agent wallet signs over radio payload field inside Graphcast message. Security can be improved by signing over Graphcast message fields such as block hash, block number, nonce, identifier, graph_account, etc.

Expectation proposal

Require payload in GraphcastMessage
Update GraphcastMessage structure and signed data types

Current Graphcast Message is structured as below such that only payload:T is signed by the signature
pub struct GraphcastMessage<T>
where
    T: Message
        + ethers::types::transaction::eip712::Eip712
        + Default
        + Clone
        + 'static
        + async_graphql::OutputType,
{
    pub identifier: String,                        // not necessary as included in payload: T
    pub payload: T,                                  // EIP712 signed
    pub nonce: i64,                                 // not EIP712 signed, secure Graphcast level
    pub network: String,                         // not EIP712 signed, optional for radios
    pub block_number: u64,                  // not EIP712 signed, secure Graphcast level, may not be available for message sender
    pub block_hash: String,                   // not EIP712 signed, secure Graphcast level, may not be available for message sender
    pub graph_account: String,             // not EIP712 signed, secure Graphcast level
    pub signature: String,                       // Signature field after signing over payload: T
}

Two options for Message layered structure
1.

Thinking about other message types such as "upgrade_version_message" from subgraph developer, fields such as "block_number", "block_hash" shouldn't be needed in the message.
The check "valid_block_hash" might be on a message type specific level to poi-radio
Move appropriate fields to Radio Payload message that're already of Eip712 types

Propose to move nonce, network, graph_account so that the fields can be securely signed .
Propose to move block_number, block_hash so that general operators of a radio operator might not need access from a block provider.
GraphcastMessage has identifier, payload, signature left

Enforce Eip712 message typing on Graphcast message,
block_number, block_hash becomes optional,
use graph_account or some constant as a placeholder on signature when building GraphcastMessage, sign over message and then replace the signature field
require extra handling at decryption as well, it must read the message fields and replace graph_account before recovering sender address from the signature

Love it. Also think the first approach is better, it's cleaner in the sense that it doesn't leave the Optional fields in the top-level message and enables more freedom when defining the Radio-specific message types.

authors: axiomatic-aardvark hopeyen

repo: graphops/graphcast-sdk


text:
refactor: drop eventuals in favor of tokio watch + timers for allocation id

Fixes #441

Pull Request Test Coverage Report for Build 11617844048
Details

59 of 61 (96.72%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 74.681%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

tap-agent/src/agent/sender_account.rs
15
16
93.75%

tap-agent/src/agent/sender_allocation.rs
24
25
96.0%

Totals

Change from base Build 11602628063:
0.1%

Covered Lines:
5333

Relevant Lines:
7141

💛  - Coveralls

authors: coveralls shiyasmohd

repo: graphprotocol/indexer-rs


text:
Added service execution instrumentation and also chained instrumentation

This will allow the gqlgw to implement ServiceExecution wrapping more easily

Looks like builds failed

authors: bbakerman tsroka

repo: graphql-java/nadel


text:
create app with db fails with sqlite

~/projects
❯ npx nexus-future
1264 ● nexus:cli:entrypoint:creating ./brief-barracuda where all subsequent work will occur
✔ Please select which package manager you would like to use › yarn
✔ Do you want to use a database? (https://prisma.io) … yes
✔ Choose a database › SQLite
s 69 ● nexus:cli:create:app:Scaffolding base project files...
   3 ● nexus:cli:create:app:Installing nexus-future@^0.8.0... (this will take around ~30 seconds)
5408 ● nexus:cli:create:app:Installing additional deps... (this will take around ~30 seconds)
 774 ● plugin:prisma:Initializing development database...
Error: The following command failed to complete successfully:

    yarn -s prisma2 migrate save --create-db --name init --experimental

It ended with this exit code:

    1

This underlying error occured (null = none occured):

    null

It received signal (null = no signal received):

    null

It output on stderr (null = not spawned in pipe mode):

    Error: Command failed with exit code 255: /Users/jasonkuhrt/projects/brief-barracuda/node_modules/prisma2/migration-engine cli --datasource file://dev.db --create_database

It output on stdout (null = not spawned in pipe mode):
    at createCommandError (/Users/jasonkuhrt/projects/brief-barracuda/node_modules/nexus-future/dist/utils/process.js:140:19)
    at ChildProcess.<anonymous> (/Users/jasonkuhrt/projects/brief-barracuda/node_modules/nexus-future/dist/utils/process.js:100:19)
    at Object.onceWrapper (events.js:313:26)
    at ChildProcess.emit (events.js:223:5)
    at ChildProcess.EventEmitter.emit (domain.js:475:20)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:272:12) {
  exitCode: 1,
  signal: null,
  stderr: 'Error: Command failed with exit code 255: /Users/jasonkuhrt/projects/brief-barracuda/node_modules/prisma2/migration-engine cli --datasource file://dev.db --create_database\n',
  stdout: ''
}

Notes

It works with postgressql

@Weakky since fixed this.

repo: graphql-nexus/nexus-future

license: MIT


text:
[lsp-server] 🐞 VS Code "go to definition" is blocked until the language server loads

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
When the GraphQL: Language Feature Support plugin is enabled in VS Code, "go to definition" will block on startup until the server has parsed all the files. This is problematic in a large monorepo with GraphQL colocated in the typescript files.
One thing that did help speed up the load time was to reduce the number of documents that the server was parsing:
  documents: ['**/*.{graphql,ts,tsx}', '!**/node_modules/**', '!**/generated/**', '!**/build/**', '!**/.*/**', '!**/dist/**'],. It was unclear from the documentation that one should do this, so I'm happy to contribute that as a suggestion in the docs if desired.
Currently after startup, it takes "go to definition" around 1 minute to be functional. Before the ignores in the documents blob, we were at 3m 30s.
Expected Behavior
I'm not familiar with VS Code extension limitations, but ideally "go to definition" would be unaffected by the load time of the extension. The various files should be parsed asynchronously before holding a lock on core IDE functionality.
An alternative could be some form of a cache, but I can imagine that's much trickier to manage across IDE sessions.
Steps To Reproduce

Open a large repository with GraphQL: Language Feature Support enabled in the IDE
Try "go to definition", it may work once or twice before the extension begins to initialize.
"go to definition" will hang and a progress bar will show up across the top of VS Code
"go to definition" will work once the Graphql Language Server has finished initial processing and moves to what I assume is incrementally updates

Environment

OS: Ventura 13.5
GraphQL: Language Feature Support = v0.8.17
VS Code: 1.80.2

Anything else?
No response

@MatthewMaclean if you notice, the same thing happens with typescript. it shows a loading... text on definition hover

Gotcha. The Typescript loading is just so much faster for us that I haven't noticed it holding a lock on the functionality. Well I'm happy to close this out if there's not much of an alternative.
I'll look for a spot in the docs to better highlight the glob with an exclusion filter option.

authors: MatthewMaclean acao

repo: graphql/graphiql


text:
feat: allow disabling validation (diagnostics)

users receive duplicate validation messages when using our LSP alongside existing validation tools like graphql-eslint
resolves #2363 and partially solves #2309

@dotansimha gotta admit, this canary github action is SO fast! I pushed an amended commit with a changeset and watched the comment change within ~1s 👁 👁

awkward commit I needed to add to pass CI, for some reason our @babel/preset-env version resolved in a way that requires us to re-add nullish coalescing. May cherry-pick into a seperate PR for cleaner git history


text:
Run PageInfo.startCursor and endCursor through resolveCursor() ?

In the case that you have a custom cursor defined via resolveCursor, I would think the generated pageInfo should also be run through it, else the pageInfo.startCursor / pageInfo.endCursor will be the default cursors, not the custom ones.
I actually ended up getting around this issue by generating my own pageInfo from scratch, since in my case connectionFromArray wasn't doing anything special for me (I'm pulling data from a DB, and don't have access to allItems), but if this was an oversight but intended behavior, I thought I'd bring it to light.
export const {connectionType: messageConnection, edgeType: MessageEdge} = connectionDefinitions({
  name: 'Message',
  nodeType: MessageType,
  resolveCursor: ({cursor, node}) => {
    return Base64.encode('createdAt:'+moment(node.get('createdAt')).unix());
  },
});

export const PostType = new GraphQLObjectType({
  name: 'Post',
  description: 'Post',
  fields: () => ({
    id: globalIdField('Post'),
    messages: {
      type: messageConnection,
      args: connectionArgs,
      resolve: async (post, args) => {
        let messages = await getMessages(post.id, args)
        let connection = connectionFromArray(messages, args);
        // connection.edges is still using the default cursors, because resolveCursor will only get called after this resolve returns
        // likewise, connection.pageInfo.startCursor and connection.pageInfo.endCursor are using the default cursors, but they won't be re-resolved using my custom resolveCursor()
        return connection;
      },
    },
  }),
  interfaces: [nodeInterface],
});

iam new write library ts-relay-cursor-paging

authors: BlooJeans productdevbook

repo: graphql/graphql-relay-js

license: mit


text:
add git hash in generated source file

Add the wrapit tool git hash in the generated source files, for reproducibility.

@t-bltg please review the changes I made to your PR.

Hum, the file version.cmake seems to be missing in https://github.com/grasph/wrapit/pull/25/commits/e8e9ca9ef8c8eb4d65cd0ebf9528b908616a03fe, so it fails to build.

I've usde target_sources instead, since you cannot use a missing source in add_executable (version.cpp), which would be created by the version target.

The error was still there with your fix. I don't how I missed it before. It works for me with the trick of 6785d2d  commit.

Odd, this worked on my laptop, and I extra checked by removing CMAKE_BINARY_DIR before building wrapit.
Anyway, I can confirm that it now builds as expected.

Thanks !

authors: grasph t-bltg

repo: grasph/wrapit


text:
Game scores source now includes Women's games interlaced with Men's

https://www.sports-reference.com/cbb/boxscores now includes both Men's and Women's games on its boxscores page. It is unclear when they started this process. We will need to:

Go back into the data to fix any women's games accidentally recorded
Update scraping methodology to account for this change in data collection and daily predictions

While troubleshooting solutions, SportReference blocked my ability to query the site. Hopefully this is just temporary.
Attempting a temporary solution with this commit, but I'm unable to test if it works right now:
https://github.com/grdavis/college-basketball-elo/commit/b8a5648ae94e3ed805d99115e8c70a36f693ac15

New solution pushed https://github.com/grdavis/college-basketball-elo/commit/65c2f660a88b56001dedf5eca6180a143bdfdcf4
The drawback to this solution is now every game defaults to non-neutral. Will need to monitor in a few weeks once neutral site games get going to see if there is a way to start capturing that information again. But in this part of the season it is not critical

repo: grdavis/college-basketball-elo


text:
Kslhacks/state refactor

State reference and naming are now consistent across example bot.ts and all stages.
NLP logic will be defined by user, intake is now responsible for processing nlp. This allows all reference to wolfState and pendingWolfState to be contained in the stages only.

closes #10

Adding comments to action as well as renaming dir and filename actions -> action

repo: great-lakes/botbuilder-wolf


text:
Easy workflow

The easiest workflow should allow the following statement to generate AliTV JSON files:
# download a number of fasta and/or genebank files
./alitv.pl *
This should create a set of AliTV JSON input files and a yml file, for later modification and replay.

The yml file need to be created first, afterwards the normal JSON generation can be executed.

repo: greatfireball/AliTV-perl-interface


text:
Facedancer v3.0

This PR replaces the old Facedancer implementation with facedancer.future.

Would it be possible to port the facedancer-keyboard-interactive.py legacy example to the new framework? It took me some time to implement it, quite a pity seeing it being just removed.

The legacy keyboard examples based on USBKeyboard have been deprecated in favour of the rubber-ducky example which uses a USBKeyboardDevice implementation based on Facedancer 3.0's new HID Class definitions.
I've got a bit much on my plate for the next few months to tackle this myself, but if you are interested a good place to start would be to look at:

https://github.com/antoinevg/Facedancer/blob/antoinevg/facedancer-v3/examples/rubber-ducky.py
https://github.com/antoinevg/Facedancer/blob/antoinevg/facedancer-v3/facedancer/devices/keyboard.py
https://github.com/antoinevg/Facedancer/tree/antoinevg/facedancer-v3/facedancer/classes/hid

authors: antoinevg xairy

repo: greatscottgadgets/Facedancer


text:
Add path highlighting in graph view

Add some sort of glow or highlight for a particular path (or multiple paths?) in the graph view.
Probably will need another column of checkboxes in the paths table to allow user to show the path highlight. We could do it via mouse hover but 1) that wont work on mobile and 2) it might be hard sometimes for the user to see both the full paths table and the full graph container on screen at once.

I think it makes sense to have a way to toggle highlighting on or off for a path. However, it may also be nice to have highlight-on-hover enabled, such that the link between the path table and graph visualization is immediately clear.

Implemented in dev branch. Will be incorporated by future PR.

closed by #44 and #41

such that the link between the path table and graph visualization is immediately clear.

I think there's probably a better way to accomplish this. Not sure what it is yet though. Maybe a better page layout, or helper/explanation text at the top describing the "workflow" of hetmech (when we integrate it into het.io).

authors: dhimmel vincerubinetti

repo: greenelab/hetmech-frontend


text:
@i18n("hello"+".world") does not work

Hello,
@i18n("hello.world") renders hello.world message
@i18n("hello"+".world") does not
Not sure why.
I love rythm (big fan of .net razor in fact), even if it is a little buggy from place to place, it still is the best templating framework I found yet.
I've updated integration into [ninjaframework] (https://github.com/momiji/ninja-rythm/tree/first-init), and it pleases us with this configuration.
Maybe you should have a look to [rocker] (https://github.com/fizzed/rocker) someday, they also have some interesting things...
Regards

@i18n(...) is a directive, it doesn't support runtime concatenation at the moment. I will fix this issue in the next version. Before the new version come out, instead of using @i18n("hello" + ".world"), use the runtime function call: @__i18n("hello" + ".world").


text:
xstyled vs styled-system

💬 Questions and Help
I adopted xstyled into a project without fully understanding its benefits. Now I'd like to get a better understanding so I can make informed decisions going forward.
There are a few places in the documentation that refer to the differences between xstyled and styled-system:
https://xstyled.dev/docs/motivation/

xstyled is faster
xstyled can evolve separately from styled-*

https://xstyled.dev/docs/getting-started/

xstyled css can refer to theme values directly in css syntax

https://xstyled.dev/docs/grid-system/

xstyled includes some help for making grids, which styled-system does not (but similar can be found in the styled-system ecosystem such as reflexbox)

https://xstyled.dev/docs/color-modes/

xstyled has built-in support for dark mode, although it appears that styled-system may have gained this abillity now as well

At this point, it seems that the super-powered css function is the main selling point of xstyled. Is that correct, or are there other significant benefits that I'm missing?

Yeah it is correct! I think the website should reflect it. For me xstyled is kind of 'styled-components' with super powers.

Is there still a big performance difference now that styled-system added some of the changes you proposed?

Piggybacking on this issue, I'd like to know whether xstyled is here to stay? After implementing a design system on top of styled-system and seeing that Brent Jackson seems to have taken a break from all his libraries and the Spectrum community is a wasteland, I found xstyled and it seems to be a better fit for my use-case anyways (except for the not yet fully there Typescript support).
Then I found out that your very own smooth-ui (based on xstyled) has been abandoned as well.
This all makes me wonder what the hell is going on in the design systems library space. 😄 I'd really like to migrate to xstyled, but it seems to be a tough call…

Hello @soulchild, I am actually working on v2 of xstyled. The core of xstyled is very solid and it is used in production on big projects. So it has proven itself. I am actually working on a better dev experience and documentation.
Stay tuned, but you will not be disappointed!

xstyled v2 is lot of more complete than styled-system, the comparison is no longer relevant.

xstyled v2 is lot of more complete than styled-system, the comparison is no longer relevant.

authors: agriffis gregberge hc-codersatlas soulchild

repo: gregberge/xstyled


text:
Not working on react 16

currently not hiding on react 16, when cancel / confirm button clicked
<Confirm                                                               onConfirm={confirmDelete}                                                               body="Are you sure you want delete this Item?"                                                               confirmText="Confirm Removal"                                                               visible={false}                                                               title="Confirm Action">                                                               <Button bsStyle="danger"><FontAwesome name="trash"}/> Delete</Button> </Confirm>

Should be fixed now in version 5.0.0

authors: gregthebusker monski

repo: gregthebusker/react-confirm-bootstrap


text:
[Question] Loading screen on page load / before app is rendered

Lovers of Gridsome 👋,
No bug - just a buggy developer. However, I could really use some help:
How would you go about creating a loading screen that fires on the page load? A screen that's visible before Gridsome renders all of the vue instances, routing etc. Should be the absolute first thing visible.
Any thoughts/tips? 🙂

You can always create an App.vue or index.html and add your transitions inline for this purpose. An example of index.html usage is on the Official Gridsome site here. The documentation is available here.

Thanks a lot @Microflash !

authors: Microflash nicolaisimonsen

repo: gridsome/gridsome


text:
[Question] Handling global data updated by child components

I'm not sure if this is a bug or something I'm doing wrong, hence why I'm phrasing this as a question for now:
In a project I'm working on I have a custom App.vue with a global Navigation component that changes to light/dark based on a property set by the page rendered in <router-view>, or by the value set by a previous page.
I'm achieving this by having a property in the data-object of the root Vue instance and setting that value in the component's created hook via $root — the same can be achieved with Vuex, I have tried that, but it doesn't change the outcome. (And using vuex for something tiny like this is overkill imo.)
Everything works flawlessly during development, however during build all the values get messed up, i.e a page that should have a dark navigation ends up having a light one and vice versa. Could this be due to a race condition during build? Or what else might be causing that?
I can't be sure, but I feel like the values reaching App.vue are "lagging" behind, i.e if a "light" page is rendered followed by a "dark" one followed by another "light" one, the outcome might be "light, light, dark" instead of "light, dark, light".
I can work around the issue somewhat by accessing $page from the App.vue component, however that seems rather hacky since it will be undefined on routes that don't have a page-query—which means I can't reuse the previous route's value on those.
I'm sorry if this question seems a little jumbled, I've been wrecking my brain over this for the past four hours. I'll be happy to clarify if there's a need.
Thank you for your time.

Using Vue.observable might be a good solution for you. Can see an example of it here (just in vue not gridsome specific):
https://vuedose.tips/tips/creating-a-store-without-vuex-in-vue-js-2-6/

Thank you for your reply, but the problem isn't that the variables aren't reactive—as I've said, everything works fine in development. It's once I build the site and the static HTML is generated that things fall apart. The values in the generated HTML do not match what they would be if it was a normal Vue app. Once the application fully hydrates, the issue fixes itself.
Whether I use a data property on the root instance or Vuex doesn't make a difference, so I doubt using an Observable would fix the issue.

I had this issue, too.
Here my ThemeSwitcher component:
https://github.com/noxify/gridsome-starter-casper-v3/blob/master/src/components/ThemeSwitcher.vue#L36
By clicking the icon to change from light to dark, the new value will be passed to the the parent component:
https://github.com/noxify/gridsome-starter-casper-v3/blob/master/src/layouts/partials/Navbar.vue#L38
From the navbar component, the new value will be passed to the Default layout:
https://github.com/noxify/gridsome-starter-casper-v3/blob/master/src/layouts/Default.vue
In the Default layout, i set the theme and pass it back to the child components.
Hope that helps.

Thank you for your reply! I also considered using events to switch the colors, however I found it not to scale very well, since they might need to be passed up quite a long chain. Awesome Starter by the way. :wink:
I feel like I need to add a little more detail about my question though, since I’m not dealing with a user-initiated change here.
I have created this repo with a minimal example that you can clone and observe the behaviour for yourselves. If you follow the instructions in the README, you should end up with a built page which has a dark header upon initial load, despite the data for home specifying "dark": false. Navigate to another page and back and the issue will have fixed itself, but the generated Markup for index.html contains a "dark" class even though it shouldn’t.

Hi @amxmln ,
sorry for the delay - but i think I found a way to solve your problem (w/o an alternative way :D )
I created a PR with this changes: https://github.com/amxmln/gridsome-global-data-example/pull/1
Hope this what you want to do :)
I tested it with gridsome develop and also with gridsome build.
Both ways are working as expected ( for me ;) )

Hi @noxify , no worries, we’re all busy people. :wink:
Thanks for your PR, I had a look through the changes and basically your workaround involves shifting the data-access from the App.vue into a Default.vue, right? I’ve noticed you included a darkMode prop, you’re not using that, however, since the layout still determines its dark state by accessing $root.pageDark.
I find it very curious that this setup works, while accessing the property directly from the App.vue does not. :thinking: Perhaps there is a race condition of sorts?
In my project, I’m working around the issue by accessing $page directly from the App.vue during build via process.isServer since I’m not using Layouts there, that works as well, but I feel like it’s a hack more than anything else.

Hi @amxmln,

your workaround involves shifting the data-access from the App.vue into a Default.vue, right?
yes

I’ve noticed you included a darkMode prop, you’re not using that, however, since the layout still determines its dark state by accessing $root.pageDark.
I have tested some stuff - my first idea was to use property to set the mode via <Layout :darkMode="..>

but then i rethinked my first idea and moved to $root.darkMode because I'm wasn't sure if you're using this somewhere else ( = reducing the refactoring if there is one )

I find it very curious that this setup works, while accessing the property directly from the App.vue does not. 🤔 Perhaps there is a race condition of sorts?

Possible - tbh, i have not enough experience with Vue - sorry.

since I’m not using Layouts there, that works as well
What the reason to not use Layouts?

but I feel like it’s a hack more than anything else.
Make it work, then make it better ;)

To this issue: Is it solved?

Hi @noxify,
thank you for your reply. If this is caused by a race condition, or some form of concurrence during the build process, I think the issue is with Gridsome, not Vue, and thus a bug that should be addressed by this project.
I wasn’t sure if this was caused by something I did wrong, so I didn’t label it as a bug when I created the issue, but I think it might be one. Either I create a new issue about this, or rename this one and update the description. What’s the better course of action in this case? :thinking:

authors: amxmln noxify sanscheese


text:
Managing tabs or table links

In grist certain tables like join tables are not required for the user to see at all. However if we hide the join table or make it inaccessible to end users, all the tables linked to the join tables will be in accessible to the users. Is there any way to avoid this and simply make join table hidden (not inaccessible)? That would be very nice. Is we can also add custom tab features in grist (which should be html section somewhere up in workspace with simple button and hyperlink features), it would make grist truly a full blown application.

Do you mean situations like this template https://templates.getgrist.com/doc/afterschool-program/p/6, where one can select a Class to see all Enrollments in it (which are a join table), but you'd like to see the Students in each class instead?
It is actually possible! Here is an example: https://templates.getgrist.com/doc/afterschool-program~j8YhqLShYaTShyYtUqun8A~80/p/6. It requires adding a ReferenceList:Students column to the Classes table, whose value can be constructed with a formula like this:
Enrollments.lookupRecords(Class=rec).Student

(I left the column visible in the example, but you can hide it and it'll still work.) It allows linking a widget listing Students directly to the table of Classes. The Enrollments join table is still necessary, but is not present in the view, and does its job via the lookup formula.

Thank you for your reply. What I meant to say is very simple actually. Enrollment is a join table. However most the work happens in the classview and  my team members need not see the "Enrollment" table or "Class" table. So if there was a simple way to hide these table it would be great. Lets take example of  google spreadsheet. There if I want to hide a sheet i can just right click and click on hide button. Its data is accessible to all from any other sheet but visually the hidden sheet is not visible.
Also I am a layman and use grist cloud platform. By the way I like Grist a lot. However I dont want to write any codes for simple things. I dont have so much time to learn programming as I am already past that age. I just want to hide what i dont want to see in grist, Do color coding of the menu items. If the menu or tab link could be created somewhere on the top as per our choice (ability to simple hyperlinking the html buttons would be great).
What I observed is grist has simplified the complex processes but the simple things which are needed to small business owners to make it user friendly are missing. IMO.

but you'd like to see the Students in each class instead?

Not really. I just want the feature to hide and unhide tables without making them inaccessible. Right click and hide. And if needed go somewhere and unhide. Analogous feature in google spreadsheet would be hiding and unhiding the sheet.
This feature is needed to make grist simple and less complicated. Make only those links and features visible which are needed.

There have been recent changes which are close to what you want, which became possible due to Raw Data Pages.
So now you can safely remove any page without losing access to the data in it. All the data is still accessible in the "Raw Data" section that's always available under Tools in the left panel.

It's not quite what you are asking for (since there is no way to "unhide", only re-add), but it might help. The Class Enrollment template could be simplified using this. Here is an example: Class Enrollment. Note how the only pages are the ones intended as the most useful ones. (Also e.g. the Students page has a filter button to easily filter by class.) But then all data, including Enrollments, is still available in Raw Data, if ever needed: Enrollment Raw Data. (Most templates were created before the Raw Data feature was available, and haven't been tweaked yet to take advantage of it.)
Does this help at all?

Thank you very much. Yes "Raw Data" is close to what is needed. However my requirement is very simple and more related to visibility / invisibility of the tabs. Hopefully one click visibility and invisibility will be developed in grist. It could be made by locking the expansion and collapse feature. Only admin should be expand the collapsed tabs. For example under classview we have several tables. All the tables I want to hide, i could bring there and then collapse and lock. I as a admin can uncollapse these but my team members who dont need to see these tables cannot un-collapse or expand these.

authors: anupamtandon dsagal

repo: gristlabs/grist-core


text:
CLEWS-24615: API client errors handling

Description

These are the errors that are handled by the added exception 400, 401, 404, 500
The current implementation returns a response as shown below 👇

API call failed with the error message:
Giving up on https://api.gro-intelligence.com/sample_unit/ after 1 tries:

Seeing as it is difficult to parse the message ☝ the error message will include the following info in the response body

Status Code
Retry Count
Response
Message
Url

Hey @waracci FYI I just added some message parsing on the error responses to something I think is a bit more useful:
Test script:
try:
    client.get_data_points(region_id=19)
except Exception as e:
    print('e {}'.format(e))
    print('response {}'.format(e.response))
    print('retry_count {}'.format(e.retry_count))
    print('url {}'.format(e.url))
    print('status_code {}'.format(e.status_code))
    print('message {}'.format(e.message))

Output changes from:
response <Response [400]>
retry_count 1
url https://api.gro-intelligence.com/v2/data
status_code 400
message Giving up on https://api.gro-intelligence.com/v2/data after 1 tries: <Response [400]>.

to:
response <Response [400]>
retry_count 1
url https://api.gro-intelligence.com/v2/data
status_code 400
message Bad Request: child "metricId" fails because ["metricId" is required]

Also I added params to the error object. Use case would be if you're looping through many different requests to the same endpoint and catching the errors as you go, you can access the params property to retroactively see which inputs resulted in the error.

authors: itsjohnward waracci

repo: gro-intelligence/api-client


text:
Countless errors related to grommet-icons

I just created new Grommet app with grommet-cli. Now I'm doing npm start and I'm getting this:
ERROR in ./node_modules/grommet/es6/components/hocs.js
Module not found: Error: Can't resolve 'grommet-icons/es6/contexts/ThemeContext' in '/Users/*****/shtrafovnet/node_modules/grommet/es6/components'
 @ ./node_modules/grommet/es6/components/hocs.js 15:0-91 240:31-47
 @ ./node_modules/grommet/es6/components/AccordionPanel/AccordionPanel.js
 @ ./node_modules/grommet/es6/components/AccordionPanel/index.js
 @ ./node_modules/grommet/es6/components/index.js
 @ ./node_modules/grommet/es6/index.js
 @ ./src/App.js
 @ ./src/index.js
 @ multi (webpack)-dev-server/client?http://localhost:8080 ./src/index.js

ERROR in ./node_modules/grommet/es6/components/Box/Box.js
Module not found: Error: Can't resolve 'grommet-icons/es6/contexts/ThemeContext' in '/Users/*****/node_modules/grommet/es6/components/Box'
 @ ./node_modules/grommet/es6/components/Box/Box.js 13:0-91 147:38-54
 @ ./node_modules/grommet/es6/components/Box/index.js
 @ ./node_modules/grommet/es6/components/index.js
 @ ./node_modules/grommet/es6/index.js
 @ ./src/App.js
 @ ./src/index.js
 @ multi (webpack)-dev-server/client?http://localhost:8080 ./src/index.js

Countless of errors like these. I just can't get started, again! Page renders tho, but it has no icons, just blank rectangles that change their color on hover.

@alansouzati wow, really? That's amazing! I just can't get started with create-react-app with Grommet added. I tried adding it manually just that way, but it appears to be unstyled somehow.
Text is in Work Sans though, but everything else is unstyled.
Can you please help me with that? I'm starting a new shiny project and I want it to have the both latest create-react-app and Grommet.
Or if you can't because of some reason, can I use grommet-react-app in production yet?

It seems that you are using Grommet v1 in a v2 platform. make sure your package.json is using 2.0.0-rc, the latest official version is still v1.
grommet-react-app is an ejected create-react-app for Grommet v1. I would not recommend starting with v1 at this point.
v2.0.0-rc is a release candidate, and we are planning to officially release grommet v2 soon.

Okay, I’m not going to use cli anymore. How do I get styles to work in create-react-app v2 and Grommet v2?

it comes built in, you dont have to worry about it.

Yep! It seems like I messed it up somehow. How I did all this from scratch and it works perfectly.
Thanks a lot! The issue is solved.

authors: alansouzati uyouthe

repo: grommet/grommet-cli


text:
Update Search.js fix .flat() function undefined error

Fixes this error in browser that don't support .flat():

Source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/flat#reduce_and_concat

Thanks for your contribution!

authors: Jumblemuddle ericsoderberghp

repo: grommet/grommet-site


text:
Error on direct installation in IRIS for Windows (x86-64) 2022.1 version zpm 0.3.4

install readonly-interoperability -v
Module readonly-interoperability was downloaded from registry (https://pm.community.intersystems.com)
Loading from C:\InterSystems\IRIS22\mgr.modules\READONLY-INTEROPERABILITY\readonly-interoperability\1.0.2\
Загрузка началась в 08/30/2022 08:48:48
Загрузка файла C:\InterSystems\IRIS22\mgr.modules\READONLY-INTEROPERABILITY\readonly-interoperability\1.0.2\module.xml как xml
Импортированный документ: readonly-interoperability.ZPM
Загрузка успешно завершена.
Skipping preload - directory does not exist.
Загрузка началась в 08/30/2022 08:48:48
Загрузка файла C:\InterSystems\IRIS22\mgr.modules\READONLY-INTEROPERABILITY\readonly-interoperability\1.0.2\module.xml как xml
Импортированный документ: readonly-interoperability.ZPM
Загрузка успешно завершена.
Loading readonly-interoperability in process 11052
[readonly-interoperability]     Reload START (C:\InterSystems\IRIS22\mgr.modules\READONLY-INTEROPERABILITY\readonly-interoperability\1.0.2)
Skipping preload - directory does not exist.
Загрузка директории началась в 08/30/2022 08:48:48 '*'
Загрузка файла C:\InterSystems\IRIS22\mgr.modules\READONLY-INTEROPERABILITY\readonly-interoperability\1.0.2\src\ReadOnly\Setup.cls как udl
Загрузка успешно завершена.
[readonly-interoperability]     Reload SUCCESS
[readonly-interoperability]     Module object refreshed.
[readonly-interoperability]     Validate START
[readonly-interoperability]     Validate SUCCESS
[readonly-interoperability]     Compile START
Компиляция началась в 08/30/2022 08:48:48 с квалификаторами 'd-lck'
Компиляция класса: ReadOnly.Setup
Компиляция программы: ReadOnly.Setup.1
Ошибка #5002: Ошибка: removeGenerated+58^%occCompile *ReadOnly.Setup
Найдено 3 ошибок при компиляции в 2.314s.
[readonly-interoperability]     Compile FAILURE
ERROR! WQM item modified $tlevel, before:1 after:0 for 'S %sc=$$createprojection^%occCompile(.%p1,.%p2,.%p3)' $ze='%Save+9^Security.Roles.1'.

the issue may be fix in version 1.0.3.
it was an error because roles and resources change in IRIS 2022, %Ens_MessageResubmit and %Ens_SequenceManager doesnt seem to exist anymore.
Can you confirm that the problem is solved for you ?

Yes, problem solved, thanks.

repo: grongierisc/iris-readonly-interop


text:
Select all and generate Excel file from queries in Admin

I would like to be able to (bulk) select all and generate Excel files as a zip from the Admin interface. Just like it is possible now for CSV files. See attachment.

As you can see I have already tried to play around with it by copying and editing the Admin CSV generate functions. However this results in a malformed zip file. Always only one correct xlsx file the rest is malformed. I think this is because xslx is a zip file itself? And it is this particular line in actions.py (which I copied from the existing function):
zip_file.writestr('%s.csv' % r.title, CSVExporter(r).get_output() or "Error!")
I just started with Django this Monday, so I am a bit stuck here.
For my intended workflow I have a whole bunch of queries whose output someone else (with no SQL knowledge) can use to email suppliers certain figures. The Admin seems like the most logical place, however from the frontend (select all -> export to Excel) would also work.

I created a pull request for this issue: #308
This pull requests also fixes what seems like a general problem with current CSV exports. (Thanks to @sjm-steffann for pointing me in de right direction.)

repo: groveco/django-sql-explorer


text:
Camera wiki update

Hey there ;)
The page about camera aspect ratio needs an update sine gd3 is now modular (to something like this):
g3d.camera.aspectRatio = love.graphics.getWidth()/love.graphics.getHeight()
g3d.camera.updateProjectionMatrix()

done :)

Either this got reverted somehow or the same update is missing on https://github.com/groverburger/g3d/wiki/Everything-is-stretched-when-I-change-the-window-size

authors: 4aiman TangentFoxy groverburger


text:
接入无埋点的SDK后报以下错误

@zhujianguo 能了解一下你是怎么集成的吗，用的是什么版本，包括 RN、Android SDK、RN SDK，谢谢。

@zhujianguo 能了解一下你是怎么集成的吗，用的是什么版本，包括 RN、Android SDK、RN SDK，谢谢。

我按着官网的步骤集成，但是在集成无埋点SDK之前我集成过埋点SDK，但是相关的我有做删除
各版本如下：

@zhujianguo postinstall 的 hook.js 跑了吗，可以尝试把 node_modules 清掉试试看。

@zhujianguo postinstall 的 hook.js 跑了吗，可以尝试把 node_modules 清掉试试看。

有的，通过自动运行脚本和手动运行都试过，你的能成功没这些问题吗？

根据报错信息显示是RN的Package没有导入成功。

@zhujianguo 确认下有这一步骤,

import com.growingio.android.plugin.rn.GrowingIOPackage; 这个好像引用不到了 ? 文档上也没有... 最新的路径是 ? @sishen

@iShawnWang 这个报名没有更改的, 出现引用找不到的原因应该是依赖没有找到， 可以参照官网:

其中红色窗口替换成RN-autotrack-2.7.5@aar

已解决 感谢 @ldkxingzhe  🎉

authors: iShawnWang ldkxingzhe sishen zhujianguo

repo: growingio/react-native-growingio


text:
VC funding column in Retro PGF Round 3

Excellent site. So useful. Thanks.
I appreciate the VC Funding column in your table. For me, it mattered, and I used it when selecting projects that I thought deserved funding. (Not that I excluded based on this, but it mattered.)
May I suggest that instead of putting "Unknown" for projects that you don't know, you use the words, "None known." Or even better yet, allow projects to explicitly tell you that they've received no VC funding, nor do they intend to. That also would have been very helpful.
Cheers.

@tjayrush, we really appreciate your feedback on our RetroPGF3 Tracker. It's really nice to hear that it was useful!
We made some changes last week and updated the column to enhance clarity.

The column now includes three distinct categories:

[USD Value Raised] - This shows the reported amount of VC funding a project has received.
"Unknown / DYOR" (Do Your Own Research) - This label is used for projects where the VC funding status is not clear or publicly available.
"No VC Funding" - This explicitly indicates projects that have not received any venture capital funding mostly from projects that have reached out to us.

We plan on continuing to track future RPGF rounds — please join us on Discord or reach out to us on Twitter/X if you have any other feedback or suggestions!
Cheers!

authors: manishiwa tjayrush

repo: growthepie/gtp-frontend


text:
Mismatched soname for libgrpc++

A symlink to libgrpc++.so.1.2.0 is created in the Makefile with the name libgrpc++.so.1. However, the soname of this library is set to libgrpc++.so.3 on the line above. This causes programs linked with libgrpc++ to fail with the error
./tests: error while loading shared libraries: libgrpc++.so.3: cannot open shared object file: No such file or directory
Creating the symlink manually fixes the problem (but I haven't checked if grpc actually works). I'm using OpenSUSE Leap 42.2, with source from the 'v1.2.0' git tag.
Note: I know very little about sonames, so this could be completely wrong. :-)

Eep, yes, thanks for the report.

FWIW, there's the same problem for libgrpc++_cronet.so.

It seems that this issue is still present in other places in the v1.3.1 Makefile. I also checked master and it's still present there, with libgrpc++.so.4 instead of libgrpc++.so.3. Can we make these use the vars so that they are guaranteed to match the soname?

There are several PRs addressing this issue (#13500, #11558, #10923, etc). Is there something fundamental blocking them from being merged? Happy to help if there's anything I can do, just seems redundant to open yet another PR.

A month ago I created a PR (#16832) to fix the same error but got no response either. Now I see that I was not the only one who tried fixing it. Looks like nobody from the maintainers cares.. All issues and PRs are assigned to @nicolasnoble and then they rot..

I just merged https://github.com/grpc/grpc/pull/16832 which should fix the problem. The good news is this we made it on time for the v1.17.x branch cut so the fix is going to be available in the v1.17.0 release (coming in about two weeks).
Sorry it took so long, we are trying our best to review things on time, but this time we really screwed up by failing to address 3 separate PRs for the same issue. I think partially the problem was coming from the fact that we are maintaining multiple build systems and each one is pretty complex (and requires a specific knowledge set that not everyone on the team has), so engineers on the team are careful in accepting build system changes (that have the potential to break lots of things and aren't always easy to test). We are thinking of how we can improve the process so things like this don't happen again.

authors: ahenriksson clemensg jtattermusch llchan nicolasnoble sesse

repo: grpc/grpc


text:
Connection backoff document needs jitter

We have a document migrated from Google docs which describes a connection retry/backoff protocol that doesn't explicitly mention adding some form of jitter to avoid a stampede.
Some form of jitter should be added explicitly to the document, and we should probably match that with the various implementations.

Can we close this?

Yes.

authors: ctiller dklempner


text:
Python flakiness on Travis test

+python2.7 -B -m grpc._adapter._future_invocation_asynchronous_event_service_test
testCancelledStreamRequestStreamResponse (main.FutureInvocationAsynchronousEventServiceTest) ... I0608 15:56:35.228180939    9225 server.c:1041] grpc_server_request_call(server=0x2146f10, call=0x7f07d5b319c0, details=0x1d4f370, initial_metadata=0x1d4f3a0, cq_bound_to_call=0x2146730, cq_for_notification=0x2146730, tag=0x1d4f360)
I0608 15:56:35.242341154    9235 call.c:1205] grpc_call_start_batch(call=0x7f07b40029d0, ops=0x7f07b40044f0, nops=1, tag=0x7f07b4004470)
I0608 15:56:35.242378645    9235 call.c:1205] ops[0]: SEND_INITIAL_METADATA
I0608 15:56:35.242494811    9235 call.c:1205] grpc_call_start_batch(call=0x7f07b40029d0, ops=0x7f07b4004b30, nops=1, tag=0x7f07b4004ab0)
I0608 15:56:35.242506704    9235 call.c:1205] ops[0]: RECV_INITIAL_METADATA ptr=0x7f07b4004a90
I0608 15:56:35.242543110    9235 call.c:1205] grpc_call_start_batch(call=0x7f07b40029d0, ops=0x7f07b4004ec0, nops=1, tag=0x7f07b4004e40)
I0608 15:56:35.242557733    9235 call.c:1205] ops[0]: RECV_STATUS_ON_CLIENT metadata=0x7f07b4004dc0 status=0x7f07b4004de0 details=0x7f07b4004e00
I0608 15:56:35.251334899    9235 completion_queue.c:223] RETURN_EVENT[0x214d390]: OP_COMPLETE: tag:0x7f07b4004470 ERROR
I0608 15:56:35.251410617    9235 completion_queue.c:223] RETURN_EVENT[0x214d390]: OP_COMPLETE: tag:0x7f07b4004e40 OK
I0608 15:56:35.251588829    9235 completion_queue.c:223] RETURN_EVENT[0x214d390]: OP_COMPLETE: tag:0x7f07b4004ab0 OK
I0608 15:56:35.255335552    9232 completion_queue.c:223] RETURN_EVENT[0x2146730]: OP_COMPLETE: tag:0x1d4f360 ERROR
I0608 15:56:35.306698085    9232 completion_queue.c:223] RETURN_EVENT[0x2146730]: QUEUE_SHUTDOWN
ok
testCancelledStreamRequestUnaryResponse (main.FutureInvocationAsynchronousEventServiceTest) ... I0608 15:56:35.307643958    9225 server.c:1041] grpc_server_request_call(server=0x21fe4a0, call=0x7f07d5b31d00, details=0x1d4f370, initial_metadata=0x1d4f3a0, cq_bound_to_call=0x21fe070, cq_for_notification=0x21fe070, tag=0x1d4f360)
I0608 15:56:35.330820307    9241 call.c:1205] grpc_call_start_batch(call=0x7f07a4001d60, ops=0x7f07a4002c90, nops=1, tag=0x7f07a4002c10)
I0608 15:56:35.330857411    9241 call.c:1205] ops[0]: SEND_INITIAL_METADATA
I0608 15:56:35.330983301    9241 call.c:1205] grpc_call_start_batch(call=0x7f07a4001d60, ops=0x7f07a40030f0, nops=1, tag=0x7f07a4003070)
I0608 15:56:35.330993782    9241 call.c:1205] ops[0]: RECV_INITIAL_METADATA ptr=0x7f07a4003050
I0608 15:56:35.331266555    9241 call.c:1205] grpc_call_start_batch(call=0x7f07a4001d60, ops=0x7f07a40032a0, nops=1, tag=0x7f07a4003220)
I0608 15:56:35.331281789    9241 call.c:1205] ops[0]: RECV_STATUS_ON_CLIENT metadata=0x7f07a40031a0 status=0x7f07a40031c0 details=0x7f07a40031e0
I0608 15:56:35.332684813    9241 call.c:1205] grpc_call_start_batch(call=0x7f07a4001d60, ops=0x7f07a40058b0, nops=1, tag=0x7f07a4004800)
I0608 15:56:35.332701287    9241 call.c:1205] ops[0]: SEND_MESSAGE ptr=0x7f07a40057c0
I0608 15:56:35.334600813    9242 completion_queue.c:223] RETURN_EVENT[0x212fb90]: OP_COMPLETE: tag:0x7f07a4002c10 ERROR
I0608 15:56:35.334690512    9242 completion_queue.c:223] RETURN_EVENT[0x212fb90]: OP_COMPLETE: tag:0x7f07a4004800 ERROR
I0608 15:56:35.334936376    9242 completion_queue.c:223] RETURN_EVENT[0x212fb90]: OP_COMPLETE: tag:0x7f07a4003220 OK
I0608 15:56:35.335123051    9242 completion_queue.c:223] RETURN_EVENT[0x212fb90]: OP_COMPLETE: tag:0x7f07a4003070 OK
I0608 15:56:35.336372942    9238 completion_queue.c:223] RETURN_EVENT[0x21fe070]: OP_COMPLETE: tag:0x1d4f360 ERROR
I0608 15:56:35.406936990    9238 completion_queue.c:223] RETURN_EVENT[0x21fe070]: QUEUE_SHUTDOWN
ok
testCancelledUnaryRequestStreamResponse (main.FutureInvocationAsynchronousEventServiceTest) ... I0608 15:56:35.408319790    9225 server.c:1041] grpc_server_request_call(server=0x220f7b0, call=0x21b6120, details=0x1d4f370, initial_metadata=0x1d4f3a0, cq_bound_to_call=0x220f380, cq_for_notification=0x220f380, tag=0x1d4f360)
I0608 15:56:35.416170801    9247 call.c:1205] grpc_call_start_batch(call=0x7f0790001540, ops=0x7f07900026b0, nops=1, tag=0x7f0790002630)
I0608 15:56:35.416209458    9247 call.c:1205] ops[0]: SEND_INITIAL_METADATA
I0608 15:56:35.416349376    9247 call.c:1205] grpc_call_start_batch(call=0x7f0790001540, ops=0x7f0790002b10, nops=1, tag=0x7f0790002a90)
I0608 15:56:35.416358379    9247 call.c:1205] ops[0]: RECV_INITIAL_METADATA ptr=0x7f0790002a70
I0608 15:56:35.416392809    9247 call.c:1205] grpc_call_start_batch(call=0x7f0790001540, ops=0x7f0790002cc0, nops=1, tag=0x7f0790002c40)
I0608 15:56:35.416402779    9247 call.c:1205] ops[0]: RECV_STATUS_ON_CLIENT metadata=0x7f0790002bc0 status=0x7f0790002be0 details=0x7f0790002c00
I0608 15:56:35.416544336    9247 call.c:1205] grpc_call_start_batch(call=0x7f0790001540, ops=0x7f0790003590, nops=1, tag=0x7f0790002f20)
I0608 15:56:35.416553536    9247 call.c:1205] ops[0]: SEND_MESSAGE ptr=0x7f07900034a0
E0608 15:56:35.506551055    9226 tcp_client_posix.c:151] socket error: 104
E0608 15:56:35.506686736    9226 tcp_client_posix.c:151] socket error: 104
I0608 15:56:35.506998500    9245 completion_queue.c:223] RETURN_EVENT[0x2205560]: OP_COMPLETE: tag:0x7f0790002630 OK
I0608 15:56:35.507139243    9245 completion_queue.c:223] RETURN_EVENT[0x2205560]: OP_COMPLETE: tag:0x7f0790002f20 OK
I0608 15:56:35.606448714    9244 completion_queue.c:223] RETURN_EVENT[0x220f380]: OP_COMPLETE: tag:0x1d4f360 OK
E0608 15:56:35.606476267    9226 tcp_client_posix.c:148] socket error: connection refused
E0608 15:56:35.606519702    9226 tcp_client_posix.c:148] socket error: connection refused
I0608 15:56:35.606739231    9244 call.c:1205] grpc_call_start_batch(call=0x7f07cc010520, ops=0x7f07b0000ea0, nops=1, tag=0x7f07b0000e20)
I0608 15:56:35.606750873    9244 call.c:1205] ops[0]: RECV_CLOSE_ON_SERVER cancelled=0x7f07b0001110
I0608 15:56:35.606775716    9244 call.c:1205] grpc_call_start_batch(call=0x7f07cc010520, ops=0x7f07b0000d40, nops=1, tag=0x7f07b0001560)
I0608 15:56:35.606783080    9244 call.c:1205] ops[0]: SEND_INITIAL_METADATA
I0608 15:56:35.606898868    9244 call.c:1205] grpc_call_start_batch(call=0x7f07cc010520, ops=0x7f07b0001690, nops=1, tag=0x7f07b0001a80)
I0608 15:56:35.606907578    9244 call.c:1205] ops[0]: RECV_MESSAGE ptr=0x7f07b0001670
I0608 15:56:35.607352033    9245 completion_queue.c:223] RETURN_EVENT[0x2205560]: OP_COMPLETE: tag:0x7f0790002a90 OK
I0608 15:56:35.608628930    9244 server.c:1041] grpc_server_request_call(server=0x220f7b0, call=0x21b65a0, details=0x7f07b0007860, initial_metadata=0x7f07b0007890, cq_bound_to_call=0x220f380, cq_for_notification=0x220f380, tag=0x7f07b0007850)
I0608 15:56:35.608654750    9244 completion_queue.c:223] RETURN_EVENT[0x220f380]: OP_COMPLETE: tag:0x7f07b0001560 OK
I0608 15:56:35.608696167    9244 completion_queue.c:223] RETURN_EVENT[0x220f380]: OP_COMPLETE: tag:0x7f07b0001a80 OK
I0608 15:56:35.608837802    9244 call.c:1205] grpc_call_start_batch(call=0x7f07cc010520, ops=0x7f07b0000d40, nops=1, tag=0x7f07b0000d70)
I0608 15:56:35.608847038    9244 call.c:1205] ops[0]: RECV_MESSAGE ptr=0x7f07b00010f0
E0608 15:56:36.705358176    9226 tcp_client_posix.c:148] socket error: connection refused
E0608 15:56:36.705524915    9226 tcp_client_posix.c:148] socket error: connection refused
E0608 15:56:36.805359397    9226 tcp_client_posix.c:148] socket error: connection refused
E0608 15:56:36.805406778    9226 tcp_client_posix.c:148] socket error: connection refused
I0608 15:56:38.416593308    9244 completion_queue.c:223] RETURN_EVENT[0x220f380]: OP_COMPLETE: tag:0x7f07b0000d70 OK
I0608 15:56:38.417082893    9244 completion_queue.c:223] RETURN_EVENT[0x220f380]: OP_COMPLETE: tag:0x7f07b0000e20 OK
I0608 15:56:38.418058011    9245 completion_queue.c:223] RETURN_EVENT[0x2205560]: OP_COMPLETE: tag:0x7f0790002c40 OK
ERROR:root:Unexpected exception from task run in logging pool!
Traceback (most recent call last):
File "/home/travis/build/grpc/grpc/python2.7_virtual_environment/local/lib/python2.7/site-packages/grpc/framework/foundation/logging_pool.py", line 43, in _wrapping
return behavior(*args, **kwargs)
File "/home/travis/build/grpc/grpc/python2.7_virtual_environment/local/lib/python2.7/site-packages/grpc/framework/face/testing/stock_service.py", line 269, in service
_watch_future_trades(request, response_consumer, control, context.is_active)
File "/home/travis/build/grpc/grpc/python2.7_virtual_environment/local/lib/python2.7/site-packages/grpc/framework/face/testing/stock_service.py", line 80, in _watch_future_trades
raise abandonment.Abandoned()
Abandoned

More at https://s3.amazonaws.com/archive.travis-ci.org/jobs/65908815/log.txt

Closing - grpc._adapter.future_invocation_asynchronous_event_service_test is no longer in the codebase.

authors: nathanielmanistaatgoogle vjpai


text:
macos opt/tcp_client_posix_test fails

https://grpc-testing.appspot.com/job/gRPC_master/7774/config=opt,language=c,platform=macos/console
D1001 11:48:37.080791000 140735213904640 test_config.c:155] test slowdown: machine=1.000000 build=1.000000 total=1.000000
D1001 11:48:37.081419000 140735213904640 tcp_client_posix_test.c:90] test_succeeds
E1001 11:48:37.081796000 140735213904640 tcp_client_posix_test.c:274] End of first test
D1001 11:48:37.081807000 140735213904640 tcp_client_posix_test.c:142] test_fails
E1001 11:48:37.081840000 140735213904640 tcp_client_posix.c:261] connect error to 'ipv4:0.0.0.0:0': Can't assign requested address
D1001 11:48:38.089281000 140735213904640 tcp_client_posix_test.c:185] test_times_out
D1001 11:48:38.091947000 140735213904640 tcp_client_posix_test.c:237] now=1.010561550 connect_deadline=2.010502930
E1001 11:48:38.092143000 140735213904640 tcp_client_posix_test.c:76] assertion failed: g_connecting == NULL

*******************************
Caught signal 6
  no backtrace

FAILED: bins/opt/tcp_client_posix_test [ret=-6, pid=66205]

Seen again: https://grpc-testing.appspot.com/job/gRPC_master/7965/config=opt,language=c,platform=macos/console

Seen again: https://grpc-testing.appspot.com/job/gRPC_master/lastCompletedBuild/config=opt,language=c,platform=macos/console

Like a photogenic yeti: https://grpc-testing.appspot.com/job/gRPC_master/lastCompletedBuild/config=opt,language=c,platform=macos/testReport/(root)/tests/bins_opt_tcp_client_posix_test/

And again: https://grpc-testing.appspot.com/job/gRPC_master/13042/config=opt,language=c,platform=macos/testReport/junit/(root)/tests/bins_opt_tcp_client_posix_test/

Another instance: https://grpc-testing.appspot.com/job/gRPC_master/13564/config=opt,language=c,platform=macos/testReport/junit/(root)/tests/bins_opt_tcp_client_posix_test/

And again: https://grpc-testing.appspot.com/job/gRPC_master/15215/config=dbg,language=c,platform=macos/consoleText

Still happening..
https://grpc-testing.appspot.com/job/gRPC_master/15481/config=opt,language=c,platform=macos/

authors: adelez dgquintas dklempner murgatroid99 soltanmm sreecha


text:
Fix libuv core portability tests

This fixes #10879.
The main fixes are the change in tcp_server_uv.c to wait to accept incoming connections until the server starts, and the change in iomgr_uv.c to disable threading in the executor.
I also added a check to several libuv-specific iomgr functions to assert that they are running on the same thread that initialized the library, to try to avoid this in the future, or at least make it easier to debug.
There are a couple of other fixes to minor memory leaks and uses of uninitialized variables that were discovered while debugging this issue, and I disabled one test from running in the libuv tests because it starts a thread.

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

Asan and Msan actually passed, but reported failure. The Windows failure is #11860. Based on a local run, the sanity failure looks related to OWNERS, but I didn't touch that in this PR. And the interop tests almost all passed, but one timed out.