text:
Specify a dependency should be on the module path

I need to specify a certain dependency should be on the module path.  It's not a modular jar, so it should run as an automatic module.  I tried following this example project.  However, this modifies the jar files which fails when the jars are signed.  I could remove the signature files (.SF, .DES, .RSA), but the code itself checks that these exists and fails if they don't, which makes sense since it's proprietary code, and they don't want people mucking around with their code.
The solution seems extremely simple: move a string from -cp to -p.
However, as I look into the gradle source, I see that gradle actually doesn't have any concept of a module path at all!  This is very surprising considering that gradle supposedly models the "domain" of dependencies, their management, building a java project, and even running java projects.  The distinction between the classpath and module path is essential to build and run the code.  After all, ANY jar file can be placed either on the classpath or the module path regardless of whether its a module jar or not, and where you place it affects its visibility to the rest of the system significantly.
Gradle, other than the module path, has a sophisticated modelling of the domain, with distinctions between the compile-time classpath, run-time classpath, and even whether transitive dependencies end up on either of those classpaths or not.
Now, it does appear that module path "support" was added by shoehorning in the JavaModuleDetector service into a variety of tasks, including CreateStartScripts (used by assembleDist), JavaExecHandlerBuilder (used by run), and JavaCompile.  This detector basically sorts the classpath into the module path and the final classpath.  It's invoked just before doing the work that requires the distinction, such as compiling, running, or outputting the start build scripts.
In the compile and run tasks, I can effectively override the behavior by add extra command line arguments that definitively set the classpath and module path.  In the case of the CreateStartScripts class, I can't see a way to override the behavior, since I can't replace the implementation of the JavaModuleDetector since it isn't a field, and I can't modify its output since it isn't stored in a field.  I can't override methods of a task, since I can't replace tasks with subtypes (I believe), but even if I could, I'd have to copy and paste the code from the super class into the subclass since the work is either done all in one method, or delegated to private methods.
Expected Behavior
Either:

model module paths in the domain as you do module classpaths,
enable the behavior of the JavaModuleDetector to be overridden, preferably modified, especially on a per-task and per-project basis, or
make tasks that require a distinction of a classpath and a module path consume two file collections as task inputs/properties.

I'm really open to any solution here that works here.  I really don't want to rewrite all the java-related tasks, or add brittle hacks to each task as I come across them because the domain model is broken.
Current Behavior
The module path is not modeled at all in the domain and the behavior of the JavaModuleDetector cannot be changed in any manner, and tasks are hard or impossible to configure to change the module path.

If I understand correctly, the detection logic in Gradle does not work because your JAR does not even have the MANIFEST entry for automatic module name?
Is that not the easiest thing to change? Otherwise even renaming that file causes the module name to change.

That's right, but I can't change the manifest since it's a signed jar, and that makes the validation wrong.  I can't remove the signature so that it isn't a signed jar, since the code in the jar checks that the signature is intact.  To be clear, this jar is not my own; I cannot make the company that provides it sign the jar with my own changes.
Yes, renaming the jar file name changes the module name, which affects the code, so I'd expect would be modelled in the build script since it's an important part to get right when building and running.

After some thinking, I found a workaround.  Not to make gradle put the jar on the module path, but I can put the jar on the classpath, and then build by own automatic module which bridges the classpath API to the module-path world.  This is what I have to do anyway when I have dependencies that have split packages since those fail to load as automatic modules.
I still think a build system should be able to move a dependency from the classpath to the module path easily, especially one as sophisticated and widely used in Java projects as Gradle.

Thanks for reporting a workaround.
I'll leave this open as a feature request but no work is planned in this area for the medium term.

I think an issue I've come across is related. If a non-modular Java library is included in 'dependencies' in a Java project, Intellij IDEA will think it is a module and require you to specify it in module-info.java, using the automatic JAR module name as described in the Java API here (not the same as Automatic-Module-Name which doesn't exist for many projects).
However, when Gradle's compileJava runs, it gives "error: module not found " on the module-info.java file. So Gradle doesn't seem to support JAR-file-name based automatic modules, or maybe it's that IntelliJ idea is assuming something can be a module when it can't be one. It seems like it would be useful for Gradle documentation somewhere to mention that at least, that it doesn't support automatic JAR modules.

I think the problem is in both.  Gradle at the last minute sorts the classpath into the module path and classpath by looking at the artifacts themselves -- if they have a module declaration, or a manifest entry for the automatic module name, it's placed on the module path, otherwise the classpath.
I think IntelliJ may put a jar file on the module path if it is required (by either its filename or automatic module name in the manifest) by an explicit module.  IntelliJ's method may work in general, and maybe Gradle should do such a thing, but I know IntelliJ does have a bug where if you require an IntelliJ module (ie, a "sub-project") as an automatic module, it won't work.
That bug makes the workaround I described above very frustrating to use, since you need to make a sub-project that builds the automatic module to bridge the classpath to the module path, but since a sub-project builds that jar, IntelliJ won't be able to find it when you require it as an automatic module.  (It would be able to find it if it were an external dependency.)  Now you can work around that by building sub-project to create the jar, then explicitly add the jar file to the dependencies of the main project.  But, that change will be undone whenever you re-load from Gradle (which I think happens when you open the project), and you'll have to be sure that jar is up-to-date when you're compiling.

I'd like to add my dependency problem in this thread.
I have a little groovy project that depends on org.codehaus.groovy:groovy-all:3.0.10 along with this dependency I get a transitive dependency via org.codehaus.groovy:groovy-cli-picocli:3.0.10 to info.picocli:picocli:4.6.1.
I added to my project this little modul-info.java:
module zzz {
  exports de.mydomain.mypackage;

  requires org.codehaus.groovy;
  requires org.codehaus.groovy.cli.picocli;
  requires info.picocli;
}

When I try to build my project I get this error:
error: module not found: info.picocli requires info.picocli;
So a add -d for debug information to my gradle call:
2022-05-30T11:07:30.996+0200 [DEBUG] [org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler] Compiler arguments:

-source 11 -target 11 -d /home/bdonauba/eclipse-config-2021-12/eclipse-workspace/zzz/build/classes/java/main -h /home/bdonauba/eclipse-config-2021-12/eclipse-workspace/zzz/build/generated/sources/headers/java/main -g -sourcepath /home/bdonauba/eclipse-config-2021-12/eclipse-workspace/zzz/src/main/java -proc:none -s /home/bdonauba/eclipse-config-2021-12/eclipse-workspace/zzz/build/generated/sources/annotationProcessor/java/main -XDuseUnsharedTable=true

-classpath /home/bdonauba/.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-api/1.7.25/da76ca59f6a57ee3102f8f9bd9cee742973efa8a/slf4j-api-1.7.25.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.apache.ant/ant/1.10.12/be08c4f63e92e03bac761404cf77bc270928b6c5/ant-1.10.12.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.hamcrest/hamcrest-core/1.3/42a25dc3219429f0e5d060061f71acb49bf010a0/hamcrest-core-1.3.jar

--module-path /home/bdonauba/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-core/2.17.2/fa43ba4467f5300b16d1e0742934149bfc5ac564/log4j-core-2.17.2.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-slf4j-impl/2.17.2/183f7c95fc981f3e97d008b363341343508848e/log4j-slf4j-impl-2.17.2.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-ant/3.0.10/78de69050e0b80b9dc82c582ca1efdd1e44b49ae/groovy-ant-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-astbuilder/3.0.10/8321e46a9102394589d0f7f69e4a22eeee7936a3/groovy-astbuilder-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-cli-picocli/3.0.10/da2322f7c2f26cb2be1ebd7f10774019a1d31e24/groovy-cli-picocli-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-console/3.0.10/530d682e2f5fc691b7a4a7aa575d406da3504e48/groovy-console-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-datetime/3.0.10/b0d9a510aaf426c26c4294ab5be4d1e5bc09494f/groovy-datetime-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-groovydoc/3.0.10/1f85c12a08d402816813d01ab0e766cf0555d776/groovy-groovydoc-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-jmx/3.0.10/e3f8818be3ec7c92df4bcd65cfa00075329a7fc8/groovy-jmx-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-json/3.0.10/5962a46d1584060065cd8d87bc175e8350715477/groovy-json-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-jsr223/3.0.10/a2713237f82c2b12575ac4b861d69dd0829c8644/groovy-jsr223-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-macro/3.0.10/81c984d99535686640763e2e1ad7849dd52fbab2/groovy-macro-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-nio/3.0.10/98fb17b16a106214695ac3c75ca14188c8c6d5e6/groovy-nio-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-servlet/3.0.10/5e94652deb8e572671b662460de2a5f0513af809/groovy-servlet-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-sql/3.0.10/46e9dbe26e2e6ce00ee55814ab0b8bf97185c0f5/groovy-sql-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-swing/3.0.10/5ca4b3eaf637f81b0fa054db9604eed2a64e268b/groovy-swing-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-templates/3.0.10/ee4e54b0c24f6ce8a34d09cc737e9d79f71c03da/groovy-templates-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-test/3.0.10/5bc0117cbb8f9a8f1e1c756d4c2efba723574370/groovy-test-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-test-junit5/3.0.10/1424600412bc35e95b7baaecd23cda449e74c0f5/groovy-test-junit5-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-testng/3.0.10/6d7699da9d93554368ddeac18e0972c70f65609e/groovy-testng-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-xml/3.0.10/5367241b0c5d4638c0e8371028a2d19a0af35156/groovy-xml-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy/3.0.10/b92c72a758f468e64b55e38abe06afa873decdba/groovy-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-docgenerator/3.0.10/4210e2237f87f0458a096704fdc25eedfdc58578/groovy-docgenerator-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy-groovysh/3.0.10/39d4bb27754117b7baddd9c4d259795e415e5264/groovy-groovysh-3.0.10.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.17.2/f42d6afa111b4dec5d2aea0fe2197240749a4ea6/log4j-api-2.17.2.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/com.github.javaparser/javaparser-core/3.24.0/6b87dfd14e6db068f4fe7f23526b6e02353a296e/javaparser-core-3.24.0.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/junit/junit/4.13.2/8ac9e16d933b6fb43bc7f576336b8f4d7eb5ba12/junit-4.13.2.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.junit.jupiter/junit-jupiter-api/5.8.2/4c21029217adf07e4c0d0c5e192b6bf610c94bdc/junit-jupiter-api-5.8.2.jar:/home/bdonauba/.gradle/caches/modules-2/files-2.1/org.opentest4j/opentest4j/1.2.0/28c11eb91f9b6d8e200631d46e20a7f407f2a046/opentest4j-1.2.0.jar /home/bdonauba/eclipse-config-2021-12/eclipse-workspace/zzz/src/main/java/module-info.java
2022-05-30T11:07:30.997+0200 [INFO] [org.gradle.api.internal.tasks.compile.JdkJavaCompiler] Compiling with JDK Java compiler API.

As you can see picocli-4.6.1.jar is neither on the modulepath nor on the classpath although it's a full blown module jar with modul-info.class.
I downloaded 4.6.1 by hand from central and checked it myself. The jar files contains module information:
javap -c META-INF/versions/9/module-info.class
module info.picocli {
  requires java.base;
  exports picocli;
}

To sum the whole thing up I often do not understand how gradle is acting in reference to Java modules.
BTW I can build my project within Eclipse. I just had to call 'gradle eclipse' and moved some of the jar files from from classpath to modulpath. I wished it would be so easy in gradle.

I think this issue is not a feature request but a bug. Simply put, gradle does not support non-modularized JARs properly. Here is a minimal project to reproduce this:
build.gradle.kts
plugins {
    id("java")
}

repositories {
    mavenCentral()
}

dependencies {
    implementation("com.github.tomakehurst:wiremock-jre8:2.33.2")
}

module-info.java
module example.main {
	requires wiremock.jre8;
}

Now run ./gradlew compileJava and you will get:
/Users/i547301/SAPDevelop/IdeaProjects/UnnamedModuleTest/src/main/java/module-info.java:2: error: module not found: wiremock.jre8
        requires wiremock.jre8;
                         ^
1 error

If you run it with --debug you will see that the wiremock jar is put on the classpath but not on the module-path. If I run javac manually with the jar on the module-path, it compiles without errors.

I agree with @jakobmagiera. Gradle does not support dependencies on non-modularized JARs correctly. The section of https://docs.gradle.org/current/userguide/java_library_plugin.html which @ritzow quotes, namely

A third case are traditional libraries that provide no module information at all — for example commons-cli:commons-cli:1.4. Gradle puts such libraries on the classpath instead of the module path.

describes exactly what Gradle should not be doing. When building a modular project, the correct way to depend on a legacy JAR is to place it on the module path so that it is made into an "automatic module". This should be done even if it doesn't have Automatic-Module-Name defined in its manifest. See e.g. https://openjdk.org/projects/jigsaw/spec/sotms/#automatic-modules.
Gradle is currently inhibiting adoption of the module system by making it impossible for modular projects to depend on non-modular JARs lacking Automatic-Module-Name without jumping through the hoops described in https://docs.gradle.org/current/userguide/java_library_plugin.html.
Maven does it the right way, out-of-the-box with no hoops. Here is a simple modular project depending on a non-modular JAR org.hipparchus:hipparchus-core:2.3 which lacks an Automatic-Module-Name.
pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example</groupId>
    <artifactId>com.example</artifactId>
    <version>0.0.1-SNAPSHOT</version>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.hipparchus</groupId>
            <artifactId>hipparchus-core</artifactId>
            <version>2.3</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <artifactId>maven-clean-plugin</artifactId>
                <version>3.1.0</version>
            </plugin>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.0</version>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>3.1.0</version>
            </plugin>
        </plugins>
    </build>

</project>

src/main/java/module-info.java
module com.example {
  requires hipparchus.core;
  exports com.example;
}

src/main/java/com/example/SquareRoot.java
package com.example;

import org.hipparchus.util.FastMath;

public class SquareRoot {

  public static void main(final String[] args) {
    System.out.println(FastMath.sqrt(2.));
  }

}

Build using mvn package and run using
$ java --module-path /path/to/hipparchus-core-2.3.jar:./target/com.example-0.0.1-SNAPSHOT.jar --module com.example/com.example.SquareRoot
1.4142135623730951

You can also bypass Maven and manually compile using javac if you so choose.

+1 for providing a way to define if a jar goes on the module vs class path.

authors: andrewsgoetz big-andy-coates dumischbaenger jakobmagiera kjmcclain ljacomet ritzow


text:
Update Zinc used by Scala plugin to 1.7.1

Zinc 1.7.1 includes a number of bug fixes including under-compilation when Java annotation changes.
Release notes:

https://github.com/sbt/zinc/releases/tag/v1.7.0
https://github.com/sbt/zinc/releases/tag/v1.7.1

Diff: https://github.com/sbt/zinc/compare/v1.6.1...v1.7.1

We're now up to 1.8.0

We have a PR to update to the latest - Zinc 1.9.3

#25887

Any reason to be cautious?

source: gharchive/issue

authors: gabrieljones ijuma ljacomet

repo: gradle/gradle

license_type: permissive

license_source: github-api


text:
The --java-version option doesn't prevent "gradle init" from entering interactive mode, as expected

Current Behavior
The gradle init --java-version option doesn't work as expected since gradle still enters the interactive mode and ask for the Java version (which defeats the purpose of this option)
Expected Behavior
When the --java-version option is used, gradle init should not enter interactive mode to ask for the Java version
Context (optional)
No response
Steps to Reproduce
Everything to reproduce is described in details here
https://github.com/gradle/gradle/issues/26598#issuecomment-1869513296
Gradle version
8.5
Build scan URL (optional)
No response
Your Environment (optional)
The most important info about the environment are  described in the link provided above through SDKMAN commands

Some more info to help debug.
When using the --java-version option, grade not only asks (in interactive mode) for the "Java version" but also for the "new API" question. When you provide a value through stdin gradle doesn't enter interactive mode at all, even though only one answer is provided.
The command below does not enter interactive mode
echo 'no' | gradle init --type java-application --dsl groovy --project-name s3onezoneexpress --package com.teevity.sandbox.s3onezoneexpress --test-framework junit-jupiter

Not sure how this can help but as it doesn't seem very consistent, it probably does

I can confirm this issue with Gradle 8.5.

Thank you for providing a valid report.
The issue is in the backlog of the relevant team and is prioritized by them.

This indeed should skip interactive mode, I'll take a look.

This was already fixed by https://github.com/gradle/gradle/pull/27408 which is part of 8.6 RC1.

authors: SimonScholz cobexer nfonrose


text:
TestKitFunctionalTestSpockBuildCache Sample Never Hits The Cache If The Output Is A Directory

Specific build commands run in a specific sequence in a command line build results in cache hits for a custom task as and when expected. Yet those exact same build commands run in the exact same sequence programmatically in a Spock/TestKit functional test, fail to produce build cache hits for the exact same task code that successfully produces cache hits from the command line.

This issue has led me to suspect that there could be some kind of defect either in TestKit or the User Guide's sample code.
Expected Behavior

FROM_CACHE outcome
Current Behavior

UP_TO_DATE outcome
Context

I'm working on a custom @CacheableTask for a custom plugin.

I am trying to accomplish the automation of functional testing for that @CacheableTask.
The task has @Inputs and @Outputs, etc. More specifically, it has a directory that is annotated as an @OutputFile. In normal operation I can build the project directly from the command line and get cache hits under the expected conditions. For example, I can do:

gradle build and get an UP_TO_DATE outcome.

rm -fr to delete the output directory or just do a gradle clean build and I get the expected FROM_CACHE outcomes whenever I want.

Steps to Reproduce

Here is a self-contained custom plugin project with a cacheable task. It contains a Spock/TestKit functional test in which the reported issue occurs.

The steps that led me to the issue are:

I copied the sample Groovy code to a file within my existing project.

I copied the plugin DSL block, the dependency block, the task configuration, etc., from my project's build.gradle

I pasted that into the User Guide sample test's buildFile

I followed the User Guide's instructions to the letter

Your Environment

Java 11
Gradle version 5.3.1
Linux

Due to Privacy concerns, I'd rather not publicize the information build scans reveal.

@lingocoder Thank you for reporting. I did run the test locally, and for the first run I saw this in the info log:
Caching disabled for task ':execjar' because:
  Gradle does not know how file 'jaxrs.out' was created (output property 'watchOutDir'). Task output caching requires exclusive access to output paths to guarantee correctness.

So caching was disabled since something else placed the jaxrs.out file in the output directory. The task itself didn't work on my machine with this message:
Task ':execjar' is not up-to-date because:
  No history is available.
Cannot run program "java": error=2, No such file or directory
java.io.IOException: Cannot run program "java": error=2, No such file or directory

The task does not fail though... It probably also doesn't create any output, that's why it is up-to-date on the second run.
All in all, this doesn't seem to be a problem with testkit.

Hey Thanks @wolfs for investigating that. And thanks for keeping me in the loop.

...The task itself didn't work on my machine...

Thanks. When did you clone/download it by the way? There have been a lot of changes since I first reported this a few months ago. But I'll investigate and see if I can make it fail the way it did on your machine.
Do you remember what you did to make it fail?

authors: lingocoder wolfs


text:
Add 'org.gradle.jvm.environment' attribute

Implementation of #15430

@bot-gradle test this

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

@bot-gradle test this

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

@bot-gradle test this

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

@bot-gradle QF

Sorry I don't understand what you said.
Currently I support the following commands:

@bot-gradle test {BuildStage} to trigger a build

e.g. @bot-gradle test SanityCheck plz
SanityCheck/CompileAll/QuickFeedbackLinux/QuickFeedback/ReadyForMerge/ReadyForNightly/ReadyForRelease are supported
test this means test ReadyForMerge
SanityCheck can be abbreviated as SC, ReadyForMerge as RFM, etc.

@bot-gradle help to display this message
@bot-gradle clean to clear the conversation history

@bot-gradle test QF

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

@bot-gradle test QF

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

source: gharchive/pull-request

authors: bot-gradle jjohannes


text:
Reproduce issue with parallel project configuration

Fixes #?
Context

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

Your PR is queued. See the queue page for details.

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

authors: big-guy bot-gradle


text:
Remove remaining internal-android-performance-testing sources

This project was removed some time ago, but build.gradle.kts was not removed.

@bot-gradle test and merge

I've triggered a build for you.

authors: asodja bot-gradle


text:
Lazily evaluate git commit id

So it isn't a configuration input anymore.
I tried it locally and doing a commit did not invalidate the configuration cache state any more.

@bot-gradle merge

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

authors: bot-gradle wolfs


text:
Fix accidentally introduced org.gradleinternal package

The types here should have gone into org.gradle.buildinit.plugins.internal.maven instead. The change was likely introduced in https://github.com/gradle/gradle/pull/16248.
Reviewing cheatsheet
Before merging the PR, comments starting with

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

This was not accidental it seems, see @jjohannes response https://github.com/gradle/gradle/pull/16248#issuecomment-2175847402
That also explains failing tests, since classes are loaded in a different classloader.

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle clean

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle clean

@bot-gradle help

Currently, the following commands are supported:
@bot-gradle test <BuildTrigger1> <BuildTrigger2> ... <BuildTriggerN> [without PTS]
Add without PTS to run the build with full test coverage.

A trigger is a special build for this PR on TeamCity, common triggers are:

SanityCheck/CompileAll/QuickFeedbackLinux/QuickFeedback/PullRequestFeedback/ReadyForNightly/ReadyForRelease
Shortcuts: SC/CA/QFL/QF/PRF/RFN/RFR
Specific builds:

BD: BuildDistributions/BuildDocs so that you can preview the generated docs/distribution.
PT: PerformanceTest, all performance tests for Ready For Nightly stage.
APT: AllPerformanceTest, all performance tests, including slow performance tests.
AST: AllSmokeTestsPullRequestFeedback
AFT: AllFunctionalTestsPullRequestFeedback
ASB: AllSpecificBuildsPullRequestFeedback
ACC: AllConfigCacheTestsPullRequestFeedback
ACT: AllCrossVersionTestsReadyForNightly
AFTN: AllFunctionalTestsReadyForNightly
ACTR: AllCrossVersionTestsReadyForRelease
AFTR: AllFunctionalTestsReadyForRelease

@bot-gradle squash

Squash the current pull request into a single commit. The squash message will come from the pull request body, with:

All Signed-off-by: lines kept.
All authors being Co-Authored-By:

@bot-gradle merge

Enqueue this PR into GitHub merge queue for merging.

GitHub will create a merge commit from your PR branch HEAD and the target branch
A GitHub Merge Queue Check Pass build will be triggered on the merge commit
When the build passes, the target branch will be fast-forwarded to this merge commit (i.e. merge the PR)

@bot-gradle squash and merge

Squash the current pull request into a single commit as described in squash command above,
then enqueue this PR into GitHub merge queue as described in merge command above.

@bot-gradle cherrypick to <branch>

Cherrypicks the current PR to another branch.
A new PR will be created and a build will triggered automatically if there is no conflict.

@bot-gradle cancel

cancel a running build in GitHub merge queue and remove the PR from the queue

@bot-gradle clean

clear the conversation history

@bot-gradle help

display this message

To run a command, simply submit a comment.  For detailed instructions see here.

@bot-gradle test this without PTS

I've triggered the following builds with parameters: -DenablePredictiveTestSelection=false for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle clean

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle clean

One way I found that it's possible to make this work is by filtering a package out of Gradles cores classpaths, see https://github.com/gradle/gradle/pull/29591/commits/9139c5f77d30b0a7d37b87a504f853d23b12d5d0

Explanation from @ghale

Gary Hale
I think this is reasonable.  The problem is that the Maven2GradleWorkAction class is getting loaded from the Gradle runtime classloader hierarchy rather than the worker classloader, meanwhile the maven Settings object is getting loaded from the worker classloader (because it is not visible through the filter between classloaders).  These need to be loaded from the same classloader, wherever it is.  Your solution blocks Maven2GradleWorkAction from getting loaded through the filter between classloaders, which is fine, I think. The other option would be to poke a hole for the maven Settings object, but that seems like it cause problems elsewhere.  Yet another option would be to not pass a Settings object in the parameters object, but to pass something else that can be transformed into a Settings object in the work action, but that feels pretty ugly, too.

This is a general problem with WorkAction objects inside the Gradle codebase, but isn't a problem for 3rd party objects.  We could probably solve this more generally by creating a better filter between classloaders such that it could only reach public api stuff or something, but I imagine that would open an enormous can of worms.  Or, I wonder if it would be enough to just always prevent the work action and parameters object from being loaded through the filter?  Dunno what problems that might create.  What you've done is probably fine, but it could get us in trouble if, say, a 3rd party plugin is loading a MavenProjectsCreator or something else (which would be a public api violation, but would still break builds).

I suppose another option would be to somehow recognize that the work action and parameters object are in the Gradle runtime classloader hierarchy and use the runtime classloader to deserialize the parameters object.  I don't know if that would cause problems for other work actions or not.

The problem is that we are referencing a non-Gradle object in a parameters object that is in the Gradle runtime.  So, if the action/parameters and everything the parameters object references are in the Gradle runtime classloader, all good.  If the action/parameters object and everything the parameters object references are all outside of the Gradle runtime classloader (i.e. in a plugin classloader), all good.  If the action/parameters object are outside of the Gradle runtime and reference something in the Gradle API, also all good.  But if the action/parameters object are in the Gradle runtime classloader and reference something outside of the "Gradle API" (like maven) then there's a problem because the API filter blocks it from being accessed from the worker classloader when we are deserializing the parameters object.

The merge queue build has failed. Click here to see all failures.

authors: asodja bot-gradle lptr


text:
[Bug] Datasource secret reference not working

Describe the bug
I've been following this document: https://grafana-operator.github.io/grafana-operator/docs/examples/datasource_variables/readme/ to create datasource and refer the token created in a kubernetes secret (deployed in same namespace).
Version
Full semver version of the operator being used- v5.0.0-rc2
To Reproduce
Steps to reproduce the behavior:

Install Grafana operator and Grafana external instance
Create a Grafana datasource as below:

apiVersion: grafana.integreatly.org/v1beta1
kind: GrafanaDatasource
metadata:
  name: sentry-ds1
  namespace: monitoring
spec:
  valuesFrom:
    - targetPath: "secureJsonData.authToken"
      valueFrom:
        secretKeyRef:
          name: "my-secrets"
          key: "sentry_org_token"
  instanceSelector:
    matchLabels:
      dashboards: dashboarding
  datasource:
    name: sentry-ds1
    access: proxy
    editable: false
    jsonData:
      url: https://sentry.io
      orgSlug: 'my-org'
    secureJsonData:
      "authToken": ${sentry_org_token}
    type: grafana-sentry-datasource

Define K8s secret:

apiVersion: v1
stringData:
  sentry_org_token: MY--RANDOM--TOKEN==
kind: Secret
metadata:
  name: my-secrets
  namespace: monitoring
type: Opaque

See error

message: |
      GrafanaDatasource/monitoring/sentry-ds1 dry-run failed, error: failed to create typed patch object (monitoring/sentry-ds1; grafana.integreatly.org/v1beta1, Kind=GrafanaDatasource): .spec.valuesFrom: field not declared in schema
    reason: ReconciliationFailed

Expected behavior
The datasource should be created with secret defined in my-secrets and it should not complain about schema as I've taken the example from docs.
Suspect component/Location where the bug might be occurring
While creating the datasource - while referring the k8s secrets.
Screenshots
If applicable, add screenshots to help explain your problem.
Runtime (please complete the following information):

OS: [e.g. Linux,Fedora,Mac] - Linux
Grafana Operator Version [e.g. v5.0.0]  v5.0.0-rc2
Environment: [e.g Openshift,Kubernetes,minikube etc. please specify versions] Kubernetes
Deployment type: [e.g running the operator locally, or deployed] Running operator locally
Other: [Other variables/things that might be relevant to this bug, versions of other services e.g. operator-sdk]

Additional context
I'm using kustomize to sync the Grafana objects. These object (dashboards or datasources) can be created in any given namespace hence I should not set the reference in Grafana object. I've been testing this use case from last one month and observed following:

Datasource are not easy on reading K8s secrets - even deployed in same NS
It should not complaints about schema (already example is given)
Update in datasource or secret will break the datasource
I've tried following but even this does not work with secret grafana-os-credentials deployed and ready.

# deploy on bakery grafana
apiVersion: grafana.integreatly.org/v1beta1
kind: GrafanaDatasource
metadata:
  name: sentry-datasource1
  namespace: monitoring
spec:
  secrets:
    - grafana-os-credentials
  instanceSelector:
    matchLabels:
      dashboards: dashboarding
  datasource:
    name: sentry-datasource1
    access: proxy
    editable: false
    jsonData:
      url: https://sentry.io
      orgSlug: 'my-org'
    secureJsonData:
      authToken: ${SENTRY_ORG_TOKEN}
    type: grafana-sentry-datasource

Any hint would be great.

It seems the feature was added here but still not working for me. Am I missing anything?

@rajeevsh990 You're simply trying to use syntax that was introduced in a newer version of the operator. The PR you're referring to is part of v5.0.0-RC3). Though, I'd recommend to install something newer like v5.1.0 to avoid hitting some bugs.

Thankfully I found it and it worked.

repo: grafana-operator/grafana-operator


text:
Update the Ansible doc to use the alloy role instead of Agent

PR Description
Which issue(s) this PR fixes

Notes to the Reviewer
PR Checklist

[ ] CHANGELOG.md updated
[ ] Documentation added
[ ] Tests updated
[ ] Config converters updated

This topic is still hidden for Alloy. It will be published in Alloy docs soon.

authors: clayton-cornell ishanjainn

repo: grafana/alloy


text:
Allow clientId and tenantId hint when using workload identity

Workload identity supports the usage of multiple identities in the same pod. This PR attempts to add support for it.

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

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

@aangelisc As far as I know, this is already usable when using the new format with azureCredentials, unless the datasource does some validation on the jsonData. I am happy to update the documentation if you could point me to the relevant repository.
The question is if this should be supported with the legacyCredentials via the getFromLegacy function?

Did you consider security implications?
My concern that this may give ability to probe other identities in the Kubernetes cluster even if they aren't supposed to be used by Grafana and belong to other services hosted in the same cluster.
For this reason TenatID and ClientID were added to Grafana config (here), so they are not accessible by user.

I did. Security is actually the main driver for this. We have different teams that use the Azure Monitor datasource. We want to manage the datasources for them to restrict the scope and subscriptions that the datasource has access to, so each of them should use a separate ManagedIdentity. Today, this is possible with multiple ServicePrincipals, but not with ManagedIdentities. The issue with using ServicePrincipals is then lifecycle management of the ClientSecret.
Probing for other managed identities would not work since the FederatedIdentityCredential you create is tied to the subject claim of the Grafana ServiceAccount.

@nilfr ideally the data sources would need to be updated to provide the client ID and tenant ID of the identity via the UI to make this functionality more accessible (otherwise it will only be usable via provisioned data sources).
@kostrse this functionality looks good to me and I'm happy to add this to the SDK if you see no issues with it.

@aangelisc I have updated the branch, I can look into submitting a PR for the UI once this is merged.

Apologies for this falling through the cracks! I've merged main to allow me to merge this

@aangelisc Anything I can do to help get a tag and a release for this, so that we can add this to grafana/grafana?

Hi @nilfr! There are a couple things I'm trying to get merged and then I'll cut a new release (hopefully this week).

Hi @nilfr, apologies for the delay, I've published a new version of the SDK now 😊 Thanks again!

authors: CLAassistant aangelisc kostrse nilfr

repo: grafana/grafana-azure-sdk-go


text:
Please add support for Windows as OS

Currently the profiler only supports running Dotnet applications on Linux but being able to also profile them while running on windows would be quite nice, since a lot of people probably run dotnet apps on Windows using IIS.
The README.md mentions that this profiler is based on https://github.com/DataDog/dd-trace-dotnet which seems to support  Windows as OS. Source: https://docs.datadoghq.com/profiler/enabling/dotnet?tab=windows#requirements
Thanks a lot

+1

+1

+1

I want to add pyroscope to windows but the docs only show how to configure for linux.
Investigating these repos, I'm trying to understand how this issue relates to this one in the main pyroscope repo.  Is there a way to compile pyroscope for windows and its just not currently distributed?

Yes! This feels like a MASSIVE missing feature. Profiling desktop apps on windows would be great.

authors: giard-alexandre gmkado mhascak ntimo tkononowiczsolwit yahyaozturk

repo: grafana/pyroscope-dotnet


text:
QueryVariable: Display error notice when query variable fails

In core Grafana, we show an alert when a query variable encountered a failure. We should add an error indicator to a variable dropdown in scenes so that users can identify errors.

@dprokop I think this is implemented?

authors: dprokop torkelo

repo: grafana/scenes


text:
Dbt and postgres connectors

Draft flow to create a DBT and postgres connected grai server from Jaffle Shop Data

If you want to add this compose file  it will spin up all of a server, frontend, and DB all in one. This way you can skip the "get grai running step" as well.
version: "3.7"

services:
  server:
    image: ghcr.io/grai-io/grai-core/grai-server:latest
    ports:
      - 8000:8000
    environment:
      - DB_HOST=db
      - DB_PORT=5432
      - DB_NAME=docker
      - DB_USER=docker
      - DB_PASSWORD=docker
      - DJANGO_SUPERUSER_USERNAME=null@grai.io
      - DJANGO_SUPERUSER_PASSWORD=super_secret
    depends_on:
      - db
  db:
    image: postgres:14.3-alpine
    environment:
      - POSTGRES_USER=docker
      - POSTGRES_PASSWORD=docker
      - POSTGRES_DB=docker
    ports:
      - 5432:5432
    healthcheck:
      test: "pg_isready -U docker"
      interval: 2s
      timeout: 2s
      retries: 15
  frontend:
    image: ghcr.io/grai-io/grai-core/grai-frontend:latest
    ports:
      - 3000:80

Yep makes sense, I will work it in.

authors: TonyLLondon ieaves


text:
RAMJobStore not loading at startup

The error indicates that the RAMJobStore tables are not created at startup.  I'm using Grails 3.1.1.  I tried plugin version 2.0.5 - 2.0.8 with the same failure.  Plugin version 2.0.4 is working.  Appreciate your help with this.
ERROR org.springframework.boot.SpringApplication - Application startup failed
org.springframework.context.ApplicationContextException: Failed to start bean 'quartzScheduler'; nested exception is org.springframework.scheduling.SchedulingException: Could not start Quartz Scheduler; nested exception is org.quartz.SchedulerConfigException: Failure occured during job recovery. [See nested exception: org.quartz.impl.jdbcjobstore.LockException: Failure obtaining db row lock: Table "QRTZ_LOCKS" not found; SQL statement:
SELECT * FROM QRTZ_LOCKS WHERE SCHED_NAME = 'quartzScheduler' AND LOCK_NAME = ? FOR UPDATE [42102-190] [See nested exception: org.h2.jdbc.JdbcSQLException: Table "QRTZ_LOCKS" not found; SQL statement:
SELECT * FROM QRTZ_LOCKS WHERE SCHED_NAME = 'quartzScheduler' AND LOCK_NAME = ? FOR UPDATE [42102-190]]]

The same issue confirmed.

I don't understand, RAMJobStore tables? It's look like you enable JDBCStore, for JDBCStore you need to create tables by self.

I can also confirm this issue.
My configuration:
quartz:
    jdbcStore: false
    autoStartup: true

authors: AlexKovynev PatrickHuetter arjangch coaxcable

repo: grails-plugins/grails-quartz

license_source: bigquery


text:
Created app should use groovy gradle styling

Current app looks like Kotlin and adds a bunch of unnecessary characters.
Not sure why this happened, but if we are going to keep this route we should also add semi-colons to every line.
dependencies {
    implementation("org.grails:grails-core")
    implementation("org.grails:grails-logging")
    implementation("org.grails:grails-plugin-databinding")
    implementation("org.grails:grails-plugin-i18n")
    implementation("org.grails:grails-plugin-interceptors")
    implementation("org.grails:grails-plugin-rest")
    implementation("org.grails:grails-plugin-services")
    implementation("org.grails:grails-plugin-url-mappings")
    implementation("org.grails:grails-web-boot")

Formatting should be the same as it always has been:
dependencies {
    developmentOnly "org.springframework.boot:spring-boot-devtools"
    compileOnly "io.micronaut:micronaut-inject-groovy"
    console "org.grails:grails-console"
    implementation "org.springframework.boot:spring-boot-starter-logging"
    implementation "org.springframework.boot:spring-boot-starter-validation"
    implementation "org.springframework.boot:spring-boot-autoconfigure"
    implementation "org.grails:grails-core"
    implementation "org.springframework.boot:spring-boot-starter-actuator"
    implementation "org.springframework.boot:spring-boot-starter-tomcat"

centralize dependency versions in gradle.properties so they are not repeated multiple times.

or bonus points if you use Strings instead of GStrings

FYI... I think the examples you cited are indeed Strings.  I don't think Groovy creates GStrings for something like "org.grails:grails-console".  I think the compiler knows that is a String.

or bonus points if you use Strings instead of GStrings

FYI... I think the examples you cited are indeed Strings. I don't think Groovy creates GStrings for something like "org.grails:grails-console". I think the compiler knows that is a String.

If that is the case, I prefer double quotes.
implementation "org.springframework.boot:spring-boot-starter-logging"

It's obviously a personal preference, but for what it's worth, I prefer single quotes as it helps my brain distinguish between String and GString without having to check. Also, again my opinion, single quotes take up less space, which makes the code easier to read.

@matrei I agree, but knowing now it always compiles to a String changed my perspective because

The build file no longer has uniform formatting
If you want to add a dynamic version, you have to edit both quotes as opposed to just add the version.

assert "Test" instanceof String
assert "Test" instanceof GString  // <-- Fails

The build file no longer has uniform formatting

That's part of the feature, I don't have to actively check if there is a variable in the string when reading/scanning the code.

If you want to add a dynamic version, you have to edit both quotes as opposed to just add the version.

This is the drawback, but with Alt+Enter+Enter in Intellij you can toggle between GStrings and String syntax easily.
Are we optimizing for reading or writing? I think every little thing that brings clarity and simplifies reading helps out.

You need double quotes for versions from gradle.properties.
If we want them to match, double quotes would be the way to go.  With the grails-bom expansion, these are rarer, but there will be a few in a normal Grails apps.
Some examples from one of my projects:
implementation "io.awspring.cloud:spring-cloud-starter-aws:$springCloudStarterAWSVersion"
implementation "io.awspring.cloud:spring-cloud-starter-aws-parameter-store-config:$springCloudStarterAWSVersion"
implementation "com.sendgrid:sendgrid-java:$sendGridVersion"

implementation "com.google.api-client:google-api-client:$googleApiClientVersion"
implementation "com.google.auth:google-auth-library-oauth2-http:$googleOauth2Version"
implementation "com.google.maps:google-maps-services:$googleMapsServicesVersion"

I've spent a lot of time thinking about this and I now advocate for double quotes.
My rational is for consistency across the entire file and still accomodate situations that need GStrings. It is also from the perspective of clarity for people that are not fluid in the Groovy language.
Previously I adopted the Groovy purist perspective where '' was always used for Strings, but considering the fact Groovy has lost a lot of popularity and has tried in several ways to be more like java over the past 5 years, I think it is better to preference java like constructs when the groovy equivalent does not provide any gains.  This is more to eliminate any confusion to someone new to the Groovy language.

Sounds like the majority favors double quotes ☺

lol, I still like single quotes, but if Groovy isn't going to have a purist mentality when it compiles double quotes into  Strings, why should I?

authors: codeconsole jamesfredley jeffscottbrown matrei

repo: grails/grails-forge


text:
Hide featured comments on YouTube

Link: https://www.youtube.com/watch?v=sbwfpTNVFjM

I've tried before, but I've given up on Facebook/Instagram. The names they assign elements are very dynamic, so it's tough to block comments over the long run. A lot of other sites, like YouTube, just assign a nice ID of "comments", or at least something predictable and stable.. makes life much easier!

If you update the definitions for the addon, the featured/teaser comment should be blocked now too.

authors: grantwinney spacecowgoesmoo

repo: grantwinney/hide-comments-everywhere

license: MIT


text:
tgt_emb_as_output_layer config parameter

❓ Questions and Help
I do not understand tgt_emb_as_output_layer parameter.
    tgt_emb_as_output_layer: bool, default=False
        When this option is set ``True``, the output projection layer(It is used to project RNN encoded # noqa
        representation to target sequence)'s weight will be shared with the target vocabulary's embedding. # noqa

For some example, I see it is set to TRUE while for some it is False.
Can anyone please explain this parameter?

This is determined according to the specific experimental results.

@AlanSwift not quite sure what you meant? Is it a hyper-parameter then?

Yes. It is a hyper-parameter.

@AlanSwift This is determined according to the specific experimental results Can you please explain?

@AlanSwift when should I set it and why?

@AlanSwift should I set it for a classification task?

You have to tune this parameter. There is no clear conclusion.

authors: AlanSwift smith-co


text:
Remove configurable-assets-bundle

The configurable-assets-bundle was used so we can edit the maps JavaScript code while the server is running(?). However, we were already pointing the bundle override into web/target/classes in config-example.yml and if we change the files there our changes will be reflected in the browser already without the configurable-assets-bundle. Therefore I do not see why we need this?
With this PR we (still) can edit main-template.js or any of the other javascript files of the map client and see the changes after a page reload byrunning npm run watch which will browserify all the files and copy the resulting main.js file to web/target/classes/assets whenever we make a change. Changes to index.html are not reflected and we would need some mechanism that updates index.html in the target folder after making a change to achieve the same effect. In any cas the configurable-resource-bundle would only be beneficial if we pointed it to web/src/main/resources/assets, but I could not make this work and apparently config-example.yml was changed to point to the target folder (maybe for the same reason).

Sorry no, its a bit more complicated than this...
I think we have two:

use the configurable-assets-bundle and point it to src/main/resources/assets. This way the resources are loaded from the location on disk and we can make changes directly. However, the javascript code will not be updated because it is copied to target/classes/assets by npm run watch. We could fix this by adjusting the watch script maybe. At least in theory. When I tried this I still did not see updates probably because Dropwizard was still reading the main.js file from target/classes/assets. Basically it reads from both paths and things get complicated.

remove the configurable-assets-bundle and always read from target/classes/assets. Since our npm run watch command compiles and copies our javascript to target/classes/assets anyway we will see our changes of the java script code. However, we do not see changes of the index.html file, because npm run watch does not copy it to the target folder (but we could add something like this to the watch script).

To me it does not seem to be worth the extra plugin and configuration (and further changes) just to be able to hot-reload index.html. Also there are better ways to do this. For example running a separate hot-reloading server from the assets folder. There is not really a need to serve GH maps from the GH server while developing the UI.

It is not only index.html but likely also any change to the css file or icon etc (?)
We can surely do this change, but we need a documented and working way to develop the UI. Maybe we decouple developing the UI as you suggested and serve the UI e.g. via http-server? (for the end product this won't be required as we bundle it in the maven build)

It is not only index.html but likely also any change to the css file or icon etc (?)

Yes. npm run watch bundles and copies the javascript files to target/classes/assets, while all the static files like *.css, index.html, image files etc. simply remain in src/main/resources. Actually I think this is where most of the confusion comes from. Why do we copy the bundled file (main.js) to target/classes/assets manually? This should be done by maven instead. Maven does this just like it does for index.html etc.

We can surely do this change, but we need a documented and working way to develop the UI. Maybe we decouple developing the UI as you suggested and serve the UI e.g. via http-server? (for the end product this won't be required as we bundle it in the maven build)

Yes there are many options. If we fix the paths in package.json (see my last commit) we can already get 'hot reload' without the configured assets bundle. It can be done like this:

npm run watch # this bundles the javascript files and updates main.js (in src/main/resources) whenever we change a javascript file
start the GH server in debug mode
make changes to static resources, javascript (or even Java files)
in IntelliJ: run -> debugging actions -> reload changed classes
refresh your browser window

This works and we can apply changes to all files (even Java), but the hot reload is rather slow and we need to manually refresh the browser. Therefore a better option (in case we are only developing the UI) is this:

start the GH server (say on port 8989 which is the default)
npm install -g live-server
npm run watch (as before)
in web/src/main/resources/assets/js/options point GH maps to your local GH server using this line: routing: {host: 'http://localhost:8989', api_key: ''}
cd web/src/main/resources/assets && live-server # this will serve GH maps from this folder from port 8080 by default

This way we can develop GH maps and we do not even have to reload the browser page, but it will reload automatically if we focus the browser window.
My favorite solution for this, however, is using VSCode with the Live Server plugin. It works the same way except that we do not run live-server from the command line but simply start live server for the assets folder from VSCode. I like this better because the browser window reloads even without focusing the browser and we can just keep developing and watch our changes on another screen for example. I don't know why this works and does not work with the live-server package from npm.

Actually I think this is where most of the confusion comes from. Why do we copy the bundled file (main.js) to target/classes/assets manually?

Not sure I understand this. We do not copy main.js manually IMO, we create it from the other JS files and put it into the target folder so that it gets served and live editing works. How would maven help us here?
Or do you mean why we put main.js into target/.. and not src/..? I think the problem is that main.js is not really a source and so we do not want it in our git repo. Ok, we could ignore it via git but it still would feel strange to me as the sources and main.js will then be mixed.

Yes there are many options

I would describe a solution that can be used with any editor like with live-server (or even http-server as I would not care too much that I have to reload to see changes -> this is necessary in the current situation too).

in web/src/main/resources/assets/js/options point GH maps to your local GH server using this line

Why is this necessary? Isn't this possible to do with the npm watch command?

Not sure I understand this. We do not copy main.js manually IMO, we create it from the other JS files and put it into the target folder so that it gets served and live editing works. How would maven help us here?

Maven copies resource files to the target folder as part of our 'build'. If we copy main.js to target we 'manually' interfere with this build system. This is why the hot reload does not work properly: If we start e.g. the GH server from IntelliJ it tries to simulate our build (maven), but once we manipulate the target folder some other way (e.g. by running npm run watch which copies a file (main.js) to target that does not exist in src) there is confusion because the files in target and src are no longer in sync.

Or do you mean why we put main.js into target/.. and not src/..? I think the problem is that main.js is not really a source and so we do not want it in our git repo. Ok, we could ignore it via git but it still would feel strange to me as the sources and main.js will then be mixed.

No we should not add main.js to src (as it was some time ago). Still, I think browserify/watchify should create the file in src (and we should leave it up to maven to copy it to target). Its true its not a source file in the sense that we write it ourselves, but it is a source file in the sense that it is something maven should find and add to our build target. The fact that we use browserify to build  the main.js file from some other js files is just an implementation detail so to say. For maven the only important thing is that this file exists and that it should be added to the jar. To do this in a really clean way I would even argue that the 'source' javascript files should not go into src/main/resources, because they are just 'source' files for main.js and should not go to the jar.

I would describe a solution that can be used with any editor

Yes I was also hesitant to mention another tool. live-server would be ok probably because we need to install node anyway. Do you mean python http.server? So far we have no python dependencies and on Windows its probably not installed by default? I would prefer live-server also because of the automatic reload.

I would not care too much that I have to reload to see changes

You should really give it a try, I think its very useful (but only if you do not even have to focus the browser as with the VSCode live-server plugin) :)

Why is this necessary? Isn't this possible to do with the npm watch command?

Hm the npm watch command only re-creates main.js from the js files whenever there is a change. But once we serve GH maps from some server other than the GH server (e.g. using live-server or http.server) we have to set the url of the GH server or how else should the routing requests end up in the right place?

I updated the docs mentioning both the IntelliJ and the live-server methods.

Maven copies resource files to the target folder as part of our 'build'

Do you mean IntelliJ? I mean, for maven the build process is already working, but here we need to copy the main.js file to target whenever there is a change and this is not something that maven does for us (?)

To do this in a really clean way I would even argue that the 'source' javascript files should not go into src/main/resources, because they are just 'source' files for main.js and should not go to the jar.

Probably the most correct place (in maven-terms) for main.js would be target/generated-sources?

do you mean python http.server

I meant http-server from npm

only if you do not even have to focus the browser as with the VSCode live-server plugin) :)

Ah, I think I only know this from deck.gl and this "late auto reload" was quite ugly and not really a time safer.

But once we serve GH maps from some server other than the GH server

Ok, understood

Do you mean IntelliJ?

No I meant maven, but well, its kind of the same thing. Maven (run from the command line) builds and copies to target folder (and adds the same files to the jar). But IntelliJ simulates the same as it adds all the files to the classpath when e.g. starting the server.

I mean, for maven the build process is already working, but here we need to copy the main.js file to target whenever there is a change and this is not something that maven does for us (?)

No! If we change main.js in src/main/resources and reload the classes in intellij the updated file is refreshed in the classpath of the running server as well. If we copy main.js to target/assets in theory we do not need to reload the classes, but then we have inconsistent behavior, because things aren't like they are expected to be. Or to put it the other way around. Assuming we put it into target/assets at which folder would you point the configurable assets plugin? If we point it to target/assets we no longer get live updates for index.html and if we point it to src/main/resources we no longer see updates of main.js.

Probably the most correct place (in maven-terms) for main.js would be target/generated-sources?

main.js is a non-Java file that is supposed to be added to the class path so it should be in src/main/resources IMO. We should not touch the target folder at all. The target folder is just maven's output folder. And like I said if anything then we should move the javascript 'source' files out of src/main/resources because they are not resources.

I meant http-server from npm

Ah ok, but its probably similar. Hm I like the live reload of live-server but never tried http-server. Personally I would use VSCode with the live server plugin anyway for the reasons I mentioned earlier.

Ah, I think I only know this from deck.gl and this "late auto reload" was quite ugly and not really a time safer.

Ok :)

Should we do smaller steps and:

make browserify create main.js in src/main/resources
add main.js to .gitignore
keep the plugin for now and point it to src/main/resources

This way we can move on with #2237 and keep the same workflow for now (and it will actually work in contrast to current master).

Ok, have made some minor changes to make it working with live-server

Ok :) What do you mean with 'late' reload?

The browser reload only happened when I viewed/focussed the browser window. So not much faster then quickly switching app windows+F5.
btw: it seems that live-server sometimes reloads it immediately and sometimes requires the focus. Maybe I did something wrong.

Just for later reference. We now removed the configurable-assets-bundle and build main.js in src/main/resources for now. Hot-reload can be achieved either using IntelliJ reload classes or the npm live-server package. See docs for instructions.
Later we should think about:

moving javascript sources to src/main/js or similar so they do not end up in the jar and also live-server does not get triggered multiple times.
creating main.js in yet another location, because its not really a source file...

authors: easbar karussell

repo: graphhopper/graphhopper


text:
Fix for issue 546

Improve bicycle waytype classification for a bicycle=  tag on roads.

I have no idea why travis is failing with JDK8, I don't think that it is related to the changes.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project graphhopper: Unable to generate classpath: org.apache.maven.artifact.resolver.ArtifactResolutionException: Unable to get dependency information for org.apache.maven.surefire:surefire-junit4:jar:2.18.1: Failed to retrieve POM for org.apache.maven.surefire:surefire-junit4:jar:2.18.1: Could not transfer artifact org.apache.maven.surefire:surefire-junit4:pom:2.18.1 from/to central (https://repo.maven.apache.org/maven2): Connection reset

Very strange. The tarvis failure disappeared.

Sorry, I just restarted it without a comment here.

Thanks, merged after clarification in #546

authors: karussell ratrun


text:
Add time-ms yUnitSystem parameter for displaying millisecond values

Shows values in milliseconds, scaling to seconds, minutes, hours, days and years.

#1220 took care of this

repo: graphite-project/graphite-web


text:
Subscription: Exception while fetching data

Hello,
When I want to run the subscription stockQuotes I get the following error:
"message": "Exception while fetching data (/stockQuotes/stockCode) : Expected source object to be an instance of 'subscription.resolvers.StockPriceUpdate' but instead got 'io.reactivex.internal.operators.flowable.FlowableFilter'"
Can someone explain what I'm doing wrong?
Thanks!

This is when you just run the example as is?

Yes, I just copied the code.

Ok, that's not good. Will take a look at it later, thanks for reporting.

Making the method Publisher<StockPriceUpdate> stockQuotes(List<String> stockCodes) public should fix it for now. Issue will be fixed in next release of graphql-java-tools. Caused by bug https://github.com/graphql-java/graphql-java-tools/issues/182.

authors: oliemansm rvanrees

repo: graphql-java/graphql-spring-boot


text:
Warn when trying to build before having run npm install

This should prevent struggles like this one: http://stackoverflow.com/questions/35096635/error-in-building-graphiql/35470669#35470669

tl;dr: if you don't npm install before running npm run build, then the build will use any old version of Babel that it can find (say… version 6, installed globally).

This makes sense. I'll look into upgrading babel to the latest, but nonetheless this seems like a good warning. Thanks!

authors: asiandrummer steveluscher

repo: graphql/graphiql


text:
silently skip emails when we don't have an address

This is a fix for #3343.

Alternate to #3345.

I considered skipping the sleep call when we don't actually make an API call, but if I'm reading the rest of the email infrastructure right that wouldn't actually speed up queue processing at all. It looks like we call dequeue_mails every 60 seconds with max 60 messages, so even if we only mailed 30 of them, we would still wait another ~30 seconds until proceeding to the next batch.

Apparently I botched that first commit. Oh well. :-/

Ready for review @rohitpaulk @Changaco et al.

It looks like we call dequeue_mails every 60 seconds with max 60 messages, so even if we only mailed 30 of them, we would still wait another ~30 seconds until proceeding to the next batch.

That could change in the future, so I've changed it to only sleep if we're actually making an API call.

Email queue is down to 0 :dancer:

https://twitter.com/Gratipay/status/589073378016899072 :dancer:

license: mit


text:
@griest024 feat(category): add filter type field query to replacement driver

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

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

PR Type
What kind of change does this PR introduce?

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

What is the current behavior?

Category driver makes an uncachable aggregations query to get filter types.
What is the new behavior?
Category driver makes cachable filter type fields query.
Does this PR introduce a breaking change?
[ ] Yes
[x] No

Other information
supersedes #1452  and #1450

This looks pretty good to me. Only thing is that a lot of the factory tests have essentially nothing in them. I'd be ok with either adding the tests or deleting the spec files for those factories

@lderrickable added tests

repo: graycoreio/daffodil


text:
feat(all): upgrade to Angular 13

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

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

PR Type
What kind of change does this PR introduce?

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

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

Upgrade to Angular 13
Other information

need to fix apollo-angular peer deps


text:
feat(design-land): added article component and examples to design-land

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

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

PR Type
What kind of change does this PR introduce?

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

What is the current behavior?

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

Other information

closing in favor of #892 #893 and #894

authors: Nolan-Arnold damienwebdev


text:
Find out why core::float needs explicit exports

core::float imports from fXY::* which in turn re-exports predicates and functions from cmath.
Turns out the predicates somehow do not get exported unless one uses explicit export statements.
This is a bug and it needs to be investigated where this is coming from.

I thought the rule was: "if you dont have any export statement, all gets exported". If there is anything special about predicates, this should go into the spec.

If you don't export anything, everything that is locally defined gets exported, not things that were imported from elsewhere. But maybe that's not what you're referring to here. The code that manages re-exports is young, and might have bugs. Though predicates are just functions, and I don't see a reason why they wouldn't work.

authors: boggle marijnh

repo: graydon/rust


text:
Use a clean git repo in the production search-api.het.io instance

Following #78 & https://github.com/greenelab/connectivity-search-backend/pull/80, I noticed the following unstaged change in the git repo on search-api.het.io:
diff --git a/dj_hetmech/settings.py b/dj_hetmech/settings.py
index 9b9bdd9..691968f 100644
--- a/dj_hetmech/settings.py
+++ b/dj_hetmech/settings.py
@@ -29,7 +29,7 @@ with open(path) as read_file:
 SECRET_KEY = 'secret_not_yet_set'

 # SECURITY WARNING: don't run with debug turned on in production!
-DEBUG = True
+DEBUG = False

 ALLOWED_HOSTS = ['localhost', 'search-api.het.io', ]

This seems problematic to me. If we change settings.py it could cause the git pull --ff-only to fail. There must be a more robust way of setting DEBUG false? For example, by way of an environment variable or other option passed to django? @dongbohu what do you think?

Good point. I think we can set DEBUG and SECRET_KEY in secrets.yml. If they are not found in secrets.yml, default them to:
SECRET_KEY = 'secret_not_yet_set'
DEBUG = True

Do you want to include that in the PR that you are working on now?

Good point. I think we can set DEBUG and SECRET_KEY in secrets.yml. If they are not found in secrets.yml, default them to:
SECRET_KEY = 'secret_not_yet_set'
DEBUG = True

Do you want to include that in the PR that you are working on now?

I created a local branch on serch-api.ht.io, so its local main branch is in sync with the repo. When your changes are merged, git pull --ff-only should be okay.

I created a local branch on serch-api.ht.io, so its local main branch is in sync with the repo. When your changes are merged, git pull --ff-only should be okay.

Good point. I think we can set DEBUG and SECRET_KEY in secrets.yml. If they are not found in secrets.yml, default them to:

I like this idea.

Do you want to include that in the PR that you are working on now?

Would prefer to have this as a separate PR.

When your changes are merged, git pull --ff-only should be okay.

So the instance is currently not on the main branch?

Good point. I think we can set DEBUG and SECRET_KEY in secrets.yml. If they are not found in secrets.yml, default them to:

I like this idea.

Do you want to include that in the PR that you are working on now?

Would prefer to have this as a separate PR.

When your changes are merged, git pull --ff-only should be okay.

So the instance is currently not on the main branch?

I found DEBUG was True in the evening, so I created a new branch and set it
to False, then deployed it on production. We can have deploy it on "main"
branch after this is fixed.
On Fri, Jan 8, 2021 at 10:20 PM Daniel Himmelstein notifications@github.com
wrote:

Good point. I think we can set DEBUG and SECRET_KEY in secrets.yml. If
they are not found in secrets.yml, default them to:
I like this idea.
Do you want to include that in the PR that you are working on now?
Would prefer to have this as a separate PR.
When your changes are merged, git pull --ff-only should be okay.
So the instance is currently not on the main branch?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/greenelab/connectivity-search-backend/issues/81#issuecomment-757086799,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADTOURLNNCR7OS44GCYMLETSY7DQFANCNFSM4V3GRATA
.

I found DEBUG was True in the evening, so I created a new branch and set it
to False, then deployed it on production. We can have deploy it on "main"
branch after this is fixed.
On Fri, Jan 8, 2021 at 10:20 PM Daniel Himmelstein notifications@github.com
wrote:

Good point. I think we can set DEBUG and SECRET_KEY in secrets.yml. If
they are not found in secrets.yml, default them to:
I like this idea.
Do you want to include that in the PR that you are working on now?
Would prefer to have this as a separate PR.
When your changes are merged, git pull --ff-only should be okay.
So the instance is currently not on the main branch?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/greenelab/connectivity-search-backend/issues/81#issuecomment-757086799,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADTOURLNNCR7OS44GCYMLETSY7DQFANCNFSM4V3GRATA
.

I filed a quick PR #82 for this issue.

I filed a quick PR #82 for this issue.

authors: dhimmel dongbohu

repo: greenelab/connectivity-search-backend


text:
RFI prevent certain PRs to be opened when another one already includes the update

Hi,
I was wondering if there was a way to prevent greenkeeper bot from opening a PR  when there is another PR opened with this packaged already updated to the right version (any other PR).
Cheers,

Hi there,
Greenkeeper only opens one PR per dependency and then keeps that PR up to date with comments. At least that’s what it should do, I’m not entirely sure what’s going on in your case. Could you link to an example if you have a publicly accessible one, or contact support@greenkeeper.io if it’s private, then I can look at the logs and check what’s up.
Thanks in advance!

I was thinking that other open PRs (not by greenkeeper) in the project could already have the upgraded dependency, but if greenkeeper closes its PR once the other has been merged it is ok. Thanks for your input.

authors: espy plozachm

repo: greenkeeperio/greenkeeper


text:
feat(alias): Alias status to info

Hey :)
I was intuitively looking for a status command. So maybe aliasing it to info would be nice.
Best,
Finn

Hi @finnp, thank you for your contribution! :+1: :relaxed:

Thank you for the slam dunk instant merge! :basketball:  :relaxed:

:rocket: :joy:

authors: christophwitzko finnp


text:
Bump minimum Go version in CI

Caddy requires Go 1.15 or higher

@francislavoie , thank you! 👍

authors: francislavoie greenpau

repo: greenpau/caddy-auth-portal


text:
Some form_builder methods could not be used in my form?

in active_admin/lib/active_admin/form_builder.rb i see
commit_button_with_cancel_link
cancel_link
commit_button
methods
If i use
f.commit_button in my form

=semantic_form_for [:admin, @resource] do |f|
  = f.input :some_field
  = f.commit_button

It works, but when i use commit_button_with_cancel_link , or cancel link i have "undefined method `cancel_link' for #" error.
What is going on ?

First of all, this is a good catch - the implementation of the formtastic extensions is using the old style which is no longer recommended (i.e. subclassing Formtastic::FormBuilder). Which means that it should probably be updated to support the newer version of formtastic. What this means for you is that if your version of Formtastic is at 2.x, it's possible the active_admin defined code for formtastic just won't work right.

+1
I can't use has_many method of ActiveAdmin FormBuilder in a partial view, which i think is very good. Any way to achieve it?

authors: akashkamboj latortuga panSarin


text:
Exceptions aren't translated to Python

For example, playing in the REPL I forgot to close a path:
>>> pco = pyclipper.PyclipperOffset()
>>> pc.AddPath([[0,0], [10,0], [10,10], [0, 10]], pyclipper.JT_ROUND, pyclipper.ET_CLOSEDPOLYGON)
terminate called after throwing an instance of 'ClipperLib::clipperException'
  what():  AddPath: Open paths must be subject.
Aborted (core dumped)

it's possible to declare such functions that may throw a c++ exception with an except +
http://cython.readthedocs.io/en/latest/src/userguide/wrapping_CPlusPlus.html#exceptions
would you like to work on a PR?

authors: anthrotype thatch

repo: greginvm/pyclipper


text:
fix Issue with [:repl-options :init] composability #21

Contains a fix and a working example for https://github.com/greglook/whidbey/issues/21

When I realized that https://github.com/greglook/whidbey/pull/28 fixes https://github.com/greglook/whidbey/issues/21 as well, I merged it.
This branch now contains the solution of cichli in combination with my example.

Thanks for filing this! I'm closing this as the original issue is resolved, and I don't think the example here is necessary to add to the repo.

authors: greglook johannesloetzsch

repo: greglook/whidbey

license: unlicense


text:
How to apply .AdditionalProperties(false) recursively

Environment

Nuget Package: JsonSchema.Net.Generation
Nuget Version: 2.0.1
OS: Win10
.Net Target: Core 6.0

Dear Mr. Dennis!
I would like to add "additionalProperties": false to each level of a JSON Schema. So far, I only managed to apply it on the top-level of the generated Schema:
    public string Generate(Type t)
    {
        SchemaGeneratorConfiguration config = new();
        config.Nullability = Nullability.AllowForNullableValueTypes;
        config.PropertyOrder = PropertyOrder.AsDeclared;
        JsonSchemaBuilder builder = new JsonSchemaBuilder().FromType(t, config);

        builder.AdditionalProperties(false);// TODO shall be applied recursively

        JsonSchema jsonSchema = builder.Build();
        string schema = JsonSerializer.Serialize(jsonSchema);
        return schema;
    }

How to set it recursively?
Many thanks,
Michael :)

Update: I found your class
public class AdditionalPropertiesIntent.
It has a constructor
public AdditionalPropertiesIntent(SchemaGenerationContextBase context)
But i'd expect
public AdditionalPropertiesIntent(bool value)

There's not a built-in way to do this, but I could add an option to control this fairly easily.  Options would be:

Never
Sealed object types
All object types

I might also create an attribute for this.
In the meantime, you have a couple options:

Create and handle the attribute
Create a refiner to add the intent

Instructions for both are in the docs.

The additionalProperties keyword actually takes a schema, of which false is a valid schema that just always fails (and true always succeeds).  Thus, for generation purposes, having a generation context in the constructor is correct.
You can see this in the fluent builder extension method as well:
https://github.com/gregsdennis/json-everything/blob/1c9e3f903e09fc65968f151879fe7eb0d2e0566c/JsonSchema/JsonSchemaBuilderExtensions.cs#L34
That said, I don't currently have a way of representing a false context.  I'll need to set that up.

Hi! I would apprechiate a solution like [ Never Sealed All]. In the meantime i have constructed my own:
internal class NoAdditionalPropertiesRefiner : ISchemaRefiner
{
    public bool ShouldRun(SchemaGenerationContextBase context) => context.Type.IsClass && context.Type != typeof(Version) && context.Type != typeof(string);

    public void Run(SchemaGenerationContextBase context) => context.Intents.Add(new NoAdditionalPropertiesIntent());
}

internal class NoAdditionalPropertiesIntent : ISchemaKeywordIntent
{
    public void Apply(JsonSchemaBuilder builder) => builder.AdditionalProperties(false);
}

Nice.  Glad you found a workaround.

authors: MichaelJachan gregsdennis

repo: gregsdennis/json-everything


text:
Code cleanup

Dead code removal
Conversion of BOOST_FOREACH to range based for loops
Remove DAO RPC commands
Remove thread priorities

I think I will remove the foreach changes in this PR as they cause it to grow out of a comfortable review range.

I don't like that you are removing DAO functionality. But as you say, it can be added back.

Why should BOOST_FOREACH be removed? And what should be used instead?
I use it in new code...
Post that removed commits somewhere or just provide the hash here.

C++11 ranged based for loops (for(T obj : iterable)) replaces BOOST_FOREACH without requiring a massive header to be included. The commit for it is only in a local branch now. What needs to be done when replacing it can be found in the refactoring wiki. The reason I excluded it here was because the change became so large that it was difficult to review and would get in the way of other PRs. It's probably better to take baby steps.
I think if we want the DAO functionality back we could rewrite it in a cleaner way by using a dedicated library for HTTP communication instead of re-implementing our own version.

I did not notice dao used the ad-hoc http. Then remove it so it compiles.

authors: denravonska tomasbrod

repo: gridcoin/Gridcoin-Research


text:
Should nlopt_opt be finalized?

I'm interested in the rationale behind preserving explicit destruction of the optimization object instance instead of wrapping this within a finalizer.
I can see a few reasons why'd you keep this as the user's responsibility, primarily to avoid dealing with the odd behavior prescribed by the Fortran standard.

Actually, the nlopt_opt will destroy the handle automatically using a final procedure:
https://github.com/grimme-lab/nlopt-f/blob/696b0e225fe393f1b77006912f09882c25599c48/src/nlopt_wrap.f90#L146
The destroy procedure is additionally exposed to allow the user to perform this operation manually, since the destroy procedure will check whether the handle is actually associated:
https://github.com/grimme-lab/nlopt-f/blob/696b0e225fe393f1b77006912f09882c25599c48/src/nlopt_wrap.f90#L239-L243

Right, I missed that, sorry. I was only looking at the example in the readme.
I fully agree with your reasoning.

Maybe we could update the documentation for this and add a code comment in the example? However, I think that this example might be a bit special, because we are in a program scope which doesn't necessarily call the final procedure on exit but leaves it to the kernel to clean up the used memory after the process terminates. To avoid false positive memory leaks from the C side, manual deconstruction seems like the right thing to do.

By documentation do you mean the Readme? If so, I can I create a PR. Yes, the explicit destruction in the main program scope is a good rule, to avoid the false positive when using an application like valgrind.
My question was motivated by my two recent threads:

https://fortran-lang.discourse.group/t/automatic-finalization-of-derived-types/2295/14
https://fortran-lang.discourse.group/t/should-associate-trigger-automatic-finalization/2324/3

An artificial example for the auto-finalization in the associate statement, would be a constraint object with a pointer component, that was created using the default structure-constructor directly in the associate statement, instead of declaring at as a (static) target in the main program scope.

authors: awvwgk ivan-pi

repo: grimme-lab/nlopt-f


text:
Add post-install message to advise users of next steps

It took me a few mins to understand why my new terraformer install wasn't working, and there's a long thread about it here https://github.com/GoogleCloudPlatform/terraformer/issues/439
This change adds a short message after installation to guide the user to the next steps to complete the install.

Thanks for contribution.
Looks good to me.

authors: grimoh qnm

repo: grimoh/asdf-terraformer


text:
Ability to rename an organization (team site)

After #903 has been implemented, a user has reported that he could not find how to rename the team site he created.
There is already a API endpoint that can be called, but that is a bit technical for users. Unless I am wrong, I think there is currently no other way.
That should be easy to be implemented regarding the development itself, still it would need some design work beforehand.
cc @lusebille

Thanks @fflorent. It is is at all helpful as a design reference, our SaaS billing system has this functionality (you can see it on free team sites). It might be as easy to start fresh though, since our design isn't particularly pretty.

Mocks to talk about during a meetting
https://www.figma.com/design/wcpetFt6aOKzTszcvPPWLQ/[05%2F24]-Grist-Design?node-id=500-68429&t=VWUrb7BuAbEPIHmT-1

The design that makes the most sense is one with a new page for managing a Team Site (aka Org). However, that becomes essentially a subset of the "Billing" page in SaaS. So a question: would it be better to factor out the billing-specific parts from the billing page, and move the rest of the page into grist-core?
A related question is whether the concept of "Plan Managers" is relevant to team sites created on self-managed installations? E.g. are they the ones who can update org name, or can any Team Members with owner permission do that? @paulfitz , do you know? Configuring "Plan Managers" is another important piece of functionality that's currently only available on the billing page.

authors: dsagal fflorent lusebille paulfitz

repo: gristlabs/grist-core


text:
Docker image is broken

I suppose something is broken in docker variant of launch. I've tried a bunch of variants with several machines (Windows 11+Docker WSL2, Almalinux 9.4 + Docker) with resolvable domains:
docker run -p 9999:80 -e URL=http://altair.local:9999 -e TEAM=test -e EMAIL=al@masked.domain -e PASSWORD=qwerty -v /home/al/tmp/grist-test:/persist --name grist --rm -it gristlabs/grist-omnibus

docker run -p 9999:80 -e URL=http://altair:9999 -e TEAM=test -e EMAIL=al@masked.domain -e PASSWORD=qwerty -v /home/al/tmp/grist-test:/persist --name grist --rm -it gristlabs/grist-omnibus

docker run -p 9999:80 -e URL=http://localhost:9999 -e TEAM=test -e EMAIL=al@masked.domain -e PASSWORD=qwerty -v /home/al/tmp/grist-test:/persist --name grist --rm -it gristlabs/grist-omnibus

docker run -p 9999:80 -e URL=http://192.168.122.1:9999 -e TEAM=test -e EMAIL=al@masked.domain -e PASSWORD=qwerty -v /home/al/tmp/grist-test:/persist --name grist --rm -it gristlabs/grist-omnibus

docker run -p 9999:80 -e URL=http://127.0.0.1:9999 -e TEAM=test -e EMAIL=al
@masked.domain -e PASSWORD=qwerty -v /home/al/tmp/grist-test:/persist --name grist --rm -it gristlabs/grist-om
nibus

docker run -p 9999:80 -e URL=http://grist.intra.ORGNAME.REALDOMAIN:9999 -e TEAM=test -e EMAIL=al
@masked.domain -e PASSWORD=qwerty -v /home/al/tmp/grist-test:/persist --name grist --rm -it gristlabs/grist-om
nibus

and the same with https-version. All of these fails on both machine the same way:

Welcome to Grist.
In quiet mode, see http://localhost:17100 to use.
For full logs, re-run with DEBUG=1
Setting up database...
ApiError: Domain is not permitted: Invalid domain value.
at HomeDBManager.unwrapQueryResult (/grist/_build/app/gen-server/lib/homedb/HomeDBManager.js:2255:15)
at setupDb (/grist/_build/stubs/app/server/server.js:98:16)
at async main (/grist/_build/stubs/app/server/server.js:134:9) {
status: 400,
details: undefined
}
error [grist-omnibus] grist failed: exited with 0

All the hosts I mentioned above are resolvable on the hosts, I've double-checked.
How can I fix it? (-e DEBUG=1 doesn't add any useful info)

Ah, that reads like TEAM=test is not a permitted value. Try something else, like TEAM=something. Sorry for this, it is an accidental limit inherited from our SaaS, where team names end up being subdomains and we forbid some that might be confusing.
https://github.com/gristlabs/grist-core/blob/d6701debb114fc832a53efa090c634ef8001f052/app/common/orgNameUtils.ts#L9

Thanks, that fixed the issue

authors: al-indigo paulfitz

repo: gristlabs/grist-omnibus


text:
disk_resource_ensure_loaded needs name param

Missing parameter in example of gritbook

Good catch

authors: lavrod sparkprime

repo: grit-engine/grit-engine


text:
Add support for assert.rejects

This is kind of blurring the lines between assertive and assertive-as-promised, but given async functions this is the only thing I keep "poly-filling". For everything else the normal assertive works perfectly fine:
function assertRejects(promise) {
  return promise.then(() => {
    throw new Error('Did not fail as expected');
  }, error => error);
}

test('foo', async () => {
  const error = await assert.rejects(Promise.reject(new Error('My Error')));
  assert.equal('My Error', error.message);
});

Great idea! :+1: from me, too. :-) Is its opposite already covered by the
other wrapper library? Would be good to have both, IMO.
On fre 6 nov. 2015 at 16:57 Jan Olaf Krems notifications@github.com wrote:

This is kind of blurring the lines between assertive and
assertive-as-promised, but given async functions this is the only thing I
keep "poly-filling". For everything else the normal assertive works
perfectly fine:
function assertRejects(promise) {
return promise.then(() => {
throw new Error('Did not fail as expected');
}, error => error);
}
test('foo', async () => {
const error = await assert.rejects(Promise.reject(new Error('My Error')));
assert.equal('My Error', error.message);
});
—
Reply to this email directly or view it on GitHub
https://github.com/groupon/assertive/issues/24.

The opposite is already covered by await fnThatRejects(), at least for test frameworks that support promises (e.g. mocha & tap).

authors: jkrems johan

repo: groupon/assertive