Gradle 7 requires duplicatesStrategy for "fake" duplicates

Gradle 7 rightfully requires a duplicatesStrategy for handling duplicate files.
However, the respective error can also be produced by adding the same directory to a source set multiple times.
This is a situation often encountered when using multiple third-party plugins, which add the same directories to a source set.
This situation is mostly out of control of the user, yet requires to specify a handling strategy - which in this case seems ultimately unnecessary, since no real file duplicates (duplicate files in multiple directories) are involved.
SourceDirectorySet#getSourceDirectories() might be a potential point, where duplicate source directories could be considered and filtered.
Expected Behavior
Gradle should allow innocently adding the same source directory multiple times, without requiring to set duplicatesStrategy for common tasks (processResources, sourcesJar)
Current Behavior
Gradle throws the duplicatesStrategy error, when the same source directory is added multiple times.
Context
We are using complex builds with a variety of third-party plugins with little to no control over them. The problem forced us to update our build scripts/custom plugins, even though there weren't any actual duplicates involved.
Steps to Reproduce
Build the attached sample project.
g7-duplicate-sources.zip
Your Environment
Gradle 7.0/7.0.2, Windows 10
Build scan URL:

I am also facing this issue while upgrading from Gradle 6.6.1 to 7.0.2, with no real file duplicates involved:
Task :compileE2eTestJava
[Step 1/1] :compileE2eTestJava
[:compileE2eTestJava] FAILURE: Build failed with an exception.
[:compileE2eTestJava]
[:compileE2eTestJava] * What went wrong:
[:compileE2eTestJava] Execution failed for task ':processE2eTestResources'.
[Step 1/1] > Entry application.properties is a duplicate but no duplicate handling strategy has been set. Please refer to https://docs.gradle.org/7.0.2/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy for details.
[Step 1/1] > Task :processE2eTestResources FAILED
[Step 1/1] * Try:
[Step 1/1] Run with --info or --debug option to get more log output. Run with --scan to get full insights.
[Step 1/1] :processE2eTestResources
[:processE2eTestResources] * Exception is:
[:processE2eTestResources] org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':processE2eTestResources'.

The note to refer to https://docs.gradle.org/7.0.2/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy for details is not helping since the task processE2eTestResources is defined by Gradle, not by me, so it is unclear to what exactly I need to add this property to in order to fix this issue.

This is a manifestation of a missing internal Gradle feature. Gradle does not do any deduplication in this use case. And even if such a feature would exist, this configuration would cause many issues. Tasks cannot be up-to-date, caching won't work, etc.
It is the plugin's responsibility to define unique input and output folders. If there's such an overlap, the plugins should also enable the clients to configure those folders.

Agreed that this kind of overlap can be troublesome for other Gradle features, like you mentioned.
But the issue at hand is that Gradle is flagging duplicates, when in fact there aren't any. I still think this should be adressed.

@donat from the Gradle user perspective it looks like a defect introduced in Gradle 7. It would be very nice for the Gradle team to mention it in the Upgrade Guide here https://docs.gradle.org/current/userguide/upgrading_version_6.html. Its current section about Duplication Strategy is kind of misleading. It says "encounters a duplicate entry", and when I read that, I think "but I don't have any duplicates, so it is not relevant to me". Hope you see my point.
And fix for the problem was suggested here https://discuss.gradle.org/t/gradle-7-fail-for-duplicates-in-copy-specs-has-no-duplicates-in-project/39834/8

Folks, what is the solution for this problem? I'm honestly baffled. I'm using 7.1. I followed advice from official upgrade documentation and added this
tasks {
    withType<Copy> {
        duplicatesStrategy = DuplicatesStrategy.EXCLUDE
    }
}

But it doesn't seem to help, as if this setting is not inherited by other tasks. So that distTar or assemble fail for me with the same error unless I set duplicatesStrategy for each of these tasks.

In case it helps. I believe I hit exactly this problem, and the solution that seems to work for me is
task sourcesJar(type: Jar) {
    duplicatesStrategy = 'include'
    classifier = 'sources'
    from sourceSets.main.allSource
}

java {
    withJavadocJar()
    withSourcesJar()
}

Order of these is important! task sourcesJar must come first, and you must also have withSourcesJar()

For anyone coming here and using kotlin multiplatform, the plugin trigger the issue if withJava() is used : https://youtrack.jetbrains.com/issue/KT-46978
The official gradle response to this issue is very disapointing. It's ok to don't fix it as plugin should not do what they are doing.
But showing some level of empathy for your users would be greatly appreciated.
Actually we have a message wich talk about a duplicated resource that is not duplicated. It's missleading.
Their is nothing in documentation/upgrade-guide that can help.
 Or they curse gradle for being "too complicated" and "not working".
This not very pleasant for everyone.
Once this issue is found, it's time to remove plugins, comment any build part depending on it, and re-add/enable them one by one, maybe in different combination to search culprit(s). On complex build, it's cumbersome.
What can be done ?
At level 1, mention in upgrade guide that some plugin which was incorrectly using copy might break the build.
At level 2, mention in the error message that it might be caused by plugin bugs.
At level 3, detect directory added multiple times, produce a message adapted to this situation
At level 4, detect directory added multiple times, and say which plugin(s)/call-site is adding it
I understand that it may be not trivial to handle.
But saying "not our problem : good bye" when issue is not directly under user control nor visibility of user and triggered by and update of gradle, letting user suffering from it, it feel like gradle don't care and it's just sad...

@ylemoigne I completely agree.
Gradle guys, the issue is if Gradle gets too overwhelming to use it'll loose popularity. I don't want that, I love to use Gradle for many years now but this is a warning sign. Please make sure releases are user friendly.
I had genuine duplicate files in my repo (log4j.properties in different test directories) and my solution was:
allprojects {
  apply plugin: 'java'

  tasks.withType(Copy).all {
    duplicatesStrategy 'exclude'
  }
...

I had limited time to troubleshoot my issue mentioned above so eventually I had to rollback to version 6.
A possible workaround (not tested by me yet), suggested by this comment, is to add the following to the build.gradle:
rootProject.tasks.named("processE2eTestResources") {
    duplicatesStrategy = 'include'
}

Kotlin type safe syntax that worked for me:
<project>.tasks.named("processResources", Copy::class.java) {
   duplicatesStrategy = DuplicatesStrategy.INCLUDE
}

@JiangHongTiao - I contacted jetbrains support and they pointed back to gradle so I see no point trying to come up with a work around with gradle for it does not make sense to put in extra code throughout a project just to fix a build issue.
Hope gradle/jetbrains figures out what is actually going wrong with 7 to 7.2 ....

Still having this issue in 7.2.

Just had the same issue while upgrading from Gradle 6.7 to 7.3.
It has been caused by my sourceSets definition
sourceSets { 	main { 		java { 			srcDirs = ['src'] 		} 		resources { 			srcDirs = ['src'] 			includes = ['**/*.xsd'] 		} 	} }
I fixed it in my scripts by setting the duplications strategy for the sourcesJar in my custom plugin:
project.getTasks().getByName("sourcesJar").setProperty("duplicatesStrategy", DuplicatesStrategy.EXCLUDE);
Maybe this is helpful for others, that come across this issue too.

I'm getting this when upgrading from a previous gradle version.
processResources {
    from(sourceSets.main.resources.srcDirs) {
        filter ReplaceTokens, tokens: [version: version]
    }
}

seemed to be a popular example for filtering something bundled in the resources folder before it was packaged.
However this error indicates it's creating a duplicate?

Fortunately, I found this issue here, otherwise I will be stunned by gradle 7.

After upgrading from some 6.x to 7.3.3, I get this error report while building a pure java module. It is beyond me to understand what is the concrete cause, as there is no pointing to line number, nor to the dependency causing this trouble. After a day of trials in vain, I would like to announce a strong wish to be presented for better error messages. What a timethief for something that seems to be most likely on the fringe of the build process, regarding importance.
I ask @mlopatkin or @donat to be so kind to make a suggestion on how to handle this. Thanks

Just wondering if this is being worked on? I ask because I can't deploy a training program that involved using Gradle as part of the development tools. As per my previous note I did revert to a previous version but given the seriousness of this issue I figured a fix would be issued in short order.
Am I missing something or does this issue not prevent people from using Gradle 7?
If it is not going to be fixed or is considered a low priority can this be stated so I and people like me can make a decision as to which direction to go? I have to make a decision soon and had hoped for a fix.

@GregMarshBYKA You are missing something.  Plenty of people are using Gradle 7.  This issue, while annoying, can be worked around in the interim while we are waiting for a proper fix.  You have to set the duplicatesStrategy in one of various ways (plenty of examples above) and you can continue on with Gradle 7.

@swpalmer
I don't think I am missing anything. As per my original post, I will be starting several training programs for coders and we had intended to use the initial demo which currently does not work out of the box.
As to the solutions, these are workarounds and I have not checked all of them - a few of them required a lot of redundant work.
I was hoping to get clarity as to when the fix is scheduled.
As to the latest fix mentioned I will try that and the following might be some value for those working on a solution.
https://docs.gradle.org/current/javadoc/org/gradle/api/file/DuplicatesStrategy.html
Thank you

I have bumped on this new behavior as well. I had project with several subprojects. And many of them had the same file in the resource directory (.giitkeep) as there was no files in the directory but we still wanted to keep it in the repository. Now during the generation of jar artifact, this exception has been thrown.
In my case simple solution was to remove those .gitkeep files so there were no duplicate files anymore in the final artifact.
In case there would really be some files that I would require in final artifact I would need to find a way of how to exclude them, or just follow what @lackovic suggested https://github.com/gradle/gradle/issues/17236#issuecomment-894768083

In my case the issue was not the duplicate handling. Fair enough, silently overwriting duplicate files was bad. In my case it has revealed a particular fact about our build that I cannot explain, and really don't know where to start debugging. The best I could achieve while debugging with Intellij was that it might have something to do with the fact we are using the google protobuf plugin.
The Jar task was trying to copy 3 identical sets of files and I have no idea why. So the new duplicateStrategy has kind of revealed some other issue here, but it was annoying nonetheless.
// package the compiled application, along with all dependencies, into a single runnable jar
val fatJarTask = tasks.register<Jar>("app") {
    archiveClassifier.set("app")

    from(sourceSets.main.get().output)

    dependsOn(configurations.runtimeClasspath)
    from({
        logger.error("this message is printed 3 times when running the 'app' task and it's not clear why")
        configurations.runtimeClasspath.get().filter { it.name.endsWith("jar") }.map { zipTree(it) }
    })

    // https://github.com/gradle/gradle/issues/17236
    duplicatesStrategy = DuplicatesStrategy.INCLUDE

    manifest {
        attributes["Main-Class"] = "MainKt"
    }
}

I just hit this issue too with gradle 7.3.3. I'm using the jvm-test-suite plugin, i have a 'test' suite and 'integrationTest' suite.
as soon as i added log4j2.xml to src/integrationTest/resources i got this error:

Execution failed for task ':messenger:processIntegrationTestResources'.
Entry log4j2-test.xml is a duplicate but no duplicate handling strategy has been set. Please refer to https://docs.gradle.org/7.3.3/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy for details.

for sure there are no duplicates , this was my workaround:
processIntegrationTestResources{
duplicatesStrategy = DuplicatesStrategy.WARN
}

Thanks for all previous comments,  this worked for me when we have a task already defined.
processResources() {
    duplicatesStrategy = 'EXCLUDE'
}

I added the workaround previously mentioned by @robvadai and it worked.
This isn't my project, https://github.com/Kotlin/kotlinx.serialization
I am not familiar with Gradle and I just want it to compile.
allprojects {
apply plugin: 'java'
tasks.withType(Copy).all {
    duplicatesStrategy 'exclude'
}

}

For those looking for a kotlin solution (i.e. how to write this in a build.gradle.kts file) this worked for us:
tasks.jmhJar {
    duplicatesStrategy = DuplicatesStrategy.EXCLUDE
}

none of the above solutions seem to work and I always get a build failure with this Entry BOOT-INF/lib/reactive-streams-1.0.3.jar is a duplicate but no duplicate handling strategy has been set. Please refer to https://docs.gradle.org/7.4.2/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy for details.
rolling back to gradle 6, again.

help: after https://stackoverflow.com/questions/67265308/gradle-entry-classpath-is-a-duplicate-but-no-duplicate-handling-strategy-has-b
with: Entry WEB-INF/lib/ObjectFactory.class is a duplicate but no duplicate handling strategy has been set.
Realized that in my case I needed to do this in the type Jar instead Copy, thank you all
tasks.withType(Jar).all {
    duplicatesStrategy 'exclude'
  }

I don't know the current status and I did not invest too much time researching, so I just share my observation in case in helps someone.
I have a Kotlin project with the build file below. With gradle 7.3 I encountered an "Entry classpath.index is a duplicate but no duplicate handling strategy has been set" error. Since it clearly cannot be something that I configured in the build file, I refused to add any config. The build has to work just like that. So I updated to gradle 7.6 and hoped for the best and yep - the error was gone. And don't know why, I don't know what caused it in the first place, and I honestly don't care.
Since this thread is full of "add this to your config" suggestions I just wanted to share that it is clearly not always the "fix" to this issue to take the blame and change the build config. There must have been a (or at least one) bug in the Gradle software that has been fixed.
import org.jetbrains.kotlin.gradle.tasks.KotlinCompile

plugins {
    kotlin("jvm") version "1.7.21"
    war
}
group = "de.uapcore"
version = "1.0-SNAPSHOT"

repositories {
    mavenCentral()
}

tasks.withType<KotlinCompile>().configureEach {
    kotlinOptions.jvmTarget = "11"
}

tasks.war {
    archiveFileName.set("lightpit.war")
    from("src/main/resources")
}

kotlin {
    sourceSets {
        val main by getting {
            dependencies {
                // ... usual suff ...
            }
        }
    }
}

I don't know the current status and I did not invest too much time researching, so I just share my observation in case it helps someone.
I have a Kotlin project with the build file below. With gradle 7.3 I encountered an "Entry classpath.index is a duplicate but no duplicate handling strategy has been set" error. Since it clearly cannot be something that I configured in the build file, I refused to add any config. The build has to work just like that. So I updated to gradle 7.6 and hoped for the best but no, the error was still there.
UPDATE - I did some research now...
Since this thread is full of "add this to your config" suggestions I wanted to find a solution that does not require the user to add mysterious config to the build file. There has to be a way, otherwise the build system would not work with a default config, which would be really really bad.
Apparently in my case the root cause is that most recent versions of IntelliJ are generating some classpath.index file that Gradle does not expect and does not know how to handle. And since this file is generated in every source file location (i.e. at least one in code directory and one in resource directory), it is a genuine duplicate.
See https://youtrack.jetbrains.com/issue/IDEA-305759/Gradle-cannot-handle-classpath.index-duplicates for more info.
To be very clear: I still believe that Gradle should have proper defaults that do not cause such builds to fail. But I also would admit that currently Gradle works as designed. It's just poor design imho...
import org.jetbrains.kotlin.gradle.tasks.KotlinCompile

plugins {
    kotlin("jvm") version "1.7.21"
    war
}
group = "de.uapcore"
version = "1.0-SNAPSHOT"

repositories {
    mavenCentral()
}

tasks.withType<KotlinCompile>().configureEach {
    kotlinOptions.jvmTarget = "11"
}

tasks.war {
    archiveFileName.set("lightpit.war")
    from("src/main/resources")
}

kotlin {
    sourceSets {
        val main by getting {
            dependencies {
                // ... usual suff ...
            }
        }
    }
}

Thanks for pointing this out, it turned out to be the reason for me.
However I think that Gradle's duplicate handling strategy is fine, otherwise you would have silent duplicates. Failing fast in this case is good. Maybe the message could point to the files.

I met the similar issue. The solution is quite simple: Execute rm -rf <project>/build to remove the build folder.

@uap-universe In my opinion the default strategy should be to fail because I believe in "fail fast" approach. Avoid unexpected issues.

I did not try the FAIL strategy, yet. If you get a similar message as in WARN pointing to the files, I could live with that. But at least some default would already make me happy.

Yes, same here. I was thinking classpath.index is a variable or configuration parameter. I didn't think about a file until I read this issue. I think

the message should be more clear. the error is obviously an error, so this is fine for me. probably better than silently ignoring
it should not be necessary to fix this by the developer. intellij did a change and this brakes a very widely used usecase. so I clearly think intellij should stop causing this issue.
best workaround for me is: "adding -Didea.classpath.index.enabled=false into Help | Edit Custom VM Options and Settings (Preferences on macOS) | Build, Execution, Deployment | Compiler | User-local build process VM options (overrides Shared options)." (https://youtrack.jetbrains.com/issue/IDEA-305759/Gradle-cannot-handle-classpath.index-duplicates#focus=Comments-27-6626901.0-0)

This thread contains a number of possible solutions that I assume the Gradle Team can judge as to which is the best option. I am just wondering what needs to resolve this issue which for myself I commented on back in Oct 2021. Back then I went back to a version of Gradle that worked "https://github.com/gradle/gradle/issues/17236#issuecomment-938892546" but it was not really a viable option.
I hope that the consensus is to fix the issue versus providing "workarounds" that always get us into trouble.
Either way, Happy New Year to all and I hope that this issue is finally laid to rest soon.

@GregMarshBYKA The least common denominator seems to be to identify the failing task (which might not be in your build file, yet! So that's the "hard" part - at least for beginners) and then explicitly specify the duplicate strategy to be WARN (some also go for EXCLUDE right away, but I'd prefer WARN).
Maybe @big-guy can shed some light on what happened since Nov 2021 what we can expect in a future version.
In my particular case, for example, I removed the entire default JAR task. The funny thing about this is, that I have to explicitly write code, to disable something that breaks the build :-D
before
tasks.war {
	archiveFileName.set("lightpit.war")
	from("src/main/resources")
}

after
// Only configuring the WAR task I want in my build is not enough, because
// there is a default JAR task, which also throws the error when there is no
// DuplicatesStrategy set. Therefore, I either need to ALSO configure the JAR
// task or disable it entirely (which is what I do - because I don't need it).
tasks.jar {
	enabled = false
}

tasks.war {
	duplicatesStrategy = DuplicatesStrategy.WARN
	archiveFileName.set("lightpit.war")
	from("src/main/resources")
}

uap-universe

Thank you, Mike, for your comments, for me the fundamental problem is that we are being asked to add a solution for something that does not exist and since this was not a problem in earlier versions I don't understand the justification for allowing such a workaround to exist.
My ask was based on the simple fact that the introductory example used to build an app that used Gradle failed - IE:, the equivalent of C's "Hello World"  not working.
I am happy to use a Gradle-approved solution, even if it is a forced workaround to solve the issue but maybe that is better as a flag that can be turned off and on.
Normally I would not bother and just move on to something else but there is something simply annoying about this bug in Gradle that keeps flagging duplicates that don't exist. I am assuming that the result has nothing to do with duplicates found (no matter how bizarrely they are created.) but rather code that fails and triggers this event.
As to letting it default to a warning that is a good solution simply because we can add code when duplicates actually exist and we can ignore adding code when we are starting from scratch or know that duplicates do not exist.
Does the Gradle team respond to these threads or is it simply user driven?
Cheers

Thank you, Mike, for your comments, for me the fundamental problem is that we are being asked to add a solution for something that does not exist and since this was not a problem in earlier versions I don't understand the justification for allowing such a workaround to exist.

Yes, that was also exactly my point in a previous comment. I think we completely agree in all points. Now it's up to gradle devs to hopefully come up with a solution soon.

Thank you, Mike, for your comments, for me the fundamental problem is that we are being asked to add a solution for something that does not exist and since this was not a problem in earlier versions I don't understand the justification for allowing such a workaround to exist.

Yes, that was also exactly my point in a previous comment. I think we completely agree in all points. Now it's up to gradle devs to hopefully come up with a solution soon.

It has been at least a year so, yes, I hope so too for I would like to be able to use Gradle at some point for new development.

I really appreciate everyone's comments for it shows that this is clearly an issue and not something that is born out of a failure to understand how Gradle works.
That said, can anyone suggest an effective path to engage Gradle regarding this fundamental failure? Not knowing the inner workings of Gradle I do not want to assume that the solution is only dependent on resources being assigned to fix a bug. If it is complex and can't be fixed right now may we know why?
Like many support threads, it is very frustrating to watch users fix or attempt to fix things that should be dealt with by those in the know.
Fingers crossed.

@big-guy can you please confirm, that you are still working on this? @jvandort can you please have a look and maybe reassign this issue if @big-guy is currently busy doing something else? Thank you so much :-)

If I understand the (quickly scanned) discussion above this indicates that some form of copy or similar task is writing a file that already exists. If that's true this has got to be the worst error message ever... "you have a duplicate Named X. Too bad, you figure it out" is about what it says. The great thing is that it's often the same thing being copied twice so no matter how much you grep or search for a duplicate, it's not there. Duplicate of what? where is the destination that seems to contain a duplicate? If gradle wants to ensure that one never accidentally overwrites via copy, then it needs to track all the things that copy files. (src/main/resources/foo.txt --> build/resourceTmp/foo.txt etc) Then when it tries to copy src/test/resources/foo.txt --> build/resourceTmp/foo.txt it can complain like this:
src/test/resources/foo.txt attempting to overwrite /build/resourceTmp/foo.txt (previously copied from src/main/resources/foo.txt)

For even better clarity track the current task and modifed times so that one could understand
src/main/resources/foo.txt (task:mungeResources) attempting to overwrite /build/resourceTmp/foo.txt (previously copied from src/main/resources/foo.txt (task:copyResources)

And possibly NOT fail if the mod time hadn't changed.
Wait, that's too much memory you say... possibly which is why the biggest problem here is this should be an optional feature for folks who are having issues with things getting mysteriously overwritten. Maybe something like
allProjects {
  strictCopy true
}

Problem:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':mycoolmodule:processResources'.
Caused by: org.gradle.api.InvalidUserCodeException: Entry mycoolresource is a duplicate but no duplicate handling strategy has been set. Please refer to https://docs.gradle.org/7.5/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy for details.
Solution:
processResources.duplicatesStrategy = DuplicatesStrategy.EXCLUDE

Problem: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':mycoolmodule:processResources'.
Caused by: org.gradle.api.InvalidUserCodeException: Entry mycoolresource is a duplicate but no duplicate handling strategy has been set. Please refer to https://docs.gradle.org/7.5/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy for details.
Solution: processResources.duplicatesStrategy = DuplicatesStrategy.EXCLUDE

Thank you but we are discussing a bug in Gradle whereby an error is thrown when a duplicate does not exist.

If I understand the (quickly scanned) discussion above this indicates that some form of copy or similar task is writing a file that already exists. If that's true this has got to be the worst error message ever... "you have a duplicate Named X. Too bad, you figure it out" is about what it says. The great thing is that it's often the same thing being copied twice so no matter how much you grep or search for a duplicate, it's not there. Duplicate of what? where is the destination that seems to contain a duplicate? If gradle wants to ensure that one never accidentally overwrites via copy, then it needs to track all the things that copy files. (src/main/resources/foo.txt --> build/resourceTmp/foo.txt etc) Then when it tries to copy src/test/resources/foo.txt --> build/resourceTmp/foo.txt it can complain like this:
src/test/resources/foo.txt attempting to overwrite /build/resourceTmp/foo.txt (previously copied from src/main/resources/foo.txt)

For even better clarity track the current task and modifed times so that one could understand
src/main/resources/foo.txt (task:mungeResources) attempting to overwrite /build/resourceTmp/foo.txt (previously copied from src/main/resources/foo.txt (task:copyResources)

And possibly NOT fail if the mod time hadn't changed.
Wait, that's too much memory you say... possibly which is why the biggest problem here is this should be an optional feature for folks who are having issues with things getting mysteriously overwritten. Maybe something like
allProjects {
  strictCopy true
}

Thank you but we are discussing a bug in Gradle whereby an error is thrown when a duplicate does not exist.

...is a duplicate but no duplicate handling strategy has been set. Please refer to https://docs.gradle.org/7.5/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy for details.
This is the problem that I am receiving when I try to build my project in which I am trying to upgrade the Gradle version from 6.7 to 7.5. I tried to add this in build.gradle but the error still persists.
`allprojects {
apply plugin: 'java'

tasks.withType(Copy).all {
    duplicatesStrategy 'exclude'
}
...

`
I also tried to add this in my build.gradle.in file but I am not able to remove this error and every time build fails. Even tried it with .INCLUDE and .EXCLUDE but no way to get rid of this error.
tasks.withType(Copy) {     duplicatesStrategy = DuplicatesStrategy.WARN }
There are two build.gradle.in files but the error is from first file. I have tried to add into 1 file in which there is error and also tried it in both files but no chance.

It's another magic line I will handle to my simple Spring Boot project to make it work with Kotlin and QueryDSL. Don't really know, what causes the actual problem but I am just tired of this.

is it possible this bug is still alive? Having some issues with gradle 8.1.1
see https://github.com/gradle/gradle/issues/25208
Any help is very welcome cause i can't publish at the moment. This is a show stopper

I don't know why you can't publish here carstenSpraener (I can't reference you either) - this itself is an issue but to your point, I have not seen anything published that refers to this being resolved and everything so far that I have seen is a workaround for a "NON ERROR".
I am hoping that something posted here or in the releases will specifically address this issue for we are still using the old version of Gradle.

案是：log4

I found that you are too right, I have been using the maven, but spring in the use of gradle. I would like to learn a little, I found that it is too dissuasive, no matter what, I never clone the code down after the direct start success, each time there will be a lot of small problems, and finally I really do not want to touch the

I am not sure if anyone of the gradle team watches this task anymore - however maybe this can useful for others, our solution:
subprojects { p ->
  // To prevent naming conflicts in multi-module projects, include the full relative path in the jar name.
  // This is crucial when common module names (like 'api' or 'core') exist in various subdirectories.
  // This strategy ensures jar name uniqueness across the project.
  tasks.withType(Jar).tap {
    configureEach {
      archiveBaseName.set(project.path.replace(':', '-').stripMargin('-'))
    }
  }
}

In a situation where two sub modules have same name (as described in the comment) default value for jar files causes error in tasks where these are collected together (for example Spring's bootWar task which I assume many people relay on in one way or another).
This is direct result of Project#getName method returning potentially non unique value for multiproject file being used as a default for archive base name.
One potential solution would be to change that default to Project#getPath - which according to documentation returns unique value in the repository.
In this case meddling with duplicatesStrategy seems misguided - as allowing duplicates can lead to unintended side effects - like duplicates that developers don't know about.
This doesn't address conflicts from "outside-of-repo" jars but still looks like an overall improvement.

I am not sure if anyone of the gradle team watches this task anymore - however maybe this can useful for others, our solution (in root build.gradle file):
subprojects {
  // To prevent naming conflicts in multi-module projects, include the full relative path in the jar name.
  // This is crucial when common module names (like 'api' or 'core') exist in various subdirectories.
  // This strategy ensures jar name uniqueness across the project.
  tasks.withType(Jar).tap {
    configureEach {
      archiveBaseName.set(project.path.replace(':', '-').stripMargin('-'))
    }
  }
}

In a situation where two sub modules have same name (as described in the comment) default value for jar files causes error in tasks where these are collected together (for example Spring's bootWar task which I assume many people relay on in one way or another).
This is direct result of Project#getName method returning potentially non unique value for multiproject file being used as a default for archive base name. One potential solution would be to change that default to Project#getPath - which according to documentation returns unique value in the repository.
In this case meddling with duplicatesStrategy seems misguided - as allowing duplicates can lead to unintended side effects - like duplicates that developers don't know about.
This doesn't address conflicts from "outside-of-repo" jars but still looks like an overall improvement. Also changing : to - can maybe be skipped.

@Azahe , thank you for your code sample which addresses issues that I am sure people will benefit from. Unfortunately, the core issue here is not related - Gradle 7 broke something and flags duplicates when there aren't any. This is the real issue and as per your comment at the beginning, I do not know if anyone is looking at this for there does not seem to be any further input. I hope this topic stays open and is not closed due to lack of responses for as far as I can tell nothing has changed.

I'm the orignal bug author and reported a very specific situation, where adding the same source directory twice to the project (something that multiple third-party plugins might do) leads to erroneous reporting of duplicates, as demonstrated by a reproducer project attached.
This specific misbehaviour/bug has been closed and flagged as no-fix by the gradle devs (https://github.com/gradle/gradle/issues/17236#issuecomment-856806005). So there probably won't be happening anything regarding the original issue.
For some reason this specific report seems to be found by people dealing with all sorts of duplicate issues and has become sort of a fly trap since.
I can only recommend to file a separate issue for your specific problem, ideally with a reproducer sample attached.

@lkoe Hi Lars, there are many variations added but the core issue that you pointed out resulting from the requirement to add a "duplicatesStrategy" even for nonexistent duplicates is still there and a lot of the comments relate so hopefully someone is taking note. Cheers

Thanks, everyone, for the discussion and sorry for the late reply.
As @donat pointed out in his message, the idiomatic way to resolve this is to change Gradle plugins and script to avoid intersecting directories. The default fail-fast strategy is correct and, as some of you indicated, helpful in most cases, so it's unlikely that this behavior will be changed.
However, the error message should definitely be improved to indicate the sources of the duplicates to ease the debugging and fixing the issue.
Another option might be improving the duplicates strategy to ignore exact duplicates (e.g. with matching fingerprints) - this should solve the issue for newbie users. However, it's up to the team responsible for that area to decide.

The issue is in the backlog of the relevant team, but this area of Gradle is currently not a focus one, so it might take a while before a fix is made.

I agree that the error message needs to be greatly improved. I have a project which keeps getting spurious duplicate errors on files that don't exist in my project. running clean usually but not always fixes it for the next build, but sooner or later it returns and it affects the CI too. The error message specifies the path of the supposedly duplicate file, file the file (which is different every time — the example I'm looking at right now is META-INF/versions/9/module-info.class) never actually exists in my project. Presumably it is generated by gradle itself or a plugin, but there is no information whatsoever in the error message with which to debug the cause of the duplicate or even where to find the file in question (with the hope that perhaps looking at the file itself can offer some insight). I'm forced to set duplicatesStrategy=WARN now because I can't eliminate the cause and the CI build risks spuriously failing otherwise. Forcing us to disable (effective) duplicate checking defeats the point of checking for duplicates in the first place.


1.5.42 Dashboard arrow exists app first time after cloud sync

Description:
Couldn't find a card for this.
User has set dashboard view and synced it to cloud, then signs out from app and signs in to cloud again.
Actual: user will see cards view with arrow at top left corner. Tap on arrow closes app.
Expected: go to dashboard view.

https://user-images.githubusercontent.com/50437378/133627550-bd8b5874-d7a9-4659-b6b9-ba5789579f66.mp4

1.5.45

Can be tested @markoaamunkajo


Allow 'deployer' to be a role or group, not just a single user

I want to let multiple users be the 'deployer' to my s3 bucket, e.g. me, my colleagues, + the user from a CI app like Jenkins or something.
Normally to facilitate this I'd have a 'deployer' role (not user), and then authorize any of the above users assume that role so that they can deploy.
As this is coded now, there can only be one user. https://github.com/ringods/terraform-website-s3-cloudfront-route53/blob/d2e06/site-redirect/main.tf#L78
Agree it's a good idea to have this module support making a role instead? It could output the role arn, and users of this module could authorize users to assume that role as needed. https://www.terraform.io/docs/providers/aws/r/iam_role_policy_attachment.html
Alternatively, the modules could just output the policy JSON, and then users of this module could use that to send into IAM however makes sense.

Hi @gobengo , sorry not responding sooner.
Although we don't have a specific use case for this ourselves, I think it might be useful for other users. We don't have the bandwidth to handle this at the moment, so would you be willing to submit a PR to tackle this?

I'm going to close this issue due to lack of activity. Feel free to re-open it or create a new one if the problem persists.


Error import pdfToPng function. 3.6.0 version

Hello! I would like to thank you for the quick solution to the problem for node 22. But the latest version does not import the pdfToPng function correctly. It was probably broken here
https://github.com/dichovsky/pdf-to-png-converter/pull/64/files

Hello! I would like to thank you for the quick solution to the problem for node 22. But the latest version does not import the pdfToPng function correctly. It was probably broken here https://github.com/dichovsky/pdf-to-png-converter/pull/64/files

Hi @bloodgang94
Could you provide repro steps ?
Did you try to clean up node_modules folder?
It works on my side

Hello! I would like to thank you for the quick solution to the problem for node 22. But the latest version does not import the pdfToPng function correctly. It was probably broken here https://github.com/dichovsky/pdf-to-png-converter/pull/64/files

Hi @bloodgang94 Could you provide repro steps ? Did you try to clean up node_modules folder? It works on my side

Yes, of course, https://github.com/bloodgang94/pdf-to-png-reproduce

Im having the same issue

Im having the same issue
Steps:

Install the latest version of the package
run the app

Tried removing node_modules are installing them again. But it doesnt work

@NotVenuMadhav @bloodgang94 please try v3.6.3

@dichovsky , this problem has been resolved. can be closed


KAFKA-2624: Change log message position

Log warning message before truncating log in order to
display right offset value for the truncated log.

Thanks. LGTM

Hi,
Can we close this MR ?
Thanks
Francois

@dopuskh3 Maybe you can ping a reviewer directly to review the patch.

Thanks for the patch. LGTM

Log warning message before truncating log in order to
display right offset value for the truncated log.

Log warning message before truncating log in order to
display right offset value for the truncated log.


[QUESTION] Blocked with "accessing a cross-origin frame" error

Hello,
I was on PublisherConnector before and my code was working, since I upgrade to PublisherInterface, I always get "EXTERNAL ERROR: Blocked a frame with origin "https://domain" from accessing a cross-origin frame."
I followed the documentation and the process. I'm on symfony and front with twig.
Here is my code:
(async () => {         try {             const publisherInterface = await PublisherInterface.build(iframe);             await publisherInterface.addListener(                 "DocumentFullyRendered",                  target => {                     $('.zoom').on('click', (e)=>{ zoom(e, publisherInterface); });                 }             );         } catch (e) {             console.log(e);         };     })();
It's not even doing the build.

No problem, for those who encountered the same issue and are on self hosting, follow this link: https://github.com/chili-publish/publisher-interface/wiki/Moving-to-Publisher-Interface#moving-to-publisher-connector


[TUBEMQ-555] fix short session bug

We are working on the 0.8.0 version release, it will be merged in 0.9.0.
Thanks @leno1001


[$1000] Admins channel not showing the updated rate/uint changes in a new UI

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Go to staging dot on web chrome
Create a new workspace
Go to admins channel
Now go to the workspace and try to edit the workspace name and the default currency and notice that the admins channel shows the updated workspace name and currency message
But now try to change the rate/unit of the same workspace and notice that it doesn't display the updated rate/unit message on admins channel
(To cross check, since new.expensify has not been updated now , I tried on it and in the older version or in the previous UI, when we used to change the rate/uint of the workspace, it used to give us the updated rate/unit on the admins channel)

Expected Result:
The admins channel should display message on updating rate/unit as how it used to do earlier (Or how it shows message when we update the workspace name or currency)
Actual Result:
The updated rate/unit message is not displayed on admins channel
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.3.19-6
Reproducible in staging?: y
Reproducible in production?: N (New UI for track rates)
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/43996225/0a89d0a8-6cb0-4c5b-ab00-8baf8290c2d0
https://github.com/Expensify/App/assets/43996225/9d1c9a24-3bc0-4f11-b1c8-5dd7b8ef33aa
Expensify/Expensify Issue URL:
Issue reported by: @priya-zha
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1685093646369479
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01252e932ddd3b2115
Upwork Job ID:<PHONE_NUMBER>871712256
Last Price Increase: 2023-05-30

@sakluger Should this one be triggering a message in the admins room?

@sakluger bump on my previous question 😄

@sakluger another friendly bump

@hayata-suenaga Can you guide me to where this happens in the code? This is an internal bug and not external, right?

The unit used for mileage is part of an attribute of a custom unit.

it's handled here
https://github.com/Expensify/Web-Expensify/blob/f7f9d92fe2d44fdfb594938fa3bbe8dba65c4c72/lib/Report/Action/PolicyChangeLog/Utils.php#L146
The currency under rate

and it's handled here
https://github.com/Expensify/Web-Expensify/blob/f7f9d92fe2d44fdfb594938fa3bbe8dba65c4c72/lib/Report/Action/PolicyChangeLog/Utils.php#L255

if it used be working before, I don't know why it suddenly stopped working...

Thanks, I will try to debug it and come up with a fix.

Hmm interesting, the code you linked is not called at all when updating the rate. I will follow the flow.

@hayata-suenaga I found the problem, it's because we call updateWorkspaceCustomUnitAndRate instead of updateWorkspaceCustomUnit

Was any change introduced to change the method to call?

Yes, there was a PR to combine two API requests into one here: https://github.com/Expensify/Web-Expensify/pull/37117 Not sure if your changes or @joelbettner PR got merged first, maybe they were being merged around the same time and forgot to include the changes from each other.

Would you like me to create a fix PR? or you already started working on the fix?

I already started working on it, no worries 😄

Not overdue, PR has been merged and deployed to prod

It should have been closed automatically, this is done, closing.

@pecanoro @bfitzexpensify I'm the external reporter for this bug.

Ahh sorry, @bfitzexpensify can you handle payment for that?

Payment complete! Let's close this out.


improved commends in env file. inline commends now work.

now inline commends can be used by space and #
will work
API_KEY=thisisanapikey # This is a commend
will work
API_KEY=thisisanapikey #This is a commend
will not work (no space before #)
API_KEY=thisisanapikey# this is a commend

I like this @Karl1b. I suppose if we wanted to be REALLY thorough we could also allow escaped values for # like "This is a value that ends with  #". But the case where somebody has a value that ends with " #" is probably so few and far between we don't need to worry about it.


New package: ByteDance.Doubao version 1.3.3

Checklist for Pull Requests

[x] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[x] Does your manifest conform to the 1.6 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

The PackageUrl resists Internet translation. For future reference, the download links are in a menu opened by this small element, at the bottom left of the page:


Loading pictures in profiles

Open Profile: the place where a picture should be is grey, same for other related picture showing it grey and says loading....
Regards,
Ana Green

Which viewer?

I saw you posted FS 5.0.11 in the other issue.
I just tested on 9.40 (Vin's GWGrid) and on latest master with a cache-cleared Firestorm 6.0.2 (56680) Feb  8 2019 23:11:19 (64bit) (Firestorm-Releasex64) with OpenSimulator support.  In both cases the texture showed up in the legacy profile view.

In case that should step back to 9.40?
It has been a long-standing problem and was not a high critical thing to fix. Dad is using Firestorm 5.0.11 (53634) Jan  9, 2018, 20:02:54 (Firestorm-Releasex64) with OpenSimulator support, because for him he said it works in general better.
Extended: Bob said, It has not been solved at all yet. Only this one clue was the DB error field size was not large enough for what was being put into it. But making the field size larger only resolved the DB error, not the way the attachment is being processed or accessed. One of them has it wrong.
Regards,
Ana Green

Profile pictures are not a problem in Halcyon. I have already proven this with Frank. It is a problem with his viewer and we worked on clearing his cache to see if that was part of the issue. There may also be a FireStorm version problem as I do not think we are on the same viewer release. I am using FireStorm <IP_ADDRESS>680. I have no problem placing a picture in my profile or seeing the Grid Owner profile picture in Dreamcastle world. I sent both screen captures of that to Frank on Skype. I also set my profile picture on my Gospel World account with no problem, it is running Halcyon 0.9.40.

This is probably just a matter of updating the profile picture.  Usually, when a picture is grey it means the viewer is having trouble reaching that particular asset.  It may even be a default picture for the profile.  The quickest and easiest way to correct this would be to open your profile drag and drop your preferred picture on your profile's picture and click the okay button.  Assuming everything on the backend is working as it should (and I would say it is in this case) the picture should update and the grey picture should be fixed.

In which case, I'm going to conclude that this is a local issue, not a Halcyon issue and close this report.  Thank you all.


Implement Reflect for Box

What problem does this solve or what need does it fill?
Boxed Reflect trait objects should themselves be reflectable
What solution would you like?
Implement Reflect for Box<dyn Reflect>.
What alternative(s) have you considered?
None.
Additional context
Working snippet from @Davier:
unsafe impl Reflect for Box<dyn Reflect> {
    fn type_name(&self) -> &str {
        self.deref().type_name()
    }

    fn any(&self) -> &dyn Any {
        self.deref().any()
    }

    fn any_mut(&mut self) -> &mut dyn Any {
        self.deref_mut().any_mut()
    }

    fn apply(&mut self, value: &dyn Reflect) {
        self.deref_mut().apply(value)
    }

    fn set(&mut self, value: Box<dyn Reflect>) -> Result<(), Box<dyn Reflect>> {
        self.deref_mut().set(value)
    }

    fn reflect_ref(&self) -> ReflectRef {
        self.deref().reflect_ref()
    }

    fn reflect_mut(&mut self) -> ReflectMut {
        self.deref_mut().reflect_mut()
    }

    fn clone_value(&self) -> Box<dyn Reflect> {
        self.deref().clone_value()
    }

    fn reflect_hash(&self) -> Option<u64> {
        self.deref().reflect_hash()
    }

    fn reflect_partial_eq(&self, value: &dyn Reflect) -> Option<bool> {
        self.deref().reflect_partial_eq(value)
    }

    fn serializable(&self) -> Option<Serializable> {
        self.deref().serializable()
    }
}

Hi there! Never contributed before but want to give it a try. Can I help on this issue?

Hi @franciscoaguirre, that sounds great :) Are you comfortable with the process of making PRs in general? See https://github.com/bevyengine/bevy/blob/main/CONTRIBUTING.md#contributing-code for a refresher if you need it.
This should be a straightforward PR: just drop the snippet into place, and write a simple test to verify that it works as expected :) Feel free to open a draft PR (that says "Closes #3392" in its body) and then ping me for questions in that thread (or ask around in #scenes-dev on Discord).

What is the actual use case here? This enables nested boxing, which i'd like to avoid unless absolutely necessary.

I don't immediately remember the end user use case right now. I suspect that #3694 will help.

IIRC someone wanted to store Box<dyn Reflect>s in a component (possibly a Vec of them), and still be able to reflect that component.

For example, I have a struct that contains modified components from the last network tick (and components represented as dyn Reflect) that I need send over the network. Is this a valid use case or is there a better way to achieve this?

For this, it feels like what we really want is better DynamicScene support, and the ability to use those for that sort of diff-ing operation. We already have a tool for the serde of collections of dynamic components, but it's not clearly documented and the use case hasn't been fleshed out.

What is the actual use case here? This enables nested boxing, which i'd like to avoid unless absolutely necessary.

I ran into this while trying to write a task system for my game:
#[derive(Component, Reflect)]
struct MoveTask {
    to: Vec3,
    next_task: Box<dyn Reflect>
}

/* more tasks here ... */

#[derive(Component, Reflect)]
struct NoOpTask {
    next_task: Box<dyn Reflect>
}

fn no_op_task_tick(
    mut commands: Commands,
    q_tasks: Query<(Entity, &NoOpTask)>
) {
    for (entity, task) in &q_tasks {
        commands.entity(entity).remove::<NoOpTask>();
        if let Some(new_task) = task.next_task {
            commands.entity().insert_reflect(new_task);
        }
    }
}

There might be a better way of doing this, like a command for inserting a Box<dyn Component>.

I have found this to be something I would have used - also for a task system. My task steps were components that I pull out of a Vec<Box> and place the active step on the task. This worked very well, but I ran into a problem when implementing save / load using bevy reflect. I had to temporarily switch to every task step being an entity (each with one component). In my case, I was basically using an Entity as a level of indirection to the dyn Reflect component I was interested in.


How to interpret byte streams as numerical objects?

LSIO will now be completely agnostic to the contents of the data. LSIO will "just" perform IO.


Clarification required: Authorization/Authentication tokens

Regarding the OAUTH Tokens used for authentication and authorisation, we require some clarifications

The OSDM Provider's IDM will provide pairs of access token/refresh token
They will be JWTs (JSON Web Tokens) (at least the access token)
The token endpoint will return the expiry time of the access token in the standard way
An OSDM Consumer can request and use multiple sets of access/refresh tokens for the same IDM account in parallel (to support distributed/parallelized consuming services). In particular, requesting a new token pair from the IDM does NOT invalidate previously issued tokens which have not yet expired

might be covered by JWT - to be checked

Addressed in documentation.


Backward History fails on foreign keys

System information:

Windows 10 x64 pro
DBeaver 21.2.5

Connection specification:

SQL Server Database
Microsoft JDBC Driver for SQL Server

When jump to a foreign key record

Backward history does not work. either shortcut (ALT+left) or menu (it seems disabled)

Steps to reproduce, if exist:

execute a select from a table that has a foreign key to another table

Click on foreign key column icon (as Shows image 1)

Try to go backward to the original select, using the shortcut (ALT+left) or the menu (Image 2)

This worked fine on 21.2.4 version
Thank you

thanks for the report

Probably side effect of that ticket #13318

Fixed

Thanks.
Congratulations for the good work you do with this great software

verified.
Fix will be available in 21.3.0


Optional "[]" syntax for std.range.iota too

bearophile_hugs reported this on 2013-06-24T14:01:52Z
Transfered from https://issues.dlang.org/show_bug.cgi?id=10466
CC List

hsteoh
joseph.wakeling
monarchdodra

Description
There are _many_ situations where you want to iterate on a full range of an integral value using iota, and you want the iteration variable to be of that type.

Unfortunately this doesn't iterate on the last value:

iota(ubyte.min, ubyte.max)

And this doesn't yield ubytes:

iota(ubyte.min, ubyte.max + 1)

So a simple solution comes copying from std.random.uniform, using the optional "[]" syntax:

iota!"[]"(ubyte.min, ubyte.max)

bearophile_hugs commented on 2013-08-25T15:23:48Z
(In reply to comment #2)
> I like this idea, though there are some corner cases we need to clarify,
> namely, what should iota!"(]"(0.0, 1.0, 0.3) and iota!"()"(0.0, 1.0, 0.3) do?

I don't use iota with floating point arguments, it's too much tricky. I prefer to write code that doesn't make my head hurt trying to understand its exact semantics months later.

So my first answer is: disallow FP types for iota(). I know this probably will not happen, so let's see. This is what the arange() function of the Python good numpy library gives for those intervals:

>>> from numpy import arange
>>> arange(0.0, 1.0, 0.3)
array([ 0. ,  0.3,  0.6,  0.9])
>>> arange(0.0, 1.0, 0.3)
array([ 0. ,  0.3,  0.6,  0.9])

So I presume your iotas should give:

iota!"(]"(0.0, 1.0, 0.3)
==>
[0.3; 0.6; 0.9]

iota!"()"(0.0, 1.0, 0.3)
==>
[0.3; 0.6; 0.9]

bearophile_hugs commented on 2013-07-25T17:12:00Z
Another use case:

auto lazy_lower_case = iota!"[]"('a', 'z');

Currently you should use this that is much less handy (and it doesn't work for other reasons):

iota('a', '{')

joseph.wakeling commented on 2013-08-31T00:34:59Z
(In reply to comment #4)
> Hmm, iota with FP gets tricky, because, for example, 0.1 does not have an exact
> representation in floating-point. So if you write iota(0.0, 1.0, 0.1), it's
> unclear whether 1.0 will be included or not (for example, you may end up with
> 0.999999998 and it gets included, or it may end up with 1.0000001 and get
> excluded).

Surely that should be a case of, "use with FP at own risk".  There are cases where it might be useful, but as with all things, you need to understand the possibility of rounding error.

I got bitten rather amusingly by such an example where I was doing a for () loop across [0, 1] in 0.1 increments.  GDC and LDC can handle that, DMD couldn't, and I had to switch to increments that were negative powers of 2.  If you can trust the user to implement a for () loop correctly, you can trust them to do the same with iota().

Bottom line -- iota() currently does allow FP numbers and excluding them would be a breaking change.

bearophile_hugs commented on 2013-08-25T19:46:49Z
(In reply to comment #4)

> Which makes iota!"[]" and iota!"()" unreliable when used with FP. :-(

If you want to keep things simpler and you prefer a safer enhancement (that doesn't forbid future enhancements to support FP) and you want to allow the "[]" syntax only for integral types (including in future BigInt), this is OK for me :-)

joseph.wakeling commented on 2013-08-31T12:37:42Z
(In reply to comment #7)
> I understand the general meaning of your words, and I could agree, but at the
> moment there is no D code around shaped as "iota!"(]"(0.0, 1.0, 0.3)", so
> formally there is no breaking. A code breaking change is when code that used to
> work suddenly stops working or silently has a different semantics.

No, but there is D code shaped around iota(0.0, 1.0, 0.3) which is semantically identical to iota!"[)"(0.0, 1.0, 0.3), which is part of the proposal.

So, if there is going to be any "choice of boundary conditions" generalization of iota, it should work as a seamless generalization of all the behaviour it currently supports -- which includes both integral and floating-point types.

hsteoh commented on 2013-08-25T19:24:55Z
Hmm, iota with FP gets tricky, because, for example, 0.1 does not have an exact representation in floating-point. So if you write iota(0.0, 1.0, 0.1), it's unclear whether 1.0 will be included or not (for example, you may end up with 0.999999998 and it gets included, or it may end up with 1.0000001 and get excluded).

One example given in the python docs (http://docs.python.org/3/tutorial/floatingpoint.html) is that 0.1 + 0.1 + 0.1 != 0.3, because neither 0.1 nor 0.3 have exact representation in FP. So if you write iota(0.1, 0.3, ...) you might get surprised by the results. Which makes iota!"[]" and iota!"()" unreliable when used with FP. :-(

Similar issues exist if we implement issue #10762, if the user-defined type supports ++ and -- or +=, but does not have exact semantics.

bearophile_hugs commented on 2013-08-31T03:25:36Z
(In reply to comment #6)

> Bottom line -- iota() currently does allow FP numbers and excluding them would
> be a breaking change.

I understand the general meaning of your words, and I could agree, but at the moment there is no D code around shaped as "iota!"(]"(0.0, 1.0, 0.3)", so formally there is no breaking. A code breaking change is when code that used to work suddenly stops working or silently has a different semantics.

hsteoh commented on 2013-08-25T14:41:32Z
I like this idea, though there are some corner cases we need to clarify, namely, what should iota!"(]"(0.0, 1.0, 0.3) and iota!"()"(0.0, 1.0, 0.3) do?


Support for SVG

@boylesean  The SVG now can be clicked to pop up. Please provide more details about your problems and how to support for SVG.

Two examples:

Creating a diagramme in plantuml, specifying the codeblock with ```plantuml-svg
Creating a diagramme in D2, specifying the codeblock with ```d2

They both supposedly create an svg which renders just fine in Obsidian, but clicking does not pop up the image in image-toolkit.


User-Self-Service

hi,
is something like a User-Self-Service for eg.

Password reset
Manage external Accounts (FB/Google/MS/ADFS)
Change some UserInfo-Claims (Name, Tel, EMail, Mobile)
planned?

@brockallen already working on this?

No. I think this is beyond the scope of what IdMgr is about. If you want to add this and submit a PR, then feel free to discuss here. But the UI architecture doesn't have any concept of self-service.

Personnally, I think this should be considered for IdentityServer3, not IdentityManager.

Yes, at this point IdMgr is really for devs and admins. I'll close this to reflect that.


Major update.

This branch has been out there, and in use, for some time.
Removes old things, adds news things, updates most things.
Works well with bedrock-{webpack,vue,quasar,fontawesome} updates.
Pardon the mess, but other watch# branches may need to stay around until projects are updated.

There may be some more code that can be removed here.  The package.json bedrock manifest code is still processed.  It was useful for systemjs processing, but may not be needed at all anymore?
The custom bedrockDependencies was also for systemjs.  It could still be used to override reading all deps with a custom list, but I'm unsure if that has a real use case?
The above can be handled later as needed.

@gannan08, @aljones15, @mattcollier -- please specifically weigh in on whether you think we still need the old features @davidlehn mentioned. Ideally we'd clean out the cruft and have less to maintain.

very much in favor of eliminating browserDependencies if possible.

The above can be handled later as needed.

@davidlehn If this is the case then remove old code.

@mattcollier The default behavior is now to work as if "browserDependencies": "all" was specified, and it just reads all the dependencies.  I'm unsure if there's a use case where you would want to override that to only look at specific deps.  I think all our current projects should/need to be updated to just remove their browserDependencies configuration.

@gannan08 You are suggesting to just remove all the old stuff now?  I had been thinking just leaving some of the old support in there for the next release, update all the active projects, then we'll have more info to determine if we can clean up unused features even more.

bedrock.{manifest,browserDependencies} support now removed.

Found an annoyance.  bedrock-webpack uses a frontend polyfill file that may require you to have top-level deps on core-js and regenrator-runtime.  It just depends on what other dependencies you have and how npm lays them out.  I added an upgrade note here about it.  We can probably ignore it for now unless someone wants to look into the issue and find a better solution.


is it support win10？

good afternoon sir.
【my configuration as below】：
computer operation syste：win10
spring-startup-analyzer：v2.0.6
jdk-version：open-jdk17
springbootversion：3.1.1
【question desc】：
i am create a new springboot project，it not contains anyone other maven pom，at my install jar after，i try start it，cmd line as below：
java -jar demo-0.0.1-SNAPSHOT.jar -javaagent:C:/xxx/Downloads/Analyzer/lib/spring-profiler-agent.jar
i am ensure my spring-profiler-agent.jar path no mistake，but，why start springboot application at after, i don't see "======= spring-startup-analyzer finished, click http://localhost:8065 to visit details. ======
" infomation，aslo not any other err infomation，just like a normal springboot start the same，why？extra i don't see the type of support  of  Analyzer project

Have you configured the spring-startup-analyzer.app.health.check.endpoints option?

You need to implement a health check interface and then configure the spring-startup-analyzer.app.health.check.endpoints option.
For example, the health check interface as follow:
@RestController
public class Home {
        @RequestMapping({"/health"})
    public String index(Model model) {
        return "index";
    }
}

and then you need to set -Dspring-startup-analyzer.app.health.check.endpoints=http://localhost:7002/health

You need to implement a health check interface and then configure the spring-startup-analyzer.app.health.check.endpoints option.
For example, the health check interface as follow:
@RestController
public class Home {
        @RequestMapping({"/health"})
    public String index(Model model) {
        return "index";
    }
}

and then you need to set -Dspring-startup-analyzer.app.health.check.endpoints=http://localhost:7002/health

i have add this start command param now：“-Dspring-startup-analyzer.app.health.check.endpoints=http://localhost:7002/health”，now my springboot demo project start console appearing  "Server listening on port 8065"，and appearing log/startup.log file at my Analyzer directory，but, I still cannot access local port 8065 to view my bean analysis logs，the status of this webpage is ERR_ EMPTY_ RESPONSE，then, i am findout my spriingboot-Analyzer startup.log，everything is normal log information，
just have two warn logs is ：“Current OS do not support AsyncProfiler, Only support Linux/Mac.” with “AsyncProfiler instance is null, can't execute start command.”
my goal is when the application starts in Java Agent mode, it is dynamically loaded into the jvm and runs together with the application. then, I view my bean analysis log on a page
what mistakes may I have made,please point out that ,I will try and findout. thank you for taking the valuable time to answer

You can check if output/*-analyzer.html exists and the html relies on online resources: https://cdn.tailwindcss.com and https://cdn.skypack.dev/hyperapp ,ensure your environment can access these online resources.

You need to implement a health check interface and then configure the spring-startup-analyzer.app.health.check.endpoints option.
For example, the health check interface as follow:
@RestController
public class Home {
        @RequestMapping({"/health"})
    public String index(Model model) {
        return "index";
    }
}

and then you need to set -Dspring-startup-analyzer.app.health.check.endpoints=http://localhost:7002/health

i have add this start command param now：“-Dspring-startup-analyzer.app.health.check.endpoints=http://localhost:7002/health”，now my springboot demo project start console appearing "Server listening on port 8065"，and appearing log/startup.log file at my Analyzer directory，but, I still cannot access local port 8065 to view my bean analysis logs，the status of this webpage is ERR_ EMPTY_ RESPONSE，then, i am findout my spriingboot-Analyzer startup.log，everything is normal log information，
just have two warn logs is ：“Current OS do not support AsyncProfiler, Only support Linux/Mac.” with “AsyncProfiler instance is null, can't execute start command.”
my goal is when the application starts in Java Agent mode, it is dynamically loaded into the jvm and runs together with the application. then, I view my bean analysis log on a page
what mistakes may I have made,please point out that ,I will try and findout. thank you for taking the valuable time to answer

The new version v2.0.7 has implemented CDN resource localization, you have a try again.


youtube url

https://www.youtube.com/watch?v=rlJ_jVekIc4

@liangchenye Thanks, it is OK now.
https://github.com/huawei-openlab/harbour#demo


Node 4: Use embedded OpenSSL headers first

This a workaround for the compilation
error with Node 4:
../vendor/openssl/openssl/ssl/s3_clnt.c:3262:60: error: use of undeclared identifier 'EVP_PKT_EXP'
Node 4.0.0 includes openssl 1.0.2d, which
no longer defines EVP_PKT_EXP and friends.
node-gyp puts header directories supplied
by node first, therefore OpenSSL include
files shipped by node are used, and
not the ones from the embedded OpenSSL
source.

Wow, brilliant, thank you @saper!

On Mon, 14 Sep 2015, Tim Branyen wrote:

Wow, brilliant, thank you @saper!

Why can't we use OpenSSL that ships with node?

I'm not sure, if you can figure out how to make it work, we'll happily accept a PR.

I'm not sure, if you can figure out how to make it work, we'll happily accept a PR.

ah, ok, I wasn't sure if this was given any consideration and there were some issues
which made us not do it.

@saper I vaguely remember trying to get it work ages ago, I think @TooTallNate or someone else had info on linking to it wrt node-gyp.  I think we gave up due to Windows issues and decided to build our own.

Still an issue unfortunately: https://github.com/nodejs/node-v0.x-archive/issues/4051

Thanks @ToolTallNate. So what we need is the intelligent way, cross-platform way to create list of the APIs exported (to generate a linker export map)?

Thanks @TooTallNate. So what we need is the intelligent way, cross-platform way to create list of the APIs exported (to generate a linker export map)?


dev channel sdk version number hiccup

Since 27 Nov 2018 I use the sdk version 2.2.0-dev.0.0, (a few weeks later I also tried out 2.2.0-dev.1.1, but I got some strange errors).
But today I got this message in WebStorm:
Dart SDK Update:
A new version to the Dart SDK (2.1.1-dev.3.2) is availabe for download.
Current version: 2.0.0-dev.35.0.

If I check the Settings, the version is given with 2.2.0-dev.0.0 (from the sdk version file)
On the Dart SDK Website:
https://www.dartlang.org/tools/sdk
dev channel: pre-releases, usually updated 1/week; currently 2.1.1-dev.3.2.
On the Archive page
https://www.dartlang.org/tools/sdk/archive
you can download a version 2.2.0-dev.0.0 and 2.2.0-dev.1.1
So I guess the version 2.2.0-dev.0.0 is in fact the version 2.0.0-dev.35.0 and therefore the latest version is 2.1.1-dev.3.2 ?

2.2.0-dev.0.0 was commited on 2018-11-20 and 2.1.1-dev.0.1 on 2018-12-21, so I'm afraid there was a glitch in the numbering of the former. Downloading the newest one should get you on track again.

2.1.1-dev.3.2 Is the latest dev release. There was a change in our release strategy that meant that we suddenly were aiming for 2.1.1 instead of 2.2.0 on master. That made us change back to the 2.1.1. Unfortunately, that confused some of the package managers and the confusion won't be completely gone until we released the 2.2.0 stable version.

I was VERY VERY VERY confused today until I found this issue.


Preposterous startup time

When running a job with 60,000 input files stored in S3, it can take two hours to check for file existence in generatePlan before the job even begins.
Solutions:

Implement this as many threads, perhaps max(50, number of files / 30)

Have a flag to bypass this check

Automatically skip this check if there are >30 files, since this is almost certainly a list of files generated elsewhere.
private PipePlan generatePlan(List errors) {
...
while (!toGenerate.isEmpty()) {
Pipe file = toGenerate.iterator().next();
toGenerate.remove(file);
boolean exists = file.exists(baseConf);
if (exists && !file.isObsolete(baseConf)
&& (!forceRebuild || file.getProducer() == null)) {
if (!generated.contains(file)) {
System.out.println("File: " + file.getPath()
+ " exists and is up to date.");
// ok already
generated.add(file);
plan.fileCreateWith(file, null);
}

Isn't one of the benefits of this framework is to eliminate redundant work?
The Use case is that the 60,000 files and been previously been process and 2 new files are added and another has been replaced. Running the job over all 60,000 files would be less desirable than the time required to check the dependencies, right?
Of course, there are times when you know you want to replace or force the re-processing of all files, so the proposed feature would be to '-skip' dependency checking or '-force' reprocessing.
I don't like the idea of spawning multiple threads to check HDFS files due to complexity that it would add to Hadoop client code.

I think we can reduce the metadata IO 100-to-1 using the manifest design,
allowing us to keep the dependency checking without a performance penalty
On Fri, Jan 6, 2012 at 10:55 AM, Douglas Moore <
<EMAIL_ADDRESS>
wrote:

Isn't one of the benefits of this framework is to eliminate redundant work?
The Use case is that the 60,000 files and been previously been process and
2 new files are added and another has been replaced. Running the job over
all 60,000 files would be less desirable than the time required to check
the dependencies, right?
Of course, there are times when you know you want to replace or force the
re-processing of all files, so the proposed feature would be to '-skip'
dependency checking or '-force' reprocessing.
I don't like the idea of spawning multiple threads to check HDFS files due
to complexity that it would add to Hadoop client code.

Reply to this email directly or view it on GitHub:
https://github.com/tap-git/tap/issues/2#issuecomment-3388903


Extension 'firebase/storage-resize-images' emulator, not working well with Windows

Environment info
firebase-tools: 11.23.1
Platform: Windows 11
Configuration
firebase.json
{
  "functions": [
    {
      "source": "functions",
      "codebase": "default",
      "ignore": [
        "node_modules",
        ".git",
        "firebase-debug.log",
        "firebase-debug.*.log"
      ],
      "predeploy": [
        "npm --prefix \"$RESOURCE_DIR\" run lint",
        "npm --prefix \"$RESOURCE_DIR\" run build"
      ]
    }
  ],
  "firestore": {
    "rules": "firestore.rules",
    "indexes": "firestore.indexes.json"
  },
  "storage": {
    "rules": "storage.rules"
  },
  "emulators": {
    "auth": {
      "port": 9099
    },
    "functions": {
      "port": 5001
    },
    "firestore": {
      "port": 8080
    },
    "storage": {
      "port": 9199
    },
    "ui": {
      "enabled": true
    },
    "singleProjectMode": true
  },
  "extensions": {
    "storage-resize-images"<EMAIL_ADDRESS>  }
}

extensions\storage-resize-images.env
ALLOWED_EVENT_TYPES=firebase.extensions.storage-resize-images.v1.complete
DELETE_ORIGINAL_FILE=false
DO_BACKFILL=false
EVENTARC_CHANNEL=projects/${param:PROJECT_ID}/locations/europe-west4/channels/firebase
FUNCTION_MEMORY=2048
IMAGE_TYPE=jpeg,webp,png
IMG_BUCKET=demo
IMG_SIZES=500x500
IS_ANIMATED=true
LOCATION=europe-west1
MAKE_PUBLIC=true
RESIZED_IMAGES_PATH=thumbnails

Test case
Steps to reproduce:
Setup Firebase Emulator with config specified above with a demo project. (i use --project demo-ember)
Upload a JPEG to a {folder} in the Firebase Storage Emulator.
Expected result
Thumbnail gets generated/uploaded in a thumbnails/ folder next to the user uploaded file in {folder}.
Actual result
Thumbnail gets generated/uploaded to the root with {folder}\thumbnails\my_image.jpeg as the name``
Related issues
https://github.com/firebase/extensions/issues/1732

I believe this should have been addressed by this PR.
Is this still occuring with the most recent version of the extension?

Still occurring to me

Still occurring to me too

Hey, appreciate this is still occurring and will look into this, I'm going to close this issue here as it's a duplicate of https://github.com/firebase/extensions/issues/1732 just for tracking purposes


Issue with parent resource of type pod

Describe the bug
Connaisseur is making invalid API calls when checking for parent resource, when the parent resource is of type pod.
Detailed description
We are using the kuberhealthy project (https://github.com/kuberhealthy/kuberhealthy), which is an operator for synthetic monitoring on Kubernetes. Kuberhealthy schedules checks (i.e. pods) at specified intervals, those pods run some monitoring tasks, and those pods terminate with a "Completed" status.
Checking for the parent of any of those temporary monitoring pods show:
kubectl get po dns-status-internal-1643848976 -n kuberhealthy -o json | jq ".metadata.ownerReferences"
[
  {
    "apiVersion": "v1",
    "kind": "Pod",
    "name": "kuberhealthy-7d47c7c9d6-m2skw",
    "uid": "f7852c4f-78bc-4573-b72b-1353104d7ba8"
  }
]

In connaisseur logs you will see the following entry:
requests.exceptions.HTTPError: 403 Client Error: Forbidden for url: https://<IP_ADDRESS>:443/apis/v1/namespaces/kuberhealthy/pods/kuberhealthy-7d47c7c9d6-m2skw

This error comes from:
https://github.com/sse-secure-systems/connaisseur/blob/eaa16437426d1dab5335d995ed952bf13d46acfa/connaisseur/workload_object.py#L61-L62
However this is not a valid API call.
curl -s $APISERVER/apis/v1 --header "Authorization: Bearer $TOKEN" --cacert /tmp/ca.crt
404 page not found

My EKS 1.21 cluster shows the following api-resources:
pods                              po                       v1                                          true         Pod
replicationcontrollers            rc                       v1                                          true         ReplicationController
daemonsets                        ds                       apps/v1                                     true         DaemonSet
deployments                       deploy                   apps/v1                                     true         Deployment
replicasets                       rs                       apps/v1                                     true         ReplicaSet
statefulsets                      sts                      apps/v1                                     true         StatefulSet
cronjobs                          cj                       batch/v1beta1                               true         CronJob
jobs                                                       batch/v1                                    true         Job

RestAPI calls targeting the v1 apiVersion (core group) typically use https://$APISERVER/api/... instead of https://$APISERVER/apis/...
I suspect the same error impacts replicationcontrollers objects.

Closing issue as it has been resolved by PR #514 . Feel free to re-open if that is not the case.


Typescript typings generation don't include schema filtered out by filterSchema transforms

Is it by design that the generation of the typescript typings doesn't generate typings for schemas that are filtered out via the filterSchema transform?
I want to generate typings for all my sources via:
graphql-mesh typescript --output ./src/generated/mesh.ts

So that I can use the typings in my additional-resolvers.  However, I only want to expose some Queries when running the graphql server via:
yarn graphql-mesh serve

Is there a better way to accomplish this?

@fvllam Could you share a reproduction?

Hi @ardatan
Suppose I have 2 graphql endpoints, One and Two.
One's schema:
type Query {
  oneQuery: TypeOne
}
type TypeOne {
...
}

Two's schema:
type Query {
  twoQuery(input: TwoInput): String
}

input TwoInput {
  a: String
}

Say my .meshrc.yaml looks something like this:
sources:
  - name: One
    handler:
      graphql:
        endpoint: <one endpoint>
  - name: Two
    handler:
      graphql:
        endpoint: <two endpoint>
transforms:
  - filterSchema:
      - Query.!twoQuery
  - extend: |
      extend type TypeOne {
        myCustomField: String
      }
additionalResolvers:
  - ./lib/additional-resolvers.js

And in the additional resolver (typescript) code I want to resolve TypeOne{ myCustomField } by calling the sdk for Two.api.twoQuery.
However, during the build step when I generate the sdk and compile the typescript
graphql-mesh typescript --output ./src/generated/mesh.ts
tsc

I get an error from tsc:
error TS2304: Cannot find name 'QueryTwoQueryArgs'
Looking at the generated mesh.ts it seems the TwoSdk gets generated and references twoQuery and QueryTwoQueryArgs, but the definition for QueryTwoQueryArgs is not generated.
If I remove the schemaFilter transform then it generates and compiles fine but defeats the goal.

Available in https://github.com/Urigo/graphql-mesh/releases/tag/v0.2.11


Upgrade to GWT 2.8.0-rc2

Related:
https://github.com/uberfire/uberfire/pull/493
https://github.com/dashbuilder/dashbuilder/pull/232

+1


Need SDK documentation

Hey, the library is great, but we need documentation.  The Nuget package does not install any xml documentation for the classes.
Is there documentation anywhere for this library?

@escallin , you are correct, we do not yet have documentation. I'm sorry for that, we'll try to get some documentation in the future. In the interim - do you have any questions that I can help you with? We do have some sample code that shows some examples of how to use the library and there are more than 30 unit tests as well that exercise the code, those can be useful as well. I do acknowledge the need for formal documentation, we haven't had a chance to assemble that yet. Let me know if I can assist in any way.

Hello Inbar.  Thank you for the quick reply.  I noticed that a lot of the source code IS xml commented.  If you could include all the xml comments as a separate XML Documentation file so that intellisense would work, that would be a good start.
I am trying to accomplish a specific task that you don’t have an example for.  Let me write up a scenario and I will send it to you.  Should I ask it in the “issues” board here at github, or is there a better place?
Thanks,
Eric
From: Inbar Gazit<EMAIL_ADDRESS>Sent: Thursday, March 12, 2015 11:43 AM
To: docusign/DocuSign-.NET-Client
Cc: Eric Scallin
Subject: Re: [DocuSign-.NET-Client] Need documentation (#13)
@escallinhttps://github.com/escallin , you are correct, we do not yet have documentation. I'm sorry for that, we'll try to get some documentation in the future. In the interim - do you have any questions that I can help you with? We do have some sample code that shows some examples of how to use the library and there are more than 30 unit tests as well that exercise the code, those can be useful as well. I do acknowledge the need for formal documentation, we haven't had a chance to assemble that yet. Let me know if I can assist in any way.
—
Reply to this email directly or view it on GitHubhttps://github.com/docusign/DocuSign-.NET-Client/issues/13#issuecomment-78506084.

@escallin , I see, you can get the source here and then would have intelisense, but you want to use the nuget and it's not coming through, right? we would definitely get this fixed soon. I need to figure out how to do that and would get back to you.
As for the scenario - sure, feel free to open an issue here so it's publicly shared with others who might have the same need.
Thanks for your patience!

Yes, that’s correct.  The nuget package only downloads the compiled dll.
I was able to compile the source code from github and output the XML Documentation file.  Once the file is place with the dll from NuGet, the Intellisense will work.  I think you should still include it in the NuGet package so that it updates.
I did notice that the source code is not as well documented as I thought.  Most of the documentation is generic like "Get or Sets the xxxx property".  Really need to now what the property or method is used for.
Thanks,
Eric

Thanks Eric, I appreciate the feedback. We would do our best to improve documentation in the future. Please let me know if there's something I can help you with in the interim.

Has there been any progress on this? It would be very useful if NuGet installed IntelliSense xml files along with the library. It is quite a pain to have to have the documentation open in one window with Visual Studio in another. People with only one monitor I'm sure are wearing out their ALT and TAB keys.
I did some quick digging, and I think this is what  you want.

Hi Everybody,
First, I do apologize for our (DocuSign's) very slow responses to issues raised in the repo. We've reorganized to improve matters.
We share your desire to document the SDK itself. Since each SDK method has a one-to-one correspondence to an API method, the API reference documentation can often be used.

I've entered internal enhancement request DEVDOCS-1148

Any update on this?


helm: Support setting annotations for nodePlugin and provisioner

Add annotation support for both the RBD and CephFS Helm charts.  Allow setting annotations at the nodePlugin DaemonSet level and Pod level and at the provisioner Deployment and Pod level.  This change will not make any changes to existing deployments by default.  Changes will only be made if the nodePlugin.podAnnotations, nodePlugin.annotations, provisioner.annotations, or provisioner.podAnnotations values are set.  While testing I discovered that there was an existing pre-commit error with the check-yaml hook.  It fails on the devel branch when testing the helm templates, presumably due to them being templates and not pure yaml files.  I added an exclusion for these templates to get the hooks to pass.

@mergifyio rebase

@mergifyio queue

Thanks for the PR @mvollman!


Rope performance is Really Bad

even after #28, we get the following benchmark results:
test tests::rope_add_1000      ... bench:  92,545,093 ns/iter (+/- 8,325,688)
test tests::rope_insert_1000   ... bench:  18,670,209 ns/iter (+/- 2,987,965)
test tests::string_add_1000    ... bench:     227,800 ns/iter (+/- 8,419)
test tests::string_insert_1000 ... bench:   3,262,551 ns/iter (+/- 313,452)

Time to find some hotspots in need of optimisation....

I suspect we're spending a lot of time in rebalance(), and I'm going to see if rebalancing performance can be improved. Gonna try to do some profiling & see what happens.

@cjm00, do you have any thoughts?

According to some quick profiling I did in Xcode Instruments, in the rope_add_1000 test, about 39% of our time is spent clone()ing and a whopping 49% is spent in drop()

Oh, you know what, the add test is biased against us a bit, since the Rope + operator is the immutable append operator. So each test iteration we were spending a lot of time creating new Ropes, and then drop()ping them, which wasn't happening for the String

A slightly fairer benchmark gets us the following results:
test tests::rope_add_1000      ... bench:  19,723,159 ns/iter (+/- 2,204,592)
test tests::rope_insert_1000   ... bench:  24,254,046 ns/iter (+/- 5,445,680)
test tests::string_add_1000    ... bench:     249,592 ns/iter (+/- 84,816)
test tests::string_insert_1000 ... bench:   3,272,854 ns/iter (+/- 672,410)

Performance still needs work, but it is not quite as tragic as I thought.

so, uh,

with rebalancing disabled:
test tests::rope_add_1000      ... bench:  12,757,218 ns/iter (+/- 2,015,672)
test tests::rope_insert_1000   ... bench:   8,874,948 ns/iter (+/- 1,053,272)
test tests::string_add_1000    ... bench:     249,911 ns/iter (+/- 7,707)
test tests::string_insert_1000 ... bench:   3,156,994 ns/iter (+/- 300,301)

of course, we should get some performant benefits from maintaining a balanced Rope, but it looks like our current (recursive) implementation is a time-suck.

Yikes. Unfortunately the internet here is less reliable than I'd like, but
we'll have to deal with this for sure.
On Dec 26, 2016 2:55 PM, "Eliza Weisman"<EMAIL_ADDRESS>wrote:

with rebalancing disabled:
test tests::rope_add_1000      ... bench:  12,757,218 ns/iter (+/- 2,015,672)
test tests::rope_insert_1000   ... bench:   8,874,948 ns/iter (+/- 1,053,272)
test tests::string_add_1000    ... bench:     249,911 ns/iter (+/- 7,707)
test tests::string_insert_1000 ... bench:   3,156,994 ns/iter (+/- 300,301)
of course, we should get some performant benefits from maintaining a
balanced Rope, but it looks like our current (recursive) implementation is
a time-suck.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/hawkw/an-editor/issues/34#issuecomment-269241262, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AETT5oROOXWU3N6gNsZKMHlPfWPuVbxrks5rMCm6gaJpZM4LVfFP
.

That's fine, it can wait 'til you get back. Thinking about going ahead & rewriting Rope to allocate all nodes in an Arena...

(something like this binary tree impl: https://github.com/TeXitoi/benchmarksgame-rs/blob/master/src/binary_trees.rs)

That's probably a good place to start. You could look at how xi-editor
implements its Rope as well, I've been meaning to do that.
On Dec 26, 2016 3:08 PM, "Eliza Weisman"<EMAIL_ADDRESS>wrote:

(something like this binary tree impl: https://github.com/TeXitoi/
benchmarksgame-rs/blob/master/src/binary_trees.rs)
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/hawkw/an-editor/issues/34#issuecomment-269241918, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AETT5mvWDth2NKgiGYGIQZX8fNhmBjYvks5rMCzNgaJpZM4LVfFP
.

Their Rope implementation (having peeked at the source just now) is not based on Arena allocation; they're using a persistent immutable rope with Rcs.

(which, as a side note, I still think is probably a much easier way to implement an edit history - implementing all editing commands so that they're undo-able seems Not Trivial)

Also, an Rc rope would cut down on cloning & allocation a lot, since similar ropes can just share a majority of their nodes. Might result in a significant performance improvement.
Of course, if we go that route, we can't provide an API with method signatures that match String,  but I'm beginning to question whether matching String's API exactly is really the best option (see #23)...

I'm going to try throwing together quick implementations of both an Arena rope and an Rc rope, and doing some more in depth benchmarking.
We may also want to look into servo/tendril as a replacement for Strings in our Rope. A Tendril is essentially a string, but it doesn't allocate for text less than 8 bytes long. This might shave off a lot of allocations in cases when the Rope is fragmented, especially like when appending a lot of short text segments.

The rope-persist branch adds a very quick first pass on a Rope with Rcs.  Rebalancing is not implemented yet, and I think there's a lot of improvements that could be made to the way it uses its Rced pointers.
Performance results:
test tests::rope_add_1000      ... bench:  12,023,458 ns/iter (+/- 1,973,965)
test tests::rope_insert_1000   ... bench:   9,433,005 ns/iter (+/- 2,317,771)
test tests::string_add_1000    ... bench:     245,912 ns/iter (+/- 81,211)
test tests::string_insert_1000 ... bench:   3,577,902 ns/iter (+/- 1,048,494)

Very similar to performance with mutable Ropes. It looks like adding may be slightly faster and inserting may be slightly slower, but both are probably within the margin of error enough that we can basically say "performance is the same".

Persistent rope performance with tendrils:
test tests::rope_add_1000      ... bench:  11,727,258 ns/iter (+/- 1,593,874)
test tests::rope_insert_1000   ... bench:   9,225,393 ns/iter (+/- 1,529,663)
test tests::string_add_1000    ... bench:     220,916 ns/iter (+/- 36,505)
test tests::string_insert_1000 ... bench:   3,112,728 ns/iter (+/- 201,573)

rope-persist also adds support for thread-safe (atomic) ropes, using Arcs, or, if tendril is enabled, using atomic Tendrils:
atomic ropes with Arc:
test tests::rope_add_1000      ... bench:  12,565,666 ns/iter (+/- 2,003,767)
test tests::rope_insert_1000   ... bench:   9,886,233 ns/iter (+/- 1,433,699)
test tests::string_add_1000    ... bench:     239,453 ns/iter (+/- 25,660)
test tests::string_insert_1000 ... bench:   3,311,874 ns/iter (+/- 461,709)

atomic ropes with atomic Tendrils:
test tests::rope_add_1000      ... bench:  12,056,925 ns/iter (+/- 1,668,730)
test tests::rope_insert_1000   ... bench:   8,824,835 ns/iter (+/- 1,247,299)
test tests::string_add_1000    ... bench:     223,351 ns/iter (+/- 71,106)
test tests::string_insert_1000 ... bench:   3,117,460 ns/iter (+/- 452,039)

As above, tendril gives us very slightly better performance but not significantly.

I'm wondering what the performance of a mutable Arena-based Rope with Tendrils would look like. I'll start on writing that either this evening or tomorrow.

One concern with an Arena is that, as @twisted-pear pointed out, it'll start to leak memory if the arena-backed structure lives too long. A potential solution could be adding a free list of nodes that can be overwritten

Okay, I've made some changes that massively improve our performance - it turns out that I had overlooked something really embarrassingly obvious.
We were caching the length on each node, but never actually using the cached length - we were calculating it each time. And even though calculating a node's length isn't a really slow operation, we use lengths enough that we were spending NEARLY FIFTY PERCENT of our total run time in calls to Node.len(). I knew this was gonna be something really embarrassing 😳
Anyway, commit 2bb1602fae37e8616dc695918eb4695d1d13fa94 fixes this.
New performance numbers on master (with rebalancing still disabled), and after making some tweaks to benchmarks across the board:
test tests::rope_add_1000      ... bench:     141,526 ns/iter (+/- 38,626)
test tests::rope_insert_1000   ... bench:     370,765 ns/iter (+/- 108,240)
test tests::string_add_1000    ... bench:      56,680 ns/iter (+/- 8,351)
test tests::string_insert_1000 ... bench:   3,450,232 ns/iter (+/- 665,061)

I think you'll agree that's much less tragically bad.

Given our perf numbers after 2bb1602fae37e8616dc695918eb4695d1d13fa94, I'm gonna call this closed. Additional work on optimisation would be nice, but Rope performance is no longer unusably slow.

Performance with rebalancing is still really bad, though. I'm going to move discussion of rebalance performance to #27.


Allow multiple gems to be uploaded at once

great little improvement. thanks

try to test it locally and get a new gem out

@jasonmk FYI just pushed a new version to rubygems.org with your patches - thanks again


fix: unstoppable domains test

Problem solved
Short description of the bug fixed or feature added

PR-Codex overview
This PR updates the test suite for resolving addresses in the Unstoppable Domain extension. It modifies the test structure to conditionally run based on the presence of an environment variable, enhancing flexibility.
Detailed summary

Changed describe to describe.runIf(process.env.TW_SECRET_KEY) for conditional test execution.
Maintained the test for resolving an existing address.
Kept the test for handling non-existent domain names unchanged.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

Merge activity

Nov 11, 7:03 PM EST: The merge label 'merge-queue' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.


HTTP.sys: Update sample code from 3.x to 8.0

Make an 8.x version of
https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/fundamentals/servers/httpsys/samples/3.x/SampleApp  in the newly created 8.x folder
@david-acker  are you interested in this

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

ID: 5e347c54-6a6a-d685-4af7-39b023bf7f15
Version Independent ID: 41aa77f5-9466-6580-5ec6-b1bf97bd0f01
Content: HTTP.sys web server implementation in ASP.NET Core
Content Source: aspnetcore/fundamentals/servers/httpsys.md
Product: aspnet-core
Technology: aspnetcore-fundamentals
GitHub Login: @tdykstra
Microsoft Alias: riande

@Rick-Anderson Sure! I can get started on this tomorrow.

@david-acker Consider starting with an empty project. I think you can do everything with that.


Use mainly IdpProfiles for email search.

Coverage increased (+0.004%) to 89.701% when pulling 07c714ee3c00c44bc62ec9ce865188a1b2e7a5f7 on akatsoulas:profile-email-search into f1458326c90d92fd758f8d8c9782e0716c1e8aa8 on mozilla:master.


Suggested addition to Instruction.md

Thanks for providing the Dockerfile - super convenient to use instead of compiling and installing the code. I suggest you add some more details of how to use the dockerfile in the Instruction.md file, since it is not crystal clear currently:
To build the docker img:
docker build -t house_3d:v0 .

Here is the command I used to run the docker container w/ GUI forwarding and mounting of my external drive that holds the SUNCG objects:
nvidia-docker run -it --name house_3d_instance --env="DISPLAY" --env="QT_X11_NO_MITSHM=1" --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" -v /mnt/ubuntu_extra_ssd:/mnt/ubuntu_extra_ssd house_3d:v0

Then, you can test the code using:
python3 tests/test-rendering.py --interactive /mnt/ubuntu_extra_ssd/SUNCG/house/05cac5f7fdd5f8138234164e76a97383/house.obj

If everything is working, a window should pop up with a bunch of green (blank space) and a fenced house with a car and basketball hoop in the driveway (assuming you grabbed the example asset from the Instruction.md):

You can use the keyboard to move the camera view around and on each step it should cycle between RGB, Semantic Label, Semantic Instance Label, and Depth image.

This is really helpful, thanks much! @mfe7