text:
Proposal for cache interface update

Actualizo comentarios y propongo cambios en la interfaz base de cache:

Desacoplo los tipos de objeto valor a interface{}. string es un tipo muy restrictivo para representaciones de valores a cachear, aunque si buscamos un punto medio podemos utilizar tambien []byte, que es convertible a string sin overhead y es el el tipo utilizado por las interfases Marshaler/Unmarshaler
Cambio el tipo de TTL por time.Duration. Esto es mas idiomático por parte del lenguaje (los consumidores van a poder configurar valores de forma mas ergonómica) y es probablemente el tipo compatible con las APIs e implementaciones que utilicemos para los mecanismos de espera y evicción internos

@lggomez totalmente de acuerdo con el cambio de type de TTL.
Con respecto al cambio de string, me parece que va a ser mejor trabajar directamente con []byte y ser un poco mas restrictivo con la utilizacion de interaface{} sino despues vamos a agregar un paso mas de casteo de interface{} a lo que elijamos castear / guardar.

@tomiok compro lo segundo, ahi actualice

Ferpecto @lggomez @tbuchaillot

authors: lggomez tbuchaillot tomiok

repo: gophers-latam/GoKey


text:
Revised

通篇认真学习了3次（较长时间段），仔细阅读和理解：
发现了一些局部的字词问题、内容失误、以及代码的排版误差。
非常感谢您们的贡献！！
通篇的修订总量稍大，故按每章分别提交，方便审阅复查。
非常荣幸能发现一些小bug供修复参考。
:)

提交前已合并来源的最新master版本。

@zhliner
非常非常感谢啊！

@zhliner ，我先合并了，那一句要改的话再提个pr就成~

留名

source: gharchive/pull-request

license_type: permissive

license_source: bigquery


text:
Investigate curl -N flag, update shlibs

Added in
https://github.com/goreleaser/godownloader/commit/f451dc90951ac6e6cd52e208b3b9006e44228957#diff-83752e6cf679642f9650d58b739cb2c3
the command for curl added the -N flag
This turns off curl buffering.   That's fine, but its not clear what problem this solved. (or maybe I missed it).
I don't see this in similar shell downloaders like:
https://github.com/golang/dep/blob/master/install.sh
Just curious on why, and to make sure it's in older curl versions.
@caarlos0 any ideas here on why it was added?
If it's needed, then I need to update client9/shlibs (no problem, just another thing to do).
n

I believe it is to reduce the risk of executing partially downloaded files, not really sure though... @flyinprogrammer ?

The -N came from here i believe: https://github.com/goreleaser/godownloader/pull/38
My commit just happened to rebuild the scripts because of the CI process? I believe?
It certainly wasn’t intentional, happy to help dig in more if it’s an issue.

ah good find @flyinprogrammer   I'll take a look... not clear why that person was having problems and why buffereing would be a problem.   Looks like it might be masking another issue.

yeah, I was like 'uh, ok then' and didn't investigate it further, my bad...

source: gharchive/issue

repo: goreleaser/godownloader

license: mit


text:
Blank Terminal on Launch

Not sure what I'm missing here.
If I launch open-wsl.exe via explorer or run command, I get nothing but a cursor and no functionality.
If I launch from cmd prompt, it works as expected. Any insights?
EDIT: Success condition is actually running open-wsl as admin.

https://github.com/goreliu/wsl-terminal/issues/36#issuecomment-329681075

authors: goreliu jbawgs

repo: goreliu/wsl-terminal


text:
Issue importing examples

Hello, I'm new to Go and I'm trying to follow the MNIST tutorial. However, when I try to import the gorgonia.org/gorgonia/examples/mnist package, it gives me the following error:
could not import gorgonia.org/gorgonia/examples/mnist (no required module provides package "gorgonia.org/gorgonia/examples/mnist")

Any suggestions? Here's the code:
package main

import (
        "fmt"
        "log"

        "gorgonia.org/gorgonia/examples/mnist"
        "gorgonia.org/tensor"
)

func main() {
        for _, typ := range []string{"test", "train"} {
                inputs, targets, err := mnist.Load(typ, "./testdata", tensor.Float64)
                if err != nil {
                        log.Fatal(err)
                }
                fmt.Println(typ+" inputs:", inputs.Shape())
                fmt.Println(typ+" data:", targets.Shape())
        }
}

I'm running go 1.17.8 and have installed Gorgonia with go get go get -u gorgonia.org/gorgonia.

please see #535 sounds the same problem.

repo: gorgonia/gorgonia

license_source: github-api


text:
subject: short description

Description: After some time of running a client MessagesSendMessage request sleeps forever. Seems like a deadlock, but I am not really sure. Some debug logs provided below
What version of gotd are you using?
github.com/gotd/td v0.99.2
Can this issue be reproduced with the latest version?
Yes
What did you do?
API.MessagesSendMessage
What did you expect to see?
A messages to be sent
What did you see instead?
MessagesSendMessage method sleeps forever
What Go version and environment are you using?
go version go1.21.1 linux/amd64
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/root/.cache/go-build'
GOENV='/root/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.1'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/app/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1773707187=/tmp/go-build -gno-record-gcc-switches'

I run MessagesSendMessage with timeout of 5 minutes, context closes
Debug logs:
{"level":"debug","ts":1713448933.1994636,"logger":"conn.mtproto","caller":"mtproto/new_encrypted_msg.go:62","msg":"Request","v":"v0.99.2","conn_id":0,"dc_id":2,"type_id":"0xf3427b8c","type_name":"ping_delay_disconnect#f3427b8c","msg_id":7359207130800523400}
{"level":"debug","ts":1713448933.1996253,"logger":"conn.mtproto.group","caller":"tdsync/cancel_group.go:48","msg":"Task stopped","v":"v0.99.2","conn_id":0,"dc_id":2,"task":"pingLoop","error":"disconnect (pong missed): write: write: write intermediate: write tcp 188.120.255.161:60372->149.154.167.51:443: write: broken pipe","errorVerbose":"disconnect (pong missed):\n    github.com/gotd/td/mtproto.(*Conn).pingLoop\n        /go/pkg/mod/github.com/gotd/td@v0.99.2/mtproto/ping.go:115\n  - write:\n    github.com/gotd/td/mtproto.(*Conn).pingDelayDisconnect\n        /go/pkg/mod/github.com/gotd/td@v0.99.2/mtproto/ping.go:71\n  - write:\n    github.com/gotd/td/transport.(*connection).Send\n        /go/pkg/mod/github.com/gotd/td@v0.99.2/transport/connection.go:48\n  - write intermediate:\n    github.com/gotd/td/proto/codec.Intermediate.Write\n        /go/pkg/mod/github.com/gotd/td@v0.99.2/proto/codec/intermediate.go:64\n  - write tcp 188.120.255.161:60372->149.154.167.51:443: write: broken pipe","elapsed":60300.000978525}
{"level":"debug","ts":1713448933.1999178,"logger":"conn.mtproto","caller":"mtproto/conn.go:172","msg":"Closing","v":"v0.99.2","conn_id":0,"dc_id":2}
{"level":"info","ts":1713448933.1999276,"logger":"conn.mtproto.rpc","caller":"rpc/engine.go:271","msg":"Close called","v":"v0.99.2","conn_id":0,"dc_id":2}
{"level":"debug","ts":1713448933.1999583,"logger":"conn.mtproto.group","caller":"tdsync/cancel_group.go:48","msg":"Task stopped","v":"v0.99.2","conn_id":0,"dc_id":2,"task":"ackLoop","error":"acl: context canceled","errorVerbose":"acl:\n    github.com/gotd/td/mtproto.(*Conn).ackLoop\n        /go/pkg/mod/github.com/gotd/td@v0.99.2/mtproto/ack.go:33\n  - context canceled","elapsed":60300.00136314}
{"level":"debug","ts":1713448933.2000499,"logger":"conn.mtproto.group","caller":"tdsync/cancel_group.go:48","msg":"Task complete","v":"v0.99.2","conn_id":0,"dc_id":2,"task":"handleClose","elapsed":60300.001440411}

Looks like #1030

Looks like #1030

Yeah. All I do is listening to hundreds of channels and sending messages in one to many manner. So it's kinda like this person said

Application restart helps tho

authors: TrixiS ernado

repo: gotd/td

license: MIT


text:
Issue with getting the package

Ran: go get github.com/gotmc/libusb
Expected: No issues
Got: # github.com/gotmc/libusb ../../workspace/src/github.com/gotmc/libusb/context.go: In function 'set_debug': ../../workspace/src/github.com/gotmc/libusb/context.go:11:34: error: 'LIBUSB_OPTION_LOG_LEVEL' undeclared (first use in this function); did you mean 'LIBUSB_ERROR_NO_MEM'?  //   return libusb_set_option(ctx, LIBUSB_OPTION_LOG_LEVEL, level);                                   ^~~~~~~~~~~~~~~~~~~~~~~                                   LIBUSB_ERROR_NO_MEM ../../workspace/src/github.com/gotmc/libusb/context.go:11:34: note: each undeclared identifier is reported only once for each function it appears in

It appears you're using libusb 1.0.21. There was a breaking change in libusb 1.0.22 related to libusb_set_debug, which was fixed in commit 558d53e. Is there any way you could install libusb 1.0.22 to see if this fixes the problem?

I added a v1.0.21 release to the last commit before fixing the v1.0.22 breaking change, so you could install v1.0.21 to see if that resolves the problem.

What to do next if there is a problem with v1.0.21?

authors: 404th draganbobas matthewrankin

repo: gotmc/libusb


text:
feat: add getAllIssueTypes api

增加获取issue类型的接口，方便做筛选

LGTM

authors: livepo sevennt

repo: gotomicro/ego-component


text:
Port of govuk-frontend or implementation of the GOV.UK Design System?

GOV.UK Frontend is not an implementation of the GOV.UK Design System, it is a core part of the Design System, so govuk-react would therefore be a port of GOV.UK Frontend.

See
https://github.com/penx/govuk-react/pull/234#issuecomment-384920363
Need to discuss and clarify in readme

govuk-react is currently an implementation of GOV.UK Design System with the intention of directly using the GOV.UK Frontend source code in future, at which point it will become a port of GOV.UK Frontend

Also worth noting that govuk-react goes beyond a port, in that it provides additional functional components that a React App may need, e.g. LoadingBox.

Since this comment was written, we've been more closely following govuk-frontend, but we do still have additional components that are not present there.
I believe our existing description in README.md adequately describes things, and that we can probably close this issue.

authors: penx stevesims

repo: govuk-react/govuk-react


text:
Issue13

Added username/password functionality to connect to MQTT broker.
Specified on the command line with -u <username -P .

I'm a Git newbie... how do I incorporate this into my running system please?

git pull
This fetches the latest code from the repository.
You then have to rebuild and restart the program.

authors: bwims davet2001 gpbenton

repo: gpbenton/engMQTTClient


text:
Merge default and improve mode

Policy and info

Maintainers will close issues that have been stale for 14 days if they contain relevant answers.
Adding the label "sweep" will automatically turn the issue into a coded pull request. Works best for mechanical tasks. More info/syntax at: https://docs.sweep.dev/
Consider adding the label "good first issue" for interesting, but easy features.

Feature description
It seems to me that the default generation mode could just be an edge case of the improve mode - where the codebase to improve doesnt have any files yet. This would possibly streamline the code base, and allow for scenarios where someone wants to generate a new project but has already added a few tests, interfaces or a readme etc.
Motivation/Application
Im working on battleships task in autoGPT hackathon. This involves generating a new program in a repo where a few tests and interfaces are already present in the root source folder. We fail this test as generate task cant reference existing code. That made me think about why these things are seperate at all - and if they should be merged?

Hey, @TheoMcCabe, is this still a relevant issue and enhancement proposal? If not, please let me know, and I'll proceed with closing this.

Hey @TheoMcCabe I'm closing this for now since there was no activity recently, please feel free to reopen if it becomes relevant again.

authors: TheoMcCabe viborc

repo: gpt-engineer-org/gpt-engineer


text:
Handle BigInteger+BigDecimals like "normal" types

In Nashorn (don't recall what Rhino did here), a a JavaScript function like return argument + 1; called with BigInteger.ONE returns the numeric value 2. But with Graal.js it returns the JS string 11. The only way I could get it to work is to refactor this to
var BigInteger = Java.type("java.math.BigInteger")
return argument.add(BigInteger.ONE)

which feels a bit odd.
I'm not sure, whether the missing "native" support for BigInteger/BigDecimal is technically a regression or intentional, as I could not find anything explicit in the Narhorn/Rhino migration pages.
There is a related ticket for GraalPython, https://github.com/graalvm/graalpython/issues/60

Thank you for the report. As you have pointed out, java.math.BigInteger.ONE + 1 is 2 in Nashorn. So, it should be 2 in our nashorn-compat mode as well. I will fix it. On the other hand, there are some doubts if  BigInteger/BigDecimal (and other java.lang.Numbers) should be converted to JavaScript numbers this way even outside nashorn-compat mode (as these are not lossless conversions). So, the fix will work in nashorn-compat mode only (for now, at least).

Fixed by https://github.com/graalvm/graaljs/commit/1116051dd3385d76cee150b74af4fcf240defe26.

authors: iamstolis snazy

repo: graalvm/graaljs


text:
Make FindElementByTag more efficient

Currently this function iterates over all elements to find a tag match. It should be simple to make this more efficient using a hashmap index.

even just a simple cache (which wouldn't require an index on all elements or a major refactor) will make parsing native pixel images much faster.

repo: gradienthealth/go-dicom


text:
Support Android Studio as well

Hi!
Can't run android sample from this repo on the latest AS 2.2.3
I'm using Kotlin 1.1 M04 and jdk 8
Error:Internal error: org.jetbrains.kotlin.codegen.CompilationException: Back-end (JVM) Internal error: Failed to generate function android
Cause: Error type encountered: [ERROR : AppExtension] (ErrorTypeImpl).
File being compiled and position: (64,1) in C:/dev/git/gradle-script-kotlin/samples/hello-android/build.gradle.kts
PsiElement: //Extension functions to allow comfortable references
fun Project.android(setup: AppExtension.() -> Unit) = the<AppExtension>().setup()
The root cause was thrown at: KotlinTypeMapper.java:147
	at org.jetbrains.kotlin.codegen.MemberCodegen.genSimpleMember(MemberCodegen.java:199)
	at org.jetbrains.kotlin.codegen.ScriptCodegen.genMembers(ScriptCodegen.java:229)
	at org.jetbrains.kotlin.codegen.ScriptCodegen.generateBody(ScriptCodegen.java:100)
	at org.jetbrains.kotlin.codegen.MemberCodegen.generate(MemberCodegen.java:127)
	at org.jetbrains.kotlin.codegen.PackageCodegenImpl.generateFile(PackageCodegenImpl.java:119)
	at org.jetbrains.kotlin.codegen.PackageCodegenImpl.generate(PackageCodegenImpl.java:65)
	at org.jetbrains.kotlin.codegen.KotlinCodegenFacade.generatePackage(KotlinCodegenFacade.java:99)
	at org.jetbrains.kotlin.codegen.KotlinCodegenFacade.doGenerateFiles(KotlinCodegenFacade.java:77)
	at org.jetbrains.kotlin.codegen.KotlinCodegenFacade.compileCorrectFiles(KotlinCodegenFacade.java:44)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.generate(KotlinToJVMBytecodeCompiler.kt:417)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.analyzeAndGenerate(KotlinToJVMBytecodeCompiler.kt:328)
	at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileScript(KotlinToJVMBytecodeCompiler.kt:532)
	at org.gradle.script.lang.kotlin.support.KotlinCompilerKt.compileKotlinScriptToDirectory(KotlinCompiler.kt:70)
	at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler$compileTo$1.invoke(CachingKotlinCompiler.kt:134)
	at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler$compileTo$1.invoke(CachingKotlinCompiler.kt:45)
	at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler.withProgressLoggingFor(CachingKotlinCompiler.kt:185)
	at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler.compileTo(CachingKotlinCompiler.kt:132)
	at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler.access$compileTo(CachingKotlinCompiler.kt:45)
	at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler$compileWithCache$cacheDir$2.execute(CachingKotlinCompiler.kt:114)
	at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler$compileWithCache$cacheDir$2.execute(CachingKotlinCompiler.kt:45)
	at org.gradle.cache.internal.DefaultPersistentDirectoryCache$Initializer.initialize(DefaultPersistentDirectoryCache.java:92)
	at org.gradle.cache.internal.FixedSharedModeCrossProcessCacheAccess$1.run(FixedSharedModeCrossProcessCacheAccess.java:73)
	at org.gradle.cache.internal.DefaultFileLockManager$DefaultFileLock.doWriteAction(DefaultFileLockManager.java:184)
	at org.gradle.cache.internal.DefaultFileLockManager$DefaultFileLock.writeFile(DefaultFileLockManager.java:174)
	at org.gradle.cache.internal.FixedSharedModeCrossProcessCacheAccess.open(FixedSharedModeCrossProcessCacheAccess.java:71)
	at org.gradle.cache.internal.DefaultCacheAccess.open(DefaultCacheAccess.java:130)
	at org.gradle.cache.internal.DefaultPersistentDirectoryStore.open(DefaultPersistentDirectoryStore.java:55)
	at org.gradle.cache.internal.DefaultPersistentDirectoryStore.open(DefaultPersistentDirectoryStore.java:30)
	at org.gradle.cache.internal.DefaultCacheFactory.doOpen(DefaultCacheFactory.java:89)
	at org.gradle.cache.internal.DefaultCacheFactory.open(DefaultCacheFactory.java:63)
	at org.gradle.cache.internal.DefaultCacheRepository$PersistentCacheBuilder.open(DefaultCacheRepository.java:116)
	at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler.compileWithCache(CachingKotlinCompiler.kt:116)
	at org.gradle.script.lang.kotlin.provider.CachingKotlinCompiler.compileBuildScript(CachingKotlinCompiler.kt:92)
	at org.gradle.script.lang.kotlin.provider.KotlinBuildScriptCompiler.compileScriptFile(KotlinBuildScriptCompiler.kt:195)
	at org.gradle.script.lang.kotlin.provider.KotlinBuildScriptCompiler.executeScriptBodyOn(KotlinBuildScriptCompiler.kt:107)
	at org.gradle.script.lang.kotlin.provider.KotlinBuildScriptCompiler.access$executeScriptBodyOn(KotlinBuildScriptCompiler.kt:44)
	at org.gradle.script.lang.kotlin.provider.KotlinBuildScriptCompiler$compileTopLevelScript$1.invoke(KotlinBuildScriptCompiler.kt:92)
	at org.gradle.script.lang.kotlin.provider.KotlinBuildScriptCompiler$compileTopLevelScript$1.invoke(KotlinBuildScriptCompiler.kt:44)
	at org.gradle.script.lang.kotlin.provider.KotlinScriptPlugin.apply(KotlinScriptPlugin.kt:42)
	at org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:39)
	at org.gradle.configuration.project.BuildScriptProcessor.execute(BuildScriptProcessor.java:26)
	at org.gradle.configuration.project.ConfigureActionsProjectEvaluator.evaluate(ConfigureActionsProjectEvaluator.java:34)
	at org.gradle.configuration.project.LifecycleProjectEvaluator.doConfigure(LifecycleProjectEvaluator.java:70)
	at org.gradle.configuration.project.LifecycleProjectEvaluator.access$000(LifecycleProjectEvaluator.java:33)
	at org.gradle.configuration.project.LifecycleProjectEvaluator$1.execute(LifecycleProjectEvaluator.java:53)
	at org.gradle.configuration.project.LifecycleProjectEvaluator$1.execute(LifecycleProjectEvaluator.java:50)
	at org.gradle.internal.Transformers$4.transform(Transformers.java:169)
	at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:106)
	at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:61)
	at org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:50)
	at org.gradle.api.internal.project.DefaultProject.evaluate(DefaultProject.java:599)
	at org.gradle.api.internal.project.DefaultProject.evaluate(DefaultProject.java:125)
	at org.gradle.execution.TaskPathProjectEvaluator.configure(TaskPathProjectEvaluator.java:35)
	at org.gradle.execution.TaskPathProjectEvaluator.configureHierarchy(TaskPathProjectEvaluator.java:60)
	at org.gradle.configuration.DefaultBuildConfigurer.configure(DefaultBuildConfigurer.java:38)
	at org.gradle.initialization.DefaultGradleLauncher$ConfigureBuildAction.execute(DefaultGradleLauncher.java:233)
	at org.gradle.initialization.DefaultGradleLauncher$ConfigureBuildAction.execute(DefaultGradleLauncher.java:230)
	at org.gradle.internal.Transformers$4.transform(Transformers.java:169)
	at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:106)
	at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:56)
	at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:160)
	at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:119)
	at org.gradle.initialization.DefaultGradleLauncher.getBuildAnalysis(DefaultGradleLauncher.java:107)
	at org.gradle.launcher.exec.GradleBuildController.configure(GradleBuildController.java:79)
	at org.gradle.tooling.internal.provider.runner.ClientProvidedBuildActionRunner.run(ClientProvidedBuildActionRunner.java:60)
	at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
	at org.gradle.tooling.internal.provider.runner.RunAsBuildOperationBuildActionRunner$1.execute(RunAsBuildOperationBuildActionRunner.java:43)
	at org.gradle.tooling.internal.provider.runner.RunAsBuildOperationBuildActionRunner$1.execute(RunAsBuildOperationBuildActionRunner.java:40)
	at org.gradle.internal.Transformers$4.transform(Transformers.java:169)
	at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:106)
	at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:56)
	at org.gradle.tooling.internal.provider.runner.RunAsBuildOperationBuildActionRunner.run(RunAsBuildOperationBuildActionRunner.java:40)
	at org.gradle.tooling.internal.provider.runner.SubscribableBuildActionRunner.run(SubscribableBuildActionRunner.java:75)
	at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
	at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:41)
	at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26)
	at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:75)
	at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:49)
	at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:49)
	at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:31)
	at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:67)
	at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
	at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:47)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
	at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:26)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
	at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:34)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
	at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:74)
	at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:72)
	at org.gradle.util.Swapper.swap(Swapper.java:38)
	at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:72)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
	at org.gradle.launcher.daemon.server.exec.LogAndCheckHealth.execute(LogAndCheckHealth.java:55)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
	at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:60)
	at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
	at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:72)
	at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
	at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:50)
	at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:297)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
	at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:46)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalStateException: Error type encountered: [ERROR : AppExtension] (ErrorTypeImpl).
	at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper$1.processErrorType(KotlinTypeMapper.java:147)
	at org.jetbrains.kotlin.load.kotlin.TypeSignatureMappingKt.mapType(typeSignatureMapping.kt:118)
	at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapType(KotlinTypeMapper.java:460)
	at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.writeGenericArguments(KotlinTypeMapper.java:586)
	at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.writeGenericType(KotlinTypeMapper.java:537)
	at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.access$600(KotlinTypeMapper.java:96)
	at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper$2.invoke(KotlinTypeMapper.java:465)
	at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper$2.invoke(KotlinTypeMapper.java:462)
	at org.jetbrains.kotlin.load.kotlin.TypeSignatureMappingKt.mapType(typeSignatureMapping.kt:93)
	at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapType(KotlinTypeMapper.java:460)
	at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.writeParameterType(KotlinTypeMapper.java:1300)
	at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.writeParameter(KotlinTypeMapper.java:1270)
	at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.writeParameter(KotlinTypeMapper.java:1259)
	at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapSignature(KotlinTypeMapper.java:1068)
	at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapSignature(KotlinTypeMapper.java:1004)
	at org.jetbrains.kotlin.codegen.state.KotlinTypeMapper.mapSignatureWithGeneric(KotlinTypeMapper.java:987)
	at org.jetbrains.kotlin.codegen.FunctionCodegen.generateMethod(FunctionCodegen.java:173)
	at org.jetbrains.kotlin.codegen.FunctionCodegen.generateMethod(FunctionCodegen.java:157)
	at org.jetbrains.kotlin.codegen.FunctionCodegen.gen(FunctionCodegen.java:132)
	at org.jetbrains.kotlin.codegen.MemberCodegen.genSimpleMember(MemberCodegen.java:190)
	... 108 more

I have the same issue when running the android sample

I have updated the hello-android sample README to document the requirement on Android Studio 2.3 and the latest Kotlin plugin from the EAP 1.1 update channel.

Tried with AS2.4 alpha and latest kotlin plugin
the code being compiled, but all gradle script is red: http://i.imgur.com/eFe493L.png
am i doing something wrong?

tried with AS 3.0 preview4
Hello-Android isn't being compiled.
Error:Internal error: unable to compile script, see log for details

authors: adi1133 bamboo deviant-studio

repo: gradle/gradle-script-kotlin


text:
Project "coordinates" should use providers

Expected Behavior
The project "GAV" coordinates, as well as its "status" should use the Provider API.
Current Behavior
Currently Project defines getGroup, getName, getVersion and getStatus which are used by a number of dependency management and publication tasks. Because those can be changed anytime in a build, it leads to accidental complexity to get access to those lazily, most often requiring to share the whole project.
We should introduce providers for those, possibly a @Nested ProjectCoordinates or something similar.
An example of such a task is OutgoingVariantsReportTask which accesses the project at execution time for this.

I think we should introduce an Extension for this and move away from having something hard-coded on Project or in a Convention (such as the base convention).
In our build we already have a custom moduleIdentity extension which carries such information.
We could introduce such an extension in core and use it everywhere internally. Project.GetVersion() etc could then delegate to the extension only if they are used for backward compatibility (but they won't be used by Gradle core anymore).

We should use an extension to hold this data only if we intend this data to be something that is defined by a plugin of some kind, otherwise it should be something statically reachable from Project. To make it an extension also implies that we intend to support dependency resolution for Project instances that don't have this extension defined.
Core should never use an extension, otherwise the thing is not an extension. It is just more awkwardly accessed and less easily discovered statically defined data.

Just to clarify: I'm not trying to suggest that we shouldn't use an extension to model this data, only that if we do use an extension, it should be implemented as an actual extension.

I guess my main point is that we should give some thoughts to this, and sketch the use cases, before just transferring what we have now to providers. (Although we could if we do not want to mix too many concerns.)
We already allow different coordinates (group, name, version) to be defined in Publications and give special consideration to that during dependency resolution. In that light, I wonder if coordinates should be something in the core, or if e.g. just the name and the project path is what makes up identity of a project in the very core of Gradle.
Also we have the BasePluginConvention that has something like archiveBaseName. Which is not exactly the same, but it plays into the whole project name thing, once things are getting published.
Just wanted to mention these things here.

I think your main point is a good one. Personally, I think we should remove the coordinates from the project and use the project path as its identity when resolving locally, so that the coordinates are used only when publishing to some external system.
We should also consider removing archiveBaseName, as it was only really intended to be used for the legacy maven publishing plugin.
We might consider adding the coordinates to the component objects, so that the library { } or application { } objects can have an external identity associated with them and this would be used to calculate the (default) coordinates for the publications for these components.

To add more context to the need here, my own plugin reckon computes the version of your project from Git history. It makes use of project.getVersion() being typed as an Object that is later coerced to a String, which is essentially an old-school Provider.
My users have reported an issue ajoberstar/reckon#147 where some other plugins are accessing the version before users have configured the ReckonExtension, which ultimately means they're accessing the version before the user's build.gradle even ran. In a case like that, the offending plugin is likely operating with the wrong version value, since it's also before a user could have statically configured version = 'whatever' in the build.gradle.
There's stuff I can do in reckon to work around this to at least avoid the hard failure, but the real solution is that plugins need to treat project.getVersion() as the lazy value it potentially is. It appears that there's a mix of 3rd party and core Gradle plugins that can be found to call .toString() on the version too early. Having a new method of accessing the version using a Property<String> would go a long way towards reinforcing this behavior for plugin authors.

My 2ct:

java... won't make sense in my mind, as this is not Java specific, but a foundation of Gradle's core dependency management (every component has a group and a name).
I think the new place should be in settings.gradle. That's where you also define the name now via include("name") or rootProject.name = "name". If the group would be defined there, the projects coordinates are know earlier. This can help with further optimization for isolated projects and composite builds. Right now, composite build includes suffer from ordering issues, because the configuration phase of a build needs to be finished to know all the coordinates for the substituations. If the group would be known after the initialization phase, this could be greatly simplified I believe.

+1 to what @jjohannes said. I also feel like this should live into Settings, but there could be something smarter there, like a "project identity provider". Basically we need an object which represents the identity of a project (group, name), but it could be for example derived from the folder name, etc.

I see how that could be misunderstood. I don't mean having the same group for all subprojects. (Although for some builds it may be nice to have a convenient notation for that.) I mean that the information is defined in settings and then can't be modified afterwards anymore. But it can still be different for each individual project. E.g. if it would exist right now, the notation could be smth like this:
Include("module-a") {
  group = "org.example"
}

What @melix  wrote also contains that. Basically it would be good to have a new (and easy to use) API in settings to define which subprojects you have and give each of them a clear identity (group and name).

There are projects out there that dynamically set the version. One example is projects that use Git information to do that.
It is therefore important that information can be modified in the buildscript itself or via a Project plugin.

Good remark. I think there are at lease two topics/concerns mixed in this issue.
To clarify: what I wrote (https://github.com/gradle/gradle/issues/13672#issuecomment-1833838282) is only about moving the group definition to setting (initialization phase). Which is the same phase in which the name is defined and fixed.
I agree that defining project versions should stay in the normal build configuration phase.

I am actually not convinced that there's any difference between group, name and version. It should be possible to set the version via a settings plugin. In fact I think it's important that this information is computed prior to evaluating projects so that there's a model which can be queried. If that uses providers, then using git as an input or not shouldn't really matter, it would be covered.

@melix If you want to set those values in settings.gradle, it will cover 90% of use cases. However those values should then appear in projects as providers which can be overridden ( in order to cover the other 10% or so).
I do not agree with creating a custom provider in settings.gradle. It will end up with messy settings.gradle. It is also much simpler to do more work in a Project plugin than a Settings plugin. It is also less messy to apply for most people.
As an example, a JavaScript project, might want to obtain the version out of package.json rather than setting it twice. Node Gradle plugin already provides a simple way of doing this via
npm {
  usePackageJsonVersionAsProjectVersion()
}

I think forcing additional Settings plugins to be written to handle this, puts unnecessary stress on plugin authors.

What does Gradle use the group/version for outside of publishing? I'm mostly wondering because for publishing having them both on the Project and then again on the Publication can cause weird inconsistencies and confusion. 2 examples are

https://github.com/gradle/gradle/issues/23354 were Gradle itself is using the wrong ones in the published metadata,
project.name is not mutable from within the project so you either need to set publication.artifactId or change the name in settings.gradle which then again has different side effects
So maybe this could also be a chance to think about this holistically whether these should exist on both levels?

@gabrielittner you can break third party tooling. Centralizing those coordinates at the project level helps to consume then in other plugins that does not care at all about publication. I have used them without having any publishing plugin applied.

As middle ground, before some new API is introduced, could it be possible to change the behavior of the version accessor so that when a provider is passed to the setter, the getter retrieves the provider value instead of giving pack the provider as is.
This behavior should be behind a feature flag to ensure nothing breaks in consuming code if the build didn't opted in.
I've seen workarounds wrapping the provider itself that calls .get() in the .toString() implementation.

authors: JavierSegoviaCordoba adammurdoch ajoberstar bric3 gabrielittner jjohannes melix ysb33r

repo: gradle/gradle


text:
Remove deprecated org.gradle.logging.LoggingManagerInternal

Summary

org.gradle.internal.logging.LoggingManagerInternal

See how it goes and consider getting rid of the types and patch the bytecode or generate placeholder types to let plugins compiled against past API work.
Checklist

[x] Validate whether we should remove the API in the 7.0 release

If the removal is not possible then create a follow-up issue and link it in the overview spreadsheet

[x] Update the upgrade guide
[x] Check User Manual for dangling references and outdated documentation
[x] Mark the story as done in the overview spreadsheet.

Done: #15767

Done: #15767

authors: bamboo jjohannes


text:
Model building hangs when using new parallel TAPI APIs

Using IntelliJ IDEA 2021.1 EAP (Community Edition) Build #IC-211.6085.26, built on February 20, 2021 and the
project_hang_reproducer (2).zip, sync fails to finish.
Thread dump threads.txt does not point to any Kotlin/AGP code, so I'm not sure what's causing this. Also, parallel model building is disabled so that does not seem to be the root cause.

Also, parallel model building is disabled so that does not seem to be the root cause.
But it uses the new Controller.run() API to run nested actions.

It looks like there are 2 issues here. One is that, according to the thread dumps, parallel build is still happening even though it is is disabled. What are you using to disable it?
The second issue is the deadlock itself. Looking at the thread dumps, this probably only happens when included builds are present. We should have a fix ready soon.

The deadlock should be fixed now.

I've also verified that:

building gradle from https://github.com/gradle/gradle/commit/7c8357a247e621e38617e3cd97cc60c0a0ea39de
using IJ Build #IC-211.7142.13, built on April 21, 2021
enabling gradle.tooling.models.parallel.fetch in the options registry in the IDE

runs sync successfully (some dependencies do not resolve but that is unrelated).
The thread dumps were generated by @vladsoroka, so I'm not sure how the parallel mode was disabled.

Thanks for testing it out. I might close this issue and we can open a new issue if there are problems with correctly disabling the feature.

authors: adammurdoch gavra0 yuriy-solodkyy


text:
Switch to Gradle 7.0 causes "plugin not found"

When I switch to Gradle 7.0 https://github.com/ytai/ioio/pull/250/files I run into
Plugin with id 'maven' not found
https://github.com/ytai/ioio/pull/250/checks?check_run_id=2339920975
Expected Behavior
No error should appear
Current Behavior
It run into Plugin with id 'maven' not found
Steps to Reproduce
https://github.com/ytai/ioio/pull/250/files
Your Environment
Here you see the error https://github.com/ytai/ioio/pull/250/checks?check_run_id=2339920975

The maven plugin has been removed in Gradle 7.0 after it has been deprecated for a while.
Please replace it with maven-publish. See: https://docs.gradle.org/current/userguide/upgrading_version_6.html#removal_of_the_legacy_maven_plugin


text:
--write-verification-metadata not adding entries for parent poms

Expected Behavior
We'd like ./gradlew --write-verification-metadata ${taskThatResolvesArtifacts} -m to generate entries in gradle/verification-metadata.xml for all signed artifacts, even if they're just parent poms
Current Behavior
We're observing when running ./gradlew --write-verification-metadata that it isn't adding entries into gradle/verification-metadata.xml for the keys used to sign parent poms
For example, https://android-review.googlesource.com/c/platform/frameworks/support/+/2024786/8 was generated by removing some entries from gradle/verification-metadata.xml and running https://android-review.googlesource.com/c/platform/frameworks/support/+/2019456/9, but it failed at https://android-build.googleplex.com/builds/pending/P31485959/androidx_device_tests/latest/view/logs/build_error.log with:
A problem occurred evaluating script.
> Dependency verification failed for configuration ':buildSrc:plugins:cacheableApi'
  6 artifacts failed verification:
    - apache-15.pom (org.apache:apache:15) from repository maven2
    - apache-18.pom (org.apache:apache:18) from repository maven2
    - apache-9.pom (org.apache:apache:9) from repository maven2
    - mojo-parent-40.pom (org.codehaus.mojo:mojo-parent:40) from repository maven2
    - tomlj-1.0.0.jar (org.tomlj:tomlj:1.0.0) from repository maven2
    - tomlj-1.0.0.pom (org.tomlj:tomlj:1.0.0) from repository maven2
  This can indicate that a dependency has been compromised. Please carefully verify the signatures and checksums. Key servers are disabled, this can indicate that you need to update the local keyring with the missing keys.

The .pom file of each of these dependencies appear to specify <packaging>pom</packaging> (even tomlj-1.0.0.pom)
Context
This makes it more difficult for us to remove the 16-character versions of some keys from gradle/verification-metadata when Gradle adds the 40-character versions, see https://github.com/gradle/gradle/issues/20193

Also related, I observed that Gradle didn't add an entry for Gradle Enterprise either
From https://android-build.googleplex.com/builds/pending/P31484702/androidx_device_tests/latest/view/logs/build_error.log :
FAILURE: Build failed with an exception.

* What went wrong:
Dependency verification failed for configuration 'classpath':
  - On artifact gradle-enterprise-gradle-plugin-3.8.1.jar (com.gradle:gradle-enterprise-gradle-plugin:3.8.1) in repository 'maven': Artifact was signed with key '5208812e1e4a6db0' but it wasn't found in any key server so it couldn't be verified

This can indicate that a dependency has been compromised. Please carefully verify the signatures and checksums. Key servers are disabled, this can indicate that you need to update the local keyring with the missing keys.

These files failed verification:
  - GRADLE_USER_HOME/../../prebuilts/androidx/external/com/gradle/gradle-enterprise-gradle-plugin/3.8.1/gradle-enterprise-gradle-plugin-3.8.1.jar (signature: GRADLE_USER_HOME/../../prebuilts/androidx/external/com/gradle/gradle-enterprise-gradle-plugin/3.8.1/gradle-enterprise-gradle-plugin-3.8.1.jar.asc)

I'm not sure whether this is similar enough to be part of this issue or a new issue

This came up again today. I found that this workaround seemed to work:

Identify a parent .pom file for which --write-verification-metadata isn't writing an entry. Call it Parent.
Find any (other) .pom file that our build is depending on. Call it Dep.
Modify Dep to declare a dependency on Parent (not just listing it as the parent)
Regenerate verification metadata via --write-verification-metadata
Inspect the resulting verification-metadata.xml for changes and undo any that are unwanted (like failures to verify Dep due to us modifying it in step 3)
Undo the modifications in Dep from step 3

related but separate issue: https://github.com/gradle/gradle/issues/25111

This is most likely caused by the levels of caching in Gradle dependencies.
When Gradle sees a Maven POM the first time, it walks its parent hierarchy to build its full model. It then caches an internal representation of this in <GRADLE_USER_HOME>/caches/modules-2/metadata-2.<version>/descriptors.
If this cache is already present when you generate the dependency verification file, Gradle will only attempt to resolve the project POM but not attempt to walk the parents and will cause them to not appear in the metadata file. Which will be an issue for a build running on a machine that does not have that cache entry.
A workaround can be to remove the metadata cache before generating dependency verification data. Either for all modules if you do a first time generation, or specific to some coordinates, which can be found inside that descriptors folder as a group/artifact/version set of folders underneath.
A proper fix would be to make this metadata model building aware that we are building dependency verification and force the parent walking in that case.

Note that this issue is also happening when choosing a completely empty folder as GRADLE_USER_HOME, so it sounds unlikely it is related to caching. Unless something about the parent gets cached while processing the children...

authors: grote ljacomet mathjeff yogurtearl


text:
Make OutputEventRenderer single point emitting threads for rendering pipeline

Expected Behavior
Executor logic e.g. for throttling or task grouping is moved to OutputEventRenderer, the top of the rendering pipeline. Synchronization only needs to happen in OutputEventRenderer and none of the listeners in the pipeline.
The central executor is shut down as needed. Part of the work will likely involve identifying all the places that create instances of OutputEventRenderer outside of a service registry. To be able to properly shut down, the OutputEventRenderer needs have a lifecycle.
Current Behavior
Synchronization needs to happen at lower levels of the rendering pipeline. This maybe lead to contention and synchronization issues.
Context
Avoid contention and synchronization issues for rendering pipeline.
Related to #2221

Duplicate of #2221

authors: bmuschko oehme


text:
8.1 RC3: Dependencies not available when 'org.gradle.configuration-cache.problems=warn'

It seems dependencies are not available for tasks that set notCompatibleWithConfigurationCache() when org.gradle.configuration-cache.problems=warn.
Expected Behavior
Dependencies are printed when running the allConfigurationDependencies task having org.gradle.configuration-cache.problems=warn set in gradle.properties.
Current Behavior
Dependencies are not printed.
They are printed if org.gradle.configuration-cache.problems=warn is commented out in gradle.properties.
Context
It prevents the Gradle Versions Plugin from working when org.gradle.configuration-cache=true and org.gradle.configuration-cache.problems=warn: https://github.com/ben-manes/gradle-versions-plugin/issues/666#issuecomment-1488938639.
Related: #24411.
Steps to Reproduce
Reproducer: https://github.com/ianbrandt/gradle-configuration-cache.
Credit for the minimal reproducer task to @ben-manes.
Your Environment
Build scan URL: https://scans.gradle.com/s/wdrhio333pxey.

This is the intended behavior of notCompatibleWithConfigurationCache, though it might be a bit counter-intuitive. With problems=fail, errors coming from an annotated task do not fail the build but the cache entry is always discarded, so the build never runs from cache when such a task is in the work graph. With problems=warn, the entry is stored, and Gradle attempts to reuse it.
Before Gradle 8.0, it was only noticeable when you have a configuration cache hit, because a miss build was using a previously configured work graph. Since 8.0, the configured graph is first saved to the configuration cache, and then the new instance of the graph is loaded from the cache to be executed, to benefit from the parallel execution. Gradle falls back to the old behavior of using the configured graph if the entry is discarded due to errors. With problems=warn, it is expected that your build might run incorrectly if there are problems detected.
@ianbrandt, do you have a use case which requires you to keep using problems=warn for anything but seeing more configuration cache problems in one go?

@mlopatkin: Oh, well, I suppose I don't (that I know of).
I enabled it as a part of the troubleshooting that led to the now fixed #24411, and was naively assuming the Gradle Versions Plugin should work regardless of whether it was set to warn or fail.
Having it set to warn seems to also break the Dependency Analysis Plugin, as I just filed here: https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin/issues/885.
As of RC3, both plugins seem to work with org.gradle.configuration-cache=true and nothing set for org.gradle.configuration-cache.problems. That's my use case at present, though given how the User Guide explains the option:

By default, Gradle will fail the build if any configuration cache problems are encountered. When gradually improving your plugin or build logic to support the configuration cache it can be useful to temporarily turn problems into warnings.

...I wouldn't tend to think warn would itself lead to any breakage. Quite the opposite, really. If you all intend to keep it as is for 8.1, maybe a warning added to the manual would help avert future bug filings.

authors: ianbrandt mlopatkin


text:
Cannot create companion GCC Cross-toolchain without default platforms

Expected Behavior

Toolchains (specifically GCC) should not automatically inherit all platforms ability to build.
model {
 platforms {
    x86 { architecture 'x86' }
    x64 { architecture 'x86_64' }
    xaarch64 { architecture 'aarch64' } // Cross-platform
 }

 toolchains {
    gcc(Gcc) {
       target("x86") { }
       target("x64") { }
    }
    xgcc(Gcc) {      // Cross platform toolchain
       target("xaarch64") { cppCompiler = "aarch64-linux-gnueabi-g++" }
    }
 }
}

The gcc toolchain should only support x86 and x64 targets, while the xgcc toolchain should only support xaarch64 targets.
Current Behavior

Both gcc and xgcc bind to all platform targets (x64, x86, xaarch64), as shown by println <toolchain>.platforms
Context

The current behaviour makes it particularly difficult to create projects that can build for multiple targets (local platforms, as well as cross-platforms for remote targets). When using the following model rule, every binary reports buildable by xgcc (for a component that uses any targetplatform x86, x64 and/or xaarch64):
@Mutate
void configureOptionalBuildables(BinaryContainer binaries) {
    binaries.withType(NativeBinarySpec) { bin ->
       println "${bin} ${bin.toolChain}"
    }
 }

For my specific use case, I'd like to skip over builds that aren't supported on the current system (i.e. if a cross toolchain is supplied, but doesn't exist on the system path, just skip it, similar to how specifying an "arm" platform (with no custom prefix or path) will be skipped in favor of x86 and x64). When the extra xgcc toolchain is added, the default x86 and x64 targets added by gradle's internals cause gradle to think the platform is buildable, but when it looks for aarch64-linux-gnueabi-g++, it can't find it, and fails instantly.
Steps to Reproduce (for bugs)

See above.
Your Environment

Gradle Version: 4.1
Native Plugin: "cpp"

I've done a bit more digging and found a workable solution for the time being.
Subclassing AbstractGccCompatibleToolChain identically to the implementation of GccToolChain, and adding the following lines in the constructor will 'unset' the default x86 and x64 architectures added by the AbstractGccCompatibleToolChain constructor through reflection.
def platConfField = AbstractGccCompatibleToolChain.class.getDeclaredField("platformConfigs")
platConfField.setAccessible(true)
platConfField.get(this).clear()
platConfField.setAccessible(false)

def configInsertLoc = AbstractGccCompatibleToolChain.class.getDeclaredField("configInsertLocation")
configInsertLoc.setAccessible(true)
configInsertLoc.set(this, 0)
configInsertLoc.setAccessible(false)

Perhaps it may be worthwhile to add a way to 'reset' the platformConfigs property of AbstractGccToolChain to make this behaviour accessible to the DSL?

Closed with #3124


text:
simple way to reduce CLI reporting of dependencies when writing locks

Expected Behavior
I want the list of dependencies but including the projects, basically the output should be similar to the result of this small shell script I keep in a Makefile
./gradlew dependencies --write-locks --scan | grep -e FAILED -e https
https://gradle.com/s/vj57gufd42bai

probably something like
tasks.withType<Dependencies>().configureEach {
  report { verbosity = FAILURES }
}

I understand that it's currently possible, but the way I was told is so complicated as to not be worth the effort figuring it out or maintaining the code to do so. Only printing failures or perhaps the tree including the failure seems reasonable.
Current Behavior (optional)
No response
Context
As it stands you can easily do --write-locks and not realize anything is failing at all.
yes you can figure this out by looking at a scan, but that is significantly annoying when you don't know that there's anything that needs to be looked at.

This issue needs a decision from the team responsible for that area. They have been informed. Response time may vary.

It seems like the CLI approach is good enough. A plugin can also address that. However, since it looks like a common use case, we can consider documenting the described approaches and/or including the suggested output filtering in the core task.

Alternatively, --write-locks could change the behavior of dependencies to fail the build or hide output.  Or we should have a task similar to dependencies that is specifically made for writing locks that has the better behavior.
We're not planning on changing this in 8.x

Or you could add a command line option to show only failed dependencies.
Side comment it didn't occur to me that this didn't fail the build. I think that writing locks where there are failures should fail to build regardless of whether it's on dependencies. I guess this issue is more about the dependencies report output than it is that. I could open another issue for that?

authors: big-guy ov7a xenoterracide


text:
Support composite builds in continuous build

We now detect changes to buildSrc, nested GradleBuild tasks and composites
Composite builds don't work yet because the included build's tasks are not executed
Removed warnings about using composite build and continuous build

@eskatos @bamboo Heads up, this is going to cause some breakage in GSK in 4.1.  I'm adding a new scope between build session and build.  This changes the PluginServiceRegistry interface.
I introduced a AbstractPluginServiceRegistry that implements all of the methods so subclasses only need to override what they need.
I've handled the breakage right now by catching AbstractMethodError, but I'll coordinate with you guys once this is merged.

@big-guy For some minor tweaks (renames, etc), I've made the changes myself, rebased and force-pushed. For the rest, I've left review comments. Not much required to be ready to merge (assuming I didn't break anything!).

@bigdaz please take another look and see if this can be merged.

@bamboo @eskatos now that this is merged, are you guys using a 4.0 nightly until 4.0-rc-1 is out or can you move to a 4.1 nightly?

@big-guy we currently use snapshots from a gradle-script-kotlin branch on top of release (4.0-*)
Yep, we'll move this on top of master soon (4.1-*), probably once 4.0-rc-1 is out.

@eskatos @bamboo Just AbstractPluginServiceRegistry is on release now, https://github.com/gradle/gradle/commit/cb1429a39e761019fe0c8d09337c980ff0cc64ae
I think you should be able to update to a newer 4.0-nightly and switch to using it.  Once that's in, we can then update master to use a newer version of GSK and I can remove my dirty catch AbstractMethodError handling.

Thanks, @big-guy.
@eskatos, I've just rebased gradle@gradle-script-kotlin on top of release and triggered a new distro build.

Thanks for the heads up @big-guy!
See https://github.com/gradle/gradle-script-kotlin/commit/170f07b702dc5745c44773fbce684cafeecfba7c

@big-guy the new Gradle Script Kotlin release based using AbstractPluginServiceRegistry is on master. It should be ok to remove the AbstractMethodError exception handler now.

Thanks @bamboo : https://github.com/gradle/gradle/commit/16ea61af0034ac1fc396aba73f54556af66dd6a3

Hey guys, so glad to see this feature implemented just in time for my needing it! A quick sanity check, though: should these changes be available in 4.0 M2? I've just upgraded to it, and I'm still seeing [composite-build] Warning: continuous build doesn't detect changes in included builds.. If not, I guess it won't be available until 4.1? Thanks.

FYI, I just grabbed the latest 4.1 nightly and --continuous now works exactly as expected with my composite build. Beautiful!
Btw, it's nice to see https://gradle.org/nightly in place, but I had a hard time finding it. To make it a little more discoverable, you might want to update the text at https://gradle.org/install#manually from

Need to work with an older version? See the releases page.

To something like

Need to work with an older version or nightly snapshot? See the releases page.

Thanks for the feedback @cbeams. Glad it's working out for you.
I'll pass on your comment about making the nightly more easily discoverable.

authors: bamboo big-guy bigdaz cbeams eskatos


text:
Fixes for restoring build services when loading from configuration cache after storing

Fixes #?
Context
Also fixes locating the root gradle.properties file when using --settings-file. This option is deprecated, however the issue was causing some test failures when load-after-store is enabled for the configuration cache.
Also fixes some tests to make them configuration cache compatible.
Contributor Checklist

[ ] Review Contribution Guidelines
[ ] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[ ] 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.
[ ] 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
[ ] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[ ] Ensure that tests pass sanity check: ./gradlew sanityCheck
[ ] 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

@bot-gradle test and merge

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

authors: adammurdoch bot-gradle


text:
Publish 8.0-20221228191444+0000

Publish 8.0-20221228191444+0000

@bot-gradle test and merge

I've triggered a build for you.


text:
Update Publishing Samples and Docs

Attempt at some small improvements to javadoc and documentation throughout publishing.

Link to publishing sections of docs from publishing samples.
Suppress IDE errors from javadoc links to missing subproject.

@bot-gradle test and merge

Error while scheduling pre-tested commit, please contact the administrator.

@bot-gradle test and merge

I've triggered a build for you.

authors: bot-gradle tresat wolfs


text:
Fix ill task ordering 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
n/a Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
n/a 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

Reviewing cheatsheet
Before merging the PR, comments starting with

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

@bot-gradle test and merge

I've triggered a build for you. Click here to see all failures if there's any.

authors: Vampire bot-gradle lkasso


text:
Introduce Isolated Projects-safe builder for Kotlin DSL models

Introduces a separate IP-safe model builder used for the Kotlin DSL model requested during sync.
The existing builders have to be compatible with generic parametrization, while the modern versions of IntelliJ do not use them during sync. With Isolated Projects feature enabled, we can assume more constraints, which ultimately make the implementation of the model builder cleaner.

@bot-gradle merge

I've triggered a build for you. Click here to see all failures if there's any.

authors: alllex bot-gradle


text:
Add "Contributing to Documentation" to CONTRIBUTING.md

Just a minor update that helps with discovering documentation guidelines
Context

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
[x] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[x] Provide unit tests (under <subproject>/src/test) to verify logic
[x] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[ ] Ensure that tests pass sanity check: ./gradlew sanityCheck
[ ] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Reviewing cheatsheet
Before merging the PR, comments starting with

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

@bot-gradle merge

The merge queue build has started. Click here to see all failures if any.

authors: bot-gradle oleg-nenashev


text:
Fix punctuations

#28329
Context

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.
[ ] Update User Guide, DSL Reference, and Javadoc for public-facing changes.
[ ] Ensure that tests pass sanity check: ./gradlew sanityCheck.
[ ] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest.

Reviewing cheatsheet
Before merging the PR, comments starting with

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

@bot-gradle merge

The merge queue build has started. Click here to see all failures if any.

The merge queue build has started. Click here to see all failures if any.

authors: bot-gradle helfese ov7a


text:
Migrated build-type plugin to Kotlin

That was an interesting experience. See http://mrhaki.blogspot.com/2009/03/use-negative-index-in-groovy-lists-to.html for the Groovy behavior with a negative array index. I don't think that was intended by the author but avoided an OutOfBounds exception which I got initially with Kotlin. I just converted the code. But it would be good to have at some point refactoring to express its intent better. I also removed an unnecessary constructor.

Almost all of your generics lack spaces between the generics.
Eg: Map<String,Any> vs Map<String, Any>.

Superseded by #43

authors: JLLeitschuh eskatos hansd


text:
Add option to add all labels on the deployment

This is an option to fix #1546
We have a requirement where we need all the labels applied to the deployment to be applied to to pod as well

@David-John-Nintex why isn't additionalLabels an option?
It will look a bit ugly since you will have to redefine a few labels, but I think it should do the trick.
Would prefer not to add a single config for a single user.

@David-John-Nintex why isn't additionalLabels an option? It will look a bit ugly since you will have to redefine a few labels, but I think it should do the trick.
While it would work, then we have to keep it in line with the chart updates, since some of the values there are generated by helm, however if this is the recommended way of doing it, then it should work

Would prefer not to add a single config for a single user.
I can see this, was wondering, however, if it would be something others would also like to use, but if not, then yes, I do agree, one thing for one user is not a great thing

@NissesSenap additionalLabels is not an option for us, as we would have to redefine the labels that are already defined in the grafana-operator.labels helper function (namely app.kubernetes.io/version and app.kubernetes.io/managed-by so these would be redefined everywhere where we use the labels

I think it's a very limited pool of companies that have this need, but we can wait with the issue and see if it gets any thumbs up.
@David-John-Nintex I don't understand your answer. Why wouldn't it be possible to do exactly that?
I think the additional labels would overwrite the existing default labels. Can you share how it would look?
Another options since your company have this great idea, would be to have a mutating webhook that solves this for you automatically for example through OPA, this way you don't have to label your applications in all third party apps, that I assume you do today.

@NissesSenap I agree my company has a very strict policy to get things into our clusters.
However, looking at the latest changes that have been made to your helm charts, you have now removed the ability to add additional labels to the deployment (with the merging of the labels and the additionalLabels) you now cannot add any additional labels to the Deployment
I have updated my PR to include the ability to add additionalLabels to the deployment as you were previously able to add, except this time specifically for the Deployment

It's still possible to add labels to the deployment, those labels will however also be applied to all other resources.
If we decide to go with deployment.additonalLabels, I'd like to see the same option for all other resources as well.

It's still possible to add labels to the deployment, those labels will however also be applied to all other resources.
If we decide to go with deployment.additonalLabels, I'd like to see the same option for all other resources as well.

If you look at https://github.com/grafana/grafana-operator/blob/e328412e8e2eff3d0155edcbd86950101ca37742/deploy/helm/grafana-operator/templates/deployment.yaml#L21 only the selectorLabels are set on the Pod created by the Deployment
As far as I can see this is the only resource where the merging of the additionalLabels into the grafana-operator.labels here has broken the ability to set custom labels

I see, you want this to apply to the selector instead of the deployment.
In that case, would it suffice to add
{{- with .Values.additionalLabels }}
{{ toYaml . }}
{{- end }}

to the selectorLabels template?

I see, you want this to apply to the selector instead of the deployment. In that case, would it suffice to add
{{- with .Values.additionalLabels }}
{{ toYaml . }}
{{- end }}

to the selectorLabels template?

No, then you'll effectively be making selectorLabels the same as labels which would work for me, but i think you would probably have to add
{{- with .Values.additionalLabels }}
{{ toYaml . }}
{{- end }}

to the label: part in the deployment template

I agree with @David-John-Nintex, I currently also have this limitation as I need to add labels to pods, not just the deployment 👍

Hey, I missed this issue so I opened a duplicate one (#1642). In my issue I suggest changing the macro from including grafana-operator.selectorLabels to grafana-operator.labels in spec.template.metadata.labels, as it would cleanly fix everyone's issue.

I see, you want this to apply to the selector instead of the deployment. In that case, would it suffice to add
{{- with .Values.additionalLabels }}
{{ toYaml . }}
{{- end }}

to the selectorLabels template?

You can't do this, because it would break the deployment on update. Selector labels are immutable after being set, which is why they are templated separately from the additional labels.

This is a stale PR, and a new one has been opened #1649

authors: David-John-Nintex NissesSenap jrRibeiro pharaujo theSuess

repo: grafana/grafana-operator


text:
Annotation examples, filtering to tempated host

Grafana: 3.1.1
Grafana-zabbix: 3.1.1
Unfortunately annotations are a bit hazy now and for me as first time user it's not working.  At all.
First problem is that your example in the guide is outdated (and pretty annoying anyway, it's a moving gif insead of some well rested text showing an example, but that's probably a matter of taste): it's using some old GUI; the new GUI have at least four (or rather five)  field to fil; (instead of one) and zero tooltips or samples.
Since the dashboard uses $group and $host templating I thought it's useable in the annotation, but maybe not.  Or wildcards, or regexp, in some format. Or not. Wildcards are required, or even useful for group and host? Or shall it left empty? Or have to be filled by specifics?
I can't get it working, possibly missing the right permutation. :-)

I need to add docs for annotations, you're absolutely right.

I'm trying to use a template in an annotation, and it is not working.  I have tried about 20 different combinations of the template name with no luck.  Either there is a bug, or I just haven't come across the right syntax.  What is the correct syntax for this?

That's strange, it works for me:

Hello, I have problem with wildcard in Trigger field

But when I type a full name of trigger I can see all needed annotations.
Zabbix version -  3.2.4
Grafana version - 4.2.0
Zabbix plugin - 3.3.0
Could you please help me?

Use regexp instead wildcard?

Thanks. It's work fine

No idea how to query. This doesn't work - no annotations displayed on my graphs for the following annotation configuration:

Even though the Zabbix UI shows problems for the same query:

This is how to query:

We need documentation on how to properly query in annotations.

The best way to remove issues that devs didn't even look at is to mark them as stale for lack of activity. ;)

The best way to remove issues that devs didn't even look at is to mark them as stale for lack of activity. ;)

That's not fair, Alex have commented in 2016!  ;-)

authors: Nowaker ad-m alexanderzobnin grinapo jars99 svdubovik

repo: grafana/grafana-zabbix


text:
Modify QueryVariable

Hi,
I have a simple QueryVariable, like this:
function getVariable() {         return new QueryVariable({             name: 'output',             datasource: ABCD,             query: SELECT blabla,             hide: VariableHide.hideVariable,         });     }
I use it as SceneVariableSet, like:
return new EmbeddedScene({         $variables: new SceneVariableSet({             variables: [                 getVariable()             ],         }),...
For display I use it in a textPanel, like:
const textPanel = PanelBuilders.text()             .setTitle("title")             .setOption("content",                 "Variable: <b>${output}</b>"             ).build()
Question: how can I modify the value of the variable (named 'output' here) before display it? It should be a string, I want manipulate that, like uppercase oder so.
Thank you in advance.

you have variable formats here https://grafana.com/docs/grafana/latest/dashboards/variables/variable-syntax/
We do not have an upper-case variable value formatter.
You could contribute it https://github.com/grafana/scenes/blob/main/packages/scenes/src/variables/interpolation/formatRegistry.ts

authors: korinekgergely torkelo

repo: grafana/scenes


text:
tk fmt panic when encountering unescaped regex in string

Given this invalid jsonnet:
{
  x: {
    data: '([^:]+)(?::\d+)?',
  },
}

running ./tk fmt test.jsonnet (latest main - 774c664) panics with the following stack:
panic: Badly formatted string, should have been caught in lexer.

goroutine 1 [running]:
github.com/google/go-jsonnet/internal/formatter.(*EnforceStringStyle).LiteralString(0xc0002a63f0, 0x1580280, 0xc0002a63f0, 0xc0001b8370, 0x0, 0x0)
	/Users/ntodor/Projects/go/pkg/mod/github.com/google/go-jsonnet@v0.17.0/internal/formatter/enforce_string_style.go:45 +0x1e5
github.com/google/go-jsonnet/internal/pass.(*Base).Visit(0xc0002a63f0, 0x1580280, 0xc0002a63f0, 0xc0002ce170, 0x0, 0x0)
	/Users/ntodor/Projects/go/pkg/mod/github.com/google/go-jsonnet@v0.17.0/internal/pass/pass.go:431 +0x297
github.com/google/go-jsonnet/internal/pass.(*Base).ObjectField(0xc0002a63f0, 0x1580280, 0xc0002a63f0, 0xc0002ce0f0, 0x0, 0x0)
	/Users/ntodor/Projects/go/pkg/mod/github.com/google/go-jsonnet@v0.17.0/internal/pass/pass.go:160 +0x193
github.com/google/go-jsonnet/internal/pass.(*Base).ObjectFields(0xc0002a63f0, 0x1580280, 0xc0002a63f0, 0xc0001b8490, 0x0, 0x0)
	/Users/ntodor/Projects/go/pkg/mod/github.com/google/go-jsonnet@v0.17.0/internal/pass/pass.go:191 +0x76
github.com/google/go-jsonnet/internal/pass.(*Base).Object(0xc0002a63f0, 0x1580280, 0xc0002a63f0, 0xc0001b8420, 0x0, 0x0)
	/Users/ntodor/Projects/go/pkg/mod/github.com/google/go-jsonnet@v0.17.0/internal/pass/pass.go:331 +0x66
github.com/google/go-jsonnet/internal/pass.(*Base).Visit(0xc0002a63f0, 0x1580280, 0xc0002a63f0, 0xc0002ce350, 0x0, 0x0)
	/Users/ntodor/Projects/go/pkg/mod/github.com/google/go-jsonnet@v0.17.0/internal/pass/pass.go:435 +0x8a3
github.com/google/go-jsonnet/internal/pass.(*Base).ObjectField(0xc0002a63f0, 0x1580280, 0xc0002a63f0, 0xc0002ce2d0, 0x0, 0x0)
	/Users/ntodor/Projects/go/pkg/mod/github.com/google/go-jsonnet@v0.17.0/internal/pass/pass.go:160 +0x193
github.com/google/go-jsonnet/internal/pass.(*Base).ObjectFields(0xc0002a63f0, 0x1580280, 0xc0002a63f0, 0xc0001b8540, 0x0, 0x0)
	/Users/ntodor/Projects/go/pkg/mod/github.com/google/go-jsonnet@v0.17.0/internal/pass/pass.go:191 +0x76
github.com/google/go-jsonnet/internal/pass.(*Base).Object(0xc0002a63f0, 0x1580280, 0xc0002a63f0, 0xc0001b84d0, 0x0, 0x0)
	/Users/ntodor/Projects/go/pkg/mod/github.com/google/go-jsonnet@v0.17.0/internal/pass/pass.go:331 +0x66
github.com/google/go-jsonnet/internal/pass.(*Base).Visit(0xc0002a63f0, 0x1580280, 0xc0002a63f0, 0xc0002b0200, 0x0, 0x0)
	/Users/ntodor/Projects/go/pkg/mod/github.com/google/go-jsonnet@v0.17.0/internal/pass/pass.go:435 +0x8a3
github.com/google/go-jsonnet/internal/pass.(*Base).File(0xc0002a63f0, 0x1580280, 0xc0002a63f0, 0xc0002b0200, 0xc00000e9d8)
	/Users/ntodor/Projects/go/pkg/mod/github.com/google/go-jsonnet@v0.17.0/internal/pass/pass.go:461 +0x88
github.com/google/go-jsonnet/internal/formatter.visitFile(...)
	/Users/ntodor/Projects/go/pkg/mod/github.com/google/go-jsonnet@v0.17.0/internal/formatter/jsonnetfmt.go:133
github.com/google/go-jsonnet/internal/formatter.Format(0x7ffeefbff9e1, 0xc, 0xc0002a6390, 0x2f, 0x2, 0x2, 0x1, 0x1, 0x1010001, 0x0, ...)
	/Users/ntodor/Projects/go/pkg/mod/github.com/google/go-jsonnet@v0.17.0/internal/formatter/jsonnetfmt.go:168 +0x5f6
github.com/google/go-jsonnet/formatter.Format(...)
	/Users/ntodor/Projects/go/pkg/mod/github.com/google/go-jsonnet@v0.17.0/formatter/formatter.go:47
github.com/grafana/tanka/pkg/tanka.Format(0x7ffeefbff9e1, 0xc, 0xc0002a6390, 0x2f, 0x2f, 0x0, 0x0, 0x1)
	/Users/ntodor/Projects/oss/tanka/pkg/tanka/format.go:89 +0xeb
github.com/grafana/tanka/pkg/tanka.FormatFiles(0xc0002b0090, 0x1, 0x1, 0xc00014dd48, 0x0, 0x7cb1fb8, 0xc0002b01d0, 0x0, 0x0)
	/Users/ntodor/Projects/oss/tanka/pkg/tanka/format.go:66 +0x2cc
main.fmtCmd.func2(0xc0001e2460, 0xc0002b0090, 0x1, 0x1, 0x0, 0x0)
	/Users/ntodor/Projects/oss/tanka/cmd/tk/fmt.go:72 +0x22c
github.com/go-clix/cli.(*Command).execute(0xc0001e2460, 0xc0002b0070, 0x1, 0x1, 0xc0001e2460, 0xc0002b0070)
	/Users/ntodor/Projects/go/pkg/mod/github.com/go-clix/cli@v0.1.1/command.go:118 +0x291
github.com/go-clix/cli.(*Command).Execute(0xc0001b0d20, 0x0, 0x0)
	/Users/ntodor/Projects/go/pkg/mod/github.com/go-clix/cli@v0.1.1/command.go:74 +0x157
main.main()
	/Users/ntodor/Projects/oss/tanka/cmd/tk/main.go:58 +0x2eb

LE: I tried updating go-jsonnet to the latest version with go get -u github.com/google/go-jsonnet@12bd29d,  but I still see the same issue. Please let me know if you wish me to open an issue on the go-jsonnet side too.

@sbarzowski I think this issue might be of interest to you. Please let me know if you'd like me to open an issue for it on the go-jsonnet repo.

I think you just have to escape the slash:
{
  x: {
    data: '([^:]+)(?::\\d+)?',
  },
}

I'm not an expert on this but I'm pretty sure this is part of the JSON spec, the \ is a reserved character: https://datatracker.ietf.org/doc/html/rfc8259#section-7

I agree, but I assume panicking might not be the ideal behaviour here. I'll see if I can repro it on the go-jsonnet side and open a bug there.

Good point, feel free to reopen if this panic is Tanka specific

authors: Duologic mihaitodor

repo: grafana/tanka


text:
Controlling the media sequence values of individual segments

I have an application that records HLS streams and I often need to replicate the media sequence values of some source stream. One thing I encounter fairly frequently is that the media sequence is restarted or it could be that some media segments are dropped. In any case, I need more precise control of the media sequence values of individual segments. It is not simply a matter of incrementing the sequence by one.
I already have this working correctly. This is how it works.
I call MediaPlaylist.Remove() if I have to, then I create a segment, set its SeqId and call MediaPlaylist.AppendSegment().
Now I find the first segment in the playlist and set MediaPlaylist.SeqNo = firstSegment.SeqId.
I don't like how I find the first segment, and I was going to ask if you could expose a function that would return the head of the list.
I was also hoping that the changes in #116 would be helpful for my use case. In theory, the playlist could respect the sequence IDs that I set on the segments, and automatically set the media sequence of the playlist to the media sequence of the first segment (although this would break backwards compatibility).
But unfortunately, PR #124 breaks what I have right now. The SeqId values that I set on the segments before I append them to the playlist are lost.
So now I have two problems:

I need the SeqId values that I set on the segments to be preserved.

I would like a way of accessing the first segment in the playlist.

The second thing should be easy, but I'm worried about the first one.
Do you think you could support such a use case?

This is no longer relevant to me.


text:
snap: Fix snap build with kernel fragments

Signed-off-by: Ganesh Maharaj Mahalingam ganesh.mahalingam@intel.com

Pushing this to master directly. Closeing this PR now.

repo: grahamwhaley/kata-containers-packaging


text:
Where to put boilerplates

Hey, I have created a boilerplate for rails6 + graphql https://github.com/zauberware/rails-devise-graphql
Where can I include this here in the Readme?

Hi @simonfranzen, I was considering to have starters listed since there are some noteworthy examples like yours. You can add a section called "starters/boilerplates" before "other rails tools" and add yours by sending a pull request.

PR is open https://github.com/gramantin/awesome-rails/pulls

@simonfranzen merged, thanks so much!

authors: ekremkaraca simonfranzen

repo: gramantin/awesome-rails


text:
🛑 Grambling State University is down

In 21e95c1, Grambling State University (https://www.gram.edu) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Grambling State University is back up in 66d76ab after 1 hour, 10 minutes.

repo: gramblingstatewebmaster/upptime


text:
🛑 Grambling State University is down

In 81f3658, Grambling State University (https://www.gram.edu) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Grambling State University is back up in 24480bf after 22 minutes.


text:
Update types please

.showScanQrPopup() and .platform are missing

This repo only uses the types of another package. We extracted them into @types/telegram-web-app. Do you want to contribute to https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/telegram-web-app and add the missing types from the Bot API 6.4 update?

This repo only uses the types of another package. We extracted them into @types/telegram-web-app. Do you want to contribute to https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/telegram-web-app and add the missing types from the Bot API 6.4 update?

I am not experienced enough in writing ts to contribute

This was completed in a0dd51239d6266814507b546f72f0dea3d1d2262 and released in 1.3.0.

authors: KnorpelSenf alevinru

repo: grammyjs/web-app


text:
Cannot read property 'serviceId' of undefined when using graphcool-lib in legacy projects

Hi,
I'm using resolvers functions in the console. I get error from graphcool-lib since I saved again my functions
types :
type SignupEmailUserPayload {
  id: ID!
}

extend type Mutation {
  signupEmailUser(email: String!, password: String!): SignupEmailUserPayload
}

functions :
const fromEvent = require("graphcool-lib").fromEvent

module.exports = function(event) {
  const graphcool = fromEvent(event)
  return { id: "ID" }
}

Error :
CODE: 500
MESSAGE: Cannot read property 'serviceId' of undefined
ERROR: Script generated an unhandled synchronous exception.
TypeError: Cannot read property 'serviceId' of undefined
at Object.fromEvent (/data/_verquire/graphcool-lib/0.1.3/node_modules/graphcool-lib/dist/src/index.js:163:49)
at module.exports (/data/io/23d6f9cf1e594725a8ac5fff930cd115/webtask.js:6:34)
at /data/io/23d6f9cf1e594725a8ac5fff930cd115/webtask.js:40:24
at Async.series.Request.get.Async.series.Async.forEachOf.createError.code (/data/sandbox/lib/sandbox.js:854:33)
at /data/sandbox/node_modules/async/dist/async.js:3853:24
at replenish (/data/sandbox/node_modules/async/dist/async.js:946:17)
at iterateeCallback (/data/sandbox/node_modules/async/dist/async.js:931:17)
at /data/sandbox/node_modules/async/dist/async.js:906:16
at /data/sandbox/node_modules/async/dist/async.js:3858:13
at /data/sandbox/lib/sandbox.js:928:24

Seems to be resolved by the graphcool-lib update https://github.com/graphcool/graphcool-lib/releases/tag/v0.1.3
I close the issue

what's the fix?

repo: graphcool/graphcool


text:
Logo ideas

As the title suggests this issue is used to find a great logo for graphql-middleware.
The best idea I got so far, which would also somehow reflect the name, is a group or three cartoon animals with the middle one wearing a GraphQL T-Shirt - something like npm’s wombat.
I would love to hear all the ideas you’ve come up with! 😄

Thanks a lot for bringing this up! I really like the idea of @fabien0102. I think there should be a visual-only logo that works without "GraphQL Middleware" text part, therefore I'm rather a fan of the first suggestion.
Maybe @kuldar has some thoughts as well?

I like the direction of the first logo. 👍 I agree with @schickling though, that it would be great if the symbol could stand on its own. I can try iterating a bit on the first concept to see if I can come up with some improvements.

@kuldar Just in case that you need the sources (even if it's really simple to recreate ^^)
graphql-middleware-logo.zip

@kuldar Very nice iteration! Really like the ratio of yours propositions (mine was a little bit too rectangle ^^).  I think that my favorite is the Logo v1, simple and understable (and I also like the dash style for the idea of "flexibility" and "lightness" 😃 )

I agree, I think v1 & v3 have more potential than others. I think v1 feels bit more like a full "stack" vs. the v3 feels bit like it's crossing off the GraphQL logo.  But I agree, that with v1, there's less super direct connection to GraphQL.

Great work @kuldar! I'm actually a big fan of v2 since it clearly shows how you can split up your GraphQL server into layers, v1 is also great though.
Other thoughts? :)

I agree with @schickling, I don’t know why but v2 feels just very well put - maybe because it’s for some reason slightly similar to Prisma logo?
Truly great ideas!

What about something like this, which emphasizes the nature of middleware (sequential processing). The use of gradients, seamlessly transitioning between centers, with only two colors, is suggestive of the transformation of data between middleware (the center of the dots symbolizing individual pieces of middleware). This is just a rough concept. Let me know if y'all have ideas for its revision :) I'll continue to brainstorm.

Hey @kuldar, could you provide me with the files of your designs? I think we should try v2 first and see how it feels within the README - we can nevertheless still switch later on to v1 or v3 if needed, but I have high hopes for v2. What do you think?

#3 Please do keep the thread going! I like the appearance of v2 in README, but I would be more than happy to hear your thoughts as well!

authors: fabien0102 harrysolovay kuldar maticzav schickling

repo: graphcool/graphql-middleware


text:
[WIP] sanitize names when using them as tag value

related: https://github.com/graphite-project/graphite-web/pull/2458

Codecov Report

Merging #858 into master will decrease coverage by 0.66%.
The diff coverage is 75%.

@@            Coverage Diff             @@
##           master     #858      +/-   ##
==========================================
- Coverage   49.88%   49.22%   -0.67%
==========================================
  Files          37       37
  Lines        3460     3462       +2
  Branches      495      495
==========================================
- Hits         1726     1704      -22
- Misses       1622     1639      +17
- Partials      112      119       +7

Impacted Files
Coverage Δ

lib/carbon/util.py
45.03% <75%> (-3.81%)
:arrow_down:

lib/carbon/hashing.py
83.15% <0%> (-7.37%)
:arrow_down:

lib/carbon/protocols.py
71.8% <0%> (-1.77%)
:arrow_down:

lib/carbon/cache.py
79.47% <0%> (-1.33%)
:arrow_down:

Continue to review full report at Codecov.

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

The biggest concern here is the impact that this will have on anyone who is currently using series with a ~ character in the name, since those series will be changed.  We could reduce that impact if we reduce the scope here to only stripping leading ~ signs, since technically that is the only place that it actually impacts the tagging system.

Yeah, we could do that. Then i think I should update the docs accordingly, and update the validation function in raintank/schema as well to keep everything consistent

Another question: What do we do if a metric name is exactly ~ and nothing else?
We have a rule that says tag values must be >=1 char long in https://github.com/graphite-project/graphite-web/blob/master/docs/tags.rst#carbon
We could just add it to the index with tag name="", but that would only be queriable via regex because the query name= has another meaning.
In the case of MT we could also consider that metric to have "invalid tags", and there's already a setting to define whether metrics with invalid tags should still get indexed via their other tags and the name or not, but in the case of carbon I'm not sure if there's a nice way to reject a metric name.

The only real option available here would be to drop it as invalid afaik

I updated the docs accordingly https://github.com/graphite-project/graphite-web/pull/2458/files

Currently, if the resulting string is "", it would raise an Exception which gets caught here: https://github.com/graphite-project/carbon/blob/8e94e48f1d7605857b4e8ff3f5ac3646d55fd3f8/lib/carbon/cache.py#L42
So it would ignore the metric and log an error. I think that's probably what we want

I've pushed a few more tests, so the test coverage report is happy

authors: DanCech codecov-io replay

repo: graphite-project/carbon


text:
Support for relationship, pagination and cursors

It would be great if we can demonstrate how relationship, pagination and cursors could be implemented.
Here is some documentation: https://graphql.org/learn/pagination
It is easy to return a list of items e.g. Array(Bar) but not sure how to implement pagination.
Thanks!

GraphQL is not tied to any specific data store, you can implement these things in any way you want. The example from your link would look something like this:
@[GraphQL::Field]
def friends(ctx: MyContext, first: Int32?, offset: Int32?): Array(Hero)
  first = 100 if first.nil?
  offset = 0 if offset.nil?
  rows = ctx.database_query("SELECT foo from bar LIMIT #{first} OFFSET #{offset}")
  rows.map { |row| Hero.new row }
end

That was very helpful.
Thank you!

authors: jgillich kefahi

repo: graphql-crystal/graphql


text:
How to use new object macro when its subject gets derived

Trying to figure out how to use new object macro when its subject gets derived as a part of another struct:
struct Person {
  name: String,
}

#[juniper::object]
impl Person {
  fn name(&self) -> &str {
    self.name.as_str()
  }
}

#[derive(GraphQLObject)]
struct Derived {
  person: Person,
}

Error is on the line #[derive(GraphQLObject)]:
the trait bound `user::Person: juniper::GraphQLType<__S>` is not satisfied

the trait `juniper::GraphQLType<__S>` is not implemented for `user::Person`

help: consider adding a `where user::Person: juniper::GraphQLType<__S>` bound

This is an unfortunate interaction of generics.
I'm working on a fix, but for now you can do this:
#[derive(GraphQLObject)]
#[graphql(Scalar = juniper::DefaultScalarValue)]
struct Derived {
  person: Person,
}

It works, thanks!

authors: alexfedoseev theduke

repo: graphql-rust/juniper


text:
🛑 GrauNeko.com is down

In 7f17758, GrauNeko.com (https://graueneko.com) was down:

HTTP code: 403
Response time: 6820 ms

Resolved: GrauNeko.com is back up in 3fddf7d after 33 minutes.

repo: graueneko/status-page


text:
fix: remove tar file in the stages image to save space and remove the c…

…hgrp as the copy is doing ti
fixes AM-4370

CI has been skipped to save credits as those files are not evaluated

repo: gravitee-io/gravitee-access-management


text:
6375 migrate role part2

Issue
gravitee-io/issues#6375
Description
Next step for role migration screen
Additional context

Gravitee.io Automatic Deployment
📚 View the storybook of this branch here

Gravitee.io Automatic Deployment
Congrats, all the CI steps were 🟢 . The Bot was able to deploy the build of this PR, so you can now try it directly here! 🚀
Notes: The deployed app is linked to the management API of the Element Zero team's environment.

Gravitee.io Automatic Deployment
📚 View the storybook of this branch here

Gravitee.io Automatic Deployment
Congrats, all the CI steps were 🟢 . The Bot was able to deploy the build of this PR, so you can now try it directly here! 🚀
Notes: The deployed app is linked to the management API of the Element Zero team's environment.

Gravitee.io Automatic Deployment
📚 View the storybook of this branch here

Gravitee.io Automatic Deployment
Congrats, all the CI steps were 🟢 . The Bot was able to deploy the build of this PR, so you can now try it directly here! 🚀
Notes: The deployed app is linked to the management API of the Element Zero team's environment.

authors: ThibaudAV graviteeio

repo: gravitee-io/gravitee-api-management


text:
fix: put reportMetrics execution in vertx event queue

Issue
https://github.com/gravitee-io/issues/issues/7194
Description
Since the migration to VertX 4, end() is returning a future, which means the underlying call is not made at the good time.
To fix that, we put the call of reportMetrics() function to vertx event queue, so we are sure it's executed after the response is flushed

Gravitee.io Automatic Deployment
🚀 A prerelease version of this package has been published on Gravitee's private artifactory, you can:

use it directly by updating your project with version: 1.2.1-SNAPSHOT.issues-7194-reporting-after-response-end
download it from Artifactory here

:tada: This PR is included in version 1.2.1 :tada:
The release is available on:

1.2.1
GitHub release

Your semantic-release bot :package::rocket:

authors: graviteeio ytvnr


text:
fix(hc): optimize httpclient for healthcheck

Issue
https://github.com/gravitee-io/issues/issues/6658
Description
Create the HttpClient only once per HealthCheck Endpoint and reuse it while it's possible.

Replaced by https://github.com/gravitee-io/gravitee-api-management/pull/887

authors: gaetanmaisse jhaeyaert

repo: gravitee-io/old-gravitee-api-management


text:
the stderr error logger should not contain entire RFC5424 message

What are the steps to reproduce this issue

Install an ingester
Route systems syslog out to our ingester
observe output

What happens?
This is what the entry is:
<30>1 2023-11-16T23:27:22.725587+00:00 hostname gravwell_simple_relay 35859 - -  <14>1 2023-11-16T23:27:22.721015Z hostname simplerelay - SimpleRelay/main.go:219 [gw@1 ingesteruuid="a9ae46fc-0312-47aa-b5ed-1be8b1330000" active="9"] Closing active connections

What were you expecting to happen?
Just emit the  [gw@1 ingesteruuid="a9ae46fc-0312-47aa-b5ed-1be8b1330000" active="9"] Closing active connections portion when sending to stderr
Any logs, error output, etc?
Any other comments?
the syslog  relay/journal/whatever already puts an appname and header on it, we shouldn't do that too
This also happens in the windows internal logging, we emit a full RFC5424 message into the windows event logger, thats bad.
What versions of software are you using?
5.4.2

I'm still seeing full RFC5424 messages on fatal logs to stderr:
√ valinor:gravwell/ingesters/HttpIngester % ./HttpIngester -config-file test.conf

^C<11>1 2023-11-29T14:41:45.315424-07:00 valinor httpingester - HttpIngester/main.go:177 [gw@1 error="http: Server closed"] failed to serve HTTP server

You will because you did not redirect stderr so we assume you are in debug mode
without redirecting stderr, everything goes to stderr
WITH redirecting stderr, only fatal goes to stderr

When I run as above, only fatal messages come to stderr, and the rest go to the log location. But yes, when I redirect stderr, it trims the output to just the message and structured output.
LGTM

repo: gravwell/gravwell


text:
TypeError:can't convert np.ndarray of type numpy.bool_

Traceback (most recent call last):
File "main.py", line 89, in
num_predict=args.num_predict)
File "/home/hemengge/xlnet-pytorch/data_utils.py", line 335, in make_permute
is_masked = torch.Tensor(feature.pop("is_masked"))
TypeError: can't convert np.ndarray of type numpy.bool_. The only supported types are: double, float, float16, int64, int32, and uint8

Having the same issue.

is_masked = torch.ByteTensor(feature.pop("is_masked").copy().astype(np.uint8)) @menggehe

authors: LorraineLo4 menggehe stephen-song

repo: graykode/xlnet-Pytorch


text:
Context help in Alert Configuration UI under Custom Message box references old documentation

When configuring a new or editing existing Alert Configuration, the help text under the Custom Message refers to an older (1.3) version of Graylog but should refer to 2.3 (and under a different section in docs at that). See:

In:
https://github.com/graylog-labs/graylog-plugin-slack/blob/bd1cc8061cdf80b301c5283d16abed1772b96b11/src/main/java/org/graylog2/plugins/slack/configuration/SlackConfigurationRequestFactory.java#L52
the URL:
http://docs.graylog.org/en/1.3/pages/streams.html
should probably be:
http://docs.graylog.org/en/2.3/pages/streams/alerts.html#email-alert-notification
or maybe without the named anchor if that's likely to change.

Good catch. All fixed in 3.0.1

repo: graylog-labs/graylog-plugin-slack